A security decision record is a short document that captures a significant risk decision: the context, the options considered, what was chosen, who approved it and what would trigger a review. Keeping them in a shared, searchable place makes audits easier and stops teams from relitigating old debates.
Why bother
People forget why a choice was made. Two years later a new engineer or auditor finds an odd configuration and nobody remembers the reason. Either it is "fixed," reintroducing the original problem, or it is defended with no evidence.
A record preserves reasoning. It also shows that risk acceptance was deliberate, which matters in audits and customer reviews.
The idea borrows from architecture decision records used by engineering teams, so developers often find it familiar.
When to write one
Not every choice needs a record. Write one when a decision:
- Accepts a risk above your normal threshold.
- Chooses between security designs with different trade-offs.
- Grants a long lived exception.
- Changes how sensitive data is stored or shared.
- Departs from a written policy.
A template that fits one page
- Title and date.
- Context. What problem or requirement triggered this, in a short paragraph.
- Options. Two to four realistic choices, each with pros and cons.
- Decision. The option chosen and the main reason.
- Risks accepted. What remains exposed, in plain words.
- Controls. Compensating measures and who runs them.
- Approvers. Names and roles, including the business owner.
- Review trigger. A date or event, such as a vendor change or a new data type.
- Status. Proposed, accepted, superseded or retired.
Where to store them
Use a version controlled folder or wiki that engineers already visit, with one file per record and a consistent naming scheme. Link records from the related code repository, ticket or risk register entry. If records live in a private folder, they will not be read.
Keep them honest
Write the options fairly, including the one you did not choose. Record dissent. A record that reads like justification after the fact loses credibility.
When a decision is replaced, do not delete the old one. Mark it superseded and link to the new record. The history is the value.
Connect to your register and reviews
Each accepted risk should appear in the risk register, pointing to its record. In quarterly reviews, scan for records whose review trigger has passed. Overdue triggers are a simple, objective list to work through.
Quick check
Do all security decisions need a written record?
No. Reserve records for decisions that accept notable risk, choose between significant designs or depart from policy.
Where should records be stored?
Somewhere engineers already work, such as a version controlled repository or wiki, linked to the risk register.
Last reviewed: 19 October 2026.
