ISO 27001 A.8.32: Change Management

To satisfy ISO 27001 A.8.32, put every change to production systems, applications, and infrastructure through one documented path: a request, a risk and impact assessment, testing, and an approval by someone other than the person who made the change. The action teams get flagged on is segregation of duties: the author and the approver cannot be the same person, and when the team is too small for that, the compensating review has to be written down.

A.8.32 is a Technological control in Annex A of ISO/IEC 27001:2022. It maps fully to SOC 2 CC8.1, so a team already running SOC 2 change management has most of the evidence an ISO 27001 auditor will ask for.

What is ISO 27001 A.8.32?

ISO 27001 A.8.32, titled Change management, requires that changes to information processing facilities and information systems be subject to change management procedures. The intent, as expressed in ISO/IEC 27001:2022, Annex A, is that changes are planned, assessed for their security impact, tested, approved, and documented before they reach production, so that a change does not become the event that breaks security or availability.

The control is deliberately broad. It covers application code, operating systems, network configuration, and the infrastructure that hosts them. It does not prescribe a specific ticketing tool, branching model, or approval chain. What it expects is that changes follow a defined process, that the process assesses security consequences before a change ships, and that a team can show the assessment, the test result, and the approval after the fact. A one-person shop with a documented review cadence can satisfy A.8.32; a large team pushing unreviewed changes to production cannot.

How do you implement A.8.32?

Run every production change through a single, documented sequence, regardless of whether the environment is cloud or on-prem. The governance actions below are the same in both:

1. Raise a change request. Every change starts as a record: a ticket, a pull request, or a change entry that states what is changing, why, and which systems it touches. Unplanned work gets a record too, even if it is opened after the fact for an emergency fix.
2. Assess risk and security impact. Before work proceeds, evaluate what the change could break, what it exposes, and what rollback would cost. High-impact changes (schema migrations, network rule changes, authentication changes) get more scrutiny than routine dependency bumps. Tag material, security-relevant changes so they are easy to separate from low-risk ones later.
3. Test in a non-production environment. Prove the change behaves as intended before it reaches production. Automated tests, security scans, and a check in a staging environment that mirrors production are the usual evidence.
4. Require approval by a second person. Someone other than the author reviews and approves the change. This is the segregation-of-duties action A.8.32 leans on hardest: the person who writes the change is not the person who signs off on it.
5. Keep a rollback plan. Each significant change records how to reverse it, and the team confirms the rollback path works rather than assuming it does.
6. Document the outcome. The approved request, the test result, the approval, and the deployment record are retained together so the change is reconstructable months later.

In cloud environments

In cloud environments, the change pipeline enforces most of A.8.32 mechanically. Changes are raised as pull requests in source control (GitHub pull requests, for example); branch protection blocks a merge until a second reviewer approves and required status checks (automated tests, SAST, SCA, secret detection) pass. Infrastructure changes go through the same review because infrastructure is defined as code: a Terraform or Ansible change is a reviewed, version-controlled pull request rather than a console click. The CI/CD system deploys on merge and writes a deployment log. Those pull requests, their approvals, the passing checks, and the deploy logs are the evidence, produced as a byproduct of how the team already delivers changes. Wiring compliance evidence into the pipeline this way is the core of GRC engineering. One caution on infrastructure as code: provisioning is a point-in-time event, so a periodic check that running state has not drifted from the code is what carries the story from a Type 1 snapshot to ongoing assurance.

On-prem / self-hosted

On-prem and self-hosted environments enforce A.8.32 through change tickets and scheduled windows rather than a merge gate. A change ticket in the service management tool (Jira, for example) carries the request, the impact assessment, and the approval; a change advisory board or a named approver signs off on higher-risk changes before they are scheduled. Changes are applied during a defined maintenance window, with the rollback plan attached to the ticket and the implementation result recorded against it. The approval and segregation of duties are the same as in cloud; the mechanics are the ticket, the board, and the window instead of the pull request and the pipeline.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.32?

Auditors evaluating A.8.32 look for a consistent trail from request to approved deployment across the audit period.

How does A.8.32 map to SOC 2?

A team with SOC 2 CC8.1 in place has already built the change process A.8.32 asks for, and the same change tickets, approvals, and test records go into both audit packages. The SOC 2 to ISO 27001 control mapping covers the full crosswalk and what transfers between the two frameworks.

Related controls

A.8.32 governs how a change moves to production; the controls around it govern where it is built and what else the change process touches. A.8.31 (separation of development, test and production environments) gives the change process the non-production environments it tests in, and A.8.19 (installation of software on operational systems) constrains what can be installed once a change is approved. A.8.9 (configuration management) defines the baseline a change moves away from and back to, and A.5.8 (information security in project management) pushes security assessment upstream into how changes are planned. The technological controls overview summarizes how the A.8 controls fit together.

Part of Truvo's control-by-control ISO 27001 reference series. This post is part of the ISO 27001 certification guide. If you are building or tightening a change management process as part of an effective security program and want a second set of eyes on the control design, Truvo runs scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.32?

ISO 27001 A.8.32 is the change management control in Annex A of ISO/IEC 27001:2022. It requires that changes to information systems and processing facilities follow a documented process: a change request, a security impact assessment, testing, approval by a second person, and a retained record of the change.

What evidence satisfies A.8.32?

Typical A.8.32 evidence includes change tickets or pull requests showing approvals, test records from a non-production environment, deployment logs, an emergency-change log with retrospective approvals, and rollback records for significant changes. The same artifacts satisfy SOC 2 CC8.1.

Does A.8.32 require segregation of duties between author and approver?

Yes, in practice. A.8.32 expects changes to be approved before they reach production, and an approval by the same person who made the change is not independent review. On teams too small for real-time peer review, a documented compensating control, such as a quarterly retrospective review of tagged security-relevant changes, can satisfy the intent.

How do you handle emergency changes under A.8.32?

Emergency changes still get a record and a review, applied after the fact. The change is implemented to resolve the incident, then logged, assessed, and approved retrospectively so the emergency path does not become an unreviewed backdoor around the normal process.

Does A.8.32 apply to infrastructure changes?

Yes. A.8.32 covers infrastructure and network changes as well as application code. In cloud environments, infrastructure defined as code moves through the same reviewed pull request and pipeline as application changes, and a periodic drift check confirms running state still matches the approved configuration.

How does A.8.32 map to SOC 2 CC8.1?

A.8.32 maps fully to SOC 2 CC8.1. Both require that changes be authorized, tested, approved, and documented before implementation. Change approval records, pull request templates with required reviews, test-environment evidence, and the change management policy serve both frameworks without adaptation.