A security definition of ready is a short checklist a user story must pass before the team pulls it into a sprint. It confirms the data touched, the trust boundaries crossed and the abuse cases are known, so security questions are answered while a story is cheap to change, not after the code exists.
Definition of ready, in plain words
The Scrum Guide does not define a "Definition of Ready" artifact. It does say that backlog items the team can finish within one sprint are deemed ready for selection in sprint planning, and that items usually reach that state through refinement. Many teams write that idea down as a checklist and call it a definition of ready.
Adding a security section to that checklist is a team choice, not a rule from the guide. It works because refinement is the last cheap moment to ask what could go wrong.
The checks worth adding
Keep it to five or six lines. A long list gets ignored.
| Check | Question it answers | Typical evidence |
|---|---|---|
| Data named | What data does this story read, write or expose? | One line in the story |
| Trust boundary | Does input cross from a user, partner or another service? | Note on the diagram or story |
| Identity and access | Who may do this, and what happens if someone else tries? | Acceptance criterion |
| Abuse case | What is the misuse we must handle? | One abuse case or "none, because" |
| New dependencies | Does it add a package, service or SDK? | Package name and owner |
| Review needed | Does it need a design review or a threat model? | Yes or no with reason |
The last row is the useful one. It forces a decision, so a risky story gets a design review and a routine one does not.
How to run it in refinement
- Read the story aloud and ask the five questions in order.
- Write the answers into the story itself, not a separate document.
- If an answer is "we do not know", split off a time-boxed spike and keep the story out of the sprint.
- If the story needs a design review, schedule it before planning.
- Mark the story ready only when every row has an answer.
The threat modeling community frames the underlying work as four questions: what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job. The first three map neatly onto a ready check. The fourth belongs to review and testing later.
Common mistakes
- Making it a gate for security staff. The team answers the questions. Security helps only when the answer is unclear.
- Copying a list of 20 items. Pick the ones that change decisions.
- Treating "none" as an answer. Require a reason, such as "no new input, read-only report".
- Never revisiting the list. After a security bug, ask which ready check would have caught it, and add or sharpen that line.
NIST's Secure Software Development Framework supports this habit. Practice PW.1.1 asks teams to use risk modeling to assess security risk for the software, and PO.1.2 asks them to document the security requirements the software must meet. A ready check is a light way to apply both at story level.
Where it stops
A ready check does not replace a threat model for a new system or a major change. It also does not prove the story is secure. It only proves the team thought about it in time. Pair it with security acceptance criteria and a security-aware definition of done so the thinking carries through to testing and release.
Safeguard can add dependency scanning and policy checks on pull requests, which backs the "new dependencies" row with data. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a definition of ready part of Scrum?
No. The Scrum Guide describes backlog items being ready for selection after refinement but does not define a Definition of Ready artifact. Teams add one by choice.
How long should the security part be?
Five or six lines. Each line should change a decision, such as whether to hold a design review or split off a spike.
Who answers the questions?
The team that owns the story. Security staff or a champion step in when an answer is unclear.
Sources
- The Scrum Guide
- NIST SP 800-218, Secure Software Development Framework 1.1
- Threat Modeling Manifesto
Last reviewed: 19 October 2026.
