Information Security During Disruption Procedure

1. Purpose

The Information Security During Disruption Procedure defines how the organization maintains appropriate information-security controls when normal business operations, systems, facilities, personnel, suppliers, or technology services are disrupted.

The procedure ensures that business continuity and recovery activities do not unnecessarily create additional security risks.

It provides a structured approach for:

Protecting information during disruptions.
Maintaining confidentiality, integrity, and availability.
Managing emergency access.
Protecting critical systems and information.
Maintaining logging and monitoring.
Managing emergency changes.
Protecting backups and recovery environments.
Controlling temporary workarounds.
Supporting incident response and disaster recovery.
Verifying security after recovery.
Documenting security decisions and exceptions.

2. Scope

This procedure applies during:

Cybersecurity incidents
Ransomware attacks
Cloud outages
Cloud-account compromise
Data breaches
Application failures
Database failures
Network outages
Infrastructure failures
Supplier outages
SaaS provider failures
Office or facility disruption
Workforce disruption
Natural disasters
Backup or recovery events
Major technology failures
Disaster-recovery activation
Emergency changes
Any other disruption that may affect information security

It applies to:

Production systems
Cloud infrastructure
Corporate systems
Applications
Databases
Networks
Endpoints
Identity and access systems
SaaS services
Backup systems
Source code and CI/CD
Customer information
Employee information
Confidential business information
Critical suppliers

3. Core Principle

During a disruption:

Business continuity does not mean security controls can be ignored.

Emergency operations should maintain security controls wherever practical.

Where a security control cannot be maintained, the organization should:

Assess → Authorize → Compensate → Monitor → Document → Restore

Any temporary security exception should be treated as a controlled risk rather than an informal workaround.

4. Roles and Responsibilities

Role	Responsibility
Incident Commander	Coordinates major incident/disruption response
Business Owner	Prioritizes business services and recovery
Security Lead	Maintains information-security requirements
IT/Cloud Lead	Manages infrastructure and technical recovery
Application/DevOps Lead	Supports application and deployment recovery
Privacy/Legal	Advises on privacy, legal and regulatory requirements
Supplier Owner	Coordinates critical suppliers
Executive Management	Makes major business and risk decisions
Employees	Follow emergency security instructions

For smaller organizations, one individual may perform multiple roles.

5. Procedure Overview

The procedure follows:

Disruption Detected
↓
Assess Security Impact
↓
Activate Appropriate Response
↓
Protect Critical Information & Systems
↓
Control Emergency Access
↓
Maintain Monitoring & Logging
↓
Manage Emergency Changes
↓
Protect Backups & Recovery Resources
↓
Recover From Trusted State
↓
Verify Security
↓
Remove Temporary Controls
↓
Reassess Risk
↓
Record Lessons & Improve

6. Step 1 — Identify the Disruption

The disruption may be identified through:

Security alert
Incident report
System monitoring
Cloud provider notification
Supplier notification
Employee report
Customer report
Application failure
Network outage
Backup failure
Disaster declaration
Management notification

Create or update the appropriate incident, event, or disruption record.

Record:

Date and time
Description
Source
Affected service
Affected system
Initial business impact
Initial security impact
Reporter
Initial owner

7. Step 2 — Determine Whether Security Is Affected

Assess whether the disruption could affect:

Confidentiality

Could information be exposed to unauthorized people?

Integrity

Could information or systems be modified incorrectly?

Availability

Could critical information or services become unavailable?

Also consider:

Customer impact
Personal-data impact
Regulatory impact
Contractual impact
Supplier impact
Financial impact
Security-control degradation
Ability to monitor systems

If the disruption is also a security incident, activate the applicable Incident Response Procedure.

8. Step 3 — Classify the Disruption

The organization should determine the nature and severity of the disruption.

Examples:

Situation	Potential Response
Minor internal system outage	Normal IT recovery
Critical SaaS dependency unavailable	Business continuity response
Production outage	Incident + continuity response
Cloud account compromise	Security incident + continuity
Ransomware	Major security incident + continuity
Data breach	Incident response + privacy/legal assessment
Critical supplier failure	Supplier + continuity response

Classification should be based on actual and reasonably foreseeable impact.

9. Step 4 — Protect Critical Information

During disruption, identify and protect critical information such as:

Customer data
Personal data
Financial information
Authentication information
Source code
Secrets
Encryption keys
Security logs
Backups
Business-critical documents
Intellectual property

Do not move sensitive information to unapproved storage merely because normal systems are unavailable.

Where emergency transfer is unavoidable:

Use an approved secure method.
Restrict recipients.
Encrypt where appropriate.
Record the transfer.
Delete temporary copies when no longer required.

10. Step 5 — Protect Critical Systems

Identify systems necessary for continued operation.

Typical priorities may include:

Identity and access management
Security monitoring
Production services
Customer databases
Critical applications
Backup systems
Network connectivity
DNS
Critical SaaS platforms
Supporting internal systems

Recovery priorities should be based on business impact and risk.

11. Step 6 — Emergency Access Management

Disruptions may require emergency or privileged access.

Emergency access should follow these principles:

Use named accounts.
Use MFA wherever technically possible.
Grant only required privileges.
Use temporary access where possible.
Record the reason.
Obtain authorization.
Log activity.
Monitor activity.
Remove access after the emergency.

Prohibited Practices

Avoid:

Shared administrator passwords
Untracked emergency accounts
Permanent privilege escalation
Disabling MFA without authorization
Unlogged administrative activity
Sending credentials through ordinary email or chat

If an emergency requires deviation, the deviation must be documented and reviewed.

12. Step 7 — Emergency Credentials

If credentials must be created, reset, or rotated:

Use approved credential-management mechanisms.
Generate unique credentials.
Apply appropriate complexity requirements.
Enable MFA where available.
Restrict access.
Record ownership.
Rotate credentials after the emergency where appropriate.
Revoke temporary credentials when no longer required.

If a credential may have been exposed during the disruption, treat it as potentially compromised and follow the applicable credential-compromise process.

13. Step 8 — Maintain Logging and Monitoring

Security monitoring should continue during disruption wherever technically possible.

Priority logging may include:

Authentication
Privileged activity
Cloud activity
Network activity
Application activity
Database activity
Security alerts
Configuration changes
Backup activity
Recovery activity

If normal monitoring is unavailable:

Identify the monitoring gap.
Assess the risk.
Establish alternative monitoring where practical.
Increase manual review if necessary.
Record the period of reduced visibility.
Restore normal monitoring as soon as possible.

14. AWS SaaS Example

During an AWS production disruption, the organization may temporarily move workloads, modify security groups, restore databases, or activate another recovery environment.

Security requirements should continue to include:

IAM authentication
MFA
Least privilege
CloudTrail
Security monitoring
Encryption
Network controls
Secrets protection
Logging
Backup protection

If an emergency security-group change is required to restore service:

Business Need Identified
→ Emergency Change Authorized
→ Security Impact Assessed
→ Change Implemented
→ Activity Logged
→ Service Restored
→ Security Configuration Verified
→ Temporary Rule Removed or Formally Approved
→ Change Reviewed

15. Step 9 — Emergency Change Management

Emergency changes may be necessary to maintain critical services.

Examples include:

Failover
Database restoration
Network rerouting
Security-group modification
DNS changes
Application rollback
Infrastructure rebuild
Emergency patching
Credential rotation
Temporary service configuration

Each emergency change should record:

Change ID
Reason
Affected system
Security impact
Business impact
Requestor
Approver
Implementer
Date/time
Change performed
Validation
Rollback plan where practical
Final status

Emergency changes should be reviewed after the disruption.

16. Step 10 — Protect Backups

During major incidents, especially ransomware or destructive attacks, backups should receive heightened protection.

The organization should:

Restrict backup administration.
Protect backup credentials.
Monitor backup deletion.
Protect immutable backups where available.
Verify backup integrity.
Prevent compromised production credentials from unnecessarily controlling backups.
Preserve recovery copies.
Test restoration where required.

The organization should avoid restoring from a backup that may contain the original compromise unless it has been assessed and determined to be trustworthy.

17. Step 11 — Protect Recovery Environments

Recovery environments should not become an uncontrolled security bypass.

Before restoring or activating a recovery environment, verify where practical:

IAM
MFA
Network controls
Security groups/firewalls
Encryption
Secrets
Logging
Monitoring
Vulnerability status
Backup source
Configuration
Access permissions

Recovery environments should be monitored during operation.

18. Step 12 — Data Protection During Recovery

When restoring or moving data:

Use approved storage.
Protect data in transit.
Protect data at rest.
Restrict access.
Minimize unnecessary copies.
Maintain data integrity.
Verify the source.
Record major transfers.
Secure temporary data.

Personal or customer data should not be copied into less-secure environments simply to accelerate recovery.

19. Step 13 — Supplier and Cloud Provider Coordination

During a disruption involving a supplier or cloud provider:

Identify the affected service.
Confirm the provider’s incident status.
Record provider communications.
Determine customer/business impact.
Assess security impact.
Request relevant technical information where necessary.
Escalate through contractual contacts.
Activate alternative arrangements where available.
Document decisions.

Supplier communications should be coordinated through the designated supplier owner and incident-management process.

20. Step 14 — Communication

Communication during disruption should follow the Security Incident Communication Procedure where applicable.

Communication should:

Use verified information.
Avoid speculation.
Protect sensitive information.
Use authorized channels.
Clearly identify known and unknown information.
Identify responsible owners.
Provide updates at appropriate intervals.

If normal communication systems are unavailable, use approved alternative communication channels.

21. Step 15 — Incident and Privacy Assessment

During disruption, assess whether:

Unauthorized access occurred.
Data was exposed.
Data was modified.
Data was lost.
Credentials were compromised.
Security controls were disabled.
Personal data was affected.
Customer information was affected.
Regulatory obligations may apply.
Contractual commitments may be affected.

Where applicable, activate:

Incident Response Procedure
Data Breach Playbook
Cloud Compromise Playbook
Ransomware Playbook
Account Compromise Playbook
Privacy/Data Breach process
Supplier Incident process

22. Step 16 — Preserve Evidence

If the disruption involves a security incident or suspected compromise:

Preserve relevant logs.
Preserve security alerts.
Record important system states.
Preserve relevant communications.
Record configuration changes.
Protect investigation evidence.
Maintain evidence traceability.

Evidence should be handled according to the Evidence Collection Procedure and, where appropriate, the Chain-of-Custody Procedure.

Normal log deletion or retention processes should not result in destruction of relevant investigation evidence.

23. Step 17 — Recovery

Recovery should follow the applicable recovery or disaster-recovery procedure.

Typical sequence:

Contain
→ Assess
→ Select Trusted Recovery Source
→ Restore
→ Secure
→ Test
→ Monitor
→ Return Service

Recovery should prioritize critical business services according to the organization’s defined recovery objectives.

24. Step 18 — Security Verification Before Service Restoration

Before returning a service to normal operations, verify:

Authentication works correctly.
MFA is functioning.
Privileged access is appropriate.
Unauthorized accounts are removed.
Security groups/firewalls are correct.
Encryption is enabled.
Secrets are protected.
Logging is active.
Monitoring is active.
Vulnerabilities are addressed or risk accepted.
Backup is functioning.
Application integrity is confirmed.
Data integrity is confirmed.
Security alerts are reviewed.

25. Step 19 — Remove Temporary Security Exceptions

After normal operations are restored:

Remove temporary accounts.
Remove temporary privileges.
Remove temporary firewall rules.
Remove emergency network paths.
Re-enable normal security controls.
Revoke temporary credentials.
Restore standard configurations.
Close emergency access.
Review emergency changes.

Temporary controls should not remain indefinitely.

26. Step 20 — Post-Recovery Review

After recovery, assess:

What happened?
What caused the disruption?
What security controls were affected?
What temporary exceptions were used?
Were emergency accesses properly controlled?
Were logs available?
Was evidence preserved?
Were backups effective?
Was recovery successful?
Were RTO/RPO objectives achieved?
Was customer information affected?
Were suppliers involved?
What risks remain?

Record findings in the appropriate incident, risk, corrective-action, or improvement records.

27. Risk Reassessment

Following significant disruption, reassess:

Existing risks
New risks
Residual risk
Security-control effectiveness
Supplier risks
Cloud risks
Backup risks
Business continuity risks
Recovery risks

Where required, update:

Risk Register
Statement of Applicability
Security controls
Policies
Procedures
Recovery plans
Supplier requirements

28. Corrective Actions

Corrective actions may include:

Technical improvements
Additional monitoring
Access-control improvements
Backup improvements
Architecture changes
Supplier changes
Process changes
Policy updates
Training
Additional testing
Recovery improvements
New security controls

Each significant action should have:

Action ID
Finding
Root cause
Owner
Priority
Target date
Implementation evidence
Verification
Effectiveness assessment
Closure decision

29. Information Security During Degraded Operations

Where normal operations cannot be maintained, the organization may operate temporarily in a degraded mode.

Examples:

Manual customer processing
Reduced application functionality
Alternate communication
Secondary infrastructure
Temporary restricted access
Manual approval processes
Offline operational procedures

Even in degraded mode:

Only the minimum necessary security controls should be temporarily reduced, and the reduction should be explicitly assessed and authorized.

30. Emergency Security Exception

Where a security control cannot be maintained, document:

Field	Example
Exception ID	EX-2026-001
Disruption	Production outage
Control Affected	Normal network restriction
Reason	Emergency service restoration
Risk	Temporary increased exposure
Compensating Control	Restricted source IP + monitoring
Approver	Security/Management
Start Time	Date/time
Expiry	Date/time
Owner	IT/Cloud Lead
Review	Post-recovery
Closure	Temporary rule removed

Emergency exceptions should be time-bound wherever possible.

31. Startup Implementation

A startup can implement this procedure with a simple operating model:

Before Disruption

Critical Services
→ Critical Assets
→ RTO/RPO
→ Backup
→ Recovery Procedure
→ Emergency Contacts

During Disruption

Detect
→ Assess
→ Activate
→ Protect
→ Control Access
→ Monitor
→ Recover

After Disruption

Verify
→ Remove Temporary Controls
→ Assess Risk
→ Root Cause
→ Corrective Action
→ Lessons Learned
→ Test Again

The startup does not need a large business-continuity team. The critical requirement is that responsibilities, decision authority, recovery priorities, security requirements, and evidence are clear.

32. Minimum Information Security During Disruption Checklist

Activation

Disruption recorded.
Business impact assessed.
Security impact assessed.
Incident classification completed.
Appropriate response activated.

Information Protection

Critical information identified.
Customer information protected.
Personal information protected.
Secrets and credentials protected.
Sensitive transfers controlled.

Access

Emergency access authorized.
MFA maintained where possible.
Least privilege applied.
Temporary access recorded.
Emergency credentials controlled.

Technology

Critical systems identified.
Logging maintained.
Monitoring maintained.
Emergency changes documented.
Backups protected.
Recovery environment secured.

Recovery

Trusted recovery source identified.
Recovery performed.
Data integrity verified.
Security controls verified.
Monitoring restored.
Service validated.

Closure

Temporary access removed.
Temporary security exceptions removed.
Emergency changes reviewed.
Incident/disruption records updated.
Evidence preserved.
Risk reassessed.
Corrective actions assigned.
Lessons learned recorded.

33. Relationship With Other Documents

Document	Relationship
Business Continuity & Information Security Policy	Defines overall requirements
Business Continuity Plan	Defines continuity strategy
Disaster Recovery Plan	Defines technology recovery
Incident Response Procedure	Handles security incidents
Incident Response Playbooks	Provides scenario-specific response
Security Incident Communication Procedure	Controls incident communication
Evidence Collection Procedure	Protects investigation evidence
Security Log Retention Standard	Defines log retention
Backup and Recovery Procedure	Defines backup/recovery activities
Emergency Change Procedure	Controls emergency changes
Access Control Policy	Defines access requirements
Risk Management Procedure	Supports risk decisions
Corrective Action Tracker	Tracks improvements

34. ISO 27001 Alignment

This procedure supports the organization’s implementation of ISO/IEC 27001:2022 requirements and applicable Annex A controls relating to:

Information security during disruption
ICT readiness for business continuity
Incident management
Access control
Privileged access
Logging and monitoring
Backup
Configuration management
Change management
Supplier management
Evidence preservation
Risk management
Continual improvement

The specific controls and implementation should be determined through the organization’s risk assessment and Statement of Applicability (SoA).

This procedure should also be aligned with the organization’s business impact assessment, continuity plans, disaster-recovery arrangements, contractual obligations, and applicable legal/regulatory requirements.

35. Audit Evidence

Typical evidence includes:

Approved procedure
Disruption records
Business continuity activation records
Incident records
Emergency access records
Emergency change records
Security exception records
Cloud recovery records
Backup restoration evidence
Security logs
Monitoring alerts
Evidence Collection Forms
Evidence Register
Incident Investigation Reports
Recovery verification records
Supplier communications
Customer communication records where applicable
Risk reassessment
Corrective Action Tracker
Lessons Learned Register
Tabletop exercise results
Recovery test results

36. Final Audit Trail

Disruption Detected
→ Disruption Recorded
→ Business Impact Assessed
→ Security Impact Assessed
→ Response Activated
→ Critical Information Identified
→ Critical Systems Identified
→ Emergency Access Controlled
→ Logging & Monitoring Maintained
→ Emergency Changes Authorized
→ Backups Protected
→ Recovery Environment Secured
→ Trusted Recovery Performed
→ Security Controls Verified
→ Service Restored
→ Temporary Controls Removed
→ Evidence Preserved
→ Risk Reassessed
→ Corrective Actions Assigned
→ Lessons Learned
→ Management Review
→ Procedure Improved

37. Final Principle

A disruption is not an excuse to abandon information security. It is a situation where security decisions must become more deliberate, controlled, and documented.

Assess → Protect → Control → Monitor → Recover → Verify → Restore → Learn → Improve

The objective is:

Keep critical services operating + Protect information + Control emergency access + Maintain security visibility + Recover from a trusted state + Verify the environment before returning to normal operations.

ISO/IEC 27001