Business Continuity and Disaster Recovery Plan (BCP/DR)
1. Purpose
This Business Continuity and Disaster Recovery (BCP/DR) Plan defines the policies, procedures, and controls established by RunWhen to ensure the continuity of business operations and the recovery of services in the event of a disruption.
This document should be read in conjunction with RunWhen’s broader security and resilience documentation, including:
2. Scope
This plan applies to:
- RunWhen’s SaaS platform hosted on Google Cloud Platform (GCP)
- RunWhen’s internal business operations and supporting systems
- Software development, support, and customer engagement functions
This plan does not extend to customer-managed environments where RunWhen software is deployed in a self-hosted configuration.
3. Service Delivery Models
RunWhen provides two deployment models:
3.1 SaaS Deployment (RunWhen-Hosted)
- Hosted on Google Cloud Platform (GCP)
- Runs on Google Kubernetes Engine (GKE)
- Deployed across multiple availability zones within a region
- GKE automatically rebalances workloads across availability zones
This architecture provides high availability within a region (multi-availability-zone resilience).
3.2 Self-Hosted Deployment (Customer-Managed)
- Customers deploy RunWhen software within their own infrastructure
- Customers are fully responsible for:
- Infrastructure availability
- Disaster recovery
- Multi-region resilience (if required)
Important Statement:
Customers requiring multi-region disaster recovery or jurisdiction-specific resilience controls are strongly encouraged to deploy the self-hosted version of RunWhen within their own controlled environments.
4. Business Continuity Objectives
RunWhen’s objectives are to:
- Maintain availability of SaaS services within defined recovery targets
- Ensure continuity of internal operations supporting customers
- Minimize impact of disruptions on customers and stakeholders
- Provide clear responsibility boundaries between RunWhen and customers
5. Business Impact Analysis (BIA)
5.1 Critical Functions
| Function | Description | Deployment Model |
|---|---|---|
| SaaS Platform Availability | Customer-facing service delivery | SaaS |
| Software Development | Code creation and maintenance | Internal |
| Customer Support | Incident response and support | Internal |
| Documentation Delivery | Access to product documentation | Internal |
6. Dependencies
RunWhen relies on a combination of cloud infrastructure providers and enterprise SaaS services.
6.1 Infrastructure Dependencies (SaaS)
| Provider | Service | Role |
|---|---|---|
| Google Cloud Platform | Compute, storage, networking | Primary hosting platform |
| Google Kubernetes Engine (GKE) | Container orchestration | Service runtime |
6.2 Operational Dependencies
6.2.1 Business Operations Data Continuity
RunWhen maintains critical business records within enterprise-grade SaaS platforms that provide built-in redundancy, high availability, and disaster recovery capabilities. This architecture minimizes reliance on single infrastructure components and supports continuity of operations during disruption scenarios.
6.2.2 System of Record by Function
| Function | System of Record | Deployment Model |
|---|---|---|
| Human Resources | Gusto, Remote.com | SaaS |
| Finance | Pilot, QuickBooks | SaaS |
| Legal | Google Workspace | SaaS |
| Customer Records | Google Workspace, Atlassian Confluence | SaaS |
6.2.3 Business Operations Continuity Strategy
RunWhen’s business continuity approach for operational data is based on:
- Reliance on enterprise SaaS providers with established BCP/DR programs
- Geographically distributed infrastructure operated by those providers
- Access-based recovery, rather than infrastructure-based restoration
- Minimal dependence on locally hosted or single-region systems
RunWhen does not maintain on-premises systems for these functions, reducing exposure to localized infrastructure failures.
6.2.4 Testing Relevance
BCP/DR testing exercises (including environment reprovisioning and internal disruption simulations) validate that:
- Internal teams can continue operating using SaaS systems during infrastructure disruptions
- Access to critical business records can be restored via standard authentication mechanisms
- No business-critical data is dependent on a single environment or deployment instance
Where applicable, disruption scenarios include loss of primary access methods (e.g., temporary unavailability of a SaaS provider), with fallback procedures defined for communication and coordination.
6.2.5 Vendor Dependency Considerations
RunWhen acknowledges that business continuity for these systems is partially dependent on third-party providers. Accordingly:
- RunWhen selects providers with strong security and resilience practices
- Vendor-level BCP/DR capabilities are inherited as part of the overall control environment
- Internal procedures focus on maintaining access and operational continuity rather than data reconstruction
6.2.6 Busienss Operations Responsibility Model
RunWhen is responsible for:
- Maintaining access to SaaS platforms
- Managing user access controls and authentication
- Defining internal procedures for continuity of operations
SaaS providers are responsible for:
- Infrastructure availability and redundancy
- Data durability and backup
- Disaster recovery execution within their platforms
This approach complements RunWhen’s broader BCP/DR strategy, which emphasizes recoverability through redeployment for platform components and access continuity for business operations.
7. Risk Scenarios
RunWhen considers the following disruption scenarios:
| Scenario | Impact | Mitigation |
|---|---|---|
| Availability zone failure | Partial service degradation | Multi-AZ GKE deployment |
| Regional outage (GCP) | SaaS service disruption | Customer option for self-hosted deployment |
| SaaS dependency outage | Internal disruption | Alternate communication and recovery procedures |
| Loss of developer workstation | Local productivity impact | Rapid reprovisioning |
8. Recovery Objectives
8.1 SaaS Platform
| Metric | Target |
|---|---|
| Recovery Time Objective (RTO) | < 4 hours (AZ-level disruption) |
| Recovery Point Objective (RPO) | Near-zero (persistent storage replication) |
8.2 Internal Operations
| Function | RTO | RPO |
|---|---|---|
| Source code access | < 4 hours | Near-zero |
| Internal communications | < 8 hours | Minimal |
| Customer support response | < 24 hours | N/A |
9. Disaster Recovery Strategy
9.1 SaaS Platform
- Multi-availability-zone deployment within a single GCP region
- Automated workload distribution and failover via GKE
- Persistent storage replication across zones
Limitation:
- The SaaS platform is not designed for automatic multi-region failover
Customer Guidance:
Customers requiring multi-region or cross-jurisdiction disaster recovery must deploy RunWhen in a self-hosted configuration.
9.2 Internal Systems
- Cloud-based SaaS tools with built-in redundancy
- Distributed workforce enabling geographic resilience
- Reprovisionable development environments
10. Data Protection and Backup
- Source code is version-controlled and replicated via GitHub
- Documentation and internal data are stored in Google Workspace
- SaaS platform data is replicated within GCP infrastructure
RunWhen does not store or process customer production data outside the scope defined in its Data Security and Privacy policy.
11. Incident Response
RunWhen follows a structured incident response process:
- Detection and identification of disruption
- Internal escalation to responsible teams
- Activation of recovery procedures
- Communication to stakeholders (as appropriate)
- Post-incident review and remediation
Further details are defined in RunWhen’s Security Incident Response documentation.
12. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| CTO | Overall BCP/DR ownership |
| Engineering | Service recovery and platform resilience |
| Support | Customer communication and issue management |
| Leadership | Decision-making during major incidents |
13. Testing and Validation
RunWhen conducts periodic testing of its continuity and recovery capabilities.
13.1 Test Types
| Test Type | Frequency | Description |
|---|---|---|
| Infrastructure resilience testing | Ongoing | Kubernetes rescheduling and failover validation |
| Chaos testing (non-production) | Daily | Simulated Kubernetes disruptions |
| Recovery exercises | Quarterly | System and workflow recovery validation |
13.2 Example (Redacted)
- Scenario: Simulated Kubernetes node failure
- Outcome: Workloads rescheduled automatically within minutes
- Improvement: Enhanced monitoring alerts for node degradation
14. Plan Maintenance
- Reviewed annually or upon significant architectural changes
- Updated following major incidents or test findings
- Version-controlled and access-restricted
15. Customer Responsibilities
For self-hosted deployments:
- Customers are responsible for:
- Infrastructure availability
- Backup and recovery
- Multi-region resilience (if required)
For SaaS deployments:
- RunWhen provides multi-availability-zone resilience within a region
- Customers are responsible for assessing whether this meets their regulatory or operational requirements
16. Summary
RunWhen’s BCP/DR strategy is designed to:
- Provide high availability for SaaS customers through multi-availability-zone architecture
- Enable customers with advanced resilience requirements to deploy self-hosted solutions
- Maintain continuity of internal operations through reliance on enterprise-grade SaaS providers
- Continuously validate resilience through testing and operational practices
Contact & Documentation
RunWhen’s Security and Compliance Team maintains responsibility for business continuity readiness and documentation. Additional details, tabletop reports, or internal playbooks may be shared under NDA for enterprise customer reviews.
For more information, contact: security-and-compliance@runwhen.com