R ritvik.singh/portfolio
~/portfolio/ blog/ iso-policy
// grc 2026.02.02·7 min read

Writing ISO 27001 policies that engineers actually read.

Compliance documents read like legal walls. A field guide to rewriting 14 client policies into single-page mappings between control IDs and on-call playbooks.

The compliance wall problem

ISO/IEC 27001:2022 Annex A has 93 controls across 4 themes. Most organisations implement them by producing Word documents that nobody reads after the audit cycle ends. The documents exist to satisfy the auditor, not to change behaviour.

The problem shows up during incidents. An engineer faces an anomalous event at 2 AM and tries to find the incident response policy. They find a 40-page document written in passive voice. They close it and do what seems right. The policy failed the only test that matters.

What the standard actually requires

ISO 27001 requires documented policies, evidence of implementation, and evidence of review. It does not specify format, length, or reading level. The auditor checks that the control is addressed, that someone owns it, and that there's evidence it's followed. A one-page policy that gets referenced in real incidents satisfies this better than a 40-page document that doesn't.

The test: Can a new engineer, on their first week, find the policy they need in under 2 minutes and take the correct action? If not, the policy has failed regardless of what the auditor said.

The rewrite approach

For each of the 14 policies, I used a three-column structure:

  1. Control ID + what it means in plain English — one sentence. No references to the standard's own language.
  2. What we do — the specific tool, process, or configuration that implements this control. Named systems, not categories.
  3. What you do if it breaks — a numbered runbook. Who to call, what to check, where to log it.

Before and after: A.9.1.1 — Access Control Policy

// before

"An access control policy shall be established, documented, and reviewed based on business and information security requirements. Asset owners shall take account of the access control policy when granting access rights to assets."

// after

A.9.1.1 — Who can access what.
We use role-based access in Okta. No user gets rights not tied to their role. New accounts: raise a ticket in Jira → manager approval → IT provisions within 24h. Stale accounts: automated 90-day disable in Okta. Violation? Disable account → log in the SIEM → notify team lead.

The template that worked

Every rewritten policy follows this skeleton. The heading is the control ID plus a human-readable label. The body is never longer than one page.

// policy template
## A.X.X — [Control Name in plain English] # what this is: one sentence ### What we use [Tool / process / config] — specific, named, version if relevant ### Normal operation Step-by-step: who does what, where it's logged ### If something goes wrong 1. Immediate action 2. Who to notify (name, not title) 3. Where to log the incident ### Review Owner: [name] · Review: annually · Last updated: [date]

14 policies: what changed

  • Access control (A.9.x) — linked directly to Okta group configuration; IR steps reference specific ticket queues
  • Incident response (A.16.x) — replaced generic phases with actual tooling: Wazuh alert → Jira ticket → Slack channel → post-mortem template
  • Data classification (A.8.2) — reduced to a 4-tier table with examples per tier; no prose
  • Change management (A.12.1.2) — mapped to existing GitLab merge request workflow, not a separate process
  • Supplier relations (A.15.x) — one-page vendor risk checklist replacing a 20-page document

The auditor approved all 14 without revision requests. More importantly, three months later, the IR policy was referenced correctly during an actual incident. That's the only metric that matters.

← wazuh tuning next: dlp playbook →