Picture a recovery exercise where the application comes back within its target time and the data reaches the agreed recovery point. The technical team reports a pass.
Then the business team asks which transactions actually completed before the disruption. Nobody can reconcile the answer yet. People can log in, but they can't confidently resume processing.
The test produced useful evidence. But evidence of what?
Define the activity that must resume
NIST's contingency-planning guidance gives the two standard targets. The Recovery Time Objective (RTO) is the maximum time a system resource can stay unavailable before the impact becomes unacceptable. The Recovery Point Objective (RPO) is the point in time before the outage to which data can be recovered: in effect, how much data loss the business can tolerate.1
Both are technical measures. Before the test, agree on what they mean for the business. Which activity must resume? What data must be present? Which reconciliations, access checks and dependent services are necessary? Who can accept the recovered condition?
A target expressed only as elapsed time leaves those questions open. Attach a business acceptance condition to it, so the test measures a usable outcome, not just a running system.
Run two clocks, not one
Have the business owner pick one representative transaction sequence. For it, keep a short acceptance record: its last confirmed state before the outage, its restored state, any missing or duplicate action, the reconciliation performed, and the person who accepted the result.
Then record two times: when technical restoration was achieved, and when the business acceptance condition was met. They may not be the same moment. Reporting both tells leadership how much recovery work remained after the system came back. Reporting only one gives them a reassuring timestamp and an incomplete picture.
NIST's Cybersecurity Framework 2.0 includes a recovery outcome for verifying the integrity of restored assets and confirming normal operating status. It supports examining the recovered condition. It doesn't prescribe a business acceptance test for every service.2
Report the boundary alongside the result
State what was tested, what passed and which dependencies or conditions were excluded. A bounded exercise can succeed without demonstrating recovery under every disruption scenario.
Start the next recovery discussion with the business activity, not the clock. The time target becomes useful once everyone knows what it's timing.
Related Reading
Read False Green in Disaster Recovery: Why the Finding Determines the Fix for what happens when a test that proved a restart gets reported as proof of recovery.
