A CVSS base score of 9.8 tells a security engineer that a vulnerability is remotely exploitable, requires no privileges, and needs no user interaction. It tells a CFO nothing. Put “CVSS 9.8” in front of a budget committee and you will get silence, followed by a question you cannot answer well: “so what happens to us if this gets exploited.” CVSS was built to compare vulnerabilities to each other, not to compare a vulnerability to a business outcome. Treating it as if it were a risk score is the single most common reason security teams lose credibility with leadership.
Why a 9.8 Means Nothing to a CFO and What Does
CVSS measures technical severity: attack vector, complexity, privileges required, scope, and impact to confidentiality, integrity, and availability of the affected component. None of those inputs know what the component does for your organization. A 9.8 on an internal build server that never touches customer data is a different conversation than a 9.8 on the API gateway that processes card transactions, even though the score is identical.
Executives think in four currencies: money, time, obligation, and reputation. A translation layer has to convert technical severity into at least one of those. The conversion needs three inputs that CVSS does not carry:
- Asset criticality: what business process, revenue stream, or data class the affected system supports.
- Exposure: whether the vulnerable component is internet facing, reachable only from a trusted segment, or air gapped.
- Compensating controls: whether a WAF rule, network ACL, or authentication layer already blocks the practical attack path even though the CVSS vector says it should not.
A useful shorthand for a first pass: multiply CVSS base score by an asset criticality weight (1 to 3) and divide by an exposure discount (1 for internet facing, 2 for internal segment, 3 for isolated). It is not a certified risk formula, but it moves a conversation from “how scary is the number” to “how scary is the number for us,” which is the only question that matters to a budget owner.
Mapping Technical Findings to Business Processes, Revenue Lines, and Data Classes
Before you can translate a finding, you need an asset inventory that already answers “what does this system do for the business,” not just “what is its hostname and IP.” Most vulnerability programs fail here first: the scanner returns a hostname, and nobody has recorded that the hostname is the checkout service, or the HR file share, or a decommissioned staging box nobody remembered to remove from DNS.
Build a business context tag on every asset with at minimum these fields:
- Process: order processing, payroll, customer support, internal tooling.
- Revenue linkage: direct (the asset processes transactions), indirect (the asset supports staff who process transactions), none.
- Data classification: regulated PII, cardholder data, trade secret, public.
- Business owner: a named person, not a team distribution list, who can answer “can this go down for four hours.”
Once that tag exists, every CVSS score inherits it automatically. A SQL injection finding on a system tagged “order processing, direct revenue, cardholder data” writes its own headline: this bug is a potential path to a PCI DSS reportable event and a checkout outage, not just an 8.6. Platforms that consolidate scanner output against a maintained asset inventory, such as SITEY, carry this business context alongside every finding automatically, so the tag does not have to be re-typed into a spreadsheet during triage. If your tooling does not do that, the tag lives in a CMDB or asset register you join against scan results in whatever reporting layer you already use.
Building a Simple Impact Rubric Your Organization Can Agree On
The rubric has to be agreed to once, in a calm room, before an incident, not invented under pressure during one. Five levels is enough resolution without becoming a debate exercise. A workable starting point:
| Level | Label | Definition | Example trigger |
|---|---|---|---|
| 1 | Negligible | No customer-facing or regulated system affected | Finding on an isolated lab host |
| 2 | Minor | Internal disruption, no data exposure, recoverable within a shift | DoS on an internal wiki |
| 3 | Moderate | Limited data exposure or partial service degradation | Read-only access to non-regulated internal data |
| 4 | Major | Regulated data exposure or revenue-generating service outage | Unauthenticated access to a customer database |
| 5 | Severe | Multi-system compromise, breach notification obligation, or sustained revenue-generating outage | Domain admin compromise from an internet-facing foothold |
Two rules keep this rubric from decaying into a popularity contest during a live triage meeting. First, the definitions must reference outcomes (data exposed, service down, notification owed), never adjectives (critical, severe, high) borrowed from a scanner’s own severity field, because those already carry unrelated meaning. Second, the business owner assigned to the asset, not the security analyst, has final say on the impact level when there is disagreement, because they are the one who will answer for the consequence. Security proposes the level from the finding’s technical detail; the owner confirms or overrides it with a one-line justification that gets logged. That log line is also your audit trail if a regulator or auditor later asks how a finding was scoped, which is exactly the kind of traceability compliance mapping work depends on.
Expressing Likelihood Without Pretending to Actuarial Precision
Do not assign a percentage to “likelihood of exploitation in the next 90 days” unless you have an actuarial model behind it, because a fabricated number is worse than no number: it invites a false sense of precision and gets quoted in a board deck as if it were measured. Use an ordinal scale instead, built from observable signals rather than guesses:
- Confirmed exploitation: the vulnerability appears in CISA KEV, has a public Metasploit or Nuclei module, or you have direct telemetry of exploitation attempts against your own perimeter.
- Weaponized: a working public proof of concept exists but no confirmed mass exploitation yet.
- Theoretical: the CVE is published with a CVSS vector but no known working exploit.
- Requires chaining: exploitation depends on combining this finding with at least one other condition (another vulnerability, a misconfiguration, insider access) that is not currently present.
Cross this ordinal scale against the five-level impact rubric and you get a 4×5 grid, which is a legitimate, explainable heat map without inventing a single decimal point. A finding that lands in “confirmed exploitation” plus “major impact” gets a patch SLA measured in hours; a finding in “requires chaining” plus “minor impact” can sit in a monthly batch. This is also where re-testing earns its keep: a patch that closes the confirmed-exploitation path but leaves the chaining condition in place has only partially reduced likelihood, and the grid should reflect that until a retest confirms the full chain is broken, not just the headline CVE.
Three Before and After Rewrites of Real Finding Descriptions
The gap between a scanner’s raw output and a sentence a non-technical stakeholder will actually read is usually one paragraph of translation work. Three representative rewrites:
| Before (scanner language) | After (business language) |
|---|---|
| “CVE-2024-XXXXX, CVSS 9.8, unauthenticated remote code execution in Apache Struts component on host web-prod-04.” | “An attacker on the internet could take full control of the server handling customer order submissions, with no login required. This risks a checkout outage and a possible data exposure event requiring customer notification.” |
| “Missing HttpOnly flag on session cookie, CVSS 4.3, medium severity.” | “A successful phishing attack against an employee could let an attacker steal their active login session on the internal HR portal. Payroll and personnel records would be exposed to that one compromised account, not the wider internet.” |
| “Outdated TLS 1.0 supported on load balancer, CVSS 5.9.” | “Some older client connections to our public site use an encryption standard with known weaknesses. This does not currently expose data on its own, but it will likely appear as a finding in our next PCI DSS assessment and should be scheduled before that audit window.” |
Notice the pattern: each rewrite names who can do what, to which business function, and what the downstream consequence is (outage, notification, audit finding), while dropping the CVE identifier and score entirely from the sentence a stakeholder reads first. Keep the technical detail available as a linked reference for the engineer who has to fix it, but do not lead with it.
Keeping the Translation Layer Maintainable as Findings Scale
A hand-written rewrite works for the three findings you present at a quarterly board meeting. It falls apart at the volume a real environment produces, where a single external scan across a mid-size estate routinely returns thousands of findings after deduplication. Three practices keep the translation layer from becoming its own backlog:
- Template the rewrite, not the finding. Build one sentence template per finding class (RCE, credential exposure, misconfiguration, outdated crypto) with variables for asset name, business process, and consequence, so a human only fills in the blanks instead of drafting prose each time.
- Push the business context tag upstream, not downstream. If the asset inventory carries process, revenue linkage, and data classification, every new finding on that asset inherits the context automatically instead of requiring a fresh interview with the asset owner each time a scanner runs.
- Route the rewrite to the right audience automatically. A major-impact, confirmed-exploitation finding should generate an executive-facing summary the moment it is validated, not sit in a queue until the next scheduled report. This is the kind of narrative generation that AI-assisted triage is well suited to, since the model can draft the business-language version from the technical finding plus the asset’s context tag, leaving a human to review and approve rather than write from scratch.
The failure mode to watch for as volume grows is silent drift: the rubric that made sense with 50 findings a month stops getting applied consistently at 500, definitions get reinterpreted ad hoc, and two analysts start scoring the same finding class differently. Revisit the rubric and the likelihood scale on a fixed cadence, quarterly is reasonable, and treat any finding that could not be classified cleanly as a signal that a category is missing rather than forcing it into the nearest bucket.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.