Cloud Security Architecture Review Prompt

This prompt is for cloud architects and security engineers who need to perform a structured control gap analysis on an AWS, Azure, or GCP architecture design before it reaches production. The job-to-be-done is turning a design document, infrastructure-as-code plan, or architecture diagram description into a provider-specific security assessment mapped to the shared responsibility model. The reader is expected to supply a detailed system design that includes IAM roles, network topology, encryption configuration, logging setup, and compliance requirements. Without this context, the prompt cannot produce a meaningful gap analysis.

Use this prompt when you have a concrete cloud design artifact and need to identify missing controls, misconfigurations, and compliance deviations before deployment. It is appropriate for pre-production security reviews, compliance preparation, and architecture decision record support. The prompt is designed to reason about provider-native services—AWS IAM policies, Azure RBAC, GCP service accounts—and flag gaps like overly permissive security groups, missing encryption at rest, or logging blind spots. It works best when the input includes the target compliance framework (e.g., SOC 2, PCI DSS, HIPAA) and the cloud provider, so the analysis can reference specific control requirements and service defaults.

Do not use this prompt for runtime incident response, live infrastructure auditing, or penetration test planning. It analyzes design documents, not running environments. It is not a substitute for a qualified security reviewer or a formal third-party audit. For high-risk regulated workloads, always route the output to a human security architect for validation. If the input design is incomplete or the provider is unspecified, the prompt will produce unreliable results. Pair this prompt with the 'Secrets Management Architecture Review Prompt' and 'Network Segmentation Analysis Prompt' for a comprehensive cloud security review, and always run the included eval checks to verify that provider-specific misconfigurations are flagged before accepting the output.

This prompt template is designed to be the core instruction you send to a frontier model when you need a structured, provider-specific security gap analysis of a cloud architecture. It assumes you have a design document, diagram description, or Infrastructure-as-Code (IaC) plan as your primary input. The template uses square-bracket placeholders that you must replace with concrete values before execution. Do not leave any placeholders unresolved in a production system; doing so will cause the model to hallucinate or default to generic, unhelpful advice.

textCopy
You are a senior cloud security architect. Your task is to perform a rigorous security review of the provided cloud architecture design, strictly mapped to the shared responsibility model of [CLOUD_PROVIDER].

## Input
[ARCHITECTURE_DESIGN_DOCUMENT]

## Review Constraints
- Provider: [CLOUD_PROVIDER] (must be one of AWS, Azure, GCP)
- Compliance Framework: [COMPLIANCE_FRAMEWORK] (e.g., SOC 2, PCI DSS, HIPAA, none)
- Risk Appetite: [RISK_LEVEL] (must be one of Low, Moderate, High)
- Focus Areas: [FOCUS_AREAS] (e.g., IAM, Network, Encryption, Logging, Compute, all)

## Output Schema
Return a single valid JSON object with the following structure:
{
  "summary": "A one-paragraph executive summary of the most critical findings.",
  "shared_responsibility_analysis": {
    "provider_responsibilities": ["List of controls the provider manages"],
    "customer_responsibilities": ["List of controls the customer must implement"],
    "gaps": ["List of controls that are unclear or unassigned"]
  },
  "findings": [
    {
      "id": "F-001",
      "severity": "Critical|High|Medium|Low",
      "category": "IAM|Networking|Encryption|Logging|Compute|Compliance",
      "title": "Short finding title",
      "description": "Detailed description of the misconfiguration or missing control",
      "resource": "Specific resource or service affected",
      "recommendation": "Actionable remediation step",
      "reference": "Link to [CLOUD_PROVIDER] best practice or [COMPLIANCE_FRAMEWORK] control ID"
    }
  ],
  "compliance_mapping": [
    {
      "control_id": "String from [COMPLIANCE_FRAMEWORK]",
      "status": "Compliant|Non-Compliant|Not Applicable",
      "evidence": "How the design meets or fails the control"
    }
  ],
  "risk_score": 0-100,
  "next_steps": ["Prioritized list of 3-5 immediate actions"]
}

## Instructions
1. Analyze the design against [CLOUD_PROVIDER] Well-Architected Framework security pillar.
2. Identify misconfigurations, missing controls, and deviations from least privilege.
3. Map every finding to a specific resource or service in the design.
4. For each finding, provide a concrete, actionable recommendation, not generic advice.
5. If [COMPLIANCE_FRAMEWORK] is provided, map findings to specific control IDs.
6. If the design document is incomplete, note assumptions and flag missing information as a finding.
7. Do not invent resources or services not present in the design.

To adapt this template, start by replacing the placeholders with concrete values. For [ARCHITECTURE_DESIGN_DOCUMENT], paste the full text of your design, diagram description, or IaC plan. For [CLOUD_PROVIDER], use the exact string "AWS", "Azure", or "GCP" to trigger provider-specific reasoning. The [FOCUS_AREAS] placeholder can be a comma-separated list or the string "all". If no compliance framework applies, set [COMPLIANCE_FRAMEWORK] to "none" and the model will skip the compliance mapping section. The output schema is strict JSON; you should validate it against this schema in your application harness before surfacing results to a user. For high-risk production reviews, always route the final output to a human security architect for approval before acting on any remediation steps.

This prompt is designed to be embedded in a security review pipeline, not used as a one-off chat. The implementation harness must enforce provider-specific validation, handle the shared responsibility model correctly, and ensure that every finding is traceable to a control framework. Because cloud misconfigurations are a leading cause of security incidents, the harness should treat the model's output as a draft analysis that requires structured validation before it reaches an architect or auditor.

Wire the prompt into an application by first assembling the required inputs: the architecture document or diagram description, the target cloud provider (AWS, Azure, or GCP), the applicable compliance frameworks, and the risk tolerance level. The application layer should pre-process the architecture description to extract service names, resource types, and trust boundaries before passing them into the prompt as structured context. After the model responds, run a provider-specific validator that checks for known misconfiguration patterns—for example, S3 bucket policies with Principal: *, Azure NSG rules with 0.0.0.0/0, or GCP service accounts with overly broad IAM roles. If the validator flags issues, append the validation errors to the original prompt context and request a targeted re-review of only the flagged resources. Log every prompt version, input hash, model response, and validator result for auditability. For high-risk environments, route all findings through a human review queue before they appear in any dashboard or report.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, such as Claude 3.5 Sonnet or GPT-4o, because cloud architecture documents can be lengthy and the analysis requires cross-referencing multiple control families. Do not use a small or general-purpose model for this workflow—missed misconfigurations have direct security consequences. Set temperature to 0 or near-zero to maximize consistency across reviews. If your architecture documents exceed the model's context window, implement a chunking strategy that splits the document by service boundary or trust zone, review each chunk independently, and then run a synthesis pass that reconciles cross-boundary findings. The synthesis pass should flag any control gaps that span multiple chunks, such as a network ACL in one chunk that contradicts a security group rule in another.

The output schema should be strictly enforced. Define a JSON schema that includes arrays for findings, control gaps, compliance mappings, and remediation steps. Each finding must include a resource identifier, the specific misconfiguration, the control framework reference, and a severity rating. After the model responds, validate the JSON structure and retry up to two times if the output is malformed or missing required fields. On the second retry, include the schema validation errors in the prompt so the model can self-correct. If both retries fail, log the failure, flag the review as incomplete, and escalate to a human reviewer. Never silently accept a partial or malformed security review.

For teams integrating this into a CI/CD pipeline or architecture review platform, implement a caching layer that stores review results keyed by the hash of the architecture document and the prompt version. This prevents redundant reviews of unchanged architectures and reduces both cost and latency. When the architecture document changes, invalidate only the affected chunks and re-review them. Finally, build an eval harness that runs this prompt against a golden dataset of known cloud architectures with documented misconfigurations. Measure precision, recall, and false-positive rate on a per-provider basis. A prompt that misses S3 bucket misconfigurations but catches IAM issues is not ready for production—provider-specific eval coverage is non-negotiable.