Why SOC 2 Now Covers Your Pipeline
SOC 2 Type II certification has become a de facto requirement for selling software to Enterprise clients in the US, UK and DACH region. The certification evaluates whether an organization’s controls operate effectively over a period (typically 6-12 months).
Historically, SOC 2 auditors focused on production infrastructure — servers, databases, access management. Today, the pipeline that builds and deploys your application is firmly in scope. The logic is straightforward: if the pipeline has unrestricted access to production, signing keys and customer data — it’s a critical control point.
Common Findings in First-Time SOC 2 Pipeline Audits
No separation of duties. The same developer can write code, approve the pull request and deploy to production. SOC 2 CC6.1 requires responsibility separation — minimum one-person review before merge to production branch.
Static secrets without rotation. Cloud API tokens, database access keys — created once, never rotated. The auditor asks for rotation policy and enforcement evidence. OIDC eliminates this for cloud access entirely.
Insufficient log retention. Pipeline runs, builds, deploys — but logs are kept for 30 days (GitHub/GitLab default). SOC 2 Type II requires evidence spanning 6+ months.
No dependency scanning. The application uses dozens of external libraries with no vulnerability checks. SOC 2 CC7.1 requires a vulnerability identification and management process.
“As-built” documentation gap. The organization has a security policy in Word but no evidence the pipeline actually implements it. The auditor compares declared policy with actual configuration — discrepancies are findings.
Practical Pipeline Checklist for SOC 2
Security (CC6): Branch protection with required review. OIDC instead of static tokens. Least-privilege GITHUB_TOKEN. Secret scanning on every push.
Availability (CC7): Automated CVE scanning in dependencies. Pipeline status monitoring. Critical vulnerability response SLA.
Processing Integrity (CC8): Artifact signing (Cosign). SBOM with every build. Integrity verification before deployment.
Change Management (CC8.1): All pipeline configuration as code in Git. Pull request with review before changes. Automated tests after configuration changes.
An Evidence Pack automates evidence collection across all these areas — instead of manually compiling documentation before an audit, artifacts generate with every deploy.