Business Continuity & Disaster Recovery Policy

Governs how Finaisse maintains availability and recovers from disruption. Subordinate to the Information Security Policy.

Policy owner	Security & Infrastructure Owner (Sekhar Prakash)
Applies to	The Finaisse platform and its data stores
Effective	2026-08-19 (v0.1 draft)
Review cadence	Annual + on major architecture change
SOC 2	A1.2, A1.3

1. Purpose

Ensure Finaisse can continue or promptly restore service, and recover customer data, in the event of infrastructure failure, data corruption, or a disaster affecting a region or provider.

2. Backups

• Databases: managed backups with point-in-time recovery. Staging uses Railway-managed Postgres. 🎯 Target (AWS) — Aurora/RDS with automated backups, PITR, and Multi-AZ (F-18).
• A documented and exercised database restore procedure exists (see Staging DB Restore Console).
• Object storage: versioning enabled; 🎯 Target (AWS) — cross-region replication and TLS-only bucket policy for Restricted data.
• All backups are encrypted using the same key-management infrastructure as production data.

3. Recovery objectives

🎯 Target — define and ratify RTO and RPO per service tier before AWS production go-live (owner: Security & Infrastructure Owner; Domain 13). Until ratified, recovery is best-effort against the documented restore procedure.

Objective	Status
RTO (per tier)	🎯 Target — to be defined
RPO (per tier)	🎯 Target — to be defined
DB point-in-time recovery window	Provided by managed DB; window to be confirmed for AWS

4. High availability (AWS — target state)

🎯 Target, at AWS production:

• Multi-AZ deployment for compute and database — no single-AZ dependency in the production traffic path.
• Managed auto-scaling compute (ECS Fargate).
• Redundant NAT/gateways across AZs (F-22 covers the current single-NAT gap).

Temporal workflow orchestration is a managed dependency; its availability characteristics are documented in the platform architecture.

5. Disaster recovery

• IaC-governed recovery: production infrastructure is defined in Terraform, enabling environment rebuild from version-controlled code rather than manual reconstruction.
• 🎯 Target — a documented DR plan with a defined recovery sequence (secrets → core services → workers → dependent pipelines) and a designated DR region (Mumbai primary; DR target to be selected).
• 🎯 Target — DR validated by annual restore/failover drill with measured RTO/RPO; first drill at AWS production readiness.

6. Dependencies

Continuity depends on third-party providers (Railway today; AWS, Cloudflare, GHCR, Temporal in production). Provider risk is assessed under the Vendor & Subprocessor Risk Policy.

7. Review

Reviewed annually and after any DR event or significant architecture change. Drill results are recorded and feed remediation items into the findings register.

Revision history

Version	Date	Author	Change
0.1	2026-08-19	Security & Infrastructure Owner	Initial draft