Security, Infrastructure & OperationsBackup & Continuity
Data Recovery Procedure
Restoration steps for Postgres and S3; DR scenarios and communication with affected customers
Recovery Scenarios and Procedures
1. Platform Outage
Actions:
- Monitoring provider status — the Heroku status page (Shared Model) or AWS Health Dashboard (Dedicated Model)
- Notification of affected customers via email
- Status updates issued until resolution
- Upon recovery: verification of application and data integrity
2. Corruption / Loss of Relational Data (Postgres / RDS)
Restoration tools:
| Model | Tool | Mechanism |
|---|---|---|
| Shared (SaaS) | Heroku Postgres (CLI / Dashboard) | Restoration from PITR or from a daily backup (30-day retention) |
| Enterprise (Dedicated) | AWS RDS (AWS Console / CLI) | Restoration from PITR or from an automatic daily snapshot (30-day retention) |
Steps:
- Identifying the desired restoration point (PITR or daily backup/snapshot)
- Initiating the restoration through the managed tool (always via HTTPS channel)
- Verifying data integrity after restoration
- Notifying affected customers
3. Loss / Corruption of Documents (AWS S3)
Option A — Restoration from S3 versioning:
- Recovery of the previous version of the affected document directly from S3
- Applicable for accidental deletion or overwrite
Option B — Restoration from CRR Replica:
- In the event of a regional AWS outage or massive data loss
- The cross-region replica is a passive backup in a separate region
- Not a live failover target — requires manual recovery procedures
4. Bad Release
Rollback to the previous release via the managed release tools:
- Shared Model — Heroku Releases: one-click rollback to any previous release (CLI or Dashboard)
- Dedicated Model — AWS ECS redeploy to the previous version (task definition)
5. Credential Compromise
Immediate procedure:
- Rotation of all affected secrets — Heroku config vars (Shared) or AWS Secrets Manager (Dedicated)
- Rotation of AWS keys (generating a new IAM set, disabling compromised keys)
- Rotation of Postmark / AWS SES tokens and the electronic signature provider
- Review of activity logs for unauthorized access
- Notification of customers if their data is affected
RTO — Recovery Time Objective
| Scenario | Estimated RTO |
|---|---|
| Application platform outage (Heroku / dedicated AWS) | 4 hours |
| Database restoration (Heroku Postgres / AWS RDS) | 4 hours |
| Document recovery from S3 replica | 8 hours |
Communication with Customers
- Affected customers are notified via email as soon as an event is identified
- Status updates are issued throughout the incident until resolution
- Upon resolution: final confirmation sent to affected customers
Post-Incident
For any event with production impact:
- Written review of the incident — causes, impact, actions taken
- Corrective actions identified and tracked through to implementation
- Procedure updated if there are lessons to be learned
External Customer Archive (Optional)
Customers can configure an automatic daily export of signed documents to an external storage destination of their choice (cloud storage, qualified e-archive, etc.). This external archive provides:
- An additional recovery path outside the platform
- Data portability at any time
- Full customer control over their own backup copy