ICT Business Continuity Plan

1. Purpose

The ICT Business Continuity Plan (ICT BCP) defines how the organization will maintain or restore critical information and communication technology services when normal ICT operations are disrupted.

The plan focuses specifically on the continuity of:

Cloud infrastructure
Applications and APIs
Databases
Networks and connectivity
Identity and access management
Security services
Backup and recovery systems
Source code and CI/CD
Monitoring and logging
Critical SaaS platforms
Technology suppliers and service providers

The objective is not simply to restore technology. The objective is to maintain critical business services through a disruption while preserving security, confidentiality, integrity, and availability.

2. Scope

This plan applies to ICT services supporting:

Customer-facing applications
Production environments
Internal business applications
Databases and data stores
Cloud infrastructure
Network connectivity
Identity and authentication
Security monitoring
Backup and recovery
Source code repositories
CI/CD platforms
Critical SaaS applications
Communication systems
Critical suppliers and technology dependencies
Remote-working infrastructure

The scope should be aligned with the organization’s:

ISMS scope
Business Continuity Plan
Business Impact Assessment
Risk Assessment
Disaster Recovery Plan
Critical Service Register
ICT Dependency Register

3. ICT Continuity Objectives

The organization shall establish ICT continuity arrangements that enable it to:

Protect critical information during disruption.
Maintain availability of critical technology services.
Restore critical ICT services within defined recovery objectives.
Protect backups and recovery resources.
Maintain security controls during continuity operations.
Provide secure emergency access where required.
Maintain appropriate logging and monitoring.
Coordinate with critical technology suppliers.
Communicate technology disruptions to relevant stakeholders.
Validate the security and integrity of recovered systems.
Record significant decisions and recovery actions.
Learn from disruptions and improve ICT resilience.

4. ICT Continuity Principles

ICT continuity shall be based on the following principles:

Critical services first

Recovery priorities shall be based on business impact and service criticality.

Security continues during disruption

Business continuity does not mean that security controls can simply be bypassed.

Recover from a trusted state

Systems should be recovered from known-good infrastructure, configurations, backups, source code, and recovery points.

Protect recovery resources

Backups, recovery accounts, recovery environments, credentials, secrets, and infrastructure-as-code must be protected from the same incident affecting production.

Minimize dependencies

Critical services should have their important technology and supplier dependencies identified.

Defined recovery objectives

Recovery requirements should be based on documented business needs, including RTO and RPO where applicable.

Evidence-based recovery

Recovery should be supported by documented evidence rather than assumptions.

Test before crisis

Continuity and recovery capabilities should be periodically tested according to risk and criticality.

5. ICT Critical Services

The organization should maintain an ICT Critical Service Register.

ICT Service	Business Service	Criticality	RTO	RPO	Primary Dependency	Recovery Method
Production SaaS	Customer service	Critical	4 hrs	1 hr	AWS	DR environment
Customer Database	Customer operations	Critical	4 hrs	1 hr	AWS RDS	Backup/PITR
Identity/SSO	Workforce access	High	4 hrs	4 hrs	IdP	Secondary access
Source Code	Product development	High	8 hrs	4 hrs	Git platform	Repository recovery
CI/CD	Software deployment	High	8 hrs	4 hrs	CI/CD provider	Rebuild
Email/Collaboration	Business communication	Medium	8 hrs	24 hrs	SaaS provider	Provider recovery
Internal Applications	Internal operations	Medium	24 hrs	24 hrs	SaaS/Cloud	Service restoration

Note: RTO and RPO values above are examples. Actual targets should be established from the organization’s Business Impact Assessment and recovery requirements.

6. ICT Dependency Mapping

For every critical ICT service, the organization should understand:

Business Service → ICT Service → Application → Infrastructure → Data → Identity → Network → Supplier → Recovery Dependency

For example:

Customer SaaS → Web Application → ECS → RDS → S3 → IAM → VPC → AWS → Backup

This dependency chain helps identify hidden recovery dependencies.

7. ICT Disruption Scenarios

The ICT BCP should consider scenarios relevant to the organization.

Examples include:

Cloud disruption

Cloud region outage
Cloud service failure
Cloud account compromise
Loss of cloud connectivity
Misconfiguration
Cloud provider incident

Cybersecurity disruption

Ransomware
Malware
Account compromise
Data breach
DDoS attack
Credential compromise
CI/CD compromise
Supply-chain attack

Technology failure

Database failure
Storage failure
Application failure
Network failure
DNS failure
Authentication failure
Hardware failure

Data disruption

Data corruption
Accidental deletion
Unauthorized modification
Backup failure
Loss of recovery point

Supplier disruption

Critical SaaS outage
Cloud provider outage
Managed service provider failure
Payment provider outage
Communication provider failure

People disruption

Loss of key technical personnel
Unavailability of administrators
Workforce disruption
Loss of critical knowledge

8. ICT Business Impact Assessment

The organization should assess the impact of ICT service disruption on:

Impact Area	Assessment
Customer service	What customer services stop?
Revenue	What revenue-generating activity is affected?
Security	Does the disruption create additional security risk?
Confidentiality	Could information become exposed?
Integrity	Could information become corrupted or inaccurate?
Availability	How long can the service remain unavailable?
Regulatory	Are regulatory obligations affected?
Contractual	Are customer commitments affected?
Operations	Which internal processes stop?
Reputation	Could customers or partners be materially affected?
Dependencies	Which other services become unavailable?

The result should determine recovery priority and required continuity controls.

9. Recovery Prioritization

ICT services should normally be restored according to business criticality.

Example:

Priority 1 – Critical

Customer production
Customer database
Identity/security controls
Critical network services

Priority 2 – High

CI/CD
Source code
Monitoring
Critical internal applications

Priority 3 – Medium

Collaboration systems
Non-critical SaaS
Development environments

Priority 4 – Low

Non-critical tools
Test environments
Convenience services

The actual prioritization should be based on business impact rather than technology preference.

10. ICT Continuity Strategies

Possible continuity strategies include:

Redundancy

Use redundant infrastructure or services where justified by risk.

Backup

Maintain protected and tested backups for critical information.

Replication

Replicate critical information or services where required.

Failover

Maintain the ability to move services to an alternate environment.

Infrastructure as Code

Maintain infrastructure definitions so critical environments can be rebuilt consistently.

Alternative suppliers

Identify alternatives for highly critical technology dependencies where practical.

Manual workaround

Define temporary manual processes where technology cannot immediately be restored.

Remote working

Maintain secure remote-working capabilities for workforce continuity.

Emergency access

Maintain controlled break-glass access for recovery activities.

Emergency change

Allow controlled emergency changes when normal change procedures would create unacceptable delay.

11. AWS SaaS Example

Consider a SaaS startup running its production environment on AWS.

Architecture:

Route 53 → CloudFront/WAF → Load Balancer → ECS → RDS → S3

Supporting services:

IAM
KMS
Secrets Manager
CloudTrail
CloudWatch
GuardDuty
Security Hub
CI/CD
Backup services

A regional disruption affects the production environment.

The ICT continuity process may be:

Disruption Detected
↓
Business Impact Assessed
↓
ICT Continuity Activated
↓
Customer Service Prioritized
↓
Recovery Environment Prepared
↓
IAM/Security Controls Established
↓
Network Restored
↓
Database Restored
↓
Application Restored
↓
Secrets/KMS Validated
↓
Monitoring & Logging Enabled
↓
Application Security Tested
↓
Business Validation
↓
Customer Service Restored
↓
Enhanced Monitoring
↓
Recovery Review

A successful application deployment alone should not be considered proof of successful recovery. Security controls, data integrity, access, monitoring, and business functionality must also be validated.

12. ICT Continuity Activation

The ICT BCP may be activated when:

A critical ICT service becomes unavailable.
Recovery through normal operational procedures is insufficient.
A major cloud outage occurs.
A ransomware or major cyber incident affects technology.
Critical data is corrupted or unavailable.
A critical supplier becomes unavailable.
A major network failure occurs.
A disaster recovery event is declared.
A major business disruption requires technology continuity measures.

The Incident Commander, Business Owner, ICT/IT Lead, or designated management authority should determine whether formal activation is required.

13. ICT Continuity Response

Step 1 — Detect

Identify the technology disruption.

Record:

Date/time
Affected service
Detection source
Initial symptoms
Initial business impact

Step 2 — Assess

Determine:

What failed?
Which business services are affected?
Which information is affected?
Is this a security incident?
Is customer service affected?
Are critical suppliers involved?
Is data integrity affected?
Is the issue expected to exceed normal recovery capability?

Step 3 — Activate

If required:

Activate ICT continuity team.
Assign Incident Commander/Recovery Lead.
Notify business owners.
Establish communication channel.
Start decision log.
Define recovery priorities.

14. Protect Information and Backups

Before recovery begins:

Protect available backups.
Prevent accidental backup deletion.
Protect recovery credentials.
Preserve important logs.
Protect encryption keys.
Preserve source code.
Preserve infrastructure-as-code.
Isolate compromised environments where necessary.
Prevent the incident from spreading into the recovery environment.

For ransomware or compromise scenarios, recovery should not blindly restore potentially compromised systems.

15. Emergency Access

Recovery may require privileged or emergency access.

Emergency access should:

Have a documented business reason.
Be explicitly authorized.
Use strong authentication.
Use minimum required privileges.
Be time-limited.
Be monitored.
Be logged.
Be revoked after recovery.
Be reviewed after use.

The organization should not rely on undocumented shared administrator passwords.

16. Emergency Changes

Emergency changes may be required during ICT continuity.

Examples:

Modify firewall/security group rules.
Redirect traffic.
Restore infrastructure.
Change DNS.
Restore database services.
Modify routing.
Deploy emergency application fixes.
Activate alternate infrastructure.

Emergency changes should still record:

Change → Reason → Risk → Approval → Implementation → Validation → Monitoring → Rollback/Review

17. Recovery Sequence

The recovery sequence should be based on service dependencies.

A typical SaaS recovery sequence may be:

Cloud account
IAM and security controls
Network/VPC
Security groups/WAF
Storage
Database
Application infrastructure
Secrets and encryption
Load balancing
DNS
Monitoring and logging
Application validation
Business validation
Customer service restoration

The actual sequence should be customized to the organization’s architecture.

18. Recovery Validation

Before declaring recovery complete, verify:

Security

IAM is secure.
MFA is enabled.
Privileged access is reviewed.
Security groups are correct.
Encryption is enabled.
Logging is functioning.
Monitoring is active.
Security alerts are functioning.

Data

Required data is available.
Data integrity has been checked.
Backup restoration completed successfully.
RPO was achieved or deviation documented.

Application

Application starts correctly.
APIs operate correctly.
Authentication works.
Critical workflows work.
Integrations operate.

Business

Business owner validates service.
Customer-facing functionality works.
Critical transactions can be completed.
Customer impact is understood.

19. RTO and RPO Assessment

After recovery, record:

Metric	Target	Actual	Result
RTO	4 hours	3h 35m	Achieved
RPO	1 hour	42 min	Achieved
Data validation	Required	Completed	Achieved
Security validation	Required	Completed	Achieved
Business validation	Required	Completed	Achieved

If the target was not achieved, the organization should:

Document the deviation.
Determine the reason.
Assess the resulting risk/business impact.
Create corrective action where necessary.
Reassess the recovery strategy.

20. Communication During ICT Disruption

Communication should be:

Timely
Accurate
Authorized
Fact-based
Need-to-know
Consistent

Potential stakeholders include:

Executive management
ICT/IT team
Security team
Business owners
Employees
Customers
Critical suppliers
Cloud providers
Legal/privacy team
Regulators where applicable

Communication should distinguish between:

Confirmed Facts | Current Impact | Actions Taken | Unknowns | Next Update

Avoid speculation during an active incident.

21. Supplier and Cloud Provider Coordination

Critical technology suppliers should be included in ICT continuity planning.

The organization should maintain:

Supplier contact information
Service criticality
Escalation contacts
Support arrangements
Contractual commitments
Recovery capabilities
Alternative arrangements where appropriate
Exit/dependency information

For AWS or another cloud provider, the organization should understand which recovery responsibilities belong to the provider and which remain with the organization.

22. Security During ICT Continuity

Temporary continuity arrangements must not create uncontrolled security exposure.

Examples:

Continuity Requirement	Security Control
Emergency admin access	MFA + temporary role
Alternate environment	Secure baseline
Temporary network access	Restricted rules
Emergency deployment	Change record
Backup restoration	Integrity validation
Remote working	Secure authentication
Temporary supplier	Due diligence/risk review
Emergency credentials	Time-limited + monitored
Degraded operation	Documented security exception

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

Exception → Reason → Risk → Compensating Control → Approval → Expiry/Review

23. ICT Continuity Testing

The organization should periodically test its ICT continuity capability.

Possible tests include:

Tabletop exercise
Cloud outage simulation
Backup restoration
Database restoration
Application recovery
Infrastructure rebuild
Failover test
Emergency access test
Emergency change test
Supplier continuity test
Communication test
Ransomware recovery exercise
Regional cloud recovery test

Testing should produce evidence and corrective actions.

A test is successful only when the organization can demonstrate what it actually recovered, how long it took, what failed, and what was improved.

24. ICT Continuity Test Evidence

Evidence may include:

Test plan
Test scenario
Participant list
Recovery timestamps
Backup restoration evidence
Cloud configuration
Infrastructure deployment records
Application validation
Database validation
Security validation
Monitoring screenshots/logs
Communication records
Decision logs
RTO/RPO measurements
Findings
Corrective actions
Retest results

25. Roles and Responsibilities

Role	Responsibility
Executive Management	Business decisions and activation authority
Business Owner	Defines business recovery priorities
ICT/IT Lead	Coordinates technology recovery
Incident Commander	Coordinates major disruption response
Security Lead	Ensures security during recovery
Cloud/Infrastructure Lead	Restores infrastructure
Application Lead	Restores applications
Database Owner	Restores and validates data
DevOps Lead	Restores CI/CD and deployment capability
Supplier Owner	Coordinates critical suppliers
Privacy/Legal	Assesses legal/privacy obligations
Communications	Coordinates stakeholder communication

For a startup, one person may hold multiple roles, provided decision-making and security responsibilities remain appropriately controlled.

26. ICT Continuity Records

The organization should retain appropriate records such as:

ICT Critical Service Register
Business Impact Assessment
ICT Dependency Register
ICT Business Continuity Plan
Disaster Recovery Plan
Recovery Runbooks
Backup records
Recovery test reports
Supplier continuity records
Emergency Access records
Emergency Change records
Incident records
Decision logs
Communication records
Corrective Action Tracker
Lessons Learned Register
ISMS Improvement Log

27. Relationship With Other ISMS Documents

The ICT BCP should not operate independently.

Typical relationship:

Business Impact Assessment
↓
Critical Service Register
↓
Risk Assessment
↓
ICT Business Continuity Plan
↓
Disaster Recovery Plan
↓
Recovery Runbooks
↓
Backup & Recovery
↓
Testing
↓
Test Results
↓
Corrective Actions
↓
Lessons Learned
↓
Risk Reassessment
↓
ISMS Improvement

This creates a continuous improvement cycle rather than a standalone continuity document.

28. Startup Implementation

A startup does not necessarily need a complex continuity architecture.

A practical minimum model can be:

1. Identify

Document the top 5–10 critical ICT services.

2. Understand

Map each service to:

Application → Data → Cloud → Identity → Supplier → Backup

3. Define

Set business-approved RTO/RPO targets.

4. Protect

Implement:

MFA
Least privilege
Backups
Logging
Monitoring
Secure configuration
Infrastructure-as-code where practical

5. Recover

Document how each critical service can be restored.

6. Test

Perform at least practical recovery exercises appropriate to risk.

7. Improve

Track gaps in the Corrective Action Tracker and ISMS Improvement Log.

29. ICT Continuity Checklist

Before approving the plan, verify:

Critical ICT services identified
Business owners identified
ICT dependencies mapped
Critical information identified
Business impact assessed
RTO/RPO established where applicable
Recovery priorities defined
Recovery strategies documented
Backups identified
Backup protection verified
Recovery procedures documented
Emergency access defined
Emergency change process defined
Security controls defined for continuity
Critical suppliers identified
Supplier escalation contacts available
Communication procedures defined
Recovery responsibilities assigned
Recovery testing performed
Test evidence retained
Findings recorded
Corrective actions assigned
Recovery objectives reviewed
Plan periodically reviewed

30. ISO/IEC 27001 Alignment

ICT continuity arrangements should be integrated with the organization’s risk-based ISMS.

Relevant areas may include:

Information security during disruption
ICT readiness for business continuity
Backup
Redundancy
Logging and monitoring
Access control
Privileged access
Configuration management
Change management
Incident management
Supplier security
Cloud services
Information protection
Business continuity testing

The organization should determine the applicable controls through its risk assessment and risk treatment process and reflect applicable controls in the Statement of Applicability (SoA).

The ICT BCP is therefore not simply an Annex A checklist. It is operational evidence that the organization’s identified continuity and information-security risks are being addressed.

31. Audit Evidence

An auditor should be able to trace:

Critical Business Service
→ ICT Dependency
→ Business Impact
→ Risk
→ RTO/RPO
→ Continuity Strategy
→ Recovery Procedure
→ Test
→ Actual Recovery Result
→ Finding
→ Corrective Action
→ Risk Reassessment
→ Management Review

For example:

Customer SaaS
→ AWS production
→ Critical service
→ RTO 4 hours
→ AWS recovery strategy
→ DR procedure
→ Recovery test
→ Actual recovery 3h 35m
→ Database restoration issue identified
→ Corrective action
→ Retest
→ Management review

That is significantly stronger evidence than simply presenting an approved ICT BCP document.

32. Final Audit Trail

ICT Service Identified
→ Business Criticality Assessed
→ Dependencies Identified
→ Business Impact Assessed
→ Recovery Requirement Defined
→ RTO/RPO Established
→ Continuity Strategy Defined
→ Recovery Responsibility Assigned
→ Security Controls Defined
→ Recovery Procedure Established
→ Continuity Capability Tested
→ Actual Recovery Measured
→ Security Validated
→ Business Service Validated
→ Findings Identified
→ Corrective Actions Assigned
→ Risk Reassessed
→ Management Review
→ ICT Continuity Capability Improved

33. Final Principle

ICT Business Continuity is not simply keeping technology available. It is the organization’s ability to maintain or restore critical technology services securely, recover trusted information and systems, meet business recovery requirements, and demonstrate that the recovery capability actually works.

Identify Critical Services + Understand Dependencies + Protect Information + Define Recovery Objectives + Prepare Recovery Capability + Maintain Security + Test + Measure + Improve.