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.
How do you prove a vulnerability was remediated?
Updated
Proving remediation means producing evidence a fix actually landed — a rescan, a version confirmation, or a control test — tied to the finding with a timestamp. A ticket marked 'done' is not evidence. This page describes what auditors typically expect as best practice, not a guarantee. Not legal advice.
Proving remediation, last verified 10 September 2026, against AICPA SOC 2 Trust Services Criteria CC7.1 and CC8.1, ISO/IEC 27001:2022 Annex A control A.8.8 and Clause 9, NIST SP 800-40 Revision 4, and PCI DSS v4.0.1 Requirement 11. It is not legal advice, not a guarantee that any specific evidence will satisfy any specific auditor, and not a substitute for that framework's own text.
This is an evidence checklist, not YOUR audit opinion
Audience: a compliance owner, security engineer, or CISO preparing to show that a finding was actually fixed — for an internal review, a SOC 2 examination, an ISO/IEC 27001 audit, or a PCI DSS assessment. This page is not legal advice. It does not produce YOUR evidence, does not run YOUR audit, and does not determine that any specific evidence trail will satisfy any specific auditor or assessor.
'Remediated' and 'closed' are not the same claim. A ticket status is a workflow state a person set; remediation evidence is an independent check — a rescan, a version confirmation, or a control test — that the vulnerable condition no longer exists. Auditors who have seen a closed ticket reopen after a failed rescan tend to ask for the second thing, not just the first. Last verified 10 September 2026.
- Framework requirement versus best practice: AICPA SOC 2 CC7.1 and CC8.1, and ISO/IEC 27001:2022 A.8.8 and Clause 9, are framework requirements only if that examination or that certified ISMS control applies to YOU. PCI DSS v4.0.1 Requirement 11 is a requirement only if YOU are in PCI DSS scope. NIST SP 800-40 Revision 4 is NIST guidance on patch management, not a certification requirement in itself.
- The vulnerability remediation SLAs, program-checklist, and track-accepted-risk guides on this site are live or ship alongside this page. A dedicated vulnerability-vs-exploit-vs-risk, CVE-vs-CWE-vs-CVSS, what-is-KEV, how-to-prioritize-vulnerabilities, exploitability-vs-severity, remediation-timeframes, what-is-an-SBOM, end-of-life-dependencies, detect-vulnerable-open-source-packages, handle-zero-day, and how-ShipReadyMetrics-prioritizes-risk guide either ships alongside this page or is not on this site yet; naming any that are not yet live is not a link.
Evidence checklist — what an auditor typically accepts
The table below lists the kinds of evidence that commonly satisfy an auditor's request for proof of remediation, per finding type. It is a best-practice checklist distilled from common audit practice, not a guarantee that any specific auditor will accept any specific artifact — an examination engagement letter or an assessor's own testing procedures govern that. Last verified 10 September 2026. Not legal advice.
| Finding type | What typically counts as proof | Kind of text | What it does not prove |
|---|---|---|---|
| A dependency or package vulnerability (SCA finding) | A rescan showing the fixed version installed, or a diff of the lockfile showing the version bump, tied to the finding's identifier and a timestamp. | Best practice, informed by NIST SP 800-40 Rev. 4 patch-verification guidance. | Does not prove the upgrade did not introduce a regression, and does not prove the vulnerable code path was ever reachable in the first place. |
| A code-level flaw (SAST finding) | A code diff showing the fix, a rescan of the same rule against the changed code showing no recurrence, and the code-review or pull-request record. | Best practice. | Does not prove the fix is complete for every input; a rescan checks the same rule, not every possible exploit path. |
| A running-system or configuration flaw (DAST or CSPM finding) | A rescan of the live target confirming the condition no longer reproduces, plus the configuration-change record (who, what, when). | Best practice, informed by PCI DSS v4.0.1 Requirement 11 rescanning expectations where PCI scope applies. | Does not prove the configuration will not drift back; that is what recurring scans and change control are for. |
| A secret-scanning finding (a leaked credential) | Confirmation the credential was rotated or revoked, plus the rotation timestamp from the credential provider — a code fix alone is not sufficient if the old value is still live. | Best practice. | A code change removing the secret from source does not by itself prove the exposed credential was invalidated. |
| A vulnerability accepted as risk rather than fixed | The signed risk-acceptance record: owner, justification, compensating control, and expiry — see the track-accepted-risk guide on this site. | Best practice; ISO/IEC 27001:2022 Clause 6.1.3 and 8.3 govern risk treatment and acceptance decisions where that ISMS applies. | An acceptance record proves a decision was made and by whom; it does not prove the underlying risk is actually low. |
A worked evidence trail — illustrative, not YOUR file
The sequence below illustrates what a defensible evidence trail looks like end to end for one dependency finding. It is an example, not a template that satisfies every framework or every auditor by itself. Last verified 10 September 2026. Not legal advice.
| Step | What is recorded | Timestamp source |
|---|---|---|
| 1. Finding opened | Scanner or feed identifies the vulnerable package version and CVE identifier; the finding is assigned an owner and a due date. | Ingest timestamp from the connected source. |
| 2. Fix applied | The owner upgrades the package; the change is committed and reviewed through the normal pull-request process. | Version-control commit and merge timestamp. |
| 3. Verification | A rescan of the same repository confirms the vulnerable version is no longer present. | Rescan timestamp, tied to the same finding identifier. |
| 4. Closure recorded | The finding is marked remediated with a reference to the verification rescan, not just the merged pull request. | Closure timestamp, distinct from and after the verification timestamp. |
Framework requirement versus best practice — do not conflate them
Do not treat a certification badge as proof that every finding was individually verified, and do not treat this checklist as one of the cited frameworks' own text. Last verified 10 September 2026. Not legal advice.
| Text | What it is | What this page does not do |
|---|---|---|
| AICPA SOC 2 Trust Services Criteria CC7.1 and CC8.1 | Framework requirement, only if a SOC 2 examination covering those criteria applies to YOU. CC7.1 concerns detecting and monitoring for vulnerabilities and configuration changes; CC8.1 concerns change management. | Does not determine that CC7.1 or CC8.1 binds YOU, and does not represent the auditor's testing procedures. |
| ISO/IEC 27001:2022 Annex A control A.8.8 and Clause 9 | Framework requirement, only if that certified ISMS control and Clause 9 performance-evaluation activities apply to YOU. A.8.8 is management of technical vulnerabilities; Clause 9 covers monitoring, measurement, and internal audit. | Does not determine that A.8.8 or Clause 9 binds YOU, and is not a certification decision. |
| PCI DSS v4.0.1 Requirement 11 | Framework requirement, only if YOU are in PCI DSS scope. Requirement 11 covers testing security of systems and networks regularly, including vulnerability scanning and rescanning expectations. | Does not determine that Requirement 11 binds YOU, and is not a Qualified Security Assessor's finding. |
| NIST SP 800-40 Revision 4 | NIST guidance on enterprise patch management planning, not a certification requirement in itself. | Does not treat NIST guidance as a certification standard. |
| This product's finding lifecycle and evidence collection | ShipReady recommendation: a record of when a finding was opened, when it was rescanned, and when it was closed. Not itself an auditor's verdict. | Does not claim this product 'proves' remediation. Does not replace an auditor's own testing. A named human still owns the verification step and the audit relationship. |
Common evidence gaps auditors flag
The gaps below recur across audit types more than any single missing document does. Naming them is not a claim that avoiding them guarantees a clean audit — that depends on the specific engagement. Last verified 10 September 2026. Not legal advice.
- A closed ticket with no linked rescan — the workflow says done, and nothing independent confirms it.
- A remediation date that is the merge date, not the verification date — the two are often days or weeks apart, and only the second one is proof.
- An accepted-risk finding with no expiry, sitting in the same list as genuinely remediated findings with no way to tell them apart at a glance.
- A secret-scanning finding closed by removing the value from source, with no confirmation the credential itself was rotated or revoked.
What to do now
The list below is operational preparation. It does not determine what any specific auditor, examiner, or assessor will accept for YOUR engagement. Walk it with your compliance owner and, for a live engagement, with the auditor's own requirements. Last verified 10 September 2026. Not legal advice.
- Never treat a ticket status alone as proof; pair it with an independent check — a rescan, a version confirmation, or a control test — tied to the same finding identifier.
- Record two timestamps, not one: when the fix was applied, and when it was verified. An auditor who has seen closures reopen after a failed rescan will look for the second timestamp.
- For accepted-risk items, keep the signed exception record — owner, justification, compensating control, expiry — as the evidence, not a promise to fix later. See the track-accepted-risk guide on this site.
- Map each evidence type to the specific framework clause it supports (SOC 2 CC7.1/CC8.1, ISO/IEC 27001:2022 A.8.8, PCI DSS v4.0.1 Requirement 11) rather than assuming one evidence format satisfies every framework.
- Ask your own auditor or assessor what they will accept before the engagement starts; this checklist is common practice, not that auditor's specific requirements.
Where this shows up in ShipReady Metrics
If you already have a session: signed-in app → Security → Findings records when a finding was opened, ingested from connected sources such as GitHub Dependabot, code scanning, secret scanning, and first-party SAST/DAST, and when it moved to a remediated or verified state. That finding-lifecycle record can be exported as supporting evidence for a review.
That evidence-collection surface is not itself an auditor's verdict. This product does not claim to prove that a fix satisfies SOC 2 CC7.1/CC8.1, ISO/IEC 27001:2022 A.8.8, or PCI DSS v4.0.1 Requirement 11 for YOU, does not replace an auditor's own testing procedures, and does not issue certifications. A named human still owns the verification step, the evidence package, and the relationship with the auditor. This page does not document a public demo URL.
Primary sources (last verified 10 September 2026)
Every claim on this page is taken from one of these. If a later revision of a source changes the rule, the date above is how you can see we have not re-checked yet.
AICPA's SOC 2 Trust Services Criteria, including CC7.1 (detection and monitoring) and CC8.1 (change management), are a framework requirement only if a SOC 2 examination covering them applies to YOU. ISO/IEC 27001:2022 Annex A control A.8.8 (management of technical vulnerabilities) and Clause 9 (performance evaluation) are a framework requirement only if that certified ISMS applies. PCI DSS v4.0.1 Requirement 11 (test security of systems and networks regularly) is a requirement only if YOU are in PCI DSS scope. NIST SP 800-40 Revision 4, Guide to Enterprise Patch Management Planning (April 2022), is NIST guidance, not a certification standard. These are not a complete world list. Not legal advice.
The vulnerability remediation SLAs, program-checklist, and track-accepted-risk guides on this site ship alongside this page. The vulnerability-management glossary entry on this site is the education page under glossary.
Frequently asked questions
Is this legal advice?
No. It is a best-practice evidence checklist distilled from AICPA SOC 2 Trust Services Criteria CC7.1/CC8.1, ISO/IEC 27001:2022 A.8.8 and Clause 9, PCI DSS v4.0.1 Requirement 11, and NIST SP 800-40 Revision 4. Whether any of those frameworks applies to YOU, and what a specific auditor will accept, is a question for that auditor and, where relevant, counsel. This page is not legal advice.
Is a ticket marked 'done' proof of remediation?
No. A ticket status is a workflow state a person set. Proof is an independent check — a rescan, a version confirmation, or a control test — that the vulnerable condition no longer exists, tied back to the original finding with a timestamp. Auditors who have seen closed tickets reopen after a failed rescan tend to ask for that independent check.
Does a SOC 2 report or ISO 27001 certificate prove every finding was individually verified?
No. A certification or examination report reflects testing over a period or a sample, governed by that engagement's own scope and procedures. It is not a per-finding guarantee, and it does not substitute for keeping per-finding remediation evidence on hand.
Does ShipReady Metrics prove that our vulnerabilities were remediated?
No. Signed-in app → Security → Findings records when a finding was opened, remediated, and verified, and that lifecycle record can support an evidence package. It is not itself an auditor's verdict, does not replace an auditor's own testing procedures, and does not issue certifications. A named human still owns the verification step and the audit relationship.
What evidence does an accepted-risk finding need instead of a fix?
A signed exception record: a named owner, the justification, any compensating control, and an expiry or review date. See the track-accepted-risk guide on this site. That record is evidence a decision was made and by whom; it is not evidence that the underlying risk is actually low.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.