In the previous lesson we documented each finding of the TechNova engagement and, in the SQLi template, we wrote "Severity: Critical | CVSS 9.8" with a promise: to justify it here. This is the moment. When a report gathers twenty, thirty, or fifty findings, TechNova cannot fix them all at once: it needs to know where to start. Risk classification answers that question with an objective yardstick, not with intuition or with whichever finding looked flashiest to you.

Here we develop in detail the industry-standard system for scoring technical severity, CVSS (Common Vulnerability Scoring System), in its 3.1 and 4.0 versions: what each metric measures, how to read a vector, how the score translates into a rating. But the lesson does not stop there, because technical severity is not the same as business risk. A CVSS 9.8 on an isolated test server may matter less, to TechNova, than a 6.5 on the payment gateway. You will learn to combine both views, the technical and the business one, into a real prioritization table. The concrete remediation of each finding is the next lesson (06-03); here we decide the order.

1. Technical severity versus business risk
2. What CVSS is and what it is for
3. The base metrics of CVSS v3.1
4. Reading and building a CVSS vector
5. From score to rating
6. CVSS v4.0: what changes
7. Temporal and environmental metrics
8. Business risk: likelihood times impact
9. Prioritization table for TechNova's findings
10. Alternatives: OWASP Risk Rating and DREAD
11. Common Mistakes and Tips
12. Exercises
13. Conclusion

Before getting into the mechanics, fix this distinction because it governs the whole lesson:

• Technical severity: how serious the vulnerability is in itself, regardless of where it sits. CVSS measures it. It is objective and comparable across organizations.
• Business risk: how much TechNova cares that this vulnerability gets exploited. It combines the likelihood of it happening with the impact on its specific business (revenue, data, reputation, compliance). It depends on context.

A professional pentester delivers both: CVSS gives authority and comparability ("this is a 9.8, it is not my opinion"); business risk gives relevance ("and on top of that it is in your store, which is where your revenue comes from"). Prioritizing by CVSS alone is a junior mistake; prioritizing by business intuition alone lacks rigor. They are used together.

CVSS is an open standard, maintained by FIRST, that assigns a vulnerability a numeric score from 0.0 to 10.0 based on its technical characteristics. Its value is that it is reproducible and comparable: two analysts who assess the same vulnerability with the same metrics get the same score, and that score means the same thing at TechNova as at any other company in the world.

CVSS is organized into three metric groups:

Most reports report the base score, and it is what you will see in CVE databases. The temporal and environmental metrics adjust that base to TechNova's reality.

The base group divides into exploitability (how easy the vulnerability is to abuse) and impact (what breaks if it is abused). These are the eight base metrics of v3.1:

The last three (C, I, A) are the classic CIA triad. The higher the impact on each and the easier the exploitation, the higher the score.

CVSS is communicated as a vector: a compact string that encodes each metric. Here is how TechNova's SQLi looks:

Read it metric by metric:

With these values, the official CVSS v3.1 calculator gives a base score of 9.8. There is no need to memorize the formula: you use the FIRST calculator. What matters is knowing how to justify each metric with the evidence from the test, why PR is None, why C/I/A are High, because that is where professional rigor lives.

The number from 0 to 10 translates into a qualitative rating, which is what a non-technical person understands. The official CVSS v3.1 scale:

Our SQLi, at 9.8, falls into Critical. That is why in the 06-01 template we wrote "Severity: Critical": it was not a subjective label, but the translation of the CVSS score. In the report both are shown, the number and the label, so that technical and business readers each understand it at their own level.

CVSS v4.0 (published by FIRST) refines the model to address criticism of v3.1, above all that almost everything ended up being "Critical". Main changes you should know about:

• New impact granularity: it separates the impact on the vulnerable system (VC/VI/VA) from the impact on subsequent systems (SC/SI/SA), replacing the old Scope with something more expressive.
• More nuanced User Interaction: it now distinguishes None / Passive / Active instead of just None/Required.
• The "Temporal" group is renamed "Threat" and focuses on exploit maturity.
• Score nomenclature: a v4.0 vector can be reported as CVSS-B (base only), CVSS-BT (base+threat), or CVSS-BTE (base+threat+environmental), making clear what was scored.

A v4.0 vector begins with CVSS:4.0/.... In practice, in 2026 both versions coexist; report with whichever your client or tool uses and always state the version, because an 8.0 in v3.1 is not exactly comparable to an 8.0 in v4.0.

The base score is "lab-grade". The other two dimensions bring it closer to reality:

• Temporal / threat: they adjust according to the current state of the threat. Is there a reliable public exploit? Is there a patch available? A vulnerability with a working exploit circulating is more dangerous today than the same one with no known exploit. These metrics lower or maintain the score, they never raise it above the base.
• Environmental: they adjust according to your infrastructure. Here TechNova can say "in my case the confidentiality of this asset is maximal because it holds payment data" (raising the impact), or "this system is isolated and not exposed" (lowering it). It is the natural bridge to the business risk of section 8.

In pentest reports the base is usually reported as a common reference, and the environmental is used to argue the real prioritization to the client.

Here we make the leap from the technical to what keeps TechNova's leadership up at night. Risk is classically modeled as:

• Likelihood: how easy and attractive it is for this to actually get exploited. The exploitability side of CVSS (AV, AC, PR, UI) feeds this part, plus context: is it exposed to the Internet? is there a public exploit? is it an appealing target?
• Business impact: what TechNova loses if it happens. Not in abstract CIA terms, but concrete ones: lost revenue, leaked customer data, non-compliance fines, reputational damage, the store going down.

This is visualized with the classic risk matrix:

TechNova's SQLi is high likelihood (Internet-exposed, unauthenticated, trivial to exploit) and high impact (the store's entire database, which is the heart of the business): critical risk. It matches its CVSS, and that is why it tops the list.

We gather several findings from the engagement and prioritize them by combining CVSS and business risk. This table is the heart of the report for the decision-maker:

Notice the professional nuance: TN-014 has a lower CVSS than TN-001 but shares high priority because of its likelihood and its business impact; TN-030, though a real finding, is low priority and should not consume resources ahead of the critical ones. That reading is what turns a list of scores into a plan.

CVSS is the de facto standard, but it is worth knowing other frameworks you will see mentioned:

• OWASP Risk Rating Methodology: it calculates risk as Likelihood × Impact, but breaks each factor down with criteria designed for web applications (attacker skill, motive, opportunity, group size; technical impact and business impact). Its strength is that it integrates business impact explicitly.
• DREAD: an older model (Damage, Reproducibility, Exploitability, Affected users, Discoverability) that scores each factor and averages them. It is simple but subjective; today it is rarely used formally.

In a professional report the usual approach is CVSS for technical severity plus a layer of business risk in the OWASP style. Mention them to give context, but keep CVSS as the backbone for its comparability.

• Prioritizing by CVSS alone. A 9.8 on an isolated asset may yield to a 6.5 on the payment gateway. Always combine technical severity and business risk.
• Inflating the scores. Marking everything "Critical" to scare people destroys your credibility and leaves the client unable to tell what is truly urgent. Justify each metric with evidence.
• Not stating the CVSS version. An 8.0 in v3.1 is not equivalent to an 8.0 in v4.0. Always specify CVSS:3.1/... or CVSS:4.0/....
• Confusing vulnerability with risk. The vulnerability is technical; the risk depends on TechNova's context. The same flaw carries different risk on different assets.
• Forgetting business impact. Leadership does not prioritize by "C:H/I:H"; it prioritizes by "every customer's data gets leaked". Translate.
• Tip: learn to justify the vector, not memorize the formula. Use FIRST's official calculator and spend your effort defending why each metric is worth what it is worth.

Exercise 1. During the test you confirm a stored XSS in the store's review form: any visitor who views the review executes the attacker's script (session theft). It requires no privileges, is exploited over the network, but it does need the victim to load the page. Build the base CVSS v3.1 vector, reasoning through each metric (AV, AC, PR, UI, S, C, I, A).

Exercise 2. You have two findings: (A) a SQLi with CVSS 9.8 on a staging server with no real data and not accessible from the Internet; (B) an access-control flaw with CVSS 6.5 on the production payment gateway. Argue which one TechNova prioritizes and why, using the technical severity vs. business risk distinction.

Exercise 3. Explain, for the executive summary, what it means that TechNova's SQLi has "CVSS 9.8, critical risk" without using technical jargon, in two or three sentences a CFO would understand.

Solution 1. Reasoned vector for the stored XSS:

• AV:N — it is exploited through the web (network).
• AC:L — no special conditions are needed.
• PR:N — the attacker posts the review without needing privileges (or with a basic account; here we assume None since it is a public review).
• UI:R — Required: the victim must load the review page for the script to run.
• S:C — Changed: the script runs in the victim's browser, a component distinct from the vulnerable server (the impact crosses the scope).
• C:L / I:L / A:N — typical of XSS: session/data theft is limited (C:L), possible limited manipulation of the content viewed (I:L), no direct impact on availability (A:N).

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N (approx. 6.1, Medium). What matters is the reasoning, not nailing the decimal.

Solution 2. TechNova prioritizes (B), the flaw in the payment gateway, despite its lower CVSS. Reason: the technical severity of (A) is higher (9.8), but its business risk is low because it is in staging, with no real data and no Internet exposure: the likelihood of real exploitation and the impact are minimal. (B) has a lower CVSS but is in production, on the payment gateway: high likelihood of being a target, and direct impact on revenue, card data, and compliance. The risk = likelihood × impact is far higher in (B). That said: (A) must be fixed anyway (and watch that this staging does not end up exposed), but (B) goes first.

Solution 3. Example for leadership: "Our online store's catalog has a flaw that lets anyone on the Internet, with no password, access the entire database: customer data, orders, and passwords. It is the highest severity level there is and could be exploited with very little effort, so it must be fixed urgently, ahead of anything else."

We have learned to prioritize, which is what turns a list of findings into an action plan. We mastered CVSS as the technical-severity standard: its base metrics (AV, AC, PR, UI, Scope, and the CIA triad), how to read and build a vector like CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, how the score translates into a rating (from Low to Critical), what CVSS v4.0 adds, and what the temporal/threat and environmental metrics are for. And, above all, we learned not to confuse technical severity with business risk: the likelihood × impact matrix and TechNova's prioritization table showed why a lower-CVSS finding sometimes goes first. We also mentioned OWASP Risk Rating and DREAD as alternatives.

We now have the findings documented (06-01) and prioritized by risk (06-02). We know what is wrong and in what order to tackle it. What is missing is what truly reduces TechNova's risk: saying how to fix it, in an actionable, realistic, and prioritized way. That is the next lesson, 06-03: Remediation Recommendations, where we turn every priority in this table into a roadmap TechNova can execute.