ISO 27001 Change Management: Controlling Security Changes
Change is inevitable in any organisation. New systems are deployed, applications are updated, processes are redesigned, and people join or leave. But every change carries information security risk. ISO 27001:2022 clause 8.2 requires organisations to assess and manage the security implications of changes before they happen, not after. A structured change management process is essential for maintaining the confidentiality, integrity, and availability of your information assets.
Without proper change management, even a simple configuration update can introduce vulnerabilities, disrupt operations, or expose sensitive data. This guide covers the full scope of ISO 27001 change management requirements, including risk assessment for changes, the change process, emergency changes, and the role of the Change Advisory Board (CAB).
ISO 27001 Clause 8.2: Information Security Risk Assessment for Changes
Clause 8.2 requires your organisation to perform information security risk assessments on planned changes. This is not a generic risk assessment – it is a focused assessment of the specific security risks introduced by the change. The clause mandates that risk assessments be conducted systematically, documented, and repeated when significant changes occur.
Key requirements of clause 8.2:
- Perform information security risk assessments for planned changes
- Retain documented information of the risk assessment results
- Apply the risk treatment process to address identified risks
- Repeat risk assessments when significant changes occur
- Ensure consistency with your overall ISMS risk assessment methodology
| Change Type | Risk Assessment Focus | Example Risks |
|---|---|---|
| Infrastructure change | Network security, access controls, availability | Misconfigured firewall, exposed ports, single point of failure |
| Application change | Code vulnerabilities, data integrity, authentication | Injection flaws, broken access control, insecure deserialisation |
| Process change | Control gaps, segregation of duties, documentation | Reduced oversight, unauthorised approvals, skipped verification steps |
| Personnel change | Access rights, knowledge loss, insider threat | Orphaned accounts, unrecovered credentials, insufficient handover |
Types of Changes Covered by ISO 27001
ISO 27001 change management covers all changes that could affect information security. The scope is broad and includes changes to infrastructure, applications, business processes, and personnel. Each category requires a tailored approach to risk assessment and control implementation.
Infrastructure Changes
Infrastructure changes include modifications to networks, servers, storage, firewalls, cloud environments, and endpoints. These changes affect the foundational security of your entire ISMS. Common infrastructure changes requiring formal change management include:
- Network topology changes (new subnets, VPNs, firewall rules)
- Server upgrades, migrations, or decommissioning
- Cloud environment changes (new accounts, regions, service configurations)
- Security tool updates (SIEM, antivirus, DLP rule changes)
- Certificate renewals and cryptographic key rotations
Application Changes
Application changes cover software releases, patches, configuration updates, and feature changes. The security risk depends on whether the application is internally facing, customer-facing, or handles sensitive data. Application change management must integrate with your secure development lifecycle (Annex A.14).
Process Changes
Changes to business processes can introduce security gaps by removing or altering controls. Examples include changing the approval workflow for access requests, modifying data handling procedures, or outsourcing a previously in-house process. Process changes often have subtle security implications that are easily overlooked.
Personnel Changes
Personnel changes include new hires, role changes, transfers, and terminations. These changes directly affect access control, segregation of duties, and the human element of security. ISO 27001 requires controls for joining, moving, and leaving (Annex A.7). Formal change management ensures that access rights are provisioned, modified, and revoked in a timely manner.
| Personnel Event | Security Action Required | Timeline |
|---|---|---|
| New hire | Background check, access provisioning, security awareness training | Before or on day one |
| Role change | Access rights review, revised permissions, additional training if needed | Effective on change date |
| Termination | Account disablement, credential recovery, asset return, exit interview | On or before last working day |
The Change Advisory Board (CAB)
Many organisations establish a Change Advisory Board (CAB) to review and authorise significant changes. While ISO 27001 does not explicitly require a CAB, it is a best-practice governance structure that supports clause 8.2 compliance. The CAB typically includes representatives from information security, IT operations, business units, and compliance.
CAB responsibilities include:
- Reviewing change requests for security impact
- Challenging inadequate risk assessments
- Approving or rejecting changes based on residual risk
- Ensuring changes have appropriate rollback plans
- Reviewing emergency changes retrospectively
- Monitoring the overall change pipeline and risk profile
The CAB should meet at regular intervals (weekly or bi-weekly) and maintain records of all decisions. For fast-moving organisations, consider a virtual CAB or delegated authority for low-risk changes.
The Change Management Process
A robust change management process under ISO 27001 should follow a defined lifecycle. The exact steps may vary by organisation, but the core stages are consistent.
| Stage | Activity | Output |
|---|---|---|
| 1. Initiation | Change requester submits a change request with scope, rationale, and timeline | Completed change request form |
| 2. Impact assessment | Security impact analysis, risk assessment per clause 8.2 | Risk assessment report |
| 3. Planning | Define implementation plan, testing approach, rollback plan, and communication | Change implementation plan |
| 4. Authorisation | CAB or authorised person reviews and approves or rejects the change | Authorisation record |
| 5. Implementation | Execute the change following the approved plan | Implementation checklist |
| 6. Testing and verification | Verify that the change works correctly and security is maintained | Test results, sign-off |
| 7. Post-implementation review | Review outcomes, document lessons learned, close the change record | Post-implementation review report |
Emergency Changes
Not all changes can go through the full standard process. Security incidents, critical vulnerabilities, or system outages may require immediate action. Your change management process must include an emergency change procedure that balances speed with control.
Emergency change requirements:
- Define what constitutes an emergency change (clearly scoped to prevent abuse)
- Pre-authorise a limited set of individuals who can approve emergency changes
- Document the change after the fact with full details of what was done and why
- Conduct a retrospective security review within an agreed timeframe (e.g. 48 hours)
- Submit the emergency change for retrospective CAB review
- Track emergency change frequency as an indicator of systemic issues
If your organisation processes frequent emergency changes, investigate the root causes. High emergency change volume often indicates underlying problems such as inadequate maintenance windows, insufficient monitoring, or reactive rather than proactive management.
Security Impact Assessment for Changes
The security impact assessment is the core of clause 8.2 compliance. For every change, you must assess what could go wrong and what controls are needed to prevent or mitigate the impact. The level of rigour should be proportionate to the risk.
A security impact assessment should answer these questions:
- What information assets are affected by this change?
- What security controls are impacted (added, removed, or modified)?
- What new vulnerabilities could this change introduce?
- Are there dependencies on other systems or processes?
- What is the worst-case security impact if the change fails?
- What is the rollback plan and does it restore security controls?
- Who needs to be notified about the change?
Frequently Asked Questions
Does ISO 27001 require a separate change management procedure?
Not explicitly, but you must demonstrate that changes are controlled. Most organisations document a change management procedure or policy because it is the most effective way to ensure consistency and provide audit evidence. The procedure should integrate with your existing ITIL or service management processes if you have them.
What is the difference between clause 8.2 and Annex A.8.32?
Clause 8.2 is a mandatory ISMS process requirement to perform risk assessments for changes. Annex A.8.32 (change management) is a control that organisations must select if identified as applicable in their risk assessment. Both work together: clause 8.2 drives the risk assessment, and A.8.32 drives the change control process itself.
Can we skip CAB approval for low-risk changes?
Yes, define categories for standard, normal, and emergency changes with different approval levels. Low-risk, pre-approved changes (e.g. routine patching) can follow a streamlined process without CAB approval. Document the categorisation criteria and ensure any change that falls outside the defined low-risk category receives appropriate scrutiny.
How do we handle changes in a DevOps environment?
Integrate change management into your CI/CD pipeline. Automate security gates (SAST, DAST, container scanning) and ensure that every deployment triggers a documented change record. Use infrastructure as code to make changes reviewable and auditable. The key is that the control exists, not that it follows a manual process.
What records must be kept for change management?
You must retain documented information of risk assessments (clause 8.2) and evidence that changes are controlled. Practical records include change request forms, risk assessment reports, approval records, implementation checklists, test results, and post-implementation review reports.
How often should the CAB meet?
Weekly meetings are standard for organisations with moderate change volumes. Monthly may suffice for smaller organisations. The key is that the meeting frequency matches the pace of change in your organisation. If changes are waiting weeks for CAB review, your process is a bottleneck, not a control.
Take Control of Security Changes with ISO 27001
A well-designed change management process protects your organisation from the security risks that every change brings. ISO 27001 clause 8.2 gives you the framework to assess risks systematically, and Annex A.8.32 provides the control structure to implement changes safely. Whether you manage infrastructure, applications, processes, or people, change management is essential to maintaining your security posture over time.
Bitrixme helps organisations across the GCC implement ISO 27001-compliant change management processes. Contact us to discuss how we can support your ISMS implementation or certification journey.
