An information security policy is the top-level document in which an organization states its commitment to protecting information and sets the direction that every other security rule follows. It defines what the organization will do, who is accountable, and why, giving management, staff, and auditors a single reference point.
Almost every security framework starts here, and for good reason. Without a clear policy, controls get applied inconsistently, staff guess at what is expected, and auditors have nothing to anchor their assessment to. This guide walks through what the policy is, where it fits in ISO 27001, what it must contain, and how to write one that people actually read and follow rather than one that gathers dust.
What an information security policy is (and is not)
A policy is a high-level business rule that states intent. It says what the organization will do and often who is responsible, but it does not spell out the technical detail. That detail lives further down in the document hierarchy. A common mistake is trying to cram configuration steps and tool names into the policy itself, which makes it brittle and forces top management to re-approve it every time a product changes.
The policy is a statement of principle. It should still be true in three to five years, even as the technology underneath it changes. If you find yourself editing the main policy every quarter, the content probably belongs in a standard or procedure instead.
The policy hierarchy: policy, standard, procedure, guideline
Security documentation follows a hierarchy, with the information security policy at the top and progressively more detailed documents beneath it. Understanding these four layers prevents the single most common documentation failure: mixing intent, mandate, and instruction into one unreadable document.
- Policy: the high-level what and why. Example: "The organization protects information in transit using strong encryption."
- Standard: a mandatory, measurable requirement that supports the policy. Example: "All external data transfers must use TLS 1.2 or higher."
- Procedure: step-by-step instructions for how a task is done. Example: "Steps to configure the TLS profile on the load balancer."
- Guideline: recommended, non-mandatory advice that offers flexibility. Example: "Prefer certificate automation where practical."
Policies are meant to last for years, while standards and procedures change far more often because technology, business processes, and organizational structures move quickly. Keeping them in separate documents means you can update a procedure without dragging top management back through a full policy re-approval.
The hierarchy also clarifies enforcement. Policies and standards are mandatory, so breaking them has consequences, while guidelines are advisory and exist to help people make good decisions where rigid rules would not fit. When staff understand which layer a rule sits in, they know whether they are looking at a hard requirement or a recommendation, and that distinction alone removes a surprising amount of confusion during audits and day-to-day work.
What ISO 27001 Clause 5.2 requires
In ISO 27001:2022, Clause 5.2 makes the information security policy a mandatory, top-management responsibility. The clause requires that top management establish a policy that is appropriate to the purpose of the organization, includes information security objectives or a framework for setting them, commits to satisfying applicable requirements, and commits to continual improvement of the information security management system (ISMS).
The clause also demands that the policy be available as documented information, be communicated within the organization, and be available to interested parties as appropriate. This is where many implementations stumble: the policy exists as a file, but nobody has communicated it, so staff have never seen it and auditors find no evidence of awareness.
It helps to distinguish two things that share the word policy. Clause 5.2 governs the single, top-level information security policy owned by top management. Annex A control 5.1 then expects a family of topic-specific policies beneath it, covering areas such as access control, cryptography, acceptable use, and supplier security, each owned at the appropriate management level. Our guide to ISO 27001 certification explains how these documents fit into the wider ISMS, and the Statement of Applicability guide shows how the controls behind them are justified.
Best practice, echoed across ISO 27001 guidance and PCI DSS Requirement 12, is that the information security policy should be reviewed and approved by senior management at least annually. As a rule of thumb, no policy should carry a last-reviewed date older than 365 days.
What to include in the policy
A strong top-level policy stays short but covers the essentials. Aim for a document that a new employee can read in a few minutes and still walk away knowing what matters.
- Purpose and scope: what the policy covers and which parts of the organization it applies to.
- A management commitment statement signed or endorsed by top management.
- Information security objectives, or a clear framework for setting them.
- A commitment to meet legal, regulatory, and contractual requirements.
- A commitment to continual improvement of the ISMS.
- Roles and responsibilities, including the named policy owner.
- A reference to the topic-specific policies that sit beneath it.
- Version, approval date, next review date, and consequences of non-compliance.
How to write, approve, and review it
Drafting works best as a small cross-functional effort. Involve IT, legal, HR, and compliance so the policy reflects real obligations and real operations, then route the draft to senior leadership or the CISO for formal approval. Record that approval in management review minutes, because auditors look for evidence that top management genuinely endorsed the current version, not just that a document exists.
Set a review cadence of at least once a year, and trigger an out-of-cycle review after any major incident, significant infrastructure change, or new legal obligation. Each review should confirm the policy is still accurate, still communicated, and still owned. Treat the review date as a live commitment, not a formality.
Communication is the step most teams underestimate. A policy that lives in a shared drive but has never been circulated does not satisfy Clause 5.2, and it does nothing to change behavior. Build communication into onboarding, require an acknowledgement that staff have read it, and reinforce the key points through awareness training. Auditors routinely ask employees whether they know the policy exists, and a confident answer is worth more than any signature on the document itself.
Common mistakes to avoid
The biggest failure is the copy-paste template that nobody follows. A downloaded policy full of controls the organization does not actually operate is worse than no policy, because it creates audit findings and gives staff a document they cannot act on. Other frequent problems include burying technical detail in the top-level policy, never communicating it to employees, leaving the review date to lapse, and having no named owner, so nobody keeps it current.
Write the policy for your organization, keep it high-level, communicate it, and review it on schedule. Do that, and the information security policy becomes what it is meant to be: the foundation the rest of your security program stands on.