Vulnerability Management Operating Pack — Guide
- Version 1.1
- Updated
- Next review
Vulnerability Management Pack
Your scanner reports hundreds or thousands of issues. Nobody agrees which ones matter, who should fix them, or by when. This pack gives you ready-made documents to settle those three questions and keep them settled.
Is this for you?
This pack is for you if:
- you have been made responsible for vulnerabilities, but security is not your only job;
- findings keep piling up and old ones never seem to get fixed;
- an auditor, regulator or customer is about to ask how you handle vulnerabilities.
You will need some way of scanning your systems. If you have none yet, start there.
Start with these three
You do not need all ten documents. Most teams get the biggest improvement from three:
- Risk Rating & Deadline Model — decides which findings to fix first and how long each may stay open. It looks at whether a weakness is being exploited and whether the system faces the internet, not just the scanner’s severity label.
- Weekly Triage & Remediation Procedure — a 30-minute weekly routine: look at new urgent findings, give each one an owner, chase what is late.
- Remediation Tracker — one list of open findings with owner, deadline and status. A finding only counts as fixed when a new scan confirms it.
Not sure where you stand? Take the free 15-minute self-assessment first. It tells you which documents will help most.
A simple 90-day plan
| When | What to do | You’re done when |
|---|---|---|
| Month 1 | Agree priorities and deadlines with IT. Give every group of systems a named owner. | IT and security accept the deadlines. |
| Month 2 | Run the weekly routine. Check which systems your scanner is missing. | The weekly meeting has run four times. |
| Month 3 | Get the rules approved by management and send your first short report. | Management has made a decision based on it. |
Everything in the pack
| Document | What it does | Format |
|---|---|---|
| Vulnerability Management Standard | The rules management approves: what is scanned, how often, and the deadlines | Word |
| Weekly Triage & Remediation Procedure | The weekly routine, step by step | Word |
| Risk Rating & Deadline Model | How to decide what gets fixed first | Word |
| Scan Coverage Register | Shows which of your systems are not being scanned | Excel |
| Remediation Tracker | Tracks each finding until it is confirmed fixed | Excel |
| Scanner Set-up Checklist | Checks your scanner is giving you complete, trustworthy results | Excel |
| Metrics Workbook | Four numbers management can act on, calculated for you | Excel |
| Self-Assessment | Scores your current approach and suggests next steps | Online / Excel |
| Management Briefing Deck | Slides for your monthly or quarterly update | PowerPoint |
Adapting it
- Small team: the Standard asks for a weekly meeting, because the deadlines are short: a Priority 1 finding must be mitigated within 72 hours and fixed within 7 days, and 14 days is the tightest deadline for non-emergency findings, so a finding that waits two weeks to be discussed is already late. If you have few new findings, you can meet every two weeks instead: change the Standard to say so, and keep giving urgent findings an owner as soon as they appear. You can skip the slide deck at first.
- IT run by an outside provider: put the deadlines into your agreement with them, and ask for scan results, not just “done” updates.
- Regulated firm (banking, investment, payments): keep the scan coverage register up to date, because supervisors will ask which critical systems are covered.
Not covered here
Installing patches (Patch Management pack), penetration testing, handling a live attack (Incident Management pack), and choosing a scanning product.
What changed
Each change to this pack's documents since it was published, newest first.Changes across all packs
The Priority 3 note no longer says 30 days meets the payment card standard; it says that standard's month runs from the patch's release, not from detection.
The payment card question, the Priority 3 note and the regulated-entity adaptation no longer say Priorities 1 to 3 meet that standard's one-month period; its month runs from the patch's release, not from detection, so a late-detected finding can miss it inside its own deadline.
- Vulnerability Risk Rating & SLA Model 1.2 → 1.3
Unknown exploitation evidence is treated as not known exploited and checked again at the next weekly triage, as the Inputs table says; the paragraph under the table and the inventory limitation no longer say every missing input makes a finding more urgent.
- Vulnerability Risk Rating & SLA Model 1.1 → 1.2
The small-team note gives the deadlines behind the weekly meeting: a Priority 1 finding is mitigated within 72 hours and fixed within 7 days, and 14 days is the tightest deadline for other findings.
- Guide 1.0 → 1.1
The definition of internet-facing now also names third-party connections, and every P01 document uses it word for word. Section 4.3: fixes are proved by a targeted rescan, so closure never waits for the scanning schedule; internet-facing web applications are scanned at least monthly and internal ones quarterly. Section 7 defers to the organisation's exception standard, and the more senior approver and the shorter duration apply.
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. Priority 1 exceptions go to the approver the Standard's VM-18 names, which may be the more senior approver of the organisation's exception standard.
The definition of internet-facing now names partner links, guest Wi-Fi and third-party connections, word for word as the Standard has it. A Priority 1 exception goes to the approver the Standard's VM-18 names, which may be the more senior approver of the organisation's exception standard.
- Vulnerability Risk Rating & SLA Model 1.0 → 1.1
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. The As-at date ships as a fixed date instead of TODAY(), so the file does not change from day to day; set it to today's date or type =TODAY(). The frequencies note now covers end-user devices and internet-facing web applications.
- Scan Coverage & Asset Scope Register 1.0 → 1.1
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. A two-weekly review now carries the Standard's two conditions. The Suggested priority now applies the model's criticality uplift (RM-05). Priority 1 exceptions go to the approver VM-18 names. The As-at date ships as a fixed date instead of TODAY(), so the file does not change from day to day; set it to today's date or type =TODAY().
- Vulnerability Remediation Tracker 1.0 → 1.1
Internet-facing now includes partner links, guest Wi-Fi and third-party connections, as the Standard defines it. SF-06 checks internet-facing web applications at least monthly and internal ones at least quarterly, as the Standard now sets them. SF-04 and SF-05 say plainly that end-user devices are scanned continuously by an agent or at least monthly, and cloud infrastructure assessed continuously by a posture tool or at least weekly.
The definition of Priority now names all four inputs of the Vulnerability Risk Rating & SLA Model, asset criticality included. EXAMPLE finding VUL-0005 is on a High criticality system, so its suggested Priority 3 is what the model gives (a Critical system would be raised to Priority 2, RM-05).
PRI-01's Defined level and the Prioritisation action now include asset criticality, the fourth input of the Vulnerability Risk Rating & SLA Model. A two-weekly triage counts for OWN-02 only with the Standard's two conditions.
The exceptions slide's notes name the approver the Standard's VM-18 now names for Priority 1 exceptions.
Published. The guide and nine documents, at 1.0.