QA before your SOC 2 audit: the evidence checklist
A SOC 2 audit is really one question asked many ways: can you prove your controls work? For a software team, a lot of that proof is your testing. Build it in early and the audit gets boring, in the best way.
By Quality AboveAll · May 7, 2026 · 7 min read
Where this fits in the wider picture.
QA before your SOC 2 audit: the evidence checklist
Senior people on the actual work
No layered account teams between you and the build.
Designed for the bad day
Failover, retries and load behaviour proven before launch.
Threat modelled from the start
Secure defaults, dependency hygiene, and audit trails.
Budgets, not guesses
Latency and throughput targets set and measured.
Usable by everyone
WCAG 2.2 checks built into the pipeline.
A SOC 2 audit asks for evidence that your controls work. Testing is where a lot of that evidence comes from. Build it into CI before the auditor asks, not the week they arrive. We do this as compliance testing.
What a SOC 2 auditor actually wants
SOC 2 is not a certificate you buy. It is an auditor confirming that your controls exist and work over time. For a software team, a large share of that proof comes from how you test and ship.
The good news: if your testing is disciplined, most of the evidence already exists. You just have to capture it.
The evidence checklist
- Change management. Show that code is reviewed and tested before release. Gated tests in CI/CD are direct evidence.
- Access controls. Prove who can deploy and that tests run on every change.
- Security testing. Regular checks against the OWASP Top 10. See security and penetration testing.
- Monitoring. Evidence you detect and respond to issues in production.
- Test data handling. No real customer data in test environments. We use masked and synthetic data by default.
Build the evidence into CI
The teams that pass cleanly do not scramble. Their pipeline already records test runs, approvals, and gates on every merge. When the auditor asks, the trail is there. That is the difference between a stressful audit and a boring one, and boring is the goal.
The best audit prep is a pipeline that produces evidence as a side effect of shipping.
Prepping for an audit now? A testing audit maps your gaps to the controls an assessor will look for, so you walk in ready.
Questions about this topic.
What QA evidence does a SOC 2 audit need?
Evidence that changes are tested and approved before release: linked requirements, test results, and change records showing who verified what. Auditors look for a repeatable process, not test volume.
How far ahead should we prepare?
Start at least a quarter before the observation window. Controls need to be operating, not just documented, and retrofitting evidence for changes already shipped is far more expensive.
Does SOC 2 require test automation?
No. It requires demonstrable, consistent process. Automation makes the evidence easier to produce and harder to skip, which is why most teams end up automating during preparation.
How ready is your product to ship and scale?
Answer 12 questions and get a maturity score across architecture, delivery, quality and security, plus the three things we would fix first. No email required to see your result.
Senior-led QA,embedded in your workflow.
Often less than one full-time hire. Book a free 30-minute testing audit and we'll show you exactly where the risk is hiding.