Security Policy Management Pack — Guide
- Version 1.1
- Updated
- Next review
Security Policy Management Pack
Most organisations have security policies; few have policies anyone reads. They were copied from a template years ago and name people who have left. When an auditor asks who has read them, nobody can show it. This pack helps you build a smaller set of documents that people follow, keep it current, and prove it has been read.
Is this for you?
This pack is for you if:
- you inherited a folder of policies and are not sure which ones are in force;
- your policies have no owner, or a review date nobody checks;
- an auditor asked for evidence that staff have read them, and you had none.
How many documents you need
Fewer than you might think. The pack lists 18 topics, and when each is needed:
| Your organisation | Topics to cover |
|---|---|
| Core: every organisation | 7 |
| Growing: about 50 people or more | 15 |
| Regulated: NIS2 essential or important entity, or DORA financial entity | 18 |
Developing software in-house adds secure development and change management to any profile.
A policy says what the organisation commits to; the detail goes into standards and procedures, approved lower down. Every document sits in one of four tiers:
| Tier | Who approves it | Reviewed at least every |
|---|---|---|
| Policy | Executive management | 12 months |
| Standard | Head of Information Security (the document owner is consulted) | 12 months |
| Procedure | Head of Information Security (the process owner is consulted) | 24 months |
| Guideline (advice, not mandatory) | Information security | 24 months |
The top policy is approved by the board or its equivalent. Who that is depends on how the organisation is governed: the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, such as in an owner-managed company, executive management. In a NIS2 or DORA entity, the management body itself approves it, not a committee it has delegated to.
Review sooner after a major incident, a material change, a change in law, an audit finding or a shift in threats. Keep each policy to four pages of body at most.
Start with these three
- Policy Framework Standard — the twelve rules every security document follows.
- Security Policy Document Template — nine sections, with requirements an auditor can test.
- Policy Register & Review Schedule — the one authoritative list of your documents and their review dates.
Your first month
| When | What to do | You’re done when |
|---|---|---|
| Week 1 | Name the approver for each tier in the Framework Standard. Collect every security document. | Management has approved the Standard. |
| Week 2 | Register every document with an owner. Run the gap assessment. | You know what is missing, duplicated or overdue. |
| Week 3 | Rewrite the top policy and the most overdue one in the template. Consult those who must follow them. | Both are with their approvers. |
| Week 4 | Publish approved versions in one place, withdraw the old ones, and ask people to acknowledge them. | Acknowledgements are in the tracker. |
Four numbers to report
Report these to management quarterly.
| Number | Target |
|---|---|
| Documents past their review date | Zero policies; no document more than 30 days overdue |
| Documents in force without approval at the right level | Zero |
| Acknowledgement coverage: people in scope with a current acknowledgement | 95% or more |
| Overdue acknowledgements, named by manager | None older than 30 days |
New starters acknowledge within 10 working days, everyone again within 30 days of a material change, and everyone once a year.
Everything in the pack
| Document | What it does | Format |
|---|---|---|
| Policy Framework Standard | The rules management approves | Word |
| Policy Lifecycle Operating Procedure | A document’s path from draft to retirement | Word |
| Security Policy Document Template | A policy short enough to read and specific enough to audit | Word |
| Security Policy Hierarchy & Document Map | Which documents your profile needs | Excel |
| Policy Register & Review Schedule | Every document and when it is next reviewed | Excel |
| Policy Attestation & Acknowledgement Tracker | Who has acknowledged which version | Excel |
| Policy Coverage Gap Assessment | Topics missing, duplicated or out of date | Excel |
| Policy Development & Approval Responsibility Matrix | Who drafts, is consulted, approves and communicates | Excel |
| Policy Health & Attestation Reporting Workbook | The four numbers: what is overdue and who has not signed | Excel |
Adapting it
- Small organisation: cover the seven Core topics first. One person may own several documents, but each still needs a named owner and a review date.
- Regulated entity (NIS2, DORA): cover all 18 topics. NIS2 Article 21(2)(a) and (f) expect policies on information system security and on assessing whether your measures work. DORA Article 6(5) requires a review at least once a year and after major ICT-related incidents. Delegated Regulation (EU) 2024/1774, Article 2(2), sets what each policy contains, including its approval date and the consequences of non-compliance; the template has a place for each.
- IT run by an outside provider: the provider’s procedures can sit in your hierarchy, but the policies and their approval stay yours. Register the provider documents you rely on, and have its staff acknowledge the policies that apply to them.
Where it maps
- ISO/IEC 27001:2022 — Annex A 5.1 and Clause 7.5.
- NIST CSF 2.0 — GV.PO-01 and GV.PO-02.
- NIS2 — Article 21(2)(a) and (f).
- DORA — Article 6(5) and 9(4)(a); Delegated Regulation (EU) 2024/1774, Article 2(2).
What changed
Each change to this pack's documents since it was published, newest first.Changes across all packs
The regulated-entity tailoring sets every tier's review interval to 12 months, Standards and Procedures included, as the Policy Framework Standard and the procedure say, not only for documents that form part of the ICT risk management framework.
- Policy Register & Review Schedule 1.1 → 1.2
A procedure is approved by the Head of Information Security, with the process owner consulted, and the guide says who approves the top policy: the board or its equivalent, by how the organisation is governed, and in a NIS2 or DORA entity the management body itself, not a committee it has delegated to.
- Guide 1.0 → 1.1
The top policy is approved by the board or its equivalent, and in a NIS2 or DORA entity by the management body itself.
- Policy Framework Standard 1.0 → 1.1
- Policy Lifecycle Operating Procedure 1.0 → 1.1
A policy is approved by executive management, and the top policy by the board or its equivalent, and in a NIS2 or DORA entity by the management body itself.
- Security Policy Document Template 1.0 → 1.1
The top policy is approved by the board or its equivalent, and by the management body itself in a regulated entity; other policies by the Policy tier's approver, not by a delegate the management body names.
- Security Policy Hierarchy & Document Map 1.0 → 1.1
The Policy tier's approver reads Executive management; who approves the top policy is set in the Policy Framework Standard.
- Policy Register & Review Schedule 1.0 → 1.1
- Policy Health & Attestation Reporting Workbook 1.0 → 1.1
The Policy tier's approver reads executive management; who approves the top policy is set in the Policy Framework Standard.
- Policy Coverage Gap Assessment 1.0 → 1.1
The Policy approval row names the board or its equivalent, by structure, as the approver of the top policy.
Published. The guide and nine documents, at 1.0.