A security definition of done is a short list the team agrees applies to every story before it counts as finished. Keep it to about seven checks, make most of them automatic, and review the list each quarter. Long lists get ignored. Short ones that tooling enforces actually change behavior.
Definition of done versus acceptance criteria
Acceptance criteria belong to a single story: "only the account owner can view this invoice." The definition of done applies to every story: reviewed, tested, documented. Security belongs in both. For story level criteria, see security acceptance criteria for user stories. This post covers the team wide list.
A starting checklist
Adapt these seven. Delete any that do not apply to your stack.
- Dependencies scanned. The change passes dependency scanning, and new packages were chosen deliberately.
- No secrets in code. Secret scanning ran on the branch and found nothing.
- Input handled. New inputs are validated and encoded for where they are used.
- Access checked. Every new endpoint or action enforces authorization on the server, not just in the interface.
- Logging reviewed. Security relevant events are logged, and sensitive values are not.
- Tests cover the risky path. At least one test exercises a denied or malformed case.
- Reviewer looked at the trust boundary. The reviewer confirmed who can call this and what it can reach.
Automate what you can
Items 1 and 2 are good candidates for pipeline checks that block a merge. Item 6 can often be a test template. Items 3, 4 and 7 need human judgment, so make them a short review prompt in the pull request template rather than a separate meeting.
A pull request gate is one place to enforce the automatic checks. The demo below shows a gate evaluating a pull request. Click through to see what happens when a rule fails.
Try it yourself
Click through it at your own pace, or open it full screen.
Roll it out without resentment
Introduce the list with the team, not at them. Ask which items they already do and which feel like friction. Start with three checks, and add more after the habit holds. If a check produces many false alarms, fix the tooling before blaming the engineers.
Keep a way to mark a check as not applicable with a one line reason. That keeps honest teams honest, and gives you data on which checks do not fit.
Review the list itself
Each quarter, look at what escaped to production or was found late. If a class of problem keeps slipping through, add or sharpen a check. If a check has never failed in a year, ask whether it is still needed or just habit.
Safeguard's policies and gates can enforce checks such as dependency and secret rules at pull request time, which keeps the automatic items off people's memory.
Quick check
How long should a security definition of done be?
About seven items or fewer. Longer lists are skipped, and automation covers the mechanical ones better than reminders do.
Who owns the checklist?
The team that uses it. Security can suggest items, but the team should agree them and prune them each quarter.
Last reviewed: 19 October 2026.
