Vulnerability prioritisation
from raw signals to a defensible queue
A backlog longer than the team can address inside the standard remediation window forces prioritisation. The question is how to prioritise defensibly. Run vulnerability prioritisation on the engagement record so every finding carries CVSS, EPSS, CISA KEV exploitation status, asset criticality, exposure, and compensating controls, and the queue orders itself by real residual risk rather than by creation date or by a single severity number.
No credit card required. Free plan available forever.
Run vulnerability prioritisation on the engagement record
Most security programmes have a backlog longer than the team can address inside the standard remediation window. The question is not whether to prioritise but how to prioritise defensibly. CVSS alone produces a queue where theoretical criticals sit above actively exploited highs. A spreadsheet of asset tiers maintained outside the queue drifts apart from the live findings record within a quarter. SecPortal closes both gaps by combining CVSS, EPSS, CISA KEV exploitation status, asset criticality, exposure annotation, and compensating controls into a single ranked queue stamped on the engagement record.
This is the workflow view of prioritisation. For the long-form framework that explains the reasoning behind each signal, read the vulnerability prioritisation framework guide. For triage that validates whether a finding is real before it enters the priority queue, read the scanner result triage workflow. For the categorisation primitive that records the asset tier the priority queue reads as a multiplier, read the asset criticality scoring workflow. For the deadline enforcement that turns priority tiers into measurable closure windows, read the vulnerability SLA management workflow. For the deferred-risk side that runs alongside prioritisation, read the vulnerability acceptance and exception management workflow.
Six signals that drive a defensible priority queue
Prioritisation is not a single metric. It is the deliberate combination of severity, likelihood, exploitation status, asset value, exposure, and compensating control state. The six signals below are the inputs every defensible programme records against each finding. Anything missing from the list reduces the priority decision to a guess that will not survive an audit read.
CVSS 3.1 base severity
The intrinsic technical severity of the vulnerability if it were exploited. Captured as the full attack vector, attack complexity, privileges required, user interaction, scope, and CIA impact metrics. CVSS answers the "how bad if exploited" question. It is the starting point of prioritisation, not the final answer; a CVSS 9.8 in an internal-only system with a compensating control may legitimately rank below a CVSS 7.5 in an internet-facing API with active exploitation in the wild.
EPSS exploit likelihood
The Exploit Prediction Scoring System estimates the probability that a vulnerability will be exploited within the next thirty days based on real-world exploitation data. EPSS separates the small set of vulnerabilities that are both severe and likely from the much larger set that are severe but rarely exploited. Pairing EPSS with CVSS turns a backlog of hundreds of high findings into the dozen the team has to address first this week.
CISA KEV exploitation status
The Known Exploited Vulnerabilities catalogue is the strongest single signal a prioritisation queue can carry. Anything in KEV is being actively exploited by threat actors at the time the catalogue was updated. KEV-listed findings on internet-facing assets warrant the tightest SLA tier regardless of CVSS score, because the assumption that exploitation is theoretical no longer holds.
Asset criticality and business context
The same vulnerability in a tier-zero asset (cardholder data, customer authentication, regulated data) carries materially higher impact than the same vulnerability in a non-production sandbox. Asset tier is the multiplier that converts technical severity into business risk. Without asset context, the queue treats every finding as if it sits on the same system; with asset context, the queue reflects what actually matters to the business.
Exposure and reachability
Internet-facing exposure raises real risk; internal-only reachability lowers it. Network segmentation, authentication walls, and zero-trust controls are part of the exposure picture rather than abstract risk reductions. A finding that is technically high but unreachable from the public network without authenticated access deserves a different SLA tier than one that is one curl request away from exploitation.
Compensating controls in place
A WAF rule, network segmentation, monitoring alert, or session-policy hardening can demonstrably reduce residual risk. Compensating controls are recorded against the finding with the rule ID, segment policy, or alert query so the residual claim is verifiable later. Generic claims that "a WAF blocks this" without naming the rule are the most common path from a defensible exception to a finding the audit cannot defend.
Six failure modes that quietly break prioritisation programmes
Every prioritisation programme that drifts into creation-date order drifts there for one of the same reasons. The six modes below recur whenever the priority signals live somewhere other than the finding itself. Each one is invisible at the time and visible at the next breach, audit, or post-incident review.
CVSS alone drives the queue
The team sorts findings by base CVSS score and works the top of the list. Half the criticals are theoretical; half the highs are KEV-listed and actively exploited but get worked second. The fix is layering EPSS, KEV, and asset context onto the ordering rather than treating CVSS as the sole input. CVSS is a severity score, not a priority score.
Asset criticality lives in a side spreadsheet
A separate document lists tier-zero, tier-one, and tier-two assets, but the finding queue does not pull from it. The result is a queue where tier-zero criticals sit alongside tier-three mediums in creation-date order. The fix is recording asset criticality against the engagement scope so every finding logged on that asset inherits the tier without manual classification.
EPSS scores are pulled once and never refreshed
A team integrates EPSS scoring at first import and then forgets to refresh. Six months later the queue is using a six-month-old probability estimate that no longer reflects current exploitation patterns. EPSS is updated daily and the prioritisation logic has to reflect the live estimate, not the snapshot taken at the moment of import.
KEV catalogue is treated as a nice-to-have
The team checks KEV at the end of triage rather than at the start. Findings that should have been escalated to a tighter SLA tier sit in the standard queue for weeks before someone notices the CVE is in KEV. The fix is making KEV a queue-entry signal so KEV-listed findings carry the tightest SLA from the moment they land.
The queue does not reflect compensating controls
A finding rated critical on base CVSS but mitigated by a WAF rule sits at the top of the queue alongside un-mitigated criticals. The team chases the mitigated finding and the un-mitigated one waits. The fix is recording the compensating control against the finding so the residual severity is visible alongside the original severity, and the queue can sort by residual rather than by base.
Prioritisation is a quarterly review, not a daily discipline
A spreadsheet reorders findings once a quarter at the steering meeting. Between reviews the queue drifts back toward creation-date order and the urgent work gets buried. The fix is making prioritisation a queue-state property rather than a meeting deliverable: every finding carries its priority signal at all times, and the queue surfaces the closest-to-slipping work first.
Five priority tiers a defensible queue lands on
A useful priority tier is concrete, not abstract. Tiers map to actions, owners, and SLA windows rather than to colour codes. The five tiers below are the shape most enterprise and consultancy programmes converge on once they apply the six signals above. Tune the bands to your release cadence and regulatory windows, then record the policy on the engagement record so every finding inherits the same logic.
| Priority tier | When the tier applies | What the tier means in practice |
|---|---|---|
| Immediate | KEV plus internet exposure or critical asset | KEV-listed CVEs on internet-facing assets, KEV-listed CVEs on tier-zero assets even when internal, or finalised exploitation chains with a working proof-of-concept available publicly. The tightest SLA tier in the queue. Escalation routes immediately to the engagement lead and the named senior approver. |
| High urgency | High CVSS plus high EPSS plus reachable | CVSS 7.0 or above, EPSS at the elevated band (commonly 0.1 and above as a programme-tunable threshold), and internet or authenticated-but-reachable exposure. The work the team plans this sprint. Asset tier escalates the SLA when the asset is tier-zero or tier-one regardless of the EPSS percentile. |
| Standard | High CVSS or active EPSS but compensating controls reduce residual | High CVSS findings whose residual severity, after the compensating control is applied, fits within the standard remediation window. The exception register names the control, the residual rationale, and the review cadence. Standard tier is the largest band by volume and the one most likely to age silently if the queue does not surface it. |
| Routine | Medium CVSS, low EPSS, internal exposure | Medium-severity findings that the team addresses on the normal release cadence. Routine work is bundled into remediation sprints, hardening rounds, or release-train cycles. The SLA is generous but the queue still tracks closure timestamps so the long tail does not drift into the next quarter. |
| Hardening | Low CVSS, low EPSS, no exploitation signal | Hygiene and hardening items. Bundled into the next maintenance window or shipped as a side effect of other work. The hardening tier still has a target close window and a closure timestamp so the audit can see the long tail is not abandoned, but it does not interrupt the roadmap. |
Six fields every prioritisation policy has to record
A defensible prioritisation policy is six concrete fields on the engagement record, not an abstract sentence in a security policy document. Anything missing from the list below is a known gap in the audit trail rather than something a reviewer will spot in time.
Severity-and-likelihood weighting
How CVSS, EPSS, and KEV combine into a single priority score. The most common pattern is a tiered rule: KEV plus exposure equals immediate, high CVSS plus elevated EPSS plus reachable equals high, and so on. The weighting is recorded on the engagement so every finding inherits the same logic without manual reordering.
Asset tier mapping
The classification of in-scope assets into tier-zero (cardholder data, customer authentication, regulated data), tier-one (production business systems), tier-two (internal supporting systems), and tier-three (development and sandbox). The mapping is a property of the engagement scope, not of the individual finding, so every finding inherits the tier from the asset it sits on.
Exposure annotation source
How the queue determines whether a finding is internet-facing, internal-only, or behind authentication. Common inputs are the verified-domain hostname check, the scanner module that produced the finding (external scanning versus authenticated scanning versus code scanning), and the engagement scope description. Recording the exposure source makes the residual claim verifiable later.
Compensating-control register
The list of named compensating controls (WAF rule IDs, segment policies, monitoring alert queries, session-policy hardening references) that can be applied to a finding to reduce its residual severity. The register lives alongside the engagement so the residual claim is auditable rather than narrative.
EPSS refresh cadence
How often the platform refreshes EPSS scores against the live finding queue. EPSS is updated daily; a defensible policy refreshes at least weekly, more often for tier-zero assets. The refresh cadence is recorded on the engagement so the audit can verify the priority decision was based on a current estimate rather than a months-old snapshot.
Review trigger conditions
The events that force a finding to be re-prioritised: a new KEV listing for the underlying CVE, an EPSS percentile crossing a threshold, a compensating-control change, an asset re-tiering, or a regression. Trigger-driven re-prioritisation keeps the queue accurate between scheduled reviews rather than waiting for the next cycle.
Vulnerability prioritisation checklist
Before any engagement opens new findings into the priority queue, and at every quarterly review, the engagement lead and the remediation owner walk through a short checklist. Each item takes minutes; missing any one of them is the source of the failure modes above and the audit gaps that follow.
- The prioritisation policy is recorded on the engagement, not in a separate slide deck.
- CVSS 3.1 vectors are captured for every finding the engagement produces.
- EPSS scores are refreshed against the live queue at a defined cadence.
- KEV catalogue membership is checked at the moment a finding is logged, not at quarterly review.
- Asset criticality is a property of the engagement scope, not of an individual analyst memory.
- Exposure annotation is sourced from the scanner module, not from a free-text comment.
- Compensating controls are named with rule, segment, or query references, not generic claims.
- Residual severity is recorded alongside base severity so the queue can sort by either.
- KEV-listed findings carry the immediate tier from the moment they enter the queue.
- The prioritisation queue is the same queue owners work; there is no parallel review document.
- Review triggers re-prioritise findings between scheduled reviews when the underlying signals change.
- The activity log captures every prioritisation decision and reordering with timestamp and user.
- The branded portal mirrors the live priority view for client-side visibility.
- AI-generated reports include the prioritisation rationale alongside the closure metrics.
How prioritisation looks in SecPortal
Prioritisation is one workflow stitched into four feature surfaces: the findings record, the engagement record, the branded client portal, and team management for owner assignment. The work that has to happen at each stage is the same work the platform already supports for everyday findings operations; the prioritisation layer just makes the signal capture, residual calibration, and tier assignment explicit on the queue.
Policy on the engagement
The prioritisation policy lives on the engagement record itself. Every finding logged against the engagement inherits the severity-and-likelihood weighting, the asset-tier mapping, and the exposure annotation source so the priority logic is enforced by default rather than reapplied each cycle.
CVSS calibration on every finding
Each finding stamps the CVSS 3.1 vector, base severity, and recalibrated residual severity. The findings record shows base and residual side by side, so the queue can sort by either depending on whether the team is reviewing baseline exposure or residual after compensating controls.
Asset tier on the engagement scope
Asset tier is a property of the engagement scope, recorded once and inherited by every finding logged on that asset. Tier-zero, tier-one, tier-two, and tier-three findings sort distinctly on the queue, so a tier-zero high never sits below a tier-three critical because of a base-CVSS comparison alone.
Exposure from the scanner module
Exposure annotation is sourced from the scanner module that produced the finding: external scanning on the verified domain, authenticated scanning behind a credentialed login, or code scanning against a connected repository. The source is recorded so the residual claim is verifiable later rather than narrative.
Compensating controls on the finding
Compensating controls are recorded against the finding with the rule, segment, or query reference. The residual likelihood and impact are captured so the queue can sort by residual rather than by base. The pair feeds the exception workflow when residual severity sits outside the standard SLA.
Audit trail in the activity log
Every priority decision, tier reassignment, and compensating-control change lands on the activity log with timestamp and user. The CSV export is the trail an ISO 27001, SOC 2, PCI DSS, or NIST audit reads when it asks how the priority order was decided.
Reporting views the priority queue actually drives
The reports that drive prioritisation performance are not the static PDF that lands at the end of an engagement. They are the live views owners, security leads, and auditors look at every week. The five below are the ones every meaningful programme settles on, and they all derive from the live findings record rather than a parallel spreadsheet.
Queue by priority tier
Open findings grouped by immediate, high urgency, standard, routine, and hardening. The headline view leadership reads in weekly reviews and the line ISO 27001 and SOC 2 audits expect to see trended over time.
KEV coverage report
Open findings whose underlying CVE sits in the CISA KEV catalogue, ordered by exposure and asset tier. KEV coverage is the report a CISO presents to the risk committee when asked whether the programme covers actively exploited vulnerabilities.
EPSS top-percentile view
Open findings whose EPSS percentile sits above the programme threshold. The view surfaces the small set of vulnerabilities most likely to be exploited in the next thirty days so the team can address them before the probability becomes an incident.
Tier-zero exposure view
Open findings on tier-zero assets regardless of severity. Tier-zero exposure is the view a CISO and a board read together when asked whether the programme is protecting the systems most likely to materially harm the business if breached.
Residual versus base severity drift
Findings whose residual severity differs from base severity, with the compensating control reference. The view surfaces where the queue is relying on compensating controls so the audit can verify the controls are still in place and the residual claim still holds.
Activity log export
Every prioritisation decision, tier reassignment, and signal refresh lands on the activity log. The CSV export is the audit evidence ISO 27001, SOC 2, PCI DSS, and NIST assessors expect to see when they ask for the trail behind the headline numbers.
What auditors expect from a prioritisation programme
Vulnerability prioritisation evidence appears in audit reads whenever an external assessor reviews the security programme. The frameworks below all expect a documented policy plus enforcement evidence rather than a slide that names the targets without proving them.
| Framework | What the audit expects |
|---|---|
| ISO/IEC 27001:2022 | Annex A 8.8 expects technical vulnerability management to be informed by the criticality of the asset and the exposure of the system. Clause 6.1.2 expects risk to be assessed against the organisation context. A defensible prioritisation policy that combines CVSS, EPSS, KEV, asset tier, and exposure annotation is the artefact a 27001 audit reads as evidence the risk-based requirement is met. |
| SOC 2 | Common Criteria CC3.2 expects the entity to identify and analyse risks to the achievement of its objectives. CC7.1 expects the entity to detect and remediate vulnerabilities, and the auditor will look for evidence that detection led to risk-prioritised response rather than first-in-first-out work. Recording the prioritisation logic on the engagement and the priority decision on each finding produces the trail CC3.2 and CC7.1 audits read. |
| PCI DSS v4.0 | Requirement 6.3.1 expects a process for identifying security vulnerabilities and assigning a risk ranking based on industry best practices. Requirement 6.3.3 expects critical security vulnerabilities to be addressed in a timely manner. The risk-ranking requirement is the prioritisation requirement; combining CVSS, KEV exploitation status, and asset criticality into a documented ranking satisfies the assessor expectation. |
| NIST SP 800-53 Rev. 5 | RA-3 expects risk to be assessed considering threat, vulnerability, likelihood, and impact. RA-5 expects vulnerability scanning and the analysis of scan reports to drive remediation actions. SI-2 expects flaw remediation to be informed by risk. The prioritisation policy is the connective tissue between RA-3, RA-5, and SI-2; without it, the controls read as siloed activities rather than as a coordinated programme. |
| CISA BOD 22-01 | Federal civilian executive branch agencies and any organisation aligning to the Known Exploited Vulnerabilities catalogue are expected to remediate KEV-listed vulnerabilities within tight windows (commonly two weeks for KEV findings on internet-facing systems). KEV-driven prioritisation is no longer a best practice; it is the floor any modern programme is measured against. |
Where prioritisation fits across the vulnerability lifecycle
Prioritisation composes with the rest of the vulnerability lifecycle on the same engagement record so the priority decision, the SLA enforcement, and the closure evidence stay connected to the work that produced the finding and the work that will eventually retest it.
Upstream and adjacent
Prioritisation depends on scanner result triage promoting validated findings into the queue, on bulk finding import preserving the original tool metadata, on threat intelligence driven prioritisation ingesting external CTI signals (KEV, EPSS shifts, CERT advisories, vendor PSIRT bulletins, ISAC alerts) into the queue with provenance, and on vulnerability acceptance and exception management handling the residual cases that compensating controls move out of the standard tier.
Downstream and reporting
Priority tier feeds vulnerability SLA management because the tier decides the deadline. The queue feeds remediation tracking for the broader status workflow and retesting because closure under tier depends on retest evidence. AI report generation produces the leadership and audit narratives from the live record.
Pair the workflow with the long-form guides and the framework references
Prioritisation is operational; the surrounding guides explain the reasoning behind each signal and the framework clauses that mandate risk-based ranking. Pair this workflow with the vulnerability prioritisation framework guide for the upstream signal explanation, the CVSS scoring explained guide for the severity vector deep dive, the vulnerability management programme guide for the broader programme context, the CISA KEV catalog guide for the operational walkthrough of KEV ingestion, KEV-aligned SLAs, and KEV exception handling, and the research on vulnerability remediation throughput and vulnerability reopen rate for the durability axis that paired prioritisation has to defend. The framework references that mandate risk-based ranking include ISO 27001 for technical vulnerability management, SOC 2 for CC3.2 and CC7.1 risk identification and remediation, PCI DSS for requirement 6.3.1 risk ranking, and NIST SP 800-53 for RA-3, RA-5, and SI-2 flaw remediation expectations. Programme owners running a continuous exposure cycle around the same prioritisation logic will find the Continuous Threat Exposure Management (CTEM) framework a useful sequencing layer that ties scope, discovery, prioritisation, validation, and mobilisation into a single cycle record. Buyers evaluating risk-based vulnerability management platforms specifically often compare an analytics layer above existing scanner contracts to a workspace that prioritises on the engagement record itself; the SecPortal vs Kenna Security page covers that side-by-side for the RBVM category.
Buyer and operator pairing
Vulnerability prioritisation is the workflow vulnerability management teams run as the spine of the find-track-fix-verify loop, the workflow internal security teams and AppSec teams run to keep the queue ordered by real risk, and the workflow product security teams run alongside PSIRT intake. CISOs and security leaders read the priority queue and the KEV coverage report as the live posture rather than as a quarterly snapshot. GRC and compliance teams read the prioritisation rationale as audit evidence that risk-based ranking is in operation rather than aspiration.
What good vulnerability prioritisation feels like
Priority is a property of the finding
Every finding carries CVSS, EPSS, KEV status, asset tier, exposure, and compensating controls on its own record. The priority decision is not an output of a quarterly meeting; it is a property of the finding the queue inherits at all times.
KEV is the floor, not the ceiling
KEV-listed findings carry the immediate tier from the moment they enter the queue. The programme covers KEV before anything else, and the KEV coverage report demonstrates the floor. Beyond KEV, EPSS and asset tier order the rest of the high-urgency work.
Residual severity is auditable
Compensating controls are recorded with rule, segment, or query references. The residual severity sits alongside the base severity on every finding the controls apply to, and the audit can verify the residual claim from the same record the queue runs on.
Evidence is derivative of the work
The priority tier breakdown, the KEV coverage view, the EPSS top-percentile view, the tier-zero exposure view, and the activity log export all derive from the live record. Nobody assembles the prioritisation evidence at the end of the quarter from a spreadsheet; the activity log is the trail and the AI report is the narrative.
Vulnerability prioritisation is the discipline that turns a backlog into a queue ordered by real risk. Run it on the engagement record, and every priority decision carries the signal capture, the residual calibration, and the audit trail that the programme and the audit both expect. For the programme layer that sequences prioritisation alongside Scoping, Discovery, Validation, and Mobilisation as one continuous cycle, pair this workflow with the CTEM cycle workflow.
Frequently asked questions about vulnerability prioritisation
What is vulnerability prioritisation?
Vulnerability prioritisation is the discipline of deciding which findings to remediate first when the queue is longer than the team can address inside the standard remediation window. A defensible prioritisation policy combines technical severity (CVSS), exploit likelihood (EPSS), active exploitation status (CISA KEV), asset criticality, exposure, and compensating controls into a single ranked queue. The output is not a flat list of findings; it is an ordered queue where the work most likely to be exploited and most damaging if exploited sits at the top.
How is prioritisation different from triage?
Triage is the validation step that decides whether a finding is real, a false positive, a duplicate, or out of scope. Prioritisation is the ordering step that decides which validated findings to remediate first. Triage answers "is this a finding"; prioritisation answers "is this the next finding". Both run on the same engagement record. Triage produces validated findings; prioritisation produces an ordered queue from those findings.
How is prioritisation different from SLA management?
Prioritisation decides which severity tier a finding earns based on signals like CVSS, EPSS, KEV, asset criticality, and exposure. SLA management enforces the deadline that severity tier maps to (critical within seven days, high within thirty, and so on), tracks breach, and routes escalation. Prioritisation feeds SLA management: the priority decision drives the severity tier, and the severity tier drives the deadline. Both run on the engagement record so the priority rationale is visible alongside the SLA timer.
Should the queue use CVSS, EPSS, or KEV?
All three, with KEV as the strongest single signal. CVSS measures intrinsic severity if exploited. EPSS estimates probability of exploitation in the wild within thirty days. KEV is the catalogue of vulnerabilities being actively exploited at the time the catalogue was updated. A defensible policy uses KEV plus exposure to identify the immediate tier, CVSS plus EPSS plus asset tier to order the rest of the high-urgency queue, and compensating controls plus asset context to calibrate residual severity. Any one signal alone produces a queue that misses cases the other signals would have caught.
How often should EPSS scores be refreshed?
EPSS is updated daily. A defensible programme refreshes EPSS against the live finding queue at least weekly, more often for tier-zero assets. The refresh cadence is recorded on the engagement so an audit can verify the priority decision was based on a current estimate rather than a snapshot from six months ago. Pulling EPSS once at import and never refreshing produces a queue whose ordering decays with every passing week.
How are KEV-listed findings handled?
KEV-listed findings carry the immediate tier from the moment they enter the queue, regardless of the base CVSS score. The KEV catalogue is checked at finding logging, not at quarterly review, so a CVE that lands in KEV after the original triage is re-prioritised on the next refresh trigger. KEV findings on internet-facing assets warrant the tightest SLA tier; KEV findings on tier-zero assets warrant the same tier even when the asset is internal because active exploitation in the wild changes the residual exposure assumption.
How does asset criticality affect prioritisation?
Asset criticality is the multiplier that converts technical severity into business risk. The same CVSS 7.5 finding on a tier-zero customer-data system warrants different prioritisation than the same finding on a tier-three sandbox. A defensible policy records asset tier as a property of the engagement scope so every finding logged on that asset inherits the tier without manual classification, and the queue surfaces tier-zero criticals before tier-three criticals even when the CVSS score is identical.
How do compensating controls affect the priority order?
Compensating controls reduce residual severity below base severity. A WAF rule, network segmentation, monitoring alert, or session-policy hardening can demonstrably move a critical CVSS finding into the standard queue rather than the immediate queue. The compensating control is recorded against the finding with a rule, segment, or query reference, the residual likelihood and impact are captured, and the queue sorts by residual severity rather than base. Generic claims that "a WAF blocks this" without naming the rule are not defensible compensation.
How should the prioritisation rationale be documented?
The rationale lives on the finding record, not in a separate document. Every finding carries the CVSS vector, the EPSS percentile at the time of decision, the KEV status, the asset tier, the exposure annotation, the compensating control reference if applicable, and the resulting tier assignment. The activity log captures the priority decision with timestamp and user. AI-generated reports surface the rationale alongside the closure metrics so leadership and auditors read the same trail the operators ran the queue from.
How does SecPortal support vulnerability prioritisation?
SecPortal records the prioritisation policy on the engagement, captures CVSS 3.1 vectors with environmental and temporal calibration on every finding, surfaces severity and residual severity on the queue, supports asset-tier and exposure annotation through the engagement scope, captures compensating controls with rule references, exports the activity log to CSV for ISO 27001, SOC 2, PCI DSS, and NIST evidence, and generates AI-driven reports that include the prioritisation rationale alongside the closure metrics. SecPortal does not write the prioritisation policy for the team; it makes risk-based, audit-defensible vulnerability prioritisation the path of least resistance.
How it works in SecPortal
A streamlined workflow from start to finish.
Capture the prioritisation policy on the engagement
A defensible policy names the severity-and-likelihood weighting (how CVSS, EPSS, and KEV combine), the asset-tier mapping that classifies in-scope assets into tier-zero through tier-three, the exposure annotation source per scanner module, the compensating-control register, the EPSS refresh cadence, and the review trigger conditions. Record the policy on the engagement so every finding logged against it inherits the same logic.
Stamp the priority signals on every finding
When a finding is logged, the platform stamps the CVSS 3.1 vector and base score, the asset tier inherited from the engagement scope, and the exposure annotation sourced from the scanner module that produced the finding. EPSS percentile and KEV status are captured against the underlying CVE so the priority decision uses the live exploitation context rather than a months-old snapshot.
Calibrate residual severity for compensating controls
Where a WAF rule, network segmentation, monitoring alert, or session-policy hardening reduces exposure, the compensating control is recorded against the finding with a rule, segment, or query reference. The residual likelihood and impact are captured so the queue can sort by residual rather than by base. Generic claims that a control mitigates a finding without naming the rule are not defensible compensation; they are gaps the audit will read as absent controls.
Surface priority tiers on the live queue
The dashboard groups findings by priority tier: immediate (KEV plus exposure), high urgency (high CVSS plus elevated EPSS plus reachable), standard (high severity but compensating-control reduced residual), routine (medium severity, low EPSS, internal exposure), and hardening (low severity, no exploitation signal). Owners see their queue ordered by residual risk rather than by creation date. The branded client portal mirrors the live priority view so the client and the firm read the same picture.
Re-prioritise when signals change
Trigger-driven re-prioritisation keeps the queue accurate between scheduled reviews. A new KEV listing for the underlying CVE, an EPSS percentile crossing the programme threshold, a compensating-control change, an asset re-tiering, or a regression all force a fresh tier evaluation. The activity log captures every reordering with timestamp and user so the trail is reconstructable later.
Report priority evidence for audit and leadership
AI-generated reports, the activity log export, and the engagement record together produce the prioritisation evidence: queue by tier, KEV coverage report, EPSS top-percentile view, tier-zero exposure view, and residual-versus-base severity drift. The CSV export covers the audit asks for ISO 27001, SOC 2, PCI DSS, and NIST. The leadership view covers the board ask for risk-based remediation posture.
Features that power this workflow
Run vulnerability prioritisation as a record, not as a meeting
CVSS, EPSS, KEV, asset tier, exposure, and compensating controls captured on every finding. The queue orders itself by real risk. Start free.
No credit card required. Free plan available forever.