1. Purpose
The Emergency Change Procedure defines how urgent changes to information systems, applications, infrastructure, cloud environments, security controls, configurations, and production services are assessed, approved, implemented, monitored, and reviewed when following the normal change-management process would create unacceptable delay or risk.
Emergency changes may be required to:
- Restore a critical business service.
- Contain an active security incident.
- Remediate a critical vulnerability.
- Recover from a disaster.
- Prevent significant data loss.
- Address a critical cloud or infrastructure failure.
- Correct a serious production defect.
- Protect customer information.
- Respond to an urgent supplier or technology issue.
The objective is:
Respond quickly without turning an emergency into an uncontrolled change.
2. Scope
This procedure applies to emergency changes involving:
- Production systems
- Cloud infrastructure
- AWS accounts and services
- Applications and APIs
- Databases
- Networks and firewalls
- IAM and privileged access
- Security controls
- WAF and endpoint controls
- CI/CD pipelines
- Source code
- Infrastructure as Code
- DNS
- Backup and recovery systems
- Monitoring and logging
- Encryption and key-management systems
- SaaS platforms
- Third-party integrations
- Customer-facing services
- Recovery environments
3. Emergency Change Principle
An emergency change is still a change.
The organization should not interpret an emergency as permission to:
- Skip security completely.
- Make undocumented production changes.
- Use unauthorized credentials.
- Disable logging without justification.
- Bypass testing unnecessarily.
- Leave temporary configuration permanently in place.
The emergency process reduces time and administrative overhead, but retains appropriate risk control.
4. When an Emergency Change May Be Used
Examples include:
Security
- Active cyberattack
- Compromised account
- Critical vulnerability exploitation
- Malware or ransomware containment
- Unauthorized access
- Data breach containment
- Malicious configuration change
Availability
- Major production outage
- Critical database failure
- Network failure
- DNS failure
- Cloud service disruption
- Application failure
Recovery
- Disaster recovery activation
- Emergency backup restoration
- Critical infrastructure rebuild
- Failover to a recovery environment
Business
- Critical customer service disruption
- Major transaction-processing failure
- Regulatory or contractual emergency
- Critical supplier failure
5. When an Emergency Change Should Not Be Used
The emergency process should not be used merely because:
- A normal change was not planned.
- Someone forgot to submit a change request.
- A routine task is inconvenient.
- The normal approval process takes time.
- A project deadline is approaching.
- A developer wants immediate production access.
- Testing was skipped for convenience.
If the change is important but not genuinely urgent, use the normal change-management process.
6. Emergency Change Lifecycle
Emergency Identified
↓
Change Required Confirmed
↓
Impact & Risk Assessed
↓
Emergency Change Classified
↓
Approval Obtained
↓
Implementation Plan Defined
↓
Backup/Rollback Prepared
↓
Change Implemented
↓
Security & Service Validation
↓
Enhanced Monitoring
↓
Rollback if Required
↓
Post-Implementation Review
↓
Normal Change Record Updated
↓
Change Closed
7. Emergency Change Roles
| Role | Responsibility |
|---|---|
| Change Requestor | Identifies and documents the emergency change |
| Change Implementer | Performs the technical change |
| Technical Owner | Confirms technical requirement and impact |
| Security Lead | Reviews security implications |
| Incident Commander | Coordinates changes during security incidents |
| Business Owner | Confirms business impact |
| Change Approver | Authorizes the emergency change |
| Tester/Validator | Confirms the change achieved the intended result |
| Management | Provides escalation/approval for significant changes |
One person may perform multiple roles in a startup, provided conflicts of interest and risk are appropriately managed.
8. Step 1 — Identify the Emergency
Create an emergency change record.
Minimum information:
- Change ID
- Date/time
- Requestor
- Affected system
- Business service
- Emergency reason
- Related incident/DR record
- Required action
- Expected impact
- Proposed implementation time
Example:
EC-2026-0007
Critical vulnerability identified in an internet-facing production component. Emergency patch required to reduce active exploitation risk.
9. Step 2 — Confirm That an Emergency Change Is Required
Determine:
- What is happening?
- What happens if no change is made?
- Is there an active security or business risk?
- Can the issue be controlled without a system change?
- Can the normal change process be followed safely?
- What is the consequence of waiting?
The emergency route should be selected based on risk and urgency.
10. Emergency Change Categories
| Category | Example |
|---|---|
| EC-1 Critical Security | Active exploitation or compromised system |
| EC-2 Critical Availability | Major production outage |
| EC-3 Critical Data | Data corruption or loss risk |
| EC-4 Disaster Recovery | Recovery of critical service |
| EC-5 Critical Vulnerability | Urgent security patch |
| EC-6 Critical Business | Major customer/business disruption |
| EC-7 Other | Other genuinely urgent situation |
11. Step 3 — Assess the Change
Before implementation, assess:
Business Impact
- Customer impact
- Revenue impact
- Critical business process
- Service availability
- Contractual impact
Security Impact
- Confidentiality
- Integrity
- Availability
- Authentication
- Authorization
- Logging
- Monitoring
- Encryption
- Data protection
Technical Impact
- Infrastructure
- Application
- Database
- Network
- Cloud
- Dependencies
- Integrations
Recovery Impact
- Backup
- Rollback
- Failover
- Recovery environment
- Data consistency
12. Step 4 — Define the Minimum Change
The change should be as limited as practical.
Document:
- What will change?
- What will not change?
- Which system/resource will be affected?
- Which environment?
- Which configuration/code/component?
- Who will implement it?
- When?
- What is the expected result?
Avoid combining unrelated changes into an emergency change.
13. Step 5 — Assess Risk
Consider:
| Risk Area | Question |
|---|---|
| Availability | Could the change cause an outage? |
| Security | Could security controls be weakened? |
| Data | Could information be lost or corrupted? |
| Access | Could privileges change? |
| Dependencies | Could another service fail? |
| Recovery | Can the change be reversed? |
| Customer | Could customers be affected? |
| Compliance | Could regulatory/contractual requirements be affected? |
Record the identified risks and available controls.
14. Step 6 — Emergency Approval
Emergency changes should be approved by an authorized person.
Approval should consider:
- Urgency
- Risk
- Business impact
- Security impact
- Technical impact
- Implementation approach
- Rollback capability
- Monitoring
- Testing available before implementation
For major security incidents, the Incident Commander or authorized Security Lead may approve the change under the organization’s emergency authority.
15. Emergency Approval Model
| Change | Typical Approval |
|---|---|
| Critical security containment | Security Lead / Incident Commander |
| Critical production recovery | Technical Lead / Business Owner |
| Critical vulnerability patch | Security Lead / Technical Owner |
| Disaster recovery change | DR/Technical Lead |
| High-impact customer service change | Technical + Business authority |
| Major infrastructure change | Technical Lead + Management as required |
The organization’s defined authority matrix should take precedence.
16. Step 7 — Prepare the Implementation
Before making the change, define:
- Implementation steps
- Responsible person
- Start time
- Expected duration
- Dependencies
- Backup requirements
- Rollback steps
- Validation steps
- Monitoring requirements
- Communication requirements
Where practical, prepare a rollback before implementation begins.
17. Step 8 — Backup and Recovery Preparation
Depending on the change, consider:
- Database backup
- Snapshot
- Configuration backup
- Infrastructure state
- Previous application version
- Previous container/image
- Infrastructure-as-Code version
- DNS configuration
- Firewall configuration
- Security policy version
For critical systems:
Do not make an irreversible change without understanding the recovery consequence.
18. AWS Example — Emergency Security Group Change
Suppose an exposed production workload is being actively targeted.
An emergency change may be required to restrict inbound traffic.
Process
- Incident identified.
- Security group identified.
- Current configuration captured.
- Emergency change created.
- Security impact assessed.
- Change approved.
- Restricted rule implemented.
- Application connectivity tested.
- CloudTrail activity reviewed.
- Security monitoring increased.
- Permanent architecture change identified if required.
- Post-change review completed.
Evidence should include the original configuration, approval, change activity, validation, and final configuration.
19. Step 9 — Testing Before Implementation
Testing should be performed where practical.
Possible methods:
- Test environment
- Staging
- Sandbox
- Configuration validation
- Automated tests
- Security validation
- Peer review
- Dry run
- Infrastructure-as-Code validation
During a true emergency, complete testing may not be possible.
If testing is reduced or skipped, document:
- Why testing could not be completed.
- What risk was accepted.
- What compensating controls were used.
- What validation will be performed afterward.
20. Step 10 — Implement the Change
During implementation:
- Use authorized access.
- Use named accounts.
- Follow the approved implementation plan.
- Record significant actions.
- Avoid unrelated changes.
- Maintain logging.
- Monitor system behavior.
- Monitor security events.
- Record deviations from the plan.
If the situation changes materially, reassess before continuing.
21. Emergency Access Relationship
Where elevated access is required, use the Emergency Access Procedure.
The two processes should remain linked:
Emergency Change Required
→ Emergency Access Required?
→ If Yes → Emergency Access Approval
→ Temporary Privilege
→ Change Implementation
→ Access Revocation
Emergency access should not automatically become permanent simply because an emergency change was performed.
22. Step 11 — Validate the Change
After implementation, verify:
Technical
- System is functioning.
- Configuration is correct.
- Dependencies are working.
- Application is available.
- Database is functioning.
Security
- Security controls remain active.
- Logging is functioning.
- Monitoring is functioning.
- IAM permissions remain appropriate.
- No unintended exposure exists.
- Vulnerability is addressed where applicable.
Business
- Critical service is available.
- Customer functionality works.
- Business owner confirms expected result.
23. Step 12 — Enhanced Monitoring
Emergency changes should receive additional monitoring where appropriate.
Monitor:
- Application errors
- Authentication
- Privileged activity
- Cloud activity
- Network traffic
- Security alerts
- Database activity
- Customer-impacting metrics
- Performance
- Availability
The monitoring period should reflect the risk and criticality of the change.
24. Step 13 — Rollback
Rollback should be initiated when:
- The change causes unacceptable impact.
- The intended result is not achieved.
- Security risk increases.
- Data integrity is affected.
- Critical service becomes unstable.
- The change cannot be safely completed.
Rollback should be documented.
Record:
- Reason
- Time
- Person responsible
- Rollback method
- Result
- Validation
- Remaining risk
25. Step 14 — Emergency Change During Security Incident
During an incident, changes may be required for:
- Blocking malicious IPs
- Disabling compromised accounts
- Revoking tokens
- Removing malicious IAM policies
- Isolating workloads
- Blocking network traffic
- Disabling compromised integrations
- Patching exploited vulnerabilities
- Restoring secure configurations
- Protecting backups
The change should remain linked to the incident record.
Example:
INC-2026-0017
→ EC-2026-0009
→ Disable compromised IAM access
→ Revoke sessions
→ Rotate credentials
→ Validate cloud environment
26. Step 15 — Emergency Change During Disaster Recovery
During DR, emergency changes may include:
- DNS failover
- Network routing
- Recovery environment configuration
- Database restoration
- Application deployment
- IAM configuration
- Security control activation
- Backup restoration
- Cloud infrastructure provisioning
Recovery changes should follow the Disaster Recovery Plan and maintain security controls.
27. Step 16 — Post-Implementation Review
Every significant emergency change should receive a post-implementation review.
Review:
- Was the emergency classification appropriate?
- Was the change successful?
- Was the intended risk addressed?
- Were there unexpected effects?
- Was the rollback plan adequate?
- Were security controls maintained?
- Was monitoring sufficient?
- Was emergency access revoked?
- Were additional changes required?
- Should a permanent change be created?
- Was a control weakness identified?
28. Convert Temporary Fix Into Permanent Change
An emergency change may only be a temporary solution.
Example:
Emergency firewall rule blocks a malicious source.
After the emergency:
Temporary Fix
→ Root Cause Review
→ Permanent Architecture/Configuration Change
→ Normal Change Process
→ Testing
→ Implementation
→ Verification
The organization should avoid allowing emergency fixes to become undocumented permanent configurations.
29. Emergency Change Register
Maintain a central register containing:
| Field | Description |
|---|---|
| Change ID | EC-YYYY-XXXX |
| Date/Time | Change initiated |
| Requestor | Person requesting |
| System | Affected system |
| Environment | Production/etc. |
| Emergency Category | EC-1 to EC-7 |
| Reason | Why urgent |
| Related Incident/DR | Reference |
| Risk | Identified risk |
| Approval | Approver |
| Implementer | Person performing change |
| Planned Change | Description |
| Rollback | Rollback approach |
| Start Time | Implementation |
| Completion | Completion time |
| Validation | Result |
| Monitoring | Monitoring performed |
| Outcome | Successful/Failed/Rolled Back |
| Permanent Fix | Required/Not Required |
| Review | Post-change review |
| Corrective Action | Related action |
| Status | Closed/Open |
30. Emergency Change Status
Recommended status values:
- Requested
- Assessing
- Awaiting Approval
- Approved
- Implementing
- Monitoring
- Successful
- Rolled Back
- Failed
- Post-Review
- Permanent Change Required
- Corrective Action
- Closed
31. Emergency Change Checklist
Identification
- Emergency confirmed.
- Business/security reason documented.
- Related incident/DR record identified.
- Affected system identified.
Assessment
- Business impact assessed.
- Security impact assessed.
- Technical impact assessed.
- Data impact assessed.
- Dependencies identified.
- Risk assessed.
Approval
- Authorized approver identified.
- Minimum change defined.
- Implementation plan defined.
- Rollback plan defined.
- Monitoring defined.
- Approval recorded.
Implementation
- Authorized access used.
- Backup/snapshot completed where appropriate.
- Change implemented.
- Significant actions recorded.
- Logging maintained.
- Monitoring enabled.
Validation
- Technical validation completed.
- Security validation completed.
- Business validation completed.
- Customer impact assessed.
- Unexpected effects checked.
Closure
- Change outcome recorded.
- Emergency access revoked where applicable.
- Enhanced monitoring completed.
- Rollback assessed.
- Permanent change identified if required.
- Corrective actions assigned.
- Risk reassessed.
- Post-implementation review completed.
- Change record closed.
32. Startup Implementation
A startup does not need a complicated Change Advisory Board to manage emergency changes effectively.
A practical model is:
One Emergency Change Record
- One Authorized Approver
- Risk Assessment
- Implementation Plan
- Rollback Plan
- Logging
- Post-Change Validation
- Post-Implementation Review
For an AWS SaaS environment, the minimum evidence set could include:
- Change request
- Approval
- Before configuration
- Implementation record
- CloudTrail activity
- Deployment record
- Validation result
- After configuration
- Monitoring evidence
- Rollback evidence if applicable
- Post-change review
33. Metrics
Management may monitor:
- Number of emergency changes
- Emergency changes by category
- Successful changes
- Failed changes
- Rolled-back changes
- Emergency changes causing incidents
- Emergency changes requiring permanent fixes
- Average emergency change completion time
- Changes without adequate approval
- Changes without rollback plans
- Recurring emergency changes
- Emergency changes related to vulnerabilities
- Emergency changes related to incidents
A high number of recurring emergency changes may indicate weaknesses in planning, architecture, vulnerability management, monitoring, or normal change management.
34. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Change Management Policy | Defines overall change-management requirements |
| Change Management Procedure | Defines normal changes |
| Emergency Access Procedure | Controls temporary privileged access |
| Incident Response Procedure | Provides incident context |
| Incident Response Playbooks | Defines scenario-specific response |
| Disaster Recovery Plan | Defines technology recovery |
| Business Continuity Plan | Defines business continuity |
| Information Security During Disruption Procedure | Maintains security during disruption |
| Vulnerability Management Procedure | Identifies vulnerabilities requiring urgent action |
| Configuration Management Standard | Defines secure configurations |
| Evidence Collection Procedure | Preserves relevant evidence |
| Corrective Action Tracker | Tracks permanent remediation |
| Risk Register | Records material residual risk |
35. ISO 27001 Alignment
This procedure supports risk-based implementation of ISO/IEC 27001:2022 requirements and applicable controls relating to:
- Change management
- Configuration management
- Access control
- Privileged access
- Information security during disruption
- Incident management
- Vulnerability management
- Logging and monitoring
- Backup and recovery
- ICT readiness for business continuity
- Secure development and operational change
The organization should determine the specific controls applicable to its environment through its risk assessment and Statement of Applicability (SoA).
Not every organization requires the same emergency-change controls or approval structure.
36. Audit Evidence
Typical audit evidence includes:
- Emergency Change Procedure
- Emergency Change Register
- Emergency change requests
- Approvals
- Risk assessments
- Implementation plans
- Rollback plans
- Backup/snapshot evidence
- Change logs
- CloudTrail records
- Deployment records
- Configuration before/after evidence
- Testing/validation records
- Monitoring records
- Incident records
- Emergency access records
- Post-implementation reviews
- Corrective actions
- Permanent change records
- Risk reassessment
An auditor should be able to trace:
Why the change was urgent → Who approved it → What changed → Who implemented it → What controls were used → Whether the service/security was validated → Whether temporary access was removed → Whether the change was reviewed.
37. Final Audit Trail
Emergency Identified
→ Change Requirement Confirmed
→ Emergency Classification
→ Business/Security/Technical Impact Assessed
→ Risk Assessed
→ Minimum Change Defined
→ Approval Obtained
→ Implementation Plan Defined
→ Backup/Rollback Prepared
→ Emergency Access Granted Where Required
→ Change Implemented
→ Activity Logged
→ Security Validated
→ Business Service Validated
→ Enhanced Monitoring
→ Rollback if Required
→ Emergency Access Revoked
→ Post-Implementation Review
→ Permanent Fix Identified Where Required
→ Risk Reassessed
→ Corrective Action Assigned
→ Change Closed
38. Final Principle
Emergency change management is not about removing control during a crisis. It is about applying the right amount of control quickly enough to reduce the risk.
Identify → Assess → Approve → Prepare → Change → Validate → Monitor → Roll Back if Necessary → Review → Improve
The objective is:
Make the minimum necessary change, with appropriate authority, preserve evidence, maintain security, verify the result, and ensure temporary emergency solutions do not become uncontrolled permanent changes.