How to write security policies, standards and procedures
Security documentation fails for predictable reasons: it is too long, it mixes the three document types together, it is written for auditors rather than for the people expected to follow it, and nobody owns keeping it current. Getting the structure right solves most of that.
What this session covers
- A policy states intent and is short, stable and approved at a senior level. It says what must be true, not how.
- A standard sets the specific, measurable requirement — the minimum key length, the patching window, the review frequency.
- A procedure is the step-by-step detail for the people doing the work, and changes most often.
- Every document needs an owner, an approval record, a version and a review date. Documentation without these is not governance.
The most useful discipline is to write for the reader who has to comply, not the auditor who has to check. If a standard cannot be understood by the engineer expected to implement it, it will not be implemented consistently, and the audit finding that follows is a symptom rather than the problem.
Keep policies short enough that people will actually read them. Length is not rigour.
Go further with mentorship
This session is part of our free twelve-week GRC series. If you want structured, mentor-led support to turn this into a job-ready skill set, the LSCS GRC Mentorship programme runs over six months with live sessions, real case studies and interview preparation.