Vulnerability scan evidence for a SOC 2 audit
Running the scanner is the easy half. The evidence auditors actually test is what happened to the findings afterwards, and whether it happened inside the window you promised.
An auditor accepts vulnerability scan evidence as a pair: the dated scan report showing the scope and the findings, and the remediation trail showing each finding closed inside the timeframe your own policy sets for its severity. A clean scan report on its own is close to worthless as evidence, because it proves nothing about the eleven months of findings you had before it.
Every scan in the window The population, not the most recent report
What scan output does an auditor accept?
The report has to answer four questions on its face: what was scanned, when, by what tool, and what was found. A PDF export from the scanner does this. A screenshot of a dashboard tile reading "0 critical" does not. It names no scope and carries no date the auditor can rely on.
- Infrastructure scan
- Authenticated or unauthenticated scanning of hosts, containers and cloud resources. Evidence is the report plus the target list, so the auditor can see that production was in it.
- Dependency scan
- Software composition analysis over your own codebase, usually running in the pipeline. Evidence is the tool configuration and a sample of run outputs, not a single export.
- Container image scan
- Scanning at build or in the registry. Easy to evidence because the pipeline logs every run with a timestamp already.
- Cloud configuration scan
- Posture checks against your cloud account. Auditors increasingly ask for it separately from host scanning, so name it in your policy rather than folding it in silently.
How do you evidence remediation inside your stated SLA?
Your policy names a number of days per severity. The auditor picks findings from your scan history, finds them in your tracker, and computes the days between detection and closure. That is the whole test, and it is arithmetic.
| Severity | Target days | What closes the finding |
|---|---|---|
| Critical | 7 | Patch deployed, or the finding retested clean in a later scan |
| High | 30 | Fix merged and deployed, with the change record attached |
| Medium | 90 | Fix, or a dated risk acceptance signed by a named owner |
| Low | 180 | Fix, acceptance, or a documented decision to defer with a review date |
Pick numbers you can hit with the team you have. A policy promising critical findings closed in twenty four hours, written by a company with no on-call rotation, manufactures exceptions in month two. The same trap applies to every cadence you write down. The evidence collection page keeps returning to the point: your policy is the standard you get tested against.
- Set the scan cadence in policy and put it in a calendar with a named owner, or automate it so the cadence proves itself.
- File every scan report, including the ugly ones. Missing months are the finding, not the findings themselves.
- Open a tracker item per finding above your threshold, with the detection date copied from the scan.
- Close the item with a link to the change that fixed it, or with a written risk acceptance carrying a name and a date.
- Re-scan and keep the report that shows the finding gone. Retest evidence is what turns your claim into the auditor's observation.
- Track your own SLA breach rate monthly, so you find the pattern before the auditor computes it.
Risk acceptance is evidence, not an escape
Accepting a medium finding is a legitimate outcome and auditors treat it as one, provided the acceptance names the risk, names the person accepting it, carries a date, and has a review point. What fails is a tracker full of items sitting open past their target with no decision recorded at all, which reads as a control that stopped operating rather than a risk that was managed.
Where a penetration test is not a substitute
These are different controls and auditors test them separately. A penetration test is a point-in-time exercise by a person, typically annual, evidenced by the report and the remediation of its findings. Vulnerability scanning is a recurring automated control, evidenced by the run history. An annual test cannot satisfy a policy that commits to monthly scanning, and monthly scanning does not satisfy a customer contract that asks for an independent test.
Most first Type 2 audits end up with both, because the auditor expects the scanning control and the enterprise customer expects the test. What a penetration test for SOC 2 has to cover is worth reading before you buy one. Scope is where that spend goes wrong.
Why does scan evidence get sent back?
- One report, dated last week. The window is twelve months and the population is every scan in it. A single recent report is the classic sign of a control that started when audit prep did.
- A dashboard screenshot with no date in frame. Scanner dashboards show current state, and current state is not what a Type 2 tests.
- The scan scope excludes production. Staging results are not evidence about production. Check the target list on the report, not the tool settings you remember configuring.
- Findings closed in the tracker with no fix and no acceptance. A ticket marked done with an empty comment field cannot be tied to anything.
- Detection dates rewritten. Bulk-closing an old backlog and reopening the items with today's date destroys the trail, and the tracker's history shows it happened.
The evidence tracker gives scanning and remediation their own rows with a cadence and an owner, and the change evidence page covers the fix side of the trail, since a closed vulnerability normally points at a merged pull request.
Get scanning and remediation evidence that holds
Scans prove little without the remediation record beside them. Send your scope and compare Canadian firms that run both.
Get matchedCommon questions
How often do we need to scan for SOC 2?
As often as your policy states. Monthly is the most common commitment for infrastructure and it is defensible; continuous scanning in the pipeline for dependencies is easier to evidence than anything manual because the pipeline logs itself. Quarterly is acceptable if that is what you will do.
Do we have to fix everything the scanner reports?
No. You have to handle everything above your stated threshold, and handling includes a documented risk acceptance. What you cannot do is leave findings open past your own target with no decision recorded.
Does a cloud provider's own security tooling count?
Yes, if it produces dated reports covering your resources and you act on the findings. The tool's brand is irrelevant to the auditor. What matters is scope, cadence, and the closure trail.
Our scanner only keeps 90 days of history. Is that a problem?
It is, for a twelve month window. Export each report as it is produced and file it yourself. Retention that expires mid-window is the same failure mode as log retention set shorter than the audit period, and it cannot be fixed retroactively.
Can we start scanning halfway through the observation window?
You can, and the auditor will note that the control did not operate for the first half. Depending on the firm this becomes an exception in the report or a reason to shorten the window. Starting the scan cadence before the window opens is much cheaper than explaining it afterwards.