LEARN. PRACTICE. GROW.Define recovery from the business process
In a fictional service, daily closing depends on position files, validation, approval and delivery to a recipient. A VM’s RTO alone does not describe when that process works again. BIA identifies impact over time, dependencies, priorities and the minimum acceptable operating level. Also define the recoverable data point and who can accept loss or reconciliation. In the worksheet, 90 minutes is a fictional contractual target measured from disruption, not a value required by a standard. Write down the clock’s start and end so teams do not measure different phases and report incompatible conclusions.
Trace dependencies under degraded conditions
Application instances run in A and B, but both use a self-managed database and gateway in A. Losing A leaves the B instance without the complete transaction. In a second design, B has data and compute, but recovery credentials, the image repository and DNS administration depend on A. A failover while A is healthy does not establish the ability to start B when A disappears. Review from a business operation and distinguish dependencies of an already running service from dependencies for reconstruction and traffic changes. AWS location guidance supports this analysis; no AWS deployment or induced failure occurred in this block.
Check time, data point and backlog separately
The fictional plan adds 10 minutes for detection, 15 for decision, 45 for restoration and 25 for validation: 95, five above the 90-minute target. These phases are sequential as stated; change the sum only when parallelism is demonstrated and dependencies permit it. For disruption at 10:00, the last recoverable commit is 09:42: 18 minutes, above the case’s 10-minute RPO, with no additional validated logs. Finally, processing 140 items per minute while 100 arrive leaves a net 40 for a 1200-item backlog: 30 minutes under constant rates. None of these calculations measures performance or guarantees recovery; each answers a different question.
Plan the exercise and acceptance decision
A tabletop discussion can reveal missing contacts, circular dependencies and ambiguous criteria. It does not establish that backups restore, permissions work or the application supports load. Define an authorized exercise with scope, suitable data, stop conditions, owners and expected evidence. Validation should include the data point and a representative functional operation as well as technical process status. APS should be able to execute the steps using its own identities. If the exercise retains a dependency declared unavailable by the scenario, record the exclusion and limit the conclusion. Acceptance should distinguish observations from estimates and decisions still outstanding.
Include supplier, capacity and return to normal service
The recovery supplier promises four hours, but capacity is shared and several customers occupy the same risk area. Clarify reserved capacity, priority, access, communications and support before treating the promise as demonstrated capability. Budget for exercises, parallel operation, reconciliation and on-call staff. Recovering in B can also create new data requiring reconciliation before returning to A. If the primary site cannot be reused, define who decides whether to stay or migrate. Summary: green infrastructure status is partial evidence; closure requires accepted service, data, access and operational responsibilities. Connect this lesson with portability, contracts and the authorization matrix already studied.
FICTIONAL WORKSHEET: recovery acceptance
Target from disruption: 90 min.
Estimated sequential phases: detection 10 + decision 15 + restore 45 + validation 25.
Disruption: 10:00 UTC. Last recoverable commit: 09:42 UTC. RPO: 10 min.
Backlog: 1200 items. Arrivals: 100/min. Total processing: 140/min. Constant rates, no retries.
Deliverable: calculation | assumptions | target met? | evidence required from an actual exercise.
Add identity, images, DNS, external dependencies and decision owner.The plan totals 95 minutes against a 90-minute target; the data point is 18 minutes old against a 10-minute RPO.
Common pitfalls
Counting components without paths; adding unavailable capacity; treating tabletop as a technical trial; confusing restoration with service acceptance.
Related topics: Continuity and impact analysis · Change, suppliers and operations
Connect dependencies, timing, data and capacity with service-recovery criteria.
Reference: Contingency Planning Guide for Federal Information Systems · CCSP examination outline effective 2026-08-01; January2026 V2 PDF