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 vulnerability management evidence do auditors expect?
Updated
Four artifacts carry the programme: proof of scan coverage across the whole estate, a written prioritisation rationale, remediation records measured against your own stated targets, and risk-acceptance records for what you did not fix.
Vulnerability-management evidence map, last verified 10 September 2026 against the CISA Known Exploited Vulnerabilities catalog and Binding Operational Directive 22-01, the FIRST Exploit Prediction Scoring System and the CVSS v4.0 specification, NIST SP 800-40 Rev. 4, PCI DSS v4.0.1 Requirements 6 and 11, ISO/IEC 27001:2022 Annex A 8.8, and the AICPA Trust Services Criteria. BOD 22-01 binds US federal civilian executive branch agencies; it is not a rule for private companies, and no source here mandates KEV, EPSS, or CVSS as your prioritisation method. Those are complementary best-practice signals. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: a security lead, engineering leader, or compliance owner who has scanners producing findings and needs the programme to be provable end to end — discovery through remediation or documented acceptance.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. Last verified 10 September 2026.
The shape of the audit conversation is predictable. An auditor asks what you scan, how often, how you decide what to fix first, how quickly you fix by severity band, and what happens to the ones you do not fix. If you can answer those five with artifacts, the control is evidenced. If you can only answer them with a dashboard screenshot, you will be sampled harder.
- Coverage is the first question and the most commonly failed one. A scanner finding nothing in a repository or account nobody connected is not a clean result.
- Your own stated targets are what you are tested against. A policy promising remediation of critical findings in seven days, met in practice in thirty, is worse evidence than a policy that says thirty and is met.
- The exception path is a control, not an admission of failure. Risk acceptance with a named approver, a compensating measure, and an expiry date is a legitimate outcome; a finding that quietly ages is not.
- Deduplication matters for the numbers to mean anything. The same vulnerability reported by three tools is one risk, and counting it three times makes trend evidence meaningless.
Lifecycle-to-evidence map
Read the first column as the lifecycle stage, the second as the artifact, the third as the control assertion, and the fourth as the common failure. Last verified 10 September 2026. Not legal advice.
| Lifecycle stage | Evidence artifact | Control assertion it supports | Common failure |
|---|---|---|---|
| Asset and scope definition | The inventory of repositories, images, hosts, cloud accounts, and applications in scope, with the scanner that covers each and the date the mapping was last confirmed | You know what should be scanned. AICPA TSC CC7.1; ISO/IEC 27001:2022 Annex A 5.9 inventory of information and other associated assets and 8.8. | A scope list that is a subset of production. Unscanned assets are the finding, and the auditor usually finds them from a different list. |
| Scan coverage and cadence | Scan run history per asset class with dates, the schedule configuration, and the coverage report showing assets scanned versus assets in scope | Scanning happens on a defined cadence across the estate. PCI DSS v4.0.1 Requirement 11.3 where in scope; Annex A 8.8; NIST SP 800-40 Rev. 4. | Evidence of scans running, with no evidence of what they did not reach. |
| Authenticated versus unauthenticated coverage | Configuration showing where credentials are used, and the record of which findings depend on authenticated visibility | The scan sees what an attacker with a foothold would see. NIST SP 800-40 Rev. 4 guidance. | Unauthenticated-only scanning presented as full coverage, understating package-level exposure. |
| Ingestion and deduplication | The record of sources ingested, and the deduplication logic or tooling that collapses the same vulnerability reported by multiple scanners into one finding | Counts and trends are meaningful. Supports every metric you report under AICPA TSC CC4.1 monitoring. | Three tools, three counts, and a trend line that reflects tooling changes rather than risk. |
| Prioritisation rationale | The written method: which signals you use, how they combine, and what band a finding lands in — plus a worked example showing the method applied | Remediation order is deliberate and repeatable. Annex A 8.8; NIST SP 800-40 Rev. 4. See the KEV, EPSS and CVSS section below. | Severity taken from a single vendor score with no stated method, so the order cannot be defended or reproduced. |
| Remediation targets | The published target per band, its approval, and the date it took effect | Response time is defined rather than improvised. AICPA TSC CC7.1; PCI DSS v4.0.1 Requirement 6.3.3 for critical and high-risk patches where in scope. | Targets that exist in a policy nobody measures against, and that the data contradicts. |
| Remediation records | Per finding: detection date, band, owner, fix or mitigation, closure date, and the change or deploy that carried the fix | Findings are actually remediated, traceably. Annex A 8.8; AICPA TSC CC7.1. | Closure with no link to a change, so an auditor cannot confirm the fix reached production. |
| Verification and rescan | The rescan or retest result after the fix, or the verification step that confirmed closure | Closure is verified, not asserted. NIST SP 800-40 Rev. 4; PCI DSS v4.0.1 Requirement 11.3.1.3 for rescanning where in scope. | Findings marked resolved by the assignee with nothing confirming it. |
| Exception and risk acceptance | The acceptance record: finding, business reason, compensating measure, named approver at an appropriate level, expiry date, and review outcome at expiry | Unremediated risk is knowingly owned. Annex A 5.4 and 8.8; AICPA TSC CC3.2 and CC7.1. | Silent aging: findings past target with no acceptance record, which evidences that you knew and did nothing. |
| Exploited-in-the-wild handling | The record of how you treat findings that appear in the CISA KEV catalog, including an expedited path and the decisions taken in the period | Actively exploited weaknesses get priority. Best practice; BOD 22-01 timelines bind US federal civilian executive branch agencies, not private companies. | Treating KEV membership as just another severity input, with no expedited path recorded. |
| Blast-radius and dependency reach | Evidence that you can determine which services and releases include an affected component, including transitive dependencies where a lockfile exists | Impact assessment is possible without guesswork. Annex A 8.8; supports incident response under Annex A 5.26. | Knowing a package is vulnerable without knowing which services ship it, so remediation scope is estimated. |
| Programme reporting and oversight | Periodic reporting to a named owner or committee with open findings by band, aging past target, and acceptance count — plus the record that it was reviewed | Management oversees the programme. AICPA TSC CC4.1 and CC2.3; ISO/IEC 27001:2022 Clause 9.1 and 9.3. | Metrics produced and never presented, or presented with no record of the discussion. |
KEV, EPSS, and CVSS: complementary signals, and best practice rather than mandate
These three answer different questions, and the common mistake is using one as if it answered all three. None of them is required of a private company by any source on this page. Using them together is best practice because it produces an order you can explain. Last verified 10 September 2026 against the CISA KEV catalog, the FIRST EPSS documentation, and the CVSS v4.0 specification. Not legal advice.
| Signal | What question it answers | Which kind of authority | What it does not tell you |
|---|---|---|---|
| CISA KEV — the Known Exploited Vulnerabilities catalog | Has this vulnerability been observed being exploited in the wild, according to CISA's criteria for inclusion? | Regulatory guidance for the general public; a legal requirement only for US federal civilian executive branch agencies, through Binding Operational Directive 22-01 and its remediation timelines. | Whether you are affected, whether the affected component is reachable in your environment, or that absence from the catalog means absence of exploitation. |
| FIRST EPSS — Exploit Prediction Scoring System | What is the modelled likelihood that this vulnerability will be exploited in the near term, expressed as a score between 0 and 1? | Industry best practice — a community model published by FIRST, updated continuously. | Impact if exploited, your specific exposure, or a guarantee about any individual vulnerability. It is a probabilistic model, and it changes as evidence changes. |
| CVSS v4.0 — Common Vulnerability Scoring System | How severe is this vulnerability technically, given exploitability and impact characteristics? | Industry best practice — a specification published by FIRST. Some frameworks and contracts reference severity bands derived from it. | Likelihood of exploitation, or your environmental context unless you actually apply the environmental and threat metric groups rather than quoting the base score. |
| Reachability and exposure analysis in your own environment | Is the affected code path actually reachable, and is the asset internet-facing or otherwise exposed? | Industry best practice. No framework named here requires it, and it changes prioritisation more than any external score. | Nothing about whether the vulnerability is being exploited elsewhere — combine it with KEV and EPSS rather than replacing them. |
| PCI DSS v4.0.1 Requirement 6.3.1 asks in-scope entities to identify and assign risk rankings to vulnerabilities, and 6.3.3 to install critical or high-security patches within one month of release. | Legal requirement in the contractual sense for entities in scope, through card-brand and acquirer agreements. | Does not mandate CVSS, EPSS, or KEV as the ranking method, and does not apply where no cardholder data is in scope. | |
| Rank by KEV membership first, then by EPSS for likelihood, then by CVSS for impact, adjusted by reachability and exposure — and write the method down. | ShipReady Metrics recommendation, and how this product ranks findings. | Not required by any framework named here. The value is that the resulting order is explainable to an auditor and reproducible next quarter. |
A sample remediation-SLA evidence format
This is the shape of the artifact that answers the timeliness question. It states the target, the population, and the outcome per band, and it exposes aging rather than hiding it. Rows below are illustrative format examples, not measurements of any real programme. Last verified 10 September 2026. Not legal advice.
| Field or row | Example content | Why an auditor looks for it |
|---|---|---|
| Header — targets and approval | Targets: KEV-listed or critical, 7 days; high, 30 days; medium, 90 days; low, next planned release. Approved by the named security lead, effective 1 January 2026. | Establishes what you are measured against, and that it was set deliberately rather than after the fact. |
| Header — population and sources | Population: all findings created in the period across dependency scanning, code scanning, secret scanning, container scanning, and the external test, deduplicated across sources. | Shows the measurement covers everything, and that duplicates are not inflating or deflating the picture. |
| Row — band summary | Band: critical. Opened in period: 14. Closed within target: 12. Closed late: 1, with reason recorded. Open past target at period end: 1, with an acceptance record referenced. | Gives the auditor the counts and, more importantly, shows the exceptions are accounted for rather than absent. |
| Row — aging detail | Oldest open critical finding: 41 days, owner named, blocked on an upstream vendor fix, compensating control recorded, review date set. | Aging with an owner and a reason is a managed exception; aging with neither is the finding. |
| Row — individual finding trace | Finding identifier, CVE reference, KEV listed yes, EPSS score at triage, CVSS v4.0 base score, affected services from blast-radius analysis, fix change reference, closure date, rescan result. | Lets the auditor walk one finding end to end, which is how a sample is actually tested. |
| Row — accepted risk | Finding identifier, reason acceptance was chosen, compensating measure, approver named at an appropriate level, expiry date, and the outcome recorded at expiry. | Shows the exception path operates as a control with an end date, not as a place findings go to be forgotten. |
| Footer — coverage statement | Assets in scope: 62. Assets covered by at least one scanner in the period: 62. Assets added during the period and the date each entered coverage. | Answers the coverage question in the same artifact, which is where most vulnerability evidence falls down. |
| Footer — review and storage | Reviewed with the named owner on the stated date; stored in the evidence repository under vulnerability management; retention 12 months plus the audit period. | Shows oversight happened and the artifact itself is retained and findable. |
Checklist
A question list for the vulnerability side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Can we list every asset in scope and name the scanner covering each, and does that list reconcile with what production actually contains?
- Can we show what scanning did not reach in the period, and why?
- Is our prioritisation method written down, and could a new engineer reproduce last quarter's order from it?
- Are findings deduplicated across sources, so that counts and trends mean something?
- Do our published remediation targets match what the data shows we actually achieve?
- For a sampled closed finding, can we trace detection, decision, fix, the change that carried it, and the verification?
- Does every finding open past target have either an active remediation owner or an acceptance record with an expiry?
- Is there an expedited path for findings in the CISA KEV catalog, and was it used in the period?
- Can we determine which services and releases contain an affected component, including transitive dependencies?
- Is programme reporting presented to a named owner, with the review itself recorded?
What to do now
Ordered so the weakest link closes first. None of these steps is a legal determination, and none files anything with an auditor.
- Produce the coverage reconciliation first: assets in scope against assets scanned. It is the question that decides how much the rest of your evidence is worth.
- Write the prioritisation method down in one page: KEV membership first, then EPSS for likelihood, then CVSS for impact, adjusted for reachability and exposure. A written method beats a better unwritten one.
- Reconcile your published targets with your actual performance, and change the targets if they are not met. Being measured against a number you miss is a self-inflicted finding.
- Deduplicate across sources before you report any count, so trend evidence reflects risk rather than tooling changes.
- Give every finding past target either a named owner with a date or a proper acceptance record with an approver and an expiry. Eliminate the silent middle.
- Add an expedited path for KEV-listed findings, and record when it was invoked. Note in the control description that BOD 22-01 timelines bind US federal civilian executive branch agencies, not you.
- Make sure you can answer which services ship an affected component, including transitive dependencies, before the next urgent advisory rather than during it.
- Re-verify the CISA KEV catalog, FIRST EPSS documentation, and the CVSS specification annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not patch your systems, does not open remediation changes for you, and does not file anything with an auditor.
Vulnerability management in this product ranks findings using CISA KEV membership, EPSS, and CVSS, deduplicates across sources, and supports blast-radius search over captured dependencies — including transitive npm dependencies where a lockfile was fetched. First-party SAST and DAST exist and complement, rather than replace, third-party penetration testing.
Ingest is read-only. The GitHub App reads Dependabot alerts, code-scanning alerts, and secret-scanning alerts as findings; GitLab ingest covers security findings the same way. Neither configures scanners, changes settings, nor exports your audit pack.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. That is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, and not an auditor's opinion. A cyber risk register lives under Security for accepted risk.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
The CISA Known Exploited Vulnerabilities catalog is published guidance for the general public; CISA Binding Operational Directive 22-01 is a legal requirement for US federal civilian executive branch agencies only. The FIRST Exploit Prediction Scoring System and the CVSS v4.0 specification are community specifications and industry best practice. NIST SP 800-40 Rev. 4 is guidance. PCI DSS v4.0.1 Requirements 6 and 11 bind entities in scope through card-brand and acquirer contracts. ISO/IEC 27001:2022 Annex A 5.4, 5.9, 8.8 and Clause 9 are certification requirements. AICPA Trust Services Criteria CC3, CC4 and CC7 are professional attestation criteria. Not a complete list, and not legal advice.
The KEV and EPSS remediation guide on this site explains the signals in depth. The SBOM, dependency, and penetration-testing pages in this cluster cover the inputs and the complementary testing evidence.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of the vulnerability-management lifecycle to evidence, with every source labelled by the kind of authority it carries. Whether PCI DSS, SOC 2, ISO/IEC 27001, or any statute applies to your organisation is a legal and commercial question for counsel and your contracts. This page does not determine YOUR obligations and does not file anything with an auditor.
Are we required to remediate everything in the CISA KEV catalog within a set time?
Not as a private company. CISA Binding Operational Directive 22-01 sets remediation timelines for US federal civilian executive branch agencies. For everyone else the catalog is guidance, and treating KEV membership as an expedited trigger is best practice rather than a mandate. Where PCI DSS applies, Requirement 6.3.3 sets its own patching expectation for critical and high-security patches, independent of KEV.
Can we just use CVSS severity to prioritise?
You can, and you will over-invest in severe-but-unexploited issues while under-investing in modest-severity issues under active exploitation. CVSS answers how bad it would be; EPSS answers how likely exploitation is; KEV answers whether it is already happening; reachability answers whether it applies to you. Combine them, write the method down, and the resulting order becomes explainable and reproducible.
Is a scanner dashboard enough evidence?
No. A dashboard shows a current state that changes daily and usually cannot be reproduced for a past period. What an auditor tests is a population of findings for the period with detection dates, decisions, owners, closure dates, verification, and acceptance records. Export those; keep the dashboard for the narrative.
Does ShipReady Metrics fix vulnerabilities?
No. It ingests findings from connected sources read-only, deduplicates them across sources, ranks them using KEV membership, EPSS, and CVSS, and supports blast-radius search over captured dependencies including transitive npm dependencies where a lockfile was fetched. First-party SAST and DAST complement rather than replace third-party testing. Remediation happens in your systems, by your team.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.