The information security policy, explained (with outline)

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.

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.

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.

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.