Scanning is the easy half of vulnerability management. The half that fails audits is everything after the scan: checking that every asset was actually covered, deciding what matters this month, getting fixes onto the right team’s plate, handling the findings nobody can fix in time, and confirming with a rescan that the problem has gone. This free vulnerability management checklist turns that cycle into a repeatable monthly run. It covers scan coverage, triage with CVSS, EPSS and the CISA Known Exploited Vulnerabilities catalogue, remediation deadlines by priority, time-limited risk exceptions with a named approver, rescan verification and a signed monthly report. Each cycle leaves a record that an ISO 27001 auditor, a PCI QSA or a SOC 2 assessor can follow from finding to closure.
The two terms get used interchangeably, and that is where findings go missing. Patch management is an IT operations process: test the update, schedule it, deploy it, confirm it installed. Vulnerability management is the security process that decides what needs fixing, by when, and whether a patch is even the answer. Plenty of findings have no patch at all. They need a configuration change, a retired service or a documented decision to live with the risk for a while.
Prioritisation is where most teams struggle. A CVSS v4.0 base score measures how bad a flaw could be in general, not how likely it is to hurt you. FIRST’s EPSS adds a daily estimate of the probability that a CVE will be exploited in the next 30 days, and FIRST warns against multiplying the two together. CISA’s KEV catalogue lists vulnerabilities already being exploited in the wild. In June 2026 CISA’s BOD 26-04 replaced BOD 22-01 for US federal civilian agencies. It sets deadlines by internet exposure, KEV status, whether exploitation can be automated and the level of control an attacker gains, ranging from 3 days for the worst combination to fixing at the next upgrade for vulnerabilities not in KEV. Private organisations are not bound by it, but it is a useful model for your own tiers.
Question it answers: did the update install everywhere it should?
Cadence: vendor release cycles, such as monthly OS updates.
Output: deployment reports and change records.
Tooling: endpoint management and deployment systems.
Question it answers: which weaknesses matter here, and are they gone?
Cadence: a monthly cycle, with emergency handling for actively exploited flaws.
Output: prioritised findings, deadlines, approved exceptions and verified closures.
Tooling: scanners for detection, plus a checklist for decisions and evidence.
Scanning also only finds what a scanner can see. An annual penetration test tests whether findings can be chained into a real compromise, and its results should land in this same remediation queue.
Six phases take each monthly cycle from scan coverage to a signed report. The exception phase switches on only when a finding cannot be fixed on time.
Assigned to the vulnerability management lead. A clean report means nothing if a third of the estate was never scanned.
If a KEV-listed finding sits on an internet-facing asset, an emergency task appears here automatically.
Switches on when any finding is marked “exception requested”. The approver is the business risk owner, never the engineer asking.
The CISO or security lead owns this phase personally, separate from whoever compiled the numbers.
Every major framework expects a vulnerability process that is defined, followed and evidenced. Few of them prescribe your deadlines. The table shows the controls this cycle produces evidence for, using ISO/IEC 27001:2022, PCI DSS v4.0.1, SOC 2 (2017 criteria, points of focus revised in 2022) and CIS Controls v8.1. Treat it as a starting point for your own control mapping, not legal or audit advice.
| Framework | Control | What it expects | Evidenced in |
|---|---|---|---|
| ISO/IEC 27001:2022 | A.8.8 Management of technical vulnerabilities | Obtain vulnerability information, evaluate your exposure and take appropriate measures | Phases 1–5 |
| PCI DSS v4.0.1 | 6.3.1 | New vulnerabilities identified from industry sources and risk-ranked, with high-risk and critical ones identified | Phase 2 |
| PCI DSS v4.0.1 | 6.3.3 | Patches for critical vulnerabilities installed within one month of release | Phase 3 |
| PCI DSS v4.0.1 | 11.3.1 (with 11.3.1.1–11.3.1.3) | Internal scans at least once every three months and after significant change, authenticated where possible; high and critical findings resolved and rescanned | Phases 1 and 5 |
| PCI DSS v4.0.1 | 11.3.2 | External scans at least once every three months by an Approved Scanning Vendor, rescanned until passing | Phase 5 |
| SOC 2 | CC7.1 | Detection and monitoring procedures that identify configuration changes introducing vulnerabilities and exposure to newly discovered ones | Phases 1–2 |
| CIS Controls v8.1 | Control 7 (7.1–7.7) | A documented process; internal scans quarterly or more often, external scans and remediation monthly or more often | Phases 1, 3 and 6 |
For your SLA table, use the frameworks as floors rather than targets. PCI DSS fixes one month for critical patches and CIS asks for monthly remediation, while BOD 26-04 shows how a regulator now separates a 3-day emergency from a finding that can wait for the next upgrade. The wider framework work sits in the PCI DSS 4.0 Compliance Checklist and the SOC 2 Readiness Checklist.
A recurring schedule opens the run after your scan window closes and assigns coverage checks to the lead. Last month’s open items are carried forward, so a finding cannot quietly fall out of view between cycles.
Conditional logic shows the exception tasks only when they are needed, and the risk owner’s approval is recorded against each one. Every accepted risk carries an expiry, a reason and the person who agreed to it.
Scan extracts, change references and rescan reports are attached to the tasks they prove. When an auditor samples a critical finding, you export the cycle and show who triaged it, who fixed it and when the rescan confirmed it.
CheckFlow is not a scanner, and it does not replace one. It runs the triage, decision and sign-off work around the scanner’s output. CheckFlow’s compliance checklist software shows how recurring reviews, owners and approvals fit your wider control calendar, and our ISO 27001 checklist guide explains where control A.8.8 sits within the whole ISMS.
Cloud misconfigurations rarely show up in a network scan, so pair this cycle with the quarterly Cloud Security Review Checklist. Changes raised from Phase 3 can follow the IT Change Management Process Template.
Deployment itself follows the Patch Management Checklist, and scan coverage in Phase 1 is only as complete as the IT Asset Management Checklist behind it. Once a year, the IT Security Audit Checklist checks that the whole cycle is working.
Describe the process in a sentence and the AI checklist generator drafts the phases and tasks for you.
It should cover the whole loop, not just the scan. That means confirming scan coverage against the asset inventory, triaging findings with exploit and business context, assigning owners and deadlines, handling exceptions with an expiry and a named approver, verifying fixes with a rescan and reporting the results. A checklist that stops at “run the scan” produces reports, not reduced risk.
It depends on the framework and your risk. Under PCI DSS v4.0.1, internal scans and ASV external scans must both run at least once every three months and after significant change. CIS Controls v8.1 asks for internal scans quarterly or more often and external scans monthly or more often. Many teams now scan continuously or weekly and run the review cycle monthly, so decisions keep pace with detection.
Use all three for different jobs. CVSS describes severity, EPSS estimates the chance of exploitation in the next 30 days, and KEV confirms exploitation is already happening. A common approach treats anything in KEV on an exposed asset as urgent, uses EPSS to separate likely from unlikely threats among the rest, and uses CVSS and asset criticality to break ties. Keep the scores as separate inputs rather than combining them into one number.
No. Binding Operational Directive 26-04, issued on 10 June 2026, applies to US federal civilian executive branch agencies, and it revoked the earlier BOD 22-01 and BOD 19-02. Contractors are only covered where their contracts say so. Private organisations often borrow its logic anyway, because tiering deadlines by exposure and active exploitation is easier to defend than one flat deadline per severity.
It becomes an exception, not a silent overdue item. The template records why the deadline cannot be met, what compensating controls reduce the risk, and when the exception expires. The business risk owner approves or rejects it. When the expiry arrives, the finding comes back into the monthly cycle for renewal or remediation.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
14-day free trial, no credit cardFull refund in your first 30 daysUS hosting, EU on request
