Yes, scanner output can support a SOC 2 examination, but raw console output is rarely enough. Auditors usually want dated records that scans ran on a schedule, findings were triaged, and fixes or exceptions were tracked. A script stack can produce that with extra work. SOC 2 is an attestation from an independent auditor, not a tool feature.
What evidence usually looks like
| Evidence | What it shows |
|---|---|
| Scan schedule and run history | The control operates continuously |
| Findings with severity and dates | You identify issues |
| Tickets linked to findings | You act on them |
| Exceptions with owner and expiry | Risk acceptance is deliberate |
| Policy document | What your targets are |
Your auditor decides what is sufficient for your controls, so ask early what sample they will draw.
Where DIY setups struggle
- Retention. CI logs expire. Copy results to storage you control.
- Linkage. A finding in one tool and a ticket in another need a stable identifier between them.
- Exceptions. A suppression file edited in a pull request has history, but not always an owner or review date.
- Sampling. If an auditor picks a random month, can you show every scan for it?
A minimal evidence routine
- Store every scan result as a dated artifact.
- Create a ticket for each finding above your threshold, with the finding ID in the title.
- Require an expiry date on every exception.
- Export a monthly summary: runs, findings opened, closed, overdue.
- Keep the summary with your other control evidence.
About certifications and claims
Do not describe your own program as SOC 2 compliant or certified on the strength of scanner reports. Describe what you do: scans run on every merge, findings are triaged within stated targets. Let the auditor's report speak for itself.
Safeguard covers this ground with SBOM and dependency scanning, reachability analysis, policies and gates, and compliance evidence automation. Autonomous fix PRs are off by default, with every category set to Manual. You can try a free scan at gold.safeguard.sh/scan.
Questions to ask your auditor
Before building anything, ask which controls the scan evidence supports, what sample size they expect, and in what form they accept it. Some auditors accept exports from a ticket system, others want screenshots with dates. Agreeing the format early avoids rework at the end of the period. Also ask how they treat exceptions, since a documented, approved exception is usually acceptable while an undocumented one is a finding. The answers shape how much of the routine you need to automate.
Try it yourself
Click through it at your own pace, or open it full screen. Click a finding or control and see how evidence maps to framework requirements.
Quick check
Does a scanner report prove a control works?
It is one piece of evidence. Auditors also want proof of triage, remediation and exceptions over the audit period.
How long should scan results be kept?
Keep them for at least the audit period, and ask your auditor for their expectation.
Last reviewed: 19 October 2026.
