1. Purpose
The Change Management Procedure defines how changes to information systems, applications, infrastructure, cloud environments, configurations, security controls, processes, and technology services are requested, assessed, approved, implemented, tested, monitored, and documented.
The objective is to ensure that changes:
- Have a legitimate business or technical purpose
- Are appropriately assessed for risk
- Do not unnecessarily introduce security weaknesses
- Are authorized before implementation
- Are tested where appropriate
- Can be reversed when necessary
- Are implemented by authorized personnel
- Are properly documented
- Generate appropriate evidence
- Are reviewed after implementation
Core Principle
Request → Assess → Approve → Plan → Test → Implement → Verify → Record → Review
2. Scope
This procedure applies to changes involving:
- Cloud infrastructure
- Servers
- Networks
- Firewalls
- Databases
- Applications
- Source code
- CI/CD pipelines
- Operating systems
- Security tools
- SaaS platforms
- Identity and access systems
- Production environments
- Development and test environments
- Configuration
- Security controls
- Backup systems
- Monitoring systems
- Business processes where security may be affected
- Third-party technology services
3. Change Management Information
| Field | Details |
|---|---|
| Procedure ID | |
| Procedure Owner | |
| Change Manager | |
| Technical Owner | |
| Security Owner | |
| Version | |
| Effective Date | |
| Review Date | |
| Classification | |
| Status | Draft / Approved / Retired |
| Approved By |
4. Change Management Objectives
The organization should ensure that:
☐ Changes have a defined purpose
☐ Change ownership is identified
☐ Security impact is considered
☐ Business impact is considered
☐ Risk is assessed
☐ Required approvals are obtained
☐ Testing is performed where appropriate
☐ Backups/recovery are considered
☐ Implementation is controlled
☐ Rollback is possible where practical
☐ Changes are verified
☐ Evidence is retained
☐ Unauthorized changes are identified
5. What Is a Change?
A change is any planned or unplanned modification that may affect an organization’s:
- Technology
- Information
- Security controls
- Configuration
- Availability
- Integrity
- Confidentiality
- Business processes
Examples include:
- Deploying new application code
- Modifying AWS security groups
- Changing IAM permissions
- Upgrading a database
- Installing a security tool
- Changing firewall rules
- Modifying DNS
- Changing backup configuration
- Updating operating systems
- Changing CI/CD pipelines
- Adding a new production service
6. Change Types
Classify each change appropriately.
☐ Standard Change
☐ Normal Change
☐ Emergency Change
☐ Major Change
☐ Minor Change
☐ Security Change
☐ Infrastructure Change
☐ Application Change
☐ Configuration Change
☐ Access-related Change
☐ Vendor/Supplier Change
The organization should define its own change categories and approval requirements.
7. Standard Changes
A Standard Change is a low-risk, repeatable activity that has been pre-approved.
Examples:
- Routine patching
- Approved user provisioning
- Routine certificate renewal
- Scheduled backup configuration
- Approved software deployment
Standard changes should still:
- Follow an approved procedure
- Be performed by authorized personnel
- Be recorded where required
- Be monitored
- Be reviewed periodically
8. Normal Changes
Normal changes require assessment and approval before implementation.
Examples:
- New production infrastructure
- Major application deployment
- Database schema changes
- Network architecture changes
- New security controls
- IAM architecture changes
9. Emergency Changes
Emergency changes may be required to:
- Respond to security incidents
- Fix critical vulnerabilities
- Restore critical services
- Prevent significant business impact
- Address major system failures
Emergency changes should be:
Authorized → Controlled → Implemented → Verified → Documented → Reviewed
Where prior approval is not practical, retrospective review should be performed according to the organization’s emergency-change process.
10. Change Request
Every significant change should have a documented change request.
Change Request
| Field | Details |
|---|---|
| Change ID | |
| Requester | |
| Date | |
| System | |
| Environment | |
| Change Type | |
| Change Description | |
| Business Reason | |
| Technical Reason | |
| Risk | |
| Planned Date | |
| Owner | |
| Approver |
11. Change Description
Describe:
- What is changing?
- Why is it changing?
- Which systems are affected?
- Which users/customers may be affected?
- What dependencies exist?
- What is the expected result?
Description
12. Business Justification
Every significant change should have a legitimate reason.
Examples:
- New business requirement
- Security improvement
- Vulnerability remediation
- Performance improvement
- Customer requirement
- Regulatory requirement
- Bug fix
- Infrastructure modernization
- Cost optimization
- Availability improvement
Business Justification
13. Change Impact Assessment
Assess potential impact on:
☐ Confidentiality
☐ Integrity
☐ Availability
☐ Customer data
☐ Personal data
☐ Production systems
☐ Business operations
☐ Security controls
☐ Compliance requirements
☐ Suppliers
☐ Employees/users
☐ Disaster recovery
☐ Backup
☐ Monitoring
☐ Access controls
Impact
14. Risk Assessment
Determine the risk associated with the change.
| Risk | Likelihood | Impact | Risk Level | Treatment |
|---|---|---|---|---|
Consider:
- Security risk
- Service interruption
- Data loss
- Data exposure
- Unauthorized access
- Configuration error
- Compliance impact
- Customer impact
- Recovery difficulty
15. Security Impact Assessment
Before approval, determine whether the change affects:
☐ Authentication
☐ MFA
☐ Access control
☐ Privileged access
☐ Encryption
☐ Logging
☐ Monitoring
☐ Network security
☐ Vulnerability management
☐ Backup
☐ Data protection
☐ Privacy
☐ Security architecture
Security Assessment
16. Information Classification Impact
Determine whether the change affects information classified as:
☐ Public
☐ Internal
☐ Confidential
☐ Restricted
Information Affected
17. Compliance Impact
Determine whether the change affects:
☐ ISO/IEC 27001 requirements
☐ Customer commitments
☐ Contractual requirements
☐ Privacy requirements
☐ Legal requirements
☐ Regulatory requirements
☐ Security commitments
☐ Internal policies
Compliance Impact
18. Dependencies
Identify dependencies before implementation.
| Dependency | Owner | Impact | Mitigation |
|---|---|---|---|
Consider:
- Applications
- Databases
- APIs
- Cloud services
- Suppliers
- Network connections
- Identity systems
- Monitoring
- Backup
- Security tools
19. Implementation Plan
Document the implementation steps.
| Step | Activity | Responsible | Expected Result |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 |
Implementation should be performed by authorized personnel.
20. Testing
Where appropriate, test the change before production implementation.
Testing may include:
☐ Functional testing
☐ Security testing
☐ Integration testing
☐ Performance testing
☐ Configuration validation
☐ Vulnerability testing
☐ Backup/recovery testing
☐ User acceptance testing
Test Results
21. Test Environment
Where practical, changes should be tested in an appropriate non-production environment before production implementation.
Consider:
- Development
- Test
- Staging
- Pre-production
Production data should not be unnecessarily copied into lower environments.
22. Change Approval
Approval should be based on the risk and impact of the change.
Possible approvers:
- System Owner
- Application Owner
- IT Operations
- Security
- Business Owner
- Change Manager
- Management
Approval Record
| Approver | Role | Decision | Date | Comments |
|---|---|---|---|---|
| Approved / Rejected | ||||
23. Change Window
Define the planned implementation window.
Start: __________________
End: __________________
Time Zone: __________________
Consider:
- Customer impact
- Business hours
- Monitoring availability
- Support availability
- Rollback time
- Dependency availability
24. Communication
Where appropriate, notify affected stakeholders.
☐ IT Operations
☐ Security
☐ Business Owner
☐ Customer Support
☐ Management
☐ Affected users
☐ Supplier
☐ Customers
Communication Plan
25. Backup and Recovery Preparation
Before high-risk changes:
☐ Backup completed
☐ Backup verified
☐ Recovery process available
☐ Recovery owner identified
☐ Recovery time considered
☐ Rollback approach documented
A backup should not automatically be assumed to be recoverable without appropriate validation.
26. Rollback Plan
Every significant change should have an appropriate rollback or recovery approach.
Rollback Trigger
Rollback Steps
| Step | Action | Owner |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 |
Rollback Verification
27. Production Implementation
Before implementation:
☐ Approval confirmed
☐ Change window confirmed
☐ Required personnel available
☐ Backup/recovery confirmed
☐ Monitoring active
☐ Rollback plan available
☐ Stakeholders informed
During implementation:
☐ Steps followed
☐ Activities recorded
☐ Unexpected issues recorded
☐ Security alerts monitored
☐ Service health monitored
28. Post-Implementation Verification
After implementation, verify:
☐ System available
☐ Application functioning
☐ Security controls functioning
☐ Access controls functioning
☐ Logging functioning
☐ Monitoring functioning
☐ Backup functioning
☐ Integrations functioning
☐ Expected performance achieved
☐ No unexpected security issue identified
Verification Result
29. Change Closure
A change may be closed when:
☐ Implementation completed
☐ Expected result achieved
☐ Verification completed
☐ Issues addressed
☐ Rollback not required
☐ Evidence recorded
☐ Stakeholders notified where required
☐ Change record updated
☐ Lessons learned captured where appropriate
Closure
Result: ☐ Successful ☐ Partially Successful ☐ Rolled Back ☐ Failed
Closure Date: __________________
Closed By: __________________
30. Failed Changes
If a change fails:
- Stabilize the affected service.
- Activate rollback/recovery where necessary.
- Assess business and security impact.
- Record the failure.
- Investigate the cause.
- Communicate significant impact.
- Correct the underlying issue.
- Determine whether a new change is required.
- Capture lessons learned.
31. Unauthorized Changes
Unauthorized changes should be identified and assessed.
Examples:
- Unapproved production configuration
- Unapproved firewall modification
- Unauthorized IAM permission change
- Unapproved software deployment
- Direct production database modification
Such changes should be:
☐ Recorded
☐ Investigated
☐ Risk assessed
☐ Reverted or formally approved where appropriate
☐ Escalated
☐ Addressed through corrective action where necessary
32. Configuration Changes
Configuration changes may include:
- Firewall rules
- Security groups
- IAM policies
- Operating-system settings
- Database settings
- Application configuration
- DNS
- Encryption settings
- Monitoring configuration
Configuration changes should be traceable to an authorized change where required.
33. Access-Related Changes
Changes to access permissions should follow the Access Management Procedure.
Examples:
- New administrator
- Permission modification
- Production access
- IAM policy change
- Group membership change
- Supplier access
Principle
Access Change → Authorization → Implementation → Verification → Record
34. Security Changes
Security changes may include:
- Firewall configuration
- MFA configuration
- Endpoint security
- SIEM rules
- Detection rules
- Encryption
- Security policies
- Vulnerability remediation
- Security tooling
Security changes should be tested and monitored appropriately.
35. Cloud Changes
For cloud environments, changes may include:
- New AWS resources
- IAM policies
- Security groups
- VPC configuration
- S3 permissions
- RDS configuration
- CloudTrail
- CloudWatch
- Encryption
- Backup
- Auto-scaling
- DNS
- Production deployments
Cloud changes should be traceable to approved requests where required.
36. CI/CD Changes
CI/CD pipelines can directly affect production systems.
Changes to:
- Deployment pipelines
- Build scripts
- Infrastructure-as-code
- Secrets
- Deployment permissions
- Production environments
should be controlled appropriately.
☐ Code reviewed
☐ Approval obtained
☐ Security impact considered
☐ Testing completed
☐ Deployment controlled
☐ Rollback available
37. Infrastructure-as-Code
Where infrastructure is managed through code:
☐ Changes tracked in version control
☐ Peer review performed where appropriate
☐ Security checks performed
☐ Testing performed
☐ Deployment authorized
☐ Change traceability maintained
Examples:
- Terraform
- CloudFormation
- Ansible
- Kubernetes manifests
38. Emergency Change Procedure
When immediate action is required:
Step 1 — Identify
Determine why emergency action is required.
Step 2 — Assess
Determine the immediate security/business impact.
Step 3 — Authorize
Obtain emergency approval where practical.
Step 4 — Implement
Perform the minimum necessary change.
Step 5 — Monitor
Closely monitor the result.
Step 6 — Verify
Confirm service/security stability.
Step 7 — Document
Complete the change record.
Step 8 — Review
Perform retrospective review.
39. Change Monitoring
After significant changes, monitor:
☐ System availability
☐ Application performance
☐ Security alerts
☐ Authentication
☐ Error rates
☐ Network traffic
☐ Database health
☐ Backup status
☐ Customer impact
Monitoring duration should reflect the risk of the change.
40. Change Evidence
Maintain appropriate evidence such as:
☐ Change request
☐ Business justification
☐ Risk assessment
☐ Security assessment
☐ Approval
☐ Test results
☐ Implementation record
☐ Deployment logs
☐ Configuration records
☐ Monitoring results
☐ Rollback evidence
☐ Post-implementation verification
☐ Closure record
Do not retain passwords, API keys, private keys, or other secrets as change evidence.
41. Change Exceptions
Where the standard change process cannot be followed:
☐ Reason documented
☐ Risk assessed
☐ Compensating controls identified
☐ Appropriate approval obtained
☐ Change recorded
☐ Retrospective review performed where required
42. Change Metrics
Possible metrics include:
| Metric | Target | Frequency |
|---|---|---|
| Successful changes | ||
| Failed changes | ||
| Emergency changes | ||
| Unauthorized changes | ||
| Changes requiring rollback | ||
| Change-related incidents | ||
| Changes completed on schedule | ||
| Changes without required approval |
Metrics should be used to identify trends and improve change management.
43. Change Review
Periodically review changes to identify:
- Repeated failures
- Recurring emergency changes
- Unauthorized changes
- Inadequate testing
- Incomplete approvals
- Poor rollback planning
- Security weaknesses
- Process bottlenecks
Review Record
| Review Date | Reviewer | Findings | Actions |
|---|---|---|---|
44. Change-Related Incidents
If a change causes or contributes to a security incident or major service disruption:
- Initiate incident management.
- Stabilize the environment.
- Preserve relevant evidence.
- Assess impact.
- Investigate root cause.
- Determine corrective action.
- Review the change-management process.
45. Corrective Action
For significant change-related failures:
| Issue | Root Cause | Corrective Action | Owner | Due Date | Status |
|---|---|---|---|---|---|
Corrective actions should be verified for effectiveness before closure.
46. Roles and Segregation of Duties
Where practical, separate:
- Change requester
- Change approver
- Change implementer
- Change reviewer
For low-risk or small-team environments, complete separation may not always be practical. Where duties overlap, appropriate compensating controls should be considered.
47. Change Frequency
The organization should determine review and approval requirements based on:
- Change risk
- System criticality
- Production impact
- Security sensitivity
- Change complexity
- Regulatory requirements
- Customer commitments
High-risk changes should receive greater scrutiny than routine low-risk changes.
48. AWS SaaS Startup Example
Scenario
A SaaS startup needs to modify an AWS production security group to allow application traffic to a new service.
Change Request
Change: Add inbound HTTPS rule.
Reason: New production application service.
System: AWS production VPC.
Risk: Potential unauthorized network exposure.
Process
1. Request
Engineer creates a change ticket.
2. Assessment
Review:
- Source IP/range
- Destination
- Port
- Business requirement
- Security impact
3. Approval
Engineering/System Owner approves.
Security reviews the change where required.
4. Testing
Validate configuration in a suitable environment where practical.
5. Implementation
Authorized engineer applies the change.
6. Verification
Confirm:
- Application connectivity
- Security group configuration
- Logs
- Monitoring
- No unintended exposure
7. Evidence
Retain:
- Change ticket
- Approval
- Configuration/IaC commit
- Test result
- Deployment record
- Verification evidence
8. Closure
Close the change after successful validation.
49. Startup-Friendly Change Management Model
A startup does not need a complicated Change Advisory Board for every change.
Low Risk
Request → Approved Standard Change → Implement → Record
Normal Change
Request → Impact/Risk → Approval → Test → Implement → Verify → Close
High-Risk Change
Request → Detailed Risk → Security Review → Approval → Test → Backup → Implement → Monitor → Verify → Close
Emergency Change
Assess → Emergency Approval → Implement → Monitor → Stabilize → Document → Review
The objective is to control risk without creating unnecessary operational bureaucracy.
50. Common Mistakes
Avoid:
- Making production changes without records.
- Allowing developers to bypass change controls.
- Treating all changes as equally risky.
- Having no rollback plan for high-risk changes.
- Failing to test changes.
- Approving changes without understanding impact.
- Not considering security impact.
- Failing to monitor after implementation.
- Making direct production database changes without traceability.
- Treating emergency changes as a permanent bypass.
- Failing to review failed changes.
- Ignoring unauthorized changes.
- Not controlling infrastructure-as-code changes.
- Retaining secrets in change tickets.
- Closing changes without verifying the expected result.
51. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Change Management Policy | Defines change-control requirements |
| IT Operations Procedure | Defines operational activities |
| Access Management Procedure | Controls access-related changes |
| Configuration Management Procedure | Controls configuration |
| Vulnerability Management Procedure | Addresses security remediation |
| Incident Response Procedure | Handles incidents caused by changes |
| Backup & Restore Procedure | Supports recovery |
| Business Continuity Plan | Supports major disruption |
| Cloud Security Policy | Governs cloud changes |
| Risk Assessment | Assesses change-related risk |
| Exception Register | Records deviations |
| Corrective Action Tracker | Tracks change-related weaknesses |
| Supplier Change Procedure | Controls supplier changes |
52. ISO/IEC 27001 Connection
Change management supports the organization’s risk-based approach to information security by ensuring that changes affecting information systems and security controls are appropriately assessed, authorized, implemented, and reviewed.
The exact change controls and procedures should be determined based on:
- ISMS scope
- Risk assessment
- Risk treatment
- Statement of Applicability
- Applicable controls
- Technology architecture
- Business requirements
- Legal/regulatory requirements
- Customer requirements
- Contractual requirements
This Change Management Procedure is not itself a universally prescribed ISO/IEC 27001 document. The organization should maintain appropriate documented information and operational evidence to demonstrate that relevant changes are controlled.
53. Audit Evidence Checklist
An auditor should be able to trace:
☐ Change policy
☐ Change procedure
☐ Change request
☐ Business justification
☐ Risk assessment
☐ Security assessment
☐ Approval
☐ Test evidence
☐ Implementation record
☐ Deployment evidence
☐ Configuration evidence
☐ Monitoring evidence
☐ Rollback/recovery evidence
☐ Post-change verification
☐ Change closure
☐ Emergency changes
☐ Unauthorized changes
☐ Change metrics
☐ Corrective actions
54. Final Change Management Audit Trail
For every significant change, the organization should be able to demonstrate:
What was changed?
Why was it changed?
Who requested it?
What systems and information were affected?
What security and business risks were identified?
Who approved it?
Was it tested?
How was it implemented?
What was the rollback/recovery approach?
How was the result verified?
What evidence was retained?
What was learned from the change?
Final Principle
Change management is not about preventing change. It is about ensuring that necessary change happens in a controlled, authorized, tested, traceable, and recoverable manner.