ISO/IEC 27001:2022 Annex A 8.32 – Change Management focuses on controlling changes to information processing facilities, systems, applications, infrastructure, configurations, and other technology that could affect information security.
In a startup or fast-growing technology company, changes happen continuously:
- New application releases
- Cloud configuration changes
- Firewall changes
- Database modifications
- Operating system updates
- Security rule changes
- API changes
- Infrastructure changes
- New integrations
- Emergency fixes
The objective of A.8.32 is not to stop changes or create unnecessary bureaucracy.
The objective is to make sure that security-impacting changes are planned, assessed, authorized, tested where appropriate, implemented in a controlled manner, and traceable.
What Is ISO 27001 Annex A 8.32?
A.8.32 requires organizations to establish a controlled approach for changes to information processing facilities and information systems.
A change management process should help the organization answer:
- What is changing?
- Why is it changing?
- Who requested it?
- What could go wrong?
- What is the security impact?
- Has the change been tested?
- Who approved it?
- When will it be implemented?
- How will the change be monitored?
- What is the rollback plan?
- Was the change successful?
The level of control should be appropriate to the organization’s size, technology, risk, and type of change.
Why Is Change Management Important?
Uncontrolled changes are a common source of security and operational problems.
1. Security misconfiguration
A firewall or cloud security rule can accidentally expose a sensitive system.
2. Service disruption
A software or infrastructure change can cause downtime.
3. Data loss
Incorrect database changes can result in corruption or deletion.
4. Vulnerabilities
A change can unintentionally disable a security control or introduce vulnerable functionality.
5. Unauthorized changes
Someone may modify a production system without appropriate authorization.
6. Compliance issues
An organization may be unable to demonstrate who made a change and whether it was approved.
7. Difficult incident investigation
Without change records, it becomes difficult to determine what changed before a security incident.
What Types of Changes Should Be Controlled?
Change management should cover changes that can affect information security or the organization’s information processing environment.
Examples include:
| Change Category | Examples |
|---|---|
| Application | New feature, code release, API modification |
| Infrastructure | New server, VM, container, Kubernetes configuration |
| Cloud | IAM, security groups, storage permissions, cloud services |
| Network | Firewall, routing, VPN, DNS, segmentation |
| Database | Schema, permissions, configuration |
| Operating system | OS upgrade, patch, configuration |
| Security | EDR, SIEM, firewall, WAF, security policy |
| Identity | SSO, MFA, roles, privileged access |
| Third-party | SaaS integration, API, vendor configuration |
| Configuration | Application settings, security parameters |
| Data | Data migration or structural changes |
| Backup | Backup configuration or retention changes |
Not every minor activity requires the same level of approval.
Change Categories
A practical organization can classify changes into categories.
1. Standard Change
A routine, low-risk, repeatable change with an established procedure.
Examples:
- Routine approved patching
- Standard user configuration
- Pre-approved maintenance activity
Standard changes can follow a predefined workflow.
2. Normal Change
A change that requires assessment and authorization before implementation.
Examples:
- Major application release
- Firewall rule modification
- Database configuration change
- Cloud architecture modification
3. Emergency Change
A change that must be implemented quickly because waiting for the normal process could create greater risk.
Examples:
- Critical vulnerability remediation
- Active security incident
- Major production outage
- Compromised credentials
- Critical infrastructure failure
Emergency changes should still be documented and reviewed afterward.
Change Management Lifecycle
A practical change management process can follow this lifecycle:
Change Request
↓
Impact & Risk Assessment
↓
Security Review
↓
Approval
↓
Testing
↓
Implementation
↓
Monitoring
↓
Validation
↓
Closure
↓
Post-Implementation Review
Not every change needs the same depth of review.
The process should be risk-based.
Step 1 – Raise a Change Request
The person requesting the change should document sufficient information.
Typical information includes:
- Change description
- Business reason
- Systems affected
- Requested implementation date
- Requester
- Owner
- Security impact
- Expected downtime
- Dependencies
- Testing requirements
- Rollback plan
Step 2 – Assess the Risk
Before implementation, determine what could go wrong.
Consider:
- Confidentiality impact
- Integrity impact
- Availability impact
- Customer impact
- Regulatory impact
- Security control impact
- Dependency impact
- Business continuity impact
For example:
Change: Modify a production firewall rule.
Potential risks:
- Unauthorized access
- Internet exposure
- Service disruption
- Exposure of administrative interfaces
Therefore, the change should receive appropriate security review.
Step 3 – Identify Security Impact
A change should be reviewed for its impact on existing security controls.
Questions may include:
- Does this change affect authentication?
- Does it affect authorization?
- Does it expose a new network service?
- Does it affect encryption?
- Does it affect logging?
- Does it affect monitoring?
- Does it affect backup?
- Does it affect access control?
- Does it introduce a new third-party dependency?
- Does it change how personal or sensitive information is processed?
Step 4 – Obtain Approval
Appropriate personnel should authorize the change before implementation.
The approver should have sufficient authority and understanding of the change.
Depending on the organization, approval could involve:
- Engineering manager
- System owner
- IT administrator
- Security team
- CISO/vCISO
- Application owner
- Business owner
For low-risk standard changes, a predefined approval may be sufficient.
Step 5 – Test the Change
Changes should be tested where appropriate before being introduced into production.
Testing may occur in:
- Development
- Test
- QA
- Staging
This connects directly with A.8.31 – Separation of development, test and production environments.
For example:
Development
↓
Testing
↓
Staging
↓
Production
Step 6 – Define a Rollback Plan
Before implementing a significant change, determine what happens if it fails.
A rollback plan might include:
- Restore previous application version
- Revert infrastructure configuration
- Restore database backup
- Reverse firewall rule
- Disable new feature
- Restore previous configuration
For high-risk changes, rollback procedures should be tested where practical.
Step 7 – Implement the Change
The change should be implemented according to the approved plan.
Important information to record includes:
- Implementation date/time
- Person performing the change
- Actual changes made
- Unexpected issues
- Downtime
- Deviations from the approved plan
Step 8 – Monitor the Change
After implementation, monitor the affected systems.
Look for:
- Errors
- Security alerts
- Performance degradation
- Availability issues
- Authentication failures
- Customer complaints
- Unexpected network traffic
- Application failures
Step 9 – Validate the Result
Confirm that:
- The intended change was completed.
- The system works as expected.
- Security controls remain effective.
- No unauthorized configuration was introduced.
- Monitoring is working.
- Required documentation is updated.
Step 10 – Close the Change
The change record should be formally closed.
Record:
- Result
- Validation
- Issues
- Rollback, if applicable
- Lessons learned
- Final status
For major changes, a post-implementation review may be useful.
Example – SaaS Startup
Imagine a SaaS company wants to change its production database configuration.
Poor approach
A developer directly modifies the production database.
There is:
- No ticket
- No approval
- No testing
- No rollback plan
- No record
If the database fails, the organization may not know exactly what happened.
Controlled approach
Change Request
↓
Database Impact Assessment
↓
Security Review
↓
Approval
↓
Test in Staging
↓
Backup Verification
↓
Scheduled Production Change
↓
Monitoring
↓
Validation
↓
Closure
This creates accountability without necessarily creating excessive bureaucracy.
Emergency Change Example
Suppose a critical vulnerability is discovered in a production application.
Waiting several days for the normal change process may increase risk.
The organization can use an emergency change procedure:
Critical Vulnerability
↓
Emergency Assessment
↓
Authorized Emergency Approval
↓
Immediate Fix
↓
Monitoring
↓
Testing / Validation
↓
Post-Implementation Review
The emergency process should not mean “no controls.”
It means using an accelerated and documented process appropriate to the situation.
Change Management for Cloud Environments
Modern startups often operate entirely in cloud environments.
Change management should therefore cover changes to:
- AWS
- Microsoft Azure
- Google Cloud
- Kubernetes
- Terraform
- CloudFormation
- IAM
- Security groups
- Firewalls
- WAF
- Storage permissions
- Databases
- Serverless services
- CI/CD pipelines
For infrastructure-as-code environments, version control and pull-request approvals can provide valuable change evidence.
Example:
Terraform Change
↓
Git Pull Request
↓
Code Review
↓
Security Check
↓
Approval
↓
CI/CD
↓
Cloud Deployment
↓
Monitoring
Change Management and DevOps
Change management does not require organizations to abandon DevOps or deploy slowly.
A mature DevOps process can automate many controls.
For example:
- Pull requests
- Branch protection
- Automated testing
- SAST
- Dependency scanning
- Infrastructure-as-code review
- Automated approvals
- CI/CD deployment
- Deployment logs
- Automated rollback
This allows organizations to maintain speed with control.
What Events Should Trigger Change Management?
Organizations should consider a change-management process whenever there is a significant modification to:
- Applications
- Infrastructure
- Network architecture
- Cloud configuration
- Security controls
- Databases
- Operating systems
- Identity systems
- Production configuration
- Third-party integrations
- Data processing
- Backup systems
- Monitoring systems
Startup Quick Summary
For a startup, change management does not need to become a large ITIL-style bureaucracy.
A practical process can be:
Request → Assess → Approve → Test → Implement → Monitor → Close
For high-risk changes, add:
Security review + rollback plan + post-implementation review
For emergency changes:
Emergency approval + immediate implementation + retrospective review
Minimum Startup Implementation
A startup should at minimum establish:
1. Change management procedure
Document how significant changes are handled.
2. Change register
Maintain records of relevant changes.
3. Risk classification
Identify standard, normal, and emergency changes where appropriate.
4. Approval
Ensure significant production changes are authorized.
5. Testing
Test changes before production where practical.
6. Rollback
Define how important changes can be reversed.
7. Production controls
Restrict unauthorized direct production changes.
8. Monitoring
Monitor systems after important changes.
9. Emergency process
Define how urgent security or availability changes are handled.
10. Evidence
Retain tickets, approvals, testing results and deployment records.
Simple Change Management Register
A simple register can look like this:
| Change ID | Date | System | Change | Risk | Requester | Approver | Testing | Rollback | Status |
|---|---|---|---|---|---|---|---|---|---|
| CHG-001 | 10-Sep | Web App | Version update | Medium | Engineering | Tech Lead | Completed | Yes | Closed |
| CHG-002 | 12-Sep | Firewall | Rule update | High | IT | Security | Completed | Yes | Closed |
| CHG-003 | 15-Sep | Database | Schema change | High | Engineering | App Owner | Completed | Yes | Closed |
The actual register should reflect the organization’s change process.
Change Risk Classification
Organizations can define their own risk criteria.
| Risk | Typical Example | Control Level |
|---|---|---|
| Low | Routine approved configuration | Standard process |
| Medium | Application release | Testing + approval |
| High | Firewall/database/security change | Detailed assessment + approval + rollback |
| Emergency | Critical security fix | Emergency process + retrospective review |
Risk classification should be based on the organization’s environment and risk assessment rather than blindly applying the same process to every change.
Audit Evidence for A.8.32
An auditor may request evidence such as:
Policies and procedures
- Change Management Policy
- Change Management Procedure
- Emergency Change Procedure
- Release Management Procedure
Change records
- Change tickets
- Change register
- Pull requests
- Deployment records
- Configuration changes
Approval
- Approval records
- Security reviews
- Management approvals
- Application owner approvals
Testing
- Test results
- QA records
- Security testing
- UAT records
- Staging evidence
Implementation
- Deployment logs
- CI/CD logs
- Infrastructure-as-code commits
- Cloud activity logs
Recovery
- Rollback plans
- Backup verification
- Recovery records
Post-change
- Monitoring records
- Validation
- Post-implementation review
- Incident records, where applicable
ISO 27001 A.8.32 Audit Checklist
| # | Audit Question | Evidence |
|---|---|---|
| 1 | Is there a documented change management process? | Policy/procedure |
| 2 | Are security-impacting changes identified? | Change assessment |
| 3 | Are changes risk-assessed? | Change tickets |
| 4 | Are significant changes approved? | Approval records |
| 5 | Are changes tested before production where appropriate? | Test evidence |
| 6 | Are production changes controlled? | Deployment/change records |
| 7 | Is a rollback plan defined for significant changes? | Change record |
| 8 | Are emergency changes documented? | Emergency change records |
| 9 | Are changes monitored after implementation? | Monitoring evidence |
| 10 | Are unsuccessful changes investigated? | Incident/change records |
| 11 | Are change records retained? | Change register |
| 12 | Are changes traceable to individuals? | User/deployment logs |
| 13 | Are infrastructure and cloud changes included? | Cloud/IaC records |
| 14 | Are security controls reviewed when relevant? | Security assessment |
| 15 | Are major changes subject to post-implementation review? | Review records |
Common Mistakes
Mistake 1 – Treating change management as paperwork
A change ticket alone does not make the process effective.
The actual technical implementation should match the approved change.
Mistake 2 – No production change control
Developers or administrators should not be able to make unrestricted production changes without appropriate controls.
Mistake 3 – No testing
Important changes should be tested appropriately before production implementation.
Mistake 4 – No rollback plan
A major production change without a recovery strategy creates unnecessary risk.
Mistake 5 – Emergency changes are undocumented
Emergency does not mean undocumented.
The organization should maintain an accelerated process and review the change afterward.
Mistake 6 – Ignoring cloud configuration
Change management should cover cloud infrastructure, not just application code.
Mistake 7 – Ignoring infrastructure-as-code
Terraform, CloudFormation, Kubernetes and similar infrastructure changes can materially affect information security and should be appropriately controlled.
Mistake 8 – One process for every change
A small routine change should not necessarily require the same approval process as a major production database or firewall change.
A risk-based approach is generally more practical.
Policy vs Process vs Technical Control
| Area | Example |
|---|---|
| Policy | Security-impacting changes must be appropriately controlled |
| Procedure | Define request, assessment, approval, testing and implementation |
| Technical Control | Branch protection, CI/CD, IAM and deployment controls |
| Process Control | Change approval and testing |
| Monitoring | Deployment and administrative logs |
| Evidence | Tickets, approvals, test results and deployment records |
Relationship With Other ISO 27001 Controls
A.8.32 works closely with several other controls.
| Control | Relationship |
|---|---|
| A.8.25 Secure Development Life Cycle | Security throughout software development |
| A.8.26 Application Security Requirements | Security requirements for application changes |
| A.8.29 Security Testing in Development and Acceptance | Security testing before release |
| A.8.31 Separation of Development, Test and Production Environments | Controls movement between environments |
| A.8.9 Configuration Management | Maintains controlled configurations |
| A.8.8 Management of Technical Vulnerabilities | Addresses vulnerabilities that may require changes |
| A.8.15 Logging | Provides evidence of activities |
| A.8.16 Monitoring Activities | Detects unexpected activity |
| A.5.8 Information Security in Project Management | Integrates security into projects |
A.8.31 vs A.8.32
These two controls are frequently confused.
| Control | Main Question |
|---|---|
| A.8.31 | Are development, test and production environments appropriately separated? |
| A.8.32 | Are changes to systems and information-processing environments appropriately controlled? |
Example:
A developer creates a new application feature.
A.8.31: The feature should be developed and tested separately from production.
A.8.32: The deployment of the approved feature into production should be controlled and traceable.
Practical Implementation Model
A startup can implement A.8.32 using:
CHANGE IDENTIFIED
|
v
CHANGE REQUEST
|
v
RISK ASSESSMENT
|
+----------+----------+
| |
v v
NORMAL EMERGENCY
| |
v v
APPROVAL EMERGENCY APPROVAL
| |
+----------+----------+
|
v
TEST
|
v
IMPLEMENTATION
|
v
MONITOR
|
v
VALIDATE
|
v
CLOSE
|
v
POST-IMPLEMENTATION
REVIEW IF NEEDED
Useful Resources
Organizations implementing A.8.32 may benefit from maintaining:
- Draft Change Management Policy —
[Insert Document Link] - Change Management Procedure —
[Insert Document Link] - Change Request Form —
[Insert Document Link] - Change Management Register —
[Insert Document Link] - Emergency Change Procedure —
[Insert Document Link] - Change Risk Assessment Template —
[Insert Document Link] - Production Deployment Checklist —
[Insert Document Link] - Post-Implementation Review Template —
[Insert Document Link] - Rollback Plan Template —
[Insert Document Link]
Final Takeaway
ISO 27001 Annex A 8.32 is not about preventing organizations from changing their technology.
It is about ensuring that important changes are understood, authorized, tested where appropriate, implemented in a controlled manner, monitored, and traceable.
For startups, a practical model is:
Request → Assess → Approve → Test → Implement → Monitor → Close
The process should remain proportionate to risk. A routine low-risk change should not receive the same treatment as a major production database, firewall, identity, or security architecture change.
The ultimate objective is simple:
Change quickly when the business needs it—but make security-impacting changes controlled, traceable, and recoverable.