Information Security Policy

The information security policy is the document every other control points back to. It is short on technical detail by design: its job is to state management's intent, set the direction for the security program, and assign accountability. Auditors read it first because it tells them what the organization has committed to, and then they spend the rest of the audit checking whether reality matches. This template gives you a starting structure; the value comes from making every statement in it true for your organization.

Top-level policy versus topic-specific policies

ISO/IEC 27001:2022 separates two layers. Clause 5.2 requires top management to establish an information security policy, and Annex A control 5.1 extends that to a set of topic-specific policies (access control, incident management, supplier security, cryptography and so on). The top-level policy should stay stable for years. Operational rules that change often, like password length or log retention periods, belong in topic-specific policies or standards so you are not re-approving the master document every quarter.

A practical split: keep the top-level policy to what the board or CEO can genuinely own, then reference companion documents such as the access control policy and the incident response plan. Each companion document names its own owner and review cycle.

Sections a good policy contains

Framework requirements this document supports

Because the same policy answers all five, it is a good example of writing once and mapping many times. The approach is explained in one control, four frameworks, and framework-specific detail lives on the ISO 27001 page.

Customizing the template for your organization

1. Write the scope from your real environment. List the legal entities, offices, cloud accounts, and product lines in scope. If you are pursuing certification, the scope must match the ISMS scope statement word for word.
2. Replace generic objectives with ones you can measure. For example, a target for patching critical vulnerabilities or completing awareness training, each with an owner who reports on it.
3. Name roles, not people. Use job titles such as Head of Security so the document survives staff turnover.
4. Delete commitments you will not keep. A promise of quarterly penetration tests that happen annually becomes a nonconformity.
5. Align terminology with your other documents. If the risk methodology says risk owner, do not say risk custodian here.
6. Set the review frequency deliberately. Annual review is the common default and meets PCI DSS; add triggers such as acquisitions, major incidents, or new regulations.

Approval, communication, and acknowledgement

The approver should be top management: the CEO, the executive team, or a board-level committee, depending on how the organization is governed. A security lead approving their own policy does not demonstrate leadership commitment. After approval, publish the policy where staff can find it, communicate that it exists, and collect acknowledgements from employees and relevant contractors at onboarding and after each material revision.

How auditors test the policy

Testing usually happens in three passes. First, design: does the document contain what the framework requires and is it approved by the right level? Second, communication: auditors pick employees, sometimes at random during interviews, and ask whether they know where the policy lives and what it expects of them. Third, consistency: statements in the policy are compared against operating practice. If the policy says all laptops are encrypted, expect a sample of endpoints to be checked, often through evidence pulled from device management tooling.

Common mistakes

• Copying a template verbatim, including controls, tools, or teams the organization does not have.
• Stuffing technical standards into the top-level policy so it needs re-approval every time a setting changes.
• No acknowledgement tracking, or acknowledgements collected once and never after revisions.
• Approval by someone without authority over the whole scope.
• Scope in the policy that differs from the scope in the statement of applicability or audit engagement letter.

In Asurvo's policy center, AI drafts the policy from your organization's context rather than boilerplate, and versioning, approvals, review cycles, and acknowledgement tracking are recorded as you go, so the evidence above exists without a separate spreadsheet. See the Governance product for details.