A testable security requirement names who acts, what they do, under what condition and what must happen, in terms a tester can check. "The system shall be secure" cannot fail, so it cannot pass. "A user without the admin role gets a denial on the delete call" can.
Why vague requirements fail
If a requirement cannot be tested, teams argue about whether it was met. NIST's Secure Software Development Framework asks organizations to identify and document the security requirements their software must meet and to maintain them over time (PO.1.2), and to verify compliance at key points in the lifecycle. Verification needs a requirement that can be verified.
A four part template
Use this sentence shape: Given a condition, when an actor does an action, then a specific result occurs, and it is recorded or limited in a stated way.
| Part | Question | Example |
|---|---|---|
| Actor | Who? | A signed-in user without the editor role |
| Action | Does what? | Calls the update endpoint |
| Condition | When? | For a record they do not own |
| Result | What must happen? | The call is denied and the denial is logged |
Weak versus strong
| Weak | Strong |
|---|---|
| Passwords must be strong | Passwords shorter than the agreed minimum length are rejected at signup with a clear message |
| The system must be protected from injection | Input containing a quote or script tag is stored and displayed as plain text, and never executed |
| Access must be controlled | A user can view only records that belong to their organization |
| Logs must be secure | Logs contain no passwords or full card numbers, and only the audit group can read them |
| Data must be encrypted | Data at rest in the customer table is encrypted with a key held outside the database |
Steps to write one
- Start from a risk. Ask what could go wrong. The Threat Modeling Manifesto's second question is "what can go wrong?"
- Write the safe behavior in a sentence. Name the actor and the action.
- Add a number or a state. Length, count, time or a named result.
- Ask how you would test it. If you cannot say, rewrite it.
- Decide where it is checked. Unit test, integration test, review, scan or manual test.
- Link it to the story. A requirement without a home is forgotten.
Pick a source for the content
You do not need to invent requirements. The OWASP Application Security Verification Standard provides a basis for testing application technical security controls and a list of requirements for secure development, and it is a practical menu to choose from. Pick the items that match your risks and rewrite them in your own words with your own roles and data.
Where thresholds come from
Some thresholds, such as password length or session timeout, are policy choices. Write them in a shared policy document and refer to them from requirements, so changing the policy updates every story. Do not hard code the number in dozens of tickets.
Check coverage
Once a quarter, list your requirements and tick whether each has a test. Missing tests are a to-do list. Requirements that nobody can test are candidates for rewriting or removal.
Common mistakes
- Listing technologies instead of outcomes, such as "use TLS" with no statement of what must be protected.
- Writing requirements that duplicate the definition of done.
- Making them so detailed they describe the design, not the behavior.
- Leaving out the negative case.
Link to evidence
A requirement with a passing test is evidence. Store the test result with the release so you can show it later. Safeguard offers compliance and evidence automation, which can map checks and results to controls and keep them for reviews. A free scan is at gold.safeguard.sh/scan.
Quick check
What makes a security requirement testable?
It names the actor, action, condition and a specific observable result, so a tester can try it and see pass or fail.
Where can I find requirement wording to start from?
The OWASP ASVS is a practical menu of requirements. Choose the ones that match your risks and rewrite them with your roles and data.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1
- Threat Modeling Manifesto
- OWASP Application Security Verification Standard
Last reviewed: 19 October 2026.
