Secure Design Records (SDRs) are documents, similar to ADRs, that help teams quickly assess a design and make rapid 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 lies in using them as a collaboration tool that helps teams build a shared understanding of a tool or system, quickly identify security threats, and come to a clear agreement on how to resolve them.
A typical SDR follows this structure:
| Section | Description |
|---|---|
| Title | SDR ID and a clear, easy-to-understand title. Example: SDR-0004: Sharing Sensitive Data Externally. |
| Metadata | Key details about the record, including authors, participants, date, related tickets, 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 this base structure, the record 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, I incorporate 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.
While for AI systems, I incorporate the MITRE ATLAS Matrix and OWASP’s guidance on securing Agentic Applications. This is very 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 SDR 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 SDR 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 quickly get to agreement on what needs to happen next. Done well, SDRs make risks visible, clarify tradeoffs, and help teams make better security decisions quickly, regardless on if it a new tool being assessed or changes to a critical legacy system that needs security’s input.