ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
ISO 27001 change management is two separate requirements that most programmes run as one, and auditors sample them separately. Clause 6.3 governs changes to the information security management system itself. Annex A control 8.32 governs changes to your systems and the facilities that process information. A single change advisory board minute will not satisfy both, and a stage 2 audit that finds only one of them usually writes a finding.
This guide separates the two sides of ISO 27001 change management, shows what evidence each one needs, and lists the controls a single change record has to touch on the way through.
Free gap assessment
Where do you actually stand against ISO 27001?
Score every management system clause and all 93 Annex A controls, free, and get a prioritised gap list back.
Run the free ISO 27001 gap assessment → or View premium report sample
ISO 27001 change management is anchored in two places in the standard. ISO/IEC 27001:2022 is edition 3, published in October 2022, and it carries 93 Annex A controls in four themes: 37 organizational, 8 people, 14 physical and 34 technological. Change sits in both the clauses and Annex A.
Clause 6.3, Planning of changes, is new in the 2022 edition. It is one sentence long. When the organization determines that the ISMS needs to change, the change has to be carried out in a planned manner. There are no sub-clauses, no enumerated considerations, and no requirement anywhere in clause 7.5 to keep documented information about it. That is why it is missed so often: there is no template to fill in, only a habit to evidence.
Annex A 8.32, Change management, sits in the technological theme. The control requires changes to information processing facilities and information systems to be subject to change management procedures. Unlike clause 6.3, the control text names procedures itself, so if you have declared A.8.32 applicable in your Statement of Applicability, you cannot credibly run it undocumented, even though a change procedure is not on clause 7.5’s mandatory list.
In the 2013 edition this control was spread across four: A.12.1.2 change management, A.14.2.2 system change control procedures, A.14.2.3 technical review of applications after operating platform changes, and A.14.2.4 restrictions on changes to software packages. The 2022 consolidation into a single A.8.32 is why so many older procedures read as four disconnected sections.
| Clause 6.3 | Annex A 8.32 | |
|---|---|---|
| What changes | The ISMS: scope, policy, risk methodology, roles, objectives, the SoA | Systems and information processing facilities: servers, applications, firewall rules, cloud configuration, access models |
| Applicability | Mandatory clause, cannot be excluded | Annex A control, justified in the SoA |
| Documented information required | None stated | Procedures named in the control text |
| Typical owner | ISMS manager or CISO | IT operations, platform or engineering lead |
| Typical evidence | Management review minutes, ISMS change log, revised SoA with rationale | Change tickets, impact assessment, test and approval records, rollback plan |
| Audit sampling | Looked at against clauses 4 to 10 and the management review | Sampled as tickets against the control |
The clause-6.3 half of ISO 27001 change management is about the management system, not the technology. Changes that fall under it include a scope extension to a new site or product, a new risk assessment methodology, a change of risk owner for a material risk, a revised set of information security objectives, the addition or removal of an Annex A control in the SoA, and a reorganisation that moves security accountability.
Free ISO 27001 risk assessment
Which of your risks sit above your appetite line?
Set your own risk criteria, pick from 61 information security risk scenarios, rate likelihood and impact, and decide how to treat each one. You get a heat map, a process score and the findings an auditor would raise, free.
Run the free risk assessment → or View premium report sample
The free Amendment 1:2024, which added climate change considerations to clauses 4.1 and 4.2, is itself a worked example. Every certified organisation had to absorb it. Absorbing it meant revisiting the context and interested parties analysis, deciding whether climate is a relevant issue, and recording the outcome. Doing that deliberately, with a dated record and a named owner, is exactly what clause 6.3 asks for. Doing it by quietly editing a document and saying nothing is what gets written up.
What satisfies an auditor here is modest. A short ISMS change log with date, description, reason, impact on the risk assessment and SoA, approver and completion date covers it. Management review minutes carry the rest, and the 2022 edition added changes in the needs and expectations of interested parties to the required management review inputs. If your minutes never mention change, two clauses are exposed at once.
The A.8.32 half of ISO 27001 change management is the one most teams already have in some form, usually in a ticketing tool. The question an auditor asks is not whether you have a tool but whether the record shows a decision. A change ticket that carries a title, an assignee and a “done” status proves scheduling. It does not prove control.
A change record that holds up shows the following, and most mature tools can be configured to require them before a ticket closes:
That last point is where most programmes leak. A firewall rule change never reflected in the network diagram, or a new system that never reaches the asset inventory, breaks the records behind other controls even though the change itself went perfectly.
Splitting changes into routes by risk is common practice rather than an ISO requirement. Nothing in ISO/IEC 27001:2022 names these categories, but it is the pattern auditors see most.
| Route | Example | Approval | Evidence expected |
|---|---|---|---|
| Standard, pre-approved | Routine patching inside a defined window, user account creation to an approved template | Approved once as a change model, not per instance | The approved model, plus a log of instances |
| Normal | A new application release, a firewall rule change, a cloud configuration change | Named approver or change board before deployment | Full record: impact, test, approval, rollback, closure |
| Emergency | A fix deployed during an incident or to close an actively exploited vulnerability | Verbal or single-approver at the time, with defined authority | Retrospective record within a stated window, reviewed afterwards |
Emergency changes do not breach ISO 27001 change management requirements. An undocumented emergency change is. The test is whether your procedure defines who may authorise one, how fast the record must catch up, and who reviews the batch of them afterwards. A programme with zero emergency changes on record over a year is usually not disciplined, it is just not recording them.
Expect sampling, not a document review. A stage 2 or surveillance audit of ISO 27001 change management runs roughly like this: ask for the procedure, ask how many changes went through last quarter, pick five or six across the routes, and trace each one end to end. The gaps that surface are predictable.
| Control touched | What the change record has to show |
|---|---|
| A.8.9 Configuration management | The configuration baseline was updated, or the change was made through the baseline |
| A.8.31 Separation of development, test and production environments | Testing happened outside production, and promotion ran one way |
| A.8.33 Information for testing | Production data was not copied into test without protection |
| A.8.28 Secure coding | Code changes passed the review and scanning gates you claim to run |
| A.5.37 Documented operating procedures | Runbooks affected by the change were revised |
| A.8.8 Management of technical vulnerabilities | Patch changes trace back to a vulnerability finding and its deadline |
| Clause 10.2 Corrective action | A change that caused a nonconformity was treated as one, with root cause |
Five mistakes account for most findings: one procedure naming only the technical regime, leaving clause 6.3 unevidenced; approval recorded as a status transition with no named person; no rollback plan where the record claims one was required; test evidence that is a sentence rather than a result; and a SoA edited without a dated reason, which is a clause 6.3 failure dressed as a document update. Our guide to ISO 27001 document control covers the version and approval side of that last one, and ISO 27001 configuration management covers the baseline that A.8.9 expects a change to move.
Keep the procedure short enough to be followed. A workable ISO 27001 change management procedure fits on four or five pages and answers eight questions: what counts as a change, what the routes are, who may approve each route, what the security impact assessment must consider, where testing happens, what the rollback expectation is, what has to be recorded and for how long, and who reviews changes periodically.
Two drafting decisions matter more than the rest of the ISO 27001 change management text. Define the boundary explicitly, because “a change” expands to mean everything if you let it, and a procedure that nominally covers every password reset will be breached on day one. And set a retention period you will actually meet: certification cycles run three years with annual surveillance, so change records kept for at least the current certification cycle let an auditor sample from any point in it.
Scope the technical side against your development process. If you ship software, the ISO 27001 secure development policy and the rules you set for ISO 27001 test data are where A.8.32 meets A.8.28, A.8.31 and A.8.33, and the handover between them is where evidence usually goes missing.
ISO 27001 change management is not named in clause 7.5, which lists the mandatory documented information. But Annex A 8.32’s own control text requires changes to be subject to change management procedures, so if you have declared that control applicable, an auditor will expect to read them. In practice, yes, write it.
No, and conflating them is the most common ISO 27001 change management finding. Clause 6.3 is a mandatory requirement about changes to the management system. A.8.32 is an Annex A control about changes to systems and processing facilities. One management review minute does not evidence the second, and a stack of change tickets does not evidence the first.
Usually yes for anything that affects the certified ISMS or its scope. Certification agreements under the accredited scheme oblige the client to notify the body of changes that bear on certification, and a scope change can trigger an assessment before the certificate is updated. Routine technical changes do not need reporting.
Typically a handful per audit of ISO 27001 change management, chosen across your own routes rather than at random, with at least one emergency change if your log shows any. The sample size is the auditor’s judgement, not a fixed number, and it grows if the first two records are incomplete.
A change that fails technically is not automatically a nonconformity. A change that bypassed your own procedure is. If a failure caused a security incident or a breach of a requirement, clause 10.2 applies and you need root cause and corrective action, not just a rollback. See ISO 27001 nonconformity for how major and minor findings are graded.
If you are building ISO 27001 change management from nothing, write the ISMS change log first. It takes an hour, it closes clause 6.3, and no ticketing tool gives it to you for free. Then audit your existing change tickets against the seven record elements above and fix the two weakest fields before you touch the procedure text. For the standard’s own scope and status, the ISO/IEC 27001:2022 page at ISO is the authoritative reference, and our pillar guide, ISO 27001 explained, covers how the clauses and Annex A fit together.
If you would rather start from drafted documents than a blank page, the ISO 27001 Toolkit includes 165 templates covering the ISMS documentation set, including the change and configuration records this control expects, in editable Microsoft Office format for $99.
October 24, 2026
October 24, 2026
October 23, 2026
October 23, 2026
October 22, 2026