ISO 27001 Change Management: A.8.32 Evidence and Testing

Implement ISO 27001 change management with security impact review, approval, testing, rollback, emergency control and evidence auditors can trace.

Direct answer: ISO 27001 change management should ensure that changes affecting information-processing facilities and systems are identified, risk-assessed, authorized, tested, implemented and reviewed in a controlled way. Auditors should see a reliable process plus operating records that connect each sampled change to its security impact and outcome.

ISO/IEC 27001:2022 Annex A control 8.32 addresses change management. It applies to more than software releases: infrastructure, networks, cloud configuration, security tooling, databases, integrations and operational procedures can all alter information-security risk.

This article provides AuditPrepared guidance and does not reproduce standard text. The organisation’s risk assessment, system criticality and Statement of Applicability determine the necessary depth.

Distinguish two kinds of change

Annex A 8.32 concerns changes to information-processing facilities and information systems. ISO/IEC 27001 clause 6.3 separately addresses changes to the ISMS itself. The processes may share governance, but they are not interchangeable.

An application deployment is normally handled through operational change control. A change to ISMS scope, risk method or major governance responsibility needs planning at the management-system level. Some initiatives affect both and should produce linked records.

Define what enters the process

Set explicit coverage so teams cannot avoid control by calling work maintenance or configuration. Include, as relevant:

application code and dependencies;
operating systems, databases and middleware;
cloud resources, policies and identity configuration;
firewall, routing, name-service and remote-access rules;
logging, detection and response configuration;
cryptographic settings, keys and certificates;
production data structures and interfaces;
supplier-managed platform configuration;
automation, infrastructure code and pipelines; and
operational procedures that materially change system behaviour.

Use defined exclusions for routine activity that genuinely does not alter risk, and review those exclusions periodically.

Classify changes without weakening control

A practical model distinguishes:

standard changes: repeatable, low-risk actions with a pre-authorized method;
normal changes: assessed and approved individually; and
emergency changes: expedited because delay creates greater harm.

Pre-authorization is not absence of control. A standard change still needs a defined scope, tested procedure, authorized executor, evidence and a route back to individual assessment when conditions differ.

Emergency change does not mean undocumented change. Define who can authorize it, the minimum pre-implementation assessment, communication duties and the time allowed for retrospective review.

Make the request decision-ready

A change record should explain:

the business or security reason;
systems, information, users and suppliers affected;
owner and implementer;
proposed timing and expected interruption;
security, privacy, availability and compliance impact;
dependencies and conflicting changes;
test method and acceptance criteria;
implementation and rollback steps; and
required approvals and communication.

The amount of detail should match risk. Requiring the same record for a low-risk display change and an identity-provider migration creates bureaucracy without improving assurance.

Assess security impact before approval

Ask how the change could affect confidentiality, integrity, availability and control operation. Consider:

new or expanded access paths;
privilege and segregation-of-duty effects;
exposure to the internet or another trust zone;
data movement, retention or classification changes;
logging, alerting and forensic visibility;
encryption and secret handling;
backup, recovery and capacity requirements;
secure configuration baselines;
supplier responsibilities; and
new vulnerabilities or unsupported components.

For material risks, link a formal risk record and treatment decision. The risk score calculator can support consistent triage, while the organisation’s approved risk method remains authoritative.

Preserve separation and accountability

Where risk warrants it, separate request, approval and implementation. A developer may prepare a release without being the sole approver of their own production access and security impact.

Small teams may not achieve complete separation for every change. Use compensating practices such as peer review, logged privileged sessions, independent post-change review and narrow time-bound access. Document why the arrangement is proportionate.

Test the change and its controls

Testing should address intended function and security behaviour. Depending on the change, verify:

authorization and role boundaries;
secure configuration and hardening;
input handling and error behaviour;
logging and alert generation;
backup, restoration or failover;
performance and capacity under realistic load;
compatibility with monitoring and response tools; and
absence of unintended data disclosure.

Protect test data and environments. If production data is necessary, apply authorization, minimization and security controls rather than assuming non-production systems are harmless.

The secure development lifecycle guide provides deeper guidance for software changes.

Design rollback as a real option

A statement that a change “can be rolled back” is weak unless the prerequisites are known. Record:

the decision point and authorized decision-maker;
the previous configuration or deployable release;
data-conversion implications;
backup or snapshot readiness;
expected rollback duration;
communication needs; and
conditions where rollback would cause more harm than recovery forward.

Test recovery for high-impact changes. Database migrations and identity changes can be technically irreversible even when a prior application version exists.

Control emergency changes

An emergency route is necessary for active incidents, critical vulnerabilities and severe outages. It should retain a minimum control set:

record the urgent reason and affected service;
identify the accountable authorizer;
assess immediate security and continuity risks;
capture the action and evidence;
validate service and control operation; and
perform prompt retrospective review.

Repeated emergency use is a management signal. Investigate poor planning, weak maintenance, excessive approval delay or unstable systems instead of normalizing the shortcut.

Preserve design and operating evidence

Design evidence

policy or procedure defining scope and classes;
risk and approval criteria;
role separation and privileged-access rules;
standard-change definitions;
test, rollback and emergency requirements;
integration with incident, supplier and release processes; and
metrics, exception and escalation rules.

Operating evidence

change requests and impact assessments;
approvals recorded before implementation;
peer review and test results;
deployment or configuration logs;
communications and outage notices;
post-implementation validation;
rollback decisions and results;
emergency-change reviews; and
trend analysis and corrective actions.

The NIST publication SP 800-128, Security-Focused Configuration Management is a useful authoritative reference for controlling configuration changes. ISO conformity still depends on the organisation’s adopted ISO controls and evidence.

Trace a worked example

A team plans to expose a new customer API through a cloud gateway. The change record identifies customer data, authentication, network routing, logging and supplier dependencies. The security review requires rate limiting, approved cipher settings, restricted administrative access and alerting for repeated failures.

Automated tests confirm function and access denial. A security analyst verifies logs in the monitoring platform. The approver reviews the residual risk, maintenance window and rollback image before release. After deployment, the owner validates response codes, alert flow and service latency, then closes the record.

This evidence explains why the change was acceptable and proves the security controls continued to operate.

Audit the process through samples

Select changes across systems, teams, risk levels and types. Include a failed change, a standard change and an emergency change—not only successful planned releases.

For each sample:

verify the change was in scope;
compare classification with defined criteria;
inspect security impact before approval;
compare approver authority with risk;
inspect test and rollback readiness;
reconcile the approved change with deployment evidence;
confirm post-change validation; and
trace exceptions or failure to follow-up action.

The Annex A control lookup helps teams navigate related controls, while the licensed standard and Statement of Applicability remain the basis for conformity.

Result	Example
Pass	Sampled changes show proportionate impact review, authorization, testing, traceable implementation and validated outcomes.
Partial	Requests and approvals exist, but security tests, rollback detail or emergency reviews are inconsistent.
Fail	Production changes bypass approval, evidence cannot be reconciled or urgent work routinely avoids control.

Common questions

Must every change go to a change advisory board?

No specific committee is universally required. Approval should be timely, competent and proportionate to risk. Automated and delegated approval can be appropriate when criteria and accountability are clear.

Can a deployment platform provide all evidence?

It may prove code, timing and executor, but it may not show business authorization, security impact, test acceptance, communication or post-change review. Connect technical logs to the decision record.

Is an emergency change a nonconformity?

Not automatically. A controlled emergency path is legitimate. Failure to follow the defined path, or chronic emergency use without correction, may indicate a control problem.

Make safe change the normal path

Good change management does not prevent change. It makes security consequences visible early, assigns the right decision-maker and leaves evidence that the approved result reached production. A proportionate process is easier to follow and easier to audit.