# Disaster Recovery & Business Continuity Policy

**Last Updated:** March 18, 2026  
**Version:** 1.0  
**Classification:** Public

This Disaster Recovery (DR) and Business Continuity (BC) Policy defines the frameworks, architectures, and procedures implemented by AccountScope ("we", "our", or "us") to guarantee application availability, database integrity, and continuity of service in the event of an infrastructure outage or natural disaster.

---

## 1. Recovery Objectives (RPO and RTO)

AccountScope defines the following maximum targets for service restoration and data loss protection:

* **Recovery Point Objective (RPO):** < 24 hours. Represents the maximum period of data that could be lost from transaction history updates in the event of a catastrophic primary system failure.
* **Recovery Time Objective (RTO):** < 4 hours. Represents the target time to restore fully operational application interfaces and API services following a major service disruption.

---

## 2. Infrastructure Redundancy & High Availability

Our application is designed to tolerate local node failures without service disruption:

* **Multi-AZ Deployment:** PostgreSQL databases and secure file storage systems are hosted across multiple Availability Zones (AZs) in the AWS London region.
* **Hot Standby Databases:** Primary database instances replicate transactions synchronously to secondary hot standbys. Failover to standby nodes is automated and completed in seconds.
* **Stateless Serverless Compute:** The frontend application and PDF parsers are stateless serverless microservices that dynamically distribute load across multiple servers. If a node fails, requests are automatically routed to healthy nodes.

---

## 3. Database Backup & Vaulting Architecture

To protect against data corruption or infrastructure disasters, we maintain a rolling backup vault:

* **Backup Schedule:** Full database backups are captured automatically once every 24 hours. Transaction write-ahead logs (WAL) are archived continuously.
* **Encryption:** All backups are encrypted using AES-256 encryption with keys managed in AWS KMS.
* **Retention:** Rolling backups are retained for 90 days. Backups older than 90 days are automatically purged from storage vaults.
* **Geographical Isolation:** Backups are stored in separate physical data centers from the primary instances to guard against broad regional disasters.

---

## 4. Disaster Recovery Failover Procedures

In the event of a catastrophic failure of primary hosting infrastructure:

4.1. **Alerting:** Infrastructure alerts automatically page our on-call engineering team via pager systems.
4.2. **Assessment:** The engineering lead evaluates the outage. If primary servers are unrecoverable, the DR failover procedure is initiated.
4.3. **Database Promotion:** The hot standby database instance is promoted to primary.
4.4. **Routing Update:** DNS and CDN routing paths are updated to point to the newly promoted active instances.
4.5. **Verification:** Automatic integration testing checks run to verify core operations, including user logins, document uploads, and PDF report downloads.

---

## 5. Testing & Verification Protocol

5.1. **Quarterly Drills:** The engineering team conducts simulated disaster recovery tests and failover drills quarterly.
5.2. **Audit Trails:** Failover drill logs, recovery times, and data consistency checks are logged and reviewed by the Security Officer.
5.3. **Continuous Improvement:** DR protocols are updated based on test results to optimize RTO and ensure zero data corruption.