Scanner Output Severity Normalisation: A Practical Guide

Why scanner severities do not align by default

Scanner vendors design severity scales for their own product context, not for cross-tool consolidation. The scales differ in granularity, in the boundaries between bands, in whether they include an informational tier, and in how they treat exploitability versus theoretical impact. A finding that one tool labels High can land at Medium in another tool against the same underlying issue purely because the boundaries are drawn differently, not because the issue itself is different.

The structural reasons compound. Nessus assigns severity from a vulnerability database heuristic that weights known exploitability and CVE metadata; Burp Suite assigns severity from a runtime pattern match weighted by confidence; SARIF (used by Semgrep, CodeQL, and other SAST tools) uses a three-band system where error covers what most other scanners would split into Critical, High, and parts of Medium. SCA tools rely on the upstream CVE CVSS, which scores the dependency rather than your application is use of it. Network scanners assign severity per-service rather than per-asset, so the same misconfiguration on two ports of the same host produces two findings at two severities.

The defensible read is that scanner severity is a signal from the tool, not the answer to the prioritisation question. A consolidated findings record needs one workspace severity that translates the tool signals into a coherent decision basis, and that translation is a workspace policy decision rather than a passive inheritance from whichever scanner happened to fire first.^1,4,5,6

Severity scales across common scanners

The first input into a defensible normalisation policy is an inventory of the source severity scales the workspace ingests. The table below sets a starting reference for scanners common in internal security, AppSec, vulnerability management, and security engineering stacks. Teams tune the mapping to the asset classes the workspace covers and the risk appetite the leadership sets.

The table is a starting inventory, not the translation policy itself. The translation policy is the next step: each source severity needs a default workspace severity mapping, and each mapping needs the override rules the workspace operates under.^1,2,5,6,7,16

Designing the workspace severity translation table

A defensible translation table is short, opinionated, and audit-ready. It produces a default mapping at import, names the override conditions that can change the default, and routes both the default and the override events into the finding record so the audit chain reads cleanly.

• One canonical workspace scale. Pick five bands (Critical, High, Medium, Low, Info) or four (drop Info if the workspace does not track non-actionable findings as findings) and stick with the choice. Workspaces that mix four and five bands across teams produce inconsistent leadership trend charts.
• Per-scanner default mapping at import.Every supported scanner has a documented mapping from source severity to workspace severity. The mapping applies automatically at import; analysts do not pick the workspace severity manually for default cases.
• Named override conditions. The conditions that justify overriding the default are documented: reproducible exploit in test environment, reachability proven via code review, asset criticality higher than the scanner assumes, compensating control reducing exploitability. Each override condition is named in the policy and recorded on the finding when applied.
• Source severity preserved. The original scanner-emitted severity stays on the finding evidence section so the audit can read back the original signal without recovering it from the raw scanner export.
• Override actor and rationale recorded.Every override carries the user who applied it, the timestamp, the override condition that justified it, and a free-text rationale. Bare overrides (no rationale) are not acceptable under the policy.
• Version on the policy. The translation table carries a version, an effective date, and a change log so the audit reads against the policy that was in force at the time the finding was severity-assigned.

The policy is not a one-page table on a wiki. It is a workspace artefact that drives automation at import, drives analyst behaviour at triage, and drives audit defence at review. Programmes that hold the policy informally inherit the policy of whoever happened to triage the finding, and that informal policy does not survive team change.^8,9,10,15

Sample default mapping table

The mapping below is a starting reference for a workspace that uses five canonical bands and ingests output from Nessus, Burp Suite, SARIF SAST tools, and SCA tools. The workspace tunes the defaults based on asset class (internet-facing vs internal, production vs non-production), evidence requirements, and any compensating controls already in place.

The defaults are slightly pessimistic where the source signal is unreliable in context (SCA upstream CVSS, SAST style rules) and slightly more conservative where the source signal is strong (Nessus on internet-facing assets, Burp Suite High with Certain confidence). The policy is not the table; the policy is the table plus the override rationale, the named reviewer, and the audit trail the overrides leave.^1,7,13,14

CVSS 3.1, CVSS 4.0, and the transition window

CVSS 3.1 has been the default scoring methodology across NVD and most scanner vendors; CVSS 4.0 was released in late 2023 and is being adopted incrementally across the ecosystem. During the transition window, a workspace will receive a mix of CVSS 3.1 scores from some scanners, CVSS 4.0 scores from others, and an absence of either from tools that emit only vendor severity. The normalisation policy needs to handle the three states cleanly.

• Record the version that produced each score.A CVSS 7.5 from version 3.1 and a CVSS 7.5 from version 4.0 are not the same number; the metric weighting differs. Every CVSS value on the finding carries the version alongside it so the audit reads back the methodology.
• Record the vector, not just the score.The number is a hash of the vector. Without the vector string, the score is not reconstructable, and a future analyst cannot re-derive the severity if a metric assumption needs to change.
• Choose one workspace reporting score.Leadership trend charts and SLA assignments anchor to one score per finding. The workspace policy names which version is canonical (commonly CVSS 3.1 during the transition because it is comparable across the existing observation window) and treats the other version as evidence rather than as the canonical score.
• Plan the migration as a policy event.When the workspace moves canonical reporting to CVSS 4.0, the migration is a versioned policy change with an effective date. Findings before the date are reported on the prior score; findings after are reported on the new score. Mixing the two in the same trend chart is the failure mode that misreads scoring change as risk change.
• CVSS 4.0 base, threat, environmental, supplemental.The four-score model in CVSS 4.0 (CVSS-B, CVSS-BT, CVSS-BE, CVSS-BTE) needs an explicit policy choice about which score is canonical for workspace reporting. Most programmes anchor to CVSS-B with optional environmental adjustment for asset criticality; few programmes report the BTE score across the board.

The CVSS 4.0 vs CVSS 3.1 comparison covers the metric differences in detail, the CVSS calculator handles both vector formats for analyst-driven severity adjustments, and the severity recalibration drift research covers how the same finding re-scores across scanner generations when CVSS versions migrate, rule packs revise, and vendor severity scales change over time.^1,2,3,20

Resolving severity disagreement between scanners

Disagreement between scanners on the same underlying issue is the signal that drives normalisation; suppression of disagreement is the failure mode. The defensible resolution pattern treats disagreement as a triage prompt, not as an irritant to silence.

The unifying principle is that severity follows reproducible evidence. The triage page on scanner output deduplication covers the upstream discipline of recognising when two records describe the same issue, and the page on vulnerability scanner false positives covers the related discipline of identifying when a finding does not represent a real issue at all.^8,9,15

Severity, SLA assignment, and remediation cadence

Severity normalisation produces the input that SLA assignment consumes. A workspace that anchors SLA to source severity inherits inconsistent cadence across scanners; a workspace that anchors SLA to normalised severity produces a consistent remediation picture that auditors and remediation owners both read cleanly.

The SLAs are starting reasonable values, not regulatory requirements. PCI DSS sets a specific 30-day cadence on high-severity vulnerabilities in scope for the CDE; HIPAA, SOC 2, and ISO 27001 read SLA cadence through operating evidence rather than fixed numbers. The vulnerability SLA management workflow covers the operating discipline that turns severity into a remediation programme, and the vulnerability SLA policy template provides a starting policy structure.^9,10,11,12

How compliance frameworks read severity normalisation

Auditors do not read severity normalisation as a single control; they read it through adjacent controls that depend on consistent severity to operate. A programme that normalises severity well produces evidence that several controls read as operating; a programme that does not normalise leaves the same controls reading as partial.

• PCI DSS v4.0 Requirement 6.3.1 requires vulnerabilities to be identified, risk-ranked, and assigned a severity. The risk-ranking process is the audit-relevant artefact; a documented severity policy with override rationale satisfies the operating-effectiveness bar. PCI DSS 6.3.3 then requires patching critical and high-severity vulnerabilities within one month of release, which depends on the severity classification being defensible.¹²
• ISO 27001:2022 Annex A 8.8 (technical vulnerability management) treats vulnerability evaluation, including severity assignment, as a documented and repeatable control. The severity policy is read at audit alongside the operating evidence (findings with severity assigned through the policy, override events with rationale).¹⁰
• SOC 2 CC4.1 (monitoring activities) reads the severity model through the monitoring evidence: do the findings produced across the observation period reflect a consistent severity policy, or do they vary with the analyst on duty. CC7.1 (system monitoring) reads the trend of severity across the period as evidence the monitoring is operating.¹¹
• NIST SP 800-53 RA-5 (vulnerability monitoring and scanning) requires vulnerabilities to be analysed and remediated according to a risk-based approach. The severity policy is the artefact that operationalises the risk-based approach; a policy with override events produces the operating evidence the control reads as effective.⁹
• NIST SP 800-30 sets the underlying risk assessment model that severity normalisation maps into. A workspace severity policy that translates scanner output into a documented risk basis reads as aligned to the NIST risk assessment process rather than as a vendor-specific judgement.⁸

The shared pattern is that the severity classification is itself a control. Storage of scanner output is not the control; the workspace decision about what severity that output produces is the control. Programmes that store scanner output without normalising it satisfy the storage requirement and fail the risk-ranking requirement.

Operational checklist for defensible severity normalisation

For internal security, AppSec, and vulnerability management teams

Severity normalisation is the discipline that lets a multi-scanner programme produce a consolidated findings picture that survives leadership review and audit observation. Internal security teams, AppSec teams, vulnerability management teams, and security engineering teams operate the policy as a workspace artefact rather than as analyst preference, because preference does not survive team change.

• Anchor the severity scale to one workspace decision rather than to whichever scanner happened to import first.
• Document the default mapping per scanner; apply it automatically at import; require explicit override with rationale to change it.
• Preserve the source severity on the finding so audit can read back the original signal without recovering it from raw scanner exports.
• Resolve disagreement between scanners through reproducible evidence, not through averaging or majority.
• Anchor SLA assignment to workspace severity so remediation cadence is consistent across the scanner stack.
• Review the translation table at least annually and on scanner vendor scale changes.

For internal security teams, AppSec teams, vulnerability management teams, and security engineering teams, severity normalisation is the gate that turns raw scanner output into a defensible workspace risk picture. The severity calibration research covers how severity drifts over time across testers and tools, and the vulnerability prioritisation workflow covers how the normalised severity feeds into the prioritisation decision the programme actually operates.

How SecPortal supports severity normalisation

SecPortal anchors severity to a structured field on each finding, preserves the scanner-emitted evidence alongside it, and records every severity change as an activity event so the audit trail reads from the live engagement rather than from a reconstructed history.

Related scanner discipline

Severity normalisation sits between the upstream import and triage disciplines and the downstream remediation and reporting disciplines. The pages below cover the connected decisions.

• Scanner output deduplication covers the upstream discipline of recognising when two records describe the same underlying issue, which produces the canonical findings the normalisation policy then attaches a severity to.
• Vulnerability scanner false positives covers the parallel discipline of identifying when a scanner finding does not represent a real issue, which is distinct from downgrading the severity of a real finding.
• Scanner output formats covers what each scanner export carries (SARIF, Nessus XML, Burp XML, CSV) and how much severity context survives the import.
• Scanner evidence chain covers the seven evidence layers that hold the link from scan execution to closed finding, which the severity policy sits inside.
• Importing third-party scanner results covers the import workflow that produces the drafts the normalisation policy applies severity to.
• Scanner coverage and limits covers what each scanner class actually detects, which informs how much weight to place on a given scanner is severity assignment.
• Scanner finding tag and label taxonomy covers the parallel classification discipline that decides which structured category, impact dimension, asset class, exposure context, and remediation owner the canonical record carries alongside the normalised severity.

For the wider operating model the severity policy plugs into, the vulnerability prioritisation framework covers how severity combines with EPSS exploit likelihood, asset context, and SLA scheduling to drive remediation decisions, and the CVSS scoring guide covers the mechanics of the underlying scoring system.

Scope and limitations of this guide

Severity normalisation is a workspace policy, not a substitute for scanner-side calibration. A scanner that consistently emits the wrong severity for a class of issues is a tuning problem at the scanner; normalisation is the downstream discipline that turns the scanner output into a workspace decision. No translation table fixes a scanner that lacks coverage for an issue class, and no normalisation policy substitutes for the analyst judgement an override requires.

Severity claims that depend on whichever scanner happened to fire first almost always understate the prioritisation discipline. Severity claims that decompose into a documented mapping, named override conditions, recorded rationale, and a versioned policy are the claims that survive both the audit observation period and the team change.

Frequently Asked Questions

Sources

1. FIRST, CVSS v3.1 Specification Document
2. FIRST, CVSS v4.0 Specification Document
3. NIST, National Vulnerability Database (NVD) CVSS Calculator
4. OASIS, Static Analysis Results Interchange Format (SARIF) Version 2.1.0
5. Tenable, Nessus Vulnerability Severity Levels
6. PortSwigger, Burp Suite Issue Severity and Confidence
7. MITRE, Common Weakness Enumeration (CWE) Top 25
8. NIST, SP 800-30 Rev. 1 Guide for Conducting Risk Assessments
9. NIST, SP 800-53 Rev. 5 (RA-5 Vulnerability Monitoring and Scanning)
10. ISO/IEC, ISO 27001:2022 Annex A 8.8 Technical Vulnerability Management
11. AICPA, SOC 2 Trust Services Criteria CC4.1 Monitoring Activities
12. PCI Security Standards Council, PCI DSS v4.0 Requirement 6.3.1 Vulnerability Identification and Risk Ranking
13. FIRST, Exploit Prediction Scoring System (EPSS) Model
14. CISA, Known Exploited Vulnerabilities Catalog
15. OWASP, Risk Rating Methodology
16. CERT, Stakeholder-Specific Vulnerability Categorization (SSVC)
17. SecPortal, Findings Management Feature
18. SecPortal, Bulk Finding Import Feature
19. SecPortal, Activity Log Feature
20. SecPortal, CVSS 3.1 and 4.0 Calculator