ISO 27001 A.8.32: Preserve security when systems change

What A.8.32 requires in practice

Annex A control A.8.32 states that any change to information systems or the facilities that process information should go through change management procedures. The scope is broad: hardware, software, network rules, configurations and services all fall within it when they affect information processing.

A procedure in this sense links the reason for a change with an assessment of its consequences, authorisation by an accountable person and confirmation that the resulting state is as intended. Proportion matters. The control does not call for a meeting for every adjustment, so routine changes can follow a lighter route while significant ones receive closer scrutiny.

The outputs are defined procedures with criteria for what counts as significant, records of assessment and authorisation, arrangements for urgent changes, and verification afterwards. A change can alter access, logging, backup or recovery in ways that are not obvious, so dependencies deserve attention. Applicability follows risk treatment and the Statement of Applicability.

Understand the change and its dependencies

Define what will change and why. Consider the information, services, users and suppliers affected, including indirect dependencies. A network rule or software update can alter access, logging, backup or recovery even when its immediate purpose appears narrow.

Assess both the risk of making the change and the risk of delaying it. This is particularly relevant to urgent security treatment. The process should support an informed decision rather than treat delay as automatically safer. Connect technical changes with vulnerability management where a weakness creates time-sensitive exposure.

Choose an appropriate route and authorisation

Define responsibilities for routine, significant and urgent changes in a way that fits the organisation. Repeated low-risk work can follow an approved, controlled method, while a consequential change may need more detailed review. The categories should describe real differences in risk and decision-making, not provide easy labels for avoiding scrutiny.

Authorisation should come from people who understand the relevant technical and business consequences. Communicate with affected parties where necessary. A change approved only within an isolated technical team may overlook a critical customer activity or another team's dependency.

Why change management matters to the business

Many outages and security incidents begin with an uncontrolled change: a well-meant update that removed a protection, a rule altered without telling the people who depend on it, or a fix applied in haste. A proportionate procedure keeps the business moving while making sure someone has considered who and what a change could affect. It also records what was done, which shortens investigation when something goes wrong. Delay carries risk too, particularly for urgent security fixes, so the process should support quick, informed decisions. At audit, traceable change records show that the ISMS is operating in daily technical work.

How to implement A.8.32

Design the procedure around the types of change you really make, then keep it light enough to be used. Match the procedure to the pace of your work, because a process that nobody uses protects nothing. Involve engineers when designing the classes of change so the rules reflect real practice, and be ready to adjust them after the first review cycle.

1. List the kinds of change that occur, from routine updates to major platform moves, and decide which are standard, normal or emergency.
2. Define criteria for significant changes that need closer assessment.
3. Require each change to state its purpose, the affected information, services, users and suppliers, and the risk of acting or waiting.
4. Assign authority to approve each class of change, with a named alternate.
5. Set up a fast route for urgent security fixes, with retrospective review.
6. Plan how the change can be reversed if the result is not as intended.
7. Confirm the operational state afterwards, including access, logging and backup behaviour.
8. Review closed changes periodically to improve the procedure.

Evidence an auditor expects for A.8.32

Auditors sample real changes and follow them through. Evidence may include: Auditors may also compare a recent technical change visible in a system log against the change record that should exist for it.

• change records showing purpose, assessment, approval and outcome
• a sample that includes an urgent change and its retrospective review
• post-change checks confirming the intended state
• observation of how a change request is raised in practice
• an interview with an approver about how significant changes are distinguished

The tool used to hold the records is the organisation's choice.

Common nonconformities with A.8.32

Findings generally show changes made outside the stated route. They usually arise because teams find the process slow and bypass it, so an auditor compares system logs of recent changes with the change records that ought to exist.

• Technical changes made directly with no record, particularly on network or access rules.
• Approvals given after the change was already live, outside any emergency process.
• Assessments that ignore indirect effects on logging, backup or recovery.
• No confirmation afterwards that the result matched the intention.
• Every change treated identically, so significant changes receive no extra scrutiny.

Illustrative manufacturing example: a scheduling interface update

Illustrative software example: an urgent access restriction

A hypothetical software provider needs to restrict a service quickly after identifying a significant weakness. Waiting for the next routine review would leave unnecessary exposure, but an uncoordinated restriction could interrupt legitimate customer use.

The provider uses an authorised urgent route with a defined scope, responsible decision-maker and appropriate verification. After the immediate action, it reviews the lasting configuration, communication and any temporary measures. This preserves accountability while allowing timely treatment; urgency changes the route, not the need to understand and own the result.

Prepare implementation and recovery

Plan how the change will be performed, tested and checked. Establish what the organisation will do if the result is unacceptable, considering whether rollback, restoration or another response is feasible. A recovery plan should reflect the actual technology and dependencies rather than assume every change can be reversed instantly.

Coordinate with security testing and configuration management. Preserve the appropriate relationship between the approved change, tested version and deployed state. Where implementation differs from the plan, assess and record the consequence instead of quietly editing the original intention after the event.

Close the change against its outcome

Confirm that the intended function works and relevant security expectations remain satisfied. Update operating information, user instructions and recovery arrangements where the change affects them. Remove temporary access or exceptions when no longer required. Closure should leave the system in an understood state.

Useful evidence includes the purpose, impact assessment, authority, relevant tests, implementation result and follow-up decisions. These are practical evidence choices rather than mandated forms. A sample review should be able to follow the reasoning without relying entirely on the memory of the engineer who performed the work.

Common failures include retrospectively approving every change, omitting dependencies and leaving documentation inconsistent with operation. Review recurring issues through nonconformity and corrective action where appropriate. A proportionate process should reveal patterns that need improvement, rather than merely accumulate completed tickets.