Security decision record — notes-api (fill in)¶
Before you fill this in
Start in: Module 13 engineering assignment. Save as: docs/capstone/work/security-decision-record.md, one file per decision (for example security-decision-record-2.md). Edit the copy, never this template.
Example: Helix decision record. If your copy is about HELIX_DEBUG, you’ve decided for the wrong system.
Write one record per significant security decision: a control you chose, a threshold you set, or an architecture trade-off you made. Don’t try to make one record cover the whole capstone.
| Field | Value |
|---|---|
| Decision id | |
| Date | |
| Author | |
| Status | proposed / accepted / superseded |
Threat¶
What specific attack or failure this decision responds to. Name the invariant it protects, not just the vulnerability class.
Chosen control¶
Why this control¶
The reasoning, not just the choice — what made this the right tradeoff given the constraints you actually had (cost, latency, existing architecture, team size).
Alternative considered¶
At least one option you did not pick, and the specific reason it lost — "more work" is not a reason; "adds a round trip to every request for a threat we rate low-likelihood" is.
Residual risk¶
What this control does not cover. If you cannot name one, you have not looked hard enough.
Detection coverage¶
If this control fails or is bypassed, what would notice — a rule id, or "none yet" stated plainly.
Operational cost¶
Who maintains this, what breaks if it's misconfigured, and what it costs at the resource/latency/on-call level.