Backup and Restore RTO/RPO Analysis Prompt

This prompt is designed for infrastructure engineers, SREs, and cloud architects who need to perform a structured gap analysis on a documented backup and disaster recovery strategy. The core job-to-be-done is validating whether the current backup configuration—including frequency, retention, replication, and restore testing—can actually meet the stated Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO). Use this when you have a DR plan, a backup tool configuration export, or a set of infrastructure specifications and you need a prioritized list of risks and remediation steps before a production launch, a compliance audit, or a scheduled DR test. The prompt reasons strictly from the text you provide; it does not connect to live monitoring systems.

To use this effectively, you must supply two categories of input: the target objectives and the current state. The target objectives should include the maximum tolerable data loss in time (RPO) and the maximum tolerable downtime (RTO) for each critical system or data store. The current state should describe the backup schedule, backup type (full, incremental, snapshot), retention period, cross-region or cross-account copy status, restore testing cadence, and encryption key management. The prompt will cross-reference these inputs to identify gaps such as a backup frequency that exceeds the RPO window, a restore process that cannot meet the RTO due to data transfer time, or a lack of tested restores that invalidates the entire strategy. It will also flag operational risks like missing encryption key access in a secondary region.

Do not use this prompt when the backup configuration is unknown or when you need real-time validation against live infrastructure metrics. It is a reasoning tool for documented configurations, not a monitoring agent. For high-risk regulated environments, always require a human to review the generated gap analysis and verify the findings against the actual infrastructure before taking any action. The output is a decision-support artifact, not a substitute for a full DR exercise. After running the analysis, the recommended next step is to feed the identified gaps into your remediation backlog and schedule a restore test for the highest-risk items.

The prompt below is designed to be copied directly into your AI harness. It forces the model to act as an infrastructure resilience auditor, comparing your actual backup configuration against your recovery objectives. The output is a structured gap analysis with severity ratings, evidence requirements, and specific remediation steps. Every finding must be tied to a stated objective or an industry-accepted resilience principle.

textCopy
You are an infrastructure resilience auditor. Your task is to perform a structured gap analysis comparing the provided backup and restore configuration against the stated Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets.

## INPUT
[BACKUP_CONFIGURATION_DETAILS]

## TARGETS
- Recovery Time Objective (RTO): [RTO_TARGET]
- Recovery Point Objective (RPO): [RPO_TARGET]

## CONSTRAINTS
- Classify each finding as CRITICAL, HIGH, MEDIUM, or LOW severity.
- A CRITICAL finding means the current configuration cannot meet the stated RTO or RPO under a plausible failure scenario.
- A HIGH finding means the configuration can likely meet the target but has a single point of failure or an untested assumption.
- Every finding must cite specific evidence from the [BACKUP_CONFIGURATION_DETAILS] or state explicitly that evidence is missing.
- Do not invent configuration details. If information is missing to assess a risk, flag it as a finding with the evidence listed as "MISSING".
- Include specific checks for: untested restores, encryption key availability, cross-region copy status, and backup immutability.

## OUTPUT_SCHEMA
Return a valid JSON object with the following structure:
{
  "summary": "A one-paragraph executive summary of the overall gap status.",
  "findings": [
    {
      "id": "F-001",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "category": "RTO|RPO|Restore Testing|Key Management|Replication|Immutability|Other",
      "description": "Clear description of the gap.",
      "evidence": "Quote from INPUT or 'MISSING'.",
      "impact": "How this gap affects RTO or RPO achievement.",
      "remediation": "Specific, actionable step to close the gap."
    }
  ],
  "overall_assessment": "MEETS_TARGETS|AT_RISK|CANNOT_MEET_TARGETS",
  "requires_human_review": true
}

To adapt this prompt, replace the square-bracket placeholders with your actual data. [BACKUP_CONFIGURATION_DETAILS] should contain a structured dump of your backup schedules, retention policies, replication settings, restore test history, and key management practices. [RTO_TARGET] and [RPO_TARGET] should be your stated objectives in hours or minutes. If your configuration details are long, place them in a separate [CONTEXT] block and reference them in the prompt. The output schema is strict JSON, which makes it suitable for direct ingestion into a compliance dashboard or an automated remediation tracker.

Before deploying this prompt into a production workflow, wire the output through a JSON schema validator. A common failure mode is the model omitting the evidence field or using free-text instead of the required severity enum. Add a retry step that feeds the validation error back to the model with a correction instruction. For high-risk environments, always set requires_human_review to true in your post-processing logic and route CRITICAL findings to an on-call channel. Never treat this prompt's output as a substitute for an actual restore test.

This prompt is designed for a single-turn completion within a structured analysis pipeline. Assemble the final prompt by injecting the infrastructure inventory, stated RTO/RPO targets, backup configuration details, and restore test history into the [BACKUP_CONFIGURATION], [RTO_RPO_TARGETS], and [RESTORE_TEST_EVIDENCE] placeholders. The model expects a clear, delimited input block and will return a JSON gap analysis. Do not use this prompt in a multi-turn chat session without resetting the context window; prior turns can leak stale configuration data or override the current analysis constraints.

Call the LLM with the assembled prompt and parse the JSON output immediately. Validate the response against a strict schema that requires: a top-level gap_analysis array, each element containing finding_id, severity (one of critical, high, medium, low), category (one of frequency, retention, restore_testing, cross_region, encryption_key_access), gap_description, current_state, target_state, and recommendation. If the output fails schema validation, retry exactly once by appending the validation error message to the original prompt as a new [VALIDATION_ERROR] block. If the retry also fails, log the failure and route the raw output to a human operator queue—do not loop indefinitely.

Every analysis result must be logged with an input configuration hash (SHA-256 of the normalized input parameters) for auditability. This allows operators to trace which specific backup configuration produced which gap findings over time. Store the full prompt, model response, validation status, and timestamp in a structured log. For high-compliance environments where backup gaps could represent regulatory findings, route all outputs—even schema-valid ones—to a human reviewer queue before publishing to a compliance dashboard. The reviewer should confirm that critical findings are not false positives caused by stale input data or misinterpreted backup schedules.

Model choice matters for this workflow. Use a model with strong JSON-following capability and a context window large enough to hold the full backup configuration plus the output schema. If the backup configuration is extensive, consider pre-processing it into a summarized canonical form before injection. Do not use this prompt with models that have known difficulty with structured output or that tend to hallucinate specific technical findings. For production deployments, pair this prompt with a retrieval step that pulls the latest backup configuration from your infrastructure-as-code repository or cloud API rather than relying on manually pasted configuration data.