Penetration Testing Severity Levels and Risk Rating Matrix

Penetration testing findings are usually rated on five severity levels: critical, high, medium, low and informational. The first four follow FIRST’s CVSS qualitative ratings (critical 9.0 to 10.0, high 7.0 to 8.9, medium 4.0 to 6.9 and low 0.1 to 3.9), and informational covers observations with nothing to exploit. Severity describes the weakness; risk adds how likely it is to be used against this client and what it would cost them, and a good report shows both.

The five levels in one table

The scores in brackets are CVSS 4.0 base scores (CVSS-B), each calculated from these vectors. Yours will differ with what you actually observed, which is the reason to publish the vector rather than the number alone.

Critical  9.3  CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
  High      7.1  CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
  Medium    5.1  CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
  Low       2.3  CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N

Each level should also carry a target time to fix, agreed with the client before testing. The figures, and the frameworks behind them, are in vulnerability remediation timelines.

Severity is not risk

Severity describes the weakness: how easy it is to exploit and what it gives an attacker, the same for every organisation that has it. Risk adds the organisation: how likely it is that somebody will use this weakness against this client, and what that would cost them. FIRST says so directly in the CVSS 4.0 user guide: the base score measures severity, not risk, and should not be used alone to assess risk.

A report needs both, and keeping them apart is what makes it defensible. The severity is the part another tester can check. The risk is the part that answers the client’s real question, "is this urgent for us?", and it depends on facts the client knows better than you: what the data is worth, who can reach the system, what else protects it.

CVSS 4.0 gives you two ways to carry that context without leaving the scale:

• Threat metrics. Exploit maturity (E) records whether attacks are known to be happening. Left unset, CVSS 4.0 assumes the worst, so threat metrics can only lower a score. The unauthenticated SQL injection above is 9.3 as a base score, 8.9 with a published proof of concept (E:P) and 8.1 with no known exploit (E:U). Be careful with bespoke findings: a flaw in a client’s own code has no public exploit by definition, so it is always E:U, and threat metrics would lower every one of them. Keep them for known vulnerabilities in third-party software, and publish CVSS-B for the rest.
• Environmental metrics. Security requirements (CR, IR, AR) and modified base metrics describe this client’s system. The customer-records finding is 7.1 as a base score. If the records are of low value to this client, a confidentiality requirement of medium or low (CR:M or CR:L) brings it to 5.7, Medium.

Whichever you use, publish the base score too, and label every score with FIRST’s nomenclature: CVSS-B for base only, CVSS-BT with threat metrics, CVSS-BE with environmental metrics, CVSS-BTE with both. A reader then knows what a number includes, and the base score stays comparable across clients.

Our view: adjust for context when the client has given you facts, such as how the data is classified or who can reach the system, and never because a lower number would be more comfortable. A client deciding to live with a weakness changes its status, not its severity; when a client accepts the risk instead of fixing it covers how to record that.

Mapping CVSS 4.0 to your levels

That is the qualitative scale in FIRST’s CVSS 4.0 specification. The bands are the same in CVSS 3.1, so a firm moving between versions keeps its scale.

The simplest mapping is the right one: your four scored levels take FIRST’s bands exactly, and Informational sits outside the scale for findings with nothing to score. A firm that invents its own bands, critical from 8.5 for example, produces reports in which every rating needs explaining, and a client who checks one score against FIRST’s calculator will wonder what else was adjusted.

Allow overrides, but make them expensive. One level at most, with a written reason in the finding, checked in QA. A finding two levels away from its score has the wrong vector, not an unusual context.

Moving from 3.1 to 4.0 moves some findings across a band, so re-score rather than convert. The same four findings, scored in both versions:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H   9.8
  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N   6.5
  CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N   5.4
  CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N   3.1

The customer-records finding is the one to notice: the same weakness is Medium in a 3.1 report and High in a 4.0 report. If a client compares this year’s report with last year’s, say in the methodology which version you used and why a rating moved, before they ask. More worked vectors are in common findings scored in CVSS 4.0.

A likelihood and impact matrix

CVSS fits software and configuration weaknesses well and other findings badly. A weak password policy, a missing process, a door that tailgating defeats, a cloud account nobody owns: you can force a vector onto these, but the number will mean little. For those, a likelihood and impact matrix gives a rating a client can follow. The level definitions below are ours; the three-by-three grid that combines them comes from the OWASP Risk Rating Methodology, and its five outcomes line up with the five severity levels.

Read along the row: a weakness that is highly likely to be exploited with high impact is Critical; an unlikely one with low impact is Informational. The grid is OWASP’s, which calls the bottom-left cell "Note". Use it for findings CVSS does not fit, or to state the client-specific risk beside a CVSS severity, and say in the report which method produced which rating.

What informational is for

Informational findings are the most abused level in pentest reports. Used well, they record things a client should know that are not vulnerabilities. Used badly, they pad a report with tool output nobody asked for.

• Give every informational finding a reason to exist: what the client should do with it, or why it matters to the next test.
• Do not score it. A CVSS vector with no impact scores 0.0, None, which tells the reader nothing.
• Keep informational findings out of the remediation timelines and out of the executive summary’s count of things to fix.
• Promote it when it stops being informational. A version banner is informational; a banner showing a release with a known exploitable vulnerability is a finding about that vulnerability, rated on its own.
• Use it for positive results. "Multi-factor authentication was enforced on every administrative interface tested" is evidence, and it tells the reader where the test looked.

The rationale in the finding

Every finding should carry a sentence or two explaining the metrics a reader could dispute and any adjustment for context. It is the cheapest insurance in the report: a finding that arrives at Medium with its reasoning attached is usually accepted, and where it is not, the argument is about something specific. The penetration test report template gives it a row of its own. For the deprecated TLS finding above, it reads:

Rating rationale: Reachable from the internet (AV:N) without an account
  (PR:N). The attacker must be on the network path between a user and the
  service (AT:P) while that user is using it (UI:P). At most, small amounts
  of protected data are exposed (VC:L). No adjustment for context.

A useful test in review: could a competent reader reconstruct the vector from the description alone? If not, the description or the vector is wrong. The errors that most often make a score arguable are in the CVSS mistakes that make a pentest report arguable.

Consistency across testers

Two testers scoring the same weakness differently is the quickest way to lose a client’s trust in your ratings. Consistency comes from a handful of habits rather than a longer policy.

• House rules, written down. A page of decisions your firm has made: how you score on-path attacks, when stored cross-site scripting is High, what is always Informational. Add to it every time a scoring argument is settled.
• Library defaults. Each common finding in your library carries a default vector and a note on when to change it. Testers start from the default and record why they moved.
• Vector first. Score before writing. A vector chosen after the prose tends to be chosen to fit it.
• Calibration. Once a quarter, give every tester the same five anonymised findings from past reports and compare their vectors. The disagreements show where the house rules are missing.
• QA on the vector. The reviewer checks the vector against the description and the evidence, not only the wording.
• Calculated scores. Never type a score. Calculate it from the vector, so the number and the vector cannot disagree.

The house rules page tends to start with the same few questions. These are the answers we would write down:

In Pental, the firm chooses CVSS 3.1 or CVSS 4.0, each finding’s score is calculated from its vector, and common findings come from a findings Library the team reuses. The rest is on the platform page.