10.2 Disaster Recovery and Restoration Metrics
Key Takeaways
- The SSCP outline's restoration examples are Restore Time Objective (RTO), Restore Point Objectives (RPO), and Maximum Tolerable Downtime (MTD). Industry materials also say Recovery Time/Point Objective — same metrics.
- MTD is the business ceiling from the BIA. RTO must fit inside MTD (MTD is greater than or equal to RTO). Many models treat MTD as RTO plus Work Recovery Time.
- RPO is data-loss tolerance measured in time, not how fast the server boots. Nightly backups cannot meet a one-hour RPO.
- Payroll mismatch: a 48-hour warm-site rebuild cannot meet a 24-hour MTD, and a 24-hour backup interval cannot meet a one-hour punch-data RPO.
- Site type is chosen to meet those numbers: hot, warm, cold, cloud, reciprocal, or mobile — not the other way around.
Restoration planning: MTD, RTO, and RPO
The SSCP outline's restoration-planning examples are Restore Time Objective (RTO), Restore Point Objectives (RPO), and Maximum Tolerable Downtime (MTD). Vendor and NIST materials often say Recovery Time Objective and Recovery Point Objective. They are the same metrics. On an item that quotes the outline, Restore is the native wording. Do not invent a third definition.
These numbers are not decorations on a slide. They are how you choose a site, a backup interval, and an interim workaround — and how you later prove a test passed or failed.
| Metric | Question it answers | Unit | Who sets it |
|---|---|---|---|
| Maximum Tolerable Downtime (MTD) (also seen as Maximum Allowable Outage, MAO) | How long can this process be down before harm is unacceptable? | Time (hours or days) | Business, via the BIA |
| Restore / Recovery Time Objective (RTO) | How quickly must the system or process capability be restored? | Time | Derived from MTD; IT designs to meet it |
| Work Recovery Time (WRT) | After IT is up, how long do people need to catch up (posting, batch jobs, paper re-entry) before the process is truly whole? | Time | Operations plus the business owner |
| Restore / Recovery Point Objective (RPO) | How much data loss, measured in time, can we tolerate? | Time (15 minutes, 24 hours) | Business via the BIA; IT backup and replication design |
MTD is greater than or equal to RTO. The restore of the system must finish inside the downtime the business can survive. If MTD is 24 hours and RTO is 48 hours, the DRP is a fiction — the business has already failed before IT declares success. Many teaching models write MTD = RTO + WRT. Payroll software back online at hour 20 (RTO met on paper) still needs four hours of clerks posting time cards (WRT). If MTD is 24 hours, that design is on a knife edge. If MTD is 24 hours and RTO is also 24 hours with any WRT left, you missed MTD.
RPO is data-loss tolerance, not restore speed. An RPO of 24 hours means you can lose up to a day's data and the business will accept re-keying or going without it. It says nothing about how fast you bring the server back. You can have a short RTO and a long RPO (fail over a rebuilt app quickly, but the last good backup is last night). You can have a long RTO and a short RPO (a synchronous replica exists, but the only staff who can cut over are on a plane). Mixing those two is the classic payroll trap.
Clocks need a defined start. MTD and RTO are usually measured from the moment the process or system becomes unavailable, not from the moment someone finally declares a disaster. If detection takes six hours, those six hours already consumed MTD. RPO looks backward from the disruption to the last usable copy.
Payroll RTO versus RPO mismatch
Scenario. Payroll must run Friday 14:00 for contractors who load trucks Saturday. The BIA set MTD at 24 hours for the payroll process: missing Friday's run means Saturday no-loads and liquidated damages. Leadership also said we cannot re-enter more than one hour of punches, which is an RPO of 1 hour.
IT bought a warm site and nightly backups. Nightly backups give an RPO of up to 24 hours. Warm-site rebuild is quoted at 48 hours. Neither metric meets the BIA.
| Requirement | BIA | Current design | Gap |
|---|---|---|---|
| MTD | 24 hours | A ceiling, not a technology | — |
| RTO | Must leave room for WRT inside 24 hours | 48-hour warm rebuild | RTO exceeds MTD |
| RPO | 1 hour | Nightly backup (up to 24 hours of punches lost) | RPO too loose |
The SSCP does not fix this with a heroic weekend. You either change the design (more frequent replication or time-clock exports, a hot or cloud site, application-consistent backups every 15 minutes) or you go back to the business and re-negotiate the BIA with eyes open. Accepting a 48-hour RTO against a 24-hour MTD on a slide is how organizations fail audits and then fail Friday afternoon.
A second mismatch: a hot site with 5-minute database replication (excellent RPO) but no identity-provider replica, so nobody can log in. RTO is then gated by the identity dependency, not by the database. Restoration planning includes the dependencies the BIA listed: DNS, certificates, MFA, license servers, the time-clock vendor's cloud, and the people who know the break-glass procedure.
Do not promise both a one-hour RPO and a cheap weekly tape rotation. Do not promise an 8-hour RTO from a cold site that still has to order servers. The CAT item will hand you one expensive requirement and one cheap design and ask which statement is true. The true statement is that the design does not meet the BIA.
Interim or alternate processing strategies
While DRP restoration is underway, the organization still has an MTD clock. Interim or alternate processing is how work continues before the primary system is healthy. This is the outline's second 4.3 bullet, and it is mostly BCP work that buys time for DRP.
| Strategy | What it looks like | When it fits |
|---|---|---|
| Manual workaround | Paper shipping labels, spreadsheet payroll, phone orders | Short windows, trained staff, low transaction volume |
| Degraded or read-only mode | Catalog browsing without checkout; charting in view-only | Integrity of writes matters more than new transactions |
| Transfer of work | Sister warehouse, third-party payroll bureau, paper claims to a vendor | Reciprocal or contracted capacity already tested |
| Alternate site processing | Fail applications to hot, warm, or cloud | IT DRP is the interim strategy |
| Mobile or temporary facility | Trailer, hotel ballroom, generator and satellite | Building is gone; the process still must happen locally |
| Delayed processing / backlog | Accept the queue if MTD allows | Only if the BIA said that delay is tolerable |
Interim processing must be written, supplied, and trained. We will just use paper, with no forms, no extra laptops, no cellular, and no authorization path for paying contractors, is not a strategy. Stock the go-bag before the fire: check stock, signature stamps, VPN tokens, printer drivers, and a current vendor call tree that does not live only on the failed intranet.
Interim processing also has an integrity problem. Paper payroll posted for two days must be reconciled when PAYROLL-APP returns, or you pay people twice — or not at all. Build WRT into the RTO math for that reconciliation.
Alternate processing sites
Site type is how you meet RTO and RPO. Faster RTO and tighter RPO cost more. ISC2 does not publish a required hour count for hot versus warm. Learn the ordering and the failure modes, not a vendor brochure.
| Site type | What is waiting there | Typical RTO character (operations, not an ISC2 published number) | Typical RPO character | Main risk |
|---|---|---|---|---|
| Mirrored / redundant | Duplicate production, often active-active or near-sync | Minutes or less | Near-zero if synchronous | Cost; shared fate if both sides share a region or identity |
| Hot site | Hardware, software, current or near-current data | Hours or less | Minutes to hours, depending on replication | Cost; config drift; must be maintained and tested |
| Warm site | Hardware and software; data restored from backup after declaration | Hours to a couple of days | Whatever the backup interval is | Restore time plus last-backup loss |
| Cold site | Space, power, cooling — you ship or buy hardware | Days to weeks | Whatever backups you can get there | Misses short MTDs; hardware lead times |
| Cloud / disaster recovery as a service | Capacity on demand, images, replication, or backup restore into a cloud region | Minutes to days depending on design | Replication or backup interval | Account lockout, identity, egress, landing-zone size, same-region fate |
| Reciprocal / mutual aid | Another organization's spare capacity by contract | Highly variable | Highly variable | Both hit at once; compatibility; confidentiality of data on someone else's floor |
| Mobile site | Trailer or container with pre-loaded gear | Days, plus travel | Backup interval | Weather, permits, fuel, physical security of the trailer |
Hot means the environment is ready enough that you fail over rather than rebuild: systems installed, data already there or nearly so. Warm means you have iron and often software, but you still restore data and may still install or configure. Cold is an empty (or nearly empty) room with power and cooling. Do not call a second disk in the same chassis a hot site.
Reciprocal agreements fail exams and real events when they are handshake-only: no tested connectivity, no matching directory, no spare rack on the night the other hospital is also flooded. Cloud fails when the production identity provider is in the burned building, or when the only person with the break-glass token is unreachable, or when both production and the replica sit in one region. Hot sites fail when nobody has failed over in two years and the runbook still lists a decommissioned virtual local area network (VLAN). Mobile sites shine when the people cannot travel to a distant hot site — a community clinic after a tornado — but they still need fuel, guards, and a restore path.
Choose the site from the BIA, not from leftover budget. Payroll with MTD 24 hours, RTO 8 hours, and RPO 1 hour is not a cold site with weekly tapes. An electronic health record with an MTD of a few hours is not an untested reciprocal PC lab. An intranet wiki with MTD of a week can live on backup-to-cloud and a warm rebuild.
Decision sequence the exam wants
- The BIA names the process and MTD.
- RTO is set to leave room for WRT inside MTD.
- RPO is set from how much data the process can afford to lose.
- Site, replication, and backup design are chosen to meet those numbers — not the other way around.
- Interim processing covers the gap until the site is actually serving users.
- A test later measures real time against RTO, RPO, and MTD. A slide is not a measurement.
CAT traps in 10.2
- Treating RPO as how fast you restore.
- Designing RTO longer than MTD, or ignoring WRT so MTD is silently blown.
- Picking a cold site for a process whose MTD is measured in hours.
- Calling RAID or a second disk in the same chassis an alternate processing site.
- Assuming a reciprocal handshake or an untested cloud account meets an 8-hour electronic health record RTO.
- Starting the RTO clock at disaster declaration when the system has already been down for hours.
When a stem gives payroll numbers that cannot work together, say so and name the metric that fails. When it asks which site fits an 8-hour RTO and a 15-minute RPO, pick hot or a cloud design with replication — not weekly tapes and a dark room.
A Business Impact Analysis sets payroll Maximum Tolerable Downtime at 24 hours. The disaster recovery plan quotes a 48-hour rebuild at a warm site. What is true?
Contractors' time punches cannot be re-entered beyond one hour. Nightly backups are the only copy of the time-clock database. What is the problem?
An electronic health record has an 8-hour Restore Time Objective and a 15-minute Restore Point Objective after datacenter loss. Which alternate processing strategy actually fits?