ISO 27001:2022 Annex A 8.32 change management: audit-ready, no CAB

The auditor picks a production deployment from last quarter and asks who approved it. The honest answer is the engineer who wrote it, in a ticket raised after release. That is the finding waiting inside ISO 27001:2022 Annex A 8.32 change management. A weekly Change Advisory Board is not how a 50-person engineering team avoids it.

This guide shows the lighter route: a three-lane change policy, peer review enforced by branch protection, and a CI/CD pipeline that produces the change record as it runs. It is written for CTOs, heads of engineering and security managers at 25–250 person firms who need to pass the audit sample without slowing releases.

What does the ISO 27001:2022 Annex A 8.32 change management control require?

ISO/IEC 27001:2022 Annex A control 8.32 change management requires that changes to systems and infrastructure are assessed, authorised, tested and recorded, with an agreed rollback path. A.8.32 is a preventive technological control protecting confidentiality, integrity and availability, and it turns Clause 8.1's planned-change requirement into daily engineering practice.

The control asks for a discipline, not a document. Every change follows the same route:

• Assess the impact, with dependencies in mind.
• Authorise the change before anyone executes it.
• Test it in an environment separate from production, using the outputs of A.8.29 (security testing in development and acceptance) and A.8.31 (separation of development, test and production environments).
• Communicate it to the people it affects.
• Deploy it with a rollback path ready.
• Record what happened and when.

The aftermath is part of the control as well. Run-books, diagrams and continuity plans must be updated so they still describe the platform you operate today.

Its preventive purpose explains the design. Most outages, and a healthy share of breaches, trace back to a modification made without assessment, testing or a way back. A misconfigured firewall rule exposes data, an untested change corrupts it, and a failed deployment takes the service down. Availability is the most common failure of the three.

Clause 8.1 requires planned control of change across the management system. A.8.32 is where that sentence becomes a pull request, a reviewer and a timestamp. The NIST SP 800-128 guide for security-focused configuration management sets the same goal: manage and monitor configurations for adequate security, while supporting the services the business runs.

What changed in ISO 27001 Annex A 8.32 in the 2022 edition?

ISO/IEC 27001:2022 Annex A 8.32 change management control consolidates 2013-era change controls, including A.12.1.2 and A.14.2.2, into one technological control spanning applications, infrastructure and everything between. One change discipline now covers operations and development, instead of separate procedures for each, so teams where builders also run production maintain a single process.

The 2013 edition spread change handling across four controls. A.12.1.2 sat with operations. A.14.2.2, A.14.2.3 and A.14.2.4 sat with system development, covering change procedures, application review after platform changes and limits on changing software packages. That split invited two procedures and two sets of records.

The 2022 wording closes that gap. A database parameter change, a Terraform merge and a code release now share one lane structure and one evidence trail.

If your Statement of Applicability or internal procedures still cite the 2013 numbering, map them to A.8.32 and retire the duplicates. A single change policy gives the auditor one place to start and gives your engineers one process to follow.

Does ISO 27001 change management need a Change Advisory Board?

No. At 25–250 people, a defined approver satisfies the standard: a second engineer's review, a lead, or the CTO for high-risk changes. A Change Advisory Board adds meetings, not assurance, and breeds bypass. Segregation of duties enforced through peer review and branch protection gives auditors a stronger trail than committee minutes.

The tension is structural. The engineers who build the product also run production, and the pull towards "just push it" never goes away.

The bill arrives as the Friday-evening deployment that takes the platform down with no rollback plan. Or it is the firewall tweak that quietly exposed an admin interface for six weeks. Regulated clients feel it commercially, because UK regulators' operational-resilience expectations and enterprise customers' change-freeze and notification clauses both assume you can show controlled change.

Auditors know this too. Change is one of the most heavily sampled controls: every certification cycle, the auditor picks real changes and walks the trail.

What replaces the board is small and enforceable:

• A named approver per risk tier: a second engineer for routine work, a lead or the CTO for high-risk changes.
• Segregation enforced in tooling: repository permissions that stop an author merging their own pull request.
• The record in your existing tracker: the ticket or pull request, not meeting minutes.

Two failures recur when firms skip this. The first is importing an enterprise CAB with weekly meetings into a 40-person firm, which guarantees the process gets bypassed. The second is one engineer acting as author, approver and deployer of the same change. That is invisible day to day and obvious in an audit sample.

A committee also approves what it can see, which is usually a summary. A peer who read the diff gives better assurance than a board that read the title.

How do you write an ISO 27001 change management policy with three lanes?

Write a short policy defining three lanes: standard for pre-approved, low-risk, repeatable changes such as dependency bumps; normal for changes assessed and approved before execution; and emergency for act-now changes documented and reviewed within a defined window. Most audit pain comes from one heavyweight lane that everyone routes around.

Our guidance for a 50-person regulated firm is a policy short enough to read in one sitting, with five parts:

• Lane definitions, each with named examples, such as dependency bumps and routine patches for the standard lane.
• An approver for each lane and risk tier, plus a rule that authors never approve their own production change.
• The emergency window inside which retrospective review must happen.
• A record template held in Jira, Linear or a GitHub pull request template.
• An owner who checks the policy against the deployment history.

The standard lane is what keeps engineers on side. Pre-approve categories of low-risk, well-understood change and spend your process on changes that can hurt you. Not every small change needs its own ticket.

Policy plus pipeline wiring takes one to two weeks. The ongoing effort lies in running the emergency lane and keeping documentation current.

What must a change record contain, and what gets updated at close-out?

A change record needs what and why, impact and dependency assessment, approver, test evidence, rollback plan and timestamps, held in the Jira, Linear or GitHub tracker you already use. Close-out then updates run-books, diagrams, asset records and continuity plans the change made stale, so documentation keeps describing reality.

A change record is a template, not a new system. Each field proves one thing:

• What and why: the change and its reason, in a sentence an auditor can follow.
• Impact and dependencies: the systems, customers and upstream services affected.
• Approver: a named person who is not the author.
• Test evidence: a link to the CI run or test result, from an environment separate from production.
• Rollback plan: the way back, written before deployment.
• Timestamps: when approval was given and when the change executed.

Timestamps do more work than any other field. Approval must precede execution, and the auditor compares the two.

An approval logged after the deployment is a diary entry, not a control.

Write the rollback answer even when it is "redeploy the previous version", because saying it in the record forces the thought. For risky changes such as data migrations, also note the point past which rollback stops being possible. Material changes need telling too. Send maintenance windows and major changes to affected teams and, where contracts require it, to customers. Keep the notice with the record.

Version control underpins all of this. The NCSC technology assurance guidance on managing change effectively says configuration items should be version controlled, with the author, time and date of each change recorded. That record is what makes root cause analysis possible when defects appear.

Close-out is the step most teams skip. Before the ticket closes, update the run-books, architecture diagrams, asset records and continuity or recovery plans that the change made stale. Left alone, the CMDB and disaster-recovery plans end up describing the platform of eighteen months ago. Run a short post-implementation review on any failed or high-impact change.

How should emergency changes work under A.8.32?

Act first, then document. A defined emergency lane lets engineers deploy a break-glass fix immediately, then requires a retrospective review inside a window your policy sets. Auditors do not fail emergency change; they fail emergency change with no record and no review, which is why the follow-up should be automatic.

A workable break-glass path runs in four steps:

1. Declare it. The engineer marks the change as an emergency and names who authorised it.
2. Fix it. Deploy through the pipeline where possible, using a permitted fast path.
3. Record it. Capture what changed, who made the change and when, the same working day.
4. Review it inside the policy window: why the normal lane could not be used, whether the fix holds and which documents need updating.

Choose a window you can actually meet, such as the next working day. A window nobody meets is worse than none, because it creates a trail of overdue reviews.

Auditors like emergency records. They show the process working under pressure, which a flawless run of routine changes cannot prove. Expect the sample to include one, so keep a reviewed emergency change ready.

The failure mode is the undocumented hotfix culture. Real changes flow through Slack and SSH while the formal process handles only the ceremonial ones. Auditors compare deployment logs against change records to catch exactly this, and every unmatched deployment is a question you will have to answer.

How does your CI/CD pipeline become the change record?

Branch protection, mandatory review and CI gates turn every merge into a change record: approval, test evidence and deployment timestamps become a queryable trail, and the audit sample is a filtered list of merged pull requests. Infrastructure follows the same path through IaC pull requests, with a policy naming the pipeline as the mechanism.

Four pieces of configuration do most of the work:

• Self-approval blocked at repository level. Repository and deployment permissions make a solo merge technically impossible, rather than procedurally discouraged.
• Emergency changes that tag themselves. The tooling labels a break-glass deploy and opens the retrospective-review ticket with a deadline, closing the gap where emergency changes usually vanish.
• Drift detection. Comparing infrastructure-as-code against live configuration surfaces changes made outside the pipeline.
• Documentation triggers. Material changes automatically open tasks to update run-books and continuity plans.

Pulling the sample is then a single filter: merged pull requests to the production branch within the audit period. Each result already carries its reviewer, CI results and merge time, so nobody rebuilds the trail by hand.

Infrastructure needs the same treatment as application code. Firewall rules, IAM permissions and network configuration belong in IaC repositories. A change to them is then a pull request with a reviewer, not a console session nobody recorded. Console access stays available for emergencies, but it falls under the emergency lane and the drift check.

Check administrator bypass settings before the auditor does. If admins can merge past the rule, the control has an exception, and sampling finds exceptions.

Then name the mechanism in the policy, in one sentence. For example: production changes are made only through the version-controlled pipeline, and approval is the required review on the protected branch.

A policy that no pipeline enforces is a suggestion.

At this scale, the setup answers the auditor and the enterprise customer's change-control questionnaire from the same export. Engineers keep shipping through the workflow they already use.

What do auditors sample for A.8.32, and where do teams fail?

Auditors pick real production changes from your deployment history across all lanes, including at least one emergency change, and check each for approval before execution and test evidence. A single missing record or late approval grades minor; recurring retrospective approvals aggregate to major, and no change discipline at all grades major.

Expect questions like these in the room:

• "Pick a recent production change and walk me through it, from request to record."
• "Who approved this change, and can the person who wrote it approve it alone?"
• "Show me an emergency change and its after-the-fact review."
• "What was the rollback plan here, and has one ever been executed?"
• "Does this architecture diagram reflect the platform after the last migration?"

The auditor will ask the pipeline, not the policy. They take the deployment history, pick changes across the lanes, then check whether documentation and continuity plans caught up with the large ones. Stale run-books grade minor too, so a clean ticket trail with an out-of-date diagram still earns a finding.

Three findings recur across samples:

• Self-approval: the author-approver-deployer pattern from the CAB section.
• Retrospective approval: approval timestamps later than deployment times.
• Testing in production: staging missing or unrepresentative, so change control and A.8.31 fail together.

A rollback plan nobody has rehearsed is a hope, not a plan.

The question "has one ever been executed?" is easy to answer in advance. Rehearse a rollback in staging for your riskiest change types and keep the output. Finding out mid-incident that it fails is the expensive way to learn.

Run the sample yourself first. Pick a handful of merged changes per lane from the last quarter, plus every emergency change. Walk each one: approval before execution, test evidence, rollback answer, documentation updated. A pipeline-backed trail passes that walk without a scramble.

Frequently asked questions