What Good Looks Like
Short, worked excerpts from real examples showing high-quality content for each section of a SAD. Pattern-match your own work against these.
Guidance
The standard tells you what to document. This section tells you how to do it well — what good looks like, what mistakes to avoid, and what reviewers are looking for.
Anti-Patterns
Common mistakes, formulaic filler, and patterns that fail governance review. With before-and-after examples you can learn from.
Decision Guides
Flowcharts for common questions: which documentation depth, when do I need a threat model, should I split into multiple SADs, when is Comprehensive worth it.
Reviewer Perspectives
What different reviewers look for in a SAD — ARB chair, Security Architect, Data Architect, Site Reliability Engineer, Finance partner. Write for the audience.
When to use this guidance
Section titled “When to use this guidance”- Before you start — Read the anti-patterns and the decision guide for “which depth?”
- While drafting — Keep the worked examples open in a second tab; pattern-match what you’re writing
- Before submission — Read the reviewer perspectives for your governance path
- After first draft — Run the AI validation prompt to catch common gaps
Guiding principles
Section titled “Guiding principles”Three principles run through all of this guidance:
- Proportionality. Effort matches criticality. A Tier 4 internal tool does not need the same rigour as a Tier 1 customer-facing platform. Over-documenting is wasteful; under-documenting is risky.
- Honesty. Flag what you don’t know. “This assumption is unverified” is better than a confident-sounding guess. “We will do X” is weaker than “X is done — see Y”.
- Specificity. Generic statements do not help anyone. “The solution is secure” is not a security view. “Authentication uses Entra ID SSO with OIDC, MFA enforced for all users, session timeout 30 minutes” is.