Control Definition
Changes to information systems and to the facilities that process information must follow defined, documented change management procedures. In practice that means changes are identified, risk- and impact-assessed, approved, tested, communicated, and recorded — with a fall-back plan if they go wrong and a defined route for emergencies.
Control Objective
To preserve the security of information and systems while changes to them are planned and carried out.
What This Really Means
Every incident postmortem opens with the same question: what changed? Change management is the discipline of being able to answer that question before the incident instead of after it. The control is not about slowing engineering down — it is about making sure no change reaches a live system without someone having assessed it, someone having approved it, and a record existing that both happened.
The lifecycle the control expects is straightforward: a change is requested or identified, its risk and impact are assessed (security impact included), someone accountable — not the author — approves it, it is tested before deployment, affected parties are told, it ships with a rollback plan, and the whole thing is recorded and reviewed after implementation. There is also a sanctioned emergency path: when production is down at 2 a.m., you fix first and obtain retrospective approval — but the record still gets made, and the change still gets reviewed.
Two clarifications save teams a lot of grief. First, ISO 27001 does not require a Change Advisory Board, ITIL ceremony, or a ticketing queue — a well-designed pipeline IS change management. A pull request is the change request and the record; mandatory peer review is the authorization; CI tests and a staging deploy are the testing; feature flags and automated rollback are the fall-back; merge and deploy history is the audit trail. What matters is that the gates are defined, technically enforced (branch protection that cannot be bypassed silently), and produce records. Second, the control covers "information processing facilities", not just code: firewall rules, DNS, database schema changes, SaaS configuration, and infrastructure work all count. Many organizations govern code beautifully and leave network changes entirely undocumented.
For auditors, the heart of A.8.32 is the change record. Change records are among the most heavily sampled evidence in the entire certification audit: the auditor pulls real changes from your ticket queue or git history and walks each one through your stated process — where is the assessment, who approved it, what testing ran, what was the rollback plan, and who deployed it.
Why It Matters
Uncontrolled change is the leading cause of self-inflicted outages and a major vulnerability vector. A configuration change that opens a port, a dependency upgrade that pulls in a known CVE, a debug flag left enabled — none of these get a risk look if there is no assessment step. Every unmanaged change quietly converts a stable, assessed system into an unknown one, and the gap between the state you certified and the state you actually run grows with each shortcut.
The change log is also your forensic timeline. When something breaks or is breached, "what changed and when" is the first question incident responders, customers, and regulators ask — and an organization that cannot answer it starts every investigation blind and looks negligent doing so. Change management is additionally the enforcement point for several neighboring controls: configuration baselines (A.8.9) and environment separation (A.8.31) only hold if changes flow through a governed path.
Without working change management, organizations face:
- •Self-inflicted outages – untested or unapproved changes are the most common cause of production downtime, and a missing rollback plan turns a bad deploy into a long one
- •Silently introduced vulnerabilities – a change that weakens TLS settings, exposes a service, or disables logging ships with nobody having assessed the security impact
- •No forensic trail – without change records, incident response cannot reconstruct events, and the absence reads as negligence to regulators and enterprise customers
- •Drift from approved baselines – ad-hoc changes erode the secure configurations you certified against, so the audited state and the real state steadily diverge
- •Heavily sampled audit exposure – auditors pull real changes and check each for assessment, approval, and test evidence; every gap found is a documented nonconformity
Regional Compliance Context
Indian BFSI organizations face explicit regulatory expectations here beyond ISO 27001. RBI master directions for regulated entities expect formal, documented change management over IT systems — including separation between those who develop, approve, and deploy changes — and RBI inspections sample change records much the way certification auditors do. SEBI's CSCRF imposes comparable change and patch management discipline on market intermediaries. Fintechs and IT vendors serving these institutions should expect customer due diligence to request the change management procedure plus sample records, so the evidence you keep for A.8.32 does double duty.
Implementation Guidance
Define and Document the Change Management Procedure
Write down what counts as a change — across applications, infrastructure, networks, and SaaS configuration, not just code — plus the change categories (standard, normal, emergency), the steps each category follows, the roles involved (requester, approver, implementer), and where records live. Keep it to one document owned by engineering or IT operations and approved by management.
Classify Changes and Right-Size the Rigor
Pre-authorize low-risk standard changes — routine dependency bumps, content updates — so they flow with minimal ceremony, and reserve full assessment and approval for normal and major changes. Define explicit triggers for a security review: changes touching authentication, cryptography, network exposure, logging, or personal data. Proportionality is what keeps the process alive.
Build Risk and Impact Assessment Into the Request
Use short, structured prompts at the point of request: systems affected, data touched, security impact, dependencies, and rollback approach. For code changes, embed the prompts in the pull request template; for infrastructure and network work, in the change ticket. An assessment that takes two minutes gets done; a separate form does not.
Enforce Approval Gates Technically
Configure branch protection requiring independent review (the author cannot approve their own change), CODEOWNERS rules on sensitive paths, pipeline approvals for production deployments, and ticket-level approval for network, database, and SaaS changes. The goal is that skipping the process is technically impossible or at least leaves an unmistakable trace.
Test Before Deployment and Keep a Fall-Back Ready
Verify changes in a test or staging environment (A.8.31) with automated test suites and security scans in CI before promotion. For changes where failure matters, require a documented, failure-mode-specific fall-back: backward-compatible database migrations with a tested restore, configuration changes with the previous version captured, releases behind feature flags or blue-green deployment.
Define the Emergency Change Path
Define emergency narrowly — an active incident or imminent harm — and name who can authorize one, what minimum verification applies, and how the change is recorded and retrospectively approved, typically by the next business day. Review every emergency change after the fact, and track the emergency ratio monthly; a rising ratio means the normal path is too slow or being dodged.
Keep Records and Review the Process
Retain change records — tickets, pull requests, deploy logs, emergency records — and sample them in internal audits exactly the way a certification auditor will. Trend the metrics that matter (failed change rate, emergency ratio, rollback frequency) into management review, and update the procedure whenever tooling or team structure changes so it keeps describing reality.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.32:
Documentation
- Change management procedure covering request, assessment, approval, testing, communication, fall-back, and emergency changes
- Sampled change records — tickets or pull requests — showing impact assessment, an approver other than the author, and test evidence
- Deployment or release logs that reconcile against approved changes
- Emergency change records with retrospective approval and post-implementation review notes
- Branch protection and pipeline configuration demonstrating that approval gates are technically enforced
Interviews
- Engineering or IT operations lead on how the change process runs day to day and what happens during an emergency
- A developer or engineer on the last change they shipped: what assessment, review, and testing it went through
- A change approver on what they check before approving and what would make them reject a change
Observations
- Recent production changes sampled from git history or the ticket queue and traced to approval and test evidence
- A live demonstration that an unapproved change cannot reach production — branch protection, pipeline gates, deploy permissions
- A recent failed or rolled-back change examined to confirm the fall-back plan worked as documented
Practitioner Insights
Change records are among the most heavily sampled evidence in a Stage 2 audit. Auditors do not read your procedure and nod — they pull a handful of real production changes and walk each one through the process you claim to follow. The fatal pattern is a procedure describing a change advisory board that has not met in a year while the real changes flow through GitHub. Write the procedure to describe what engineering actually does: if your control is peer-reviewed pull requests plus enforced pipeline gates, say exactly that, and make sure the gates cannot be bypassed without leaving a trace.
Teams worry that ISO 27001 will force ticket-heavy ceremony onto their CI/CD, so they build a shadow process that exists only for the audit — and auditors spot it within minutes because the records look nothing like the deploy history. A pull request with a mandatory independent reviewer, a passing CI run, and a deployment log already is a complete change record. The genuine gap I keep finding in DevOps shops is everything outside the repository: firewall rules, DNS, SaaS admin settings, and hand-run database changes. Extend the same lightweight discipline — a record, an approver, a trail — to those surfaces and the control is whole.
Common Challenges & Solutions
Challenge
Engineers treat change management as bureaucracy and quietly route around it.
Solution
Implement the control inside the tools they already use — pull request templates, required reviews, pipeline approvals — rather than a parallel ticketing ritual. Pre-authorize low-risk standard changes so only genuinely risky work attracts extra steps. Adoption follows when the process costs minutes; resistance follows when it costs days.
Challenge
Half of all deploys get labeled emergencies so they can skip the process.
Solution
Define emergency narrowly — an active incident or imminent harm — and require retrospective approval plus review within a fixed window for every single one. Then report the emergency ratio to engineering leadership monthly. Once the metric is visible and every emergency generates follow-up work, the label stops being a shortcut.
Challenge
Code changes are well controlled, but firewall rules, DNS, SaaS settings, and database changes happen by hand with no trail.
Solution
Inventory every change surface, not just the repository. Bring infrastructure under infrastructure-as-code so it flows through the same pull-request gates; give the rest — network devices, SaaS admin consoles, manual database work — a lightweight ticket-plus-approver path. Turn on audit logging and configuration drift detection in those systems to catch whatever bypasses the process.
Challenge
Approvals are rubber stamps: the same person requests, approves, and deploys the change.
Solution
Enforce author-is-not-approver technically — branch protection that rejects self-approval, pipeline rules requiring a second identity — and route sensitive paths to designated reviewers via CODEOWNERS. In very small teams, a second qualified reviewer from an adjacent function plus fully logged deployments is an accepted compensating pattern; document it as a deliberate choice.
Challenge
Rollback plans say "revert the change" and collapse the first time they are actually needed.
Solution
Require fall-back plans specific to the failure mode for higher-risk changes: database migrations written backward-compatible with a tested restore behind them, configuration changes with the previous version captured, releases behind feature flags or blue-green deployment. Exercise the hardest case — restoring from backup — at least annually so the plan is evidence rather than hope.
