Encryption Architecture Review Prompt

This prompt is for security architects and platform engineers who need to review encryption-at-rest, encryption-in-transit, and key management designs across data stores and services. Use it when you have a system design document, architecture diagram, or infrastructure-as-code specification and you need a structured cryptographic inventory that identifies algorithm choices, key lengths, rotation policies, and compliance gaps. The prompt produces a gap analysis, not a penetration test. It assumes the input design is complete enough to reason about data flows and storage boundaries.

The ideal input is a design artifact that describes where data lives and how it moves: architecture decision records, cloud infrastructure diagrams, data flow diagrams, or Terraform/CloudFormation specifications. The prompt works best when the input names specific services, data stores, and communication paths. If your design document only describes logical components without mentioning TLS termination points, cipher suite configuration, or key storage mechanisms, the prompt will produce a sparse inventory with many 'unknown' entries. In that case, supplement the input with infrastructure-as-code snippets or configuration defaults before running the review.

Do not use this prompt for runtime traffic analysis, live penetration testing, or cryptographic implementation review in source code. Those require different tools and evidence. This prompt also cannot verify that the implemented system matches the design—it only analyzes what the design claims. For production systems, pair this design-level review with configuration audits, certificate transparency logs, and runtime TLS scans. When reviewing designs that handle regulated data (PCI, PHI, PII subject to GDPR), always route the output through a human security reviewer before accepting findings as complete.

This prompt template is designed to produce a structured cryptographic inventory and gap analysis from your encryption architecture documentation. It examines encryption-at-rest, encryption-in-transit, and key management designs across data stores and services. Replace each square-bracket placeholder with your specific design context before sending the prompt to the model. The template includes placeholders for the design document, output schema, evaluation constraints, risk tolerance, and any tool specifications you want the model to consider.

textCopy
You are a senior security architect reviewing encryption designs for production systems. Your task is to analyze the provided architecture documentation and produce a structured cryptographic inventory with identified gaps, risks, and prioritized recommendations.

## INPUT
[DESIGN_DOCUMENT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "cryptographic_inventory": [
    {
      "component": "string (service, data store, or communication path)",
      "data_classification": "string (e.g., PII, financial, internal, public)",
      "encryption_at_rest": {
        "algorithm": "string or null",
        "key_length": "string or null",
        "key_management": "string (e.g., KMS, HSM, application-managed, vault)",
        "rotation_policy": "string or null",
        "gaps": ["string"]
      },
      "encryption_in_transit": {
        "protocol": "string or null",
        "tls_version": "string or null",
        "cipher_suites": ["string"],
        "certificate_management": "string or null",
        "mutual_tls": "boolean or null",
        "gaps": ["string"]
      },
      "key_management_summary": {
        "key_type": "string (symmetric, asymmetric, token)",
        "storage_location": "string",
        "access_controls": ["string"],
        "rotation_mechanism": "string or null",
        "revocation_capability": "boolean or null",
        "gaps": ["string"]
      }
    }
  ],
  "cross_cutting_findings": [
    {
      "finding_id": "string",
      "severity": "critical | high | medium | low",
      "category": "string (e.g., algorithm weakness, missing encryption, key exposure, rotation gap, protocol downgrade)",
      "description": "string",
      "affected_components": ["string"],
      "recommendation": "string",
      "reference_standard": "string (e.g., NIST SP 800-57, OWASP ASVS V9, PCI DSS 3.4)"
    }
  ],
  "compliance_alignment": {
    "standards_assessed": ["string"],
    "gaps_by_standard": {
      "[STANDARD_NAME]": ["string"]
    }
  },
  "prioritized_actions": [
    {
      "priority": "integer (1 highest)",
      "action": "string",
      "effort_estimate": "string (small, medium, large)",
      "risk_reduction": "string"
    }
  ]
}

## CONSTRAINTS
- Only analyze components explicitly described in the design document. Do not invent services or data flows.
- Flag missing information as gaps rather than assuming defaults.
- For each gap, cite the specific section of the design document where information is missing.
- Prefer NIST SP 800-57 and OWASP ASVS V9 as reference standards unless [PREFERRED_STANDARDS] are specified.
- Mark any algorithm below 128-bit security strength as a critical finding.
- Flag any TLS version below 1.2 as a critical finding.
- If key rotation is not described for a component, mark it as a high-severity gap.

## RISK TOLERANCE
[RISK_LEVEL: standard | elevated | maximum]
- standard: Report all findings. Prioritize based on exploitability and impact.
- elevated: Escalate medium findings to high if they affect PII or financial data.
- maximum: Escalate all findings by one severity level. Flag any unencrypted internal traffic as critical.

## TOOLS AVAILABLE
[TOOLS: comma-separated list, e.g., "cipher_suite_validator, tls_version_checker, key_length_auditor"]
If tools are specified, note in each finding whether automated validation is possible and which tool applies.

## EXAMPLES
[EXAMPLES: optional few-shot examples of expected output for common patterns]

## INSTRUCTIONS
1. Parse the design document and extract all components that store, process, or transmit data.
2. For each component, populate the cryptographic inventory. Use null for fields where the design document provides no information.
3. Identify cross-cutting findings that span multiple components.
4. Map findings to compliance standards where applicable.
5. Produce prioritized actions ordered by risk reduction impact.
6. If the design document is incomplete or ambiguous, note this in a leading remark before the JSON output.

Adaptation guidance: The [DESIGN_DOCUMENT] placeholder accepts architecture diagrams, data flow descriptions, service inventories, or infrastructure-as-code excerpts. For [PREFERRED_STANDARDS], specify your organization's compliance framework (PCI DSS, HIPAA, SOC 2, FedRAMP) to align findings with audit requirements. The [RISK_LEVEL] parameter lets you tune sensitivity—use maximum for payment systems or healthcare data, standard for internal tools. If you have automated validation tools, list them in [TOOLS] so the model can flag which findings are machine-checkable versus requiring manual review. The [EXAMPLES] placeholder is optional but recommended for teams with recurring architecture patterns; provide one or two representative component analyses to calibrate output style and severity judgment.

Before shipping this prompt into a production review pipeline: Validate the output JSON against the schema using a structural validator. Run the prompt against at least three known architecture designs with documented encryption gaps to verify that the model consistently identifies the gaps you expect. Add a human review step for any finding marked critical or high severity before it reaches an audit trail. If the design document exceeds the model's context window, split it by service boundary and run the prompt per-boundary, then merge results with a deduplication step.

The Encryption Architecture Review Prompt is designed to operate on structured or semi-structured design documents, architecture decision records, or infrastructure-as-code descriptions. Before calling the model, assemble the [DESIGN_DOCUMENT] input by extracting relevant sections on data stores, service communication, TLS termination, and key management. If the design spans multiple documents, concatenate them with clear section headers. The [COMPLIANCE_STANDARDS] variable should be populated with applicable requirements such as PCI-DSS 3.2.1, FIPS 140-3, or SOC 2 cryptographic controls. If no specific standard applies, default to industry best practices for the cloud provider and data classification level in use.

Wire the prompt into an application by first validating the input completeness: check that the design document contains at least one data store and one service-to-service communication path. If the input is too sparse, return a structured error asking for the missing sections rather than calling the model. After the model returns the cryptographic inventory, run a post-processing validator that checks for required fields in each inventory entry: algorithm, key_length, location, rotation_policy, and compliance_gap. If any entry is missing a required field, retry the prompt once with a specific error message appended to the [CONSTRAINTS] variable, such as 'The previous output omitted the rotation_policy field for entry X. Regenerate with all required fields populated.' If the retry also fails, flag the entry for human review rather than silently accepting incomplete output.

For TLS version and cipher suite compliance, implement a harness check that parses the output's tls_assessment section and compares reported versions against a configurable minimum (e.g., TLS 1.2+). If the model reports a version below the threshold, the harness should automatically escalate the finding to a CRITICAL severity in the review dashboard. Similarly, validate that each cipher suite mentioned maps to a known IANA-registered suite name. Unknown or malformed suite names should trigger a retry with a clarification instruction. This prevents the model from hallucinating cipher suite names that look plausible but don't exist.

Model choice matters for this workflow. Use a model with strong technical reasoning capabilities and a large context window to handle detailed design documents. Claude 3.5 Sonnet or GPT-4o are suitable defaults. Avoid smaller or older models that may confuse algorithm names or fail to distinguish between encryption-at-rest and encryption-in-transit contexts. If the design document exceeds the model's context window, pre-process it by extracting only the sections relevant to encryption: data store configurations, service mesh settings, TLS termination points, key management service references, and certificate provisioning workflows. Do not summarise these sections; truncate non-relevant content instead.

Log every invocation with the prompt version, input hash, output hash, validator results, and retry count. Store these in an audit trail that a security reviewer can inspect. For high-risk systems, require a human to approve the final cryptographic inventory before it is accepted as a review artifact. The approval step should display side-by-side the original design document excerpts and the model's extracted findings, so the reviewer can verify that the model didn't miss a data store or misclassify a communication path. Never auto-apply remediation recommendations from this prompt without human review.