Disaster Recovery Plan and DR Testing
What disaster recovery documentation CTO2B provides for your environment, what you need to provide, and how to request a DRP or DR test.
This page explains what disaster recovery (DR) and business continuity (BCP) documentation you can get from CTO2B for your own environment, what you need to provide, and how to request a Disaster Recovery Plan (DRP) or a DR test.
What documentation is available?
Two documents, both specific to your environment:
| Document | What it is | When you get it |
|---|---|---|
| Disaster Recovery Plan | A plan for rebuilding your production infrastructure and restoring its data, built from your actual deployed environment | On request |
| DR test report | A record of a recovery drill that was actually executed, with what was tested, the measured timeline and the outcome | After a drill has been run |
For questions about CTO2B's own organisation-level continuity programme, rather than your environment, see Commitment to Security & Operational Resilience.
Why is there no standard, off-the-shelf DRP?
Because a useful plan has to describe your environment, not a generic one. The recovery steps depend on which databases, storage, secrets and workloads you run, on which cloud, and how each one is backed up. A generic document would state recovery capabilities that nobody has checked against your setup, and once you forward it to your own customers or a regulator, those statements become commitments. A customer-specific plan avoids that.
What does a customer-specific DRP cover?
At a high level:
- Scope and responsibilities — which production components the plan covers, and who does what. CTO2B executes the infrastructure rebuild and data restore; you decide whether to declare a disaster, validate your application data after a restore, and own communication to your customers and regulators.
- Recovery sequence — an ordered set of stages for each component, from recovery sources through data stores, platform and workloads. Each stage says when it can be skipped, because a disaster usually needs only some of the stages, and rebuilding a component that survived can cause a second outage.
- Disaster scenarios — which stages each type of event requires, and a damage-assessment checklist for deciding where to start.
- Recovery objectives in three separate columns — what the configuration permits (configured), what an executed test has demonstrated (validated), and the objective proposed for your approval (proposed). Where no test has been run yet, the validated column says so explicitly rather than borrowing the configured value.
- Known limitations and recommended improvements — including decisions that are yours to make.
The plan covers the infrastructure layer. Business continuity as a whole — process ownership, decision authority, customer communication and formal sign-off — stays with you. If a regulator asks your organisation to confirm an approved and tested DRP, the CTO2B plan is the technical annex you attach to your own confirmation; CTO2B does not sign that confirmation on your behalf.
A plan is versioned by the date it was delivered to you. A revision that changes a recovery objective or a limitation is sent to you for re-approval, and earlier versions are kept, so you can show what the plan said on a given date.
What you need to provide
- Your business recovery targets — the RTO and RPO your business, customers or regulator require. We propose objectives based on your environment, but the targets are yours.
- Your critical systems — which applications and data matter most, and which environment is genuinely in production use.
- Contacts and roles — who can declare a disaster, approve a recovery point and validate restored data.
- Regulatory requirements — the regulation or framework the plan must support, and any required format or test frequency.
- Your own BCP, if you have one, so the two documents do not contradict each other.
How to request a DRP or a DR test
- Raise a request in your dedicated Slack channel, or through the Support Portal, saying whether you need a DRP, a DR test, or both.
- Include the information from the list above. For a test, also send your test plan if you have one: the scenario, the in-scope system, the success criteria and your target RTO and RPO.
- For a test, agree the details with us before it runs — the exact system, the scenario (for example, whether corruption is found immediately or later, which decides the restore point used), and whether you want to observe live or receive the results afterwards.
Tests are non-disruptive by default: a database restore, for example, goes into a separate, isolated instance rather than replacing production. A live failover is run only if you explicitly ask for one. After the drill you receive the DR test report, and its results populate the validated column of your DRP.
Related articles
- RDS Backup Retention — how database backups are retained and how to change retention
- RDS Restore from Snapshot — restoring a database yourself
- SLA Policy — support response and availability commitments
- Commitment to Security & Operational Resilience — CTO2B's organisation-level security and continuity answers
- Digital Operational Resilience Act (DORA) — how the platform supports DORA
Updated 26 days ago