\The CI/CD Pipeline Is Your Compliance Engine. Here's How to Wire It Up.You're a few weeks into your SOC 2 process. An auditor you're paying by the hour, is asking you to manually export six months of access logs, screenshot your deployment approvals, and compile a spreadsheet of every employee who touched production. Meanwhile, your pipeline has been enforcing code reviews, running automated scans, and logging every deployment the entire time. The controls were running. Nobody thought to capture the proof.This is the part of SOC 2 that catches most engineering teams off guard. Not the controls themselves, but the gap between what your pipeline already does and what an auditor can actually see. If you're an engineer, DevOps lead, or CTO at a B2B SaaS company navigating your first audit or tired of the scramble that comes with every renewal, this is a guide to closing that gap for good.\What SOC 2 Auditors Are Actually Looking ForBefore mapping anything to your pipeline, it helps to understand what the framework is actually measuring. SOC 2 is built around the AICPA's Trust Services Criteria, a framework established in 2017 and still unchanged in structure today. Security is the only required category, and within it, the nine Common Criteria (CC1 through CC9) define what auditors evaluate. [1]Most of the technical controls that matter to engineers live in four of those nine areas:CC6 — Logical and Physical Access Controls: Who can access what, how access is granted, and how it's removed. In practice: identity management, MFA enforcement, access reviews, and role-based permissions.CC7 — System Operations: How the system is monitored, how anomalies are detected, and how incidents are handled. In practice: logging, alerting, and operational runbooks.CC8 — Change Management: How changes to the system are authorized, tested, and deployed. In practice: your entire software delivery process — code review, CI checks, deployment gates.CC9 — Risk Mitigation: How the organization identifies and manages risk, including third-party dependencies. In practice: dependency scanning, vendor assessments, and vulnerability management.Here is the insight worth sitting with: CC8 describes your CI/CD pipeline almost word for word. Auditors want evidence that changes are authorized, reviewed, tested, and deployed in a controlled way. That is exactly what a well-run pipeline enforces. If your pipeline already does this consistently, you are largely SOC 2 compliant in practice. The only thing standing between you and a clean audit is whether your pipeline is retaining the evidence to prove it.The Pipeline as a Control FrameworkInstead of thinking of your pipeline as a delivery mechanism with security checks bolted on, think of it as a control framework that continuously generates compliance evidence as a byproduct of shipping software. Every stage maps to one or more SOC 2 criteria. Here is what that looks like in practice.Code Commit and Pull RequestWhat the pipeline does: Enforces peer review before code is merged. Branch protection rules prevent direct commits to main. Required reviewers must approve before a merge is allowed.What this maps to (CC8): Auditors need evidence that changes are reviewed and authorized before reaching production. A GitHub or GitLab pull request with required approvals, a linked ticket, and a merge timestamp is exactly that evidence. You are already generating it. You just need to make sure it is retained.What auditors ask for: A sample of PR records from across the audit window showing consistent review and approval. On GitHub, this is an export away.CI Stage: Static Analysis and Secrets ScanningWhat the pipeline does: Runs automated SAST tools against every build to catch injection vulnerabilities, insecure patterns, and other code-level issues. Runs secrets detection to prevent API keys, tokens, and credentials from being committed to source control.What this maps to (CC7, CC9): Automated vulnerability detection is a core expectation in both criteria. There is a strong financial argument for doing this in CI rather than later: according to NIST's foundational research on software testing infrastructure, over half of software bugs are not found until downstream in the development process, and the IBM Systems Sciences Institute has documented that fixing a defect found in production costs up to 100 times more than catching it at the design stage. [2] Running SAST in CI is one of the highest-return controls you can implement, both for security and for engineering efficiency.Practical tooling: Semgrep and SonarQube for SAST. GitLeaks, Trufflehog, or GitHub Advanced Security for secrets detection. Most run natively in GitHub Actions, GitLab CI, or Jenkins with minimal configuration.What auditors ask for: Evidence that vulnerability scanning is in place and that findings are tracked through to remediation. CI scan output logs, retained across the audit window, serve as that evidence directly.Build Stage: Dependency Scanning and Artifact IntegrityWhat the pipeline does: Software Composition Analysis (SCA) tools scan third-party dependencies for known CVEs. Signed build artifacts create a traceable chain from source code to deployable image.What this maps to (CC9, CC7): Third-party risk is a growing area of auditor focus, and the data justifies it. According to Verizon's 2025 Data Breach Investigations Report, third-party involvement in breaches doubled year over year, now accounting for 30% of all confirmed incidents, up from 15% the prior year. [3] Your open-source dependencies are part of your attack surface, and auditors increasingly expect to see them managed systematically.Practical tooling: Snyk or Dependabot for dependency scanning. Docker Content Trust or Sigstore/cosign for artifact signing.What auditors ask for: Evidence of a process for identifying and remediating known vulnerabilities in dependencies. The key expectation is not that every CVE is fixed immediately, but that findings have a documented owner and a remediation path.Deploy Stage: IaC Scanning and Environment ControlsWhat the pipeline does: Infrastructure as Code scanning catches misconfigurations before they reach production. Overly permissive IAM roles, publicly accessible storage buckets, missing encryption settings. Deployment approvals add a human gate before changes reach production environments.What this maps to (CC6, CC8): IaC scanning is the closest thing to automated compliance validation for cloud infrastructure. Tools like Checkov evaluate Terraform and Kubernetes configurations against security benchmarks and can fail a deployment if critical misconfigurations are found. This directly addresses the access control and change management expectations auditors evaluate under CC6 and CC8.Practical tooling: Checkov or tfsec for IaC scanning. OPA (Open Policy Agent) for policy as code. Environment-specific deployment approvals through GitHub Environments or equivalent.What auditors ask for: Evidence that production deployments go through a defined approval process and that infrastructure is deployed in a known, controlled configuration. IaC scan results and deployment logs serve both purposes.Production: Logging, Monitoring, and Access ControlsWhat the pipeline does: Centralized logging captures activity across the production environment. Monitoring and alerting detect anomalies. CloudTrail or equivalent provides an immutable audit trail of API activity across your cloud environment.What this maps to (CC6, CC7): Production monitoring is the downstream complement to everything upstream. Without it, you can enforce all the right controls in your pipeline and still have no visibility into what is happening in production, which is exactly what CC7 requires you to demonstrate.Practical tooling: AWS CloudTrail and CloudWatch, or equivalent for other cloud providers. A SIEM platform once log volume warrants it. Access managed through a centralized identity provider with MFA enforced across all users.What auditors ask for: Evidence that logging is enabled, retained for an appropriate period, and actively reviewed. A CloudTrail export covering the audit window combined with documented alert response activity covers the majority of what auditors need here.Tooling That Doubles as Audit EvidenceThe same tools doing the security work are producing the audit evidence. You do not need a parallel documentation process. You need to make sure outputs are retained, structured, and accessible. A few principles that make this work reliably:Retain pipeline artifacts. CI run logs, scan reports, and deployment records should be retained for at least the duration of your SOC 2 observation window. For a Type II audit, that minimum observation period is three months, though most first-time audits run six to twelve months. [4] Most CI platforms let you configure artifact retention. Set it once and leave it.Use structured outputs where possible. SARIF-format scan results from SAST tools integrate directly into GitHub and are reviewable as part of the PR process. This creates a natural audit trail tying security findings to specific code changes and the reviewer who addressed them, without any additional documentation overhead.Connect your GRC platform to your pipeline. Compliance automation platforms such as Vanta, Drata, and Secureframe have native integrations with GitHub, AWS, and most major CI tools. Once connected, they pull evidence automatically and map it to the relevant SOC 2 criteria. PR approvals, deployment records, CloudTrail activity — collected continuously, available on demand. The manual evidence scramble that consumes weeks before an audit largely disappears.Timestamp everything. Auditors verifying Type II controls need to see that controls operated consistently over time, not just that they exist today. Timestamped logs, signed commits, and immutable deployment records are the foundation of that proof. Most modern tooling generates this automatically. The only failure mode is not retaining it.What Still Requires Human ProcessBuilding compliance into your pipeline does not automate everything, and it is worth being clear about where the boundaries are.Access reviews. SOC 2 expects periodic reviews of who has access to which systems. Tools can pull the current access state from your identity provider automatically, but a human still needs to review it, confirm or revoke access, and document that the review occurred. Quarterly is a reasonable cadence for most Series A companies.Vendor assessments. Third-party risk management requires a judgment call about whether a vendor's security posture is acceptable for your environment. Automating the evidence request — collecting SOC 2 reports and security questionnaire responses from vendors — is straightforward. The risk decision itself is not.Incident response. Your logging and alerting infrastructure can detect anomalies automatically. What happens next — who gets notified, how the incident is classified, what the escalation path looks like — needs to be documented and exercised before an auditor asks about it. A runbook that has never been tested is not a control.Policies and training. Security policies, acceptable use agreements, and annual security awareness training are expected at SOC 2. These live in a policy management tool and an HR system, not in a pipeline. Someone needs to own them and keep them current.The useful mental model: your pipeline handles the technical controls. Human process handles the governance controls. The clearest compliance programs are the ones where both are explicitly owned, and neither is assumed to cover the other.What This Looks Like in PracticeI have worked with engineering teams that had genuinely strong security practices. Code reviews enforced, infrastructure managed as code, automated scanning in every build. Their pipelines were doing the right things. But when the audit arrived, they spent three weeks manually reconstructing evidence that their tooling had been generating all along; Screenshots, spreadsheet exports, Slack messages to track down who approved what months ago.When you build the pipeline as a control framework from the start, that reconstruction work disappears. Your auditor asks for deployment approval records. You point to your GitHub environment logs. They ask for evidence of vulnerability scanning. You export your CI scan history. The time saved is meaningful: according to the SANS 2024 SOC Survey, 71% of security operations professionals identified a lack of automation and orchestration as the biggest obstacle in their workflows, and organizations using automated evidence collection consistently complete audits faster than those relying on manual processes. [5]The other shift is cultural. When compliance controls are embedded in the delivery process, they become part of how the team works rather than something enforced on them once a year. That changes the conversation between engineering and security from adversarial to collaborative, and it makes renewal audits progressively less disruptive as the program matures.Final ThoughtsSOC 2 has a reputation for being a documentation-heavy process that pulls engineering attention away from building. In many organizations, that reputation is earned, because compliance was treated as a separate workstream rather than a property of the delivery system itself.The controls auditors care about and the practices good engineering teams already follow are largely the same thing. Branch protection, code review, SAST, dependency scanning, IaC validation, centralized logging — these are not compliance theater. They are how you build reliable software at scale. SOC 2, at its core, is a framework for demonstrating that publicly.When your pipeline enforces the controls and retains the evidence, the audit stops being a fire drill and starts being a formality. That is the version of compliance worth building toward.References:[1] AICPA Trust Services Criteria (2017, updated points of focus 2022). The nine Common Criteria cover CC1 through CC9 under the Security category. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services[2] NIST, "The Economic Impacts of Inadequate Infrastructure for Software Testing" (2002). The IBM Systems Sciences Institute cost-of-defects research is referenced and contextualized in this report. https://www.nist.gov/document/samate-document-greg-tasseys-summary-pdf-nists-2002-report-economic-impacts-inadequate[3] Verizon 2025 Data Breach Investigations Report. Third-party involvement in breaches rose from 15% to 30% year over year. https://www.verizon.com/business/resources/reports/dbir/[4] Multiple independent sources corroborate the SOC 2 Type II observation period and overall timeline: Sprinto (sprinto.com), Sherlock Forensics (sherlockforensics.com), and BrightDefense (brightdefense.com) all cite a minimum 3-month observation window with a full journey of 6 to 15 months depending on scope and readiness.[5] SANS 2024 SOC Survey, cited via Scrut.io. https://www.scrut.io/hub/soc-2/soc-2-compliance-timeline\