Compliance Artifacts

The information security policy, explained (with outline)

An information security policy (ISP) is the top-level document of your security program — the short, executive-approved policy that sets scope, accountability, and durable commitments, and delegates operational detail to sub-policies. Here’s what belongs in it, who approves it, how auditors test it, and an annotated outline you can adapt.

Talk to a Compliance Engineer

Last updated July 26, 2026

What an information security policy actually is

Every framework you’ll ever pursue — SOC 2, ISO 27001, HIPAA — expects an information security policy. It’s the top of the policy suite: the document that states what the company protects, who is accountable, and by whose authority everything else is enforced. Acceptable use, access control, incident response — all of it hangs off this one page of intent.

Think constitution, not law library. ISO 27001 makes the hierarchy explicit: top management must establish the policy and own it, and the auditor checks that leadership actually does. SOC 2 never prescribes a document list, but the ISP is one of the first things a SOC 2 auditor reads, because it frames the entire control environment they’re about to test.

A good one is short — three to six pages. Length is a warning sign: when everything lives in a single giant document, nobody reads it, nobody maintains it, and the version employees acknowledged two years ago quietly stops matching the one on the wiki.

What belongs in the ISP versus the sub-policies

The ISP carries the durable parts: scope (which people, systems, and data it covers), security objectives, roles and accountability, an exception process, consequences for violations, and an index of the sub-policies that hold the operational detail.

Sub-policies carry everything that changes when your stack or headcount changes: acceptable use (what employees may do with company systems), access control (how accounts are granted, reviewed, and revoked), incident response (who does what when something breaks), vendor management (how third parties are vetted), plus data classification, change management, and business continuity. A useful test: if adopting a new tool would force an edit, the content belongs in a sub-policy. The ISP itself should survive an infrastructure migration untouched.

That split is what keeps the suite maintainable. The ISP gets executive sign-off and rare, deliberate changes; sub-policies get updated by their owners as operations evolve, without routing every tweak through the CEO.

An annotated outline you can adapt

Information security policy — annotated outline

[Company, Inc.] Information Security Policy — v3.1, approved [June 12, 2026]

1. Purpose. One paragraph on why the policy exists: protecting customer and company data, meeting legal and contractual obligations, sustaining trust in [Company] services.

2. Scope. Who and what is covered: all employees and contractors, all systems that store or process [Company] data, all locations — including remote work.

3. Security objectives. The handful of commitments everything else serves — confidentiality, integrity, availability — in plain language, not framework jargon.

4. Roles and responsibilities. Named accountability: the executive owner ([CISO or CTO]), an owner for each sub-policy, and what every employee is responsible for.

5. Policy statements. The durable rules: least-privilege access, encryption of customer data in transit and at rest, mandatory security training, the duty to report incidents. One line each — detail lives downstream.

6. Sub-policy index. The authoritative list — acceptable use, access control, incident response, vendor management, data classification, change management, business continuity — each with its owner and where it lives.

7. Exceptions. How a deviation is requested, who may approve it, and the rule that every exception is time-boxed and recorded.

8. Enforcement. What happens on violation, up to termination. Stated once, calmly.

9. Review and approval. Reviewed at least annually and on material change; version history kept; signature: [Name, CEO], [date].

How auditors test an information security policy

Four kinds of evidence — and the policy text itself is the least of them.

Approval records: a dated sign-off from the executive owner (and the board, where governance requires it) covering the current version — not one from three revisions ago.
Employee acknowledgment: every active employee has acknowledged the current version, including the engineer who started three weeks ago. Auditors sample the acknowledgment log against the HR roster.
Review evidence: proof the annual review happened — version history, a review ticket, meeting notes. A policy last touched in 2023 answers the question by itself.
Practice matching the text: the sharpest test. If the policy promises annual training or quarterly access checks, the auditor samples for exactly that. Every sentence in the ISP is a claim they’re entitled to verify.
Distribution: employees can actually find the current version and know they’re expected to follow it. A policy nobody can locate is treated as a policy that doesn’t exist.

Approval, review cadence, and why template policies fail

Approval belongs at the top — the CEO at most startups, the CISO once one exists, with board visibility as you grow. That isn’t ceremony: frameworks test whether leadership owns security, and the signature on the ISP is the first exhibit. Delegating approval to a compliance analyst signals exactly the wrong thing.

Review at least annually, and immediately after material change: an acquisition, a new product line, a serious incident, a major architecture shift. The review can be short; it just has to be real and leave a record.

Now the trap. Buying a template, find-and-replacing the company name, and shipping forty pages of someone else’s commitments is how policies fail audits — because auditors treat the text as a promise and test against it. A policy that pledges controls you don’t operate is worse than a modest one you do. Templates are fine scaffolding; the work is deleting every statement you can’t evidence before you adopt it. Keeping written policy and lived practice aligned is the standing problem policy and access management exists to solve.

How Agency handles information security policies

For companies on managed compliance, Agency drafts the ISP and its sub-policies to match how the company actually operates — then keeps them matched: each policy mapped to controls in the GRC platform, acknowledgments tracked to the roster, the annual review run without anyone needing to remember it. The document is the artifact; the service is keeping it true.

Heading toward a first audit? See where the ISP sits in the bigger picture in the SOC 2 framework overview and the ISO 27001 overview — the two frameworks that lean on it hardest.

Frequently asked questions

Is an information security policy required for SOC 2 and ISO 27001?

ISO 27001 requires one explicitly — clause 5.2 assigns it to top management by name. SOC 2 doesn’t prescribe documents, but auditors expect an ISP as core evidence of the control environment, and its absence is an immediate red flag. HIPAA’s administrative safeguards likewise assume documented policies. In practice: yes, for all of them.

How long should an information security policy be?

Three to six pages. It’s a governance document, not an operations manual — scope, objectives, accountability, durable commitments, and pointers to the sub-policies. If it’s pushing twenty pages, operational detail has leaked in, and that detail will go stale faster than anyone re-approves it.

Can we start from a template?

Yes — nearly everyone does, and GRC platforms ship reasonable ones. The failure mode isn’t the template; it’s adopting its commitments wholesale. Read every policy statement and ask whether you do that today. Rewrite or delete anything you can’t evidence, then adopt what remains.

Who should sign the information security policy?

The most senior person genuinely accountable for security — typically the CEO at an early-stage company, the CISO once the role exists. Auditors read the signature as evidence of management commitment, so it should be someone who could discuss the policy in an interview, not merely someone with signing authority.

How often do employees need to acknowledge the policy?

At hire, after any material revision, and — by common convention — annually, usually bundled with security training. Auditors sample the acknowledgment log against the current HR roster, so one unacknowledged new hire can become a finding. That’s why tracking acknowledgments by spreadsheet eventually breaks.

Keep going

SOC 2 HIPAA Policy & Access User Access Reviews Glossary: Evidence Collection

Policies you can operate, not just print

Agency writes the policy suite to match how your company actually runs — then keeps paper and practice aligned through every audit cycle. Top-ranked Vanta & Drata partner · 1,000+ companies served since 2021 · 4.9/5 on G2.