Home / Knowledge hub / Security requirements
Knowledge hub
Security requirements
Written statements of what the software must do or prevent to be secure.
What it means
Security requirements are statements about what a system must do, or must stop from happening, to be secure. They sit beside functional requirements such as "users can export a report" and describe the safety conditions around it. They answer the question of what safe means for this product.
A good one can be tested. "The app must be secure" cannot be. "Only the account that owns an invoice can download it" can, because someone can try with a second account and see whether it works. Written clearly, a requirement becomes a test.
Why it matters
Without them, security depends on what each developer happens to remember. Two teams build the same feature with different protections, and nobody can say which one is right, because nothing was ever agreed. The result is uneven protection. Gaps appear where no one thought to look.
They also give you something to show. A customer, auditor or insurer asking what you require of your software gets an answer, and a pentest has a standard to measure against. When a flaw turns up, you can say which requirement it broke, which makes the fix easier to scope and prioritise.
How it shows up
Requirements come from several places: regulation, customer contracts, threat modelling and lists such as OWASP ASVS. A threat model turns each threat into a requirement. Write them into the same tickets as the feature, not in a separate document that goes stale.
The mistakes repeat. Requirements are too vague to test, or copied from a standard without choosing what applies. They are written once and never updated when the feature changes. Or they exist but nobody checks the finished product against them. Add an acceptance test for each, and review the list when the design changes.
Questions people ask
Security requirements, answered
What is the difference between a security requirement and a security control?
A requirement says what must be true, such as "only the owner can read a record". A control is the mechanism that makes it true, such as an ownership check in code. Write the requirement first, then choose controls.
Where do security requirements come from?
From laws and contracts, from your own threat modelling, from past incidents and from checklists such as ASVS. Choose those that fit your product and risk. Not every source applies to every product.
How detailed should they be?
Detailed enough that two people would agree on whether the software meets them. If the wording leaves room for argument, it is too loose to test. Concrete wording also makes it easier to write a test.
Who owns them?
The product owner or engineering lead should own the list, with security teams advising. If nobody owns it, it will go stale. Review it whenever the product changes in a significant way.
Do agile teams need written requirements?
Yes, but they can be short. A line in the ticket or in the definition of done is enough, provided it is specific and checked before release. Short and checked beats long and ignored.
Sources
Where this comes from
Related
Terms that sit next to this one
OWASP ASVS
A detailed checklist of security requirements for web applications.
Threat model
Asking what is worth taking, who wants it, and how they would try.
STRIDE
A checklist of six threat types used to find what could go wrong in a design.
Secure by design
Choosing safe defaults and structures from the start, not bolting protection on later.
Security regression test
An automated test that fails if a fixed vulnerability ever returns.
Can anyone test your requirements?
A requirement is only worth having if something checks it. We test the running app for the cases that matter, such as cross-account access, and prove each failure. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.