1. Targets
| Measure | Standard tier | Notes |
|---|---|---|
| RPO (recovery point objective — maximum tolerated data loss) | 1 hour | RDS automated backups with point-in-time restore satisfy RPO ≤ 5 minutes in practice; we commit to 1 hour to retain margin against regional replication lag. |
| RTO (recovery time objective — time to restore service) | 4 hours | Infrastructure-as-code redeploy of the application stack into a second AZ, plus DB restore from snapshot. Measured from a go/no-go declaration to customer-verifiable service up. |
| Backup frequency | Continuous (RDS PITR) + daily full snapshot | Snapshots retained 30 days by default; extended retention on request. |
| DR test cadence | At least annually | Plus any time the primary region is changed or the recovery runbook is materially rewritten. |
2. Architecture
- Primary region. AWS
eu-west-2(London) by default. EU (eu-central-1) and US (us-east-1) available as alternatives at contract time. Per-tenant region selection is documented at /legal/data-residency. - Compute. Application stack deployed via infrastructure-as-code (Terraform / AWS CDK) across at least two Availability Zones within the primary region. Stateless instances behind a load-balancer — a single-AZ failure is handled transparently by the load-balancer and auto-scaling group without declaring a DR event.
- Database. Amazon RDS (Postgres) in multi-AZ mode — synchronous replication to a standby in a second AZ. Automated backups with point-in-time restore enabled; manual snapshots before any schema migration.
- Object storage. Amazon S3 with cross-AZ durability (11 nines by AWS design). Upload buckets versioned; deletion is soft-delete with a 30-day retention before permanent removal.
- Secrets. AWS SSM Parameter Store / Secrets Manager with per-environment KMS keys.
3. Failure scenarios
| Scenario | Response | Expected time-to-service |
|---|---|---|
| Single-instance failure | Auto-scaling group replaces the instance; load-balancer drains traffic in the interim. | < 5 minutes, zero customer-visible data loss. |
| Single-AZ failure | RDS multi-AZ failover to the standby in the surviving AZ; compute auto-scaling recreates capacity in the surviving AZ. | 5–15 minutes, zero data loss. |
| Full primary-region failure | Declare DR event, redeploy application stack into the pre-selected secondary region from IaC, restore DB from the most recent cross-region snapshot. Update DNS to point at the secondary region. | Within RTO 4 hours, data loss up to RPO 1 hour. |
| Ransomware / destructive compromise | Isolate affected resources, restore from an immutable snapshot prior to the earliest indicator of compromise; rotate secrets; rebuild affected compute from IaC. | Variable — target inside RTO; data loss bounded by snapshot cadence. |
| Accidental data deletion (tenant-level) | Point-in-time restore of the affected tenant's records from RDS PITR + S3 versioned restore for object storage. | Same day; data loss bounded by restore-point selection. |
4. Backup integrity and testing
- Backups are encrypted at rest with KMS keys distinct from the production encryption keys.
- Restore-from-backup is tested at least quarterly against a non-production environment; a full end-to-end DR drill (new region, IaC redeploy, DB restore, smoke-test) is conducted at least annually.
- Backup restore times are recorded and trend-tracked; if a restore exceeds its target, the runbook is revised.
5. Communication during a DR event
- Customers are notified within 1 hour of a go/no-go declaration.
- Status updates posted at least every 60 minutes during recovery; more often on request.
- A post-mortem is issued within 5 business days, covering timeline, root cause, customer impact, RPO / RTO adherence, and remediation actions.
6. Customer responsibilities
- Maintain up-to-date customer-contact details for incident communication.
- Maintain a plan for consuming any delayed outputs (valuation runs, reports) during a DR window.
- Test customer-side integrations against the secondary region if region-specific DNS or IP allow-lists are in use.
7. Review
This BCDR statement is reviewed annually, after every DR drill, and whenever a material architectural change is made. Material changes are notified to customer contacts in advance.
8. Contact
Questions: security@markst.com. Incident reporting: incidents@markst.com.