A one page vulnerability management checklist has seven steps: list what you run, scan it, rank the findings, decide fix or accept for each, fix with an owner and date, verify with a rescan, and review the numbers. Repeat it weekly. Each step below has a short test you can answer yes or no.
TL;DR
- Seven steps, repeated weekly: list, scan, rank, decide, fix, verify, review.
- Each step has a yes or no test, so you know when it is done.
- Keep a short exception rule for items you cannot fix yet.
- Print it, pin it, and use it as the agenda of a fifteen minute weekly meeting.
Why use a checklist at all?
Pilots use checklists not because they forget how to fly, but because skipped steps are costly and easy to miss. Vulnerability management has the same shape. Each step is simple. The risk is skipping one under pressure, usually the list at the start or the rescan at the end.
A vulnerability is a flaw in software that someone could misuse. Vulnerability management is the routine of finding, ranking and fixing those flaws. If you want background first, read what vulnerability management is.
What are the seven steps?
Step 1: List what you run
Do you have a current list of your applications, the packages inside them, and an owner for each?
Yes means: every application and service is on the list, with a named owner, and anything retired is marked. How to build one is in how to list your software before scanning.
Step 2: Scan
Did a scan run on every item in the last seven days, and does it cover both code and deployed software?
Yes means: no item on the list went unscanned, and the date of the last scan is recorded. New flaws are published daily, so old results go stale.
Step 3: Rank
For each new finding, did you ask four questions: is it exploited, is the code reachable, is the system exposed, does it matter?
Yes means: every new finding has a priority label. CISA says organizations should use its Known Exploited Vulnerabilities catalog as an input to prioritization. FIRST says a base CVSS score measures severity and should not be used alone to assess risk. See ranking hundreds of vulnerabilities with four questions.
Step 4: Decide
For every ranked finding, is there a written decision: fix now, fix later with a date, mitigate, or accept for a limited time?
Yes means: nothing sits in an unnamed limbo. Accepted items have a reason, an owner and an end date. See accepting an unfixable vulnerability.
Step 5: Fix
Does each fix have an owner, a due date and a clear instruction that names the lowest fixed version?
Yes means: a developer reading the ticket can start without asking questions. See what a good ticket says and what fix available means.
Step 6: Verify
After the change, did a new scan of the deployed software confirm the finding is gone?
Yes means: the ticket links to proof. If the finding came back, look at why fixed vulnerabilities keep showing up.
Step 7: Review
Did you look at five numbers this week?
- Open findings on the known exploited list that run in your environment.
- Age of your oldest high priority item.
- Findings closed this week.
- New findings this week.
- Exceptions past their end date.
Yes means: the numbers are written down and compared to last week.
What does the checklist look like on one page?
| Step | Question | Done when |
|---|---|---|
| 1. List | Is every app and owner listed? | Nothing unlisted, retired items marked |
| 2. Scan | Did every item get scanned this week? | Scan date recorded for each |
| 3. Rank | Does every new finding have a priority? | Four questions answered |
| 4. Decide | Does each finding have a decision? | Fix, mitigate or accept with end date |
| 5. Fix | Does each fix have an owner and date? | Ticket is actionable |
| 6. Verify | Did a rescan confirm the fix? | Proof linked |
| 7. Review | Were the five numbers checked? | Written down |
How do you run it as a fifteen minute weekly meeting?
Use the steps as an agenda.
- Minutes 0 to 3: new items on the list, anything retired.
- Minutes 3 to 6: scan coverage and new findings.
- Minutes 6 to 10: rank the new findings, starting with any on the known exploited list.
- Minutes 10 to 13: confirm owners and dates, and check exceptions near expiry.
- Minutes 13 to 15: read the five numbers and note anything odd.
Keep notes in one shared place. The notes become your evidence if a customer or auditor asks how you manage vulnerabilities, without you needing to claim anything more than you do.
A worked example with invented numbers
These numbers are invented to show the weekly rhythm. They are not from a real company.
A small team runs the checklist on Monday.
| Number | Last week | This week |
|---|---|---|
| Known exploited flaws open | 2 | 1 |
| Oldest high item (days) | 21 | 28 |
| Closed | 6 | 9 |
| New | 11 | 7 |
| Exceptions past end date | 0 | 1 |
What the team notices: one exploited flaw closed, which is good. But the oldest high item grew from 21 to 28 days. They see that its ticket has no owner, so they assign one. They also find an exception that expired, and either renew it with a reason or schedule the fix. Nine closed against seven new means the backlog is shrinking. Total time: fifteen minutes and two small actions.
What if you only have ten minutes this week?
Do steps 3 and 6 first. Rank new findings so the exploited ones surface, and verify fixes already made. Those two catch the most danger per minute. Return to the others next week.
Try it yourself
Click through it at your own pace, or open it full screen. Compare the options for handling a finding, which maps to step 4 of the checklist.
How can Safeguard help?
Safeguard supports the steps with SBOM and dependency scanning, asset discovery, reachability analysis and policies and gates. Compliance and evidence automation can keep records of your weekly review. Autonomous remediation with fix pull requests is available but off by default, with every category on Manual, so you decide when a fix is proposed or applied. Start with the free scan at gold.safeguard.sh/scan.
Quick check
How long should the weekly review take?
About fifteen minutes for a small team once the list and the tooling exist. The first few weeks take longer.
What if I find more findings than I can handle in a week?
Rank them, fix the top group, and record a decision for the rest. The checklist keeps the backlog visible and ordered.
Is this checklist enough for an audit?
It gives you a repeatable process and written records. What an auditor requires depends on the audit, so check the specific requirements.
Sources
Last reviewed: 19 October 2026.
