Scanner Finding Priority Recalculation After Import
A CVE the open backlog already references is revised overnight in the National Vulnerability Database. The EPSS feed regenerates and the daily exploit-prediction scores move across thousands of CVEs. CISA adds three new entries to the Known Exploited Vulnerabilities catalogue. A vendor scanner ships a rule pack update that reassigns severity on twelve existing detection rules. The asset-criticality flag on a production service flips from internal-only to customer-facing. Each of these upstream events asks the workspace to recalculate priority across an existing finding catalogue without overwriting the original detection record, without bypassing operator overrides, and without resetting the SLA clock. This guide covers the scanner-side recalculation discipline that propagates upstream priority signal through the finding catalogue as a structured live read while preserving the frozen-at-detection record alongside it.
The guide covers the boundary between recalculation and intake-time severity normalisation, the seven upstream signal classes that trigger recalculation, the live-versus-frozen field discipline, how recalculation interacts with the override register and the SLA clock, four operating cadences, six failure modes that break the chain, how imported third-party scanner output joins the recalculation surface, and how ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, DORA, and NIS2 read the recalculation artefact chain.
What recalculation is and what it is not
Recalculation is a write on a small set of live priority fields the workspace exposes on the per-finding identity, paired with a record-in-place of the prior-to-new transition in the activity log. Each finding carries an at-detection state (the severity, the CVSS base vector, the EPSS reading at detection, and the KEV membership on the detection date) that is frozen and never refreshed, plus a live operating state (the current workspace severity, the current CVSS environmental score, the current EPSS, the current KEV flag, the current asset-criticality flag) that the recalculation discipline writes against when an upstream input signal moves.
Recalculation is not intake-time severity normalisation. The scanner output severity normalisation guide covers the cross-tool intake policy that translates each scanner is native severity vocabulary into the workspace canonical severity at the moment the finding lands. Normalisation runs once at intake; recalculation runs many times after intake on the in-place finding when an upstream signal changes. The two disciplines compose and land on the same per-finding identity, but they are operated as separate policy classes with separate audit reads.
Recalculation is not severity recalibration drift research either. The severity recalibration drift research covers the econometric reading of how often vendor rule packs and scanner engine releases produce severity moves across the in-place catalogue. The research sits above the per-finding identity and reads the historical record; the recalculation discipline produces the historical record one event at a time.
Seven upstream signal classes that trigger recalculation
Seven signal classes carry most of the recalculation load in practice. Each one has a different cadence, a different scope, and a different audit reading; the workspace policy records which signals it tracks and what threshold is crossed before a recalculation is written.
| Signal class | What changes | Typical cadence |
|---|---|---|
| CVE base-score revision | NVD updates the CVSS base vector or metric values on a previously published CVE. | Irregular; per-CVE revision event. |
| CVE temporal-score update | Exploit availability, remediation status, or report confidence change against an established CVE. | Irregular; per-CVE update event. |
| EPSS feed regeneration | FIRST EPSS catalogue regenerates daily and reissues a new exploit-prediction score for every CVE. | Daily; full-catalogue refresh. |
| CISA KEV addition | A CVE moves into the Known Exploited Vulnerabilities catalogue; the binary membership flag flips. | Irregular; per-publication event. |
| Vendor rule pack update | Scanner ships a signature pack revision that reassigns severity on existing detection rules. | Per-vendor-release cadence. |
| Asset criticality change | Business-context update moves an asset between tiers (production-critical, customer-facing, internal-only, decommissioned). | Per-asset-event cadence. |
| Operating context change | Asset configuration moves (WAF added, exposure profile flipped, regulated-data scope added). | Per-configuration-event cadence. |
A workspace that tracks all seven classes against the open finding catalogue can answer the leadership question “is the open backlog priority current against the advisory and business inputs of the moment” from one record. A workspace that tracks only the daily EPSS refresh leaves CVE revisions and KEV additions to land as ad-hoc spot-checks at audit fieldwork, which weakens the chain.
Live fields versus frozen fields
The recalculation discipline writes to a small set of live fields and freezes a corresponding set of immutable fields against the original detection. The boundary matters at audit time because the framework reading typically asks for both the at-detection record and the current operating record on the same finding row.
Live fields (refreshed on recalculation)
- Current workspace severity
- Current CVSS environmental score
- Current EPSS score
- Current KEV membership flag
- Current asset-criticality flag
- Priority-last-recalculated-at timestamp
- Priority-last-recalculated-by reference
- Input-signal-version stamp (NVD revision id, EPSS feed date, KEV catalogue revision, vendor pack version)
Frozen fields (never refreshed)
- Severity-at-detection
- CVSS-base-vector-at-detection
- EPSS-at-detection
- KEV-at-detection flag
- Detection timestamp
- At-detection rationale (workspace reason the finding was created at the severity it carried)
- At-detection workspace policy version
The activity log writes the prior-to-new transition on every recalculation pass with the input signal class, the input signal version, the prior value, the new value, and the actor or scheduled job that ran the recalculation. The audit chain reads the live history alongside the frozen at-detection record so the conversation around “how did this finding move from medium to critical and which signal triggered the move” resolves from one record rather than from a reconstruction across chat logs and ticketing exports.
How recalculation interacts with the override register
The finding overrides register holds the workspace decisions that change a finding is operating disposition: false-positive overrides, accepted-risk overrides, manual severity adjustments, and deferrals. The recalculation reads the override register before writing a refreshed priority value; the interaction follows one rule per override class.
Manual-severity-override
The operator named the workspace severity explicitly (this finding is a high regardless of the CVSS reading). The recalculation writes the refreshed CVSS environmental and EPSS values but does not touch the workspace severity field. The activity log records that the upstream signal moved but the override held the operating priority.
Accepted-risk override
The operator accepted the risk with a cited reason and a hard expiry. The recalculation writes the new score values; the operating workflow continues to read the override-held disposition until the override expires. If the recalculation crosses a threshold the override conditions named (a CVE the override scoped excludes KEV membership), the workspace surfaces the threshold crossing for review.
False-positive override
The operator decided the finding is not a real issue. The recalculation reads the override and skips the priority refresh entirely; the activity log records the upstream signal move and notes the override scope. If the override is later revoked, the recalculation runs against the finding from that point forward.
Deferral
The operator deferred remediation to a future cycle with a cited reason. The recalculation writes the refreshed scores; the deferral expiry is not affected by the priority change. If the recalculation moves the finding into a severity band that the deferral scope did not authorise, the workspace surfaces the deferral for review.
For the override lifecycle (active, review-due, in-review, renewed, expired, revoked) and the closed-loop renewal record, the scanner finding exception lifecycle and expiry guide covers the operating discipline the recalculation reads against.
How recalculation interacts with the SLA clock
The SLA clock is the operating cursor that bounds how long a finding can carry an open status before it breaches the workspace severity-tier SLA. A defensible recalculation policy does not reset the SLA clock when the workspace severity moves; the clock continues against the original finding-created timestamp and the workspace records both readings on the finding row.
Recalculation increases severity
A medium finding moves to high after KEV addition; an internal asset moves to customer-facing and a previously medium finding crosses the high threshold. The workspace surfaces the finding under the new severity-tier SLA expectations but the audit trail preserves the original SLA reading against the at-detection severity. The leadership conversation reads both readings: “this finding has been open against the at-detection severity for 180 days; the new severity-tier SLA would have expected closure at 30 days had the higher priority been known at detection.”
Recalculation decreases severity
A high finding moves to medium after an NVD revision lowered the CVSS base score; an asset moves from customer-facing to internal-only and a previously high finding crosses the medium threshold. The workspace surfaces the finding under the reduced expectations but the at-detection severity-tier SLA is preserved as historical context. The leadership conversation reads the new operating expectation alongside the original commitment.
SLA clock continuity
The clock starts at the finding-created timestamp and continues across every recalculation. The “how long has this finding been open” reading resolves consistently regardless of how many recalculation events have written to the live fields.
For the SLA workflow side that consumes the recalculated priority, the vulnerability SLA management use case covers the operating mechanism that pairs the recalculation discipline to the severity-tier expectations.
Four operating cadences
The recalculation discipline runs on four cadences in practice. Each one is driven by a different upstream cadence and writes to the same live fields through different scheduled jobs.
Per-feed (daily)
Daily EPSS regeneration runs against the open finding catalogue on a scheduled job that reads the new EPSS value, compares against the threshold delta, and writes the refreshed value where the threshold is crossed. The job runs against every finding whose CVE reference is present in the EPSS catalogue.
Per-catalogue (irregular)
KEV catalogue updates run on the CISA publication cadence. A scheduled job reads the new KEV entries, finds open findings whose CVE references match, and writes the KEV-membership flag plus any priority refresh the workspace policy requires.
Per-pack (per-release)
Vendor rule pack updates run when the scanner ships a signature pack revision. The workspace records the pack version and runs a recalculation pass over recurring detections that match changed rule identifiers, writing severity refresh and rule-pack-version-of-priority.
Per-context (per-event)
Business-context changes (asset criticality, asset exposure, asset compliance scope) run on the operating cadence of the asset-management process. The workspace records the context change against the asset reference and recalculates priority for findings against that asset.
For the cycle-to-cycle metric movement that reads the recalculation events at the programme-shape level, the scan baseline and trend comparison guide covers the trend surface that sits above the per-finding recalculation history.
Six failure modes that break the recalculation chain
Six failure modes cover most of what surfaces at fieldwork as a priority surface the audit chain cannot interpret. Each one collapses the live-versus-frozen discipline into a state where the operating priority and the historical record disagree silently.
Silent overwrite of the at-detection severity
The recalculation writes over the frozen field. The audit chain loses the original detection state and the historical record becomes uninterpretable. The leadership conversation around “what did we know when we created this finding” ends in a reconstruction from chat logs.
Recalculation without activity-log entry
The priority refresh runs in place without writing the prior-to-new transition. The auditor sees only the current priority and cannot reconstruct how it was reached or which input signal triggered the move.
Override skipped by the recalculation
The recalculation writes a refreshed severity over a finding whose manual override should have held the operating priority. The workspace effectively reverses the override silently, which weakens the override discipline and the audit conversation around accepted risk.
SLA clock reset on recalculation
The clock starts from the recalculation timestamp instead of the finding-created timestamp. The “how long has this finding been open” reading no longer matches the detection date, and the SLA breach record becomes meaningless.
Inconsistent recalculation scope
The daily EPSS refresh runs against some findings but not others, typically caused by recurring-detection identity mismatches or stale CVE references. The priority surface ends up with adjacent findings at incompatible recency, and the leadership conversation around “is the backlog current” cannot resolve from the record.
Missing upstream-signal version recording
The activity log omits the EPSS feed date, the KEV catalogue revision, the NVD revision id, or the vendor pack version. The audit chain cannot reproduce why a specific recalculation happened against the inputs of the moment, and the framework reading around “show me the evidence the priority refresh is current” lacks anchor data.
Imported third-party output and the recalculation surface
Imported findings from Nessus, Burp Suite, CSPM exports, CSV imports, container scanner outputs, and consultancy deliverables enter the recalculation surface through the same per-finding identity that the native scanner output produces. The import workflow records the source-emitted vendor identifier on the evidence section so the recalculation can join the imported finding against the upstream feeds (CVE, EPSS, KEV) through the CVE reference.
For the structural intake mechanics, the importing third-party scanner results guide covers the import workflow that lands the per-finding identity the recalculation reads against. For the upstream advisory enrichment side (CVE feed binding, EPSS attachment), the vulnerability finding CVE and EPSS enrichment use case covers the workflow side that produces the upstream signal references the recalculation reads.
The honest scope is that the workspace cannot re-emit the third-party tool is detection signal under a new vendor rule pack, because that capability lives in the third-party tool. The recalculation reads the upstream advisory signals against the imported finding identity but does not re-evaluate the third-party tool is detection logic.
How compliance frameworks read the recalculation artefact chain
Auditors read recalculation through three artefact classes: the recalculation policy that bounds which signals trigger refresh and which fields write; the recalculation log that records each event with prior-to-new transitions and input-signal-version stamps; the recalculation review that confirms the discipline ran across the expected cohort scope. The framework readings below cover the controls that most often land on the recalculation discipline at scoped fieldwork.
| Framework | Controls that read recalculation evidence |
|---|---|
| ISO 27001:2022 | Annex A 8.8 technical vulnerability management (recurring detection priority kept current against upstream advisory signal); Annex A 5.7 threat intelligence (advisory signal integrated into priority discipline); Annex A 8.16 monitoring activities (priority refresh as a monitored operating event). |
| SOC 2 (TSC 2017) | CC7.1 detection of security events (detection reconciled against upstream advisory updates); CC7.2 system operations (operational priority surface kept current); CC3.2 risk assessment (priority refresh as part of the risk-input current-state evidence). |
| PCI DSS v4.0 | Requirement 6.3.1 vulnerability identification and rating (priority rating discipline that reads against upstream advisory updates); Requirement 11.4 vulnerability scanning (scan output priority kept current); Requirement 12.10 incident response (priority surface reads the upstream KEV catalogue). |
| NIST SP 800-53 r5 | RA-5 vulnerability monitoring (monitoring records updated against advisory updates); SI-2 flaw remediation (priority refresh as part of the flaw response discipline); RA-3 risk assessment (risk-input current-state evidence chain). |
| NIST CSF 2.0 | ID.RA risk assessment (risk inputs kept current); DE.CM continuous monitoring (detection records updated against advisory signals); GV.RR risk management strategy (priority refresh as part of governance reads). |
| DORA | Article 8 ICT risk management framework (risk-inputs kept current against threat-intelligence and vulnerability information); Article 13 threat-intelligence sharing (advisory signal flowing into priority discipline). |
| NIS2 | Article 21 risk management measures (priority refresh as part of risk-treatment evidence); Article 23 incident reporting (incident evidence chain reads the recalculated priority history). |
How SecPortal supports the recalculation discipline
SecPortal stores each finding as a row that carries the workspace severity, the CVSS vector, the CVSS score, the affected asset reference, the engagement reference, the template identifier, the title, the category, the control reference, and the evidence section. The at-detection state is recorded against the finding-created timestamp and the activity-log entry for the creation event. The platform exposes the primitives the recalculation discipline operates against.
Per-finding identity preserved across recalculation events
The same workspace plus template plus asset reference match key carries the finding identity across recurring scans, so the recalculation reads and writes against a stable identity rather than against per-cycle finding rows. The findings management feature covers the per-finding record the recalculation operates against.
Override register read before recalculation writes
Finding overrides record cited reason, named approver, scope, and hard expiry on the per-finding identity. The recalculation reads the override register before writing the refreshed priority value so manual-severity, accepted-risk, and false-positive overrides hold the operating disposition. The finding overrides feature covers the override mechanism.
Activity log captures the prior-to-new transition
The activity log writes every per-finding event with the named actor, the timestamp, and the engagement reference. CSV export is available for evidence packaging. The recalculation discipline writes prior-to-new transitions through the activity log so the audit chain reads the recalculation history alongside creation, assignment, status, and retest events. The activity log feature covers the audit-trail mechanism.
Bulk import carries the at-detection vendor severity
Bulk finding import preserves the source artefact alongside the workspace-translated rows so the imported at-detection vendor severity reads from the original input file. The recalculation joins the imported finding to the upstream feeds through the CVE reference and writes the live priority fields without overwriting the imported at-detection record. The bulk finding import feature covers the import surface.
Continuous monitoring detects recurring findings across cycles
Continuous monitoring runs scheduled scan executions that detect recurring findings and update last_seen on the recurring identity. The recalculation reads the recurring identity to apply the refresh across cycles rather than re-creating the finding on each cycle. The continuous monitoring feature covers the recurring scan cadence.
Compliance tracking holds the framework crosswalk
The compliance crosswalk records which framework controls read the recalculation evidence at audit fieldwork. The compliance tracking feature covers the framework reading surface.
Honest scope: SecPortal does not currently ship a packaged daily-EPSS-refresh job that automatically writes EPSS field updates against the open finding catalogue, a packaged CISA-KEV-watch job that writes KEV-membership flag changes on detection of new KEV entries, or a packaged NVD-CVSS-revision watch that writes refreshed CVSS base scores on detection of NVD revisions. SecPortal does not ship packaged Nessus, Burp Suite Enterprise, Tenable.io, Qualys VMDR, Rapid7 InsightVM, Defender for Cloud, Snyk, Veracode, Checkmarx, GitHub Advanced Security, or GitLab Ultimate priority-sync connectors. SecPortal does not ship packaged Jira, ServiceNow, Slack, PagerDuty, SIEM, or SOAR priority-push connectors. The recalculation discipline is operated as a workspace pattern; the platform provides the structured per-finding records, the at-detection severity field, the CVSS vector field, the activity log, the override register, and the bulk finding import surface that the recalculation reads and writes against. Programmes typically run the recalculation cadence as a scheduled workspace job operated outside the platform that reads the open finding catalogue and writes updated severity, CVSS environmental, and EPSS values back as structured updates that are captured in the activity log.
An operational checklist
When designing the per-finding priority record
- The finding row carries a frozen severity-at-detection, a frozen CVSS-base-vector-at-detection, a frozen EPSS-at-detection, a frozen KEV-at-detection flag, and a frozen at-detection rationale; none of these fields refresh on recalculation.
- The finding row carries a live current workspace severity, a live current CVSS environmental score, a live current EPSS score, a live current KEV flag, a live current asset-criticality flag, a priority-last-recalculated-at timestamp, a priority-last-recalculated-by reference, and an input-signal-version stamp; the recalculation writes to these fields on each pass.
- The activity-log entry for each recalculation event records the input signal class, the input signal version, the prior value, the new value, and the actor or scheduled job.
When scheduling recalculation jobs
- The per-feed daily EPSS refresh runs against the open finding catalogue at a stable scheduled time; the job stamps the EPSS feed date on every updated finding.
- The per-catalogue KEV addition watch runs against the CISA publication cadence; the job stamps the KEV catalogue revision on every updated finding.
- The per-pack vendor rule pack watch runs when the scanner ships a signature pack revision; the job stamps the rule pack version on every updated finding.
- The per-context business-context watch runs on the asset-management process cadence; the job stamps the context-change identifier on every updated finding.
At recalculation-write time
- The recalculation reads the override register before writing; manual-severity-overrides hold the operating priority, accepted-risk overrides write the new scores but not the workspace severity, false-positive overrides skip the refresh entirely.
- The recalculation never writes to the at-detection fields; only the live fields refresh.
- The recalculation never resets the SLA clock; the clock continues against the finding-created timestamp.
- The activity-log entry is written before the recalculation commits the live-field write so the audit chain reads the prior-to-new transition deterministically.
At recalculation review
- A quarterly review reconciles the recalculation activity log against the expected upstream signal cadence; the review confirms the daily EPSS job, the KEV watch, the rule pack watch, and the asset-context watch all ran without scope mismatches.
- The review samples a controlled set of recalculation events and confirms the prior-to-new transition is reproducible from the activity log against the at-detection record.
- The review samples overrides whose recalculation interaction was non-trivial (manual severity held priority across an upstream signal move, accepted risk crossed a threshold the override scope did not authorise) and confirms the operating decisions are sound.
- The review decisions are captured in the activity log so the audit chain reads recalculation maintenance as a controlled operating activity.
Where this fits in the wider scanner evidence chain
Recalculation sits next to several adjacent scanner-side disciplines that read or write to the same per-finding identity. The discipline composes with each and reads alongside them in the audit conversation.
For the intake-time severity translation that lands the at-detection state, the scanner output severity normalisation guide covers the cross-tool policy that the recalculation reads as the frozen baseline. For the structured per-finding fields the recalculation operates against, the scanner finding cross-engagement search and recall guide covers the structured fields the recall surface depends on.
For the integrity discipline that makes the per-execution record verifiable, the scanner output attestation and chain of custody guide covers the canonical record and the tamper-evidence anchor the recalculation activity log reads against. For the reproducibility discipline that lets the original analysis be replayed from the inputs of the prior scan, the scanner output replay from archived inputs guide covers the per-execution and per-job records the recalculation reads against when an audit reads a prior priority value.
For the recurring-detection freshness discipline that reads first_seen and last_seen, the scanner finding aging and staleness guide covers the aging surface that reads the same per-finding identity the recalculation operates against. For the cohort recall surface that reads recalculated priority across engagements, the cross-engagement finding search use case covers the workflow side that consumes the live priority fields.
Scope and limitations
Recalculation only works when the per-finding identity is stable across cycles and the workspace exposes the at-detection state as a frozen record alongside the live operating priority. Programmes that store findings in spreadsheets, in scanner UIs that overwrite per-finding rows on each scan cycle, or in ticketing tools that lack a recurring-detection identity cannot operate the recalculation surface coherently. The leverage point is consolidating findings into a workspace with structured per-finding identity and a live-versus-frozen field discipline before attempting to govern recalculation.
SecPortal exposes the structured records the recalculation reads and writes against, but the platform does not currently ship packaged scheduled jobs that auto-refresh EPSS, KEV-membership, NVD CVSS revisions, or vendor pack severity moves against the open finding catalogue. Programmes that operate the recalculation discipline typically schedule the jobs externally and write the updates back through the structured update surface; the activity log captures each event so the audit chain reads the recalculation history.
For the broader analytical reading of recalculation events at the programme-shape level, the severity mix shift economics research covers the operating economics of severity drift across cycles. For the workflow side that consumes the recalculated priority into a treatment cadence, the vulnerability prioritisation use case covers the operating discipline the recalculation feeds into.
Frequently Asked Questions
Run scanner recalculation on a record that keeps the at-detection state alongside the live priority
SecPortal stores every finding with a structured per-finding identity that carries the at-detection severity, the CVSS vector, the affected asset reference, the evidence section, and the engagement reference. The activity log captures every per-finding event so the prior-to-new priority transition reads alongside creation, assignment, status, override, and retest events. Bulk import preserves the source artefact for imported third-party output so the recalculation joins the imported finding to upstream feeds through the CVE reference.