SOC 2 audits rarely fail because a company lacks security controls. They fail because nobody can prove the controls ran. Evidence collection, not control design, is where engineering teams burn the most time, and it is the part of compliance that lands squarely on DevOps.
This article covers the evidence auditors actually pull from your pipeline, why screenshot-based collection breaks down in a Type II audit, and how to wire evidence generation into CI/CD so compliance becomes a byproduct of shipping rather than a quarterly fire drill.
Why SOC 2 Lands on the Pipeline
SOC 2 is built on the AICPA Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security, also called the Common Criteria, is mandatory in every report, and a surprising share of it maps directly onto how software gets built and deployed. Change management (CC8.1), logical access (the CC6 series), and system monitoring (the CC7 series) are all pipeline questions dressed up in audit language.
For a SaaS company, the system under audit is the production environment plus every path code takes to reach it. That path is your pipeline. When an auditor asks how changes are authorized, tested, and approved before deployment, they are asking about your branch protection rules, your PR review policy, and your deploy gates. The DevOps team does not support the audit. In practice, the DevOps team is the audit.
The Evidence Auditors Actually Ask For
Change management evidence carries the most weight. Auditors want proof that every production change was reviewed and approved by someone other than its author: pull request approval records, branch protection configuration, and deployment logs that tie each release back to an approved change. A policy document saying reviews happen is not evidence. The approval record is.
Access control comes next. Who can push to the default branch, who can approve their own pull request, who holds admin rights on the CI system, and when those permissions were last reviewed. Auditors routinely sample offboarded employees and check the dates: the termination date in the HR system against the date access was actually revoked in the version control system and cloud console.
Vulnerability management rounds out the core set: dependency and container scan results, evidence that findings were triaged, and remediation records showing critical issues were closed within your stated SLA. If your policy says criticals get fixed in 15 days, the auditor will pick a critical finding and count the days.
Pro Tip: Stop screenshotting branch protection settings. Export the configuration through your version control provider’s API on a schedule and store the dated JSON as a build artifact. A timestamped export collected weekly is continuous evidence; a screenshot taken during audit week proves the control existed during audit week.
Manual vs. Automated Evidence Collection
The difference between the two approaches is not effort alone. It is whether your evidence can survive a Type II audit at all.
| Dimension | Manual (screenshots and spreadsheets) | Automated (API-integrated) |
|---|---|---|
| Collection effort | Weeks of engineering time per audit cycle, repeated every year | Near zero after initial setup; evidence accrues continuously |
| Type II suitability | Weak: point-in-time captures cannot demonstrate a control operated across the full window | Strong: timestamped records exist for every day of the observation period |
| Typical failure mode | Evidence gaps discovered mid-audit, after the window has closed and cannot be backfilled | Misconfigured tests or unmonitored control failures left unremediated |
| Auditor experience | Sampling disputes, follow-up requests, extended timelines | Direct read access to structured evidence; fewer requests, faster fieldwork |
| Scaling to more frameworks | Effort multiplies per framework | Same evidence maps to overlapping controls across frameworks |
Important: A SOC 2 Type II report covers an observation window, typically 3 to 12 months. Every control must operate throughout that window, and evidence gaps cannot be backfilled after the fact. This is the single most common way manual programs fail: the team discovers in month five that a quarterly access review from month two was never documented, and there is no way to recreate it.
Where Automation Platforms Fit, and Where They Stop
Compliance automation platforms like Drata and Vanta connect to your cloud provider, version control system, HR platform, and identity provider through APIs. They test controls continuously, collect evidence automatically, and flag failures the day they happen instead of the week before the audit. For the evidence problem described above, they are the right tool, and for most SaaS teams they have made screenshot-based programs obsolete.
What they do not do is the part teams consistently underestimate. The platform will not decide your audit scope, write policies that match how you actually deploy, tune its control tests to your architecture, remediate the failures it surfaces, or manage the auditor relationship. Automation tells you a control is failing. Someone still has to fix it, and someone has to own the program end to end.
That gap is why many teams pair the platform with outside expertise. Engineering-led companies that want the automation without turning a senior engineer into a part-time compliance manager typically bring in a partner for Drata implementation services: configuring the platform against their stack, mapping controls to how the team really works, and coordinating the audit itself. Done well, the internal lift drops to hours per week instead of a dedicated headcount.
Wiring Evidence into CI/CD, Practically
Start by mapping controls to pipeline stages rather than treating compliance as a separate track. NIST’s Secure Software Development Framework (SP 800-218) is a useful bridge here: it describes secure development practices in outcome terms that translate cleanly into both pipeline steps and audit language, which makes it easier to show an auditor that a CI job satisfies a control.
Concretely, that means static analysis and dependency scanning as required pipeline gates that publish their results as artifacts, deployment approvals recorded in the deployment tool rather than in Slack threads, secrets scanning on every commit, and infrastructure-as-code review so environment changes get the same approval trail as application code. Store every output as an immutable, timestamped artifact. If a control ran, the pipeline should have produced a record without anyone thinking about it.
There is a compounding return on this work. The same pipeline evidence covers a large share of the technical controls in ISO/IEC 27001, so a team that instruments CI/CD once for SOC 2 has done most of the technical groundwork for a second certification. For companies selling into both US and European enterprises, that overlap is worth planning for from the start.
Insider Note: Across the SOC 2 engagements our team has supported, the most common Type II exception is not a technical control at all. It is user access reviews: the review actually happened, but nobody kept a dated record of who reviewed which systems and what changed as a result. Auditors treat an undocumented control as an inoperative one.
Conclusion
SOC 2 evidence collection is a pipeline engineering problem, and it rewards the same instincts DevOps teams already have: automate the repetitive work, make outputs observable, and treat configuration as code. Manual evidence programs fail Type II audits for structural reasons, not effort reasons, because point-in-time captures cannot prove continuous operation. Automation platforms solve collection but not implementation, scoping, or remediation, which is where teams either invest internal ownership or bring in a partner. Instrument the pipeline once, and every subsequent audit, and every additional framework, gets cheaper.
Frequently Asked Questions
Can you pass a SOC 2 audit without a compliance automation platform?
Yes. SOC 2 specifies what controls must achieve, not what tooling you use, and companies passed audits for years with spreadsheets and screenshots. The trade-off is cost and risk: manual collection consumes weeks of engineering time per cycle and is far more likely to produce evidence gaps in a Type II observation window that cannot be repaired afterward.
How long does SOC 2 take for a team with mature CI/CD?
A SaaS team with solid pipeline hygiene and an automation platform can typically reach audit readiness in 4 to 8 weeks, followed by the Type II observation window of 3 to 12 months before the final report. Manual programs usually need 3 to 6 months just to reach readiness. The observation window length is a business decision made with your auditor; most first reports use 3 months.
Does automated evidence collection help with ISO 27001 too?
Substantially. The technical controls overlap heavily: access management, change management, vulnerability handling, and logging evidence collected for SOC 2 maps onto a large share of ISO 27001 Annex A. Most automation platforms cross-map evidence across frameworks automatically, so the second certification costs a fraction of the first.
What happens if a control fails during the observation window?
A failure does not automatically sink the audit. Auditors report it as an exception, and what matters is detection and response: when you found it, how quickly you remediated, and whether the failure was systemic. A documented failure with a fast, recorded fix reads far better than a gap discovered by the auditor. This is another argument for continuous monitoring, since you cannot respond to a failure you notice five months late.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals
Automating SOC 2 evidence collection works best when teams build it into daily workflows from the start. CI/CD pipelines should capture clear records of approvals, test results, access changes, and deployments. It is also important to protect these records from edits and set sensible retention rules. Teams should review sample evidence regularly to catch gaps before an audit. Automation saves time, but clear ownership and human checks help keep the evidence accurate and useful.
I’d also look at the reliability of the compliance process itself. If audit records depend on the same pipelines and systems under review, there should be safeguards against unauthorized changes, accidental deletion, and missing records. Monitoring the evidence-collection jobs is equally important—an unnoticed collector failure can leave gaps in the audit trail even while the development pipeline appears to be working normally.