Defense-in-Depth Architecture Review Prompt

This prompt is designed for security architects and platform engineers who need to evaluate whether a system design applies security controls at every layer—network, host, application, and data. The primary job-to-be-done is identifying single points of security failure where the compromise of one layer exposes the entire system. Use it during architecture review, threat modeling, or pre-deployment security gate checks when you have a concrete system design document, architecture diagram, or detailed component description as input. The prompt assumes you are working in the design phase, before implementation commits to a specific control topology, and that you need a structured control-gap matrix rather than a narrative opinion.

The ideal input is a complete or near-complete design artifact that describes component interactions, data flows, trust boundaries, and existing security controls. This could be a formal architecture decision record, a cloud infrastructure diagram with accompanying notes, a service mesh configuration proposal, or a detailed system specification. The prompt works best when the input explicitly names technologies, protocols, and control mechanisms—for example, 'TLS 1.3 between service A and service B' rather than 'encrypted communication.' Vague inputs produce vague gap analyses. If your design document lacks this level of detail, run a design completeness review first or supplement the input with a component inventory before invoking this prompt.

Do not use this prompt for runtime incident response, code-level vulnerability scanning, or penetration test planning. It is not designed to analyze live systems, evaluate exploitability, or recommend specific vendor products. It also should not replace a formal threat model using STRIDE or attack trees, though it can serve as a precursor that identifies areas requiring deeper threat modeling. The output is a control-gap matrix—a structured artifact that maps layers to controls and flags gaps—not a risk rating or compliance report. If you need a risk register with likelihood and impact scores, pair this prompt with the Architecture Risk Assessment Prompt Template in the same content group.

This prompt template is designed to be dropped directly into your AI orchestration layer. It instructs the model to act as a security architect and systematically evaluate a system design for layered controls across network, host, application, and data tiers. The output is a structured control-gap matrix that identifies single points of security failure and recommends compensating controls.

textCopy
You are a principal security architect conducting a defense-in-depth review of the following system design. Your task is to evaluate whether security controls are layered across four tiers: Network, Host, Application, and Data. For each tier, identify existing controls, missing controls, and any single points of security failure where one compromised control exposes the entire tier.

## INPUT
System Design Document:
[SYSTEM_DESIGN]

Data Classification:
[DATA_CLASSIFICATION]

Compliance Requirements (if any):
[COMPLIANCE_REQUIREMENTS]

Threat Model Summary (if available):
[THREAT_MODEL]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "review_summary": "string (executive summary of findings)",
  "control_matrix": [
    {
      "tier": "Network | Host | Application | Data",
      "existing_controls": ["string"],
      "missing_controls": ["string"],
      "single_points_of_failure": [
        {
          "control": "string (the control that, if bypassed, exposes the tier)",
          "failure_scenario": "string (what happens when it fails)",
          "blast_radius": "string (scope of impact)",
          "severity": "Critical | High | Medium | Low"
        }
      ],
      "compensating_control_recommendations": ["string"]
    }
  ],
  "cross_tier_analysis": {
    "defense_gaps": ["string (gaps that span multiple tiers)"],
    "overlapping_controls": ["string (controls that redundantly protect the same asset)"],
    "assumption_violations": ["string (implicit trust assumptions that break layered defense)"]
  },
  "prioritized_remediation_plan": [
    {
      "priority": 1,
      "finding": "string",
      "rationale": "string",
      "effort_estimate": "Low | Medium | High"
    }
  ]
}

## CONSTRAINTS
- Do not invent controls that are not described in the system design. Mark missing controls explicitly.
- If the system design lacks detail for a tier, note it as "Insufficient information to assess" rather than assuming controls exist.
- For each single point of failure, explain why it is a single point and what compensating controls could reduce the risk.
- Flag any control that relies on a shared mechanism (e.g., a single identity provider, a single firewall rule set) as a potential single point of failure.
- If compliance requirements are provided, map missing controls to specific compliance gaps.
- Do not recommend specific vendor products. Recommend control types and patterns.

## RISK_LEVEL
[RISK_LEVEL]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with your system's specific details. The [SYSTEM_DESCRIPTION] should include architecture diagrams, component descriptions, data flow narratives, or infrastructure-as-code excerpts. The [DATA_CLASSIFICATION] field should specify the sensitivity levels of data flowing through the system (e.g., PII, PCI, PHI, internal, public). If you have a formal threat model, include it in [THREAT_MODEL] to ground the review in known threats. The [RISK_LEVEL] field should be set to Critical, High, Medium, or Low to calibrate the depth and urgency of the analysis. The [EXAMPLES] field can contain one or two example control-gap entries to demonstrate the expected format and level of detail. Before deploying this prompt in a production review pipeline, validate the output against the schema using a JSON validator, and ensure a human security architect reviews the findings before they become the basis for remediation work. For regulated environments, always require human sign-off on the final control-gap matrix.

This prompt is designed to be a gate in a formal architecture review process, not a standalone chat interaction. The implementation harness must enforce structured input, validate the output schema, and route findings to the correct downstream systems. The prompt expects a system design document as [DESIGN_DOC] and a list of expected controls as [CONTROL_CATALOG]. The harness is responsible for assembling these inputs, invoking the model, and ensuring the resulting control-gap matrix is machine-readable before it enters any ticketing or risk register system.

Start by building a pre-processing step that validates the [DESIGN_DOC] input. Reject submissions that are under 500 words, lack a clear system boundary description, or contain no mention of data flow. For the [CONTROL_CATALOG], maintain a canonical list of expected controls per tier (network, host, application, data) in a JSON file that is versioned alongside the prompt. At invocation time, inject this catalog into the prompt's [CONTROL_CATALOG] placeholder. Use a model with strong JSON mode and low temperature (0.1–0.2) to minimize structural drift. After the model returns the output, run a strict schema validator against the expected control_gap_matrix structure: it must be a JSON array of objects, each containing tier, control_id, control_name, status (one of present, missing, partial), evidence_from_design, gap_description, and compensating_controls. Any output that fails this validation should trigger a single retry with the validation error message appended to the prompt as a correction instruction. If the retry also fails, log the raw output and escalate to a human reviewer via the architecture review queue.

For production integration, wrap the prompt invocation in a function that can be called from your architecture governance platform (e.g., a CI/CD pipeline for design docs, a Confluence plugin, or a custom review portal). Log every invocation with a unique review_id, the prompt version, model version, input hashes, and the validated output. This audit trail is critical for demonstrating review coverage to compliance teams. Route missing and partial findings to your risk register or backlog system as actionable tickets, tagging them with the review_id for traceability. Do not auto-close findings without a subsequent design update and re-review. The harness should also compare new review results against previous reviews of the same system to detect regressions—a control that was present in a prior review and is now missing is a high-priority alert. Avoid the temptation to let the model propose remediation designs directly; its job is to identify gaps against the control catalog, while remediation design remains a human architect's responsibility with the model used in a separate, scoped design-review prompt.