Postmortem RPO/RTO Data-Recovery Analysis Prompt

You are a senior SRE and disaster-recovery specialist who analyzes incidents for
data loss and recovery performance against defined RPO and RTO objectives. You
measure against stated targets and evidence, and you critique the recovery SYSTEM —
backup design, restore tooling, runbooks — never the responder who ran the restore.

I will paste:
[OBJECTIVES] — the RPO and RTO targets for each affected data store/service.
[INCIDENT_TIMELINE] — corruption/loss onset, detection, restore start/end, verification.
[BACKUP_FACTS] — backup type/frequency, last good backup time, snapshot/replica state,
restore steps taken, and integrity/verification results.

Do the following:
1. Determine the actual data-loss window (last consistent recoverable point to loss
   event) and compare it to RPO for each store. State the RPO delta.
2. Determine actual recovery time (impact start to verified restore) and compare it
   to RTO. State the RTO delta and which phase (detect, decide, restore, verify)
   consumed the time.
3. Assess whether backups were present, current, and RESTORABLE — distinguish
   "backup existed" from "restore actually worked and was verified."
4. Identify any silent risk: unverified backups, untested restore paths, replication
   lag, missing point-in-time recovery.
5. Recommend the highest-leverage DR improvement to close the largest RPO or RTO gap.

Output format:
- Per-store RPO result (target, actual, delta) and RTO result (target, actual, delta,
  slowest phase)
- Backup restorability findings
- Silent-risk register
- Prioritized DR improvements

Guardrails: Stay blameless — missed objectives are DR-design and tooling gaps, not the
fault of whoever executed the restore under pressure. Mark any inferred timestamp,
data-loss estimate, or "last good backup" as [ESTIMATE] and state your assumption. Never
claim data was recoverable without evidence. A human owns data-loss disclosure and any
RPO/RTO objective change.

Why this prompt works

RPO and RTO are the two numbers a business actually promised itself about failure — how much data it can afford to lose and how long it can afford to be down — and yet incident postmortems routinely gloss over whether those promises held. The engineering root cause dominates the review while the recovery story gets compressed to “we restored from backup,” which quietly hides the two questions that matter most to the business: how much did we lose, and how long did it really take? This prompt forces both to be answered as measured deltas against the stated objectives, per data store, so the postmortem produces a defensible verdict rather than a reassuring hand-wave.

The most important distinction the prompt enforces is between a backup existing and a backup being restorable. This is where DR programs die: teams check the box that backups are running, the dashboard is green for years, and then during a real incident they discover the backup was encrypted with a rotated key, or the restore runbook references a tool that no longer exists, or the “backup” was a replica that faithfully replicated the corruption. By explicitly asking the model to separate “backup existed” from “restore actually worked and was verified,” the prompt surfaces the gap between theoretical and actual recoverability — which is precisely the gap that turns a minor incident into a catastrophic one.

Decomposing recovery time into detect, decide, restore, and verify phases is what makes the RTO analysis actionable. A team that blew its four-hour RTO needs to know whether the time went into not noticing the loss for ninety minutes, into an hour of paralyzed decision-making about whether to restore, into a slow restore, or into verification. Each phase points at a completely different fix — better monitoring, a clearer decision authority and runbook, faster restore tooling, or automated integrity checks. Lumping them into a single “recovery took too long” wastes the most valuable diagnostic signal the incident produced. The silent-risk register extends the same logic forward: unverified backups, untested restore paths, and replication lag are the latent failures that will cause the next incident, and naming them now is cheaper than discovering them live.

The guardrails here are unusually consequential because data loss is a legal and regulatory event, not just an operational one. The extent of loss can trigger breach-notification obligations and contractual penalties, so the prompt refuses to let inferred loss figures pass as fact — every estimated timestamp, data-loss window, or “last good backup” must be marked [ESTIMATE] with its assumption stated, and a human must verify the numbers before anything is disclosed. The single most dangerous output this analysis could produce is a false all-clear: a confident claim that data was recoverable or that a backup was good, made without verification evidence. Forbidding that claim is the guardrail that most directly protects the business, and the blameless framing ensures the engineer who executed a restore under enormous pressure is never made the story when the real lesson is a DR system that set them up to miss the target.