Incident Response Plan Architecture Review Prompt

This prompt is designed for security architects and platform engineers who need to evaluate whether a system design can support effective incident response. Use it during architecture review gates, before a new service enters production, or when an existing system undergoes a significant redesign. The prompt forces the model to reason across the full incident lifecycle: detection, containment, eradication, recovery, and post-incident learning. It assumes you have a written system design document, architecture diagram, or detailed component description as input. The output is a structured gap analysis that identifies architectural blockers, missing telemetry, insufficient isolation boundaries, and forensic blind spots. This is not a generic security questionnaire. It is a design-level review that catches threats invisible in code review alone.

The ideal input is a system design document that describes component boundaries, data flows, authentication mechanisms, deployment topology, logging and monitoring strategy, and any existing security controls. If your design document is sparse, the prompt will still produce useful output, but the gaps it identifies will be broader and less actionable. For best results, include details about how the system detects anomalies, how components are isolated, what forensic evidence is preserved, and how operators would execute containment and recovery procedures. The prompt works with both greenfield designs and brownfield modernization efforts, but it is most effective when the design is stable enough to review but not yet locked into implementation.

Do not use this prompt as a substitute for a formal threat model or a penetration test. It does not replace runtime security validation, red-team exercises, or compliance audits. It is a design-time review tool that surfaces architectural risks before they become production incidents. Avoid using it on systems that are already in production without also feeding in current incident history and postmortem findings, otherwise the model will lack the ground truth needed to assess real-world gaps. If your organization has specific incident response SLAs, regulatory requirements, or internal runbook standards, include those as constraints in the prompt to get a calibrated assessment rather than a generic one.

After running the prompt, expect a structured report that maps architectural components to incident response capabilities. Each gap should include a severity rating, a description of the missing capability, and a recommended remediation. Use this output as input to your architecture decision process, not as a final verdict. The next step is to review the findings with the engineering team, prioritize the gaps based on your risk appetite, and update the design document before implementation begins. For high-risk systems, pair this prompt with the Threat Modeling Architecture Prompt Template and the Defense-in-Depth Architecture Review Prompt to get overlapping coverage across security domains.

This prompt template is designed to be copied directly into your AI tool of choice. Replace the square-bracket placeholders with your specific system design document, incident response requirements, and output format preferences. The prompt is structured to produce a gap analysis that identifies architectural blockers to detection, containment, eradication, and recovery capabilities. It is self-contained and can be used independently of the rest of this playbook, though the evaluation harness and failure mode sections will help you validate the output before acting on it.

codeCopy
You are a senior security architect reviewing a system design for incident response readiness. Your task is to produce a structured gap analysis that identifies architectural blockers to effective detection, containment, eradication, and recovery.

## SYSTEM DESIGN
[SYSTEM_DESIGN]

## INCIDENT RESPONSE REQUIREMENTS
[IR_REQUIREMENTS]

## REVIEW SCOPE
- Detection capabilities: logging, monitoring, alerting, anomaly detection
- Containment capabilities: isolation mechanisms, segmentation, kill switches, rate limiting
- Eradication capabilities: root cause removal, patch deployment, configuration rollback
- Recovery capabilities: backup restoration, state reconstruction, service resumption
- Forensic readiness: audit trails, evidence preservation, chain of custody support

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT FORMAT
Produce a JSON object with the following structure:
{
  "summary": "One-paragraph executive summary of overall IR readiness",
  "gaps": [
    {
      "id": "GAP-001",
      "category": "detection|containment|eradication|recovery|forensics",
      "severity": "critical|high|medium|low",
      "description": "What is missing or insufficient",
      "architectural_blocker": "Why this cannot be fixed with operational changes alone",
      "recommendation": "Specific architectural change needed",
      "effort_estimate": "small|medium|large|xlarge"
    }
  ],
  "existing_controls": [
    {
      "control": "Description of existing capability",
      "category": "detection|containment|eradication|recovery|forensics",
      "effectiveness": "adequate|partial|unproven"
    }
  ],
  "critical_path_gaps": ["GAP-IDs that block IR execution regardless of other controls"],
  "compliance_notes": ["Relevant regulatory or standard gaps identified"]
}

## INSTRUCTIONS
1. Analyze the system design against each IR capability category.
2. Identify gaps that require architectural changes, not just process or operational fixes.
3. For each gap, explain why it is an architectural blocker.
4. Prioritize gaps by severity: critical gaps make incident response impossible; high gaps significantly impair it.
5. Flag any single points of failure in the IR chain.
6. If the system design lacks sufficient detail to assess a category, note it as an unknown risk rather than assuming adequacy.
7. Do not invent controls that are not described in the design document.

To adapt this prompt, replace [SYSTEM_DESIGN] with your architecture document, diagram descriptions, or design notes. The [IR_REQUIREMENTS] placeholder should contain your organization's incident response policy, compliance requirements, or specific threat scenarios you are designing against. Use [CONSTRAINTS] to specify any limitations such as budget, technology stack restrictions, or regulatory boundaries that shape what recommendations are feasible. If your review scope differs from the five categories listed, adjust them before running the prompt. The output schema is designed to be machine-readable for integration into security review pipelines, but you can modify it to match your internal reporting format. For high-risk systems, always have a human security architect review the AI-generated gap analysis before accepting it as a final assessment.

This prompt is designed to operate as a structured analysis step inside a larger security architecture review pipeline, not as a standalone chatbot interaction. The harness should treat the model output as a draft gap analysis that requires deterministic validation, forensic readiness checks, and human sign-off before it becomes part of an incident response (IR) readiness report. The primary integration points are: a document ingestion stage that extracts the system design and IR plan sections, the prompt execution stage, a post-processing validator, and a review queue for a security architect.

Input assembly should pull three distinct document sections into the prompt's placeholders: [SYSTEM_DESIGN] (architecture diagrams, service topology, data flow descriptions), [IR_PLAN] (detection, containment, eradication, and recovery procedures), and [COMPLIANCE_STANDARDS] (e.g., NIST SP 800-61, ISO 27035, SOC 2 CC7). If the IR plan is missing a required phase, the prompt will flag it, but the harness should also run a pre-flight completeness check that verifies each IR phase heading exists in the source document before invoking the model. This prevents the model from hallucinating the presence of a containment section that was never written. For RAG-based systems, retrieve the relevant architecture and IR plan chunks using metadata filters that separate design docs from procedural docs, and inject them into the prompt with clear [SOURCE: ...] demarcation.

Output validation is the most critical harness component because this prompt operates in a high-risk domain where missed gaps can extend incident duration. After the model returns its gap analysis, run a structured schema validator that checks for: (1) every IR phase (detection, containment, eradication, recovery, post-incident) has at least one finding or an explicit NO_GAP marker, (2) each finding includes a non-empty architectural_blocker field, (3) severity ratings are constrained to the enum [CRITICAL, HIGH, MEDIUM, LOW], and (4) no finding references a system component not present in the source [SYSTEM_DESIGN]. If validation fails, retry with the error message appended as a [CORRECTION_REQUEST] in a follow-up prompt, up to a maximum of two retries. After two failures, escalate to the human review queue with the raw output and validation errors attached.

Forensic readiness and isolation checks should be implemented as deterministic post-processing rules, not left to the model alone. After the model produces its gap analysis, the harness should cross-reference each finding against a checklist: Does the system design include immutable audit logging for the affected component? Are there documented quarantine mechanisms (network segmentation, credential revocation, deployment freeze) that can isolate the component during containment? If the model's output claims a gap exists but the system design already documents these controls, flag the finding for human review as a potential false positive. This dual-layer approach—model analysis plus deterministic verification—reduces the risk of both missed gaps and incorrect gap claims.

Model choice and latency considerations favor models with strong reasoning capabilities and long context windows, such as Claude 3.5 Sonnet or GPT-4o, because the prompt requires cross-referencing two potentially large documents and producing structured analysis. For teams running this review on every architecture change, consider caching the IR plan analysis and only re-running the prompt when the system design or IR plan sections change. Human approval is mandatory for all CRITICAL and HIGH severity findings before they enter any remediation tracker. The review queue should present the finding, the source evidence from both documents, and the model's reasoning in a side-by-side view that lets the security architect confirm, modify, or dismiss each gap. Never auto-commit gap analysis findings to a compliance record or ticketing system without human review.