ISO 27001 controls
Change management under ISO 27001: proving that change happens on purpose.
Most outages and many breaches start with a change: a deploy, a firewall rule, a new permission. Annex A control 8.32 Change management asks that changes to systems and information processing facilities follow an agreed path. The test is simple. Pick any change, and you should be able to show who asked, who checked, what was tested, and how you would undo it.
Back to ISO 27001 services01 · Two levels of change
Clause 6.3 and control 8.32 answer different questions
One is about changing the ISMS. The other is about changing systems.
Clause 6.3
Planning of changes
When the management system itself changes, such as a new scope, a reorganisation or a new risk method, the change is planned, not improvised.
Control 8.32
Change management
When a system, application, network or configuration changes, the change follows a defined procedure with review and records.
A large migration often touches both: the ISMS scope moves, and hundreds of system changes follow.
02 · The change path
The six steps every change passes through
Small changes pass through them in minutes. The steps still happen.
- Request: what is changing, why, and which systems it touches.
- Assess: the risk of the change, and whether it needs extra review.
- Approve: someone other than the person making it agrees it should go ahead.
- Test: the change is checked in a non-production setting, or by automated tests.
- Implement with a way back: a rollback plan exists before the change goes live.
- Record and review: the outcome is logged, and failed changes are looked at.
03 · Change types
Three kinds of change, three levels of ceremony
Classifying changes keeps the process fast where risk is low.
| Change type | What it is | Approval | Records |
|---|---|---|---|
| Standard | Low risk, repeated often, done the same way each time (a routine patch, adding a user to a group) | Pre-approved once as a type; no per-change approval | The ticket or log entry, plus the approved standard change definition |
| Normal | Everything else: features, configuration changes, new infrastructure | Peer or owner approval before release; higher risk goes to a change board or senior engineer | Request, approval, test result, deploy record |
| Emergency | Needed now to restore service or close an active threat | A named person approves fast, often verbally; full review after the fact | Retrospective record within an agreed window, with a reason for urgency |
Emergency changes are allowed. What an auditor dislikes is an emergency route used for convenience. Track how often it is used.
04 · Code and infrastructure
Change control for software teams and for infrastructure
Pull requests and infrastructure as code can be the change process.
Pull-request based change
- Protected main branch. Nobody pushes straight to the branch that deploys to production.
- Required review. At least one approver who is not the author, enforced by the platform.
- Required checks. Tests and scans must pass before merge.
- Traceable deploys. Each production deploy links to the merged change that caused it.
- Bypass is logged. Admin overrides are rare, recorded and reviewed.
Infrastructure change
Where infrastructure is defined as code, the same pull-request path covers it. Where people still change things in a cloud console or on a device, those changes need a ticket and approval too, and the audit log of the console is your check that nothing slipped past. Configuration drift detection is a useful backstop; see the configuration management guide.
05 · Evidence sampled
How an auditor tests change management
They start from the system, not from your change log.
A careful auditor pulls the list of production deploys or configuration changes from the platform itself, picks a sample, then asks you to show the request, approval and test for each. Starting from the system catches changes that never reached the change log. Expect them to look at emergency changes separately.
- A change log that is not the source of truth. A spreadsheet that misses changes made outside it fails the first sample.
- Approval after deploy. Timestamps that show approval after release turn a control into paperwork.
- Same person requests, approves and deploys. Without separation or a compensating review, the approval means little.
- No rollback thinking. Database migrations and network changes are the usual places where the way back was never planned.
- Emergency route as the normal route. A high share of emergency changes suggests the normal path is too slow, or ignored.
- Vendor changes forgotten. Changes a managed service provider makes in your environment still need a record.
Sources: ISO/IEC 27001:2022 clause 6.3 and Annex A control 8.32 (public titles only; the standard's text is not reproduced).
Change management questions
Do we need a change advisory board?
No. You need appropriate approval, which can be a peer.
The standard does not name a board. Many teams use peer review for normal changes and reserve a meeting or senior sign-off for high-risk ones. Write down which is which.
Are feature flags changes?
Usually yes, when they alter production behaviour.
Turning on a feature for customers changes the live system. Many teams treat the flag change as a standard change when the code behind it was already reviewed, and log the toggle.
How long after an emergency change should the record be completed?
Your procedure sets it. Keep it short and stick to it.
The standard does not fix a window. Choose one in your procedure, such as the next working day, and make sure sampled emergency changes meet it.
Does a SaaS vendor's update count as our change?
Not as yours to approve, but you should know about it.
You cannot approve a vendor's release. You can track significant changes to supplier services under the supplier controls and assess their effect on you.
Make every change traceable.
An ISO 27001 gap analysis samples your recent changes the way an auditor would and shows where the trail breaks.