How-To6 June 2026 8 min read

How to Write an Information Security Policy (with Template)

Write an information security policy that satisfies SOC 2 auditors and actually gets followed. Structure, required sections, and a complete template.

Key Takeaways

An information security policy defines the scope, objectives, and responsibilities for security across the organisation.
SOC 2 requires an approved, version-controlled policy — a draft or undated document is insufficient.
The policy must be reviewed annually and updated when significant changes occur.
Keep the ISP high-level; supporting policies (access control, incident response, etc.) contain the specifics.
Every employee must acknowledge the policy — typically via an annual onboarding checklist or security training completion.

In this guide

What the ISP Must Accomplish
Recommended Structure
Section-by-Section Guide
Common Mistakes
Template Outline
Review and Approval Process

What the ISP Must Accomplish

Your Information Security Policy (ISP) is the foundational document of your security programme. SOC 2 CC1.2 and CC1.3 require that management establish a security commitment through formal policies, and CC2.2 requires that policies be communicated to relevant personnel.

The ISP must: define the scope of the security programme, establish management's commitment to security, assign roles and responsibilities, reference supporting policies and standards, and describe the consequences of non-compliance.

It does not need to contain every technical control. A good ISP is 3–6 pages of clear, senior-leadership-level commitments. The technical detail belongs in supporting policies (access control policy, change management policy, etc.).

Recommended Structure

A SOC 2-compliant ISP typically includes the following sections: Purpose and Scope, Policy Statement, Roles and Responsibilities, Information Classification, Acceptable Use, Supporting Policies and Standards, Enforcement, Review and Update Frequency, and Approval.

Version control is essential. Include a document metadata block at the top: Document Title, Version Number, Author, Approved By, Approval Date, Next Review Date, and Change History. Auditors will check version numbers and approval dates.

Section-by-Section Guide

Purpose and Scope: explain why the policy exists and who it applies to. A complete scope statement: "all employees, contractors, and third parties with access to company systems and data."

Policy Statement: a senior management declaration of commitment to information security. This section should be signed or approved by the CEO, CTO, or equivalent. It establishes tone from the top — a SOC 2 CC1.1 requirement.

Roles and Responsibilities: assign accountability. Typically: CISO/CTO (owns the programme), Department Heads (accountable for their team's compliance), all employees (responsible for following policies and reporting incidents), and IT/Engineering (responsible for implementing technical controls).

Enforcement and Exceptions: describe what happens if the policy is violated (up to and including termination) and how exceptions are requested, approved, and documented. Having a formal exception process is important — it shows auditors that deviations are controlled rather than ad-hoc.

Common Mistakes

Mistake 1: Copy-pasting a generic template without customisation. Auditors will ask questions about your policy. If you cannot explain what "information classification levels" means in your specific context, it is clear the policy was not written with your organisation in mind.

Mistake 2: No approval signature or date. An undated or unapproved policy does not satisfy CC1.2. Ensure every policy has a clear approval date and the name/title of the approver.

Mistake 3: Policy text that does not match actual practice. If your ISP states "quarterly access reviews" but you have only done one in the past year, that is a finding. Write policies that reflect achievable practice, then raise the bar incrementally.

Template Outline

Section 1 — Purpose: establish the framework for protecting information assets and defining security responsibilities.

Section 2 — Scope: applies to all employees, contractors, consultants, and third-party service providers with access to company systems or data, regardless of location.

Section 3 — Policy Statement: management commitment to maintaining an information security programme that protects confidentiality, integrity, and availability of customer and company data.

Sections 4–8 cover roles, classification, acceptable use, supporting policies list, enforcement, and the review schedule. The full template is available in AuditPath's policy library.

Review and Approval Process

Set a formal annual review date — typically 12 months from the approval date. Put a recurring calendar event on the policy owner's calendar. The review should: confirm the policy still reflects actual practice, update any role titles or team names that have changed, and incorporate any new regulatory requirements.

After each review: increment the version number (e.g. 1.0 to 1.1 for minor updates, 1.0 to 2.0 for major revisions), update the change history section, get a new approval signature, and re-distribute to all employees. Document the re-acknowledgement via employee signatures or LMS completion records.

Frequently Asked Questions

How long should an information security policy be?

For a startup or mid-size company, 3–6 pages is typical. Enterprise companies may have longer policies with more detailed role definitions. Do not pad the document — auditors value clarity and accuracy over length. A concise, approved, and followed 4-page policy is better than an unapproved 20-page document.

Does the ISP need to be reviewed by a lawyer?

Not strictly required for SOC 2, but legal review is recommended if your policy includes enforcement and termination clauses. For most early-stage companies, a review by your employment counsel before the first version is sufficient.

How do we track employee acknowledgement of the policy?

Common methods: security awareness training completion (if the training includes a policy acknowledgement quiz), annual "I have read and agree" checkbox in your HR system or onboarding tool, or an email with a DocuSign acknowledgement. Any method that creates an auditable record is acceptable.

Can we have one ISP or do we need separate policies for each topic?

Best practice is a hierarchy: one high-level ISP as the umbrella document, then specific supporting policies for each topic area. This structure makes it easier to update individual policies without re-approving the entire ISP.

What happens if we do not have an ISP at the time of our SOC 2 audit?

For Type I, you need the ISP in place at the audit date. For Type II, the ISP needs to have been in place throughout the observation period. If you are missing the ISP, your auditor will note it as a material weakness in control design. Write and approve the ISP before beginning audit conversations.