How to Write an Information Security Policy

The Information Security Policy is the cornerstone document of an ISO 27001 ISMS or a SOC 2 program — and usually the first thing an auditor reads. Here is what it should contain, who owns it, and why short and honest beats long and aspirational.

What the Information Security Policy is — and why auditors read it first

The Information Security Policy is the top-level, parent document of your security program. It is the statement, signed off by leadership, that says: this organization takes information security seriously, here is the high-level direction, and here is how the rest of our policies and procedures hang together. Everything else — your access control policy, incident response plan, acceptable use rules, vendor risk process — sits underneath it and inherits its authority.

It is deliberately high-level. The Information Security Policy does not specify your password length or your backup schedule; those belong in detailed sub-policies and procedures. Its job is to set intent, scope, and ownership, and to point to where the detail lives. Think of it as the constitution of your security program, not the operating manual.

Auditors reach for it early for exactly that reason. In an ISO 27001:2022 engagement, an information security policy is an explicit requirement — clause 5.2 calls for top management to establish a documented policy that is appropriate to the organization, communicated, and available. A SOC 2 service auditor (a licensed CPA firm) looks for the same anchor as evidence that your control environment is governed from the top, not assembled bottom-up by IT alone. A clear, current, signed policy signals a real program; its absence, or a generic one nobody can speak to, signals an immature one before the auditor has looked at a single control.

What a good Information Security Policy contains

A strong policy is short — often two to five pages — and covers a recognizable set of elements. More than that and people stop reading it, which defeats the point.

Purpose and scope. Why the policy exists and exactly what it covers: which entities, locations, systems, people, and information. For ISO 27001 this should align with your defined ISMS scope. Vague or sprawling scope is a common early problem, so be deliberate.

Management commitment. A clear statement that leadership backs the program, allocates resources, and holds the organization accountable for security. This is not boilerplate — ISO 27001 clause 5.1 places leadership and commitment squarely on top management, and auditors test whether that commitment is real.

Roles and responsibilities. Who owns security overall (often a CISO, security lead, or a named executive), who owns specific domains, and what is expected of every employee and contractor. Controls with no named owner tend to have no evidence either, so name them here.

High-level rules that reference detailed sub-policies. State your security objectives and the principles everyone must follow — protect confidentiality, integrity, and availability; comply with applicable legal and contractual obligations; report incidents — and then link out. The Information Security Policy should reference, not replace, the detailed documents: access control, acceptable use, data classification, incident response, business continuity, cryptography, and supplier management.

Review cadence. State how often the policy is reviewed (annually is a common baseline) and what triggers an off-cycle review — a significant incident, a major change to the business, new regulation. ISO 27001 expects policies to be reviewed at planned intervals and when significant changes occur.

Approval and sign-off. The policy must show it was formally approved: an approver, an approval date, a version number, and a record of changes. An unapproved or undated policy is, in audit terms, not a policy at all.

Who owns it and who approves it

Ownership and approval are different roles, and conflating them is a frequent mistake.

The owner is the person responsible for keeping the policy accurate, current, and aligned with how the organization actually operates — typically the security lead, CISO, ISMS manager, or equivalent. The owner drafts it, drives the review cycle, and reconciles it against practice.

The approver is top management: the executive or governing body with the authority to commit the organization. ISO 27001 clause 5.2 puts the information security policy in the hands of top management to establish, and in practice that means a documented, dated approval; a SOC 2 auditor will likewise expect to see that leadership formally endorsed it. That sign-off is what gives the document — and every sub-policy beneath it — its authority. An approval signature with a real date, captured in your document control records, is part of the evidence an auditor looks for.

The practical implication: do not let the policy be something IT wrote and quietly filed. The whole point of the cornerstone document is that leadership stands behind it, which means leadership has to read it, understand it, and put their name on it.

Common mistakes that turn into audit findings

Most weak Information Security Policies fail in the same few ways.

It is bloated. When the parent policy tries to specify every control in detail, it becomes a sprawling document nobody reads or maintains, and it drifts out of date the moment a procedure changes. Keep it high-level and push detail down into sub-policies you can revise independently.

It is copy-paste that does not match reality. A downloaded policy that mentions a 24/7 security operations center you do not have, or names roles that do not exist in your org chart, is worse than no policy. Auditors test the policy against practice, and contradictions become findings. Document what you genuinely do — then improve it — rather than publishing an aspiration you cannot evidence.

It is never reviewed. A policy approved two years ago, with no review record and a version that predates half your current systems, tells an auditor the program is not actually governed. The review cadence has to happen, with dated evidence that it did.

Nobody can speak to it. If an auditor asks an employee about the security policy and gets a blank look, the 'communicated and available' requirement is not met. The policy has to be distributed, acknowledged, and genuinely understood — not buried on a shared drive.

It has no links. A cornerstone document that does not reference the detailed sub-policies leaves the structure of the program unclear. The references are what make it a parent document rather than an orphan.

Keep it short, link to the detail, and make it true

The best Information Security Policies are short, structural, and honest. Three principles get you there.

Keep it short. Aim for a few pages. State purpose, scope, commitment, roles, high-level rules, review cadence, and approval — then stop. Brevity is what keeps it readable and maintainable, and a readable policy is one people actually follow.

Link to the detail. Treat the policy as a map. Each high-level rule should point to the sub-policy or procedure where the specifics live, so the parent document stays stable while the detailed layer evolves. This is also the hierarchy auditors expect: top-level policy down to operating procedures and the evidence they produce.

Make it true. This is the one that matters most. A policy is a description of what you actually do, governed and signed off by leadership — not a wish list. Before you approve it, read each statement and ask honestly: do we do this, and can we prove it? Where the answer is no, change the practice or change the wording. Alignment beats ambition every time.

A word on templates. A well-built template gives you the structure — the right sections, sensible default language, and a clear hierarchy linking the parent policy to its sub-policies — which is genuinely the slowest part to build from a blank page. But a template is a starting point you tailor, not instant compliance. It cannot make you compliant or certified. It gives you a head start on the document. Making it reflect your reality, getting leadership to approve it, communicating it, and reviewing it on schedule is work only your organization can do — and it is exactly what turns a document into a program.

Frequently asked questions

How long should an Information Security Policy be?

Short — commonly two to five pages. The top-level Information Security Policy is meant to set intent, scope, roles, and high-level rules, then point to detailed sub-policies and procedures for the specifics. If it grows into a long document that tries to cover every control, people stop reading it and it falls out of date as procedures change. Keep the parent policy concise and structural, and let the detail live in documents you can revise independently.

Who should approve the Information Security Policy?

Top management. ISO 27001:2022 clause 5.2 places the information security policy with top management to establish, and in practice that means a formal, dated approval; a SOC 2 service auditor likewise expects to see leadership endorse it. The owner — typically a security lead, CISO, or ISMS manager — drafts and maintains it, but the approval, with a named approver, a real date, and a version number, is what gives the policy and every sub-policy beneath it their authority. Capture that sign-off in your document control records as audit evidence.

What is the difference between the Information Security Policy and the sub-policies?

The Information Security Policy is the top-level parent document that sets direction, scope, commitment, roles, and high-level rules, and is signed off by leadership. Sub-policies — access control, acceptable use, incident response, data classification, vendor management, and others — contain the operational detail, such as specific configurations and step-by-step procedures. The parent policy references the sub-policies rather than restating them, which keeps the cornerstone document stable while the detailed layer evolves.

How often should the Information Security Policy be reviewed?

On a defined cadence — annually is a common baseline — and additionally whenever there is a significant change, such as a major incident, a substantial change to the business or its systems, or new applicable regulation. ISO 27001 expects policies to be reviewed at planned intervals and when significant changes occur, and an auditor will look for dated evidence that the review actually happened. A policy with no review record signals a program that is not being governed.

Will a policy template make my organization compliant?

No. A well-built template gives you the structure and sensible default language — the slowest part to build from scratch — but it is a starting point you tailor, not instant compliance. No document makes you compliant or certified: ISO certification comes from an accredited certification body, and a SOC 2 report from a licensed CPA firm, after auditing a program that genuinely operates. The policy must reflect what you actually do, be approved by leadership, be communicated, and be reviewed on schedule — work only your organization can do.

Related guides: ISO/IEC 27001 · SOC 2

Toolkits that help

← All articles