Business Continuity Plan

1. Purpose

The Business Continuity Plan (BCP) defines how the organization will maintain or restore critical business services when a disruption affects normal operations.

The plan provides a structured approach for:

Identifying critical business services.
Assessing the impact of disruption.
Activating business continuity arrangements.
Prioritizing recovery.
Protecting information and critical assets.
Maintaining essential operations.
Coordinating people, technology, suppliers, and communication.
Recovering critical services.
Verifying security and business functionality.
Returning to normal operations.
Recording lessons learned and improvements.

This plan should be used together with the organization’s Business Continuity & Information Security Policy, Information Security During Disruption Procedure, Incident Response Procedure, and Disaster Recovery Plan.

2. Scope

This plan applies to business activities and dependencies that are necessary to maintain critical operations.

It covers:

Employees and contractors
Management
Business processes
Customer services
Production systems
Cloud infrastructure
Applications
Databases
Networks
Identity and access systems
SaaS platforms
Source code and CI/CD
Backup systems
Critical suppliers
Customer and business information
Communication systems
Physical facilities
Remote-working arrangements

3. Business Continuity Objectives

The objectives of this plan are to:

Protect people and information.
Maintain critical business services.
Minimize customer and business impact.
Protect confidentiality, integrity, and availability.
Establish clear recovery priorities.
Restore critical services within defined recovery objectives.
Maintain appropriate security controls during disruption.
Provide clear communication.
Recover from trusted systems and data.
Learn from disruptions and improve resilience.

4. Business Continuity Principles

The organization shall follow these principles:

4.1 Protect People First

Personnel safety takes priority over technology or business recovery.

4.2 Critical Services First

Resources should first be directed toward services that are critical to customers, operations, security, revenue, or contractual obligations.

4.3 Security Must Continue

Business continuity activities should maintain appropriate information-security controls.

4.4 Recover From a Trusted State

Systems and data should be recovered from known-good and appropriately protected sources.

4.5 Communicate Clearly

Stakeholders should receive accurate and authorized information at appropriate intervals.

4.6 Document Important Decisions

Major continuity, recovery, security, and risk decisions should be recorded.

4.7 Improve After Every Test or Disruption

Exercises and real disruptions should result in lessons and, where appropriate, corrective actions.

5. Business Continuity Activation

The BCP may be activated when a disruption could materially affect one or more critical business services.

Potential activation triggers include:

Major production outage
Ransomware
Significant cybersecurity incident
Cloud outage
Cloud account compromise
Data breach
Critical database failure
Network outage
Critical SaaS outage
Major supplier failure
Loss of critical personnel
Loss of office/facility
Natural disaster
Extended power or internet outage
Significant data corruption
Major backup failure

The level of activation should be proportionate to the impact.

6. Business Continuity Activation Levels

The organization may use the following operational levels.

Level	Description	Typical Response
Level 1	Minor disruption	Normal business/IT response
Level 2	Significant disruption	Business continuity coordination
Level 3	Major disruption	Crisis management and prioritized recovery
Level 4	Critical disruption	Executive-led major continuity response

These levels are organizational classifications and may be adjusted to suit the organization’s risk profile.

7. Business Continuity Team

The continuity response may involve:

Role	Primary Responsibility
Executive Management	Strategic decisions and major risk acceptance
Business Continuity Coordinator	Coordinates BCP activation
Incident Commander	Coordinates major security incidents
Business Owner	Prioritizes business services
Security Lead	Maintains security requirements
IT/Cloud Lead	Technology recovery
Application/DevOps Lead	Application recovery
Supplier Owner	Critical supplier coordination
Privacy/Legal	Legal, privacy and regulatory advice
Communications/Customer Success	Customer and stakeholder communication
HR	Personnel and workforce coordination

In a startup, one person may perform multiple roles.

8. BCP Activation Process

Disruption Identified
↓
Initial Assessment
↓
Determine Business Impact
↓
Determine Security Impact
↓
Determine Activation Level
↓
Notify Responsible Roles
↓
Prioritize Critical Services
↓
Activate Continuity Measures
↓
Recover Services
↓
Verify Recovery
↓
Return to Normal Operations
↓
Post-Disruption Review

9. Initial Disruption Assessment

When a significant disruption occurs, the responsible person should determine:

What happened?
When did it happen?
Which services are affected?
Which locations are affected?
Which systems are affected?
Which information is affected?
Are customers affected?
Is personal or regulated information affected?
Is there an active security threat?
Are suppliers involved?
Is the disruption increasing?
Can normal operations continue?
Is BCP activation required?

Record the assessment.

10. Business Impact Assessment

For each affected service, assess:

Impact Area	Assessment
Customer Impact	None/Low/Medium/High/Critical
Revenue Impact	None/Low/Medium/High/Critical
Operational Impact	None/Low/Medium/High/Critical
Security Impact	None/Low/Medium/High/Critical
Data Impact	None/Low/Medium/High/Critical
Regulatory Impact	None/Low/Medium/High/Critical
Contractual Impact	None/Low/Medium/High/Critical
Reputation Impact	None/Low/Medium/High/Critical

The assessment should be updated as new information becomes available.

11. Critical Business Services

The organization should maintain a current list of critical business services.

For a SaaS startup, examples may include:

Customer-facing SaaS platform
Production database
Identity and authentication
Customer support
Payment/billing services
Critical communication
Security monitoring
Cloud infrastructure
Backup and recovery
CI/CD and deployment capability

Actual criticality should be determined by the organization’s business impact assessment.

12. Critical Service Register

Each critical service should have a record containing:

Field	Description
Service ID	Unique identifier
Service Name	Business service
Business Owner	Responsible owner
Technical Owner	Technical owner
Criticality	Critical/High/Medium/Low
Customers Affected	Customer dependency
Information Used	Data involved
Key Systems	Supporting technology
Key Suppliers	External dependencies
RTO	Recovery Time Objective
RPO	Recovery Point Objective
Minimum Service Level	Minimum acceptable operation
Recovery Procedure	Relevant procedure
Communication Requirement	Stakeholders
Last Test	Most recent test
Next Review	Planned review

13. Recovery Objectives

Each critical service should have appropriate recovery objectives.

Recovery Time Objective — RTO

The target time within which a service should be restored.

Recovery Point Objective — RPO

The maximum acceptable amount of data loss measured in time.

Example:

Service	Criticality	RTO	RPO
Production SaaS	Critical	4 hours	1 hour
Customer Database	Critical	4 hours	1 hour
Identity/SSO	High	4 hours	4 hours
Customer Support	High	8 hours	24 hours
Internal Collaboration	Medium	8 hours	24 hours
Development Environment	Medium	24 hours	24 hours

These values are examples and should be determined through business impact and risk assessment.

14. Minimum Business Operations

If full operations cannot be restored immediately, the organization should define a minimum acceptable service level.

Examples:

Limited customer access
Manual processing
Reduced product functionality
Temporary support channels
Alternate communication
Manual approvals
Reduced internal operations

The objective is to maintain the most important business functions while recovery continues.

15. Continuity Strategies

Depending on the disruption, continuity strategies may include:

Failover
Redundancy
Backup restoration
Alternate infrastructure
Alternate office
Remote working
Manual processing
Temporary supplier
Alternate communication channel
Service degradation
Application rollback
Database recovery
Infrastructure rebuild
Alternate cloud environment

The selected strategy should be based on business impact, risk, cost, and recovery requirements.

16. People Continuity

The organization should identify personnel required to operate critical services.

For critical roles:

Identify primary owner.
Identify backup personnel.
Document key responsibilities.
Maintain appropriate contact information.
Cross-train where practical.
Document critical operational knowledge.
Ensure emergency authority is understood.

Critical operations should not depend unnecessarily on a single individual.

17. Remote Working Continuity

If the primary workplace is unavailable:

Employees should work remotely where practical.
Approved devices should be used.
MFA should remain enabled.
Secure network access should be used.
Sensitive information should remain protected.
Corporate systems should be used instead of personal storage.
Security monitoring should continue.
Emergency access should remain controlled.

18. Technology Continuity

Technology continuity should address:

Cloud infrastructure
Applications
Databases
Networks
Identity
DNS
Storage
Backup
Monitoring
Security systems
CI/CD
Source code
Secrets
Encryption keys
Critical SaaS platforms

Recovery order should be based on service dependencies rather than simply restoring systems alphabetically or by technology type.

19. AWS SaaS Continuity Example

A SaaS application may depend on:

DNS
↓
Load Balancer
↓
Application
↓
Database
↓
Storage
↓
Secrets/KMS
↓
IAM
↓
Monitoring

If the production database fails:

Detect the failure.
Create/update incident record.
Assess customer and business impact.
Determine whether BCP activation is required.
Confirm database recovery options.
Identify the latest trusted backup or recovery point.
Restore or fail over.
Verify database integrity.
Verify application connectivity.
Verify IAM and security controls.
Verify logging and monitoring.
Validate customer functionality.
Communicate service status.
Continue monitoring.
Document the recovery.
Perform root-cause analysis where required.

20. Information Security During Continuity

Continuity arrangements must maintain appropriate security.

During recovery:

MFA should remain enabled where possible.
Least privilege should continue.
Emergency access must be controlled.
Sensitive data must remain protected.
Logging should continue.
Monitoring should continue.
Encryption should remain enabled.
Temporary accounts must be controlled.
Emergency changes must be documented.
Security exceptions must be authorized.

Where normal controls cannot be maintained, the Information Security During Disruption Procedure must be followed.

21. Backup and Recovery

Critical systems should have appropriate backup arrangements.

The BCP should identify:

What is backed up?
How frequently?
Where are backups stored?
How are backups protected?
Who can access them?
How long are they retained?
How are they restored?
When was the last restoration test?
What is the expected RPO?

Critical backups should be protected against unauthorized deletion or modification.

22. Recovery From a Trusted State

For security incidents or data corruption, recovery should not simply restore the affected environment without assessment.

Before restoration, consider:

Source of compromise
Backup age
Backup integrity
Malware risk
Unauthorized configuration
Credential exposure
Security-control status
Application integrity
Data integrity

Where appropriate:

Contain → Investigate → Identify Trusted Source → Restore → Secure → Verify

23. Supplier Continuity

Critical suppliers should be considered in the BCP.

For each critical supplier, identify:

Service
Business dependency
Criticality
Contact
Alternative arrangement
Expected recovery
Contractual commitments
Security requirements
Data involved
Exit/migration considerations

Supplier failure should be included in continuity exercises where appropriate.

24. Cloud Provider Dependency

For cloud services, the organization should understand:

Provider responsibilities
Organization responsibilities
Availability dependencies
Regional dependencies
Backup arrangements
Data-location considerations
Recovery capabilities
Service limits
Provider incident communication
Alternative recovery options

The organization should not assume that using a major cloud provider automatically guarantees business continuity.

25. Communication Plan

During significant disruption, communication should be coordinated.

Potential stakeholders include:

Employees
Management
Customers
Suppliers
Cloud providers
Business partners
Legal/privacy advisers
Regulators where applicable
Insurance providers

Communication should contain verified information and should not unnecessarily disclose security-sensitive information.

26. Communication Sequence

A typical sequence may be:

Disruption Identified
→ Internal Assessment
→ Management Notification
→ Relevant Teams Activated
→ Customer Impact Assessed
→ Initial Communication Where Required
→ Regular Status Updates
→ Recovery Communication
→ Service Restoration Notice
→ Closure Communication

The actual sequence depends on the disruption and contractual/legal requirements.

27. Emergency Changes

Emergency changes may be required during recovery.

Examples:

DNS change
Security-group change
Database restoration
Application rollback
Infrastructure rebuild
Emergency patch
Credential rotation
Failover

Emergency changes must be:

Authorized
Documented
Security assessed
Monitored
Validated
Reviewed afterward

Temporary emergency changes should be removed or formally incorporated into the normal environment.

28. Security Incident Integration

Where disruption results from a security incident:

Security Event
→ Event Assessment
→ Incident Classification
→ Incident Response
→ Containment
→ Evidence Preservation
→ Investigation
→ Business Continuity Activation
→ Recovery
→ Verification
→ Customer/Regulatory Assessment
→ Corrective Action
→ Lessons Learned

The BCP does not replace the Incident Response Procedure.

29. Crisis Management

For major disruptions, management may activate crisis-management arrangements.

Potential triggers:

Major customer outage
Significant data breach
Ransomware
Major cloud outage
Critical supplier failure
Extended service interruption
Significant regulatory impact
Major financial impact

The crisis team should establish:

Decision authority
Business priorities
Recovery priorities
Communication authority
Customer communication
Supplier coordination
Legal/privacy coordination
Management reporting

30. Recovery Sequence

A typical technology recovery sequence may be:

Confirm personnel safety.
Confirm incident/disruption status.
Protect evidence where applicable.
Contain active threats.
Confirm recovery authority.
Protect backups.
Restore identity/access capability.
Restore core infrastructure.
Restore databases/storage.
Restore application services.
Restore integrations.
Restore monitoring/security tools.
Validate data integrity.
Validate security controls.
Validate customer functionality.
Restore normal operations.

The actual order should follow documented service dependencies.

31. Recovery Verification

A service should not be considered recovered merely because it is technically online.

Verify:

Availability

Service accessible
Required components running
Performance acceptable

Integrity

Data consistent
Configuration correct
Application version verified

Security

MFA functioning
Access controls correct
Privileged accounts reviewed
Security groups/firewalls verified
Encryption enabled
Secrets protected

Monitoring

Logging active
Security monitoring active
Alerts functioning

Business

Critical customer workflows functioning
Support available
Business owner accepts recovery

32. Return to Normal Operations

Once critical services are stable:

Remove temporary workarounds.
Remove emergency access.
Revoke temporary credentials.
Remove temporary infrastructure.
Review emergency changes.
Restore normal processes.
Verify security controls.
Confirm backups.
Update stakeholders.
Close continuity activation.

33. Post-Disruption Review

After a significant disruption, conduct a review covering:

What happened?
What was the business impact?
What was the security impact?
How quickly was the disruption detected?
Was BCP activated appropriately?
Were recovery priorities correct?
Were RTO/RPO objectives achieved?
Were backups effective?
Were suppliers responsive?
Were communications effective?
Were security controls maintained?
What failed?
What worked?
What should change?

34. Corrective Actions

Findings should be entered into the Corrective Action Tracker where appropriate.

Possible improvements include:

Architecture changes
Additional redundancy
Backup improvements
Monitoring improvements
Access-control improvements
Supplier changes
Process improvements
Documentation
Training
Additional recovery capacity
New security controls
Additional testing

Actions should have an owner and target date.

35. Business Continuity Testing

The BCP should be tested periodically.

Testing methods include:

Tabletop Exercise

Discuss a realistic disruption and evaluate decisions.

Backup Restoration

Restore selected data or systems.

Technical Recovery Test

Recover a service in a controlled environment.

Failover Test

Test an alternate environment or service.

Communication Test

Test emergency contacts and communication channels.

Supplier Test

Validate critical supplier contacts and escalation.

Testing should produce:

Test record
Participants
Scenario
Decisions
Observations
Gaps
Corrective actions
Lessons learned
Management review

36. Sample Tabletop Scenario

Scenario

A privileged AWS identity is compromised.

The attacker creates an unauthorized IAM role and modifies a security group. The production SaaS service becomes partially unavailable.

Expected response

Detect

→ Security alert generated.

Assess

→ Determine whether compromise is genuine.

Contain

→ Restrict compromised identity and unauthorized access.

Preserve

→ Protect CloudTrail and related evidence.

Investigate

→ Determine affected resources and data.

Continuity

→ Assess customer impact and activate continuity arrangements if required.

Recover

→ Restore secure configuration and affected services.

Verify

→ Validate IAM, networking, application, data, logging and monitoring.

Communicate

→ Provide approved stakeholder updates.

Improve

→ Conduct RCA, corrective action and lessons learned.

37. Business Continuity Minimum Checklist

Preparation

Critical services identified.
Business owners identified.
Critical dependencies documented.
RTO defined.
RPO defined.
Recovery procedures documented.
Emergency contacts maintained.

People

Critical roles identified.
Backup personnel identified.
Delegated authority defined.
Remote-working arrangements available.

Technology

Critical systems identified.
Backups configured.
Backups protected.
Recovery procedures tested.
Monitoring available.
Security logging available.

Suppliers

Critical suppliers identified.
Supplier contacts maintained.
Supplier dependencies assessed.
Recovery arrangements understood.

During Disruption

Disruption recorded.
Business impact assessed.
Security impact assessed.
BCP activation decision documented.
Critical services prioritized.
Communication activated.
Recovery initiated.

Recovery

Trusted recovery source identified.
Systems restored.
Data integrity verified.
Security controls verified.
Monitoring restored.
Business functionality verified.

Closure

Temporary access removed.
Emergency changes reviewed.
Risks reassessed.
Lessons learned recorded.
Corrective actions assigned.
BCP updated where necessary.
Management review completed.

38. BCP Records

The organization should retain appropriate records such as:

BCP
Business Impact Assessment
Critical Service Register
Critical Dependency Register
RTO/RPO records
Recovery procedures
Recovery test records
Backup restoration records
Tabletop exercise records
Incident records
Crisis communication records
Supplier continuity records
Emergency change records
Security exception records
Lessons Learned Register
Corrective Action Tracker
Risk assessments
Management review records

39. ISO 27001 Alignment

This Business Continuity Plan supports the organization’s implementation of ISO/IEC 27001:2022, particularly the organization’s arrangements for:

Information security during disruption
ICT readiness for business continuity
Backup
Redundancy
Incident management
Access control
Logging and monitoring
Change management
Supplier security
Risk management
Continual improvement

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

This BCP should also be aligned with the organization’s business impact assessment, risk treatment, contractual requirements, customer commitments, and applicable legal/regulatory obligations.

40. Audit Evidence

An auditor may expect to see evidence such as:

Approved BCP
Business Impact Assessment
Critical Service Register
RTO/RPO definitions
Recovery procedures
Backup configuration
Backup restoration evidence
Recovery test results
Tabletop exercise records
Emergency contact records
Supplier continuity assessments
Incident records
Emergency change records
Security exception records
Recovery verification records
Lessons Learned Register
Corrective Action Tracker
Risk reassessment
Management review
BCP review and approval

The plan itself is not sufficient evidence that continuity capability works; testing and recovery evidence are important.

41. Final Audit Trail

Business Service Identified
→ Criticality Assessed
→ Business Impact Assessed
→ Dependencies Identified
→ RTO/RPO Defined
→ Continuity Strategy Established
→ Recovery Responsibilities Assigned
→ Backup & Recovery Capability Implemented
→ BCP Tested
→ Test Results Recorded
→ Gaps Identified
→ Corrective Actions Assigned
→ Disruption Occurs
→ BCP Activated
→ Critical Services Prioritized
→ Continuity Measures Implemented
→ Recovery Performed
→ Security Verified
→ Business Functionality Verified
→ Service Restored
→ BCP Deactivated
→ Lessons Learned
→ Risk Reassessed
→ Improvements Implemented
→ Management Review

42. Final Principle

A Business Continuity Plan is effective only when the organization can continue its most important services during disruption and recover them within defined business and security requirements.

Identify → Prepare → Prioritize → Protect → Respond → Continue → Recover → Verify → Restore → Learn → Improve

The objective is:

Protect people + Protect information + Maintain critical services + Recover within defined objectives + Verify security + Learn from disruption.

ISO/IEC 27001