ISO 27001A.8 — Change management
A.8.32
Change management
ISO 27001 · ISO/IEC 27001:2022 · Last verified July 2026
Objective
Manage changes to information processing facilities and information systems so that security is preserved and unauthorized changes are prevented.
Points of focus
- Change types classified (standard / normal / emergency)
- Authorization before production change
- Testing and rollback considered
- Emergency changes retrospectively reviewed
Implementation notes
Route production changes through PR + CI with required reviewers and protected branches. Bind deploys to change tickets. Document emergency hotfix rules and force post-implementation review. Keep infra-as-code under the same discipline as app code. Crosswalk to SOC 2 CC8.1 so one pipeline story serves both audits.
Audit tip: Sample a normal and an emergency change end-to-end: request, approval, deploy artifact, verification.
Evidence auditors typically request:
- Change / deploy policy
- PR approval and CI required-check configuration
- Production deploy logs with actor and change ID
- Emergency change post-reviews
Common gaps
- Direct-to-prod pushes without review
- Emergency path used as the default
- No linkage between ticket and deploy SHA
Cross-Framework Mapping
| Framework | Requirement | Implementation note |
|---|---|---|
| ISO 27001 | A.8.32 | This control |
| SOC 2 | CC8.1 | Related Trust Services Criteria themes — map in your crosswalk; not identical requirements. |
Primary sources
- ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.32)
Frequently Asked Questions
If they alter production behavior or data exposure, treat them as changes with ownership and audit trail.
Segregation expectations scale with risk. Document compensating controls when the same engineer authors and deploys, and tighten as headcount grows.
A.8.9 emphasizes secure baselines and configuration state; A.8.32 emphasizes the process of changing that state safely.