CCSP: Business Continuity and Disaster Recovery Planning (RTO, RPO, RSL)

Business continuity (BC) keeps the organization's critical business functions running during and after a disruption; disaster recovery (DR) restores the IT systems and data those functions depend on. BC is about people, processes, facilities, suppliers and workarounds. DR is the technical subset: failover, restores, replication, rebuilding environments. The two are planned together, which is why the CCSP outline treats them as one BC/DR strategy, but each answers a different question.

A simple test: if the business carries on without the system, the arrangement belongs in the continuity plan; if the system itself comes back, it belongs in the recovery plan.

The service model shifts the balance. In IaaS the customer designs and runs most of its own DR (replicas, backups, recovery environments) on the provider's infrastructure. In SaaS the provider restores the application; the customer usually has no systems to recover, so its own plan is mostly continuity: an alternate way to perform the function (for example, routing customer requests through a shared mailbox and a spreadsheet while a ticketing SaaS is down), a copy of its own data held outside the service where possible, and contractual assurance that the provider's DR meets the customer's needs. Responsibility for planning never transfers to the provider, even when execution of the technical recovery does.

The business impact analysis that identifies critical functions and derives their objectives, the classic recovery-site patterns (backup and restore through hot site) and the test types from checklist to full interruption are taught in the CCSP lesson on secure cloud design principles (sub-domain 1.4). This lesson takes the infrastructure-planning view of sub-domain 3.5: turning those objectives into a recovery design, then building, testing and maintaining the plan.

The recovery time objective (RTO) is how quickly a service must be working again after a disruption; the recovery point objective (RPO) is how much recent data can be lost, measured backward from the moment of disruption; the recovery service level (RSL) is the percentage of normal production capacity the service must deliver while running in recovery mode. All three come from the business (through the business impact analysis), not from what the technology happens to achieve, and every recovery design is judged against all three.

The levers are separate, and confusing them is the most common planning error. Copying data more often improves the achievable RPO but does nothing for RTO: a backup taken every few minutes that takes most of a day to restore still means most of a day of downtime. Restoring faster improves RTO but does nothing for RPO. So when a design changes, ask which of the three requirements that change can actually affect.

RSL sizes the standby. If the impact analysis says a contact centre can get through a disruption while answering seven in ten of its normal calls, that 70% figure is the RSL, and the recovery environment must be able to carry 70% of production load, no less. A recovery that is fast and loses little data but cannot carry the required share of load has still failed a business requirement, because RSL is judged on its own, not traded off against the other two. RSL is also why a cheaper, smaller standby can be the right answer: there is no need to pay for 100% of production capacity in the recovery site when the business has accepted less.

Two related terms from the impact analysis frame these objectives: the maximum tolerable downtime (or maximum tolerable period of disruption) is the outer limit beyond which the business suffers unacceptable harm, and the RTO is set inside it so there is margin for declaring the disaster and verifying recovery.

Where does the RTO clock start? The plan must say. Most plans, and the arithmetic in this lesson, start it at the onset of the disruption, so the time spent noticing the problem and deciding to invoke counts against the objective. A plan that starts the clock at the declaration instead must keep the time to decide short and bounded elsewhere, or the real outage will run past the maximum tolerable downtime while the measured RTO still looks fine.

Compare the worst-case achieved recovery time and data loss with each objective separately, identify which objective fails and why, and then fund only the change that removes that cause. This gap analysis is how a cloud security professional advises the business on BC/DR spending, and it works in four steps:

1. Worst-case data loss. With periodic backups, the worst case is the full interval (a failure just before the next backup). With asynchronous replication, it is the replication lag at its worst moment, not its average: if lag spikes during month-end reporting to well beyond the RPO, the design misses the RPO during that window, however small the lag is the rest of the month.
2. Worst-case recovery time. Add up everything on the critical path: deciding to invoke, provisioning or promoting the standby, restoring data, starting dependent services, cutting over DNS and verifying. A tested restore time is the honest figure; an estimate is not.
3. Compare each against its objective. It is common for one objective to pass and the other to fail. Replica lag is lost data (an RPO matter); promotion and rebuild time is lost time (an RTO matter).
4. Choose the least-cost change that closes every gap. If both fail, a fix that addresses only one is not a fix. If neither fails, the right advice is that no change is needed, however much a more elaborate design is wanted.

The finding points at the lever:

Active-active with synchronous replication meets almost any RTO and RPO, but it is the most expensive option and adds write latency. Choosing it when a warm standby already meets both objectives is over-engineering, not good security.

Synchronous replication confirms each write only after the recovery copy has also stored it, which gives an RPO of effectively zero but makes every write wait for the round trip; asynchronous replication confirms the write locally and ships it afterwards, which adds no write latency but leaves the copy trailing by seconds to minutes. Distance is the deciding factor: the further apart the sites, the longer each synchronous write waits.

Over inter-regional or intercontinental distances the round trip is paid on every write, which is why zero-RPO synchronous replication is a metro-distance technique and not a cross-region one. The usual design for a system that must lose nothing in a local failure but also needs protection against losing a whole region splits the two: synchronous replication between nearby data centers (zones) in the primary region, plus asynchronous replication to the distant region. The residual RPO of the asynchronous leg is a real data-loss exposure for the regional scenario, so it is documented and formally accepted by the business rather than hidden.

Why replication is not a backup

Replication copies every change to the recovery site, including corruption, deletion and ransomware encryption, so it protects against the loss of a site but not against bad data; only point-in-time copies retained over time let you go back to before the damage. When ransomware encrypts the primary, replication faithfully delivers the encrypted versions to the recovery site; when a bug silently corrupts records, every replica holds the same corruption. A faster or synchronous replica only copies the damage sooner.

A complete strategy therefore combines both:

• Replication or standby for site and region failures, where speed (RTO) and freshness (RPO) matter.
• Versioned, point-in-time backups, retained long enough and protected against change, for logical failures: corruption, accidental or malicious deletion, ransomware.

Late detection changes how the RPO is met. When corruption is noticed hours after it began, the recovery point you need is just before the corruption started, not the latest copy. Periodic snapshots can only take you back to the last snapshot before that moment, losing up to a full interval of valid work. To meet a tight RPO in that scenario you need continuous log backups that allow a point-in-time restore to any moment within the retention window. In practice the point-in-time restore goes to a side copy, so valid transactions written after the corruption began can be reconciled back rather than discarded.

A delayed (lagged) replica is not a substitute for point-in-time backups. A replica that applies changes on a deliberate delay holds one moving point in the past: it helps only when damage is noticed before the delay runs out, and it offers no choice of recovery points. Corruption that goes unnoticed for longer than the delay reaches the replica like any other change. Size the protection against logical damage from two facts the business supplies: how long damage can stay undetected, and how far back it must be possible to restore. Versioned backups or log-based point-in-time restore retained over that whole range meet both; a delayed replica can be a useful extra for fast recovery from quickly noticed mistakes, but not the only protection.

Recovery copies must sit outside the blast radius of the production management plane: in a separate account or subscription, administered with different credentials, and locked against deletion or change for their retention period. An attacker who obtains production administrator credentials can otherwise delete the production resources and every copy stored alongside them in one session, which is exactly what ransomware operators try to do before they encrypt.

Separation works only if production keeps no path to delete. Any right that production identities hold over the recovery copies re-joins the two blast radii: whoever compromises production inherits it. Housekeeping such as expiring old copies should be handled by retention rules set on the protected side, so no production identity needs that access at all.

Write-once (WORM) retention is offered by cloud object storage and backup services in different forms. One common pattern, used for example by object-lock features, has two modes; other services express the same idea as an unlocked policy that can still be changed and a locked policy that cannot.

Governance mode trusts whoever holds the bypass permission, however few people that is. If the threat model includes theft of the most privileged credentials, only retention that no identity can lift holds.

Retention must outlast attacker dwell time. Dwell time is how long intruders stay undetected. If the retention window is shorter than that, every copy old enough to be clean has expired by the time anyone looks for one. Set retention longer than the realistic detection time, and layer it with account separation where possible: separation limits who can reach the copies, locked retention limits what anyone who reaches them can do.

A service is recovered only when everything it depends on is recovered too: encryption keys, identity, DNS, certificates and the network paths between them. Recovery breaks on whichever of these was left out of the inventory: an application restored on time still cannot serve traffic if the TLS certificate at the recovery site has expired, or if the secrets store holding its database credentials exists only in the primary location. The plan has to list every dependency, recover it to the recovery site and include it in the test.

Encryption keys

Encrypted backups are useless without their keys. A backup copied to another location is only recoverable if the keys that decrypt it can also be used there; a copy whose only key is lost along with the failed site cannot be restored at all. The plan must make keys available at the recovery site under equivalent controls: the key material replicated into HSM-backed key protection in the recovery location and governed by the same policy as production. Recovery is not a reason to relax key protection; a recovery site with weaker key controls becomes the easiest way to the data.

Key recovery also depends on people and quorum material. HSM key backups are commonly restorable only with an M-of-N quorum of custodians and their cards or tokens (split knowledge and dual control). The plan must ensure that, after the primary site is lost, enough custodians and enough quorum material can still reach the recovery site; key backups that arrive intact are useless if the quorum needed to unlock them was lost with the primary. The quorum itself stays: the control survives the disaster, it is not traded away for it.

Dependency mapping and recovery order

Build the plan from a dependency map: which components each service needs and in what order they must come back. The achievable recovery time is set by the critical path, the longest chain of steps that must happen one after another, not by the largest single task and not by the sum of every task.

Worked example: a file-processing service has an RTO of 8 hours. The recovery network takes 1 hour to stand up; storage restore needs the network and takes 3 hours; the processing servers need the storage and take 2 hours; switching traffic takes 0.5 hours. Reissuing certificates (1.5 hours) needs nothing else and runs alongside from the start. The dependent chain is 1 + 3 + 2 + 0.5 = 6.5 hours, inside the 8-hour RTO; the certificates do not lengthen it because they finish long before traffic is switched. Had the runbook listed the certificates as another step in the same queue, the plan would have looked 1.5 hours longer than it needs to be. Independent steps belong in parallel; only true dependencies belong in sequence.

A regional disaster sends many tenants to the same neighbouring region at once, so on-demand capacity in the recovery location is not guaranteed; capacity the RSL depends on should be reserved in advance. Relying on on-demand capacity means competing for it with every other customer of the failed region at the same moment.

Quotas, scaling rules and region choice all describe what you are allowed or configured to ask for; only a reservation describes what will be there. The proportionate answer is to reserve what the RSL requires and no more, relying on on-demand capacity only for growth beyond that. Reserving more than the RSL buys capacity the business has not asked for; reserving less leaves the RSL to chance.

Active-active designs

Running active-active across sites gives a near-zero RTO, but it meets the RSL only if the surviving sites can absorb the failed site's load. The test is arithmetic, and it is judged against the failure the requirement names:

• Two sites, each normally running at 35% of its own capacity: if one fails, the survivor takes both loads and runs at 70% of its capacity, so a 100% RSL is met.
• Two sites, each carrying half of peak but each able to scale only to 70% of peak: losing one leaves 70% of peak available, which meets a 70% RSL but not a 100% one.
• Four sites, each at 72% of its own capacity: losing one spreads its 72% across the three survivors (24% each), so they run at 96% and a 100% RSL for a single-site loss is met, with little headroom. Losing two is a different failure and needs its own requirement.

A cap on scaling is a cap on the RSL, whatever the per-site load looks like in normal operation.

A BC/DR plan is created in a fixed sequence: define the scope, gather requirements and context, analyze, assess risk, design the solution, implement it, test it, and report and revise. Each step feeds the next, so skipping ahead produces a design that answers the wrong question.

1. Define scope. Which systems, locations, business functions and disruption scenarios the plan covers. Newly migrated workloads start here, before any architecture work.
2. Gather requirements and context. RTO, RPO and RSL for each function (from the impact analysis), regulatory and contractual obligations, and the relevant parts of the provider's own BC/DR arrangements.
3. Analyze. Turn requirements into what must be recovered: current environment, dependencies, data flows, the shared-responsibility split for each service model.
4. Assess risk. The threats that could disrupt the in-scope systems (regional outage, provider failure, ransomware, insider error, capacity contention) and the risks the recovery design itself introduces. This comes before design, so the design addresses the risks that matter.
5. Design. The recovery architecture and procedures that meet the requirements against those risks.
6. Implement. Build the recovery environment, replication, backups, key copies and reservations; write the runbooks; assign roles and train people.
7. Test. Prove the implemented plan works and measure it against the objectives (see the next section).
8. Report and revise. Document findings, fix the plan and the environment, and feed the changes into the next cycle.

Invocation: who declares a disaster, and when

The plan must contain pre-agreed criteria for declaring a disaster and name the authority empowered to declare it, so that during an outage the decision is made against the criteria, not argued about. Failing over has real costs (possible data loss with asynchronous replication, a later failback), so without criteria an incident team tends to keep waiting for the primary to return until the choice is made for it. With criteria and an authority in place, the decision can be made promptly and defended afterwards.

The criteria must account for how long failover itself takes. With the RTO clock starting at the disruption (see the RTO section), failover time counts against the objective, so the latest point at which a declaration still meets the RTO is the RTO minus the failover duration. For a service with a 10-hour RTO whose failover takes 2.5 hours, the declaration deadline is 7.5 hours after the disruption began; every minute of waiting past that point is a minute of breach. Good criteria therefore name a trigger well inside that deadline (an outage of defined scope lasting a defined time), so the declaration does not depend on information that may never arrive.

Apply the criterion that matches the actual situation. Invocation criteria usually cover more than a total outage: a capacity threshold (often the RSL, the least capacity the business has said it can operate on) as well as a time threshold for a full loss of service. Each trigger is evaluated on its own terms: a capacity trigger is met when service falls below the agreed threshold, a time trigger when an outage of the stated scope has lasted the stated time. Matching the event to the wrong criterion leads either to an unnecessary failover or to a late one. Declaring early is not free: failover brings its own data loss, risk and failback work, which is exactly why the criteria were agreed in advance.

Failback

Failback, the return to the primary site, is half of the recovery plan and must be designed and tested like failover. While running in the recovery location, that location is production and accumulates new transactions, so failback has the same RPO problem as failover in reverse. The usual approach is to replicate the recovery site's data back to the primary while service continues, then cut over once the two are in sync, which keeps every transaction written during the disaster and limits the switch to a short window. Any method that moves users before the disaster-period data has reached the primary loses that data or leaves two diverging copies to reconcile.

A BC/DR test must measure the achieved recovery time, data loss and capacity and report each against the RTO, RPO and RSL; a test proves only what it measured. A timing result says nothing about data loss, and neither says anything about capacity. The test types themselves (checklist, walk-through, simulation, parallel and full interruption) are covered in the sub-domain 1.4 lesson; here the question is what the evidence must contain.

An objective that was not exercised is reported as untested, not as passed. A test driven at a small fraction of the required load can prove the RTO and RPO but not the RSL; the right conclusion is "RSL untested", and the fix is to drive the required load next time, not to infer that capacity is fine.

Capacity evidence also depends on when the test ran. A test on an ordinary day shows only that resources were available on that day; it cannot show what is available during a regional event, when many tenants fail over at the same time. A test under normal conditions therefore does not close the contention risk; only reserved capacity, or a contractual guarantee of it, does.

The test must use the recovery mechanisms the plan actually relies on. An RPO result only means something if the recovered data came from the normal backup schedule or replication stream. Taking an extra backup just before a simulated failure measures that special backup, not the design; the design's worst-case data loss is still the full scheduled interval (or the worst replication lag), and that is what must be compared with the RPO. The same applies to timing: a restore from a freshly staged copy, or with steps done ahead of time, does not show what an unplanned event would take.

Tests also need to cover the parts that plans most often skip: supporting services (identity, DNS, keys, certificates), the people and quorum material needed to restore keys, invocation, and failback. Failback belongs in the test programme: a return that has never been rehearsed can lose the data written during the disaster or cause a second long outage just when the business thinks the event is over.

Report, revise and verify

Every test ends with a report of what slowed or broke recovery (gaps in runbooks, missing network or access configuration at the recovery site, people who did not know their role), revision of both the plan and the environment, and verification of each fix in the next test. A findings list that is filed but never retested leaves the organization exactly as exposed as before.

A missed objective is a finding to fix, not a target to move. RTO, RPO and RSL are set by the business owner from the impact analysis, so a test that overruns one is reported to that owner, the causes (for example slow manual runbook steps or missing access at the recovery site) are fixed, and the fix is confirmed by a retest. Rewriting the objective to match what the test achieved, or closing the finding without changing anything, leaves the business exposed to downtime it already said it cannot accept. Only the business owner can change an objective, and only by revisiting the impact analysis.

Keeping the plan current: retest after significant change

A BC/DR plan must be updated and retested whenever a significant change affects what it recovers or where it recovers to, not only on its annual calendar date. The last successful test proves the plan worked for the environment that existed then.

Changes that should trigger an update and a retest include:

• Architecture changes: re-platforming an application onto containers or replacing self-hosted components with managed services changes the backup, replication and restore procedures, so a test against the old design no longer counts.
• Provider or location changes: a new recovery region or a new provider means the plan must be updated and recovery proven in the new location before the organization depends on it.
• Service-model changes: moving from IaaS to PaaS or SaaS shifts who performs recovery and what the customer must verify contractually.
• Changes to business requirements: a tighter RTO or RPO, a higher RSL, new regulatory obligations.
• Organizational changes: new key custodians, changed roles in the invocation chain, new suppliers.

Waiting for the next scheduled test after such a change leaves a period in which the organization believes it can recover but has no evidence that it can.

A customer verifies that a provider can meet its recovery requirements through contractual recovery commitments and independent evidence of tested recovery; an availability percentage in an SLA is not an RTO or RPO. A 99.9% monthly availability commitment with service credits says how much downtime is tolerated over a month on average and what refund follows if it is exceeded. It says nothing about how long a single major outage may last, how much data could be lost, or whether recovery has ever been tested, and a service credit does not restore lost orders.

To establish whether a provider meets an RTO and RPO, the cloud security professional:

• asks for contractual commitments on recovery time and data loss for the relevant service (or confirms that none exist and plans around that), together with the provider's backup, replication and location arrangements;
• reviews independent assurance: a SOC 2 Type II report with the Availability category of the Trust Services Criteria in scope shows whether resilience and recovery controls operated effectively over a period, not only that they were designed (Type I); ISO 22301 certification shows the provider runs a business continuity management system that has been independently audited against that standard's requirements (ISO 22301 is the certifiable requirements standard; companions such as ISO 22313 give guidance and are not certified against). Other ISO standards do not substitute for it: ISO/IEC 27017 is guidance on cloud security controls and ISO/IEC 27036 covers information security in supplier relationships; neither is a continuity management standard;
• asks for evidence of the provider's own DR testing and its results, and the right to such information under the contract;
• covers what the provider does not: exports or backups of the customer's own data held outside the service, and a continuity procedure for the business function if the service is unavailable for longer than the business can tolerate.

Reviewing provider reports in general (SOC report types, scope, bridge letters) is covered in sub-domain 1.5; for BC/DR the point is to compare the provider's evidence with the customer's own objectives.