Severity Calibration for Pentest Findings: From Scanner Output to Defensible Risk

Why scanner severity and pentest severity disagree

A vulnerability scanner assigns severity from a static rule: a generic CVSS base score, a vendor risk table, or a CVE lookup. The scanner has no view of asset criticality, network position, compensating controls, or realistic exploit chain in the environment under test. Pentest severity has to incorporate all of these. The disagreement is structural, not a bug.

Three patterns show up repeatedly:

• Scanner High, calibrated Medium. A widely flagged CVE on a host that is segmented behind a tested boundary, with no sensitive data on the host and no realistic exploit path. The technical fingerprint is real; the operational severity is lower.
• Scanner Medium, calibrated Critical. A header misconfiguration that becomes catastrophic when chained with a logic flaw the scanner could not see (cookie scope plus IDOR, CORS plus an authenticated endpoint that returns adjacent tenant data). Calibration captures the chain; the scanner cannot.
• Scanner Informational, calibrated Critical. Default credentials on an internal interface that scanners flag as Informational because the asset returned a 200 from a tested path, not a successful login. The tester confirms the login. The severity is whatever the credentialled access opens.

The point is not that scanners are wrong. They are doing the job they are designed for: deterministic, replayable triage at machine speed. Calibration is the human layer that contextualises the output. For the mechanics of using scanner data in a pentest workflow, see the operational guide on authenticated versus unauthenticated scanning and the related guide on findings deduplication.

The four-layer calibration model

A defensible severity assignment is built from four distinct layers, each producing evidence that the calibration trail can reference. Skip a layer and the rating becomes opinion; carry all four and the rating becomes auditable.

The calibrated severity is the output of all four layers, not the raw output of any single one. A finding with CVSS base 9.8 (Critical) and a verified compensating control that fully blocks the attack vector might calibrate to Medium. A finding with CVSS base 5.4 (Medium) listed in CISA KEV against a regulated asset might calibrate to Critical. The discipline is in the trail, not in the headline number.

CVSS as anchor: why it stays in the report

The CVSS specification has known limitations and has been criticised across the security industry for over a decade. Despite that, CVSS remains in nearly every pentest report for three operational reasons.

• Procurement and audit expectation. PCI DSS, NIST guidance, and most enterprise vulnerability management programmes reference CVSS by name.^8,10 Removing CVSS from a report breaks compatibility with the audit cycle the report supports.
• Vector reproducibility. A CVSS vector string is a compact, machine-readable representation of the calibration inputs. A reviewer can replay the score. An alternative rubric typically cannot match that property without significant tooling investment.
• Cross-engagement comparability. A buyer comparing two pentest reports needs a common scale. CVSS is the lowest common denominator that lets them compare findings from different consultancies without normalising rubrics.

The honest position is that CVSS is a technical anchor, not a complete severity. Treat it accordingly. Score the vector with discipline (use a calculator, record the string, document the rationale for each metric). Use the CVSS 3.1 and 4.0 calculator for vector capture and verification, and read the CVSS scoring explainer for metric-by-metric guidance. Then layer environmental and contextual factors on top.

The mistake is treating CVSS base score as the final severity. The base score answers the question "how severe is this finding in the abstract". The pentest report is supposed to answer "how severe is this finding for this client". Those are different questions.

SSVC: the decision layer above CVSS

The Stakeholder-Specific Vulnerability Categorization framework, published by Carnegie Mellon SEI and adopted by CISA, sits above CVSS as a decision-action mapping rather than a severity scale.^3,4 SSVC takes the technical inputs (exploitation status, technical impact, exposure, mission impact) and produces a recommended action: track, attend, act, or immediate.

For pentest reporting, SSVC adds two specific properties CVSS lacks:

• Action orientation. A reader of an SSVC node knows what to do (drop into the queue, attend within a week, act now). A CVSS score requires the reader to translate severity into action through a separate policy.
• Stakeholder framing. SSVC supports different decision trees for suppliers, deployers, and coordinators, which maps cleanly onto the supplier-deployer split in a pentest engagement (the consultancy is the supplier; the client is the deployer).

The most defensible reports present both: a CVSS vector for technical comparability, and an SSVC node for the action call. The two layers do not conflict; they answer different questions for different readers in the same report. An executive summary uses the SSVC action language. A technical appendix uses the CVSS vector. The remediation team uses both.

For the standalone walk-through of the four standard SSVC decision points, the three role-specific trees (Supplier, Deployer, Coordinator), the CISA Tier-1 simplified tree, the CISA Decider tool, and a four-week internal-team rollout wiring SSVC outcomes into the find-track-fix-verify lifecycle, see the SSVC stakeholder-specific vulnerability categorization explainer. For deeper context on prioritisation framing, see the vulnerability prioritisation framework and the operational article on automating findings management.

EPSS and KEV: external exploitability evidence

Two public datasets do most of the work for the exploitability layer of the calibration model: the FIRST Exploit Prediction Scoring System (EPSS) and the CISA Known Exploited Vulnerabilities (KEV) catalog.^5,6

• EPSS produces a probability between 0 and 1 that a given CVE will be exploited in the next 30 days, updated daily. It is most useful for sorting a long backlog of medium-severity findings: a 5.4 CVSS base score with EPSS 0.92 deserves more urgent attention than a 5.4 with EPSS 0.01.
• KEV is a binary signal: a CVE is either on the list because CISA has evidence of in-the-wild exploitation, or it is not. KEV inclusion is a direct trigger to escalate the SSVC decision call, often from "act" to "immediate".

Neither dataset replaces CVSS or local context. Both belong in the calibration trail when relevant. A pentest finding that maps to a known CVE should record the EPSS score at the time of the assessment and note KEV status if applicable. Findings with no CVE mapping (custom application logic, unique misconfigurations) need a defensible internal exploitability narrative instead, evidenced by the proof-of-concept used during testing.

Environmental metrics: where calibration earns its keep

The CVSS environmental metric group is the part of the specification most often ignored and most often valuable.¹ Environmental metrics adjust the base score for the specific deployment under test: confidentiality requirement, integrity requirement, availability requirement, and modified base metrics that capture compensating controls or restrictive deployment choices.

Three patterns produce most of the meaningful environmental adjustments:

• CIA requirement uplift. A finding on an asset that processes regulated data (PCI cardholder data, GDPR special category data, HIPAA PHI) takes a confidentiality requirement of High, which can lift the calibrated severity above the base.
• Modified attack vector. A finding that the scanner reports as Network attack vector but that the tested asset only exposes on an internal management interface drops to Adjacent or Local, often dropping the severity by a band.
• Modified attack complexity. A finding that requires a confirmed privileged precondition (authenticated session, supply-chain compromise, prior account takeover) raises complexity and often drops the calibrated severity below the base.

Each adjustment must cite evidence the client can verify. Environmental adjustments without evidence are indistinguishable from severity inflation or deflation, and they are the most common reason a pentest finding gets reopened by an internal stakeholder. The reverse is also true: an environmental adjustment that holds up in a remediation meeting is the evidence that the consultancy ran a calibrated assessment, not a scanner re-print.

OWASP Risk Rating: the qualitative cross-check

The OWASP Risk Rating Methodology produces a likelihood-by-impact matrix using qualitative inputs (skill level required, motive, opportunity, population size, ease of discovery, awareness, intrusion detection, and the four impact dimensions: loss of confidentiality, integrity, availability, and accountability).⁹ It is most useful as a qualitative cross-check on a CVSS-derived severity rather than as a primary scoring system.

Two specific uses earn its place in the calibration trail:

• Sanity-checking the CVSS output. If CVSS calibrates a finding to High but the OWASP matrix puts it firmly in Low (low likelihood, low impact across all four dimensions), the disagreement signals a calibration error to investigate, often in the environmental metrics.
• Communicating to non-technical stakeholders. The OWASP factor language (skill level, motive, awareness) translates to executive audiences more naturally than CVSS metric names, and pairs well with an SSVC action call in an executive summary.

OWASP risk rating is not a replacement for CVSS in a defensible report. It is a useful second axis when the CVSS output looks suspicious or when the audience needs a qualitative narrative.

The calibration trail: what to record per finding

A finding is calibrated when the report could be handed to a peer-review tester, an auditor, or a client engineer and each could replay the severity assignment from the artefacts attached. The minimum trail covers eight fields per finding:

1. CVSS vector string (3.1 or 4.0), with each metric documented.^1,2
2. Calibrated CVSS environmental score with rationale per modified metric.
3. SSVC node (track, attend, act, immediate) with the decision-tree path documented.^3,4
4. Exploitability evidence: EPSS score (if CVE-mapped), KEV listing status, internal proof-of-concept reference.^5,6
5. Asset criticality as agreed at scoping (production, regulated, internet-facing, etc.).
6. Compensating controls verified during testing, with evidence.
7. Final severity label (Critical, High, Medium, Low, Informational) and the calibration delta from the CVSS base, where they differ.
8. Reviewer attestation: the second tester or QA lead who validated the calibration.

This list is not academic. It is the dataset that determines whether a finding survives a remediation meeting, an audit walk-through, or a procurement review. Reports that carry the trail defend themselves. Reports that omit it lean on tester seniority, which is a fragile foundation when the senior tester is not in the room.

Where calibration breaks at engagement scale

Calibration discipline is straightforward on a single finding by a single tester. It breaks under three specific operational pressures.

• Tester-to-tester drift. Two testers on the same engagement can score the same finding differently because they applied different environmental judgments. Without a calibration framework as the arbiter, the disagreement becomes a seniority call rather than an evidence call.
• Engagement-to-engagement drift. A consultancy with no central calibration discipline produces inconsistent severity ratings across engagements, which is the most common source of client trust failures: the client sees a 7.5 on one report and a 6.2 on the next for what looks like the same finding, and asks the obvious question.
• Scanner-to-tester drift. When scanner output is imported into a report without re-scoring, the report inherits the scanner severity verbatim. The result is a hybrid document that disagrees with itself: the manually tested findings are calibrated, the imported findings are not.

All three breakages are operational, not methodological. They are solved by treating the calibration trail as a deliverable in its own right, not a side artefact, and by making the calibration tooling part of the engagement workflow rather than a separate document. For the broader operational context, see the security workflow orchestration research and the analysis of the pentest delivery gap.

A practical calibration checklist for testing teams

For consultancies and internal teams operationalising calibration as a discipline, a short checklist reliably surfaces the most common failure modes.

• Capture CVSS vectors at finding creation. No finding leaves draft state without a vector. Use the CVSS calculator for vector capture and verification.
• Record environmental adjustments as evidence, not opinion. Each modified metric cites the artefact (screenshot, config, diagram, control evidence) that justifies it.
• Add SSVC node alongside CVSS for findings above Medium. The action call is what remediation teams act on; surface it explicitly.
• Map CVE-linked findings to EPSS and KEV at scoring time, not at report time. Exploitability data drifts; capture it during testing.
• Require a peer reviewer attestation on every finding above Medium. The cost is low; the calibration consistency gain is large.
• Treat scanner-imported findings as un-calibrated until reviewed. Re-score before they enter the client-visible report. Do not let scanner severities pass through verbatim.
• Publish the calibration framework on the engagement workspace so clients can see the methodology before they read the findings.
• Carry calibration history across retests. A finding closed during retest should preserve the original calibration trail, not overwrite it.

What buyers should ask about severity in procurement

Severity calibration is one of the cleanest signals a buyer can use to compare consultancies before signing. The questions below get to the substance without requiring sample reports:

• CVSS version and capture method: which version is used, and is a vector string recorded with every finding?
• Environmental adjustment policy: when and how are environmental metrics applied, and what evidence is required per adjustment?
• SSVC adoption: is a stakeholder action recorded alongside CVSS, and does the report include both?
• Exploitability evidence: are EPSS and KEV captured, and how are findings without CVE mappings handled?
• Peer review: is severity validated by a second tester before report delivery?
• Drift control: what mechanism prevents tester-to-tester and engagement-to-engagement severity drift?
• Scanner integration policy: are scanner-imported findings re-calibrated before they appear in the report, or do they inherit scanner severities?

Consultancies that answer these questions in writing usually demonstrate calibration discipline. Consultancies that answer with general assurances usually do not. For broader procurement context, see the research on pentest pricing models and the practical guides for choosing a security testing provider and writing a pentest report.

How SecPortal supports calibration discipline

Calibration is the testing team's job. The platform's job is to make the discipline reproducible at engagement scale. SecPortal supports calibration in four specific ways, each anchored to verified product capability:

• CVSS 3.1 and 4.0 vector capture per finding. Every finding records the vector string alongside the calculated score, surfaced in the report and the portal.
• Template library with pre-set vectors. The 300+ template starting points carry recommended baseline vectors so testers calibrate from a consistent anchor rather than a blank score.
• AI-assisted reports that present calibrated severity with evidence. The report drafts integrate severity, evidence, and remediation guidance in a single artefact rather than three.
• Calibration trail preserved across retests. Original severity, calibration rationale, and final retest outcome are kept in a single audit-friendly history per finding.

The persona pages for cybersecurity firms, security consultants, and internal security teams map this delivery model to different organisational shapes. The use-case page on vulnerability assessment and the feature page on findings management cover the operational mechanics in detail.

Conclusion

Severity is the most consequential single field in a pentest report and the one most often left to ad hoc judgment. Calibrating it well is not about replacing CVSS or adopting a new rubric; it is about treating severity as a composite of four layers (technical baseline, environmental adjustment, exploitability evidence, and stakeholder context), evidencing each layer, and preserving the trail in a form a peer reviewer or an auditor can replay.

Consultancies that calibrate well produce reports that defend themselves in any room. Buyers who ask about calibration discipline get cleaner comparisons between competing quotes than any pricing-page line item can give them. The discipline is operationally cheap once it is part of the engagement workflow, and it is the single largest determinant of whether a finding is fixed this sprint or quietly reclassified next quarter.

Frequently Asked Questions

Sources

1. FIRST.org, Common Vulnerability Scoring System v3.1: Specification Document
2. FIRST.org, Common Vulnerability Scoring System v4.0: Specification Document
3. Carnegie Mellon SEI, Stakeholder-Specific Vulnerability Categorization (SSVC)
4. CISA, Stakeholder-Specific Vulnerability Categorization Guide
5. CISA, Known Exploited Vulnerabilities Catalog
6. FIRST.org, Exploit Prediction Scoring System (EPSS)
7. NIST, SP 800-30 Rev. 1: Guide for Conducting Risk Assessments
8. NIST, SP 800-115: Technical Guide to Information Security Testing and Assessment
9. OWASP, Risk Rating Methodology
10. PCI Security Standards Council, PCI DSS v4.0.1
11. UK National Cyber Security Centre, Vulnerability Management Guidance
12. SecPortal, Findings Management Feature
13. SecPortal, AI Reports Feature
14. SecPortal, CVSS Calculator