Write security acceptance criteria as short, testable statements attached to the story, using the same given, when, then shape as other criteria. "The system is secure" cannot be tested. "A user without the billing role receives a denial when requesting the invoice endpoint" can.
Why bother at story level
Security requirements kept in a separate policy document are read at audit time and rarely during a sprint. Criteria on the story are seen by the person writing the code and the person reviewing it. They also create a natural place to check the work is done.
You do not need criteria on every story. Use them where a story touches access, input, stored data or an external system.
A four part pattern
For each relevant story, ask one question from each group.
Access. Who may do this, and what happens to everyone else? Example: Given a signed in user without the editor role, when they submit a change, then the request is refused and no data is altered.
Input. What does the system accept, and what does it do with bad input? Example: Given an upload of a file type not on the allowed list, when it is submitted, then it is rejected with a clear message and not stored.
Data. What is stored or shown, and who can see it? Example: Given a user viewing the list page, when results load, then only records owned by their organisation appear.
Evidence. What gets recorded so we can investigate later? Example: Given an export of customer data, when it completes, then the actor, time and record count are logged without logging the data itself.
Make them testable
A criterion earns its place only if someone can check it. Prefer negative cases, because they are the ones that get missed: the wrong role, the wrong owner, the oversized input, the repeated request. If a criterion has no obvious test, rewrite it until it does, or move it to a design discussion.
Keep the list short
Three to five security criteria per relevant story is plenty. A story with fifteen is really several stories, or a sign the design needs a proper session. See how to write abuse cases for a feature for a method to find the cases worth covering.
Reuse what repeats
If the same criteria appear on many stories, such as "every endpoint checks ownership," promote them into the team's definition of done or a shared checklist and stop retyping them. Reserve story level criteria for what is specific to that story.
Quick check
Who writes the security criteria, the product owner or the engineers?
Both can. A common pattern is that engineers draft them during refinement and the product owner confirms they match the intended behaviour.
Do these replace security testing?
No. They make sure the basic expectations are written and checked during the sprint. Scanning, review and testing still catch what the criteria did not anticipate.
Last reviewed: 19 October 2026.
