Information security policy template for NIS2 and ISO 27001
You can have an information security policy template in about ninety seconds. SANS gives one away, so does CIS, so do a dozen consultancies who would rather sell you the software underneath it. The document is not scarce and it has not been scarce for fifteen years.
So it is worth asking why organisations still fail audits on it.
They fail because the template is the easy part. What ISO 27001 and NIS2 both actually require is not a text — it is an act. Somebody with authority has to approve this document, on a date, on the record, and then review it when things change. A downloaded policy with your logo at the top and no approval behind it satisfies neither regime, and an auditor establishes that in about two minutes by asking who signed it.
This article covers what belongs in the top-level policy, what belongs in the layer beneath it, and what the approval and review record has to look like.
If you want the written set rather than the explanation, the ISO 27001 Total Kit includes the top-level policy and the topic-specific policies beneath it, with the approval and review records already structured. €590 excl. VAT.
What each regime asks for
The two requirements are close enough to satisfy with one document set, and different enough that it is worth reading both.
ISO 27001 clause 5.2 puts the obligation on top management directly: they establish a policy appropriate to the organisation’s purpose, containing security objectives or a framework for setting them, a commitment to satisfy applicable requirements, and a commitment to continual improvement. It must exist as documented information, be communicated within the organisation, and be available to interested parties where appropriate.
Annex A control A.5.1 then adds the operational half. The information security policy and its topic-specific policies must be defined, approved by management, published, communicated to and acknowledged by relevant personnel and interested parties, and reviewed at planned intervals and whenever significant changes occur.
NIS2 arrives at the same place from the legal side. Article 21(2)(a) requires policies on risk analysis and information system security. For the entities covered by Commission Implementing Regulation (EU) 2024/2690, the first section of its Annex is more specific: the policy sets out the approach to managing network and information system security, is approved by the management bodies, assigns roles and responsibilities, is based on the results of the risk assessment, is communicated, and is reviewed at planned intervals and after significant incidents or significant changes.
Read those three together and the shape of the obligation is unambiguous. Four verbs recur: approve, communicate, review, and base on risk. None of them is a writing task.
One policy, then many
The top-level policy is one of a short list of items ISO 27001 names explicitly. Before writing the rest of the set, it is worth knowing which documents and records the clauses actually require — the published lists disagree with each other, and most are longer than the standard is.
The most common structural mistake is a single document trying to be everything — forty pages covering password length, backup retention, joiner-mover-leaver, acceptable use and incident escalation, all in one file, approved by the board once and then untouchable.
Both regimes expect two levels, and A.5.1 says so explicitly by naming topic-specific policies alongside the main one.
The top-level policy is short, stable and strategic. It says what the organisation commits to, who is accountable, and how the rest hangs together. Two to four pages. It changes rarely — which matters, because every change means going back to the management body for approval.
Beneath it sit the topic-specific policies: access control, cryptography, supplier security, acceptable use, secure development, backup, incident management, and so on. These are approved at a lower level, change more often, and reference the top-level policy as their authority.
The practical benefit is that you stop needing board approval to change a password rule. The compliance benefit is that the top-level policy stays readable, which is the only condition under which anybody reads it.
What belongs in the top-level policy
| Include | Why |
|---|---|
| Purpose and scope | Which entity, which activities, which locations — must match the ISMS scope and, for NIS2, the regulated entity |
| Commitment statement | Satisfy applicable requirements, and continually improve — clause 5.2 asks for both in words |
| Security objectives or the framework for setting them | Either the objectives themselves, or where they are set and reviewed |
| Roles and responsibilities | Who is accountable overall, and who owns the topic-specific policies. Required explicitly by the CIR Annex |
| Reference to risk management | The policy rests on the risk assessment, not on a template’s assumptions |
| The map of topic-specific policies | One list, so the reader can find the layer beneath |
| Consequences of non-compliance | Vague here is fine, but it has to be said |
| Approval, version, review date | See the next section — this is the part that fails |
And the things that do not belong: technical parameters, product names, IP ranges, retention periods in days, specific tools. Not because they are unimportant, but because each of them will change within a year, and each change would drag a board-approved document back through approval. Put them in the topic-specific policies or the procedures.
The test is simple. If a detail would change when you swap a vendor, it does not go in the top-level policy.
The approval record is the document
This is where downloaded templates fail, and it is worth being blunt about it: an unapproved policy is not a policy. It is a draft with a logo.
What the evidence needs to show is who approved it, when, and with what authority. For ISO 27001 that means management approval visible in the document control block and traceable to a record — minutes, a signed approval page, a workflow entry in your document system. For NIS2 the bar is higher and more specific, because Article 20 makes the management body itself accountable and the CIR Annex requires the policy to be approved by the management bodies, not delegated to the security function.
Three failures recur.
The policy approved by the person who wrote it. The CISO drafted it and the CISO signed it. Under ISO 27001 this is arguable if the CISO holds delegated authority and it is documented. Under NIS2 it is not, because the directive puts the duty on the management body specifically.
The approval with no date, or with a date that predates the content. A version 3.0 approved on a date earlier than the change log entry for version 3.0 is a finding, and it is the kind an auditor spots while skimming.
The approval that exists only in the document. The policy says “approved by the Board” but there are no minutes, no agenda item, nothing outside the file asserting it. The document cannot be the only evidence of its own approval.
Fixing this costs one agenda item and one set of minutes. It is the cheapest gap in the whole compliance set, and the most frequently open.
Review has two triggers, not one
Almost every policy template carries a line saying it will be reviewed annually. That satisfies half the requirement.
Both A.5.1 and the CIR Annex require review at planned intervals and when significant changes occur. The CIR adds significant incidents explicitly. So the review clause needs both limbs, and the event-driven one needs to name what counts: a significant incident, a material change to the risk assessment, a change of scope, a new regulatory obligation, a substantial change in the technology estate or the supplier base.
Then the review has to leave a trace even when nothing changes. A review that concludes the policy is still fit for purpose is a valid outcome — but only if it is recorded. “We reviewed it and made no changes” with no dated record is indistinguishable from not having reviewed it.
Communication and acknowledgement
A.5.1 asks for the policy to be published, communicated, and acknowledged by relevant personnel and relevant interested parties. Clause 5.2 asks for it to be available to interested parties as appropriate.
Acknowledgement is the operative word and the one most often skipped. An intranet page nobody has opened is publication without acknowledgement. What auditors look for is a record per person: read and accepted, on a date, ideally at onboarding and again when the policy changes materially.
An LMS or HR system does this well. A spreadsheet does it adequately. Nothing does it badly, and nothing is common.
For NIS2 there is a second audience worth remembering: relevant interested parties can include suppliers and customers who need to know your security commitments. That does not mean publishing the whole set — it means deciding, deliberately, what is external and recording that decision.
If you do use a free template
There is nothing wrong with starting from a downloaded document. There is something wrong with shipping it unchanged. Five checks before it becomes yours.
- Does the scope statement describe your organisation, or a generic one? Templates default to a fictional company with offices, servers and a security team. Replace it with what you actually operate.
- Do the roles named exist? A template naming a Chief Information Security Officer, a Data Protection Officer and a Security Steering Committee in a company of thirty people creates obligations you will fail. Name the roles you have.
- Is there a topic-specific layer, or does the template try to do everything? If it covers passwords and backups in the same file as governance commitments, split it.
- Does the review clause have both triggers? Most templates have only the annual one.
- Is there an approval block, and can you actually get it approved by the right body? This is the one that takes calendar time — start it before the rest.
The honest summary is that a free template saves you the drafting and none of the work that matters.
If you also need to work out which obligations apply to you in the first place, who must comply with NIS-2 covers the scope tests, and the four gaps an ISMS leaves open covers what ISO 27001 does not reach.
Frequently asked questions
Is an information security policy mandatory? Yes, under both. ISO 27001 clause 5.2 requires it as documented information and A.5.1 sets out how it must be handled. NIS2 Article 21(2)(a) requires policies on risk analysis and information system security, and the implementing regulation makes the content requirements explicit for the entities it covers.
How long should it be? The top-level policy: two to four pages. Longer than that and it has absorbed content that belongs in the topic-specific layer. The full policy set will be much longer, which is fine — it is the top-level document that needs to stay readable.
Who has to approve it? Management, under ISO 27001. The management body specifically, under NIS2 — Article 20 places the duty on them and the implementing regulation repeats it for the policy itself. If you are subject to both, approve at the higher bar.
Can one policy cover both NIS2 and ISO 27001? Yes, and it should. The requirements overlap almost entirely at this level. Where NIS2 adds specificity — approval by the management body, review after significant incidents, explicit assignment of roles — write to the stricter requirement and you satisfy both.
How often must it be reviewed? At planned intervals that you define, and additionally whenever significant changes or significant incidents occur. Annual is the common planned interval, and it is not sufficient on its own.
Does every employee have to sign it? The standard asks for acknowledgement by relevant personnel. In practice that means everyone with access to information within scope, recorded per person, with a repeat after material changes.
Where to go from here
The policy commits you; the record of which Annex A controls apply shows which controls follow from that commitment, and the documentation set as a whole is where both live.
Most of the work in this document is not writing. It is getting the right people to approve it, recording that they did, and building the habit of reviewing it when something moves. That is unglamorous and it is exactly what gets checked.
The ISO 27001 Total Kit includes the top-level policy and the topic-specific policies beneath it, with approval blocks, review triggers and the acknowledgement record already structured — one policy per process rather than a folder of overlapping files. €590 excl. VAT.
If your driver is NIS2 rather than certification, the NIS-2 Compliance Suite covers the same policy layer mapped to the thirteen sections of the implementing regulation’s Annex, with the management body approval record built in. €590 excl. VAT.
Sources
- ISO/IEC 27001:2022, clause 5.2 and Annex A control A.5.1
- ISO/IEC 27002:2022 for guidance on A.5.1
- Directive (EU) 2022/2555 (NIS2), Articles 20 and 21(2)(a)
- Commission Implementing Regulation (EU) 2024/2690, Annex section 1