What is a vulnerability prioritisation matrix?

A vulnerability prioritisation matrix is a standing decision artefact that ranks every open finding using a transparent combination of technical severity, exploit likelihood, exploitation status, asset criticality, exposure, and compensating controls. The output is a tier-ordered queue (P0 fix-now through P4 best-effort) with an SLA target attached to each tier, replacing the implicit "sort by CVSS and start from the top" behaviour with a defensible record auditors and engineering partners can both read. The matrix is the operating layer that turns a scanner backlog into a triaged plan of work.

Why is CVSS alone not enough to prioritise vulnerabilities?

CVSS is a severity score, not a priority score. It estimates the intrinsic technical impact of a vulnerability if it were exploited. It does not say whether the vulnerability is actually being exploited (KEV does), how likely it is to be exploited in the next thirty days (EPSS does), whether the affected asset holds cardholder data or customer authentication (asset criticality does), whether the system is internet-facing (exposure does), or whether a WAF rule or segmentation already reduces residual risk (compensating controls do). Programmes that drive remediation off CVSS alone fix theoretical issues in non-critical systems before they fix KEV-listed issues on the public auth service. The matrix exists to pull severity, likelihood, exploitation status, asset context, exposure, and compensating controls onto the same ranking record.

What signals does the matrix combine?

Six signals as default columns. CVSS 3.1 base severity (the technical impact if exploited). EPSS exploit likelihood (the modelled probability of exploitation in the next thirty days, refreshed daily from FIRST.org). CISA KEV exploitation status (whether the vulnerability is in the Known Exploited Vulnerabilities catalogue). Asset criticality (Tier 0 regulated data and tier-zero auth, Tier 1 production customer-facing, Tier 2 internal production, Tier 3 non-production). Exposure (internet-facing, internal-only, isolated). Compensating controls (named WAF rule, segmentation policy, monitoring rule, or session policy with the rule reference recorded). Optional columns include reachability analysis (for SCA findings where dependency-vs-call-graph reachability data exists), data classification, regulatory scope (PCI DSS cardholder data environment, HIPAA PHI, GDPR personal data), and time-since-detection so aged findings cannot quietly stay at the same tier.

How does the matrix map to SLA tiers?

The matrix produces a tier (P0 through P4) and the SLA ladder applies the tier-specific target. A reasonable default ladder: P0 within 7 days from detection, P1 within 30 days, P2 within 60 days, P3 within 90 days, P4 best effort. Tune the ladder against the frameworks that govern your programme: PCI DSS v4.0 Requirement 6 expects critical and high vulnerabilities addressed inside defined windows; ISO 27001:2022 Annex A.8.8 expects timely remediation against documented severity; SOC 2 CC7.1 expects evidence of remediation cadence; CISA Operational Directives expect KEV-listed findings closed against CISA-specified dates. The matrix is the record that connects each finding to its tier; the SLA ladder is the policy the tier triggers. Keep the two artefacts paired so the audit read shows both the decision and the policy at once.

How does the matrix handle KEV-listed vulnerabilities?

A KEV listing is the strongest single prioritisation signal because it asserts active exploitation at the time the CISA catalogue was updated. The matrix treats KEV status as a one-way upgrade: any internet-facing or perimeter-exposed asset with a KEV-listed vulnerability lands at P0 regardless of CVSS. Internal-only assets with KEV-listed vulnerabilities at minimum land at P1 because exploitation is no longer theoretical. The matrix records the KEV listing date, the CISA-specified due date (KEV-listed federal due dates also serve as a useful external benchmark for non-federal programmes), and the linkage between the finding and the KEV CVE so the audit trail is unambiguous.

How does the matrix handle compensating controls?

Compensating controls reduce residual risk and can legitimately move a finding down a tier, but only when the control is named and verifiable. A WAF rule reference, a network segmentation policy ID, a monitoring rule query, or a session policy that demonstrably blocks the exploitation path is acceptable. Vague claims like "the WAF blocks this" or "it is behind authentication" without a named control are not. The matrix has a dedicated compensating-controls column with both the control identifier and an effectiveness rating (Demonstrated / Likely / Unverified). Only Demonstrated and Likely controls move the tier; Unverified controls are recorded for follow-up but do not change priority. Periodically retest compensating controls because a WAF rule that was effective at deployment can drift over time.

Who owns the matrix and who updates it?

The vulnerability management programme owns the matrix as a policy artefact, with the CISO or security director signing the tier definitions and the SLA ladder. Engineering teams and application owners participate in the asset criticality classification because the security team cannot accurately tier assets it does not run. AppSec, product security, and cloud security teams update the per-finding rows during triage. Vulnerability management runs the recurring review (typically weekly for P0 and P1, monthly for P2 and below) and reports the aging distribution to security leadership. The exception register and the risk acceptance form are the two artefacts that pair with the matrix when a finding cannot meet its tier SLA.

How does the matrix relate to risk-based vulnerability management and CTEM?

Risk-based vulnerability management (RBVM) is the broader operating model that uses the matrix as its triage engine. Continuous Threat Exposure Management (CTEM) is the umbrella programme that pairs the matrix-driven prioritisation with attack-surface discovery, validation, mobilisation, and improvement cycles. The matrix is the layer in both disciplines where each finding receives its tier, its SLA target, and its compensating-control record. Without an explicit matrix, RBVM and CTEM frameworks become slogans rather than operating discipline because there is no shared, auditable record of how prioritisation decisions are actually made.

Can internal security teams and external pentest firms share this matrix?

Yes. The matrix is the same for both. Internal security, AppSec, vulnerability management, GRC, and cloud security teams use it to triage findings imported from authenticated scanners, external scanners, code scanning, manual reviews, third-party pentests, bug bounty programmes, and internal reports. External pentest firms and security consultancies use it to give clients a per-finding tier alongside the technical report so the client knows which finding to address first, which can wait, and which is being deferred to a documented risk acceptance. The fields are the same in both cases; the difference is who fills in the asset criticality column. SecPortal carries the matrix on the engagement workspace so the internal-team-and-external-firm handoff happens against one record rather than two.

How does this matrix tie back into audit evidence?

Auditors and customer security teams want four things for each open or closed finding: the severity at detection, the named owner, the closure or acceptance decision, and the timeline against the agreed SLA. The matrix supplies the missing fifth: the reasoning behind the SLA tier. When the matrix sits on the same workspace as the finding record, the activity log, and the audit-evidence tracker, the export is the audit artefact. ISO 27001:2022 Clause 8.3 (risk treatment), Annex A.5.7 (threat intelligence), A.5.27 (lessons learned), and A.8.8 (technical vulnerability management); SOC 2 CC7.1, CC7.2, CC7.3, CC7.4; PCI DSS v4.0 Requirement 6.3.1 and 6.3.2; NIST SP 800-53 Rev. 5 RA-5, RA-7, SI-2; NIST CSF 2.0 ID.RA and PR.PS all expect a documented prioritisation method behind remediation evidence. The matrix is that documented method.

Free Tool

Vulnerability Prioritisation Matrix Template
one signed artefact for tier ladder, asset criticality, calculation rules, and audit trail

A free, copy-ready vulnerability prioritisation matrix template that turns a scanner backlog into a tier-ordered queue. Seven structured sections covering tier definitions and SLA ladder, asset criticality classification, per-finding matrix columns, deterministic tier calculation rules combining CVSS, EPSS, CISA KEV, asset tier, exposure, and compensating controls, the compensating controls register, the aging and exception review cadence, and the audit trail keyed to ISO 27001:2022 Clause 8.3 and Annex A.8.8, SOC 2 CC7, PCI DSS v4.0 Requirement 6.3.1 and 6.3.2, NIST SP 800-53 Rev. 5 RA-5, RA-7, and SI-2, NIST CSF 2.0 ID.RA and PR.PS, CISA KEV operational cadence, EU CRA Article 13, and DORA Articles 9 and 11. Built for internal security teams, AppSec, vulnerability management, GRC, cloud security, security engineering, and CISO-sponsored programmes that need a defensible alternative to sorting by CVSS and starting from the top.

Get Started Free

No credit card required. Free plan available forever.

Full template

Copy the full vulnerability prioritisation matrix template

Seven sections covering tier definitions and SLA ladder, asset criticality classification, per-finding matrix columns, tier calculation rules, compensating controls register, aging and exception review cadence, and audit trail with framework mapping. Aligned with ISO 27001:2022 Clause 8.3 and Annex A.8.8, SOC 2 CC7, PCI DSS v4.0 Requirement 6.3.1 and 6.3.2, NIST SP 800-53 Rev. 5 RA-5, RA-7, and SI-2, NIST CSF 2.0 ID.RA / PR.PS, CISA KEV operational cadence, EU CRA Article 13, and DORA Articles 9 and 11. Replace every {{PLACEHOLDER}} before the matrix is signed off as your prioritisation policy.

1. Tier definitions and SLA ladder

Declare the tier boundaries and the SLA per tier as a signed policy artefact. Tune the numbers to your risk appetite and your framework obligations (PCI DSS v4.0 Requirement 6, ISO 27001:2022 A.8.8, SOC 2 CC7, CISA KEV cadence, NIST SP 800-53 SI-2). The ladder is the policy the matrix enforces; without it the tier columns mean nothing.

TIER DEFINITIONS

P0 - Fix now
- Definition: Active exploitation underway, or a KEV-listed CVE on a perimeter or internet-facing asset, or Critical CVSS combined with public exploit code and reachable exposure.
- SLA target from detection: 7 days.
- Escalation path: Security leadership and engineering lead paged within 24 hours of detection.

P1 - Urgent
- Definition: KEV-listed CVE on an internal-only Tier 0 or Tier 1 asset, or High CVSS combined with EPSS above the 90th percentile and reachable exposure, or any finding with an active threat-intel report naming exploitation.
- SLA target from detection: 30 days.
- Escalation path: Security operations lead and asset owner notified within 72 hours.

P2 - High
- Definition: High CVSS without KEV listing on a Tier 0 or Tier 1 asset, or Medium CVSS with EPSS above the 70th percentile on a Tier 0 asset.
- SLA target from detection: 60 days.
- Escalation path: Standard remediation queue, owner assignment within five business days.

P3 - Standard
- Definition: Medium CVSS on Tier 1 or Tier 2 assets without exploit signals, or High CVSS on Tier 2 assets with strong compensating controls.
- SLA target from detection: 90 days.
- Escalation path: Standard remediation queue.

P4 - Best effort
- Definition: Low or Informational findings, hardening recommendations, or findings on Tier 3 non-production with no data exposure.
- SLA target from detection: Best effort; review quarterly for accumulation.
- Escalation path: Tracked but not actively chased; reviewed in the quarterly aging report.

POLICY METADATA
- Version: {{POLICY_VERSION}}
- Approved by: {{APPROVER_NAME_TITLE}}
- Approval date: {{APPROVAL_DATE}}
- Review cadence: Annual or after material change to risk appetite, regulatory scope, or framework requirements.
- Framework alignment: PCI DSS v4.0 Requirement 6, ISO 27001:2022 A.8.8 and Clause 8.3, SOC 2 CC7.1 / CC7.2 / CC7.3, NIST SP 800-53 Rev. 5 RA-5 and SI-2, NIST CSF 2.0 ID.RA / PR.PS, CISA KEV operational cadence.

2. Asset criticality classification

Asset tier is the multiplier that converts technical severity into business risk. Without a documented tier per asset, the matrix collapses to a CVSS sort. Engineering and application owners participate in the classification because security cannot accurately tier assets it does not run.

ASSET CRITICALITY TIERS

Tier 0 - Regulated or tier-zero
- Examples: cardholder data environment (PCI DSS scope), customer authentication and session systems, regulated PHI under HIPAA, regulated personal data under GDPR or local privacy law, payment processing, key management, signing infrastructure, secrets management.
- Default exposure assumption: any vulnerability is a candidate for escalation regardless of network position.

Tier 1 - Production customer-facing
- Examples: production customer applications, customer APIs, customer-data-handling backends, public marketing surfaces with form submission, third-party-facing integration endpoints.
- Default exposure assumption: internet-facing unless documented otherwise.

Tier 2 - Internal production
- Examples: internal production services, internal admin tooling, employee-facing applications, internal data warehouses, internal scheduling and orchestration platforms.
- Default exposure assumption: internal-only unless connected to a Tier 1 asset.

Tier 3 - Non-production
- Examples: development, staging, sandbox, demo, training, ephemeral preview environments.
- Default exposure assumption: isolated from production data; verify per environment.

ASSET REGISTER (one row per in-scope asset)
Asset ID | Asset name | Owner team | Owner name | Tier | Exposure (internet / internal / isolated) | Data classification | Regulatory scope | Last reviewed

3. Per-finding matrix columns

The matrix has one row per open finding. Each row carries the six default columns plus optional reachability, regulatory, and aging columns. Keep the column set stable across releases so the audit read does not drift.

PER-FINDING COLUMNS

Required columns
- Finding ID (canonical record, pairs to scanner output, code scan, manual review, or third-party pentest)
- CVE / CWE / Finding-template ID
- Source (authenticated scan / external scan / code scan / manual review / third-party pentest / bug bounty / internal report)
- CVSS 3.1 base vector and score
- EPSS percentile (refreshed daily from FIRST.org)
- KEV listing status (Yes with CISA due date / No / Not applicable)
- Asset ID and asset tier (from the asset register)
- Exposure (internet / internal / isolated)
- Compensating controls (named control ID and effectiveness rating: Demonstrated / Likely / Unverified)
- Calculated tier (P0 / P1 / P2 / P3 / P4)
- SLA target date (computed from detection date + tier ladder)
- Owner team and owner name
- Status (New / Triaged / In Progress / Awaiting Retest / Resolved / Accepted / Reopened)

Optional columns
- Reachability (for SCA findings where dependency-vs-call-graph analysis is available: Reachable / Not Reachable / Unknown)
- Regulatory scope (PCI DSS CDE / HIPAA PHI / GDPR personal data / FedRAMP / DORA / NIS2 / SOX / none)
- Data classification (Public / Internal / Confidential / Restricted)
- Time-since-detection (days; informs the aging review)
- Linked engineering ticket (URL or ticket ID)
- Linked risk acceptance form (if Accepted)
- Linked retest record (if Awaiting Retest or Resolved)

4. Tier calculation rules

The tier is the output of a deterministic rule set, not a per-finding negotiation. Publish the rules alongside the matrix so engineering and audit can both reconstruct any tier decision from the same record.

TIER CALCULATION RULES (apply in order; first match wins)

Rule 1 - KEV on perimeter or internet-facing asset
- If KEV listed AND (asset tier is Tier 0 OR Tier 1 OR exposure is internet-facing) -> P0
- Reason: Active exploitation against a reachable asset.

Rule 2 - KEV on internal-only asset
- If KEV listed AND exposure is internal-only AND asset tier is Tier 0 or Tier 1 -> P1
- If KEV listed AND exposure is internal-only AND asset tier is Tier 2 -> P2
- Reason: Active exploitation, internal-only assets reduce exposure but not severity.

Rule 3 - Critical CVSS with high EPSS and reachable exposure
- If CVSS base >= 9.0 AND EPSS percentile >= 90 AND exposure is internet-facing -> P0
- If CVSS base >= 9.0 AND EPSS percentile >= 90 AND exposure is internal-only AND asset tier is Tier 0 or Tier 1 -> P1
- Reason: Severe and likely to be exploited soon.

Rule 4 - Active threat-intel report naming exploitation
- If a credible threat-intel report names this CVE as exploited in the last 30 days -> at minimum P1.
- Reason: Pre-KEV signal; do not wait for the catalogue to catch up.

Rule 5 - High CVSS on Tier 0 or Tier 1 asset
- If CVSS base >= 7.0 AND asset tier is Tier 0 or Tier 1 -> at minimum P2.
- Reason: Severe vulnerability on critical asset.

Rule 6 - Medium CVSS with EPSS above 70th percentile on Tier 0 asset
- If 4.0 <= CVSS base < 7.0 AND EPSS percentile >= 70 AND asset tier is Tier 0 -> P2.
- Reason: Likely-to-be-exploited finding on a tier-zero asset.

Rule 7 - High CVSS on Tier 2 asset with Demonstrated compensating control
- If CVSS base >= 7.0 AND asset tier is Tier 2 AND compensating control effectiveness is Demonstrated -> P3.
- Reason: Severe but materially controlled finding on a non-critical asset.

Rule 8 - Reachability override for SCA findings
- If finding source is code scanning AND dependency is Not Reachable -> downgrade one tier (e.g. P2 -> P3), but never below P3 if asset tier is Tier 0.
- Reason: Unreachable dependencies reduce real exploitability without eliminating supply-chain risk.

Rule 9 - Default tier
- All findings not matching the above default to P3 if CVSS >= 4.0 or P4 otherwise.
- Reason: Floor; the queue is never silently empty.

Rule 10 - Hard floor for regulatory scope
- If finding affects a PCI DSS cardholder data environment, HIPAA PHI store, or GDPR personal data store -> tier cannot be lower than P2 regardless of other rules.
- Reason: Regulatory scope sets the audit-defensibility floor.

Reviewers may override the calculated tier with a documented justification. Overrides are recorded with the named approver, the date, and the reason so the audit trail captures the exception rather than hiding it.

5. Compensating controls register

A compensating control reduces residual risk only when it is named and verifiable. Vague claims like "the WAF blocks this" or "it is behind authentication" do not move the tier. The matrix records the specific control reference, the effectiveness rating, and the retest date.

COMPENSATING CONTROLS REGISTER (paired to the per-finding matrix)

For each control claimed against a finding, capture:
- Control ID (WAF rule ID / segmentation policy ID / monitoring rule query / session policy reference / EDR rule)
- Control owner team
- Control type (WAF rule / network segmentation / monitoring detection / session policy / EDR rule / IAM restriction / data tokenisation / other)
- Effectiveness rating: Demonstrated / Likely / Unverified
  - Demonstrated = active test or exploit attempt confirmed blocked, dated within 90 days
  - Likely = documented control logic that would block the attack pattern but no active test
  - Unverified = claim made but no test or documentation backing it
- Date last verified
- Next verification due date
- Linked finding(s)
- Notes (any caveats, scope limits, or known bypasses)

Tier movement rule:
- Only Demonstrated and Likely controls move the tier.
- Unverified controls are recorded but do not change priority; flag for follow-up.
- A control whose verification has expired (more than 180 days since last verified) reverts to Unverified until re-tested.

6. Aging and exception review

Even a well-tiered backlog accumulates findings that cannot meet their SLA. Aging review and exception review are the two recurring meetings that keep the matrix from quietly silting up. Run them on the same cadence regardless of how busy the queue is.

AGING REVIEW

Cadence
- P0 and P1: weekly stand-up; every finding past SLA is escalated to security leadership and asset owner.
- P2: bi-weekly review; findings within 14 days of SLA breach receive an owner check-in.
- P3 and P4: monthly review; the quarterly aging report covers the full distribution.

Aging report fields (per recurring review)
- Open findings by tier
- Findings past SLA by tier
- Median time-in-tier by tier
- Aging buckets (0-30, 31-60, 61-90, 91-180, 181-365, 365+ days)
- Movement summary (new this period, closed this period, reopened this period, accepted this period)
- KEV-listed open findings (always called out separately)
- Top five oldest open findings with owner and last status update

EXCEPTION REVIEW

Cadence
- Monthly review of all accepted-risk findings and all findings within 14 days of SLA breach.
- Quarterly review of all P0 / P1 / P2 accepted-risk findings for compensating-control validity.

Exception review fields (per finding)
- Linked risk acceptance form reference
- Compensating controls effectiveness (still Demonstrated? still Likely?)
- Hard expiry of acceptance (acceptances must have a defined end date)
- Cancellation triggers (events that would invalidate the acceptance)
- Re-tier decision (continue acceptance / re-tier to P2 / re-tier to P1 / re-tier to P0)

Outputs from the aging and exception reviews feed the security leadership report and the audit evidence pack for the period.

7. Audit trail and framework mapping

The matrix only earns its audit weight if every tier decision, override, exception, and review is captured on a per-finding record with a timestamp and a named decision maker. Manual record-keeping in spreadsheets drifts; the activity log on the workspace where the matrix lives is the durable trail.

AUDIT TRAIL FIELDS (per finding)

- Tier at first triage and the rule that set it.
- Tier change history: timestamp, from-tier, to-tier, rule that applied, named approver.
- Override history: timestamp, calculated tier, override tier, reason, named approver.
- Compensating control changes: timestamp, control ID, before-effectiveness, after-effectiveness.
- SLA breach record: timestamp, breach reason, escalation path, recovery decision.
- Closure or acceptance record: timestamp, decision type, decision maker.
- Activity log reference (link to the workspace activity log for the finding).

FRAMEWORK MAPPING

The matrix is one record that satisfies the prioritisation-methodology expectation of multiple frameworks:

- ISO 27001:2022
  - Clause 8.3 information security risk treatment (the matrix is the prioritisation method behind treatment decisions).
  - Annex A.5.7 threat intelligence (KEV and EPSS columns are the documented intelligence inputs).
  - Annex A.8.8 management of technical vulnerabilities (the tier and SLA columns are the technical-vulnerability operating record).
  - Annex A.5.27 learning from information security incidents (override and acceptance review feed lessons-learned).

- SOC 2 (Trust Services Criteria)
  - CC7.1 system operations (the matrix is the operations artefact behind remediation cadence).
  - CC7.2 monitoring (the aging review evidences the monitoring of remediation backlog).
  - CC7.3 change management (the tier change history records remediation-related changes).
  - CC7.4 risk management (the matrix and the exception register are paired risk artefacts).

- PCI DSS v4.0
  - Requirement 6.3.1 (track and address vulnerabilities; the matrix is the tracking artefact).
  - Requirement 6.3.2 (rank vulnerabilities by risk; the matrix is the ranking artefact).
  - Requirement 11.4 (penetration testing findings); the matrix is the record where pentest findings receive a tier and an SLA.

- NIST SP 800-53 Rev. 5
  - RA-5 vulnerability monitoring and scanning (the matrix is the disposition record).
  - RA-7 risk response (the tier and SLA decisions are the documented response).
  - SI-2 flaw remediation (the matrix is the prioritisation and timing record).

- NIST CSF 2.0
  - ID.RA risk assessment (the matrix is the asset-risk-prioritisation artefact).
  - PR.PS platform security (the matrix drives the patch and remediation cadence).
  - DE.CM continuous monitoring (the aging review evidences continuous monitoring).
  - RS.MA incident response management (overrides and exceptions are managed events).

- CISA Known Exploited Vulnerabilities (KEV) Catalog and BOD 22-01
  - The KEV column maps each finding to its CISA-specified due date when applicable; non-federal programmes use the same dates as an external benchmark.

- EU Cyber Resilience Act Article 13 and DORA Articles 9 and 11
  - The tier and SLA decisions are the documented vulnerability-handling cadence European product and financial-services regulators expect.

How to operate this matrix

Sign Section 1 (tier definitions and SLA ladder) as a policy artefact before the matrix is filled in. The ladder is the contract between security, engineering, and audit; without it the matrix is just a list of fields.
Build the asset register in Section 2 with the engineering and application owners who run each system, not security in isolation. Tier 0 and Tier 1 classifications must trace back to a documented data-classification and exposure judgement that the owner has acknowledged.
Populate the per-finding rows in Section 3 from the consolidated backlog: authenticated scans, external scans, code scans, manual reviews, third-party pentest findings, bug bounty submissions, and internal reports. Use the SecPortal findings management feature so every finding carries a CVSS 3.1 vector, an owner field, and a status that the matrix can read against rather than maintaining a parallel spreadsheet.
Apply the deterministic rules in Section 4 to assign a tier per finding. Record overrides on the finding record with the named approver and the reason so the audit trail captures the exception rather than hiding it.
Record claimed compensating controls in Section 5 with a control ID and an effectiveness rating. Vague claims do not move the tier. Pair the controls register with periodic verification because a WAF rule that was effective at deployment can drift.
Run the aging review in Section 6 on the cadence published in the policy regardless of how busy the queue is; the matrix only earns its audit weight if the reviews actually happen. Pair each accepted-risk row with the risk acceptance form template and run the lifecycle inside the SecPortal vulnerability acceptance and exception management workflow so accepted risk does not become a forever-deferral hidden in the queue.
Capture every tier decision, override, and SLA breach in the activity log so the audit trail in Section 7 is a byproduct of the work rather than a separate task. The SecPortal workspace activity log records status transitions, comments, evidence uploads, and approvals against each finding so the matrix decision history reconstructs from the record rather than from memory.

Companion artefacts and references

The per-finding remediation record that pairs to each matrix row: the vulnerability remediation worksheet. The matrix decides priority and SLA; the worksheet runs the work.
The SLA ladder generator that calibrates Section 1 numbers against PCI DSS, ISO 27001, SOC 2, and CISA KEV expectations: the vulnerability remediation SLA calculator.
The SLA policy artefact that publishes the ladder as a signed document: the vulnerability SLA policy template.
The programme-level scorecard that reports matrix performance to security leadership: the vulnerability management programme scorecard.
The accepted-risk artefact paired to every P-tier finding that cannot meet its SLA: the risk acceptance form template, and the standing register the team operates against: the security exception register template.
The use-case workflow that runs prioritisation against the live backlog: the vulnerability prioritisation workflow, paired with the vulnerability SLA management workflow for the per-finding timer side and the vulnerability backlog management workflow for the aging side.
The narrative buyer guide and prioritisation framework explainer: the vulnerability prioritisation framework guide and the risk-based vulnerability management buyer guide.
The signal explainers that feed the EPSS and KEV columns: the EPSS score guide and the CISA KEV catalogue guide.
The framework pages that govern the audit-evidence shape: the ISO 27001 framework page, the SOC 2 framework page, the PCI DSS framework page, and the NIST CSF 2.0 framework page.
The analytical research on how findings age past SLA and why prioritisation queues drift: the research on aging pentest findings and the research on severity calibration.

This template is provided as a starting point for documenting a vulnerability prioritisation policy. It is not legal or audit advice and is not a substitute for your organisation's vulnerability management policy, risk-treatment standard, or regulator-specific evidence requirements. Have the final tier ladder and rule set reviewed against the policies and frameworks that govern your programme before it is rolled out.

Loading tool...

Related features

Vulnerability management software that tracks every finding

Document management for every security engagement

Every action recorded across the workspace

Compliance tracking without a full GRC platform

Collaborate across your entire team

AI-powered reports in seconds, not days

Bulk finding import bring your scanner data with you