Vulnerability Triage & Remediation Operating Procedure
Defines the weekly operating rhythm from scan output to assigned remediation ticket, including who decides and what evidence closes an item.
Available soon
- Format
- Word
- Size
- 60 KB
- Length
- 17 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- Scope
- Roles
- Triggers and inputs
- Procedure steps
- Decision points
- Outputs and records produced
- Timing targets
- Escalation
- Evidence retained
- Related documents
- Adapting this template
- Framework references
- 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 procedure sets out how [[Organisation Name]] turns scan results into assigned, tracked and verified fixes, every week. It is the working routine behind the Vulnerability & Exposure Management Standard: the Standard says what must happen and by when; this procedure says who does what, in which order, and what record each step leaves.
In practice it is a 30-minute weekly routine: look at new urgent findings, give each one an owner, chase what is late. The preparation before the meeting and the follow-up after it are what make the 30 minutes enough.
It answers three questions for every finding: who decides its priority and owner, who fixes it and by when, and what evidence allows it to be closed.
Scope
This procedure applies to:
- every vulnerability finding on a system in scope of the Vulnerability & Exposure Management Standard, whatever its source — scheduled scans, agent reports, cloud configuration checks, vendor advisories, penetration tests or reports from staff and third parties;
- everyone with a role in the table below, including service providers who operate systems on our behalf.
It does not cover how patches are tested and deployed ([[Patch Management Standard or procedure]]), how an active attack is handled ([[Incident Management Procedure]]), or how scanning tools are configured (the Vulnerability Scanner Configuration Review Checklist).
Guidance — delete before approval
Keep the scope identical to the Standard's. If the Standard excludes a system, this procedure should not quietly include it, or the other way round.
Findings from a penetration test usually arrive as a report, not a scan. Enter them in the tracker with the report date as the detection date and triage them at the next meeting like any other finding.
Roles
Role | What they do in this procedure |
|---|---|
Triage lead [[e.g. Security Analyst, or the Standard owner]] | Prepares the weekly agenda, proposes priority and owner for each new finding, chairs the meeting, raises and updates tickets, verifies closures, sends escalations. Runs the route for Priority 1 findings between meetings. |
Standard owner [[e.g. Head of Information Security]] | Accountable for the routine running every week. Decides disputed priorities and owners. Is the only person who may lower a priority (VM-10) or approve a false positive (VM-14). Can be the triage lead in a small team. |
Asset owners [[e.g. IT Operations Manager, application owner]] | Accept or dispute ownership at the meeting. Fix, mitigate, or request an exception before the deadline. Report fixes with what was done, early enough for a confirming scan. |
Asset owner's manager [[e.g. Head of IT, business unit lead]] | Receives escalations for findings that are late (VM-19) and for Priority 2 findings not fixed by day 10. Frees up time or accepts that an exception is needed. |
Service providers [[e.g. managed IT provider]] | Attend the meeting, or send a written update beforehand, for systems they run. Fix within the contractual deadlines and supply evidence. |
Risk owners [[defined in the risk management methodology]] | Decide exception requests for findings that cannot be fixed on time (VM-17). |
Approver [[e.g. Chief Operating Officer]] | Receives escalations for findings still open 14 days after they became overdue, and any Priority 1 that is not contained. Decides Priority 1 exceptions (VM-18). |
Guidance — delete before approval
One person can hold several roles. In many small organisations the Standard owner is also the triage lead. What must stay separate: the person who fixes a finding should not be the only person who confirms it is fixed.
Triggers and inputs
When this procedure runs
Trigger | What starts | Section |
|---|---|---|
The weekly cycle: [[day and time, e.g. every Tuesday 10:00]] | Preparation, the 30-minute meeting and follow-up | Steps 1 to 13 |
An asset owner reports a finding as fixed | Verification and closure | Steps 14 to 17 |
A new finding is Priority 1, or a vulnerability affecting our systems is reported as exploited | The Priority 1 route, without waiting for the meeting | Steps E1 to E6 |
A new Priority 2 finding appears between meetings | Owner assigned within 2 working days; confirmed at the next meeting | Step 4 |
The first meeting of each quarter | Review of systems no longer supported by their vendor (VM-15) | Step 9 |
Inputs
Input | Where it comes from | Used for |
|---|---|---|
Scan results since the last meeting | [[Your scanning tool(s)]] | New findings, and findings that have disappeared |
Scan completion and login success | [[Your scanning tool(s)]] | Coverage (target 95%, VM-02) and authenticated scan success (target 95%, VM-05) |
Open findings, owners and deadlines | Vulnerability Remediation Tracker or [[your ticketing system]] | Due this week, overdue, awaiting verification |
Asset inventory with owner, criticality and internet exposure | Scan Coverage & Asset Scope Register / [[asset inventory]] | Proposing the owner and the priority |
Known-exploited vulnerability list | [[e.g. CISA Known Exploited Vulnerabilities catalogue, your threat intelligence source]] | Whether a finding is being exploited |
Active exceptions and their expiry dates | [[Exception register]] | Exceptions expiring soon |
Procedure steps
Deadlines are counted in calendar days from the date the vulnerability was first detected on the system, not from the date a ticket is raised or the meeting is held (VM-08). A finding detected the day after a meeting has already used up to a week of its deadline by the next one. That is why Priority 1 and 2 findings are assigned between meetings.
Deadlines the routine works to
These are the deadlines in the Vulnerability & Exposure Management Standard. They are repeated here for convenience; the Standard governs if the two ever differ.
Priority | Typical findings | Deadline to fix | Notes |
|---|---|---|---|
Priority 1 — Emergency | Exploited vulnerability on an internet-facing or Critical system | Mitigate within 72 hours; fix within 7 days | Treat as a potential incident. Notify the standard owner immediately. |
Priority 2 — High | Exploited vulnerability on an internal system; Critical or High severity on an internet-facing system | 14 days | Escalate to asset owner's manager if not fixed by day 10. |
Priority 3 — Medium | Critical or High severity on an internal system; Medium severity on an internet-facing system | 30 days | Meets the PCI DSS one-month requirement for critical patches. |
Priority 4 — Low | Medium severity on internal systems; Low severity anywhere | 90 days | May be addressed through the normal patch cycle. |
How each finding's priority is worked out, including the effect of asset criticality and compensating controls, is set out in the Vulnerability Risk Rating & SLA Model.
Stage 1 — Prepare (before the meeting)
Done by the triage lead by the end of the working day before the meeting. Allow [[60 to 90 minutes]] a week once the routine is established; more for the first few weeks.
Step | What happens | Who | Output |
|---|---|---|---|
1 | Check that last week's scheduled scans ran. Note systems that were not scanned and scans where the login failed. Raise login failures with the system's owner for correction within 5 working days (VM-05). | Triage lead | Coverage note for the agenda |
2 | Export new findings since the last run. Match them against the tracker: a finding already open keeps its original detection date (VM-08). A finding that returns after verified closure is entered as new, with a note that it recurred. | Triage lead | List of new findings |
3 | Propose a priority for each new finding using the Vulnerability Risk Rating & SLA Model: is it being exploited, can an attacker reach it, how severe is it. Anything that comes out as Priority 1 leaves this list and goes to the Priority 1 route (steps E1 to E6) now. | Triage lead | Proposed priorities |
4 | Propose an owner from the asset inventory. Group findings that one action will fix (for example, one missing update across many servers) into one remediation ticket per owner, keeping each finding's own deadline. Raise tickets for Priority 2 findings now, within 2 working days of detection, rather than waiting for the meeting. | Triage lead | Draft tickets; Priority 2 tickets raised |
5 | Build the agenda: new Priority 1 to 3 findings; findings due in the next 7 days; overdue findings; exceptions expiring in the next 14 days; fixes awaiting verification; false-positive claims; coverage and login problems. Send it to attendees. | Triage lead | Agenda, circulated |
Guidance — delete before approval
Priority 4 findings are not discussed one by one. They are assigned in bulk to the owner's normal patch cycle and appear on the agenda only when they are within 7 days of their deadline. This is what keeps the meeting to 30 minutes.
If new findings run into hundreds each week, the cause is usually one or two missing updates across many systems. Grouping by fix action (step 4) turns hundreds of lines into a handful of tickets.
Stage 2 — The 30-minute triage meeting
Chaired by the triage lead. Attended by asset owners, or their delegates, for every system with an item on the agenda, and by service providers for the systems they run. The Standard owner attends when a priority, false positive or ownership needs deciding, if not already the chair.
Minutes | Agenda item | Step |
|---|---|---|
0 – 5 | Priority 1 findings since the last meeting: is the compensating control recorded, is the fix on track? Last week's actions. | 6 |
5 – 15 | New Priority 1 to 3 findings: confirm priority and owner, agree the action. | 7 |
15 – 25 | Due in the next 7 days and overdue: chase, decide escalations, agree exception requests. | 8 |
25 – 30 | Fixes awaiting verification, false-positive claims, coverage and login problems, expiring exceptions. Read back the action list. | 9 |
Step | What happens | Who | Output |
|---|---|---|---|
6 | Review every Priority 1 finding opened or open since the last meeting. Confirm the compensating control and the date it was applied are recorded (VM-09) and the fix is on track for its 7-day deadline. | Triage lead; asset owner | Priority 1 status recorded |
7 | For each new Priority 1 to 3 finding: confirm the priority, confirm the owner, and agree the action — fix, apply a compensating control and fix, or request an exception. Owners who dispute ownership or priority say so now; the Standard owner decides (see Decision points). | Asset owner; Standard owner for disputes | Agreed priority, owner and action per finding |
8 | For each finding due in the next 7 days or already overdue: ask the owner for a date. Record overdue findings without an approved exception and decide who receives the escalation (see Escalation). Agree which owners will request an exception, and by when — it must be before the deadline (VM-16). | Triage lead; asset owner | Escalations decided; exception requests due |
9 | Confirm which reported fixes were verified since the last meeting (steps 14 to 17). Decide false-positive claims (VM-14). Note systems not scanned and logins that failed. Review exceptions expiring in the next 14 days. At the first meeting of each quarter, review the list of systems no longer supported by their vendor (VM-15). | Triage lead; Standard owner | Decisions recorded |
Guidance — delete before approval
Do not let the meeting become a technical working session. If a finding needs more than two minutes of discussion, give it an owner and a date, and take the detail offline.
Hold the meeting even when attendance is thin. A short meeting with a written record is the evidence an auditor will ask for; a cancelled one leaves a gap.
Stage 3 — After the meeting
Step | What happens | Who | Output |
|---|---|---|---|
10 | Raise or update every ticket agreed in the meeting within 1 working day. Each ticket records the asset, priority, owner, detection date and deadline (VM-11). | Triage lead | Tickets in [[your ticketing system]] |
11 | Send the escalations decided in step 8, and on the day they fall due during the week (day 10 for Priority 2; the day after any deadline; 14 days after that). Copy the Standard owner. | Triage lead | Escalation messages |
12 | Record the meeting: date, attendees, decisions (priority changes, false positives, ownership disputes), escalations, and actions with owners. | Triage lead | Meeting record |
13 | Fix, or apply the agreed compensating control, and update the ticket. Request an exception through the [[Security Exception & Waiver Standard]] if the deadline cannot be met — before it passes. | Asset owner or service provider | Ticket updated; exception request if needed |
Closing a finding
A finding is closed only when a later scan confirms it is gone, or when other objective evidence is attached (VM-13). A ticket marked complete is not enough on its own. The finding counts as fixed on the date the confirming scan ran, so the owner reports the fix early enough for that scan to happen before the deadline.
Step | What happens | Who | Output |
|---|---|---|---|
14 | Mark the ticket fixed, awaiting verification, and state what was done (update installed, setting changed, system removed). Report it at least [[2 working days]] before the deadline. | Asset owner or service provider | Ticket awaiting verification |
15 | Confirm the fix: check the next scheduled scan, or run a targeted scan of the affected systems within [[2 working days]] if the deadline is close. For a system that has been removed, check the inventory record and that it no longer answers scans. | Triage lead | Confirming scan or evidence |
16 | If the finding is gone, close it in the tracker with the date and reference of the confirming scan or evidence. If it is still present, reopen the ticket with the original deadline and tell the owner. | Triage lead | Closed finding with evidence, or reopened ticket |
17 | Report the verified closures at the next meeting (step 9). | Triage lead | Closure list |
What evidence closes a finding
Situation | Evidence that closes it | Not enough on its own |
|---|---|---|
Update installed or setting changed | A later scan of the same system no longer reports the finding; or a configuration export or version report showing the fixed state | A ticket marked done; an email saying "patched" |
System retired or removed | Updated asset inventory record and the retirement or change record; the system no longer answers scans | The system simply not appearing in one scan |
False positive | Written reasoning with supporting evidence (for example, the vendor's statement that the fix was included in an update the scanner does not recognise), approved by the Standard owner (VM-14) | The owner's opinion that it does not apply |
Cannot be fixed on time | Not closed. It stays open under an approved exception with a risk owner, compensating controls and an expiry no later than 90 days after approval (VM-17) | — |
Priority 1 findings between meetings
A Priority 1 finding never waits for the weekly meeting. It is treated as a potential incident: mitigate within 72 hours, fix within 7 days, both counted from detection.
Step | What happens | Who | Output |
|---|---|---|---|
E1 | Whoever sees a possible Priority 1 — from a scan, a vendor advisory or news of a vulnerability being exploited — tells the triage lead the same working day. When a widely exploited vulnerability is announced, the triage lead runs a targeted scan of internet-facing systems. | Anyone; triage lead | Report to triage lead; targeted scan |
E2 | Confirm which systems are affected and whether they are internet-facing or Critical. If confirmed, notify the Standard owner immediately and open a Priority 1 ticket with the detection date. | Triage lead | Priority 1 ticket; Standard owner notified |
E3 | Decide with the Standard owner whether to raise it as a security incident under the [[Incident Management Procedure]] — for example, if there are signs the vulnerability has already been used against us. | Standard owner | Incident raised, or reason recorded |
E4 | Apply a compensating control within 72 hours of detection if the fix cannot be installed in that time — block access, disable the affected feature or isolate the system — and record what was done and when (VM-09). | Asset owner or service provider | Compensating control recorded |
E5 | Install the fix within 7 days of detection. If that is not possible, the approver must decide an exception (VM-18) before the deadline. | Asset owner or service provider; approver for exceptions | Fix installed, or exception decided |
E6 | Verify with a targeted scan (steps 15 and 16) and report at the next meeting (step 6). | Triage lead | Closed finding with evidence |
Guidance — delete before approval
Agree now how the triage lead reaches asset owners and the Standard owner out of hours, and who deputises when the triage lead is away. Priority 1 findings tend to be announced on a Friday.
Decision points
Decision | Who decides | Rule | Recorded in |
|---|---|---|---|
Is the finding real, or a false positive? | Standard owner, on the triage lead's or owner's evidence | Closed as false positive only with recorded evidence (VM-14) | Tracker; meeting record |
What priority does it have? | Triage lead proposes; meeting confirms. The Vulnerability Risk Rating & SLA Model is applied, not debated | A priority may be lowered only by the Standard owner, with the reason, and never to avoid a missed deadline (VM-10) | Tracker; meeting record for any change |
Who owns it? | The owner in the asset inventory. If none is recorded or it is disputed, the Standard owner assigns one | Every Priority 1 to 3 finding has a named owner before the meeting ends. The inventory is corrected (VM-01) | Ticket; asset inventory |
Fix, mitigate, or request an exception? | Asset owner proposes; the meeting agrees | Exception requested before the deadline passes (VM-16), decided by the risk owner, or the approver for Priority 1 (VM-17, VM-18) | Ticket; exception register |
Is it closed? | Triage lead | Only on a confirming scan or other objective evidence (VM-13) | Tracker, with evidence reference |
Escalate? | Triage lead, per the Escalation table | Escalation dates follow from the deadline; they are not negotiated in the meeting | Escalation message; meeting record |
Guidance — delete before approval
Disputes over ownership are the most common reason findings go unfixed. Settle them at the meeting, and correct the asset inventory the same week, so the same dispute does not come back.
Worked example — one week's triage
An illustration, not part of the procedure. The meeting is held on 13 Oct 2026; the scheduled internal and external scans ran on Mon 12 Oct.
Finding | Facts checked | Priority and deadline | Decision |
|---|---|---|---|
Remote-access gateway: vendor flaw announced as exploited | Listed as exploited; internet-facing; Critical system. Targeted scan confirmed it on Fri 9 Oct | Priority 1. Mitigate by Mon 12 Oct; fix by Fri 16 Oct | Handled before the meeting (steps E1 to E6): affected feature disabled the same evening; fix scheduled for Wed 14 Oct. Meeting confirms the control is recorded. |
Customer portal web server: High-severity flaw | Not listed as exploited; internet-facing | Priority 2. Fix by Mon 26 Oct; escalate on day 10 (Thu 22 Oct) if open | Ticket raised the morning after the scan (step 4). Web application owner confirms ownership and a fix date. |
Monthly operating system update missing on 32 internal servers, including the finance file server; rated Critical | Not listed as exploited; internal only | Priority 3. Fix by Wed 11 Nov | One ticket to the server team for all 32, installed in the next maintenance window. |
Browser flaw on 41 laptops; rated Medium | Internal; not exploited | Priority 4. Fix by 10 Jan 2027 | Not discussed. Left to automatic browser updates; reappears on the agenda only if open 7 days before its deadline. |
Print server: component reported as out of date | Detected Mon 5 Oct. Administrator shows the vendor's notice that the fix was included in an update the scanner does not recognise | Priority 3 as reported | Standard owner approves closure as a false positive; evidence attached to the tracker (VM-14). |
Production-line PC on an operating system no longer supported by its vendor | Detected Thu 20 Aug; deadline Sat 19 Sept missed; no exception requested | Priority 3. Overdue. Escalated to the owner's manager the day after the deadline, and to the approver on Sun 4 Oct | Owner presents a plan: isolate the PC on its own network segment this week, retire it by [[date]]. Exception request to be submitted by Friday; the finding stays overdue until an exception is approved. Added to the unsupported-systems list (VM-15). |
The meeting took 26 minutes. The record lists six decisions, one false-positive approval, one confirmed escalation, and four actions with owners. Priority 4 findings took no meeting time.
Outputs and records produced
Output | Produced at step | Held in | Maintained by |
|---|---|---|---|
Weekly agenda | 5 | [[Shared location or meeting invite]] | Triage lead |
Remediation tickets with asset, priority, owner, detection date and deadline | 4, 10 | Vulnerability Remediation Tracker / [[ticketing system]] | Triage lead |
Meeting record: attendees, decisions, escalations, actions | 12 | [[Location]] | Triage lead |
Escalation messages | 11 | [[Email or ticket comments]] | Triage lead |
Priority 1 records: detection, compensating control and time applied, fix, verification | E2 to E6 | Vulnerability Remediation Tracker / [[ticketing system]] | Triage lead |
Closure evidence: confirming scan reference or other evidence | 15, 16 | Vulnerability Remediation Tracker / [[ticketing system]] | Triage lead |
False-positive approvals | 9 | Vulnerability Remediation Tracker | Standard owner |
Coverage and login-failure notes | 1 | Scan Coverage & Asset Scope Register | Triage lead |
These records feed the monthly and quarterly reporting in the Vulnerability & Exposure Management Standard (VM-20), calculated with the Vulnerability Management Metrics Workbook.
Timing targets
Activity | Target | Basis |
|---|---|---|
Triage meeting | Weekly, 30 minutes, [[day and time]] | Standard VM-12 |
Preparation (steps 1 to 5) | Complete by the end of the working day before the meeting | This procedure |
Priority 1: report to triage lead | Same working day | This procedure |
Priority 1: compensating control | Within 72 hours of detection | Standard 5.2, VM-09 |
Priority 1: fix | Within 7 days of detection | Standard 5.2 |
Priority 2: owner assigned and ticket raised | Within 2 working days of detection | This procedure |
Priority 2, 3 and 4: fix | 14, 30 and 90 days of detection | Standard 5.2 |
Tickets raised or updated after the meeting | Within 1 working day | This procedure |
Fix reported for verification | At least [[2 working days]] before the deadline | This procedure |
Scan login failures corrected | Within 5 working days | Standard VM-05 |
New systems added to scanning | Before, or within 5 working days of, going live | Standard VM-03 |
Exception requested | Before the deadline passes | Standard VM-16 |
Exception expiry | No later than 90 days after approval; reviewed at the meeting in the 14 days before expiry | Standard VM-17; this procedure |
Unsupported systems reviewed | At the first meeting of each quarter | Standard VM-15 |
Guidance — delete before approval
Targets marked "This procedure" are not in the Standard. They are what makes the Standard's deadlines achievable, and you may change them — but check the result against the Standard's deadlines before you do. For example, a Priority 2 finding assigned only at the weekly meeting may already be 7 days old, leaving 3 days before the day-10 escalation.
Escalation
When | Escalated to | By | Basis |
|---|---|---|---|
Priority 2 finding still open on day 10 | Asset owner's manager | Triage lead | Standard 5.2 |
Any finding past its deadline without an approved exception | Asset owner's manager; reported as overdue | Triage lead, the day after the deadline | Standard VM-19 |
Still open 14 days after that escalation | Approver | Standard owner | Standard VM-19 |
Priority 1 without a compensating control at 72 hours | Approver, and the incident process | Standard owner, immediately | Standard VM-09; this procedure |
Ownership or priority dispute not settled in the meeting | Standard owner decides within [[2 working days]] | Triage lead | This procedure |
Service provider misses a deadline | [[Supplier or contract manager]], under the service agreement | Triage lead | Service agreement |
An escalation states the finding, the system, the priority, the detection date, the deadline, how many days it is late, and what decision is needed. It asks for a decision — more time or people, a compensating control, or an exception request — rather than simply reporting a delay.
Guidance — delete before approval
Escalation is not a punishment. It exists to move a decision to someone who can free up time or accept the risk. Findings that are escalated often usually point to a capacity problem, which belongs in the monthly report.
Evidence retained
Keep the following so an auditor or reviewer can follow any finding from detection to closure. Retention periods should match the Records to keep section of the Vulnerability & Exposure Management Standard.
Evidence | Shows | Minimum retention |
|---|---|---|
Scan results and scan schedules | Detection dates; confirming scans | [[12 months]] |
Tracker or tickets, with closure evidence | Every finding's owner, deadline and verified closure (VM-11, VM-13) | [[3 years]] |
Weekly meeting records | The routine ran every week, and the decisions made (VM-12) | [[3 years]] |
False-positive approvals | Who approved and on what evidence (VM-14) | [[3 years]] |
Priority 1 records | Compensating control within 72 hours; fix within 7 days (VM-09) | [[3 years]] |
Escalation messages | Overdue findings were escalated on time (VM-19) | [[3 years]] |
Exception requests and decisions | Requested before the deadline; approved by the right person (VM-16 to VM-18) | [[3 years after expiry]] |
Guidance — delete before approval
An auditor typically picks a handful of findings and asks to see each one's detection date, owner, deadline, and the scan that proved it was fixed. Test this yourself once a quarter on five findings.
Related documents
Document | Relationship |
|---|---|
Vulnerability & Exposure Management Standard | The rules this procedure runs: deadlines, verification, exceptions, escalation |
Vulnerability Risk Rating & SLA Model | How priority is worked out (step 3) |
Vulnerability Remediation Tracker | Where findings, owners, deadlines and closure evidence are recorded |
Scan Coverage & Asset Scope Register | Which systems are scanned, and their owners (steps 1 and 4) |
Vulnerability Scanner Configuration Review Checklist | Keeping scan results complete and trustworthy |
Vulnerability Management Metrics Workbook | Turns the tracker into the monthly report |
[[Security Exception & Waiver Standard]] | How exceptions are requested and decided |
[[Incident Management Procedure]] | Where a Priority 1 finding goes if it may already have been used against us |
[[Patch Management Standard or procedure]] | How fixes are tested and deployed |
Adapting this template
Guidance — delete before approval
Small organisation: the Standard owner can be the triage lead, and the meeting can be a 15-minute call with IT. If volumes are low you may move to a meeting every two weeks — but the Standard requires at least weekly triage (VM-12), so change the Standard at the same time, and keep assigning Priority 1 and 2 findings between meetings, or Priority 2 deadlines cannot be met.
Regulated financial entity: treat the meeting record and escalations as evidence for your ICT risk management framework and keep them for the period your regulator expects (typically at least five years). Link the Priority 1 route to your ICT-related incident classification, and check that systems supporting critical or important functions are always on the agenda when they have open findings.
IT run by a service provider: keep the triage lead role in-house. Ask the provider to attend the meeting or send a written update beforehand, to reference your ticket numbers in its own system, and to report fixes in time for a confirming scan. Do not accept the provider's own "closed" status as evidence (step 15).
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 | Annex A 8.8 — Management of technical vulnerabilities | Whole procedure |
ISO/IEC 27001:2022 | Annex A 5.37 — Documented operating procedures | Whole procedure |
NIST CSF 2.0 | ID.RA-01 — “Vulnerabilities in assets are identified, validated, and recorded” | Steps 1 to 4; false positives |
NIST CSF 2.0 | ID.RA-06 — “Risk responses are chosen, prioritized, planned, tracked, and communicated” | Steps 3 to 13; decision points |
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 procedure |
DORA — Regulation (EU) 2022/2554 | Article 9 — protection and prevention, including documented policies for patches and updates (Article 9(4)(f)) | Whole procedure |
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 | Steps 10 to 17: tracking and verifying fixes |
PCI DSS v4.0.1 | Requirement 6.3.1 — identifying new security vulnerabilities and ranking them by risk | Step 3 |
PCI DSS v4.0.1 | Requirement 11.3.1 — internal vulnerability scans at least every three months, with rescans to confirm fixes | Steps 14 to 17 |
Definitions
Term | Meaning in this procedure |
|---|---|
Compensating control | A measure that reduces the risk of a vulnerability that cannot yet be fixed, such as blocking network access to the affected service or disabling the affected feature. |
Detection date | The date the vulnerability was first reported on the system by any source. Deadlines count from it (VM-08). |
Escalation | Passing a late or disputed finding to a named manager so that a decision is made about it. |
Exception | An approved, time-limited decision not to fix a vulnerability by its deadline, with a named risk owner and compensating controls. It does not close the finding. |
Exploited vulnerability | A vulnerability with reliable evidence of use in real attacks, such as an entry in the US Cybersecurity and Infrastructure Security Agency (CISA) Known Exploited Vulnerabilities catalogue. |
False positive | A finding reported by a scanner that is shown, with evidence, not to exist on the system. |
Finding | One vulnerability reported on one system. |
Internet-facing | Reachable from the internet, directly or through a published service, without first connecting to the organisation's private network. |
Remediation ticket | A task in the ticketing system or tracker that assigns one fix action to one owner. It may cover several findings. |
Triage | Deciding, for each new finding, whether it is real, how urgent it is, and who owns it. |
Verified closure | Closing a finding on the evidence of a later scan, or other objective evidence, that it is no longer present (VM-13). |