Policy vs Procedure vs Standard
Three document types, three altitudes. A policy states intent and accountability: what must be true and who owns it (“all production access requires MFA; the CTO owns exceptions”). A standard sets the measurable bar: how much (“TLS 1.2+; AES-256 at rest; quarterly access reviews”). A procedure is the runbook: exactly how (“to offboard an employee: step 1…”).
Why the distinction is practical, not pedantic
Documents rot at different speeds. Policies should survive years; standards change with technology; procedures change with every tooling migration. Mix them — a policy that names specific software, a procedure buried in a policy — and every tool change forces a re-approval cycle through executives who shouldn’t need to care. Separate them and each layer updates at its own cadence with its own approver.
What auditors read for
Consistency across the altitudes: the policy promises quarterly reviews, the standard defines the quarters, the procedure exists and matches, and the evidence shows it ran. The classic finding lives in the gaps — a policy promising what no procedure implements, or a procedure that quietly diverged from the standard years ago.
The startup version
You don’t need forty documents. Twelve policies (the SOC 2 set), one security standards page, and runbooks where operations actually happen (your wiki, your platform). Keep the altitudes clean and short; auditors reward documents that are obviously true over documents that are impressively long.
ISMS — An ISMS is the management system ISO 27001 certifies — the loop of risk assessment, controls, internal audit, and review that runs your security program.
Incident Response Plan — An incident response plan defines how you detect, triage, contain, and learn from security incidents — with the records SOC 2 auditors and regulators sample.