Control template: ISO/IEC 27001:2022

Status: Stable · Version: iso-27001-2022/v1.0.0

A bundle of CALM control snippets covering the architecturally enforceable subset of ISO/IEC 27001:2022 and the related ISO/IEC 27002:2022 Annex A controls. You copy these into your *.calm.json files on the nodes within your Information Security Management System (ISMS) scope.

Who ISO 27001 applies to

Voluntary international standard widely required for: - Enterprise procurement — many large customers require ISO 27001 certification from SaaS / cloud / service providers - International deals — ISO 27001 is the global counterpart to SOC 2 (US-centric); many EU / APAC procurement teams require it - Government tenders — common requirement for IT services to public-sector buyers - B2B SaaS — increasingly table stakes alongside SOC 2

The certification is voluntary but commercially essential in many segments. Certificates are issued by accredited bodies (BSI, DNV, Bureau Veritas, TÜV, etc.) and typically valid for 3 years with annual surveillance audits.

What this template covers

ISO 27001:2022 has 10 clauses (4–10 are auditable Plan-Do-Check-Act requirements) plus Annex A (93 controls across 4 themes). The architectural surface concentrates in Annex A.8 Technological Controls.

3 architectural controls covering the most-tested A.8 surfaces plus A.5.15 access control. The full ISMS — clauses 4–10 (context, leadership, planning, support, operation, performance evaluation, improvement) — is governance + process, not architectural. Document those in your ISMS documentation.

The "ISMS-in-scope" pattern

A node is ISMS-in-scope if it's covered by your ISO 27001 scope statement. Tag those nodes:

{
  "unique-id": "saas-platform",
  "node-type": "service",
  "name": "SaaS Platform",
  "metadata": {
    "iso27001-in-scope": true,
    "iso27001-soa-reference": "SOA-2025-v1.2",
    "data-classification": "confidential"
  }
}

The Statement of Applicability (SoA) records which Annex A controls the firm has selected as applicable, with justifications. This template's controls map to specific A.* references for SoA traceability.

Control snippets

Copy each block under the controls key of the node it applies to.

A.5.15 — Access control (iso27001-access-control)

Per-node.

"iso27001-access-control": {
  "description": "ISO 27001:2022 A.5.15 — access control rules implemented to control physical and logical access to information and other associated assets based on business and information security requirements.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/iso-27001-2022/access-control",
      "config": {
        "control-id": "iso27001-access-control",
        "policy-document-url": "https://internal.example.com/iso27001/access-policy",
        "principle": "least-privilege-plus-need-to-know",
        "allowed-roles": ["read-only", "operator", "admin"],
        "review-frequency": "quarterly"
      }
    }
  ]
}

A.8.5 — Secure authentication (iso27001-secure-authentication)

Per-node.

"iso27001-secure-authentication": {
  "description": "ISO 27001:2022 A.8.5 — secure authentication technologies and procedures implemented based on information access restrictions and the topic-specific policy on access control.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/iso-27001-2022/secure-authentication",
      "config": {
        "control-id": "iso27001-secure-authentication",
        "mechanism": "saml-sso-plus-mfa",
        "factor-count": 2,
        "factor-types": ["password", "totp-or-webauthn"],
        "service-to-service": "mtls-or-oauth2-client-credentials"
      }
    }
  ]
}

A.8.24 — Cryptography (iso27001-cryptography)

Per-node.

"iso27001-cryptography": {
  "description": "ISO 27001:2022 A.8.24 — rules for effective use of cryptography, including cryptographic key management, defined and implemented.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/iso-27001-2022/cryptography",
      "config": {
        "control-id": "iso27001-cryptography",
        "at-rest-algorithm": "AES-256-GCM",
        "in-transit-minimum-tls": ["1.2", "1.3"],
        "key-management": "hsm-or-kms-cmk",
        "key-rotation-days": 365,
        "cryptographic-policy-url": "https://internal.example.com/iso27001/crypto-policy"
      }
    }
  ]
}

What the engine actually enforces

There is no ISO 27001-specific cross-cutter — the engine has no "if iso27001-in-scope: true, require these controls" sweep. Enforcement is graph-driven: you attach a control where you want it enforced; the absence of an attach is opt-out by silence.

For the 3 ISO 27001:2022 controls above, here is the enforcement map:

• iso27001-access-control (A.5.15) — the authorization-removal validator fires when a code change strips @PreAuthorize (or equivalent) on a sensitive-classified node.
• iso27001-secure-authentication (A.8.5) — the same authorization validator carries authentication-mechanism intent at code-change time on sensitive nodes.
• iso27001-cryptography (A.8.24) — the architectural weak-crypto validator fires on deprecated algorithm references (MD5, SHA1, DES, RC4 etc.) in code on the sensitive-classified node; relationship-protocol checks fire when a code change adds a plaintext call across an edge declared TLS-carrying.

The other Annex A surfaces (asset inventory, classification, BCDR, training, privileged access, backup, logging, monitoring, secure coding, change management) are governance + process attestations that no current ArchRails validator fires on against a diff. Author them in your ISMS documentation rather than CALM.

All checks are deterministic — pure function over your CALM JSON. The same constraint engine handles PCI DSS, GDPR, SOC 2, HIPAA, NIST CSF 2, MiFID II, NYDFS Part 500, and any controls you author yourself.

Statement of Applicability traceability

Each control's requirement-url contains the A.* reference. When your auditor asks "show me where you implement A.8.5," point at the node(s) attaching iso27001-secure-authentication — the engine's audit log records this directly. Useful for both Stage 1 (documented ISMS review) and Stage 2 (operational effectiveness) audits.

Versioning

This is iso-27001-2022/v1.0.0 — the first stable cut. Each surviving control has per-validator firing tests + cross-language coverage across 11 Tier A languages (Python, Java, C#, TypeScript, Go, Kotlin, Scala, Rust, Ruby, Swift, PHP). Future bumps: v1.x.y for additive controls and substantive validator coverage; v2.0.0 for breaking changes (control retired, semantics changed). Updates as authoritative guidance or enforcement priorities materially shift.

Out of scope for this template

• Clauses 4–10 (the auditable ISMS requirements): context, leadership, planning, support, operation, performance evaluation, improvement. Governance + process; document in your ISMS.
• Statement of Applicability (SoA) — the document itself is procedural; the template references A.* numbers so the SoA can cite "see ArchRails-enforced controls for the technical surface".
• Risk treatment plan — methodology, not architectural.
• Internal audit + management review — ISMS governance activities.
• Annex A.5 organizational controls beyond A.5.15 — most are policy / procedural (information security roles, segregation of duties policy, contact with authorities, etc.).
• A.6.x people controls — HR / training / disciplinary process.
• A.7.x physical controls — facility security, equipment. Not architectural.
• A.8 controls not in this template — there are 34 A.8 controls; we cover the small subset with the strongest code-enforceable surface (authentication, cryptography). Others (network controls, capacity management, redundancy, secure development environments, etc.) can be added as a v0.2.0-beta expansion if customers ask.
• ISO 27017 / 27018 / 27701 — sector-specific (cloud, PII, privacy) extensions of 27001. Separate templates if customers ask.

For those surfaces, pair this template with your ISMS documentation and engage your accredited certification body for the audit.