IT Security, Standards, and Compliance
You can often see the classic divide between technical and compliance persons in information technology within teams or organisations. Writing guidelines and writing configurations for implementation seem very different, with no overlaps. In reality, everyone has procedures. While they might not be written or follow a standardized format, having your ways of doing things is crucial to succeed in IT. The same goes for security. Creating policy documents and describing procedures in a way that technical minds can actually use them is a challenge. There is a crossover with the profession of writers who are experts in conveying nonfiction stories. And this is the origin of the schism between technicians and the compliance world. Badly written policies are a security risk, because no one takes them seriously. The purpose of your procedure documentation is to look things up when in trouble. Policies should let you stay out of trouble in the first place. They are the blueprints for everything that comes once you deploy and implement.
DeepSec had a few presentations covering the dreaded compliance topic. Well-written policy documents should be part of your toolbox. Since writing text and writing code are closely related, it’s a good idea to polish your writing skills. There is also lots of work to get started with practising. The European NIS2 directive is due to be put in law this autumn. After that you can continue to preparing the EU Cyber Resilience Act procedures and documents. In between, you can review your internal IT security policy. Check if the document is of any use for answering security-related questions. If not, then do some refactoring.
The call for papers for both DeepINTEL and DeepSec are still open. If you have some experience with fixing the divide between technical and compliance minds, please submit!