ISO 27001 A.8.32 - Change Management

Requirement

Requirement lens

This control asks whether changes to information processing facilities and information systems are controlled through formal change management procedures.

“Changes to information processing facilities and information systems shall be subject to change management procedures.”

Plain-language meaning

Changes to systems, infrastructure, networks, applications, code, integrations, operational processes, and information processing facilities should be planned, reviewed, approved, tested, implemented, recorded, and recoverable.

The point is not bureaucracy. The point is preventing uncontrolled changes from breaking services, weakening security controls, introducing vulnerabilities, or creating undocumented production states.

Why this matters

Uncontrolled change is a major source of outages, security gaps, audit failures, and incident confusion. A small firewall rule, software upgrade, business-process change, new integration, or emergency fix can affect confidentiality, integrity, availability, logging, access control, backup, monitoring, and compliance.

Implementation guidance

Implementer focus

A good change process proves impact was assessed before the change, approval was obtained, testing happened, rollback was planned, and implementation was recorded.

1. Define change scope

Define what counts as a change. Include applications, infrastructure, cloud resources, networks, code, configurations, databases, business processes, integrations, security controls, and operational environments.

2. Require impact assessment

Assess business, technical, security, privacy, availability, operational, supplier, compliance, and user impact before approval.

3. Approve changes at the right level

Approval should match risk. Low-risk standard changes can use predefined approval. High-risk or production changes need formal authorization from business and technical owners.

4. Test before implementation

Testing should cover function, security, regression, access control, monitoring, logging, backup/recovery, vulnerability impact, and operational readiness where relevant.

5. Plan implementation and fallback

Each significant change should define the implementation window, communication plan, monitoring approach, stop criteria, rollback/failback steps, and recovery responsibilities.

6. Record and retain change history

Keep a complete history of what changed, who approved it, who implemented it, when it happened, what evidence was produced, and whether post-implementation review found issues.

7. Control emergency changes

Emergency changes still need authorization, logging, testing where possible, post-implementation review, and retrospective approval.

Audit guidance

Auditor focus

Sample real changes and trace request, risk/security impact, approval, testing, implementation, rollback, communication, and post-change review.

Auditors should verify:

change management responsibilities and procedures are defined;
changes cannot proceed without impact assessment and approval;
security impacts are explicitly considered;
testing is performed before operational implementation;
rollback/failback arrangements exist;
changes are logged and retained;
release records identify included changes;
configuration records and procedures are updated after changes;
emergency changes are controlled and reviewed.

Evidence examples

Evidence quality

Strong evidence proves the process operated on real changes, not only that a change policy exists.

Evidence	What it proves
Change management procedure	Process is defined
Change request record	Change is documented
Security impact assessment	Security effects were considered
Test evidence	Change was verified before release
Approval record	Authorized roles approved implementation
Rollback/failback plan	Failed change can be recovered
Implementation log	Actual change activity is traceable
Release record	Grouped changes are controlled
Post-implementation review	Outcome and issues were reviewed
Emergency change record	Urgent changes remain controlled

Strong evidence

Security impact is assessed before approval.
Test results match the change risk.
Rollback steps are documented and realistic.
Release records identify all included changes.
Emergency changes have post-implementation review.
Configuration and operational documentation are updated.

Weak evidence

Ticket says “approved” with no impact assessment.
Testing is implied but not evidenced.
Rollback plan says “restore backup” without detail.
Emergency changes are undocumented.
Release notes do not identify individual changes.
Security controls affected by the change are not reviewed.

Common failures

Implementation watchouts

A.8.32 fails when production change depends on heroics, informal approvals, or chat messages instead of controlled evidence.

Failure	Why it matters
No security impact assessment	Controls can be weakened without visibility
No rollback plan	Failed change becomes an incident
No testing evidence	Defects and vulnerabilities reach production
Emergency changes bypass review	Urgency becomes a control loophole
Release bundles hide individual changes	Traceability is lost
Documentation not updated	Operations and audits rely on stale information

Exam traps

Exam focus

Change management is broader than software deployment. It covers information processing facilities, systems, infrastructure, code, networks, and operational environments.

Trap	Correct interpretation
Change management only applies to application code	Infrastructure, networks, cloud, systems, and facilities can be in scope
Approval alone is enough	Impact assessment, testing, rollback, logging, and review also matter
Emergency changes are exempt	Emergency changes still need control and retrospective review
Functional testing is enough	Security controls and vulnerabilities introduced by change should be considered
Release management replaces change records	Release records should identify the underlying changes

KB-ready summary

Mentor takeaway

A.8.32 makes production change controlled and recoverable. Strong implementation proves every meaningful change has impact assessment, approval, testing, rollback, implementation evidence, and review.

Define what changes are in scope.
Assess business and security impact.
Approve changes before implementation.
Test before operational release.
Prepare rollback and stop criteria.
Record normal and emergency changes.
Update documentation after implementation.

Templates and checklists

Iso27001
Iso27002
Annex a
Technological controls
Change management
Release management

Note Metadata

Aliases: A.8.32, Change Management

Source: 05 Annex A Technological Controls/A.8.32 Change Management.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

links

Control

ISO 27001 A.8.32 - Change Management

Requirement context

Primary control text, framework notes, or adjacent controls this note points to.

Implementation artifacts

Templates and working records that help operate the control.

Evidence required

Evidence packs and proof records that support auditability.

A.8.32 Audit Evidence Pack

Audit checks

Audit questions, checklists, or review material connected to the control.

A.8.32 Audit Checklist

Risk treatment

Risk records and ISO 27005 material this control mitigates or supports.

Risk Assessment

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.

Risk treatment artifacts

Risk records, mappings, and treatment-supporting references.

Risk Assessment