ISO 27001

Vault note, not reviewed against the source. Written in the knowledge vault on 2026-05-12 by models working with Stefan Coetzee and published as it stands, with private addresses, e-mail addresses and an employer name redacted. Check claims against the primary source before relying on them.

Map of ISO/IEC 27001:2022 as the international standard for information security management systems (ISMS), and the wider ISO/IEC 27000 family. Per-clause atoms for the mandatory management clauses (Cl 4-10), per-theme atoms for the 93 Annex A controls (Organizational, People, Physical, Technological), and cross-cutting atoms on certification, sector variants, version history, and contested points. Reference cluster for SRE work, AI-agent system compliance, supplier-agent risk, and any work where C-I-A claims must be auditable.

Anchors

  • position: current view, dated, revisable
  • anchors: primary documents, certification bodies, named practitioners

Provenance

  • BS 7799-1:1995 — UK Department of Trade and Industry code of practice for InfoSec management. First widely-adopted control catalog.
  • BS 7799-2:1999, revised 2002 — added the management-system specification side (the auditable "shall" requirements). Predecessor to ISO 27001.
  • ISO/IEC 27001:2005 — first ISO version. Adopted BS 7799-2 with edits. Plan-Do-Check-Act (PDCA) lifecycle baked into the clause structure.
  • ISO/IEC 27001:2013 — restructured to Annex SL high-level structure shared with ISO 9001 and ISO 14001. Dropped explicit PDCA. 114 Annex A controls in 14 control categories (A.5 through A.18).
  • ISO/IEC 27001:2022 — published 25 October 2022. Annex A restructured per ISO/IEC 27002:2022 (published February 2022) into 93 controls in 4 themes. New controls for threat intelligence, cloud, ICT readiness for business continuity, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, secure coding.
  • Transition deadline to :2022 from :2013 was 31 October 2025. As of 2026-05-12 the transition window has closed; new certificates must be against :2022.

What changed structurally from :2013 to :2022

  • Annex A control count 114 → 93. Eleven new controls. Fifty-seven merged into 24. One split into two.
  • Four themes replace fourteen categories. Annex A.5 Organizational (37), A.6 People (8), A.7 Physical (14), A.8 Technological (34).
  • Five attribute axes added to every control in ISO/IEC 27002:2022 for filtering and reporting: control type (preventive / detective / corrective), information security properties (confidentiality / integrity / availability), cybersecurity concepts (identify / protect / detect / respond / recover, aligned with NIST CSF), operational capabilities (governance, asset management, ...), security domains (governance and ecosystem / protection / defense / resilience).
  • Title change. "Information technology — Security techniques — Information security management systems — Requirements" → "Information security, cybersecurity and privacy protection — Information security management systems — Requirements." Reflects scope creep into privacy and broader cyber.
  • Clause numbering preserved. Cl 4-10 mandatory structure unchanged. Minor editorial wording shifts only.
  • Planning of changes (Cl 6.3) added — formerly only implied by 8.1 operational planning.

Mandatory clauses (Cl 4-10)

Clauses 1-3 (Scope, Normative references, Terms and definitions) are introductory and not directly auditable. The auditable "shall" requirements live in 4-10.

Annex A control themes

Annex A is a reference list. Statement of Applicability (SoA, required by Cl 6.1.3.d) records which controls apply, which do not, and why. Tailoring is permitted; the SoA is the audit artefact.

Cross-cutting sub-atoms

  • ISO 27001 Certification Process: scoping, gap analysis, Stage 1 vs Stage 2 audit, surveillance audits, three-year recertification cycle, accreditation bodies (UKAS, DAkkS, ANAB), certification bodies (BSI, DNV, TÜV SÜD, LRQA, SGS).
  • ISO 27001 Family and Sector Variants: 27002 controls guidance, 27003 implementation, 27004 measurement, 27005 risk, 27017 cloud, 27018 PII processor, 27019 energy utility, 27701 privacy (PIMS), 27031 BC for ICT, 27034 application security, 27035 incident management, 27036 supplier relationships.
  • ISO 27001 Version History: BS 7799 → :2005 → :2013 → :2022 evolution, control-count and structure changes, transition timelines, the Annex SL adoption.
  • ISO 27001 Controversies: checkbox compliance vs real security, SoA scope-narrowing, certification-body shopping, audit kappa variance, the "we passed the audit, then we got breached" pattern, AI-system fit gaps.

ISO 27001 vs adjacent frameworks

  • NIST CSF (2.0, 2024) — voluntary, US-origin, function-organized (Govern, Identify, Protect, Detect, Respond, Recover). ISO 27001 is certifiable; NIST CSF is not. ISO 27001 emphasizes the management system; NIST CSF emphasizes outcomes. ISO 27002:2022 cyberproperties axis aligns with NIST CSF functions.
  • SOC 2 (AICPA) — US-origin, attestation (not certification), trust services criteria (security, availability, processing integrity, confidentiality, privacy). Type 1 = point-in-time, Type 2 = period (typically 6-12 months). SOC 2 and ISO 27001 overlap heavily; many orgs run both.
  • Cyber Essentials (UK NCSC) — five-control baseline, self-assessment (Cyber Essentials) or external audit (Cyber Essentials Plus). Much narrower than ISO 27001. Common UK government supplier requirement.
  • GDPR (EU 2016/679) — privacy regulation, not security framework. ISO 27001 with 27701 extension (PIMS) provides defensible technical-and-organisational-measures evidence.
  • PCI DSS (4.0, 2022) — prescriptive payment-card standard. ISO 27001 is generic; PCI DSS is specific. Both are commonly required of payment processors.
  • CIS Critical Security Controls (v8, 2021) — prioritized control list, prescriptive. Useful for technical implementation; ISO 27001 still needed for the management-system side.

Full mapping in ISO 27001 Family and Sector Variants.

Why this matters for SRE and AI-agent work

The standard maps onto operational reality:

  • AI-agent systems (OpenCode, Claude, Hivemind, vault MCP servers) are processing systems under A.5.23 (cloud services), A.8.15 (logging), A.8.16 (monitoring activities), A.8.28 (secure coding), A.8.30 (outsourced development). Self-hosted does not exempt; "outsourced" includes model vendors.
  • Supplier-agent risk maps to A.5.19-A.5.23 (supplier relationships, ICT services, cloud services). Any agent that calls an external API or model is a supplier dependency for ISMS purposes.
  • Headscale / Tailscale topology maps to A.5.14 (information transfer), A.8.20 (network security), A.8.21 (security of network services), A.8.22 (segregation of networks).
  • Beads federation and vault sync map to A.5.12 (classification), A.5.13 (labelling), A.5.14 (transfer), A.8.3 (access restriction), A.8.5 (secure authentication).
  • Incident response maps to A.5.24-A.5.28 (incident management lifecycle). Runbooks (SRE/runbooks/) are evidence artefacts.
  • Toil reduction is not in ISO 27001 directly, but documented procedures (Cl 7.5) and competence (Cl 7.2) are. A team that has to redo work to pass audit is failing both pillars.

ISO 27001 is the management-system frame; ISO 27002:2022 is the controls handbook. Both are needed for implementation. Build the management system around the work the team already does; do not invent process to satisfy clauses.

Stefan-context relevance

Stefan does SRE / staff-engineer-track work touching:

  • Multi-tenant agent infra (OpenCode plugins, Claude Code, MCP servers, federated bd workspaces)
  • Vault-as-knowledge-store with PII separation conventions (whiteout-kb/ vs work-kb/)
  • Self-hosted control plane (headscale on AWS, [host] build host, Mac Studio retrieval router incoming)
  • Customer-facing work where the buyer is procurement-with-ISMS-questions ([employer]-class buyers, mid-market German manufacturers)

The cluster should:

  • Stay implementation-grounded (named clauses, named controls, named evidence artefacts)
  • Connect to existing SRE atoms (runbooks, patterns, pillars/08-security)
  • Make AI-agent system fit gaps explicit (model vendor as supplier, prompt-injection as new threat class, agent-generated audit-log fidelity)
  • Keep the procurement-readiness angle visible (SoA, customer questionnaires, vendor due-diligence packs)

Conventions for this cluster

  • Per-clause atoms named ISO 27001 Clause <n> <Title>.md with consistent structure (scope, sub-clause map, evidence artefacts, audit observations, common gaps, see also).
  • Annex A theme atoms named ISO 27001 Annex A.<n> <Theme> Controls.md with one section per control, mapped to attributes (type, CIA, NIST CSF function).
  • Cross-cutting atoms named with the ISO 27001 prefix for collision safety.
  • All atoms cite the relevant clause or control number explicitly. Quote "shall" requirements verbatim where load-bearing.
  • Practical evidence examples drawn from this vault and from real SRE / AI-agent work where possible. No invented case studies.

See also

ISO 27001 Cluster (pillars MOC) · position · anchors · CLAUDE · Home