ISO 27001 Information Security Policy Template: What Clause 5.2 Requires, the Topic-Specific Policies A.5.1 Expects, and What NIS2 Adds

An ISO 27001 information security policy has to do seven things, and only four of them are about what it says. Clause 5.2 of ISO/IEC 27001:2022 sets four content requirements (fit the organisation’s purpose, include objectives or a framework for them, commit to applicable requirements, commit to continual improvement) and three handling requirements (documented, communicated internally, available to interested parties as appropriate). Annex A control A.5.1 then turns the single policy into a set: a top-level policy plus topic-specific policies, each approved, published, communicated, acknowledged and reviewed.

If your organisation also falls under NIS2, there is a third layer: the implementing regulation for digital-infrastructure and digital-provider entities lists eleven elements for the top-level policy, several of which a policy written to the ISO minimum will not contain.

What Clause 5.2 Requires From the Policy Itself

In plain terms: top management writes a short policy that fits the business, states or frames security objectives, and commits to two things: meeting the requirements that apply to you and improving the ISMS. Then the policy has to exist as a controlled document that people actually receive.

The wording below follows the clause as quoted by High Table’s clause 5.2 guide. The standard itself is copyrighted, so buy a copy from ISO or your national standards body before you rely on any paraphrase.

Clause 5.2 requirement	What to write in your template
Appropriate to the purpose of the organisation	Two or three sentences on what the business does, what information it holds and why security matters to that business. Generic text copied from a template fails this test.
Includes information security objectives, or provides the framework for setting them	Either the objectives themselves or a statement of how, when and by whom they are set and reviewed
Commitment to satisfy applicable requirements related to information security	One commitment sentence, plus a pointer to a separate register of legal, regulatory and contractual requirements
Commitment to continual improvement of the ISMS	One commitment sentence naming the mechanisms (internal audit, management review, corrective action)
Available as documented information	Document control block: owner, version, approval date, next review, classification
Communicated within the organisation	A distribution statement: who receives it and how
Available to interested parties, as appropriate	A note on which version external parties receive (URM notes some organisations publish a sanitised version)

Two of these choices shape everything else. First, the objectives line: High Table recommends putting the actual objectives into the headline policy rather than only a framework, so staff hear policy and objectives in one communication. That works if your objectives are stable; if they change yearly, the framework option avoids a re-approval each time. Second, the requirements commitment: High Table advises pointing to a separate legal, regulatory and contractual register instead of listing laws inside the policy. That keeps the policy short. URM Consulting recommends a high-level policy “no longer than a couple of pages”, written so it rarely needs changing.

What A.5.1 Adds: A Policy Set, Not a Policy

In plain terms: clause 5.2 asks for one policy. Annex A control A.5.1 asks for that policy plus narrower policies on specific topics, and adds a step clause 5.2 does not mention: people have to acknowledge them.

URM quotes the control’s opening words, “Information security policy and topic specific policies shall be defined.” The rest of the control, as TCSA’s control summary paraphrases it, requires each policy to be approved by management, published, communicated to and acknowledged by the personnel and interested parties it applies to, and revisited at planned intervals and after significant changes. ISMS.online notes that the 2022 control merges two 2013 controls, 5.1.1 (policies) and 5.1.2 (review of policies), into one.

What is a topic-specific policy? ENISA’s NIS2 implementation guidance quotes the ISO/IEC 27002:2022 definition: “intentions and direction on a specific subject or topic, as formally expressed by the appropriate level of management.” The last phrase matters: a topic-specific policy does not need board sign-off. URM describes the common pattern: the IT director owns and approves the cryptography policy, the HR director the HR security policy. Keep detail out of the top-level document: URM points out that if the main policy carries detail from the supporting policies, every change to that detail needs CEO approval.

Acknowledgement is easy to miss. High Table lists the accepted forms of evidence as email confirmations, signed forms and sign-offs in a learning management system, and names new joiners who never acknowledged anything as a common failure. Build the acknowledgement into onboarding before system access, not into an annual campaign that misses everyone hired in between.

Which Topic-Specific Policies to Write

In plain terms: ISO leaves the list to your risk assessment. If you are in scope of Implementing Regulation 2024/2690, ENISA lists ten that are mandatory, and most have a close ISO anchor you can reuse.

A.5.1 names no topic-specific policies. Your Statement of Applicability and risk treatment decide which ones you need. NIS2 entities get a firmer answer. ENISA’s Technical Implementation Guidance (v1.0, June 2025) lists ten topic-specific, documented policies that the implementing regulation requires, and states that “Documenting the aforementioned topic-specific policies is mandatory.” The table maps each to the nearest ISO/IEC 27001:2022 reference; control numbers follow CertPro’s Annex A list.

Topic-specific policy (ENISA list)	CIR 2024/2690 Annex point	Nearest ISO 27001:2022 anchor	Fit
Risk management policy	2	Clause 6.1 (risk assessment and treatment; see TCSA’s clause index)	Close, but sits in the main clauses, not Annex A
Incident handling policy	3.1.1	A.5.24 Incident management planning and preparation	Close
Supply chain security policy	5.1.1	A.5.19 Information security in supplier relationships	Close
Security testing policy	6.5.1	A.8.29 Security testing in development and acceptance	Partial: A.8.29 covers development and acceptance only
Policy to assess the effectiveness of risk-management measures	7.1	Clause 9.1 monitoring, measurement, analysis and evaluation; A.5.36 compliance with policies	Partial: ISO has no single control for it
Cryptography policy	9.1	A.8.24 Use of cryptography	Close
Access control policy	11.1.1	A.5.15 Access control	Close
Privileged and system administration accounts	11.3	A.8.2 Privileged access rights	Close
Handling of information and assets	12.2.1	A.5.10 Acceptable use; A.5.12 Classification	Close
Removable media policy	12.3.1	A.7.10 Storage media	Close

The “Fit” column is our reading, not ENISA’s. ENISA says its own standards mapping “should not be interpreted as a measure of equivalency,” so treat any ISO-to-NIS2 match as a starting point for a gap check, not as proof of coverage. ENISA also leaves the format to you: separate documents, updates to existing policies, or a single comprehensive document all count. For deeper templates on two of these, see our ISO 27001 access control policy template and the ISO 27001 supplier security policy template.

Outside ENISA’s list, network security (A.8.20) and backup (A.8.13) policies are worth considering. Let your risk treatment plan decide: every extra policy is one more annual review.

The NIS2 Overlay: Eleven Elements Instead of Four

In plain terms: if the implementing regulation applies to you, your top-level policy needs more content than ISO asks for. Most of the additions are lists and dates rather than new commitments.

NIS2 Article 21(2)(a) requires “policies on risk analysis and information system security” (Directive (EU) 2022/2555, Article 21). For entities within the scope of Commission Implementing Regulation (EU) 2024/2690 (DNS service providers, TLD name registries, cloud, data centre and content delivery network providers, managed and managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers), point 1.1.1 of its Annex spells out what that policy “shall” contain. Other NIS2 entities follow their national transposition law; if yours sets no content list for the policy, this one is a sensible benchmark. Here is how a policy written only to clause 5.2 and A.5.1 compares:

CIR Annex 1.1.1 element	Covered by 5.2 / A.5.1?	What to add	Effort
(a) Set out the approach to managing security	Yes, in substance	Nothing, if your policy describes the ISMS approach	Low
(b) Appropriate to and complementary with business strategy and objectives	Mostly: 5.2 says “purpose”	One sentence tying security to strategy	Low
(c) Set out security objectives	Partial: 5.2 accepts a framework instead	The objectives themselves	Medium
(d) Commitment to continual improvement	Yes	Nothing	Low
(e) Commitment to provide resources: staff, financial resources, processes, tools and technologies	No: not among the 5.2 requirements	A resourcing commitment sentence	Low
(f) Communicated to and acknowledged by relevant employees and relevant interested external parties	Yes, through A.5.1	Extend acknowledgement to relevant external parties	Medium
(g) Roles and responsibilities	No: not among the 5.2 requirements	A roles section or a referenced RACI	Medium
(h) List of documentation to keep and retention periods	No	A documentation and retention table	Medium
(i) List of topic-specific policies	No: A.5.1 requires them but not a list	The register of topic-specific policies	Low
(j) Indicators and measures, plus current maturity level	No	A metrics table and a maturity statement	High
(k) Date of formal approval by the management bodies	Partial: A.5.1 requires approval, not a date in the text	Approval date in the document control block	Low

Point 1.1.2 adds a review rule: the management bodies review the policy “at least annually” and when significant incidents or changes occur, and “the result of the reviews shall be documented.” A.5.1 asks for review at planned intervals and after significant changes, without a fixed frequency. Write “at least annually” into a dual-use template and the review frequency satisfies both regimes.

The gap also runs the other way: Annex 1.1.1 has no counterpart to ISO’s commitment to satisfy applicable requirements, so a policy copied from a NIS2 template can miss an ISO requirement. And one approval rule is softer than it looks: the rule that topic-specific policies are approved by “an appropriate level of management” sits in the regulation’s Recital 9, which is non-binding. ENISA repeats it as guidance and asks for a record of each approval. Delegating that approval is a documented choice you can justify, not an obligation.

A Template Skeleton That Satisfies Both

In plain terms: nine short sections. The bracketed references show which requirement each section answers, so you can remove the NIS2 rows if they do not apply.

1. Document control: owner, version, classification, approval date by top management or the management bodies, next review date. [5.2 documented information; CIR 1.1.1(k)]
2. Purpose and context: what the organisation does and how security supports its strategy. [5.2 purpose; CIR 1.1.1(a), (b)]
3. Scope: a pointer to the ISMS scope statement rather than a repeat of it. See our ISMS scope statement guide.
4. Objectives: the objectives, or the framework for setting them if you are ISO-only. [5.2 objectives; CIR 1.1.1(c)]
5. Commitments: applicable requirements (pointing to the legal and contractual register), continual improvement, resources. [5.2 commitments; CIR 1.1.1(d), (e)]
6. Roles and responsibilities: top management, ISMS lead, topic-policy owners, all staff. [CIR 1.1.1(g)]
7. Policy framework: the register of topic-specific policies, each with owner and approver. [A.5.1; CIR 1.1.1(i)]
8. Documentation and measurement: records to keep with retention periods, and the indicators used to track the policy. [CIR 1.1.1(h), (j)]
9. Communication, acknowledgement, exceptions and review: who receives which version, how they acknowledge it, how exceptions are approved, and review “at least annually” and after significant change. [5.2 communication; A.5.1; CIR 1.1.1(f), 1.1.2]

Sections 1 to 5 and 9 fit on two pages; sections 6 to 8 work as appendix tables, so the topic-policy register can change without reworking the commitments.

Who Owns What

Role	Owns	Key decision
Board / top management	Top-level policy approval, objectives, resourcing commitment	Approving the policy and its review results
CISO / ISMS lead	Drafting, document control, topic-policy register, metrics	Which topic-specific policies the risk treatment requires
Department heads	Their topic-specific policies (cryptography, HR security, suppliers)	Approving their topic policy and its updates
Compliance officer / legal	The applicable-requirements register, NIS2 delta, external versions	What external parties may see
HR	Acknowledgement at onboarding, contract clauses	No system access before acknowledgement

For SME owners: one person may hold three of these roles. That is fine. What matters is that the board-level approval and the topic-policy approvals are recorded separately, with dates. For CISOs: resist merging the topic-specific policies into one large document to save effort. High Table counts the single giant policy among the common mistakes, because it can hinder people from reading it. For a broader view of the certification path, see our ISO 27001 compliance guide.

The Evidence an Auditor Samples

In plain terms: a policy nobody approved or received fails clause 5.2 however well written, and one nobody acknowledged invites an A.5.1 finding.

• Approved policy with version, date and named approver. TCSA’s clause 5.2 evidence list accepts a board minute, signed copy or e-signature trail as approval evidence.
• Review history showing revisions at planned intervals and after significant changes. High Table lists a review and approval within the last 12 months among the things auditors check.
• Communication evidence: distribution emails, intranet notices, induction records.
• Acknowledgement records: for NIS2, ENISA describes acknowledgement “typically through a signed document or digital acknowledgement” and says it may be built into employment or service contracts. Relevant external parties may receive an extract or summary relevant to their role.
• The register the requirements commitment points to, and the objectives record under clause 6.2.
• Staff awareness: TCSA notes that auditors interview randomly selected employees on whether they know the policy exists and where to find it.

The Statement of Applicability then ties A.5.1 to the rest of Annex A. Our Statement of Applicability template guide covers how auditors read it.

Frequently Asked Questions

Is the information security policy mandatory in ISO 27001?

Yes. Clause 5.2 says top management “shall establish” it, and the policy must be available as documented information. Without it, an ISMS cannot meet the clause.

Are topic-specific policies mandatory?

A.5.1 requires them to be defined, and URM quotes the control as “shall be defined.” A.5.1 itself names no topics, so which ones you cover is your decision. Advisers disagree on how strict this is: Advisera calls topic-specific policies “not mandatory documents but… recommended for all companies,” so check with your certification body. For entities under Implementing Regulation 2024/2690, ENISA calls ten specific topic policies mandatory.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• High Table, “ISO 27001:2022 Clause 5.2 Policy Explained” (linked above)
• High Table, “ISO 27001:2022 Annex A 5.1 Policies for Information Security Explained”
• URM Consulting, “Developing an ISO 27001 Information Security Policy”, 5 November 2024 (linked above)
• ISMS.online, “ISO 27001:2022 Annex A 5.1 – Information Security Policies” (linked above)
• TCSA, “Clause 5.2 Information security policy” and “5.1 Policies for information security” (linked above)
• Commission Implementing Regulation (EU) 2024/2690, Recital 9 and Annex points 1.1.1–1.1.2 (linked above)
• ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 (linked above)
• Directive (EU) 2022/2555 (NIS2), Article 21 (linked above)
• CertPro, “ISO 27001 Controls List: All 93 Annex A Controls Explained” (linked above)
• TCSA, ISO 27001 clause index (linked above)
• Advisera, “ISO 27001 control 5.1 Policies for information security” (linked above)