This article takes the risk statements from the previous one and turns them into a ranked list you can act on. Each risk gets a score: exposure = likelihood × impact. The result is a prioritized table with traceable rationale, and explicit decisions about what not to invest in.
At the end of the process described in the previous article you have a list of explicit risk statements, each with a quantified impact estimate. What you don't yet have is a ranking, and without one you're still making decisions by instinct: whoever is loudest in the room, or whatever risk feels most dramatic, gets the attention.
Why ranking matters
We don't do health checkups every month. Not because health doesn't matter, but because the return drops: if last month's checkup found nothing, the odds of catching something new this month are low. The cost of the next checkup exceeds what it's likely to find. That's diminishing returns.
Same with testing. Whether you're starting from zero or already have a suite, the question is the same: which risks get investment first, and when is enough enough? You can't test everything. You need to know which risks matter most, invest there first, and have a reason for where you stop.
Without a ranking, that decision gets made by whoever argues the hardest.
Exposure: likelihood × impact
To rank risks, you need a number to compare them by. The simplest one that works: exposure = likelihood × impact, both scored 0 to 10. Multiply, and you have a single number you can sort by.
Likelihood is how often you expect this to actually happen. If it's already happening every sprint, that's a 9. If it's rare and you have controls in place, that's a 2. I'd suggest to use any information you can find: incident history, expert gut feel, past experience with similar systems.
Impact is always financial in the end, but the path to the money differs. In SaaS it's revenue loss. In safety-critical it's lawsuits and liability. In regulated industries it's fines and legal exposure. The question to ask your stakeholders: what does failure actually cost us here?
A concrete walkthrough
Here's how this works with two concrete risks.
Take an engineer's fear like "codebase too complex". You gathered data and converted this fear to the risk statement: "If the codebase becomes too complex, then new features take 3x longer to implement, resulting in delayed releases and $200K in contract penalties". Likelihood: this is already happening every sprint, score 9. Impact: $200K in contract penalties, score 8. Exposure: 72.
Now take the fear "security keeps me up at night" from the previous article: "If user input is not properly sanitized, then SQL injection attacks may occur, resulting in a data breach and $2M+ in fines and churn". Likelihood: rare, some controls already in place, score 2. Impact: $2M+, score 10. Exposure: 20.
Code complexity: 72. Security vulnerability: 20, a 3.5× difference.
When I first saw a result like this, I was amazed: the chronic risk outranks the scary, catastrophic one. But the managers agreed, even though before they had been dismissing the engineers' complaints about code complexity for months.
Building the full ranked list
Once you've scored every risk from your list, you end up with a table you can sort by exposure:
| Risk | Exposure |
|---|---|
| Code complexity | 72 |
| Payment regression | 56 |
| Performance degradation | 45 |
| Security vulnerability | 20 |
One thing I've learned: don't get into "7.2 vs 7.4" debates. The goal isn't precise measurement, it's a consistent ranking with a defensible rationale. Small score differences rarely matter, what matters is that you can explain why something is ranked where it is, and revisit it when conditions change.
One more dimension: lifecycle stage
This ranking isn't static, because priorities shift as a product matures. In an early prototype, functional suitability and usability dominate: the product needs to work and be usable before anything else. In production, reliability, security, and performance efficiency all rise in importance.
This means the same risk list can produce different rankings at different stages. That's not inconsistency, it's the model working correctly. I'd recommend revisiting your rankings whenever the lifecycle stage changes, or whenever there's a significant shift in usage, architecture, or context.
Not everything gets testing
Some risks won't justify additional investment, and that's a decision, not an oversight.
I find it helpful to have thresholds ready when you're looking at the ranked list:
- Unacceptable (exposure > 50): must reduce through controls and testing
- Acceptable with controls (exposure 20–50): can proceed if adequate controls are in place
- Acceptable (exposure < 20): no additional investment needed
In our example, the security vulnerability scores 20, right on the boundary. In a regulated context with lower thresholds, that might require explicit sign-off. In a commercial SaaS context, it might be documented as acceptable with existing controls and reviewed quarterly.
The important thing is that "we're choosing not to invest here" is a conscious decision, not something that happened by default. In my experience, documenting the rationale, assigning an owner, and setting a review date makes the difference between a deliberate acceptance and a forgotten risk.
What you have at the end
At this point you have a prioritized list of risks, ranked by exposure with explicit rationale, and documented acceptance decisions for anything you're not acting on now.
In the next article, we'll take this ranked list and map risks to quality characteristics, then decide where, how, and how much to test. That's where the portfolio gets built.
The full research behind this series is at BeyondQuality.
