Vulnerability Risk Rating & SLA Model
Replaces raw CVSS ranking with a defensible model combining exploitability, asset criticality and exposure to produce remediation deadlines management will accept.
Available soon
- Format
- Word
- Size
- 61 KB
- Length
- 17 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- Principles
- Inputs
- Scales and criteria
- Decision logic
- Worked examples
- How to defend the method to an auditor
- Limitations
- Calibration and review
- Related documents
- Adapting this template
- Framework references
- Appendix A — Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose
This model decides how urgent each vulnerability finding is, and therefore how long it may stay open. It replaces ranking by the scanner's severity score alone with a small set of questions that reflect real risk: is the weakness being used in attacks, can an attacker reach the system, how severe is it technically, and how much does the system matter to [[Organisation Name]].
The model's output is always one of the four priorities in section 5.2 of the Vulnerability & Exposure Management Standard, with that standard's deadline. The standard sets the deadlines and who may change a priority; this model is the method that assigns a priority to each finding consistently, so that two people rating the same finding reach the same answer.
It is applied at the weekly triage meeting described in the Vulnerability Triage & Remediation Operating Procedure, and its inputs and result are recorded for each finding in the Vulnerability Remediation Tracker.
Guidance — delete before approval
Keep this model and the Vulnerability & Exposure Management Standard in step. If the standard's deadlines change, this model changes in the same approval. Where the two appear to disagree, the standard wins and this model is corrected.
This model covers findings from vulnerability scanning, cloud configuration checks, penetration tests and vendor advisories. It does not decide whether a risk may be accepted — that is the exception route in section 7 of the standard.
Principles
The model is built on six principles. They explain its design and are the answer to most questions about why a finding received the priority it did.
- Evidence of attack comes first. A weakness that attackers are known to be using is more urgent than a technically severe one nobody is using. Exploitation evidence outranks the severity score.
- Reachability matters. A weakness an attacker can reach from the internet is more urgent than the same weakness behind the organisation's own network defences.
- The standard's table is the minimum. The model may make a finding more urgent than the standard's table, never less urgent — except through the controlled lowering in rule RM-07, which the standard itself allows (VM-10).
- Simple enough to use by hand. Every priority can be read from one table in under a minute, in a meeting, without a calculator.
- Recorded and repeatable. The inputs behind every priority are written down, so anyone — including an auditor — can re-derive it.
- The clock does not restart. Deadlines run from first detection (VM-08). Changing a priority changes the length of the deadline, not its starting point.
Inputs
Each finding is rated on four inputs. A finding is one vulnerability on one system: the same vulnerability on twenty systems is twenty findings, and each may receive a different priority.
Input | Question it answers | Where it comes from | Supplied by | If it is not known |
|---|---|---|---|---|
Exploitation evidence | Is this weakness being used in real attacks? | CISA's Known Exploited Vulnerabilities catalogue; vendor advisories; [[national CSIRT or sector threat feed]]; the organisation's own incidents | Standard owner | Treat as not known exploited, and check again at the next weekly triage |
Exposure | Can an attacker reach the affected system from outside? | Asset inventory; external scan results (VM-06); firewall and cloud network rules | Standard owner, confirmed by the asset owner | Treat as internet-facing until shown otherwise |
Technical severity | How bad is the weakness in itself? | The severity the scanner reports, based on the Common Vulnerability Scoring System (CVSS); otherwise the vendor's rating | The scanning tool | Use the vendor's rating; if there is none, treat as High |
Asset criticality | How much does this system matter to the business? | Asset inventory (VM-01), using the ratings in Appendix A of the standard | Asset owner | Treat as Critical, and correct the inventory within [[5 working days]] |
Two further facts are recorded for every finding, because the deadline depends on them: the date of first detection on that system (VM-08), and any compensating control that the standard owner has accepted under rule RM-07.
Guidance — delete before approval
The 'If it is not known' column is deliberate. A missing input always makes a finding more urgent, never less, so gaps in the asset inventory cost the people who can close them. If this produces too many urgent findings in the first months, fix the inventory rather than softening the defaults.
Scales and criteria
Each input has a small number of levels. The anchors below decide which level applies; where a finding sits on a boundary, the more urgent level is used.
Exploitation evidence
Level | Anchor — use this level when | Examples |
|---|---|---|
Exploited | There is reliable evidence that the vulnerability has been used in real attacks, anywhere. Any one of: it is listed in CISA's Known Exploited Vulnerabilities catalogue; the vendor's advisory states it is being exploited; [[the national CSIRT or a trusted sector feed]] reports active exploitation; or it was used in an incident at [[Organisation Name]]. | A remote-access appliance flaw added to the catalogue last week. A mail server flaw the vendor describes as 'exploited in limited, targeted attacks'. |
Not known exploited | None of the above applies. This does not mean the vulnerability is safe — only that there is no reliable evidence yet. | A newly published flaw with no exploitation reports. An old flaw with public proof-of-concept code but no reported attacks. |
Early-warning signals are not a level of their own, but they may justify raising a priority under rule RM-06: public exploit code that works; a high score in FIRST's Exploit Prediction Scoring System (EPSS), which estimates the probability that a vulnerability will be exploited in the next 30 days; a vendor marking the flaw 'exploitation more likely'; or reports that ransomware groups are using it.
Exposure
Level | Anchor — use this level when | Examples |
|---|---|---|
Internet-facing | The vulnerable service can be reached from the internet, directly or through a published service, without first connecting to the organisation's private network — or from networks the organisation does not fully control (standard, section 5.1). | Websites, VPN and remote-access gateways, email gateways, exposed management interfaces, cloud storage or databases with public endpoints, systems reachable from partner connections or guest Wi-Fi. |
Internal | The vulnerable service can be reached only from inside the organisation's own networks, or through them after authentication (for example, over the VPN). | File servers, internal business applications, domain controllers, printers, most end-user devices. |
Guidance — delete before approval
The standard defines 'internet-facing' to include networks the organisation does not fully control (Appendix A and section 5.1), because partner links and guest networks are routinely used as entry points. If your organisation prefers a narrower definition, change it here and in the standard together.
Laptops and desktops are rated Internal unless a vulnerable service on them accepts connections from the internet. Weaknesses in browsers, email clients and document readers are attacked through the user rather than the network; when they are exploited, the exploitation rule catches them.
Technical severity
Severity is the scanner's rating, which in most tools follows the qualitative bands published by FIRST for CVSS versions 3.x and 4.0:
Level | CVSS base score | Anchor |
|---|---|---|
Critical | 9.0 – 10.0 | Easily exploited remotely, usually without credentials, with full compromise of the system. |
High | 7.0 – 8.9 | Serious compromise possible, but with a condition such as credentials, user interaction or local access. |
Medium | 4.0 – 6.9 | Limited compromise, or significant preconditions. |
Low | 0.1 – 3.9 | Minor information disclosure or weaknesses that are hard to use. |
Informational results (score 0.0, or 'None') are not findings under this model. Findings from tools that use their own scale (for example, cloud configuration checks) are mapped to the nearest band using the tool's own description; the mapping is recorded once in [[location of tool mapping]] and not decided finding by finding.
Asset criticality
Asset criticality uses the three ratings in Appendix A of the standard, recorded for every system in the asset inventory (VM-01).
Level | Anchor (the standard, Appendix A) | Examples — replace with your own |
|---|---|---|
Critical | Failure or compromise would stop a core business service or expose highly sensitive data. | [[e.g. payment platform, customer database, domain controllers, core banking or ERP system, backup server]] |
High | Significant disruption or data exposure. | [[e.g. email, HR system, file servers holding personal data, main website]] |
Standard | All other systems. | [[e.g. test systems, meeting-room devices, printers, standard laptops]] |
Criticality changes a priority only for Critical systems (rule RM-05). High criticality is used to order work within a priority (rule RM-10) and, in the standard, to set scanning frequency.
Compensating controls
A compensating control is a measure that reduces the risk of a vulnerability that cannot yet be fixed. For this model, a control counts only if it changes one of the four inputs:
Qualifies — it changes an input | Does not qualify — the inputs are unchanged |
|---|---|
Access to the vulnerable service from the internet is removed and an external scan confirms it (exposure becomes Internal). | A web application firewall, intrusion prevention or endpoint protection 'should block it'. |
The vulnerable feature or service is disabled on that system, and a scan confirms the vulnerability can no longer be reached. | The system is 'monitored', or logs are reviewed. |
The system is isolated in a network segment reachable only from [[named management hosts]], confirmed by a rule export. | The fix is scheduled, or the vendor has promised a patch. |
Controls in the right-hand column may still reduce risk. They are evidence for an exception request (VM-16, VM-17), not grounds for a lower priority.
Decision logic
The steps
- Record the inputs. For each new finding, record exploitation evidence, exposure, severity, asset criticality and the date of first detection. Apply the 'if it is not known' defaults from the Inputs section.
- Exploited? If the vulnerability is exploited and the system is internet-facing or Critical, the priority is 1. If it is exploited on any other system, the priority is 2. Severity does not matter. Go to step 5.
- Not exploited — read severity against exposure. Critical or High severity: Priority 2 if internet-facing, 3 if internal. Medium: 3 if internet-facing, 4 if internal. Low: 4.
- Criticality uplift. If the system is Critical and the severity is not Low, raise the priority by one level — but not above Priority 2. Only exploitation creates a Priority 1.
- Set the deadline from the table in 'Deadlines', counting from the date of first detection.
- Apply any recorded adjustment — a raise under RM-06, or a lowering approved by the standard owner under RM-07 — and record who made it and why.
The lookup table
Steps 2 to 4 give the result below. At the weekly triage meeting, this table is all that is needed.
Exploitation evidence | Severity | Internet-facing Standard or High system | Internet-facing Critical system | Internal Standard or High system | Internal Critical system |
|---|---|---|---|---|---|
Exploited | Any | Priority 1 | Priority 1 | Priority 2 | Priority 1 |
Not known exploited | Critical or High | Priority 2 | Priority 2 | Priority 3 | Priority 2 (raised from 3) |
Not known exploited | Medium | Priority 3 | Priority 2 (raised from 3) | Priority 4 | Priority 3 (raised from 4) |
Not known exploited | Low | Priority 4 | Priority 4 | Priority 4 | Priority 4 |
'Raised from' marks the criticality uplift (step 4). Every other cell is exactly the standard's table in section 5.2. The uplift only ever makes a finding more urgent than the standard's minimum.
Deadlines
The priorities and deadlines are those of the standard, section 5.2. They are reproduced here for convenience; the standard is the authority.
Priority | Deadline to fix | Clock and escalation | Notes |
|---|---|---|---|
Priority 1 — Emergency | Mitigate within 72 hours; fix within 7 days | Mitigate within 72 hours of first detection (VM-09); fixed by day 7. | Treat as a potential incident. Notify the standard owner immediately. |
Priority 2 — High | 14 days | Fixed by day 14. Escalate to the asset owner's manager if not fixed by day 10. | Escalate to asset owner's manager if not fixed by day 10. |
Priority 3 — Medium | 30 days | Fixed by day 30. | Meets the PCI DSS one-month requirement for critical patches. |
Priority 4 — Low | 90 days | Fixed by day 90. | May be addressed through the normal patch cycle. |
Day 0 is the date the vulnerability was first detected on that system (VM-08). Deadlines are calendar days. A finding still open after its deadline, with no approved exception, is overdue and escalated under VM-19: to the asset owner's manager, then to the approver after a further 14 days.
Rules for applying the model
RM-01 Every finding of Priority 1 to 3 is recorded in the Vulnerability Remediation Tracker with its four inputs, the resulting priority and deadline, and the date of first detection (VM-11). Priority 4 findings may be tracked in bulk through the patch cycle, but still carry the 90-day deadline.
RM-02 Exploitation evidence outranks severity. An exploited vulnerability is never below Priority 2, whatever its severity score.
RM-03 Where an input is not known, the default in the Inputs section applies. Unknown exposure counts as internet-facing and unknown criticality as Critical.
RM-04 Severity is taken as the scanner reports it, or from the vendor where the scanner gives none. Rescoring a finding by hand to reach a lower severity is a lowering, and follows RM-07.
RM-05 A finding on a Critical system that is not known to be exploited, and not of Low severity, is raised one priority level, to no higher than Priority 2.
RM-06 Anyone at the triage meeting may propose raising a priority on an early-warning signal (see Exploitation evidence); the chair decides and the reason is recorded. Raising never needs approval, because it only makes the standard stricter.
RM-07 A priority may be lowered only by the standard owner, with the reason recorded (VM-10), and only because an accepted compensating control changes an input. The finding is re-read from the lookup table with the changed input; the result is its new priority. A lowering is never made to avoid a missed deadline, and is not considered once the deadline has passed — the route then is the exception process (VM-16) or overdue escalation (VM-19).
RM-08 Lowering a priority does not restart the clock: the new deadline is the date of first detection plus the new priority's period.
RM-09 If a compensating control relied on under RM-07 is removed or stops working, the finding returns at once to its original priority and deadline. If that deadline has passed, the finding is overdue.
RM-10 Within a priority, work is ordered by: earliest deadline; then exploited before not exploited; then Critical, High, Standard systems; then higher early-warning signals.
RM-11 The standard owner checks open findings against the exploitation sources at every weekly triage. A finding whose inputs change is re-rated that week (RM-12).
RM-12 When a finding becomes more urgent because an input has changed — for example, it has just been added to the Known Exploited Vulnerabilities catalogue — its new deadline is the earlier of its existing deadline and the date the change became known plus the new priority's period. For Priority 1, the 72-hour mitigation also runs from that date.
RM-13 The 72-hour mitigation required for Priority 1 (VM-09) is part of handling a Priority 1 finding. It does not by itself lower the priority or extend the 7-day deadline.
Guidance — delete before approval
RM-12 is how the standard's VM-08 applies when a finding's inputs change. VM-08 counts every deadline from first detection, which works while a finding's inputs stay the same. When a months-old finding is newly listed as exploited, counting its new 7-day deadline from first detection would make it overdue on the day it was re-rated, which helps nobody. RM-12 never gives a later deadline than the one the finding already had, and VM-08 in the standard points here.
Who decides what: the standard owner supplies exploitation evidence and approves any lowering; asset owners confirm exposure and criticality; the triage chair records raises; the approver approves this model with the standard.
Worked examples
The examples use a first-detection date of 3 March (day 0). The organisation, systems and dates are illustrative.
Example 1 — exploited flaw on the remote-access gateway
Step | Finding: remote code execution flaw in the remote-access (VPN) gateway, CVSS 9.8 |
|---|---|
1. Inputs | Exploitation: listed in the Known Exploited Vulnerabilities catalogue — Exploited. Exposure: the gateway accepts connections from the internet — Internet-facing. Severity: Critical. Criticality: High. First detected 3 March. |
2. Exploited? | Yes, and internet-facing → Priority 1. Severity and criticality do not change this. |
3–4. | Not applied (step 2 decided the priority). |
5. Deadline | Mitigate within 72 hours — by 6 March. Fix within 7 days — by 10 March. The standard owner is notified immediately, and the finding is treated as a potential incident. |
6. Adjustment | The vendor's patch is not yet available. On 4 March the gateway's management portal is taken off the internet and the vendor's published mitigation is applied (VM-09, within 72 hours). Under RM-13 this does not lower the priority: the gateway itself is still internet-facing and the flaw is exploited. The patch must be applied by 10 March, or a Priority 1 exception approved by the approver before then (VM-18). |
Example 2 — severe but not exploited, on an internal server
Step | Finding: privilege escalation flaw on an internal file server, CVSS 8.1 |
|---|---|
1. Inputs | Exploitation: not in any exploitation source — Not known exploited. Exposure: reachable only from the office network and VPN — Internal. Severity: High. Criticality: Standard. First detected 3 March. |
2. Exploited? | No. |
3. Severity × exposure | High and internal → Priority 3. |
4. Uplift | Not a Critical system → no change. |
5. Deadline | 30 days — fixed by 2 April. Ranking by CVSS alone would have put this among the most urgent findings; the model puts it behind anything exploited or internet-facing, because an attacker must first be inside the network. |
Example 3 — a Critical system, then new exploitation evidence
Step | Finding: information disclosure flaw in the database engine behind the customer database, CVSS 5.3 |
|---|---|
1. Inputs | Exploitation: Not known exploited. Exposure: Internal. Severity: Medium. Criticality: Critical (holds customer personal data). First detected 3 March. |
2–3. | Not exploited; Medium and internal → Priority 4. |
4. Uplift | Critical system, not Low severity → raised one level to Priority 3 (RM-05). |
5. Deadline | 30 days — fixed by 2 April. |
Re-rating | On 15 March (day 12) the flaw is added to the Known Exploited Vulnerabilities catalogue. At that week's triage (RM-11) it is re-rated: exploited, on a Critical system → Priority 1 (step 2). Under RM-12 the new fix deadline is the earlier of 2 April and 15 March + 7 days: 22 March. Mitigation is due within 72 hours of 15 March — by 18 March. The standard owner is notified immediately. |
Example 4 — a lowering that is accepted, and one that is not
Step | Finding: authentication bypass in a web administration console, CVSS 7.5 |
|---|---|
1. Inputs | Exploitation: Not known exploited. Exposure: the console is reachable from the internet — Internet-facing. Severity: High. Criticality: Standard. First detected 3 March. |
2–4. | Not exploited; High and internet-facing → Priority 2. No uplift. |
5. Deadline | 14 days — fixed by 17 March, with escalation to the asset owner's manager if not fixed by 13 March (day 10). |
Lowering accepted | On 6 March, the console is restricted to the VPN by a firewall rule; the next external scan no longer finds it. The standard owner accepts this under RM-07: exposure is now Internal. Re-read: High and internal → Priority 3. The deadline counts from 3 March (RM-08): fixed by 2 April. The reason and the scan evidence are recorded. |
Lowering refused | Suppose instead that on 16 March the asset owner asks to lower the priority because the patch window was missed and 'the web application firewall protects it'. The request is refused: the firewall does not change an input, and the reason given is the deadline itself (RM-07, VM-10). The route is an exception request before 17 March (VM-16). |
Control removed | Had the firewall rule been reverted during a change on 20 March, the finding would return to Priority 2 with its 17 March deadline (RM-09), and be reported overdue at once (VM-19). |
How to defend the method to an auditor
An auditor examining vulnerability management under ISO/IEC 27001 will usually test two things this model is designed to show: that the organisation has defined criteria for judging risk which produce consistent, comparable results when applied again (clause 6.1.2), and that it evaluates its exposure to technical vulnerabilities and acts in proportion to that exposure (Annex A 8.8). The evidence below answers both.
Evidence to have ready
- The approved Vulnerability & Exposure Management Standard and this model, with matching deadlines and approval records.
- The Vulnerability Remediation Tracker, showing for each finding its four inputs, priority, deadline, first-detection date and closure evidence.
- The record of every raise and lowering, with who decided and why (RM-06, RM-07).
- The calibration record from the section 'Calibration and review', including the results of the test cases.
- Reports showing deadline adherence by priority (VM-20), so the auditor can see the deadlines are met, not just written.
The re-derivation test
The strongest defence is to invite the auditor to test the method. Pick [[10]] findings from the tracker at random; for each, take the recorded inputs and read the priority from the lookup table. Every result should match the recorded priority, or the difference should be explained by a recorded raise or lowering. Run this test yourself each quarter, so the first time is not in front of the auditor.
Questions auditors commonly ask
Question | Answer the model gives |
|---|---|
Why not simply fix by CVSS score? | A CVSS base score measures the weakness in isolation. It does not know whether attackers are using it or whether the system is reachable. Most Critical-scored findings are never exploited, while some exploited ones score Medium. The model uses CVSS as one input of four. |
How do you know whether something is exploited? | From named, public sources checked every week (RM-11): CISA's Known Exploited Vulnerabilities catalogue, vendor advisories and [[named national or sector sources]]. The check is recorded in the triage notes. |
Who can change a priority, and how is that controlled? | Anyone may propose making a finding more urgent. Only the standard owner may make it less urgent, only when a control changes an input, never because of a deadline, and always with a recorded reason (RM-07, VM-10). The clock never restarts (RM-08). |
Are the deadlines achievable? | They were tested against [[three]] months of findings before approval, and adherence is reported monthly. See 'Calibration and review'. |
Does this meet payment card requirements? | Where the payment card standard applies, it expects the organisation to rank vulnerabilities by risk and to install critical security patches within one month. Under this model every Critical or High severity finding, and every exploited finding, falls in Priority 1, 2 or 3 — all 30 days or less. See 'Adapting this template'. |
Limitations
No rating model is complete. These are the known weaknesses of this one, and how they are managed. An auditor is more reassured by a method that states its limits than by one that claims none.
Limitation | Effect | How it is managed |
|---|---|---|
Exploitation sources lag and are incomplete. | A vulnerability may be exploited for days or weeks before it is listed. The Known Exploited Vulnerabilities catalogue lists only vulnerabilities with an identifier (CVE), reliable evidence of exploitation and clear remediation guidance, and draws mainly on US government visibility. | Several sources are checked weekly (RM-11); early-warning signals may raise a priority (RM-06); re-rating uses the date the evidence became known (RM-12). |
CVSS base scores ignore context. | The same score is given whether the system is a test machine or the payment platform, and scanner and vendor scores sometimes differ. | Exposure and criticality are separate inputs. Hand rescoring is treated as a lowering (RM-04). |
Two exposure levels are a simplification. | 'Internal' is not 'safe': an attacker with a foothold through phishing moves between internal systems. Client-side weaknesses are not captured by network exposure. | Exploited internal findings are never below Priority 2. Critical internal systems receive the uplift. |
The model depends on the asset inventory. | Wrong exposure or criticality gives a wrong priority, silently. | Unknown inputs default to the more urgent level (RM-03). Criticality is reviewed with the inventory; coverage is reported under VM-02. |
Findings are rated one at a time. | Several Medium findings that together give an attacker a path to a Critical system are each rated Medium. | Penetration test findings describing a chain are rated at the level of the chain's end result. The triage meeting may raise linked findings (RM-06). |
Deadlines do not reflect effort. | A one-line configuration change and a platform upgrade receive the same deadline. | Findings that cannot be fixed in time go through the exception process, which records the reason and the compensating controls. |
Probability scores are estimates. | EPSS and similar scores are probabilities over a short period and change daily. | They are used only as an early-warning signal to raise a priority, never to lower one. |
Calibration and review
Before approval
- Take the last [[three]] months of scanner findings and rate them with this model.
- Count the findings in each priority, and how many would have missed their deadline.
- If more than a fifth of Priority 2 and 3 findings would have been overdue, add remediation capacity or agree longer deadlines in the standard before approval — not afterwards.
- Have two people rate the same [[20]] findings independently. Every difference shows an anchor that needs clearer wording.
Every quarter
The standard owner reviews the following and records the result. The indicators are signals to investigate, not targets.
Check | Signal that the model needs attention |
|---|---|
Distribution of open findings by priority | Priority 1 regularly above [[5%]] of new findings, or almost everything in Priority 4. |
Deadline adherence by priority (VM-20) | A priority consistently below [[90%]] adherence, which suggests its deadline or capacity is wrong. |
Raises and lowerings | More than [[10%]] of findings adjusted, or the same reason recurring — a sign an anchor should change. |
Missed findings | Any finding rated Priority 3 or 4 that was later used in an incident or listed as exploited before it was fixed. |
Input completeness | Findings where exposure or criticality was defaulted because it was unknown (RM-03). |
Re-derivation test | Any finding whose recorded priority cannot be reproduced from its inputs. |
Calibration test cases
Use these cases to train new triage members and to check any spreadsheet or tool that applies the model. Each must give the expected priority.
Case | Exploited | Severity | Exposure | Criticality | Expected priority | What it tests |
|---|---|---|---|---|---|---|
1 | Exploited | Low | Internet-facing | Standard | Priority 1 | Exploitation beats severity |
2 | No | Critical | Internal | Standard | Priority 3 | Severity alone does not make an emergency |
3 | No | Critical | Internal | Critical | Priority 2 | Criticality raises one level |
4 | No | Medium | Internet-facing | High | Priority 3 | High criticality does not raise |
5 | No | Medium | Internet-facing | Critical | Priority 2 | Raised from 3 to 2 |
6 | No | Low | Internal | Critical | Priority 4 | Low severity is never raised by criticality |
7 | Exploited | High | Internal | High | Priority 2 | Exploited, internal, not Critical |
8 | Exploited | Medium | Internal | Critical | Priority 1 | Exploited on a Critical system |
9 | No | High | Internet-facing | Critical | Priority 2 | Uplift stops at Priority 2 |
10 | No | High | Internal | Not recorded | Priority 2 | Unknown criticality is treated as Critical (rule RM-03) |
Review
This model is reviewed with the Vulnerability & Exposure Management Standard, at least every 12 months, and also when: the standard's deadlines change; a new version of CVSS is adopted by the scanning tool; the criteria of an exploitation source used here change; or a vulnerability rated Priority 3 or 4 contributes to an incident.
Calibration record
Date | Reviewed by | Findings sampled | Mismatches found | Change proposed | Approved by |
|---|---|---|---|---|---|
[[YYYY-MM-DD]] | [[Name]] | [[n]] | [[n]] | [[None / description]] | [[Name]] |
Related documents
Document | Relationship |
|---|---|
Vulnerability & Exposure Management Standard | Sets the priorities, deadlines and the rules for changing a priority that this model applies |
Vulnerability Triage & Remediation Operating Procedure | The weekly meeting at which this model is applied |
Vulnerability Remediation Tracker | Records the inputs, priority and deadline for each finding |
Scan Coverage & Asset Scope Register | Source of exposure and criticality for each system |
Vulnerability Management Metrics Workbook | Reports deadline adherence by priority, used in calibration |
[[Security Exception & Waiver Standard]] | The route when a finding cannot be fixed by its deadline |
[[Risk Management Methodology]] | The organisation's wider risk criteria, which this model applies to vulnerabilities |
Adapting this template
Guidance — delete before approval
Small organisation: keep the lookup table, the deadlines and rules RM-07 and RM-08 unchanged — they are what an auditor tests. You may merge this model into the Vulnerability & Exposure Management Standard as an appendix, rely on the Known Exploited Vulnerabilities catalogue and vendor advisories as your only exploitation sources, and run the calibration checks every six months instead of quarterly.
Regulated financial entity: approve this model within your ICT risk management framework so that it forms part of the documented criteria for ICT risk. Consider treating every system that supports a critical or important function as Critical, so the uplift applies to it. Where cardholder data is in scope, the payment card standard expects vulnerabilities to be ranked by risk and critical security patches installed within one month: record which priorities your organisation treats as 'critical' and 'high' for that purpose (Priorities 1 to 3 all meet the one-month period, and every Critical or High severity finding lands in one of them).
IT run by a service provider: put the lookup table and the deadlines into the service agreement, so the provider's priority matches yours. Keep the rating decision, and every lowering under RM-07, with your own standard owner rather than the provider. Require scan-based evidence when a compensating control is claimed.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); PCI DSS v4.0.1.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Clause 6.1.2 — Information security risk assessment | Whole model; how to defend the method |
ISO/IEC 27001:2022 | Annex A 8.8 — Management of technical vulnerabilities | Decision logic; deadlines |
NIST CSF 2.0 | ID.RA-05 — “Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization” | Inputs; decision logic |
NIST CSF 2.0 | GV.RM-06 — “A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated” | Whole model |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(e) — “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” | Whole model |
DORA — Delegated Regulation (EU) 2024/1774 | Article 10 — vulnerability and patch management, including automated vulnerability scanning at least weekly for ICT assets supporting critical or important functions | Decision logic: prioritising fixes |
PCI DSS v4.0.1 | Requirement 6.3.1 — identifying new security vulnerabilities and ranking them by risk | Scales and criteria |
PCI DSS v4.0.1 | Requirement 6.3.3 — installing patches for critical vulnerabilities within one month of release | Deadlines |
Appendix A — Definitions
Term | Meaning in this model |
|---|---|
Asset criticality | How much a system matters to the business: Critical, High or Standard, as defined in Appendix A of the Vulnerability & Exposure Management Standard. |
Compensating control | A measure that reduces the risk of a vulnerability that cannot yet be fixed. In this model it can lower a priority only if it changes one of the four inputs. |
CVSS | Common Vulnerability Scoring System, published by FIRST — a method for rating the technical severity of a vulnerability from 0.0 to 10.0. |
EPSS | Exploit Prediction Scoring System, published by FIRST — an estimate of the probability that a vulnerability will be exploited in the next 30 days. Used here only as an early-warning signal. |
Exploited vulnerability | A vulnerability with reliable evidence of use in real attacks, such as an entry in CISA's Known Exploited Vulnerabilities catalogue. |
Finding | One vulnerability on one system. The same vulnerability on several systems is several findings. |
First detection | The date the vulnerability was first found on that system. Day 0 for its deadline (VM-08). |
Internet-facing | Reachable from the internet, directly or through a published service, or from networks the organisation does not fully control. |
Known Exploited Vulnerabilities catalogue | A public list, maintained by the US Cybersecurity and Infrastructure Security Agency (CISA), of vulnerabilities known to have been exploited. |
Priority | One of the four levels in section 5.2 of the Vulnerability & Exposure Management Standard, each with its own deadline. |
Re-rating | Assigning a new priority because an input has changed (RM-07, RM-12). |
Uplift | The one-level raise given to findings on Critical systems (RM-05). |