An ISMS policy, called the information security policy in ISO/IEC 27001:2022, is the statement top management establishes under Clause 5.2 to set the organisation’s direction for information security. It must suit the organisation’s purpose, include objectives or a framework for setting them, commit to meeting applicable requirements and continual improvement, and be documented, communicated and available.
What must an ISO 27001 information security policy include?
Clause 5.2 of ISO/IEC 27001:2022 sets seven requirements. Four describe what the policy says and three describe how it is handled. Use this checklist against your current policy:
- Fits your organisation: the policy is appropriate to the purpose of the organisation, not a generic statement.
- Objectives: it includes information security objectives, or gives the framework for setting them (Clause 6.2 covers the objectives themselves).
- Commitment to requirements: it commits the organisation to meeting the information security requirements that apply to it, such as laws, regulations and contracts.
- Commitment to improvement: it commits to continual improvement of the information security management system (ISMS).
- Documented: it is available as documented information.
- Communicated: it is communicated within the organisation.
- Available to others: it is available to interested parties, as appropriate.
Clause 5.1 adds that top management must make sure the policy and objectives are established and compatible with the organisation’s strategic direction. ISO/IEC 27002:2022 control 5.1 gives further guidance on what the policy can contain, which the outline below draws on.
Example ISMS policy outline
The table is an example structure, not a template to copy. The owners shown are typical choices; assign the roles that exist in your organisation.
| Section | Content | Owner (example) |
|---|---|---|
| Purpose and scope | Why the policy exists, what the ISMS covers and how information security supports the business | Top management |
| Definition of information security | What information security means for your organisation | Information security manager |
| Objectives | The information security objectives, or the framework for setting them | Top management |
| Principles | The principles that guide all information security activity | Information security manager |
| Commitments | Commitment to meet the requirements that apply and to keep improving the ISMS | Top management |
| Roles and responsibilities | Who is responsible for information security management | Top management |
| Exceptions | How exemptions and exceptions to the policy are requested and handled | Information security manager |
| Topic-specific policies | A list of the supporting policies, such as access control or supplier security | Policy owners |
| Approval, communication and review | Who approved the policy and when, how it is shared, and when it will be reviewed | Top management |
What does top management have to do for the policy?
Clause 5.2 places the duty to establish the policy on top management, so the board or senior leadership cannot treat it as a document IT signs off alone. A quick sign-off without discussion leaves gaps: leaders lose sight of the risks the policy is meant to address, and staff see it as paperwork.
Trust is built when directors challenge, adapt, and live by your security policy.
A board that leads reviews risk regularly and links the policy to real changes: shifts in the market, new threats, or lessons from near-misses. When directors own the outcome, the policy becomes a working commitment that everyone in the organisation can rely on.
How Real Ownership Looks (Not Just Lip Service)
- Visible Audit Trail: Documented board debates, risk decisions, and follow-through.
- Leadership Signals: Executives sharing policy wins and “lessons learned” out loud with your teams and supply chain.
- Responsive Action: Policy updates after real incidents, not just “wait for the next annual review.”
When the board questions the policy, your people and your partners see an organisation that is vigilant, not just ticking boxes.
Book a demoWhy does a generic policy template fall short of Clause 5.2?
Every organisation’s risks are different. Clause 5.2 asks for a policy that is appropriate to the purpose of your organisation, so a template copied from another business or sector rarely fits. Vague language, or wording that describes someone else’s operations, shows gaps. An auditor or a customer doing due diligence may ask how the policy reflects your actual business.
If your policy sounds like it was built for a different company, your real risks and priorities are invisible.
An appropriate policy names your own assets, workflows and legal exposures. A healthcare provider handles patient data and privacy duties. A software company depends on software supply chains and third-party APIs. Sector, location and contract terms all change where the risk sits. A policy fits when people across the business, from IT to HR, can see their duties and risks reflected in it.
Reality-first, not template-first
If an investor or customer asks, can your teams explain how the policy fits their daily work? Does what is on paper match the decisions behind your workflows? A tailored policy that has been checked against how the business really operates passes this test, and that builds trust.
ISO 27001 made easy
An 81% Headstart from day one
We’ve done the hard work for you, giving you an 81% Headstart from the moment you log on. All you have to do is fill in the blanks.
What should information security objectives look like?
Clause 5.2 requires the policy to include information security objectives or a framework for setting them. Clause 6.2 then says the objectives must be consistent with the policy, measurable where practicable, monitored, communicated and updated as appropriate. “Protect information” is not an objective anyone can measure.
If you can’t measure a target, you can’t prove (or improve) your security.
A concrete objective might look like this:
- Protect member data in line with GDPR
- Owner: DPO
- Action: Quarterly access reviews
- Proof: Annual compliance report
Measurable objectives make security reliable and turn the policy from a governance chore into something the business can use.
Who should own the information security policy?
Top management establishes the policy under Clause 5.2, and Clause 5.3 requires top management to make sure responsibilities and authorities for information security roles are assigned and communicated. A polished document with no named owners gives staff no one to ask. Ownership shows when leaders brief their people, keep documents current and revise them quickly after something goes wrong.
Silent leadership means invisible policy, and invisible security.
Use a RACI chart (responsible, accountable, consulted, informed) or a similar structure to assign each part of the policy. Keep the evidence as you go: training attendance, meeting notes and policy change logs matter as much as the words on the page. Organisations that keep ownership visible find it easier to show their ISMS works and recover faster from setbacks.
How do you map laws, regulations and contracts to the policy?
Clause 5.2 requires the policy to commit the organisation to meeting the information security requirements that apply to it. Vague phrases such as “in line with applicable law” leave that commitment untested. Tie each obligation to a section of your policy and to the person responsible for it. Depending on where you operate, that can include UK GDPR or EU GDPR, CCPA, NIS 2, sector rules, and every client or supplier contract clause that affects information security.
Compliance isn’t assumed: it’s mapped, tracked, and owned.
A simple way to do this is a register kept up to date, in a table or dashboard:
| Law/Standard | Section of your policy | Owner | Last Review |
|---|---|---|---|
| GDPR Art. 32 | 5.2.1 | DPO | 16/03/2024 |
| NIS 2 Art. 21 | 5.2.4 | CTO | 11/02/2024 |
If you cannot see at a glance who owns each obligation and when it was last checked, the mapping is not doing its job. Record dates, names and obligations, then update the register when the rules or your contracts change.
How often should the information security policy be reviewed?
Clause 5.2 does not set a review frequency. ISO/IEC 27002:2022 control 5.1 recommends reviewing the policy at planned intervals and when significant changes occur, taking the results of management reviews and audits into account. In practice that means a scheduled review plus a review whenever a trigger arises: a new threat, a change in law or contract, or an incident that exposes a gap.
A calendar review never replaces learning from a real-world event.
The best reviews bring in compliance, technical and operations staff so blind spots do not slip through. Record each trigger and link it to the policy section it changed. A simple timeline can track each update from draft to decision. Top management should approve any changes to the policy, as ISO/IEC 27002:2022 control 5.1 also recommends.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
How should the policy be communicated and made available?
Clause 5.2 requires the policy to be communicated within the organisation and available to interested parties, as appropriate. Clause 7.4 asks you to decide what to communicate, when, with whom and how. ISO/IEC 27002:2022 control 5.1 adds that the policy should be shared in a form that is relevant, accessible and understandable, and that recipients should acknowledge it where appropriate. Clicking “agree” at onboarding, on its own, does little to change behaviour.
Policies don’t change culture until people know them by heart.
Keep evidence that the policy is in use: briefings, policy question-and-answer sessions, e-learning completion, post-incident briefings and short quizzes. Review completion rates, what people remember and incident debriefs to spot and close gaps. ISMS.online builds engagement and verification into each step, so you can show the policy is in use, not just on paper.
How do you keep the policy aligned with ISO 27001:2022?
The transition period from ISO/IEC 27001:2013 to the 2022 edition ended on 31/10/2025. If your policy still quotes 2013 wording or Annex A control numbers, update it: the controls were renumbered in 2022, so the policy control A.5.1.1 in the 2013 edition is control 5.1 in the 2022 edition. The text of Clause 5.2 itself is the same in substance in both editions.
Keeping the policy aligned takes the same discipline as any change project. Name a lead, set milestones and track every change. Record each key date, owner and document status, and keep the policy under version control so you can show what changed and when. ISMS.online lets you visualise, map and evidence each action.
Why choose ISMS.online for your information security policy?
ISMS.online brings operational discipline, evidence for audits and staff engagement into the policy process. It helps you:
- Work with our experts to create a policy that reflects how your organisation really works and who is responsible for what.
- Make each review and improvement step clear with best-practice checklists in the Action Centre.
- Keep the policy under version control, with auto-versioning.
- Hold the evidence for audits in customised audit dashboards.
- Build engagement and verification into each step, so you can show the policy is in use, not just on paper.
- Visualise, map and evidence each action.
- Prepare for certification: ISMS.online helps you achieve certification, and the certificate itself comes from an accredited certification body.
To see how ISMS.online can help you build and run your information security policy, book a demo.
Frequently Asked Questions
Does top management have to write the information security policy?
No. Clause 5.2 of ISO/IEC 27001:2022 requires top management to establish the policy, but it does not say who drafts the wording. An information security manager or a working group can prepare the draft. What matters is that top management sets the direction, approves the final text and stays accountable for it.
What is the difference between the information security policy and topic-specific policies?
The information security policy is the single high-level document required by Clause 5.2. Topic-specific policies are more detailed documents on one subject, such as access control, backup or acceptable use. ISO/IEC 27002:2022 control 5.1 describes the information security policy as general and approved by top management, and topic-specific policies as specific and detailed and approved by an appropriate level of management. Annex A control 5.1 of ISO/IEC 27001:2022 covers both.
How detailed does an ISMS policy need to be?
ISO/IEC 27001:2022 sets no length or format for the policy. It needs to meet the seven Clause 5.2 requirements and be clear enough for staff and other readers to understand. Detailed rules usually sit better in topic-specific policies and procedures, so the main policy can stay short and stable while the detail changes more often.
Do we have to share the policy with customers and suppliers?
Clause 5.2 says the policy must be available to interested parties “as appropriate”, so you decide who outside the organisation needs it. Customers and suppliers are obvious candidates. One option is a short public version, with internal detail kept in topic-specific policies. Whatever you choose, record who receives the policy and how.
Do the information security objectives have to be written into the policy?
Not necessarily. Clause 5.2 allows either option: the policy can include the objectives, or it can give the framework for setting them. The framework approach lets you update the objectives, for example in a separate objectives register, without reissuing the whole policy. Either way, the objectives must meet Clause 6.2.
Can one information security policy also support SOC 2?
SOC 2 is a separate framework with its own criteria, so check your policy against both. The Clause 5.2 requirements on this page cover the ISO 27001 side. For the SOC 2 side, see our SOC 2 information security policy guide.
