ISO/IEC 27001 2022 Information‑Security Policy Example

ISOIEC 27001 Information‑Security Policy Example
Information security

ISO/IEC 27001 2022 Information‑Security Policy Example

Last Updated on September 30, 2025 by Melissa Lazaro

Introduction

In my work helping organizations prepare for ISO/IEC 27001 certification, one of the first documents we always start with is the Information Security Policy. Why? Because it sets the tone at the top—it’s the statement from management that says, “We take information security seriously, and here’s how we commit to it.”

But here’s the challenge I see all the time: teams either make the policy so broad and vague that it’s meaningless, or they turn it into a 20-page manual that no one reads. Both extremes fail the real purpose of the policy—to give direction, build awareness, and satisfy the specific requirements of Clause 5.2 in ISO/IEC 27001:2022.

Let’s be clear about what this policy should achieve. It’s not meant to explain every control or procedure. Instead, it’s a high-level commitment from leadership that guides everything else in your ISMS.

To put it simply:

What It Is What It Is Not
A top-level statement of intent and direction from management A detailed step-by-step procedure
A communication tool to show staff, partners, and auditors the organization’s commitment A technical manual or checklist
A mandatory requirement under Clause 5.2 of ISO/IEC 27001:2022 An optional or “nice-to-have” document

In this article, I’ll give you a clear, ISO-aligned example of an Information Security Policy, explain the requirements behind it, and share practical tips on tailoring it so it actually works in your organization—not just for the audit, but for day-to-day use.

What is an ISO/IEC 27001 Information Security Policy?

Here’s how I usually explain it when sitting down with a client: the Information Security Policy is the big picture statement that tells everyone in the organization—staff, contractors, even auditors—what the company stands for when it comes to protecting information.

It’s not about passwords, backups, or access rights in detail. Those belong in procedures. The policy is higher-level—it’s the north star that gives direction to the ISMS.

A lot of confusion comes from mixing up policies and procedures. I’ve seen companies write a 15-page “policy” that’s actually a set of procedures. When the auditor asks the CEO to explain the Information Security Policy, the CEO stares at a wall of technical instructions that nobody outside of IT understands. That’s not the point.

Here’s a quick way to separate the two:

Policy Procedure
Broad, high-level statement of intent and direction Detailed, step-by-step instructions
Approved and signed by top management Owned and maintained by process owners
Tells “what” and “why” Explains “how”
Example: “We commit to protecting customer data and complying with regulations.” Example: “All staff must change their password every 90 days.”

Why This Matters

  • For staff: It tells them the company cares about security and sets expectations.

  • For management: It’s proof of leadership commitment.

  • For auditors: It’s mandatory under Clause 5.2—if it’s missing or poorly written, certification is at risk.

In my experience, the best Information Security Policies are short—one to two pages max—written in plain language, and signed by top management. That way, anyone can read and understand it, from a new employee to an external partner.

ISO/IEC 27001 2022 Information‑Security Policy Example

Core Requirements from ISO/IEC 27001:2022 (Clause 5.2)

Clause 5.2 of ISO/IEC 27001:2022 is very specific about what your Information Security Policy must contain. It isn’t optional, and auditors check it carefully.

In simple terms, the standard wants your policy to prove that top management is genuinely committed to information security—not just on paper, but as a guiding principle.

Here’s the breakdown:

Clause 5.2 Requirement Plain-Language Explanation Common Mistake
The policy must be approved by top management CEO, CIO, or equivalent must sign off—it can’t just be written by IT alone. Policy written by IT and never formally approved.
The policy must be aligned with organizational purpose and context It should reflect your business model, risks, and objectives. A bank’s policy looks different from a SaaS startup’s. Copy-pasting generic wording from a template.
It must support the organization’s information security objectives Policy should link to measurable ISMS objectives (e.g., employee awareness, customer data protection). Objectives not mentioned at all, making the policy sound disconnected.
It must include a commitment to meet requirements Cover legal, regulatory, contractual, and ISO/IEC 27001 requirements. Only mentions ISO compliance, ignoring legal or customer obligations.
It must include a commitment to continual improvement Show that your security management is not static—you’ll keep reviewing and improving. Forgetting to mention continual improvement, which auditors always check.
It must be communicated and made available Employees, contractors, and even partners should know it exists. Publishing it internally is required. Policy stored in a folder nobody can access, or staff unaware of it.

Why Auditors Care

When I’ve sat through certification audits, one of the first requests from auditors is: “Show me your Information Security Policy.” Then they ask top management to explain it. If leadership can’t summarize the key commitments, it raises a red flag that the policy is just for show.

This is why keeping it short, clear, and aligned with real business objectives is the best strategy.

Example: ISO/IEC 27001:2022 Information Security Policy (Template)

Here’s a practical example of an ISO/IEC 27001:2022 Information Security Policy. This is the type of document auditors expect to see, and it should be customized to fit your organization’s size, industry, and risks.

Information Security Policy (Sample)

1. Purpose & Scope
This policy defines the organization’s commitment to protecting information assets from threats, whether internal or external, deliberate or accidental. It applies to all employees, contractors, and third parties who access company systems, data, or facilities.

2. Objectives

  • Ensure the confidentiality, integrity, and availability of information.

  • Protect customer, employee, and partner data in compliance with legal, regulatory, and contractual obligations.

  • Support business continuity through risk-based information security practices.

  • Promote awareness and accountability across the organization.

3. Roles & Responsibilities

Role Responsibility
Top Management Approves the policy, ensures resources are available, and reviews effectiveness.
Information Security Officer (ISO/CISO) Oversees ISMS operations, risk management, and compliance with ISO/IEC 27001.
Department Managers Ensure policy compliance within their teams and report security incidents.
All Employees & Contractors Follow security practices, attend awareness training, and report suspicious activity.

4. Risk Management Commitment
The organization will conduct regular risk assessments, apply appropriate controls from Annex A, and implement risk treatment plans that align with business objectives.

5. Compliance & Legal Obligations
We commit to meeting applicable legal, regulatory, and contractual requirements, including data protection and privacy laws relevant to our industry and region.

6. Training & Awareness
All employees will receive information security awareness training at least annually, and training will be updated to reflect emerging risks.

7. Continuous Improvement
This policy will be reviewed annually and updated as needed to ensure it remains aligned with business strategy, regulatory requirements, and risk environment changes.

Approval
This policy has been reviewed and approved by Top Management.

Signature: _______________________
Name: [CEO / Managing Director]
Date: [Insert Date]

Why This Example Works

  • Short and readable: Two to three pages at most.

  • Aligned with ISO requirements: Covers leadership approval, commitment to compliance, and continual improvement.

  • Practical: Assigns clear responsibilities and links to risk management.

How to Customize the Policy for Your Organization

An Information Security Policy only works if it actually reflects your organization. Auditors are quick to spot generic templates, and employees won’t follow a document that doesn’t make sense in their daily work.

Here’s how I usually guide clients through customization:

Step 1. Align with Your Business Context

  • Look at your core business model: a hospital’s focus is patient confidentiality; a fintech’s focus is secure transactions.

  • Make sure the policy language speaks directly to your real risks and objectives.

  • Pitfall: Copying “big company” policies that don’t fit. For example, a 50-person startup doesn’t need a 10-page section on physical data centers if everything runs in the cloud.

Step 2. Keep It High-Level but Clear

  • Your policy should explain the what and why, not the technical details.

  • Example: Say “We protect customer data through appropriate technical and organizational measures” instead of “We enforce AES-256 encryption.” The latter belongs in procedures.

  • Pro Tip: Aim for a 2-page maximum. If your staff can’t read it in one sitting, it’s too long.

Step 3. Define Role-Based Responsibilities

  • Spell out who does what, without drowning in details.

  • A simple responsibility table (like in the example policy) goes a long way.

  • Mistake to avoid: Leaving it vague—if “everyone is responsible,” then no one is accountable.

Step 4. Speak Your Company’s Language

  • Use terms your employees understand. If your team uses “Service Desk” instead of “IT Helpdesk,” write it that way.

  • In my experience, staff buy-in increases when the policy sounds like their company, not a textbook.

Step 5. Get Top Management Buy-In

  • The policy has no value without leadership approval. I always insist the CEO or equivalent signs it.

  • It signals commitment to employees and satisfies auditors.

  • Pitfall: Letting IT draft and circulate the policy without executive approval. Auditors mark that as a failure of leadership commitment under Clause 5.

Quick Checklist for Customization

Customization Step Why It Matters Pitfall to Avoid
Align with business context Ensures relevance to real risks Using generic, irrelevant templates
Keep it high-level Keeps it understandable Writing technical details into policy
Define responsibilities Creates accountability “Everyone is responsible” approach
Use company language Improves staff adoption Copy-pasting ISO jargon
Get top management approval Shows leadership commitment Policy unsigned or hidden in IT

Bottom line: The best Information Security Policies are the ones people can read, understand, and connect to their day-to-day roles. Customization makes the difference between a living policy and a forgotten document.

Making the Policy Practical & Auditable

A common mistake I’ve seen is treating the Information Security Policy as a “check-the-box” document. It gets written, signed, filed in a folder—and never seen again. When the auditor asks staff about it, nobody can explain what it says. That’s an easy way to lose credibility.

The policy only adds value if it’s practical, communicated, and reviewed regularly.

Step 1. Communication Across the Organization

  • Publish the policy in a place employees can access easily (intranet, HR portal, or company handbook).

  • Introduce it during onboarding so new staff understand information security is part of the culture.

  • Reinforce it with awareness campaigns—posters, emails, or short reminders during staff meetings.

  • Pitfall: Uploading it to a shared drive and assuming “people will read it.” They won’t.

Step 2. Assign Ownership

  • Every policy needs a clear owner, usually the CISO, IT Manager, or Compliance Officer.

  • The owner is responsible for:

    • Reviewing it annually.

    • Updating it when risks, laws, or systems change.

    • Reporting to top management during management reviews.

  • Pro Tip: Don’t overcomplicate ownership. One named person with accountability is better than a vague “team responsibility.”

Step 3. Review and Update Regularly

  • ISO/IEC 27001 doesn’t set a strict timeline, but annual review is best practice.

  • Also review after:

    • Major organizational changes (mergers, restructuring).

    • New legal/regulatory requirements (GDPR, HIPAA, etc.).

    • Significant security incidents.

Review Trigger What to Check
Annual review Is it still aligned with business objectives and ISMS scope?
New regulation Does the policy mention compliance with the new law?
Major incident Does the policy need stronger commitment to monitoring, reporting, or training?

Step 4. Demonstrating Effectiveness to Auditors

Auditors don’t just want to see the signed document—they want proof it’s communicated and understood. They may ask random employees:

  • “Have you seen the Information Security Policy?”

  • “What are the main commitments?”

If staff have no idea, it raises concerns. That’s why embedding the policy into training and internal communication is critical.

Key Point: A policy that nobody reads is useless. A policy that’s signed, communicated, and refreshed regularly shows auditors (and staff) that the organization truly lives by its information security commitments.

Common Audit Findings on Information Security Policies

Over the years, I’ve seen the same audit findings come up repeatedly when it comes to information security policies. They’re not usually about having a policy—it’s about whether it’s credible, current, and applied in practice.

1. Policy Not Approved by Top Management

  • Finding: The policy was drafted by IT but never signed or endorsed by leadership.

  • Example: A tech startup had a detailed policy, but the CEO had never reviewed it. The auditor marked a major nonconformity under Clause 5.2 for lack of leadership commitment.

  • How to Avoid: Always get top management’s signature. It proves ownership at the highest level.

2. Policy Not Communicated to Staff

  • Finding: Employees didn’t know the policy existed, or couldn’t explain its purpose.

  • Example: In a financial services firm, auditors asked front-line staff if they’d seen the policy. Most had never heard of it. Result: a minor nonconformity for poor communication.

  • How to Avoid: Publish it widely (intranet, onboarding, staff briefings) and make sure it’s part of awareness training.

3. Policy Too Generic or Copy-Pasted

  • Finding: The policy looked like it was pulled straight from a template without customization.

  • Example: A healthcare provider’s policy mentioned “manufacturing processes” that didn’t exist in their business. The auditor flagged it as irrelevant, undermining credibility.

  • How to Avoid: Tailor the policy to your context—industry, risks, and objectives.

4. Outdated Policy

  • Finding: The policy hadn’t been reviewed in years, even though the business and risk environment had changed.

  • Example: A SaaS company moved fully to cloud hosting but the policy still referenced on-premise servers. The auditor raised a nonconformity for lack of review.

  • How to Avoid: Review annually, and after major changes.

5. Policy Not Linked to Measurable Objectives

  • Finding: Policy commitments weren’t tied to clear ISMS objectives.

  • Example: The policy said “We will improve information security awareness” but the company had no measurable target (like “100% of staff trained by Q2”). Auditor flagged a gap.

  • How to Avoid: Align policy with specific, measurable objectives under Clause 6.2.

Quick Recap Table

Common Finding Impact How to Prevent It
No management approval Major NC Secure top management sign-off
Not communicated to staff Minor NC Publish, train, and raise awareness
Generic / copy-paste text Weakens credibility Customize to your context
Outdated content Nonconformity Annual review + trigger-based updates
No link to objectives Gap in compliance Tie commitments to measurable KPIs

Key Takeaway: Auditors don’t just want a signed piece of paper. They want to see a current, customized, and communicated policy that’s embedded into the organization. That’s the difference between passing comfortably and scrambling to fix NCs after an audit.

FAQs (Strengthen Trust & Address User Intent)

Q1. How detailed should the Information Security Policy be?

It should be short and high-level. Think two pages, maximum. The policy sets direction and commitments. The detailed “how” belongs in procedures and guidelines. Auditors don’t expect technical details here—they want clarity and leadership intent.

Q2. Who should approve and sign the policy?

Top management. That means your CEO, Managing Director, or equivalent. The reason is simple: ISO/IEC 27001 treats the policy as a statement of leadership commitment. If it’s not signed at the top, it loses credibility with both employees and auditors.

Q3. How often should the policy be reviewed?

At least once a year. But don’t wait if something big changes—like a new regulation, major incident, or shift in business strategy. A quick update at the right time saves you from having an outdated document during audit.

Conclusion (Reaffirm Authority & Prompt Action)

The Information Security Policy isn’t just a formality—it’s the foundation of your ISMS. Done well, it shows auditors, employees, and customers that leadership takes security seriously. Done poorly, it becomes a forgotten document that weakens your certification effort.

The key is to keep it short, customized, and living:

  • Approved and signed by top management.

  • Communicated so staff know what it means.

  • Reviewed regularly to stay relevant to business risks and objectives.

In my experience, organizations that treat the policy as a living commitment—not just paperwork—get smoother audits and stronger staff engagement.

If you’re drafting or updating your own policy, start simple. Adapt the example you’ve seen here, align it with your context, and make sure it’s communicated across the company.

Next Step: If you want to save time, you can use a ready-to-customize ISO/IEC 27001 Information Security Policy template or follow a step-by-step implementation guide to make sure your policy—and the rest of your ISMS—meets the 2022 requirements without overcomplicating things.

Share on social media

Leave your thought here

Your email address will not be published. Required fields are marked *