BC/DR Readiness — Backup & Disaster Recovery
BC/DR Readiness scores a client's actual backup posture rather than taking "we have backups" on trust, and the same score feeds the ISO 27001 A.8.13 compliance control automatically.
Connecting a backup source
AWS Backup and Azure Backup are picked up automatically from a client's existing AWS/Azure Connections — nothing extra to configure. Third-party vendors are added under BC/DR → Add Connection:
| Vendor | Credential fields |
|---|---|
| Veeam | host, username, password |
| Datto | api_key, secret_key |
| Acronis | datacenter, username, password |
| Redstor | account, api_key |
| Rubrik | host, api_token |
| Cohesity | host, username, password |
| Cove (N-able) | username, password |
Test (POST /api/v1/bcdr/connections/{id}/test) calls the vendor's real API and records the result. Zerto, Commvault, Backupify and Druva can also be registered as a connection today, but have no working collector yet — they're accepted so the connection exists ready to go, but show "collector coming soon" rather than real data until one is built.
The score
Six checks, each worth points toward a 0–100 total:
| Check | Points |
|---|---|
| A backup source is connected | 20 |
| Backups have run in the last 30 days | 20 |
| Backup failure rate is below 10% | 20 |
| Backups are encrypted at rest | 15 |
| An offsite or immutable copy exists | 10 |
| A restore test was logged within the last 90 days and passed | 15 |
Risk level: LOW ≥ 80 · MEDIUM ≥ 60 · HIGH ≥ 40 · CRITICAL below 40.
Logging a restore test
The last check is the only one that can't be measured from a vendor API — someone has to actually attempt a restore and log it: POST /api/v1/bcdr/restore-test with whether it succeeded, and optionally the RTO (minutes) and RPO (hours) achieved. This is worth doing even outside a formal DR exercise — 15 of the 100 points, and the only "not measured" state that someone in your own team controls the fix for.
Known limitation: job-run success isn't measured for every vendor
Veeam, Acronis, Rubrik and AWS/Azure Backup all report genuine per-job success and failure counts. Datto, Cohesity and Cove currently report whether they're connected and current (recent activity, registered devices/jobs) but not a verified success/failure count for those recent jobs — their real per-job-run history APIs haven't been identified and verified against a live account yet, so rather than guess a plausible-looking field name, those two checks are left at their honest zero ("unmeasured"), not a fabricated "0 failures". A backup source in this state can genuinely be failing silently and this score would not yet catch it — worth knowing before treating a Datto/Cohesity/Cove-only client's BCDR score as the full picture.
API
GET /api/v1/bcdr/status, GET /api/v1/bcdr/jobs, GET /api/v1/bcdr/connections, POST /api/v1/bcdr/connect, DELETE /api/v1/bcdr/connections/{id}, POST /api/v1/bcdr/connections/{id}/test, POST /api/v1/bcdr/restore-test.
Open in the interactive docs