1. Purpose
The Emergency Access Procedure defines how temporary or exceptional access to information systems, applications, cloud environments, infrastructure, data, or administrative functions is requested, approved, granted, monitored, and removed during an emergency.
Emergency access may be required when normal access arrangements are unavailable or insufficient to:
- Restore critical business services.
- Respond to a security incident.
- Recover from a disaster.
- Contain an active security threat.
- Restore critical infrastructure.
- Investigate a major incident.
- Resolve a critical production failure.
- Maintain essential business operations.
The objective is to enable rapid response without creating uncontrolled or permanent security access.
2. Scope
This procedure applies to emergency access involving:
- Employees
- Contractors
- IT administrators
- Security personnel
- Cloud administrators
- DevOps personnel
- Database administrators
- Application administrators
- Suppliers or external specialists
- Privileged accounts
- Cloud accounts
- Production systems
- Databases
- Networks
- Security tools
- Backup systems
- SaaS platforms
- CI/CD systems
- Customer information
- Security logs
- Recovery environments
It applies to emergency access for both security incidents and operational/business continuity events.
3. Emergency Access Principle
Emergency access follows:
Minimum Access + Clear Authorization + Time Limitation + Strong Authentication + Monitoring + Evidence + Immediate Revocation
Emergency access is an exception to normal access processes, not an exception from access control.
4. When Emergency Access May Be Used
Emergency access may be considered when:
- A critical production service is unavailable.
- Normal administrators are unavailable.
- A critical security incident requires immediate action.
- A privileged account is compromised.
- Disaster recovery is activated.
- A cloud service requires urgent recovery.
- A critical vulnerability requires emergency remediation.
- Backup recovery requires elevated privileges.
- Normal access-management systems are unavailable.
- A critical supplier requires temporary technical access.
- An emergency change requires elevated access.
Emergency access must have a legitimate business or security justification.
5. When Emergency Access Must Not Be Used
Emergency access must not be used:
- For convenience.
- To avoid normal approval processes without a legitimate emergency.
- To obtain permanent privileges.
- To bypass security controls unnecessarily.
- To perform routine administrative work.
- To access information unrelated to the emergency.
- To avoid logging or monitoring.
- To create unapproved accounts or credentials.
6. Emergency Access Roles
| Role | Responsibility |
|---|---|
| Requestor | Identifies and requests emergency access |
| Approver | Authorizes access based on risk and urgency |
| System Owner | Confirms system/business need |
| Security Lead | Reviews security implications |
| IT/Cloud Lead | Implements technical access |
| Incident Commander | Coordinates access during major incidents |
| Auditor/Reviewer | Reviews emergency access after the event |
One person may perform multiple roles in a startup, but access approval and implementation should be separated where practical.
7. Emergency Access Lifecycle
Emergency Identified
↓
Need Assessed
↓
Access Requested
↓
Emergency Validated
↓
Risk Assessed
↓
Access Approved
↓
Temporary Access Created/Enabled
↓
MFA & Security Controls Applied
↓
Activity Monitored
↓
Emergency Work Performed
↓
Access Reviewed
↓
Access Revoked
↓
Evidence Recorded
↓
Post-Emergency Review
8. Step 1 — Identify the Emergency
Record:
- Emergency ID
- Date/time
- Requestor
- Affected service
- Affected system
- Description
- Business impact
- Security impact
- Reason emergency access is required
- Expected access duration
Example:
EA-2026-0001
Production database is unavailable following an infrastructure failure. The normal database administrator is unavailable. Temporary elevated access is required to perform recovery.
9. Step 2 — Determine Whether Emergency Access Is Necessary
Before granting access, determine:
- Can the task be completed using existing authorized access?
- Is the situation genuinely urgent?
- What system requires access?
- What information may be accessed?
- What privilege is required?
- How long is access required?
- Can a less-privileged role perform the task?
- Is an approved alternative available?
If normal access is sufficient, emergency access should not be used.
10. Step 3 — Define the Minimum Required Access
The requestor should specify:
- System
- Environment
- Account
- Role
- Permissions
- Resources
- Data
- Actions required
- Expected duration
Access should be limited to the minimum required scope.
Example
Instead of:
Full AWS AdministratorAccess
Prefer:
Temporary access to the specific production ECS service and associated deployment resources required to restore the affected application.
Where the emergency genuinely requires broader privilege, the reason should be documented.
11. Step 4 — Emergency Approval
Emergency access should be approved by an authorized person.
Approval should consider:
- Business impact
- Security risk
- Required privilege
- System criticality
- Information sensitivity
- User identity
- Expected duration
- Alternative options
- Compensating controls
For a major security incident, the Incident Commander or Security Lead may authorize access according to the organization’s incident-response authority model.
12. Emergency Approval Levels
| Emergency | Minimum Approval |
|---|---|
| Low-risk operational recovery | System Owner/IT Lead |
| Critical production recovery | IT/Cloud Lead + Business Owner where practical |
| Privileged production access | Authorized Manager/Security Lead |
| Security incident response | Incident Commander/Security Lead |
| Major disaster recovery | Authorized Management + Technical Owner |
| Highly sensitive/customer data access | Security/Privacy/Business authority as applicable |
| External specialist access | System Owner + Security/IT authority |
Where immediate action is necessary and prior approval cannot reasonably be obtained, emergency access may be granted under predefined emergency authority and must be reviewed afterward.
13. Step 5 — Strong Authentication
Emergency access should use strong authentication.
Where supported:
- MFA must be enabled.
- Named accounts must be used.
- Privileged authentication must be protected.
- Hardware security keys should be used where appropriate.
- Shared credentials should be avoided.
If MFA must temporarily be bypassed due to a genuine emergency, the exception must be explicitly authorized, documented, monitored, and corrected as soon as possible.
14. Step 6 — Temporary Account or Privilege
Where possible, emergency access should be implemented using:
- Temporary account
- Temporary role
- Just-in-time privilege
- Time-limited group membership
- Temporary cloud role
- Privileged-access-management mechanism
The access should automatically expire where technically possible.
15. AWS Emergency Access Example
Suppose the production AWS environment becomes unavailable and the normal administrator is unavailable.
Instead of sharing an administrator password:
- Create or enable an approved emergency role.
- Require MFA.
- Restrict the role to the required AWS account.
- Apply the minimum required permissions.
- Set an expiration time.
- Record the Emergency Access ID.
- Monitor CloudTrail activity.
- Perform the recovery.
- Verify the service.
- Remove/revoke the emergency role.
- Review CloudTrail activity.
- Record the closure.
Example:
EA-2026-0012
Temporary AWS production recovery role enabled for 90 minutes to restore ECS deployment and verify associated infrastructure.
16. Step 7 — Record Emergency Access
The following information should be recorded:
| Field | Description |
|---|---|
| Emergency Access ID | Unique identifier |
| Incident/DR ID | Related record |
| Requestor | Person requesting access |
| User | Person receiving access |
| System | Target system |
| Environment | Production/Test/etc. |
| Access Level | Privilege granted |
| Reason | Emergency justification |
| Approval | Approver |
| Start Time | Access activation |
| Expiry Time | Planned expiry |
| Actual Revocation | Actual removal |
| Monitoring | Monitoring method |
| Actions Performed | Work completed |
| Evidence | Logs/records |
| Reviewer | Post-event reviewer |
| Status | Open/Closed |
17. Step 8 — Monitor Emergency Activity
Emergency access should be monitored more closely than ordinary access where practical.
Monitoring may include:
- Authentication logs
- Privileged activity
- CloudTrail
- Application logs
- Database logs
- Network logs
- Command history
- Administrative actions
- Configuration changes
- File access
- Security alerts
The purpose is to establish:
Who accessed what, when, from where, and what actions were performed.
18. Step 9 — Protect Sensitive Information
Emergency access may expose:
- Customer information
- Personal data
- Financial information
- Source code
- Security logs
- Credentials
- Secrets
- Encryption keys
- Confidential business information
The person receiving emergency access must only access information necessary for the emergency.
Sensitive information must not be copied to:
- Personal devices
- Personal email
- Unapproved cloud storage
- Unapproved collaboration tools
- Removable media without authorization
19. Step 10 — Emergency Access During a Security Incident
When emergency access is required during an incident:
Incident Identified
→ Access Need Determined
→ Minimum Privilege Defined
→ Emergency Access Approved
→ Access Granted
→ Activity Monitored
→ Evidence Preserved
→ Response Performed
→ Access Revoked
→ Activity Reviewed
Where possible, emergency access activity should itself be treated as investigation evidence.
20. Step 11 — Emergency Access During Disaster Recovery
During DR activation, emergency access may be required for:
- Cloud infrastructure
- Backup systems
- Databases
- Network configuration
- DNS
- IAM
- Security controls
- Recovery environments
- CI/CD
Recovery access should follow the same principles:
Authorized + Limited + Time-Bound + Monitored + Recorded + Revoked
21. Break-Glass Access
A break-glass account may be maintained for situations where normal authentication or identity services are unavailable.
Examples:
- Identity provider outage
- MFA service failure
- Major cloud recovery
- Critical infrastructure failure
Break-glass accounts should have enhanced protection.
Controls should include:
- Strong unique credentials
- MFA or equivalent protection where feasible
- Restricted storage
- Limited number of custodians
- Monitoring
- Periodic testing
- Periodic access review
- Documented use
- Immediate review after use
- Credential rotation after use where appropriate
Break-glass accounts should not be used for routine administration.
22. Break-Glass Credential Protection
Where physical or offline credentials are required:
- Store them in an approved secure mechanism.
- Restrict access to authorized custodians.
- Maintain access records.
- Protect against unauthorized copying.
- Test the retrieval process periodically.
- Rotate credentials after use where appropriate.
Passwords, recovery codes, private keys, or other secrets should not be included in ordinary documents or tickets.
23. Supplier Emergency Access
External suppliers or specialists may require emergency access.
Before granting access:
- Confirm supplier identity.
- Confirm business need.
- Define exact system and access.
- Obtain authorization.
- Use named accounts.
- Require MFA where possible.
- Restrict duration.
- Monitor activity.
- Record actions.
- Remove access immediately after the work.
Supplier emergency access should comply with applicable contractual security requirements.
24. Emergency Access to Customer Data
Access to customer data should receive additional scrutiny.
Before access:
- Confirm the data is necessary.
- Identify the specific data required.
- Confirm authorized personnel.
- Limit access scope.
- Record the reason.
- Monitor access.
- Avoid unnecessary copying.
- Remove access afterward.
Where personal or regulated information is involved, applicable privacy and legal requirements should be considered.
25. Emergency Credential Compromise
If an emergency account or credential is suspected to be compromised:
- Revoke or disable it.
- Preserve relevant logs.
- Determine when compromise may have occurred.
- Identify systems accessed.
- Review privileged actions.
- Rotate related credentials.
- Investigate possible lateral movement.
- Assess data access.
- Create or update an incident record.
- Apply the Account Compromise or Cloud Compromise Playbook where applicable.
26. Emergency Access Exceptions
If normal access requirements cannot be followed, document:
- Requirement bypassed
- Reason
- Risk
- Compensating control
- Approver
- Start time
- Expiry
- Owner
- Review requirement
Example:
| Field | Example |
|---|---|
| Exception ID | EAX-2026-003 |
| Requirement | MFA |
| Reason | Identity service unavailable during DR |
| Risk | Increased account compromise risk |
| Compensating Control | Restricted network + monitored break-glass account |
| Approval | Security Lead |
| Start | 02:00 |
| Expiry | 04:00 |
| Review | Post-DR review |
27. Step 12 — Revoke Access
Emergency access should be revoked immediately when:
- The emergency task is completed.
- The system is recovered.
- The incident is contained.
- The recovery activity ends.
- The approved expiry time is reached.
- The person no longer requires access.
Revocation should include, where applicable:
- Account disablement
- Role removal
- Group removal
- Token revocation
- API-key revocation
- Session termination
- VPN removal
- Temporary firewall-rule removal
- Credential rotation
28. Step 13 — Verify Revocation
Do not assume that removing a role automatically terminates all access.
Verify:
- Account disabled.
- Group membership removed.
- Privileged role removed.
- Active sessions terminated where applicable.
- Tokens revoked.
- API keys disabled.
- Temporary credentials invalidated.
- Temporary network access removed.
- Temporary infrastructure removed.
Record evidence of revocation.
29. Step 14 — Post-Emergency Review
Every significant emergency access event should be reviewed.
Review:
- Was access necessary?
- Was the minimum privilege used?
- Was approval appropriate?
- Was MFA used?
- Was access time-limited?
- Was activity logged?
- Were sensitive systems accessed?
- Were unauthorized actions detected?
- Was access revoked on time?
- Were credentials rotated?
- Were there security gaps?
- Should the normal access process be improved?
30. Emergency Access Review Record
The reviewer should record:
| Field | Description |
|---|---|
| Emergency Access ID | Related access event |
| Access Duration | Planned vs actual |
| Access Used | Yes/No |
| Systems Accessed | Systems |
| Privileges Used | Actual privilege |
| Actions Performed | Key activities |
| Security Events | Any unusual activity |
| Data Access | Information accessed |
| Revocation | Completed |
| Credential Rotation | Required/Completed |
| Findings | Issues identified |
| Risk | Residual risk |
| Corrective Action | Required action |
| Reviewer | Review owner |
| Closure | Approval |
31. Emergency Access Register
The organization should maintain a central register.
Recommended fields:
| Field | Description |
|---|---|
| Emergency Access ID | EA-YYYY-XXXX |
| Date | Date |
| Related Incident/DR ID | Reference |
| Requestor | Requesting person |
| User | Person receiving access |
| System | Target |
| Environment | Production/etc. |
| Privilege | Access level |
| Reason | Emergency reason |
| Approver | Approval |
| Start Time | Activation |
| Expiry | Planned expiry |
| Revocation | Actual removal |
| Monitoring | Monitoring source |
| Actions | Activities |
| Review | Post-event review |
| Findings | Results |
| Corrective Action | Action reference |
| Status | Open/Closed |
32. Emergency Access Status
Recommended status values:
- Requested
- Under Review
- Approved
- Active
- Expired
- Revoked
- Under Review
- Corrective Action
- Closed
33. Emergency Access Checklist
Request
- Emergency identified.
- Business/security need documented.
- Normal access confirmed insufficient.
- Target system identified.
- Required privilege identified.
- Duration defined.
Approval
- Authorized approver identified.
- Risk assessed.
- Minimum privilege defined.
- Compensating controls identified where necessary.
- Approval recorded.
Activation
- Named account used.
- MFA enabled where possible.
- Temporary access configured.
- Expiry configured.
- Monitoring enabled.
- Emergency Access ID recorded.
Operation
- Activity monitored.
- Sensitive information protected.
- Actions documented.
- Evidence preserved where relevant.
Revocation
- Access disabled.
- Roles/groups removed.
- Sessions/tokens revoked.
- API keys revoked where applicable.
- Temporary network access removed.
- Credentials rotated where required.
Review
- Activity reviewed.
- Access duration reviewed.
- Security events assessed.
- Findings recorded.
- Risk reassessed.
- Corrective actions assigned.
- Emergency access record closed.
34. Startup Implementation
A startup can implement emergency access without deploying a complex privileged-access-management platform.
A practical minimum model is:
Named Emergency Role
- MFA
- Time-Limited Access
- Minimum Privilege
- Cloud/Application Logging
- Approval Record
- Immediate Revocation
- Post-Access Review
For AWS, this may be implemented using:
- IAM roles
- MFA
- Short-lived sessions
- CloudTrail
- IAM policies
- Identity federation
- Temporary privilege assignment
- Restricted break-glass access
The specific implementation should reflect the organization’s architecture and risk.
35. Example — Production AWS Emergency Access
Situation
A production application is unavailable during a critical customer-impacting incident.
Required action
A cloud engineer needs temporary elevated access to restore the ECS service.
Process
Incident Created
→ Emergency Access Required
→ Existing Access Insufficient
→ Required Permission Defined
→ Security/Technical Approval
→ Temporary AWS Role Enabled
→ MFA Verified
→ CloudTrail Monitoring Confirmed
→ Recovery Performed
→ Application Tested
→ Temporary Role Revoked
→ Sessions Terminated
→ CloudTrail Reviewed
→ Emergency Access Record Closed
Evidence
- Emergency Access Request
- Approval
- IAM role configuration
- CloudTrail activity
- Change record
- Recovery evidence
- Revocation evidence
- Post-access review
36. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Access Control Policy | Defines normal access requirements |
| Privileged Access Management Procedure | Defines privileged-access controls |
| Business Continuity Plan | Defines business continuity |
| Disaster Recovery Plan | Defines technology recovery |
| Information Security During Disruption Procedure | Defines security during disruption |
| Incident Response Procedure | Defines incident response |
| Incident Response Playbooks | Provides scenario-specific response |
| Emergency Change Procedure | Controls emergency changes |
| Security Log Retention Standard | Supports activity investigation |
| Evidence Collection Procedure | Preserves relevant evidence |
| Corrective Action Tracker | Tracks identified weaknesses |
| Risk Register | Records material residual risks |
37. ISO 27001 Alignment
This procedure supports implementation of ISO/IEC 27001:2022 controls and requirements relating to:
- Access control
- Identity management
- Authentication
- Privileged access rights
- Information security during disruption
- ICT readiness for business continuity
- Logging and monitoring
- Configuration management
- Incident management
- Change management
- Risk management
The specific controls applicable to the organization should be determined through the risk assessment and Statement of Applicability (SoA).
Emergency access should also be consistent with the organization’s access-control policy, business continuity requirements, incident-response arrangements, and risk appetite.
38. Audit Evidence
Typical evidence includes:
- Emergency Access Procedure
- Emergency Access Register
- Emergency access requests
- Approval records
- IAM role configuration
- Temporary privilege records
- MFA evidence
- CloudTrail logs
- Authentication logs
- Privileged activity logs
- Break-glass account review
- Emergency change records
- Access revocation evidence
- Credential rotation evidence
- Post-emergency reviews
- Security exceptions
- Corrective actions
- Risk assessments
- Management review records
An auditor should be able to trace an emergency access event from:
Why access was required → Who approved it → What access was granted → What was done → When it ended → Whether it was revoked → Whether the activity was reviewed.
39. Final Audit Trail
Emergency Identified
→ Access Need Identified
→ Normal Access Assessed
→ Minimum Privilege Defined
→ Risk Assessed
→ Emergency Access Approved
→ Named Access Enabled
→ MFA Applied
→ Expiry Defined
→ Monitoring Enabled
→ Emergency Activity Performed
→ Activity Logged
→ Evidence Preserved Where Required
→ Task Completed
→ Access Revoked
→ Sessions/Tokens Terminated
→ Credentials Rotated Where Required
→ Activity Reviewed
→ Risk Reassessed
→ Corrective Action Assigned
→ Emergency Access Closed
40. Final Principle
Emergency access should make the organization faster during a crisis without making the organization permanently less secure.
Justify → Minimize → Approve → Authenticate → Monitor → Use → Revoke → Review
The objective is:
Give the right person the minimum required access + for the shortest practical time + with strong authentication and monitoring + revoke it immediately when the emergency ends.