Secure Design Reviews (SDRs) are documents, similar to ADRs, that help teams quickly assess a design and make security decisions at a specific point in time.
SDRs work best when they are not treated as just another document listing security gaps. Their real value is as a collaboration tool: helping teams build a shared understanding of a tool or system, identify security threats and vulnerabilities, and work together on practical ways to resolve them.
A typical SDR follows this structure:
| Section | Description |
|---|---|
| Title | ADR/SDR ID and a clear, easy-to-understand title. Example: SDR-0004: Sharing Sensitive Data Externally. |
| Metadata | Key details about the review, including authors, participants, date, related ticket, and status such as draft, in progress, or complete. |
| Summary | A brief summary of the purpose of the review and the main design or security question being evaluated. |
| Scope | Defines what is being reviewed and sets boundaries for the assessment. This could include a feature, application, business process, physical device, SaaS service, proposed tool, or existing legacy system. Clear scope helps keep the review focused and time-boxed. |
| Background | Relevant context provided by the vendor, development team, business owner, or other stakeholders. This may include documentation, emails, Slack conversations, audit findings, prior assessments, or details about how the system fits into a larger initiative. |
| Threat Model | A structured model of the system and its security boundaries. C4 diagrams can be used to map the architecture of SaaS platforms, internal tools, browser extensions, or other systems. A framework like STRIDE can then be used to identify potential threats. |
| Threats and Mitigations | Details each identified threat, its potential impact, risk rating, and recommended mitigation. This section should connect the threat model to practical security decisions. |
| Action Items | Immediate tasks that should be completed to address findings from the review. These should be specific, assigned where possible, and tied to the risks identified. |
| Follow-Ups | Longer-term work, tickets, initiatives, or decisions that have been agreed up to fully resolve the review. This section tracks what is happening after the initial assessment is complete. |
While SDRs tend to follow a base structure, the review should be adjusted based on what is being reviewed. A SaaS service, an internal tool, an AI application, a browser extension, or a physical device all need different framing and different threat modeling techniques.
For SaaS services, the review incorporates Push Security’s Browser & Identity Attacks Matrix alongside a functional architecture model. This helps identify risks around identity, browser-based attacks, SaaS integrations, OAuth flows, session handling, and user behavior.
For AI systems, the review incorporates the MITRE ATLAS Matrix and OWASP’s guidance on securing Agentic Applications. This is useful when looking at risks like prompt injection, tool abuse, data leakage, insecure agent permissions, model behavior, and trust boundaries between users, agents, tools, and external systems.
The depth of the review also depends on the amount of time available. If the SDR has a full working session or multiple meetings, it makes sense to spend more time on modeling, architecture review, and threat identification. If there are only a couple of hours, the review becomes more focused: quickly understand the system, identify the highest-risk threats, and provide practical mitigations and action items.
A good SDR is not about creating a long security document. It is about helping teams understand the system, identify the risks that matter, and agree on what needs to happen next. Done well, SDRs make risks visible, clarify tradeoffs, and help teams make better security decisions quickly, whether the tool or service is still a proof of concept or an existing legacy system with AI being added to it.