ISO 27001:2022 folded its development and operational change requirements into a cleaner control set, but the audit method didn't change: certification and surveillance auditors sample real releases and trace each one backward through the change control chain. For software teams, that makes the standard's change control clause a per-release evidence obligation — and the difference between an easy surveillance visit and a findings letter is usually not the process, it's whether the records connect.
This guide details exactly what change control evidence ISO 27001 expects at the release level, how the 2022 revision's consolidated controls are audited in practice, and the automation pattern that keeps a fast-shipping team permanently sample-ready.
The trace runs in five links. The change record: what changed, why, which systems — with risk classification appropriate to your process. Security consideration: evidence someone assessed the change's security implications; for higher-risk classes, a recorded review. Authorization: the approval, carrying approver identity and role, timestamped before the deployment it authorizes. Testing: results proportionate to risk — functional plus security checks — referencing the change. Implementation: the deployment record with outcome and rollback handling. Auditors weight the links over the artifacts: five records that don't reference each other are five exceptions waiting to be written.
Modern delivery velocity creates three chronic gaps. Approval informality: merge-request LGTMs and Slack threads authorize socially but not evidentially — no role, no artifact binding. Retention mismatch: a certification cycle spans three years of surveillance; CI logs holding test evidence rotate quarterly. Population drift: feature flags, config changes, and hotfixes ship outside the "official" change process, so the auditor's deployment-derived population doesn't reconcile with your change records — and unexplained deltas are findings even when the changes themselves were fine.
The fix is capture-at-source, structurally linked. Anchor every production change to a structured change request carrying system references and risk class — this defines the population you control. Execute authorization as approval policy: the workflow enforces who must approve which class and records identity, role, and timestamp against the artifact. Bind test executions and deployment events automatically into durable storage. Route emergency changes through a governed fast path with mandatory retrospective review. Then let the Release Compliance Dossier assemble each release's chain, with compliance objectives tracking control coverage across the cycle — the measured-and-improving posture the management system clauses require.
Between audits, run the auditor's method quarterly: sample three releases, produce each chain, time it, and reconcile the deployment population against change records. Document standing exceptions (flag flips, config classes) as policy so they're categories, not surprises. Check approval timestamps against deployment timestamps — the cheapest finding to prevent. Teams that institutionalize this drill report surveillance visits shrinking to hours, because the auditor's sample hits pre-assembled records every time.
ISO 27001 change control at the release level is evidenced as a chain — change, consideration, approval, test, deployment — and audited by pulling on it. Capture the links structurally as releases ship and certification becomes maintenance; leave them scattered and every surveillance cycle rediscovers the same gaps at a worse time.
A five-link chain: the change record with risk classification, evidence of security consideration, authorization with approver identity and role before deployment, proportionate test results including security checks, and the implementation record with rollback handling.
Approval informality (merge-request LGTMs and chat threads that bind to no artifact), retention mismatch (CI logs expiring mid-certification-cycle), and population drift (flags, config changes, and hotfixes shipping outside the change process).
Through a governed fast path: compressed approval recorded like any other change plus mandatory retrospective review. The chain is the same — only the timeline compresses. Undocumented emergency paths are among the most common surveillance findings.
Structured change requests define the population, approval policies enforce and record authorization, test and deployment evidence binds automatically with durable retention, and the Release Compliance Dossier assembles each release's chain on demand.