ISO 27001 Information Security Policy Template 2026

The information security policy is the framework document of the Information Security Management System (ISMS) under ISO 27001:2022. It is the document that top management approves to formally declare how the organization understands, governs and prioritizes information security. Without a policy approved by top management, certification is not possible: clause 5.2 of the standard explicitly requires it, and any certification auditor will ask to see the document, evidence of its approval and evidence of its communication before even reviewing technical controls. This guide provides a practical narrative template, a section-by-section checklist and realistic adaptation guidance for organizations preparing to implement or renew their ISMS in 2026.

Bottom line: the ISO 27001 security policy is a short document (between 6 and 12 pages), approved by top management, that defines purpose, scope, objectives, roles, regulatory framework, risk management, compliance and review. It is not a technical manual nor a compendium of procedures. Its function is to govern, not to implement. Specific policies (access, cryptography, BYOD, backup, continuity) and operational procedures hang from it. A well designed policy stays stable for 2 to 4 years; specific policies and procedures change far more frequently.

What the ISO 27001 security policy is and why it matters

The ISO 27001:2022 standard clearly distinguishes between framework policy and specific policies. The framework policy, simply called Information Security Policy in the standard, is the top level governance document. Specific policies (logical access control, physical access control, cryptography, BYOD, backup, incident management, business continuity, supplier security, secure development, clean desk, classification and retention of information) are operational documents that develop concrete areas of Annex A.

Clause 5.2 Policy of ISO 27001:2022 establishes that top management shall establish an information security policy that is appropriate to the purpose of the organization, includes information security objectives or a framework for setting them, includes a commitment to satisfy applicable requirements and includes a commitment to continual improvement of the ISMS. Additionally, it must be documented, communicated within the organization and available to interested parties as appropriate.

That last obligation is where organizations often stumble during audit: having the policy approved is not enough. The organization must demonstrate that staff knows it, that signed acknowledgement exists and that the policy is incorporated into onboarding. An experienced auditor will ask for communication records, not just the signed PDF.

Mandatory sections of the framework policy

Purpose and scope

The purpose declares why the policy exists: to protect the confidentiality, integrity and availability of information, to comply with legal and contractual requirements, and to support business objectives. The scope defines which parts of the organization, which assets, which locations, which processes and which units are within the ISMS. Scope must match exactly the certifiable scope defined in the ISMS Manual or in the scope document. If the policy says one thing and the certificate says another, the auditor will record a major nonconformity. Practical recommendation: draft the scope once and reuse it literally across policy, manual and Statement of Applicability.

Security objectives aligned with the business

Objectives must be measurable, achievable and traceable. Valid examples: reduce mean time to detect incidents below an agreed threshold; maintain a minimum availability of the critical service expressed as annual percentage; achieve a yearly percentage of staff training coverage; close internal audit nonconformities within a defined timeframe. Each objective must be measurable through KPIs that appear in the ISMS dashboard and must be reviewed by the Security Committee. Vague objectives such as "ensure information security" are rejected by auditors because they are not measurable.

Top management commitment

This section demonstrates the leadership required by clause 5.1. It must unequivocally express that top management assumes responsibility, allocates sufficient resources, requires all personnel to comply with the policy and promotes continual improvement. A generic sentence is not enough: auditors look for active language and explicit commitment. It is common to include here the commitment to review the ISMS at least once a year through Management Committee and to treat security as a first level corporate risk.

Roles and responsibilities

The policy names the actors responsible for security: CISO or information security officer, CIO or IT officer, DPO when GDPR applies, business owners or asset owners, Security Committee and top management. Roles are named by function, not by individual person; specific names go in an annex or in a separate document updated more frequently. For each role, the responsibility is briefly described: the CISO governs the ISMS, the CIO operates the infrastructure, asset owners classify information and authorize access, the Security Committee decides on residual risks and approves exceptions.

Applicable regulatory framework

Section that cites the standards and regulations to which the organization is subject: GDPR always; NIS2 as transposed nationally when the organization is an essential or important entity; national public sector security frameworks when providing services to the public sector; DORA if it is a financial entity or a critical ICT provider to one; PCI DSS if processing card data; sector specific regulations (healthcare, eIDAS, MiCA as applicable). The listing does not need to be exhaustive at article level; naming the regulations and declaring the commitment to comply is enough.

Risk management

The policy declares that the organization manages security under a risk based approach, in accordance with ISO 27001 clauses 6.1 and 8.2-8.3. The methodology used by the organization is cited here, typically MAGERIT v3 or ISO 27005, with risk acceptance, evaluation and treatment criteria. The policy does not go into technical detail; detail lives in the risk analysis methodology. What must be in the policy is the commitment to review the risk analysis at least once a year or when material changes occur in scope, assets or context.

Compliance and internal sanctions

Declares that noncompliance with the policy will have proportionate disciplinary consequences, in accordance with applicable labor regulations and collective agreements. There is no need to detail sanction typologies: a reference to the internal disciplinary procedure and labor legislation is enough. This section serves as evidence that security is not optional. Without this clause, Works Councils and Human Resources managers may have difficulty applying corrective measures.

Review and update

The policy is formally reviewed at least once a year, and extraordinarily when a material change occurs: merger or acquisition, change in ISMS scope, significant regulatory modification, serious incident exposing framework weaknesses, change of management. The review is documented in minutes of the Security Committee or Management Committee, and if there are changes, a new version with number and date is approved. Version control is the responsibility of the ISMS officer.

Management approval with signature and date

Document closure with signature of the CEO, Managing Director or Board member with sufficient authority. Visible approval date. Version history in annex. The signature may be handwritten and scanned, qualified electronic signature or advanced electronic signature with timestamp, in accordance with eIDAS. Without signature and date, the document is not valid for audit purposes.

Practical template: commented structure

The document is structured in these sections, in this order:

1. Document identification. Title, internal code (for example POL-IS-001), version, date, classification (internal or public), author, reviewer, approver.

2. Purpose. Three or four lines. Declare that the document defines the governance framework for information security in the organization and supports compliance with ISO 27001:2022 and other applicable regulations.

3. Scope. Assets, processes, units, locations and subsidiaries included. Explicit exclusions if any. Literal alignment with ISMS scope.

4. Definitions. Brief glossary: confidentiality, integrity, availability, information asset, incident, risk, ISMS, SoA (Statement of Applicability). Five to ten terms maximum.

5. Guiding principles. Statement of principles: risk based approach, defense in depth, least privilege, segregation of duties, continual improvement, regulatory compliance, individual and collective responsibility.

6. Objectives. List of four to seven measurable objectives. Each objective links to a KPI defined in the ISMS dashboard.

7. Top management commitment. Approximately one page declaring leadership, resource allocation, annual review and continual improvement.

8. Roles and responsibilities. Table or list of roles with responsibility described in one or two lines per role.

9. Regulatory framework. List of applicable regulations.

10. Risk management approach. Reference to the methodology documented separately.

11. Related specific policies. List of specific policies developing areas of Annex A.

12. Compliance and internal disciplinary regime. Brief clause referring to the disciplinary procedure.

13. Communication. How the policy is communicated: intranet, onboarding, annual training, signed acknowledgement.

14. Review. Periodicity and triggers for extraordinary review.

15. Approval. Signature, name, position, date.

16. Version history. Table with version, date, author of changes, description of change.

Total recommended length: between 6 and 12 pages. More than 15 pages indicates that policy is being mixed with procedure.

Specific policies the framework policy must call out

The framework policy does not go into operational detail. It calls out specific policies that develop each area. The minimum recommended set to cover Annex A of ISO 27001:2022 includes:

• Logical access control policy: identity management, authentication, authorization, MFA, user lifecycle.
• Physical access control policy: secure areas, perimeter control, visitor logging, technical rooms.
• Cryptography policy: approved algorithms, key management, encryption at rest and in transit.
• BYOD and mobile devices policy: terms of use, MDM, separate profiles.
• Backup policy: frequency, retention, restoration tests, custody.
• Incident management policy: classification, escalation, notification within 24h and 72h when NIS2 or GDPR applies.
• Business continuity policy: RTO, RPO, contingency plans, annual testing.
• Supplier security policy: due diligence, contractual clauses, audit rights.
• Secure development policy: SDLC, code review, security testing, vulnerability management.
• Clean desk and clear screen policy: handling of information at workstations.
• Information classification policy: categories (public, internal, confidential, restricted) and handling rules per category.
• Retention and destruction policy: legal retention periods, secure erasure, media destruction.

Each specific policy can run between 2 and 6 pages. The framework policy cites them by name; the SoA details how they map to specific Annex A controls.

ISO 27001:2022 validation checklist (93 Annex A controls)

ISO 27001:2022 reduced the number of controls from 114 (2013 version) to 93 controls grouped into four domains:

Domain 5. Organizational controls (37 controls). Cover policies, roles, segregation of duties, contacts with authorities, asset management, classification, identity management, access control, organizational cryptography, supplier security, incident management and legal compliance. Most of these controls require specific policy documentation: control 5.1 requires policies; 5.10 requires acceptable use of assets; 5.15 requires access control; 5.19 requires supplier relationship security; 5.24 requires incident response planning.

Domain 6. People controls (8 controls). Cover pre employment screening, terms and conditions, awareness, training, disciplinary process, responsibilities after employment, confidentiality agreements and remote work. They require specific policies on awareness, remote work and discipline.

Domain 7. Physical controls (14 controls). Cover physical perimeters, entry controls, secure offices and rooms, physical monitoring, protection against physical and environmental threats, work in secure areas, clean desk, equipment placement and protection, cabling security, maintenance, secure disposal and reuse. They require specific policy documentation on clean desk and on media disposal.

Domain 8. Technological controls (34 controls). Cover endpoint, privileges, identity management, authentication, capacity management, malware, technical vulnerabilities, configuration, deletion, data leakage prevention, backup, redundancy, logging, monitoring, time synchronization, use of privileged utilities, software installation, networks, segmentation, web filtering, cryptography, secure development lifecycle, development environments, outsourced development, security testing. Most require detailed technical procedures and, transversally, a technical security policy that the framework policy must call out.

For certification it is mandatory to produce the Statement of Applicability (SoA) justifying each control: applicability, implementation, justification of exclusion where appropriate. The framework policy does not detail the SoA but must mention that it exists and where it is maintained.

Common mistakes in the policy

• Copying a generic template without adapting it. Auditors immediately detect reused templates. Any paragraph that does not fit the real organization is a nonconformity.
• Policy too long. More than 15 pages indicates mixture with manual or with procedures. The document loses its governance function and stops being read.
• Lack of periodic review. Documents dated 2021 when we are in 2026 are an immediate red flag.
• Failure to communicate to employees. Approved but not communicated policy, without acknowledgement evidence, without onboarding training. It is the most frequent failure in first audit.
• Failure to map to Annex A controls. The policy must call out the specific policies covering the controls; without that map, there is no way to demonstrate to the auditor that the framework is complete.
• Confusing policy with ISMS manual. They are different documents. The manual describes the full system; the policy governs principles and commitments.
• Failing to name the CISO or security officer. Without a clear responsible role, the policy is declarative but not executable.

How to approve and communicate the policy

Recommended approval flow: draft produced by the ISMS officer (CISO or equivalent); review by the Security Committee; legal review when there are clauses with contractual or labor impact; formal approval in Management Committee or by the CEO; signature with date; publication in the ISMS document repository; communication.

Communication channels that the auditor expects to see evidenced:

• Publication on intranet or corporate portal in a visible section accessible to all staff.
• Mandatory inclusion in the onboarding plan for new hires with signed acknowledgement.
• Annual awareness training that includes a reminder of the policy and a knowledge check (test).
• Distribution by corporate email when a new version is published, with instructions to read and acknowledge.
• Contractual clause or annex to the employment contract referring to compliance with the published security policies.

Without these evidences, the answer to the auditor's question "prove to me that your staff knows the policy" falls short.

Alignment with NIS2, DORA, national public sector frameworks

A well designed ISO 27001 security policy can become the framework document for multi regulation compliance if drafted with that intent from the start. The strategy is to design the policy as a global framework and develop in specific policies or annexes the differential requirements of each additional regulation.

ISO 27001 covers approximately 70% of the obligations of NIS2 article 21. The ISO 27001 based framework policy serves as the base, and is supplemented with specific policies that cover the deltas: incident notification within 24h and 72h, active supply chain management, specific board training, personal responsibility of directors.

DORA requires financial entities and critical ICT providers to maintain a framework for ICT risk management, incident management, digital operational resilience testing and third party risk management. An ISO framework policy can contain a specific section or annex for DORA when applicable.

National public sector security frameworks apply to organizations providing services to the public sector. These frameworks and ISO 27001 are highly compatible: an organization with a mature ISMS can certify the public sector framework at the appropriate level within short timeframes. The ISO framework policy is adapted with a specific section citing the applicable level.

Practical recommendation: if the organization is subject to several regulations, draft one single framework policy with annexes per additional regulation. Maintaining parallel policies generates contradictions and duplicates the work of annual review.

Frequently asked questions

Do I need separate policies or a single policy with many sections?

A short framework policy (6 to 12 pages) plus separate specific policies. Keeping a single policy with everything inside makes the document unreadable and forces a full review of the document for any minor change. Specific policies are updated more frequently (typically every year or whenever an operational change occurs); the framework policy stays stable for 2 to 4 years.

Who approves the security policy?

Top management. Depending on corporate structure: CEO, Managing Director, Board of Directors or Board member with sufficient authority. The ISMS officer (CISO or equivalent) drafts and maintains; the Security Committee reviews; management approves. This separation of roles is required by clause 5.1 of ISO 27001:2022.

What page count is reasonable for the framework policy?

Between 6 and 12 pages. Below 5 pages, content is usually missing; above 15 pages, there is mixture with procedures or specific policies. The audit metric that best predicts a well designed policy is readability: a new employee should be able to read and understand it in 20 minutes.

Review every year or every material change?

Both. Formal annual review with minutes from the Security Committee, with or without changes. Extraordinary review when there is a material change: new scope, merger, significant new regulation, serious incident, change of management. Annual review without changes is valid; it is enough to evidence that the policy was reviewed and the current version was kept.

Is a generic template enough to certify?

No. Any template, including this one, is a starting point. Certification requires that the document reflect the real organization: real scope, real roles, real applicable regulations, measurable specific objectives. An experienced auditor detects non adapted templates on first read. A template speeds the work by 40% to 60%; the rest is mandatory adaptation.

Will the auditor ask for evidence that the policy has been communicated?

Yes, always. It is one of the most frequent findings in a first audit: policy approved but no evidence of communication. The auditor will ask to see the portal or intranet where it is published, captures or records of inclusion in onboarding, list of acknowledgements signed by staff, training content where it is mentioned and training results. Without these evidences there is a nonconformity.

Related resources

• ISO 27001 explained: structure, controls and certification
• ISO 27001 certification: complete guide to process and costs
• ISO 27001 and NIS2: how they complement each other
• Cybersecurity audit for organizations: complete guide
• What is MAGERIT: risk analysis methodology
• NIS2 audit step by step: preparing for 2026

ISO 27001 ISMS implementation with Secra

At Secra we work with organizations that are starting their ISMS or that are renewing obsolete documentation before audit. Our work includes drafting the framework policy adapted to sector and scope, drafting the full set of specific policies aligned with the 93 Annex A controls, defining the Statement of Applicability, documentary evidence for certification audit and awareness training for staff.

If your organization plans to certify ISO 27001 in 2026 or needs to review the existing policy to align it with the 2022 version of the standard, contact us and we will design the work plan adapted to your case.