Security requirements are concrete, testable requirements built on three protection goals: confidentiality, integrity and availability. They don’t come from generic catalogs. They come from asking which assets are worth protecting and why. Only then can a team decide which measures it needs and how to verify them.
Key Takeaways
- Security requirements only make sense once the team has settled which assets are worth protecting and which protection goals (confidentiality, integrity or availability) apply to each of them.
- Running a pentest just before release is the most expensive moment to find a security bug, because every design decision has already been made.
- Card games such as Elevation of Privilege or Cornucopia let teams without dedicated security expertise find and document threat scenarios in a playful way.
- Catalogs such as the OWASP ASVS are useful, but only once a team knows which protection goals it has to meet. Without that, there is no yardstick for prioritization or test depth.
- Most of the constant background noise of attacks comes from opportunistic companies that scan for vulnerabilities automatically, not from the stereotypical hacker going after one specific target.
Security Is Part of Software Quality
Security is a quality attribute of software, just like performance or availability, and security requirements deserve the same treatment as any other quality requirement. For quality requirements in general, there is an established tool: the quality scenario, with a precondition, context, trigger, outcome and a testable metric.
For performance, this works well. You ask the stakeholder how long a transaction may take and get a concrete answer: one second in 99 percent of cases, under normal load. That gives you a scenario you can check, and in the end you can prove the requirement is met.
With security, many teams lack the vocabulary to say anything that precise. The topic isn’t too complex. People just talk about “security” in terms that are too abstract. If you want testable security requirements, you first have to be able to put them into words.
Why Abstract Security Requirements Can’t Be Tested
“We need a particularly high level of confidentiality” is not a testable requirement as long as nobody knows what it applies to. The sentence only means something once you say which data you are talking about.
Take a public website or a LinkedIn profile. Confidentiality is not the goal there. Quite the opposite: you want as many people as possible to see the content. Integrity, on the other hand, matters a lot. Nobody should be able to change the content without your consent.
So the need for protection depends on the specific asset under discussion. Without that asset, every security requirement is just hot air.
The CIA Protection Goals as a Shared Language
Instead of talking about “security” in general, look at the specific protection goals. The three most important ones are easy to remember by the acronym CIA:
- Confidentiality: What happens if the information becomes public? Does it bother you, is it a problem, is it maybe even against the law?
- Integrity: What happens if the information is changed without anyone intending it? Is that a problem, or does the correct state restore itself?
- Availability: Do you lose money if the system is down for half an hour? Or does nobody notice?
These questions turn a vague call for security into concrete requirements. There are further protection goals, such as authenticity, non-repudiation and anonymity. They also show that you can’t have everything at once: anonymity and non-repudiation contradict each other. Security is always a trade-off.
Assets First, Then Security Requirements
The analysis starts with one question: what is actually worth protecting? Here you distinguish between two kinds of assets.
Primary assets are what you really want to protect, the valuable data itself. Supporting assets are the parts of the system you need in order to process that data.
Draw this distinction cleanly and you get a systematic way to determine the need for protection. Only after that can you decide what has to be done to meet it.
Where Security Catalogs Like the OWASP ASVS Fit In
Catalogs such as the OWASP Application Security Verification Standard (ASVS) are useful, but they only work on top of requirements you have already gathered. The ASVS is well suited for audits and spells out fairly concretely what needs to be done. That is exactly why it reads as technical.
The catch is that catalogs like this cover everything. They don’t tell you which part matters for your system. Whether a non-compliance, meaning a catalog requirement you don’t meet, is a real problem is something you can only judge if you know your protection goal.
If there is no confidential data in your system, there’s no need for a serious discussion of the entire cryptography chapter. The ASVS has three levels, 1 to 3. Which level applies to you, and how thoroughly you need to test or review, follows from your requirements. That is why the requirements come first and the catalog second.
Threat modeling comes at the problem from the other side. It shows how a protection goal could be compromised and helps you prioritize countermeasures. But modeling the threat doesn’t tell you what to do about it. That is where a catalog like the ASVS supplies the concrete instructions.
A Pentest Verifies, It Doesn’t Prevent
A pentest at the end only checks what was decided earlier. The same rule applies as for every other testing topic: you can’t test quality in.
It’s good when a problem shows up before release. Still, just before release is the most expensive time to find a bug. After release, with real customer data in the system, it only gets more expensive. Thinking about security in architecture and design only works if the requirements are known. It’s a truism, but someone still has to act on it.
Security Analysis Is Iterative
Threat modeling and protection needs analysis are not a waterfall step you do once at the start. You repeat them whenever the basis of your original decisions changes. Several triggers call for a new round:
- New functionality: A new part of the application brings new data into the system, and its protection needs have to be determined.
- Major refactoring: After restructuring, you need to verify that the code still has the same security properties. New bugs may have crept in.
- Publicly known incidents: When an attack shows up in the press or on blogs, it’s worth fifteen minutes with the team to ask: would that have worked on us?
- New technology: AI components bring new kinds of attack, such as prompt injection or agents breaking out of their sandbox.
The OWASP Top 10 cover the classic world of web applications. By the way, they are not a security catalog but an awareness document meant to communicate the most important topics. For attacks on AI, there is now a separate AI Top 10 that covers these new scenarios.
Security Needs a Team Mindset, Not a Central Expert
Appointing one security expert for every 200 employees to tell everyone what to do achieves little. Security is a mindset, and it has to grow inside the teams.
Many teams have people who are interested in the topic. You can support them until they become advocates: the people who raise their hand in refinement and say that security needs discussing too, not just the storage space in the database. That gives security a foothold in the team, even without a designated expert.
Threat Modeling as a Card Game
Threat modeling works even with a team that has little security experience. One way in is card games with proper game rules.
The best-known example is Elevation of Privilege by Adam Shostack, created in Microsoft’s security team. It is released under a Creative Commons license and has been adapted several times. OWASP has its own version called Cornucopia, and for cloud scenarios there is Cumulus.
The games play much like trick-taking card games with a trump suit. You win the trick if you can explain why the attack scenario on your card is relevant to your system. Someone takes notes, and at the end the collected tricks are your list of potential attack scenarios.
“It’s a very low-threshold way to talk about threat scenarios and do threat modeling while playing cards for two hours on a Friday afternoon.”
(Markus Geiger)
Online versions exist, which is handy for remote and hybrid teams. Testers can join in and bring their own perspective.
What the Real Threat Situation Looks Like
Attacks happen all the time. If you look closely at your logs, you’ll see some attempted attack practically every hour. That doesn’t mean data is being stolen everywhere, constantly, partly because standard frameworks come with fairly decent security out of the box.
The image of the lone hacker in a hoodie is misleading. The vast majority are opportunistic IT companies that scan systems by the thousands to see whether there is money to be made. Sometimes they don’t even exploit the vulnerability they find. They document it and sell it on to someone who then installs ransomware. This market, worth billions, produces the constant background noise.
Critical infrastructure is a different story, say, a large energy provider or an airport. There, state-funded hacker groups may have a motive to compromise the infrastructure. That is exactly the question threat modeling has to ask: how big is the incentive to attack you? For a small trades business, it’s a ransom of a few hundred dollars for an encrypted hard drive. For an airport, the stakes are of a completely different kind.
What the Cyber Resilience Act Requires
The Cyber Resilience Act aims to force manufacturers to think about security early. So far, that message is reaching the broad market only slowly. The first stage, the reporting obligations, has applied since September 11, 2026, and the full obligations follow from December 11, 2027.
The legal text itself is hard to read. The German BSI’s technical guideline on the Cyber Resilience Act is more practical, with examples and guidance on how to test compliance. Much of it is common sense.
Some of the obligations mean real effort: manufacturers have to inform users proactively about vulnerabilities, provide patches and, for mass-market products, offer automatic updates that customers can switch off.
From a consumer’s point of view, that is exactly what you want. Nobody wants cheap hardware running a five-year-old embedded Linux that never gets another update after you buy it. For a lot of consumer hardware, that is the state of things today.
Frequently Asked Questions
Why are security requirements harder to formulate than performance requirements?
For performance, there are established building blocks: the quality scenario with a precondition, context, trigger, outcome, and a metric. A stakeholder specifies a concrete number, such as one second in 99 percent of cases during normal operation. When it comes to security, many teams lack precisely these linguistic building blocks. The problem lies not in the complexity of the topic, but in the fact that security is discussed in overly abstract terms.
Is confidentiality always the most important protection goal?
No. For a public website or a professional profile, confidentiality is actually undesirable because the content is meant to reach as many people as possible. What matters there is integrity: no one should be able to modify the content without consent. Which protection goal applies depends on the specific asset. Without a specified asset, every security requirement lacks substance and is therefore unverifiable.
Can security objectives be combined arbitrarily?
No, security always involves a trade-off. In addition to confidentiality, integrity, and availability, there are other security objectives such as authenticity, non-repudiation, and anonymity. Anonymity and non-repudiation directly contradict each other: If you want to verifiably attribute actions to a person, you cannot simultaneously keep them anonymous. Such conflicts must be consciously resolved rather than attempting to meet all requirements at once.
Is a catalog like the OWASP ASVS sufficient as a basis for security requirements?
No. The ASVS is well-suited for audits and provides concrete guidelines, but it only works based on established requirements. It is all-encompassing and does not specify which parts are relevant to a given system. No one needs to seriously consider the cryptography chapter if there is no confidentiality-related data in the system. Which of the three compliance levels applies is also determined by the requirements.
Is a penetration test shortly before release sufficient?
No. A penetration test only verifies what has already been decided: You can’t test quality in. Before release is the most expensive time to discover a security flaw because the design decisions have already been made. After release, with real customer data, it becomes even more expensive. Incorporating security into architecture and design requires known requirements.
When should a team repeat its threat analysis?
Whenever the original basis for decision-making changes. Four typical triggers: new functionality that introduces new data into the system; major refactorings, after which security properties must be reevaluated; publicly disclosed attacks that raise the question, “Would that have worked on us?”; and new technologies such as AI components with attack vectors like prompt injection.
How can teams without security expertise get started with threat modeling?
Through card games with real rules. “Elevation of Privilege” by Adam Shostack, developed by the security team at Microsoft, is licensed under Creative Commons; OWASP offers a variant called Cornucopia, and Cumulus is available for cloud scenarios. The game is played similarly to a trick-taking game with a trump suit: Points are awarded when someone explains why the scenario on the card is relevant to their own system. Taking notes is sufficient as documentation.
Who is behind the vast majority of attack attempts?
Mostly opportunistic IT firms that scan systems en masse to see if they can make money from them. Some vulnerabilities they find are simply documented and resold, for example to groups that install ransomware. The situation is different for critical infrastructure such as energy providers or airports: in those cases, state-funded groups may have a motive. The question of the motive for an attack belongs in threat modeling.
