Vulnerability metrics work as audit evidence when they show that a defined control operated over a period, can be reproduced from source data, and carry a date, a scope, and an owner. A screenshot of a dashboard rarely does that on its own. Records behind the number do.
This is general guidance. Your auditor decides what they accept, so ask them early what format they prefer.
What an auditor is trying to confirm
Frameworks differ, but the question is similar: did you define a vulnerability management process, and did it run as described? Evidence is anything that shows both the rule and the operation of the rule over time.
Evidence that holds up
| Evidence | What it shows |
|---|---|
| Written remediation targets | The rule exists and was approved |
| Scan records with dates and scope | The process ran, and on what |
| A list of findings with open and close dates | Time to remediate can be recomputed |
| Exception records with owner, reason, and expiry | Deviations are controlled |
| Review minutes or tickets | Humans looked and decided |
Notice that most items are records, not charts. A chart is a summary. The auditor may want to sample from the underlying list and trace one finding from detection to closure.
Make the numbers reproducible
- Store the query or export that produced each reported number.
- Keep the export, with its date, in a folder organized by period.
- Define each metric in a card: definition, source, clock start and stop, owner.
- Freeze periods. If you restate a number, record why.
- Keep a change log of tools, scopes, and rules.
If someone else can run the same query and get the same answer, the evidence is strong.
What to avoid
- Metrics with no definition. An auditor cannot test a number that has no rule.
- Evidence created after the fact. Samples that are backfilled for the audit weaken trust in everything else.
- Overstating status. If an attestation or certification is in progress, say so, and do not describe it as complete.
- Mixing scope. Say which systems the metric covers.
Sampling is normal
Expect to be asked for a sample, such as a handful of high severity findings, with proof of detection, ticket, fix, and verification. Preparing two or three traced examples in advance saves time.
Link controls to metrics
Map each metric to the control it supports in a simple table. That mapping helps you see gaps, such as a control with no metric, and avoid metrics that support nothing.
Where Safeguard fits
Safeguard can help with the inputs behind this. It runs SBOM and dependency scanning, reachability analysis to separate reachable findings from the rest, and policies and gates that you set. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a single piece of evidence can be mapped to more than one control.
Quick check
Is a dashboard screenshot enough?
Rarely. It helps as a summary, but auditors usually want the underlying records and the definition of the number.
Do we need to keep every scan result?
Keep what your policy and auditor require, for the period they require. Ask them for the expectation and write it in your retention rules.
Last reviewed: 19 October 2026.
