Lesson 5 of 5
Reporting and operational sign-off
9 min
Listen to this lesson
The output of a recovery test is a decision: can the business rely on this recovery capability, and if not, what must change? That decision needs a report that a process owner can read in ten minutes and an auditor can trace in an hour. Technical logs are attachments, not the report.
Reading the results honestly
Report what was measured, not what was hoped. If the database took over in eight minutes but users could work only after five hours because two interfaces needed manual re-pointing, the achieved RTO is five hours. If the test ran with fewer users or less data than production, say so and judge whether the result still holds. A partial pass with clear remediation is far more useful than a green report that nobody believes.
| Verdict | Meaning | Sign-off |
|---|---|---|
| Met | All targets achieved; no open high-impact findings | Process owners and operations sign off; next test scheduled |
| Partially met | Targets achieved with workarounds, or minor targets missed | Conditional sign-off with dated remediation and retest |
| Not met | A critical target missed or a critical process failed | No sign-off; residual risk formally accepted or design changed |
Verdicts and what each one allows.
Write the report for two audiences. The process owners need to know whether their processes can be recovered in time and what still worries the technical team. Auditors need to trace each claim to evidence: which test case, which timestamp, which log. Number the findings, reference them in the evidence, and keep the report with the other operational sign-offs so the next test can start by checking what was promised last time.
Keeping the capability current
Recovery capability decays. New interfaces, new hosts, a release upgrade or a new company code such as Wave 2's company code 1910 in Monterrey can all break a procedure that worked last year. Schedule recovery tests on a regular cycle that the contract supports (SAP's R&R includes at most one customer-requested DR failover test per calendar year in the optional service, with further tests billable) and trigger extra checks after major changes. Keep the DR procedures for Contoso's own responsibilities, such as interface partner contacts and re-pointing steps, under change control like any other runbook.
- Did a major change affect hosts, interfaces or the release?Yes → review DR procedures and run a targeted check · No → continue the regular cycle
- Is the last full DR test older than the agreed cycle?Yes → schedule the next test with SAP ECS · No → track open remediation
- Are all findings from the last test closed and retested?Yes → capability current · No → report the residual risk to Grace
What would you do?
Contoso's DR test brought CMP up at the DR site in 2 hours, but the EDI interface to Great Lakes Fleet Services needed 7 hours of manual work. The DR RTO target is 12 hours, and the full process tests passed at hour 9. How should the report present the result?
- A recovery report leads with a verdict, then targets versus achieved values, timeline, findings and evidence.
- Report the time until the business could work, not the time until the database came up.
- Sign-off is shared: Basis, test lead, process owners and the program or operations lead.
- Retest on a regular cycle and after major changes; keep customer-side DR procedures under change control.
Check your understanding · not graded
Lesson check
1. The database took over in 8 minutes, but users could work after 5 hours. What is the achieved RTO?
2. What can be signed off for a DR design that has never been tested?
3. Which event should trigger a review of DR procedures before the next scheduled test?
4. What does a 'partially met' verdict allow?