Security Decision Record Generation Prompt

This prompt is for security architects and technical decision makers who need to produce a structured, auditable Security Decision Record (SDR) from a design proposal, threat model, or architectural change request. The job-to-be-done is transforming a messy design discussion—often spread across documents, meeting notes, and Slack threads—into a single, traceable artifact that captures the security context, the options considered, the chosen approach, and the explicit rationale behind the decision. This is not a prompt for generating security requirements from scratch or for performing a live threat model; it assumes a design already exists and the architect needs to formalize the decision that was made.

Use this prompt when the decision involves a meaningful security trade-off—such as choosing an authentication protocol, accepting a residual risk, defining a data protection boundary, or selecting a cryptographic primitive—and when that decision will need to be revisited during an audit, an incident, or a future architecture review. The prompt requires several concrete inputs to be effective: a summary of the security problem or design context, a list of at least two options that were genuinely considered, the chosen option, and the constraints (regulatory, performance, operational) that shaped the trade-off. Without these inputs, the model will generate a hollow template that lacks the evidentiary weight an SDR requires.

Do not use this prompt for real-time incident response decisions, where speed and on-call runbooks take priority over structured documentation. Do not use it to replace a formal threat modeling exercise; the SDR documents a decision, not the discovery of threats. In regulated environments, the output must be reviewed and signed off by a human with the authority to accept the documented residual risk. The prompt is a drafting accelerator, not a replacement for architectural judgment or accountability. The next step after generating the SDR is to run the provided eval checks for decision traceability, assumption documentation, and option completeness before storing the record in your architecture repository.

This prompt template produces a structured Security Decision Record (SDR) from architectural design documents, threat models, or verbal design context. It forces the model to capture the decision context, options considered, trade-offs evaluated, rationale, and residual risks in a format suitable for audit review and future engineering reference. The template is designed to be wired into a review pipeline where design documents are submitted before implementation begins.

textCopy
You are a security architect documenting a security design decision for audit and future review.

Generate a Security Decision Record (SDR) using the following structure:

## SDR-[YYYY]-[NNN]: [DECISION_TITLE]

**Status:** [Proposed | Accepted | Deprecated | Superseded]
**Date:** [YYYY-MM-DD]
**Deciders:** [DECIDER_LIST]
**Stakeholders:** [STAKEHOLDER_LIST]

### Context
[Summarize the security problem, system boundary, threat environment, and constraints that frame this decision. Reference specific design documents, threat models, or compliance requirements.]

### Decision
[State the security decision clearly. What control, pattern, technology, or policy was chosen? Be specific enough that an engineer can implement it without ambiguity.]

### Options Considered
| Option | Description | Pros | Cons |
|--------|-------------|------|------|
| [OPTION_1] | [DESCRIPTION] | [PROS] | [CONS] |
| [OPTION_2] | [DESCRIPTION] | [PROS] | [CONS] |
| [OPTION_N] | [DESCRIPTION] | [PROS] | [CONS] |

### Trade-Off Analysis
[Analyze the chosen option against alternatives across dimensions: security posture, operational complexity, performance impact, cost, team capability, compliance alignment, and future flexibility.]

### Rationale
[Explain why this decision was made. What evidence, principles, standards, or threat scenarios drove the choice? Reference specific threats mitigated and residual risks accepted.]

### Implications
[What changes does this decision require? List concrete actions: configuration changes, new infrastructure, policy updates, monitoring additions, documentation updates, or team training.]

### Residual Risks
[What risks remain after this decision is implemented? What assumptions must hold true? What compensating controls are needed? What should future reviewers watch for?]

### Validation Criteria
[How will we verify this decision was implemented correctly? List testable conditions, audit checks, or monitoring alerts that confirm the control is working.]

### Related Decisions
[Link to related SDRs, ADRs, or design documents that influenced or are influenced by this decision.]

---

**Inputs:**
- Design Context: [DESIGN_CONTEXT]
- Threat Model: [THREAT_MODEL]
- Compliance Requirements: [COMPLIANCE_REQUIREMENTS]
- Existing Decisions: [EXISTING_DECISIONS]
- Risk Tolerance: [RISK_TOLERANCE]

**Constraints:**
- [CONSTRAINT_1]
- [CONSTRAINT_2]
- [CONSTRAINT_N]

Adapt this template by replacing the square-bracket placeholders with concrete inputs from your design review process. The [DESIGN_CONTEXT] placeholder should receive the system architecture description, data flow diagrams, or component interaction summaries. The [THREAT_MODEL] placeholder accepts STRIDE analyses, attack trees, or threat modeling outputs. The [COMPLIANCE_REQUIREMENTS] field should list applicable standards such as SOC 2, PCI DSS, HIPAA, or internal policy references. If you lack a formal threat model, replace that placeholder with a description of the trust boundaries and known threats. The [RISK_TOLERANCE] input shapes how the model evaluates trade-offs—specify whether the organization prioritizes security over velocity, accepts certain residual risks, or requires compensating controls for any accepted risk.

Before deploying this prompt into a production review pipeline, implement validation checks on the output. Verify that every SDR contains all required sections, that options are compared in a structured table, and that residual risks are explicitly documented rather than hand-waved. For high-assurance environments, require human security architect review before the SDR status moves from Proposed to Accepted. Wire the output into your existing ADR repository with a naming convention that distinguishes security decisions from general architecture decisions. Test the prompt against known security decisions from past incidents to verify it surfaces the same risks and trade-offs that experienced reviewers identified.

This prompt is designed to be called from a security architecture review pipeline, a design review bot, or an internal developer portal where architects submit design documents. The harness should collect the required inputs—[DESIGN_DOC], [SECURITY_CONTEXT], [COMPLIANCE_STANDARDS], and [DECISION_OPTIONS]—from upstream systems or structured forms before assembling the prompt. Do not expose a free-text chat interface; the prompt requires structured context to produce an auditable Security Decision Record (SDR). The output is a JSON document conforming to the [OUTPUT_SCHEMA], which your application must validate before storage.

Wire the prompt into a workflow that enforces traceability. After the model returns the SDR, run a validation step that checks: (1) the decision_id is present and unique, (2) all options listed in options_considered have corresponding trade-offs in trade_off_analysis, (3) the rationale field references specific evidence from the [DESIGN_DOC] rather than generic statements, and (4) every assumption in the assumptions_log has an owner and validation_criteria. If validation fails, retry once with the validation errors injected into [CONSTRAINTS] as explicit correction instructions. If the retry also fails, route the record to a human security architect for manual completion rather than accepting a partial SDR. Log every generation attempt, validation result, and human escalation for audit purposes.

For model choice, use a model with strong reasoning and structured output capabilities. The prompt expects the model to compare architectural options against security properties, which requires careful trade-off reasoning rather than pattern matching. Set temperature low (0.1–0.2) to reduce variance in decision rationale. If your deployment supports structured output modes (e.g., JSON mode or function calling with a strict schema), use them to enforce the [OUTPUT_SCHEMA] at the API level rather than relying solely on prompt instructions. For high-compliance environments, store the raw prompt, the full model response, the validation results, and the final approved SDR in an append-only decisions log. This creates an evidence trail showing that the decision was generated with specific inputs, reviewed by specific validators, and approved by a named human when required. Never auto-approve SDRs that touch authentication architecture, encryption key management, or zero-trust boundaries without human review, regardless of validation scores.