How to Make Changes Without Breaking (or Weakening) Your Security
ISO 27001 Control 8.32 Change management is about one core idea:
Every change to systems, infrastructure and applications should be planned, reviewed, tested, approved and documented so you don’t accidentally introduce outages or security holes.
It ties tightly into:
- 8.25–8.29 (secure development and security testing)
- 8.31 (separation of development, test and production environments)
- Your wider IT change / release process (often via ITSM tools)
This guide turns Control 8.32 into a practical, implementable process you can follow in real life, not just for the sake of the audit.
What ISO 27001 Control 8.32 Actually Expects
In plain language, ISO 27001 Control 8.32 – Change management – expects you to:
- Have a documented change process for systems, applications and infrastructure.
- Ensure all significant changes go through planning, risk assessment, testing, approval and controlled deployment.
- Consider security and continuity as part of every change (not as an afterthought).
- Keep records so you can see who changed what, when, why and with what result.
- Treat production as special – changes are tested in non-production first.
- Handle emergency changes in a controlled way, with review afterwards.
Auditors will usually pick a few changes at random and say:
“Show me how this went through your change process.”
Your evidence is what demonstrates this control.
Step 1 – Decide What Counts as a “Change” and Classify It
Start by being clear on what you treat as a “change”. I usually suggest three simple categories:
- Standard changes
- Low-risk, repeatable, pre-approved (e.g. adding a user to a standard role, routine OS patching following a tested pattern).
- Follow a predefined, documented workflow.
- Normal changes
- Anything non-trivial that could affect availability, integrity, confidentiality or performance.
- Require planning, risk assessment, testing, approval and scheduling.
- Emergency changes
- Needed urgently to fix an incident or critical vulnerability.
- Follow a shortened approval path, but are still recorded and reviewed afterwards.
Write this into a short Change Management Procedure so people know which route to use.
Step 2 – Design a Simple Change Workflow (for Normal Changes)
Your change process doesn’t have to be bureaucratic – but it does need to be consistent.
A good minimal flow is:
1. Raise and describe the change
- What is being changed?
- Why is the change needed (business and/or security drivers)?
- Which systems, data and users are affected?
Capture this in your ITSM tool or change log.
2. Plan and assess risk
- Identify technical and security impact
- Could this affect confidentiality, integrity or availability?
- Any impact on logging, monitoring, backup or incident response?
- Consider dependencies
- Other systems, integrations, third parties, licences, firewall rules, certificates, etc.
- Define back-out / rollback
- What you will do if it goes wrong, and how you’ll know it has gone wrong.
3. Get the right approvals
- Assign a change owner.
- Get approvals from:
- A technical owner (e.g. system owner / lead engineer), and
- A business owner where relevant, and
- A security reviewer for higher-risk changes.
Role-based approval (rather than “that one helpful person”) keeps it clean and auditable.
4. Test in a non-production environment
Link this to your separate dev / test / staging environment (Control 8.31):
- Test functionality – does it do what it should?
- Test security – controls still work, no new holes introduced (Control 8.29).
- Confirm performance and compatibility where relevant.
Record where and how it was tested, and the outcome.
5. Plan and schedule deployment
- Choose a sensible maintenance window (if there is risk of downtime).
- Make sure relevant teams (IT, support, security, business) are informed in advance.
- Confirm who will:
- Execute the change
- Monitor during and after
- Make the call to rollback if necessary
6. Implement and verify
- Implement the change according to the agreed plan.
- Perform post-change checks:
- Is the service up?
- Are security controls working (auth, logging, access controls, firewalls)?
- Any unexpected alerts or side-effects?
7. Close and record
- Update the change record with:
- Implementation date and time
- Who implemented it
- Results of post-change tests
- Whether a rollback was needed
- Any follow-up actions
This is what gives you traceability for ISO 27001.
Step 3 – Handle Emergency Changes Safely
Emergency changes are where many organisations quietly bypass security.
Rather than pretending they never happen, define a safe shortcut:
- Clear definition of what qualifies as an emergency (e.g. critical incident, active exploit, severe business impact).
- Minimal but real authorisation (e.g. duty manager + on-call technical lead).
- Still logged as a change, even if raised after implementation in a true crisis.
- Post-implementation review:
- Was the emergency approach justified?
- Did it introduce any new risks?
- Do we need follow-up hardening, documentation or testing?
That way, you retain control and evidence, even when moving quickly.
Step 4 – Make Production Special
Change management and environment separation are two sides of the same coin.
To align Control 8.32 with 8.31:
- No direct editing in production
- Changes are deployed via controlled mechanisms (CI/CD, configuration management tools, formal scripts).
- Everything major tested before live
- New systems and major changes must pass through a test or staging environment first.
- Production changes logged and tracked
- Firewalls rules, OS changes, database config, application settings – not just code.
- Use controlled deployment strategies
- Phased rollouts, canary releases, blue–green deployments for higher-risk changes.
- Always with monitoring and a defined rollback plan.
The message is: production isn’t a sandpit – it’s governed.
Step 5 – Embed Security into Every Change
Control 8.32 sits in the same family as the secure development controls, so your change process should naturally include security checks.
For each significant change, I recommend:
- A simple security impact assessment
- Does this change affect access control, data flows, encryption, logging, monitoring or legal obligations?
- Does it expose new ports, services or APIs?
- Security testing where appropriate
- Static or dynamic checks for application changes.
- Vulnerability scanning or configuration checks for infrastructure changes.
- Patch and update management under change control
- Security patches still need risk assessment, testing (even if shortened) and record-keeping.
- Update of supporting documents
- Network diagrams, asset inventories, procedures, incident response plans, recovery steps.
That’s how you show that changes preserve or improve security, rather than undermining it.
Step 6 – Strengthen Governance and Accountability
For more complex or higher-risk environments, add some governance structure around the change process:
- Change Advisory Board (CAB)
- A small, multidisciplinary group (IT, security, business) that reviews and approves significant or high-risk changes.
- Focused on impact, risk, timing and readiness to roll back.
- Role-based access control for changes
- Separate roles for requesting, approving, implementing and reviewing.
- Apply least privilege – only those who need to can make changes on critical systems.
- Version control and configuration management
- Use source control (e.g. Git) for code and infrastructure-as-code.
- Tag releases, keep history, and make rollbacks predictable.
- Change monitoring and alerts
- Use tooling to detect unexpected changes to key systems (e.g. config drift, unauthorised modifications).
This is what turns change management from “process on paper” into real control in practice.
Step 7 – Use Tools and Automation to Make Life Easier
Good tools make change management more reliable and less painful:
- ITSM / change tools
- Use your service desk / ITSM platform to log, approve and track changes.
- Define workflows for standard, normal and emergency changes.
- CI/CD pipelines
- Automate builds, tests, security scans and deployments.
- Integrate change approvals into the pipeline (e.g. only approved changes can be shipped).
- Infrastructure as Code (IaC)
- Define environments and configuration as code so changes are:
- Repeatable
- Reviewed (via pull requests)
- Auditable
- Define environments and configuration as code so changes are:
- Automated monitoring of changes
- Detect unauthorised configuration changes or drift from baseline.
Automation helps you apply Control 8.32 consistently, instead of relying on someone remembering each step manually.
Step 8 – Measure, Review and Improve
Finally, treat change management as a process you can tune over time.
Useful metrics include:
- Change success rate
- Percentage of changes implemented without causing incidents or needing rollback.
- Number of change-related incidents
- How often issues are traced back to inadequate planning or testing.
- Mean time to recover (MTTR) from failed changes
- How quickly you can roll back or fix when things go wrong.
- Lead time for changes
- How long it takes from request to deployment – useful to balance control vs agility.
Use post-implementation reviews and periodic process reviews to refine:
- Where the process is too heavy for low-risk changes.
- Where it’s too light for high-risk areas.
- Where automation could take friction away without losing control.
Quick Implementation Checklist for ISO 27001 Control 8.32
A simple way to see where you stand:
- There is a documented change management procedure that covers systems, applications and infrastructure.
- Changes are classified (e.g. standard, normal, emergency) with appropriate workflows for each.
- All non-trivial changes go through planning, risk assessment, approval, testing and controlled deployment.
- Production changes are tested in a separate environment first (linked to Control 8.31).
- Security impact is explicitly considered for relevant changes, with security testing built in (linked to 8.25–8.29).
- Emergency changes are still logged, authorised (even quickly) and reviewed afterwards.
- Change records include what, why, who, when, where and the outcome (including rollback if used).
- There is clear segregation of duties around who can approve and implement changes on critical systems.
- Patch and update management runs through the same change process, proportionate to risk.
- Metrics (success rate, change-related incidents, MTTR) are tracked and used to improve the process over time.
If you can walk through a real change and show that it followed this kind of structured, security-aware path, you’ll have strong evidence for ISO 27001 Control 8.32 – and, more importantly, far fewer nasty surprises when changes go live.
Explore the ISO 27001 Controls