Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What does a vulnerability management program checklist cover?
Updated
A vulnerability management program checklist groups the operational building blocks — asset inventory, scan coverage, ownership, remediation SLAs, prioritization signals, exceptions, evidence, and reporting cadence — against named framework sources. Not legal advice; it does not determine that any control, standard, or SLA applies to YOU.
Program checklist, last verified 10 September 2026 against NIST SP 800-40 Revision 4, NIST SP 800-53 Revision 5 controls RA-5 and SI-2, CIS Critical Security Controls v8.1 Controls 7 and 12, ISO/IEC 27001:2022 Annex A control 8.8, and AICPA 2017 Trust Services Criteria (with 2022 points of focus) CC7.1. It is not legal advice, not an audit, not a certification determination, and not a substitute for counsel or your auditor.
This is a checklist, not YOUR audit
Audience: a security lead, engineering manager, or compliance owner assembling or reviewing a vulnerability management program. This page is not legal advice. It does not start a clock. Reading it does not start a clock. Checking a row is not a determination that NIST SP 800-53 applies to YOU, that ISO/IEC 27001 certification requirements are met, that a SOC 2 auditor would accept the evidence, or that a control is operating effectively. This page does not patch YOUR estate. A named human still owns the SLAs, the exceptions, and the risk-acceptance sign-offs.
This corpus has no downloadable-file field. The master table below is the checklist — a structured, citable artifact, not a PDF to print and not a signed-in wizard that ticks boxes for you. Copy the table into your own tracker; this page does not track it for you.
- Kind of text matters: NIST SP 800-40r4 is voluntary NIST guidance. NIST SP 800-53 RA-5 and SI-2 are controls in a catalog that is a legal requirement only for organizations bound to implement it (federal information systems under FISMA, or contractors where a contract flows that requirement down) — otherwise it is a voluntary reference. CIS Controls 7 and 12 are best practice published by a nonprofit, not a legal mandate. ISO/IEC 27001:2022 Annex A control 8.8 is a certifiable management-system requirement only if your organization has chosen to seek or maintain that certification. AICPA Trust Services Criteria CC7.1 is an attestation criterion that binds you only if you have chosen to pursue a SOC 2 report. This page quotes which kind of text each row relies on.
- A dedicated what-is-vulnerability-management pillar is not on this site yet. Naming it is not a link. Live siblings on this site: vulnerability remediation SLAs, how to track accepted security risk, and how to prove vulnerabilities were remediated. This checklist links to all three rather than restating them.
Master checklist — area, kind of text, framework source
One table, grouped by program area. Each row is tagged as a legal requirement (only if the named framework binds you), framework guidance, best practice, or an SRM-recommendation — this page's own suggestion where no named framework states the specific rule. A checked row is not a finding that YOUR program conforms to any of the named texts. Last verified 10 September 2026. Not legal advice.
| Area | Checklist item | Kind of text | Framework source |
|---|---|---|---|
| Asset inventory | Maintain a current inventory of enterprise assets — including cloud, container, and short-lived compute — in scope for vulnerability management. | Best practice. A legal requirement only for organizations pursuing ISO/IEC 27001 or SOC 2 attestation that names asset inventory as supporting evidence. | CIS Controls v8.1 Control 1 (asset inventory) underlies Control 7. ISO/IEC 27001:2022 Annex A 8.8 supplementary guidance names an asset inventory as a precondition. |
| Asset inventory | Maintain a software bill of materials, or equivalent dependency inventory, so a newly disclosed CVE can be matched to the components that contain it. | SRM-recommendation, supported by best-practice sources. Not itself a named legal requirement in the sources this page cites. | NIST SP 800-40r4 discusses software inventory as a patch-management input. See also the SBOM guide on this site. |
| Scan coverage | Run both authenticated and unauthenticated scans of internal enterprise assets on a defined, documented cadence. | Best practice. CIS suggests quarterly-or-more-frequent as a Safeguard; it is not a statute. | CIS Controls v8.1 Safeguard 7.5. |
| Scan coverage | Run vulnerability scans of externally-exposed assets on a defined, documented cadence, distinct from the internal cadence. | Best practice. | CIS Controls v8.1 Safeguard 7.6. |
| Scan coverage | Cover first-party code (SAST), open-source dependencies (software composition analysis), running systems (DAST), committed secrets, and infrastructure-as-code, not scanning alone. | SRM-recommendation. Named frameworks describe scanning generally; none of the cited sources mandates this specific multi-source list. | NIST SP 800-53 RA-5 discusses standards for enumerating platforms and software flaws; it does not name each scanner category. |
| Scan coverage | In reporting, distinguish 'scanned and clean' from 'never scanned.' A zero from an asset that was never covered is a blind spot, not a result. | SRM-recommendation. | Not stated verbatim in any cited source; consistent with RA-5's breadth-and-depth-of-coverage intent. |
| Ownership | Assign a named owner for each asset class or maintenance group, and a named owner for the overall remediation process. | Best-practice guidance. ISO/IEC 27001:2022 Annex A 8.8 supplementary guidance calls for defined accountability; that clause binds you only if certifying. | NIST SP 800-40r4 §3.4 (assign assets to maintenance groups). ISO/IEC 27001:2022 Annex A 8.8. |
| Ownership | Define an escalation path — a named second owner, not just a Slack channel — for when a finding owner misses its remediation SLA. | SRM-recommendation. | Not named in the cited sources. |
| SLAs | Document a risk-based remediation strategy in a written remediation process, reviewed on a defined, recurring cadence. | Best practice. CIS suggests monthly-or-more-frequent review; it is not a statute. | CIS Controls v8.1 Safeguard 7.2. |
| SLAs | Install security-relevant software and firmware updates within an organization-defined time period after release, and incorporate that remediation into configuration-management tracking. | Legal requirement — only for organizations bound to implement NIST SP 800-53 (federal information systems, or contractors under a flow-down clause). Otherwise a voluntary reference control. | NIST SP 800-53 Rev. 5 control SI-2, part (c) and (d). |
| SLAs | Set differentiated remediation timeframes by risk tier — for example, KEV-listed or internet-facing critical findings on the shortest clock — rather than one flat SLA for every severity. | SRM-recommendation, informed by NIST guidance on maintenance-group risk response. | NIST SP 800-40r4 §3.3 (define risk response scenarios). |
| Prioritization signals | Rank findings using CVSS base severity together with confirmed exploitation (the CISA KEV catalog) and exploitation-probability signals (FIRST EPSS), not CVSS severity alone. | Best practice, widely published; not a single named legal mandate for private-sector use. | NIST SP 800-53 RA-5 discussion references CVSS for measuring vulnerability impact as one input among several. |
| Prioritization signals | Confirm whether the affected asset is actually exposed or reachable before treating a finding as the most urgent tier. | Best practice. | Consistent with RA-5's asset-context discussion; not a distinct named control. |
| Exceptions / risk acceptance | Record a formal, time-boxed exception for any finding not remediated within its SLA, naming an accountable owner and an expiry date. | Requirement only if pursuing ISO/IEC 27001 or SOC 2 attestation that tests risk-acceptance evidence; otherwise best practice. | ISO/IEC 27001:2022 Annex A 8.8 supplementary guidance (documented decisions). AICPA TSC risk-assessment criteria (CC3 series) discuss risk acceptance as a control activity. |
| Exceptions / risk acceptance | Review open exceptions on a defined recurring cadence rather than letting them run indefinitely. | SRM-recommendation. | Not separately named in the cited sources; consistent with CC4.1 monitoring intent. |
| Evidence | Retain scan reports, remediation tickets, and re-scan or re-test evidence that ties a specific finding to its closure. | Requirement only if pursuing SOC 2 attestation or ISO/IEC 27001 certification that an auditor will test; otherwise best practice. | AICPA TSC CC7.1 points of focus (vulnerability scanning and remediation evidence). ISO/IEC 27001:2022 Annex A 8.8 audit-trail guidance. |
| Evidence | Deduplicate a shared-library CVE to one distinct finding rather than counting it once per affected repository or occurrence, when reporting totals. | Best practice / SRM-recommendation for honest reporting. | Not named verbatim in the cited sources. |
| Reporting cadence | Report open-versus-fixed counts, SLA adherence by severity, and the age of the oldest open critical finding to a named owner on a recurring cadence. | Best practice. CIS suggests monthly-or-more-frequent review of the remediation process itself. | CIS Controls v8.1 Safeguard 7.2. |
| Reporting cadence | Escalate overdue critical findings to leadership on a defined cadence, not only when an audit or assessment asks for the number. | SRM-recommendation. | Not named in the cited sources. |
| Vulnerability handling under other regimes | If the organization also has CRA manufacturer duties, keep this program's evidence distinct from the CRA Annex I Part II coordinated-vulnerability-disclosure policy and from CRA Article 14 filings — they are different obligations with different clocks. | Legal requirement of a different statute, only if the CRA applies. Not this checklist's subject matter. | Regulation (EU) 2024/2847. The CRA coordinated-vulnerability-disclosure guide on this site is that page. |
Legal requirement versus framework guidance versus best practice versus SRM-recommendation
The table above tags each row. This table restates the five named sources at the source level, so the distinction is visible without re-reading every row. Do not treat a best-practice row as a legal mandate, and do not treat a named framework as optional because a best-practice row exists next to it. Last verified 10 September 2026. Not legal advice.
| Source | What it is | When it binds YOU |
|---|---|---|
| NIST SP 800-40 Revision 4 | NIST guidance on enterprise patch management planning. Not a regulation. | Never binding by itself. Some federal agencies and contractors treat it as expected practice; that expectation, if any, comes from a separate mandate, not this publication. |
| NIST SP 800-53 Rev. 5, controls RA-5 and SI-2 | A control catalog. RA-5 is vulnerability monitoring and scanning; SI-2 is flaw remediation. | Binds you only if you are a federal information system under FISMA, or a contractor whose contract flows down NIST SP 800-53 controls. Otherwise it is a voluntary reference catalog many organizations borrow from. |
| CIS Critical Security Controls v8.1, Controls 7 and 12 | Best-practice safeguards published by the Center for Internet Security, a nonprofit. | Never a legal mandate on its own. Some regulators or cyber-insurance underwriters reference CIS Controls as evidence of reasonable practice; that reference, if any, is a separate instrument. |
| ISO/IEC 27001:2022 Annex A, control 8.8 | A certifiable information-security management-system standard. | Binds you only if your organization has chosen to seek or maintain ISO/IEC 27001 certification, or if a counterparty contract requires it. |
| AICPA 2017 Trust Services Criteria (2022 points of focus), CC7.1 | Attestation criteria used in a SOC 2 examination. | Binds you only if your organization has chosen to pursue a SOC 2 report, or a counterparty contract requires one. |
What to do now
As of last verification on 10 September 2026, none of the five named sources has changed the substance summarized above. The list below is operational preparation. It is not a determination that any framework applies to YOU and not a substitute for your auditor's judgment.
- Walk the master table row by row against what actually runs today — not what a slide deck says runs. Mark each row done, in progress, or not applicable, and say why for 'not applicable' rows.
- If a SOC 2 report or ISO/IEC 27001 certification is a business goal, ask your auditor or certification body which rows they will test and what evidence they expect. This page does not run that test for you.
- If NIST SP 800-53 binds you through FISMA or a contract, read RA-5 and SI-2 directly, including their control enhancements, rather than relying on this page's summary.
- Pick one remediation-SLA structure (the remediation SLAs guide on this site is a template, not a mandate) and one exception-record format (the accepted-risk guide on this site) before the first missed deadline, not after it.
- Do not treat this checklist, or any signed-in surface, as the audit. A named human still signs the exception, owns the SLA, and tells the auditor what evidence exists.
Where this shows up in ShipReady Metrics
Signed-in app → Security → Findings ingests results from connected scanners — Dependabot, code scanning, secret scanning, DAST, and first-party SAST where configured — and ranks them using KEV status, EPSS, and CVSS together, with cross-source deduplication so the same underlying vulnerability surfaced by two tools is not double-counted. It also computes transitive-npm blast radius: which repositories resolve an affected package version through their lockfiles, not just which manifests mention it.
None of that is this checklist, an audit, a certification, or a determination that any row in the master table above is satisfied. The product does not assign an owner, does not sign an exception, does not set an SLA policy for you, and does not patch YOUR estate. A named human still owns each of those decisions. Signed-in Compliance surfaces can host a written remediation policy the organization authors, and can track exceptions the organization records; hosting a document is not the same as an auditor accepting it as evidence.
This page does not document a public demo URL. There is no public vulnerability-management demo path.
Primary sources (last verified 10 September 2026)
Every framework or standard claim on this page is taken from one of these. If a later revision changes the rule, the date above is how you can see we have not re-checked yet.
NIST Special Publication 800-40 Revision 4, Guide to Enterprise Patch Management Planning (2022), is NIST guidance, not a regulation. NIST Special Publication 800-53 Revision 5 (including Release 5.2.0), controls RA-5 (Vulnerability Monitoring and Scanning) and SI-2 (Flaw Remediation), is a control catalog binding only where a separate mandate (FISMA, or a contract) requires it. CIS Critical Security Controls Version 8.1, Controls 7 (Continuous Vulnerability Management) and 12 (Network Infrastructure Management), are best-practice safeguards published by the Center for Internet Security. ISO/IEC 27001:2022, Annex A control 8.8 (Management of Technical Vulnerabilities), is a certifiable management-system standard binding only on organizations that seek or maintain that certification. The AICPA 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, with the 2022 revised points of focus, criterion CC7.1, is attestation criteria binding only on organizations pursuing a SOC 2 report. These are not a complete world list. Not legal advice.
The vulnerability remediation SLAs guide on this site is the live SLA-template page. The track-accepted-risk guide on this site is the live exception-record page. The prove-remediation guide on this site is the live evidence page. The CRA coordinated-vulnerability-disclosure guide on this site is a different statute's page. A dedicated what-is-vulnerability-management pillar is not on this site yet. Naming it is not a link.
Frequently asked questions
Is this checklist a legal requirement?
No, not by itself. Each row is tagged with what kind of text it rests on. NIST SP 800-53 controls bind you only if you are subject to FISMA or a contract that flows those controls down. ISO/IEC 27001 and SOC 2 rows bind you only if you have chosen to pursue that certification or attestation. CIS Controls and NIST SP 800-40r4 are best-practice guidance, not statutes. This page is not legal advice.
If we check every row, are we ISO 27001 or SOC 2 compliant?
No. Checking a row on this page is not a certification decision and not an auditor's finding. This is a checklist for your own tracking, not a substitute for a certification body's assessment or your SOC 2 auditor's testing. Ask your auditor or certification body what evidence they will actually test.
Does ShipReady enforce these SLAs for us?
No. Signed-in Security → Findings ranks and surfaces vulnerabilities using KEV, EPSS, and CVSS together with cross-source deduplication and transitive blast-radius analysis, but it does not set your SLA policy, does not assign owners, does not sign exceptions, and does not patch your estate. A named human still owns each of those decisions.
What is the difference between a 'best practice' row and an 'SRM-recommendation' row on this page?
A best-practice row is stated, in substance, by one of the five named sources (NIST, CIS, ISO/IEC, or AICPA), even where that source does not make it a binding mandate. An SRM-recommendation row is this page's own suggestion, offered where none of the named sources states that specific rule. Neither is a legal requirement unless separately marked as one.
Is a downloadable PDF checklist available?
No. This corpus does not ship downloadable files. The master table on this page is the checklist — copy it into your own tracker, spreadsheet, or ticketing system. There is no separate PDF or template file behind this page.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.