How do we…
How do we decide which policies we actually need, for our size and regulation?
Add to board memoOpen the memo
The short answer
- Recommendation
- Pick your profile first: Core for every organisation, Growing above about 50 people, Regulated for an NIS2 or DORA entity. Then name the document that covers each required topic today, check each one, and write the missing Core topics first.
- Reasoning
- Size decides how much there is to govern, and regulation adds the topics regulators expect to see documented: continuity, risk management and effectiveness assessment. Not every topic needs its own policy. Some are best covered by a standard or a procedure, and several topics can share one short document. What matters is that each topic is covered once, at the right tier, by an approved and current document. A topic with no document has no rule at all, so missing topics come before documents that need work.
- Considerations
- The three profiles, the topic list, the threshold of about 50 people and the 95% acknowledgement target are the defaults in the CISO Times policy pack. Your regulator, contracts or certification scope may require more.
- If you have not confirmed whether you are an NIS2 or DORA entity, plan for the Regulated set. In a regulated entity the management body itself approves the top policy, and the pack sets every tier's review to 12 months, as DORA requires the ICT risk framework to be reviewed yearly.
- A provider's document can cover an operational topic, such as backup or patching, only if the contract makes it binding and you can see it. Ownership of the topic stays with you: a provider can run a standard but cannot own your policy.
- Covered means a document is well governed. It says nothing about whether it is well written or followed. Test what it says, and check through audit that people follow it.
The decision, step by step
Select any step for the reasoning behind it and where the pack covers it.
- Start
- Step
- Decision
- Outcome
Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.
Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.
Read as text
The same flow written out: each step, its reasoning and where the pack covers it. 17 steps.
Start
You need to decide which policies to have
The answer depends on two things: your size and whether you are regulated. Size decides how much there is to govern. Regulation adds topics regulators expect to see documented: continuity, risk management and effectiveness assessment.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapChoose Your Profile
Decision
Are you an NIS2 or DORA entity?
That means an essential or important entity under NIS2, or a financial entity under DORA. If you have not yet confirmed your status, plan for the Regulated set until you have. Removing a topic you turn out not to need is a smaller problem than a legal obligation with no document behind it.
- Yes, or not known: Regulated: 18 topics
- No: Do you have more than about 50 people?
In the pack
- P04-A05 Security Policy Hierarchy & Document MapChoose Your Profile
- P04-A05 Security Policy Hierarchy & Document MapDefinitions
Decision
Do you have more than about 50 people?
The threshold is the pack's default, and a rough one. The Growing topics are needed once hiring, suppliers, devices and systems are too many to handle case by case.
- Yes: Growing: 15 topics
- No: Core: 7 topics
In the pack
- P04-A05 Security Policy Hierarchy & Document MapChoose Your Profile
Step
Regulated: 18 topics
The Growing set, plus three: business continuity and ICT resilience, and information security risk management, both as policies; and a procedure for assessing whether security measures are effective. The pack says the management body itself approves the top policy in a regulated entity: the board, or the management board in a two-tier structure. Under DORA, your document map, kept current, can serve as the list of documentation to be maintained.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapDocument Map
- P04-A05 Security Policy Hierarchy & Document MapInstructions
- P04-A02 Policy Framework StandardRegulated entity (NIS2 or DORA)
Step
Growing: 15 topics
The Core set, plus supplier security and people security as policies, and six standards: remote working and mobile devices, cryptography, logging and monitoring, secure development and change, physical security, and security exceptions.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapDocument Map
Step
Core: 7 topics
Five policies: the top information security policy, acceptable use, access control, asset management and classification, and incident management. Two standards: backup and recovery, and vulnerability and patch management. This is the minimum for every organisation, including a small one whose IT is run by a provider.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapChoose Your Profile
- P04-A02 Policy Framework StandardSmall organisation
Decision
Do you develop or change software in-house?
Anyone who builds or changes software needs rules for it, including a small development team. The Growing and Regulated sets already include this topic.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapInstructions
Step
Add a secure development and change standard
It covers security in the development life cycle, testing, separation of environments and changes to live systems. The pack recommends a standard for it, so the Core set becomes eight topics.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapDocument Map
Step
Name the document that covers each topic today
Use your document register, not memory. One document may cover several topics, and one topic may need two documents. A blank is a gap. Where a provider's document covers an operational topic, record it, check the contract makes it binding, and keep ownership of the topic in-house: a provider can run a standard but cannot own your policy.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapDocument Map
- P04-A05 Security Policy Hierarchy & Document MapInstructions
Decision
Does any topic not fit your organisation?
A profile is a starting point. Some topics may not apply, and you may need one the profile leaves out. Either way, the decision is yours to record.
- Yes: Exclude or add it, with a reason an auditor accepts
- No: Check each required topic with five questions
In the pack
- P04-A05 Security Policy Hierarchy & Document MapInstructions
Step
Exclude or add it, with a reason an auditor accepts
For example, "no premises: all staff remote, no equipment rooms" is a reason to drop physical security. Write the reason next to the topic. An exclusion with no reason reads as a gap.
In the pack
- P04-A05 Security Policy Hierarchy & Document MapInstructions
Step
Check each required topic with five questions
Does a document exist? Is it approved at the right tier? Is it within its review date? For a policy, have at least 95% of the people it applies to acknowledged it (the pack's default)? Does another document cover the same ground? Answer from the register, approval records and acknowledgement figures.
In the pack
- P04-A08 Policy Coverage Gap AssessmentInstructions
- P04-A08 Policy Coverage Gap AssessmentAssessment
Decision
What does the check find for the topic?
Missing means nothing written covers it. Duplicated means two documents could give people different rules. Needs work means a document covers only part of the topic, or fails a check. Covered means it passes all five.
- Missing: Write it: missing Core topics first
- Duplicated: Merge the overlap into one document
- Needs work: Fix the check it fails, after missing topics
- Covered: Covered: keep it on its review cycle
In the pack
- P04-A08 Policy Coverage Gap AssessmentResults by Topic
Outcome
Write it: missing Core topics first
A topic with no document has no rule at all, so it comes first: Core topics, then Regulated ones (a legal obligation for regulated entities), then Growing ones. Draft it at the recommended tier, have it approved at that tier's level, and add it to your register.
In the pack
- P04-A08 Policy Coverage Gap AssessmentSummary & Actions
- P04-A03 Policy Lifecycle Operating ProcedureStage 1 — Identify the need
Outcome
Merge the overlap into one document
Fix duplication first for that topic, even if other checks fail. Merge the overlapping documents, retire the other one and correct the register. For example, a business continuity policy and a separate IT disaster recovery policy covering the same ground. Duplicated topics are taken after the missing ones, in the order Core, Regulated, Growing.
In the pack
- P04-A08 Policy Coverage Gap AssessmentResults by Topic
- P04-A08 Policy Coverage Gap AssessmentInstructions
Outcome
Fix the check it fails, after missing topics
Extend a partial document, re-issue it at the right tier, review it, or collect acknowledgements, depending on what failed. Take these after the missing topics, in the same order: Core, Regulated, Growing. For example, a procedure standing in for a policy.
In the pack
- P04-A08 Policy Coverage Gap AssessmentSummary & Actions
Outcome
Covered: keep it on its review cycle
Covered means the document is well governed. It says nothing about whether it is well written. Test what the document says against a good policy structure, and check through audit whether it is followed. Repeat this assessment at least once a year and after any review trigger.
In the pack
- P04-A08 Policy Coverage Gap AssessmentInstructions
- P04-A02 Policy Framework StandardReview (rule PF-06)
Practical checklist
- Decide whether you are an NIS2 or DORA entity, and plan for the Regulated set if you do not know yet. If you are not, choose Growing above about 50 people, or Core.
- Add a secure development and change standard if you develop or change software in-house, whatever your profile.
- From your register, name the document that covers each required topic today. A blank is a gap.
- Exclude any topic that does not fit, or add one the profile leaves out, with a reason an auditor would accept.
- For each required topic, check from the evidence that a document exists, is approved at the right tier and in date, is acknowledged by at least 95% of people in scope if a policy, and is not duplicated.
- Write the missing topics first: Core, then Regulated, then Growing. Draft each at the recommended tier, have it approved at that tier's level and add it to your register.
- Then merge duplicated documents and fix those that need work, in the same order.
- Repeat the assessment at least once a year and after any review trigger.
Evidence to have ready
- Your document map: each required topic, the document that covers it, and the reason for any exclusion or changed tier.
- The assessment results by topic, with the evidence behind each answer: the register, the approval records, the review dates and the acknowledgement figures.
- Your action plan, missing topics first, and the register entries for the documents written, merged or retired.
- For any topic a provider covers, the contract that makes the provider's document binding.
Assumptions
- The profiles, the topic list and the size threshold of about 50 people are the defaults in the CISO Times policy pack. Your own regulator, contracts or certification scope may require more.
- This decides which documents should exist and whether they are governed. It does not judge whether what they say is good, or whether people follow them.
Not covered here
- Which tier a requirement belongs in. That is “How do we separate what belongs in a policy, a standard and a procedure?”.
- Whose policies apply when a provider runs your IT. That is “If our IT is run by a service provider, whose policies apply?”.
- What else changes for an NIS2 or DORA entity. That is “If we are a NIS2 or DORA entity, what changes in how policies are governed?”.
- How to catch up when many documents are past their review date. That is “If half of our policies are past their review date, then how do we recover?”.
Related questions
- How do we separate what belongs in a policy, a standard and a procedure?
- How do we write a policy statement that an auditor can test?
- If half of our policies are past their review date, then how do we recover?
- If our IT is run by a service provider, whose policies apply?
- If we are a NIS2 or DORA entity, what changes in how policies are governed?