Business Continuity & Information Security Policy

1. Purpose

The purpose of this policy is to establish the organization’s approach to maintaining the confidentiality, integrity, and availability of information and critical business services during disruptions.

The organization recognizes that business continuity and information security are closely connected. A cybersecurity incident, cloud outage, supplier failure, ransomware attack, data loss, system failure, or other disruption may affect the organization’s ability to deliver services.

This policy establishes the principles for:

Protecting critical information and systems.
Maintaining availability of critical business services.
Preparing for disruptive events.
Responding to information-security-related disruptions.
Recovering systems and business operations.
Protecting backups and recovery resources.
Maintaining appropriate communication.
Testing business continuity and recovery arrangements.
Learning from disruptions and improving resilience.

2. Scope

This policy applies to:

Employees
Contractors
Temporary personnel
Management
IT and security teams
Cloud and infrastructure teams
Development and DevOps teams
Business process owners
Suppliers and service providers where applicable
Information assets
Business applications
Cloud environments
Production systems
Corporate systems
Networks
Databases
SaaS platforms
Source code and CI/CD systems
Backup and recovery systems
Critical third-party services
Physical locations supporting critical operations

The policy applies to both cybersecurity incidents and non-cybersecurity disruptions that could materially affect information security or critical business services.

3. Policy Statement

The organization shall maintain appropriate business continuity and information security arrangements based on business requirements and risk.

The organization shall:

Identify critical business services and supporting information assets.
Assess risks that could disrupt those services.
Establish appropriate continuity and recovery requirements.
Protect critical information and technology resources.
Maintain appropriate backups and recovery capabilities.
Establish incident response and escalation processes.
Define recovery responsibilities.
Test continuity and recovery arrangements periodically.
Protect information during disruption and recovery.
Review lessons learned after significant disruptions.
Continually improve resilience based on changes in business, technology, threats, and risks.

4. Business Continuity Principles

The organization shall apply the following principles:

4.1 Business-Critical Services First

Continuity planning should focus first on services whose disruption could materially affect customers, revenue, regulatory obligations, security, or critical operations.

4.2 Risk-Based Planning

Continuity measures should be proportionate to the risk and business impact.

4.3 Security Must Continue During Disruption

Emergency recovery must not unnecessarily bypass security controls.

4.4 Recovery From a Trusted State

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

4.5 Protect Information During Recovery

Confidential, personal, customer, financial, and other sensitive information must remain protected during emergency operations.

4.6 Defined Decision Authority

The organization should know who can declare a major disruption, activate recovery procedures, approve emergency actions, and authorize return to normal operations.

4.7 Test Before an Actual Crisis

Continuity and recovery arrangements should be tested periodically to identify weaknesses before a real disruption occurs.

5. Business Continuity Risk

The organization should consider disruptions such as:

Cyberattack
Ransomware
Cloud service outage
Cloud account compromise
Data breach
Database failure
Application failure
Infrastructure failure
Network outage
Power failure
Internet outage
Supplier failure
SaaS provider outage
Key-person unavailability
Loss of office or physical facility
Natural disaster
Fire
Flood
Pandemic or widespread workforce disruption
Major software failure
Backup failure
Data corruption
Accidental deletion
Critical vulnerability exploitation
Supply-chain compromise

The organization should periodically reassess these risks as the business and threat environment changes.

6. Business Impact Assessment

Business owners should identify the impact of disruption to critical services.

Assessment may consider:

Impact Area	Example
Customer	Customers cannot access SaaS platform
Revenue	Transaction processing unavailable
Security	Security monitoring unavailable
Regulatory	Required service or reporting unavailable
Contractual	SLA or customer commitment affected
Operational	Employees cannot perform critical processes
Financial	Direct or indirect financial loss
Reputation	Loss of customer confidence
Data	Loss, corruption, or unauthorized disclosure
Safety	Physical or personnel safety impact

The organization should identify the maximum acceptable level of disruption for important services.

7. Recovery Objectives

Business continuity and recovery requirements should define appropriate objectives such as:

Recovery Time Objective (RTO)

The target period within which a service or system should be restored following disruption.

Recovery Point Objective (RPO)

The maximum acceptable amount of data loss measured in time.

For example:

Service	RTO	RPO
Production SaaS Application	4 hours	1 hour
Customer Database	4 hours	1 hour
Identity/SSO	4 hours	4 hours
Internal Collaboration	8 hours	24 hours
Development Environment	24 hours	24 hours

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

8. Critical Information and Assets

The organization shall identify information and technology resources required to maintain critical services.

Examples include:

Customer information
Production databases
Application source code
Cloud infrastructure
IAM/SSO
Encryption keys
Secrets
Configuration
Infrastructure-as-Code
CI/CD pipelines
DNS
Domain management
Backup systems
Monitoring
Security tooling
Customer support systems
Financial systems
Critical supplier services

Critical dependencies should be documented.

9. Information Security During Business Disruption

Security requirements shall continue to apply during business continuity and recovery activities.

Emergency actions should not unnecessarily result in:

Shared credentials
Disabled MFA
Uncontrolled administrative access
Unencrypted data transfer
Unapproved software
Uncontrolled remote access
Unprotected backups
Unlogged emergency changes
Uncontrolled temporary accounts
Unauthorized access to customer information

Where emergency exceptions are unavoidable, they should be:

Authorized.
Time-bound.
Documented.
Monitored.
Reviewed after the emergency.
Removed when no longer required.

10. Backup and Recovery

Critical information and systems should have appropriate backup and recovery arrangements.

Backup requirements should consider:

Criticality
RPO
Data sensitivity
Recovery requirements
Retention
Encryption
Access control
Geographic resilience where required
Backup integrity
Recovery testing

Backups should be protected against unauthorized modification and deletion.

For high-risk environments, the organization should consider controls such as:

Immutable backups
Separate backup accounts
Restricted administrative access
Separate credentials
Backup monitoring
Offline or logically isolated recovery copies where justified

11. AWS SaaS Example

For an AWS-based SaaS application, continuity may depend on:

Users → DNS → Load Balancer → Application → Database → Storage → Secrets → IAM → Monitoring

The organization should understand how failure of each dependency could affect the service.

For example, if a production database becomes unavailable:

Incident is detected.
Incident severity is assessed.
Incident Response Team is activated if appropriate.
Database availability is investigated.
Backup/recovery options are assessed.
Recovery decision is made.
Database is restored or service is failed over according to the recovery procedure.
Application connectivity is verified.
Data integrity is validated.
Security controls are verified.
Customer service is restored.
Incident and recovery actions are documented.
Root cause and corrective actions are reviewed.

Recovery is not considered complete simply because the system is online.

12. Disaster Recovery

The organization should maintain appropriate disaster-recovery arrangements for critical technology services.

Disaster recovery may address:

Cloud infrastructure
Databases
Applications
Network services
Identity services
Storage
Backups
DNS
CI/CD
Monitoring
Security tooling
Critical SaaS dependencies

Recovery procedures should define:

Trigger
Decision authority
Recovery sequence
Responsible roles
Required resources
Dependencies
Security controls
Validation steps
Communication
Return-to-normal process

13. Incident Response and Business Continuity

Information security incidents that significantly affect business operations should be managed using both incident-response and continuity processes.

For example:

Ransomware

Security Incident
→ Containment
→ Evidence Preservation
→ Impact Assessment
→ Business Continuity Activation
→ Recovery From Trusted Backup
→ Security Verification
→ Service Restoration
→ Customer/Regulatory Communication Assessment
→ Root Cause
→ Corrective Actions

Business continuity should not replace incident response.

Both processes should operate together.

14. Crisis Management

For significant disruptions, management may activate a crisis-management process.

Potential triggers include:

Major customer impact
Extended production outage
Major ransomware incident
Significant data breach
Critical cloud outage
Major supplier failure
Significant regulatory impact
Major financial or operational impact

The crisis-management process should establish:

Incident/crisis leader
Decision authority
Communication channel
Business priorities
Recovery priorities
Customer communication
Supplier coordination
Legal/privacy coordination
Management updates
Recovery approval

15. Communication During Disruption

Communication should be:

Timely
Accurate
Authorized
Fact-based
Appropriate for the audience
Consistent
Protected from unnecessary disclosure

Communication may involve:

Employees
Management
Customers
Suppliers
Cloud providers
Business partners
Legal/privacy advisers
Regulators
Insurance providers
Law enforcement where appropriate

Only authorized personnel should communicate externally about significant incidents or disruptions.

16. Emergency Communication

If normal corporate systems are unavailable or compromised, the organization should have alternative communication methods.

Examples may include:

Approved alternate messaging platform
Emergency phone contacts
Secondary email
Emergency contact list
Cloud-based communication channel
Incident-management platform

Alternative channels should themselves be appropriately protected.

17. Supplier and Cloud Dependency

Critical suppliers and cloud providers should be considered in continuity planning.

The organization should identify:

Critical supplier
Service provided
Business dependency
Information processed
Availability requirements
Supplier failure impact
Recovery options
Alternative supplier where justified
Contractual commitments
Supplier incident communication process
Exit or migration considerations

Cloud services should be assessed using the applicable shared-responsibility model.

18. People and Key-Person Dependency

Business continuity planning should consider the unavailability of critical personnel.

The organization should identify:

Critical roles
Backup personnel
Delegated authority
Required skills
Emergency contact information
Documentation required for recovery
Cross-training requirements

Critical recovery activities should not depend unnecessarily on one individual.

19. Remote Working and Alternate Operations

Where remote work is required during a disruption:

Approved devices should be used.
MFA should remain enabled.
Secure remote access should be used.
Sensitive information should remain protected.
Emergency access should be monitored.
Unauthorized personal storage should not be used for company information.
Security monitoring should continue where practical.

20. Emergency Change Management

Emergency changes may be necessary during a disruption.

Emergency changes should:

Have a legitimate business or security reason.
Be authorized by an appropriate person.
Be documented.
Be tested where practical.
Be implemented with appropriate security controls.
Be monitored.
Be reviewed after implementation.
Be reverted or formally incorporated into normal configuration where appropriate.

Emergency status must not become a permanent bypass of change management.

21. Recovery Verification

Before declaring recovery complete, the organization should verify:

Service availability
Data integrity
Authentication
Authorization
Security configuration
Network controls
Logging
Monitoring
Backup status
Vulnerability status
Secrets and credentials
Integration functionality
Customer functionality
Security alerts
Residual risk

The service owner and appropriate technical/security personnel should approve return to normal operations.

22. Return to Normal Operations

After recovery, the organization should:

Confirm the root cause is understood or appropriately managed.
Remove temporary emergency controls.
Remove temporary accounts.
Revoke emergency access.
Restore standard configurations.
Review security logs.
Verify monitoring.
Validate backups.
Review customer impact.
Complete required communications.
Record lessons learned.
Create corrective actions.
Reassess risk.
Update continuity and recovery documentation.

23. Testing and Exercises

Business continuity and recovery arrangements should be tested periodically.

Testing may include:

Tabletop Exercise

Discuss a disruption scenario and evaluate decision-making.

Technical Recovery Test

Restore systems or data in a controlled environment.

Backup Restore Test

Restore selected backups and validate data integrity.

Failover Test

Test switching to an alternate system or environment.

Communication Test

Test emergency communication channels.

Supplier Continuity Test

Validate critical supplier contacts and recovery arrangements.

Full or Partial Simulation

Simulate a realistic disruption where justified by risk.

Testing should produce documented results and corrective actions.

24. Lessons Learned

Following significant disruptions or exercises, the organization should review:

What happened?
What worked?
What failed?
Was the disruption detected quickly?
Were roles clear?
Was escalation timely?
Were backups available?
Was recovery successful?
Were security controls maintained?
Was customer communication effective?
Were suppliers responsive?
Were RTO/RPO objectives achieved?
What gaps were identified?
What improvements are required?

Lessons should be recorded and tracked to completion.

25. Business Continuity Documentation

The organization should maintain appropriate documentation such as:

Business Continuity Policy
Business Impact Assessment
Business Continuity Plans
Disaster Recovery Plan
Critical Service Register
Critical Dependency Register
Recovery Procedures
Backup and Recovery Procedure
Incident Response Plan
Crisis Communication Procedure
Emergency Contact List
Supplier Continuity Information
Recovery Test Records
Tabletop Exercise Records
Lessons Learned Register
Corrective Action Tracker

Not every organization requires a separate document for every item. Documentation should be proportionate to business complexity and risk.

26. Roles and Responsibilities

Role	Responsibility
Executive Management	Approves continuity strategy and major recovery decisions
Business Owner	Defines business impact and service priorities
ISMS/Security Lead	Ensures information-security requirements are incorporated
IT/Cloud Lead	Leads technology recovery
Application/DevOps Lead	Supports application and deployment recovery
Incident Commander	Coordinates major security incidents
BCP/DR Coordinator	Coordinates continuity and recovery activities
Privacy/Legal	Advises on privacy, legal, regulatory and contractual obligations
Supplier Owner	Coordinates critical suppliers
Employees	Follow continuity and security procedures

One person may perform multiple roles in a startup, provided decision authority and conflicts of interest are appropriately managed.

27. Policy Exceptions

Exceptions to this policy require:

Business justification
Risk assessment
Compensating controls where appropriate
Defined owner
Approval
Expiry/review date
Documentation

Security requirements should not be permanently bypassed through informal emergency arrangements.

28. Policy Compliance

Failure to comply with this policy may result in:

Security risk
Business disruption
Customer impact
Data loss
Regulatory or contractual consequences
Corrective action
Additional management review

The organization may conduct reviews, assessments, exercises, or audits to evaluate compliance.

29. Policy Review

This policy should be reviewed at least periodically and when significant changes occur, including:

Major business changes
New critical services
Significant technology changes
Cloud architecture changes
Major incidents
Changes in suppliers
Changes in legal or regulatory requirements
Results of continuity testing
Changes in threat environment
Significant audit findings

The review should determine whether the policy remains appropriate and effective.

30. Audit Evidence

Typical evidence may include:

Approved Business Continuity & Information Security Policy
Business Impact Assessment
Critical Service Register
Business Continuity Plans
Disaster Recovery Plan
Recovery procedures
Backup configuration
Backup restoration evidence
Recovery test records
Tabletop exercise records
Incident response records
Crisis communication records
Supplier continuity assessments
RTO/RPO definitions
Recovery test results
Lessons Learned Register
Corrective Action Tracker
Risk assessments
Management review records
Policy review records

31. ISO 27001 Alignment

This policy supports the organization’s information-security continuity arrangements under ISO/IEC 27001:2022.

Relevant implementation areas include:

Information security during disruption
ICT readiness for business continuity
Backup
Redundancy
Information security incident management
Business continuity planning
Recovery
Access control
Change management
Supplier management
Risk management
Continual improvement

The specific controls selected by the organization should be determined through the risk assessment and Statement of Applicability (SoA).

Business continuity requirements should also be aligned with the organization’s business impact analysis, risk assessment, contractual commitments, and applicable legal/regulatory requirements.

32. Startup Implementation Model

A startup can establish an effective continuity capability without creating excessive documentation.

A practical model is:

Critical Services
↓
Business Impact Assessment
↓
Critical Dependencies
↓
RTO/RPO
↓
Risk Assessment
↓
Continuity Strategy
↓
Backup & Recovery
↓
Incident Response
↓
Disaster Recovery
↓
Communication
↓
Testing
↓
Lessons Learned
↓
Corrective Actions
↓
Continual Improvement

For an AWS SaaS company, the minimum practical capability may include:

AWS multi-AZ architecture where appropriate
Automated backups
Tested database restoration
Infrastructure-as-Code
Protected production configuration
MFA and privileged-access controls
CloudTrail and security monitoring
Incident response procedures
Defined RTO/RPO
Critical supplier contacts
Emergency communication channel
Recovery runbook
Periodic tabletop exercise
Periodic backup restoration test

33. Final Audit Trail

Critical Service Identified
→ Business Impact Assessed
→ Dependencies Identified
→ Security Risks Assessed
→ RTO/RPO Defined
→ Continuity Strategy Established
→ Recovery Controls Implemented
→ Backup Protected
→ Incident Response Integrated
→ Recovery Procedures Documented
→ Roles Assigned
→ Communication Defined
→ Recovery Tested
→ Test Results Recorded
→ Gaps Identified
→ Corrective Actions Assigned
→ Improvements Implemented
→ Recovery Re-Tested
→ Management Review
→ Continuity Capability Improved

34. Final Principle

Business continuity is not simply about keeping systems running. It is about maintaining critical business services while protecting information security throughout disruption, response, recovery, and return to normal operations.

Prepare → Protect → Detect → Respond → Continue → Recover → Verify → Learn → Improve

The objective is:

Keep the business operating + Protect the information + Recover from a trusted state + Verify security + Learn from disruption.

ISO/IEC 27001