ISO/IEC 27001

⌘K
  2. Home
  4. Docs
  6. ISO/IEC 27001
  8. Other Doc
  10. ICT Recovery Checklist

ICT Recovery Checklist

1. Purpose

The ICT Recovery Checklist provides a structured method for recovering critical ICT services following a disruption, disaster, cyber incident, technology failure, cloud outage, supplier failure, or other event affecting technology availability.

It helps the recovery team verify that:

  • Recovery has been properly authorized.
  • Critical dependencies are understood.
  • Recovery is performed in the correct sequence.
  • Information remains protected during recovery.
  • Security controls are restored.
  • Data integrity is validated.
  • Business services are validated.
  • RTO/RPO requirements are measured.
  • Temporary access and emergency changes are removed.
  • Recovery evidence is retained.

ICT recovery is complete only when the technology, information, security controls, and dependent business service have been validated.

2. When to Use

Use this checklist for:

  • Disaster recovery
  • Cloud outage
  • Major infrastructure failure
  • Cybersecurity incident recovery
  • Ransomware recovery
  • Data corruption
  • Database failure
  • Application failure
  • Network failure
  • IAM/identity failure
  • Storage failure
  • Regional cloud outage
  • Supplier technology failure
  • Backup restoration
  • DR testing
  • ICT continuity exercises

3. Recovery Information

FieldDetails
Recovery IDICT-REC-YYYY-XXXX
Date
Recovery Start
Recovery End
Recovery Coordinator
Incident / Disaster ID
Business Service
ICT Service
Recovery Scenario
Recovery Environment
Recovery Region/Site
Business Owner
Technical Owner
Security Lead
Recovery Status

Status

☐ Planned
☐ Activated
☐ In Progress
☐ Recovering
☐ Validating
☐ Business Validation
☐ Completed
☐ Failed
☐ Closed

4. Recovery Trigger

Identify why recovery was initiated.

☐ Cloud outage
☐ Infrastructure failure
☐ Application failure
☐ Database failure
☐ Network failure
☐ Storage failure
☐ Cybersecurity incident
☐ Ransomware
☐ Data corruption
☐ IAM failure
☐ Supplier outage
☐ Natural/physical disaster
☐ Backup restoration
☐ DR exercise
☐ Other: ___________

Record:

Trigger: __________________________

Impact: ___________________________

Recovery authority: _______________

5. Recovery Authorization

Before starting recovery:

  • ☐ Recovery requirement confirmed
  • ☐ Business impact assessed
  • ☐ Recovery authority identified
  • ☐ Recovery coordinator assigned
  • ☐ Appropriate management notified
  • ☐ Recovery team activated
  • ☐ Security team notified where applicable
  • ☐ Incident management activated where required
  • ☐ BCP/DR activation confirmed
  • ☐ Recovery scope defined

6. Recovery Objectives

Confirm the requirements being used.

RequirementTargetActualResult
RTO
RPO
Minimum Service Level
Recovery Priority

RTO and RPO should come from the organization’s approved recovery requirements.

7. Critical Service Identification

Identify the business service being recovered.

ItemDetails
Business Service
Business Owner
ICT Service
Criticality
Customers Affected
Critical Information
Minimum Service Level
RTO
RPO

Confirm:

  • ☐ Critical service identified
  • ☐ Business owner confirmed
  • ☐ Recovery priority confirmed
  • ☐ Dependencies reviewed
  • ☐ Recovery requirements confirmed

8. ICT Dependency Review

Review all dependencies before recovery.

Application

  • ☐ Application identified
  • ☐ Application dependencies identified
  • ☐ Configuration available
  • ☐ Deployment method available

Infrastructure

  • ☐ Compute
  • ☐ Storage
  • ☐ Network
  • ☐ Load balancer
  • ☐ DNS
  • ☐ Firewall/WAF

Data

  • ☐ Database
  • ☐ Object storage
  • ☐ File storage
  • ☐ Backup
  • ☐ Replication

Identity

  • ☐ IAM
  • ☐ SSO
  • ☐ MFA
  • ☐ Privileged access
  • ☐ Service accounts

Security

  • ☐ Encryption
  • ☐ KMS
  • ☐ Secrets
  • ☐ Logging
  • ☐ Monitoring
  • ☐ Security tooling

Suppliers

  • ☐ Cloud provider
  • ☐ SaaS provider
  • ☐ DNS provider
  • ☐ Identity provider
  • ☐ Other critical suppliers

9. Recovery Team Activation

Confirm the required roles are available.

  • ☐ Recovery Coordinator
  • ☐ Incident Commander where applicable
  • ☐ Cloud/Infrastructure Lead
  • ☐ Application Lead
  • ☐ Database Owner
  • ☐ Network Lead
  • ☐ Security Lead
  • ☐ Business Owner
  • ☐ Supplier Owner
  • ☐ Communications
  • ☐ Privacy/Legal where required
  • ☐ Executive Management where required

Record unavailable personnel and alternate arrangements.

10. Communication Activation

Confirm communication channels.

  • ☐ Recovery team channel available
  • ☐ Management communication available
  • ☐ Business owner communication available
  • ☐ Supplier contacts available
  • ☐ Emergency communication available
  • ☐ Out-of-band communication available if primary systems are unavailable

Important communications should be recorded.

11. Recovery Environment

Confirm that the recovery environment is available.

  • ☐ Recovery cloud account/site available
  • ☐ Recovery network available
  • ☐ Required access available
  • ☐ Required infrastructure available
  • ☐ Security controls available
  • ☐ Monitoring available
  • ☐ Logging available
  • ☐ Backup access available
  • ☐ Required tools available
  • ☐ Recovery documentation available

12. Emergency Access

Where emergency access is required:

  • ☐ Access requirement documented
  • ☐ Access authorized
  • ☐ Named user/account
  • ☐ MFA enabled
  • ☐ Least privilege applied
  • ☐ Access duration defined
  • ☐ Activity logging enabled
  • ☐ Monitoring enabled
  • ☐ Emergency credentials protected
  • ☐ Access reviewed
  • ☐ Access revoked after recovery

No shared administrator passwords should be introduced simply because recovery is urgent.

13. Backup Validation

Before restoring data:

  • ☐ Correct backup identified
  • ☐ Backup date/time confirmed
  • ☐ Recovery point confirmed
  • ☐ Backup available
  • ☐ Backup integrity checked
  • ☐ Backup encryption confirmed
  • ☐ Backup access authorized
  • ☐ Backup not affected by the incident
  • ☐ Required retention period satisfied
  • ☐ Restore method confirmed

For ransomware or suspected compromise, avoid restoring from an untrusted recovery point without appropriate investigation and validation.

14. AWS / Cloud Account Recovery

Where AWS or another cloud platform is used:

  • ☐ Cloud account accessible
  • ☐ Recovery account identified
  • ☐ IAM available
  • ☐ MFA available
  • ☐ Required roles available
  • ☐ Network available
  • ☐ Security controls available
  • ☐ CloudTrail/logging available
  • ☐ KMS available
  • ☐ Secrets available
  • ☐ Monitoring available

15. Network Recovery

Validate:

  • ☐ VPC/network
  • ☐ Subnets
  • ☐ Routing
  • ☐ Internet connectivity
  • ☐ Private connectivity
  • ☐ VPN
  • ☐ Firewall
  • ☐ Security groups
  • ☐ WAF
  • ☐ Load balancer
  • ☐ DNS
  • ☐ Network monitoring

Perform connectivity testing between critical components.

16. Identity and Access Recovery

Validate:

  • ☐ Identity provider
  • ☐ SSO
  • ☐ IAM
  • ☐ MFA
  • ☐ Administrative accounts
  • ☐ Service accounts
  • ☐ Application identities
  • ☐ Database accounts
  • ☐ Privileged roles
  • ☐ Access permissions

Confirm that recovery has not unintentionally created excessive privileges.

17. Security Control Recovery

Validate security controls before returning the service to normal operation.

  • ☐ MFA
  • ☐ Least privilege
  • ☐ Network controls
  • ☐ Firewall
  • ☐ WAF
  • ☐ Encryption
  • ☐ KMS
  • ☐ Secrets management
  • ☐ Logging
  • ☐ Monitoring
  • ☐ Security alerts
  • ☐ Vulnerability controls
  • ☐ Endpoint/security tooling

18. Storage Recovery

Validate:

  • ☐ Object storage
  • ☐ File storage
  • ☐ Block storage
  • ☐ Snapshots
  • ☐ Versioning
  • ☐ Replication
  • ☐ Encryption
  • ☐ Access permissions
  • ☐ Data integrity

19. Database Recovery

Validate:

  • ☐ Correct recovery point selected
  • ☐ Database restored
  • ☐ Database available
  • ☐ Schema validated
  • ☐ Data integrity validated
  • ☐ Database permissions validated
  • ☐ Encryption validated
  • ☐ Application connectivity validated
  • ☐ Replication configured where required
  • ☐ Monitoring enabled

Record:

Database recovery start: __________

Database recovery completed: _______

Recovery point: ___________________

20. Application Recovery

Validate:

  • ☐ Application infrastructure
  • ☐ Application deployment
  • ☐ Configuration
  • ☐ Environment variables
  • ☐ Secrets
  • ☐ Certificates
  • ☐ Database connectivity
  • ☐ API connectivity
  • ☐ Authentication
  • ☐ Authorization
  • ☐ Background jobs
  • ☐ Scheduled tasks
  • ☐ Application monitoring
  • ☐ Logging

21. Source Code and CI/CD Recovery

Where development infrastructure is critical:

  • ☐ Source repository available
  • ☐ Repository access available
  • ☐ Branches available
  • ☐ Required build tools available
  • ☐ CI/CD platform available
  • ☐ Deployment pipeline available
  • ☐ Infrastructure-as-Code available
  • ☐ Container images available
  • ☐ Package dependencies available
  • ☐ Secrets available securely
  • ☐ Deployment validated

Do not introduce hard-coded credentials simply to accelerate recovery.

22. Secrets and Encryption Recovery

Validate:

  • ☐ Secrets Manager / vault
  • ☐ API keys
  • ☐ Service credentials
  • ☐ Certificates
  • ☐ Encryption keys
  • ☐ KMS
  • ☐ Key permissions
  • ☐ Key rotation requirements

If credentials were potentially compromised during the disruption, rotate them before returning the service to normal operation.

23. Monitoring and Logging Recovery

Confirm:

  • ☐ Application logs
  • ☐ Infrastructure logs
  • ☐ Authentication logs
  • ☐ Cloud control-plane logs
  • ☐ Security logs
  • ☐ Database logs
  • ☐ WAF logs
  • ☐ Monitoring dashboards
  • ☐ Alerts
  • ☐ Security monitoring
  • ☐ Time synchronization

Recovery should not be considered complete if critical monitoring has silently remained disabled.

24. AWS SaaS Recovery Sequence

For a typical AWS SaaS environment:

  • ☐ AWS Account
  • ☐ IAM / Security
  • ☐ VPC / Network
  • ☐ Security Groups
  • ☐ WAF
  • ☐ S3 / Storage
  • ☐ RDS / Database
  • ☐ ECS / EKS / EC2
  • ☐ Secrets Manager
  • ☐ KMS
  • ☐ Load Balancer
  • ☐ DNS
  • ☐ CloudTrail
  • ☐ CloudWatch
  • ☐ GuardDuty/Security monitoring where applicable
  • ☐ Application
  • ☐ Customer-facing service

The sequence should be adapted to the actual architecture.

25. Data Integrity Validation

After recovery:

  • ☐ Required data exists
  • ☐ Expected records available
  • ☐ No unexpected corruption
  • ☐ Database consistency verified
  • ☐ Object/file availability verified
  • ☐ Application data validated
  • ☐ Transaction integrity checked
  • ☐ Permissions verified
  • ☐ Encryption verified

Data validation performed by: __________________

Evidence: _________________________________

26. Application Functional Validation

Perform business-critical functional tests.

FunctionExpected ResultActual ResultStatus
User LoginSuccessful☐ Pass
AuthenticationSuccessful☐ Pass
Customer DashboardAvailable☐ Pass
Core TransactionSuccessful☐ Pass
APIAvailable☐ Pass
Database TransactionSuccessful☐ Pass
ReportingAvailable☐ Pass

27. Business Validation

Business Owner confirms:

  • ☐ Critical service available
  • ☐ Minimum service level achieved
  • ☐ Critical business functions operational
  • ☐ Required customer functionality operational
  • ☐ Required information available
  • ☐ Business dependencies available
  • ☐ Business users can operate

Business validation result:

☐ Pass
☐ Pass With Findings
☐ Fail

28. RTO Validation

Record actual recovery time.

ItemTime
Disruption / Recovery Start
Recovery Activated
Infrastructure Available
Data Available
Application Available
Business Validation Complete
Service Declared Recovered

Target RTO: __________

Actual RTO: __________

RTO achieved: ☐ Yes ☐ No

If not achieved, create a corrective action and reassess the recovery risk.

29. RPO Validation

Record the recovery point.

Disruption point: __________________

Latest usable recovery point: _______

Actual RPO: _______________________

Target RPO: _______________________

RPO achieved: ☐ Yes ☐ No

30. Supplier Recovery

Confirm critical supplier dependencies.

  • ☐ Cloud provider
  • ☐ Identity provider
  • ☐ DNS provider
  • ☐ Payment provider
  • ☐ Email provider
  • ☐ Critical SaaS
  • ☐ Managed service provider
  • ☐ Security provider

For each affected supplier record:

Supplier:
Dependency:
Expected recovery:
Actual recovery:
Issue:
Action:

31. Security Incident Integration

If recovery is related to a security incident:

  • ☐ Incident ID linked
  • ☐ Evidence preserved
  • ☐ Compromised systems identified
  • ☐ Recovery point assessed
  • ☐ Trusted recovery source selected
  • ☐ Compromised credentials addressed
  • ☐ Persistence removed
  • ☐ Security controls restored
  • ☐ Data impact assessed
  • ☐ Monitoring increased
  • ☐ Incident response team involved
  • ☐ Recovery validated

For ransomware or compromise, recovery should not simply overwrite potentially compromised systems without appropriate investigation.

32. Emergency Changes

Record temporary changes.

Change IDChangeReasonApproved ByRollbackStatus

Confirm:

  • ☐ Emergency change authorized
  • ☐ Risk assessed
  • ☐ Change implemented
  • ☐ Change tested
  • ☐ Security validated
  • ☐ Monitoring enabled
  • ☐ Permanent solution identified
  • ☐ Temporary change removed or formally approved

33. Recovery Communication

Confirm appropriate communication.

  • ☐ Recovery team updates
  • ☐ Management updates
  • ☐ Business owner updates
  • ☐ Supplier communication
  • ☐ Customer communication where required
  • ☐ Legal/privacy communication where required
  • ☐ Regulatory communication assessment
  • ☐ Recovery completion communication

All significant communications should be recorded.

34. Recovery Monitoring

After service restoration:

  • ☐ Enhanced monitoring enabled
  • ☐ Authentication monitored
  • ☐ Privileged activity monitored
  • ☐ Application monitored
  • ☐ Database monitored
  • ☐ Network monitored
  • ☐ Security alerts monitored
  • ☐ Error rates reviewed
  • ☐ Performance reviewed
  • ☐ Customer impact monitored

Where recovery followed a security incident, enhanced monitoring should continue for an appropriate period based on risk.

35. Temporary Controls

Identify temporary measures introduced during recovery.

Examples:

  • Temporary access
  • Temporary firewall rules
  • Temporary infrastructure
  • Temporary credentials
  • Temporary routing
  • Temporary configuration
  • Temporary manual process

For each temporary control:

Temporary control: __________________

Owner: ______________________________

Expiry/Review date: __________________

Removal status: ______________________

36. Recovery Completion Checklist

Before declaring recovery complete:

  • ☐ Infrastructure recovered
  • ☐ Network recovered
  • ☐ IAM recovered
  • ☐ Storage recovered
  • ☐ Database recovered
  • ☐ Application recovered
  • ☐ Secrets recovered
  • ☐ Encryption validated
  • ☐ Security controls validated
  • ☐ Logging enabled
  • ☐ Monitoring enabled
  • ☐ Data integrity validated
  • ☐ Application functionality validated
  • ☐ Business functionality validated
  • ☐ RTO measured
  • ☐ RPO measured
  • ☐ Temporary access removed
  • ☐ Emergency changes reviewed
  • ☐ Evidence collected
  • ☐ Findings recorded
  • ☐ Recovery owner approves completion

37. Return to Normal Operations

Confirm:

  • ☐ Normal infrastructure restored
  • ☐ Temporary infrastructure removed
  • ☐ Temporary access removed
  • ☐ Temporary credentials revoked
  • ☐ Temporary network rules removed
  • ☐ Temporary DNS changes reviewed
  • ☐ Configuration normalized
  • ☐ Monitoring normalized
  • ☐ Backup schedules verified
  • ☐ Security controls returned to standard configuration
  • ☐ Documentation updated

38. Recovery Evidence

Collect and reference:

  • ☐ Recovery authorization
  • ☐ Recovery timeline
  • ☐ Backup records
  • ☐ Restore logs
  • ☐ Cloud configuration
  • ☐ Infrastructure-as-Code
  • ☐ Database validation
  • ☐ Application validation
  • ☐ Security validation
  • ☐ Monitoring records
  • ☐ Communication records
  • ☐ Emergency access records
  • ☐ Emergency change records
  • ☐ RTO/RPO measurements
  • ☐ Business validation
  • ☐ Findings
  • ☐ Corrective actions

39. Findings

Record all significant gaps.

Finding IDFindingRiskOwnerActionDue DateStatus

Examples:

  • Recovery exceeded RTO.
  • Recovery point exceeded RPO.
  • Backup unavailable.
  • Recovery credential unavailable.
  • Application dependency missing.
  • Manual configuration required.
  • Security control not restored.
  • Monitoring unavailable.
  • Supplier dependency failed.
  • Documentation outdated.

40. Corrective Actions

For each significant finding:

  • ☐ Root cause identified
  • ☐ Risk assessed
  • ☐ Corrective action defined
  • ☐ Owner assigned
  • ☐ Target date defined
  • ☐ Implementation evidence required
  • ☐ Effectiveness verification required
  • ☐ Retest requirement assessed
  • ☐ Residual risk assessed

Link actions to the organization’s Corrective Action Tracker.

41. Recovery Lessons Learned

What Worked

What Did Not Work

Improvement Opportunities

Lessons to Share

42. Recovery Closure

Recovery may be closed when:

  • ☐ Critical service restored
  • ☐ Security validated
  • ☐ Data integrity validated
  • ☐ Business validation completed
  • ☐ RTO/RPO assessed
  • ☐ Temporary controls addressed
  • ☐ Evidence collected
  • ☐ Findings recorded
  • ☐ Corrective actions assigned
  • ☐ Residual risk reviewed
  • ☐ Management notified
  • ☐ Recovery closure approved

43. Recovery Result

Recovery Result

☐ Successful
☐ Successful With Findings
☐ Partially Successful
☐ Unsuccessful

Summary

What was recovered:

What could not be recovered:

RTO result:

RPO result:

Security result:

Business result:

44. Management Review

Management should review significant recovery results.

Review:

  • Recovery capability
  • RTO/RPO performance
  • Security posture
  • Business impact
  • Significant findings
  • Supplier issues
  • Residual risk
  • Corrective actions
  • Retest requirements
  • Recovery strategy

Management decision:

☐ Recovery accepted
☐ Corrective action required
☐ Retest required
☐ Risk treatment required
☐ Recovery strategy update required

45. Relationship With Other ISMS Records

The checklist should connect with:

Business Impact Assessment

→ Critical Service Register

→ RTO/RPO Assessment

→ ICT Dependency Register

→ Backup & Restore Procedure

→ Business Continuity Plan

→ Disaster Recovery Plan

→ ICT Business Continuity Plan

→ Emergency Access Procedure

→ Emergency Change Procedure

→ ICT Recovery Checklist

→ Disaster Recovery Test Report

→ Incident Management

→ Corrective Action Tracker

→ Risk Reassessment

→ ISMS Improvement Log

46. ISO/IEC 27001 Alignment

ICT recovery should be implemented based on the organization’s:

  • Information security risks
  • Business continuity requirements
  • ICT dependencies
  • Recovery objectives
  • Backup requirements
  • Security requirements
  • Supplier dependencies
  • Incident management requirements
  • Statement of Applicability
  • Applicable contractual and regulatory requirements

Relevant ISO/IEC 27001 areas may include information security continuity, ICT readiness for business continuity, backup, redundancy, access control, authentication, logging, monitoring, incident management, supplier security, change management, and continual improvement.

ISO/IEC 27001 does not prescribe a universal recovery sequence, RTO, RPO, or checklist. These should be determined by the organization’s business and risk requirements.

47. Audit Evidence

An auditor should be able to trace:

Business Service

→ ICT Dependency

→ Recovery Requirement

→ RTO/RPO

→ Recovery Strategy

→ Recovery Procedure

→ Recovery Activation

→ Technical Recovery

→ Security Validation

→ Business Validation

→ RTO/RPO Measurement

→ Findings

→ Corrective Actions

→ Risk Reassessment

→ Management Review

This demonstrates that ICT recovery is an operational capability rather than only documented planning.

48. Final Audit Trail

Disruption Identified

→ Recovery Authorized

→ Business Service Identified

→ Recovery Requirements Confirmed

→ Dependencies Reviewed

→ Recovery Team Activated

→ Recovery Environment Prepared

→ Emergency Access Controlled

→ Backup Validated

→ Infrastructure Recovered

→ Network Recovered

→ Identity Recovered

→ Storage Recovered

→ Database Recovered

→ Application Recovered

→ Security Controls Validated

→ Monitoring Enabled

→ Data Integrity Validated

→ Business Service Validated

→ RTO Measured

→ RPO Measured

→ Temporary Controls Reviewed

→ Recovery Completed

→ Findings Identified

→ Corrective Actions Assigned

→ Risk Reassessed

→ Management Review

→ Recovery Closed

49. Final Principle

ICT recovery is not simply bringing systems back online. It is the controlled restoration of technology, information, identity, security controls, dependencies, and business services—and demonstrating that the recovered environment is secure, functional, and fit for business use.

Identify → Protect → Recover → Secure → Validate → Measure → Improve