Introduction: Why CI/CD Pipelines Are in Scope for SOC 2 Engagements
Modern software delivery relies on CI/CD pipelines as the central mechanism through which code changes move from development to production. For organizations pursuing SOC 2 attestation, these pipelines are not merely engineering infrastructure — they are control environments that directly affect the integrity, availability, and confidentiality of the services delivered to customers.
SOC 2 auditors increasingly recognize that CI/CD pipelines represent a critical control point where access decisions are enforced, changes are authorized, security testing occurs, and deployment integrity is established. If your organization delivers software through automated pipelines, those pipelines are squarely within the scope of your SOC 2 engagement.
This article provides a comprehensive mapping between the AICPA Trust Service Criteria and the specific controls that should be implemented and evidenced within CI/CD environments.
Comprehensive TSC-to-Pipeline Control Mapping
The following table maps each relevant Trust Service Criterion to the corresponding CI/CD control and the evidence an auditor expects to examine.
| TSC Criterion | Criterion Description | CI/CD Control | Evidence Required |
|---|---|---|---|
| CC6.1 | Logical access security over protected assets | Role-based access control (RBAC) for pipeline systems, repository permissions | RBAC configuration exports, access control lists, permission matrices |
| CC6.2 | Access credentials managed and authenticated | MFA enforcement, service account governance, secrets management | MFA enrollment records, secrets rotation logs, credential audit reports |
| CC6.3 | Access authorized based on business need | Least-privilege enforcement, just-in-time access for elevated permissions | Access request/approval records, quarterly access reviews, privilege escalation logs |
| CC6.6 | Security measures against external threats | Network segmentation of build environments, runner isolation, artifact integrity | Network diagrams, firewall rules, runner configuration documentation |
| CC7.1 | Detection of configuration changes | Pipeline configuration monitoring, drift detection, infrastructure-as-code auditing | Configuration change logs, drift detection reports, IaC audit trails |
| CC7.2 | Monitoring for anomalies and indicators of compromise | Pipeline anomaly detection, unusual build pattern alerts, failed deployment monitoring | Alerting configuration, anomaly detection reports, incident tickets from alerts |
| CC7.3 | Evaluation of detected events | Triage processes for pipeline security events, severity classification | Incident response runbooks, triage records, event classification logs |
| CC7.4 | Incident response execution | Pipeline incident response procedures, emergency rollback processes | IR plans covering CI/CD, post-incident reviews, rollback execution logs |
| CC8.1 | Changes authorized, designed, developed, configured, tested, and approved | Mandatory code review, approval workflows, deployment gates, automated testing | Merge request approval records, gate pass/fail logs, test execution reports |
| CC9.1 | Risk identification and assessment | Third-party dependency risk assessments, pipeline threat modeling | Risk registers, dependency inventories, threat model documents |
| CC9.2 | Risk mitigation activities | Dependency scanning, vulnerability remediation SLAs, vendor assessments | Scan reports, remediation timelines, vendor assessment records |
CC6: Logical and Physical Access Controls in CI/CD
Access controls within CI/CD environments present unique challenges compared to traditional application access. Pipeline systems often involve multiple interconnected platforms — source code repositories, build systems, artifact registries, deployment orchestrators, and cloud infrastructure providers.
Key Control Requirements
Role-Based Access Control (RBAC): Every pipeline platform must enforce granular RBAC that distinguishes between developers, reviewers, approvers, and administrators. Auditors verify that roles are formally defined, documented, and consistently applied across all pipeline components.
Multi-Factor Authentication (MFA): All human access to pipeline systems must require MFA. This includes repository access, build system consoles, deployment approval interfaces, and infrastructure management consoles. Auditors will specifically test for MFA bypass scenarios and exceptions.
Least Privilege: Pipeline service accounts, runner credentials, and automation tokens must operate with the minimum permissions necessary. Overly permissive service accounts represent one of the most common findings in CI/CD audits.
Access Reviews: Quarterly access reviews must cover all pipeline systems. These reviews should validate that terminated employees have been deprovisioned, that role assignments remain appropriate, and that service account permissions have not expanded beyond their original scope.
CC7: System Operations — Pipeline Monitoring and Incident Response
Operational monitoring of CI/CD pipelines must go beyond uptime and performance metrics. SOC 2 requires that organizations detect, evaluate, and respond to events that could affect service delivery.
Pipeline Monitoring Requirements
- Configuration change detection: Alert when pipeline definitions, security policies, or approval requirements are modified
- Anomaly detection: Identify unusual patterns such as builds triggered outside business hours, deployments bypassing approval gates, or sudden spikes in failed security scans
- Capacity management: Ensure build infrastructure can sustain expected workloads without degradation that could lead to skipped security checks
- Incident response integration: Pipeline security events must feed into the organization’s broader incident response program with defined severity classifications and response procedures
CC8: Change Management — The Core of CI/CD Governance
Change management is where CI/CD pipelines most directly intersect with SOC 2 requirements. The pipeline itself is the change management mechanism, and auditors will scrutinize whether it enforces controls consistently.
Critical Controls
Code Review Requirements: Every change destined for production must undergo peer review by a qualified individual who is not the author. Auditors will sample merge requests to verify this is consistently enforced.
Approval Workflows: Formal approval must be required before deployment to production. The approval must be documented, time-stamped, and attributable to a specific individual with the authority to approve.
Deployment Gates: Automated quality and security gates must prevent deployment when defined thresholds are not met. Gate criteria should include security scan results, test coverage, and compliance checks.
Rollback Capabilities: Documented and tested rollback procedures must exist for every deployment. Auditors will verify that rollback has been tested and that rollback events are logged.
Segregation of Duties: The person who writes code must not be the same person who approves and deploys it. This is a fundamental control that auditors verify through sampling of deployment records.
CC9: Risk Mitigation — Third-Party and Supply Chain Risks
CI/CD pipelines introduce significant third-party risk through open-source dependencies, shared build infrastructure, and SaaS-based tooling.
Risk Areas to Address
Third-Party Component Risks: Maintain a complete inventory of open-source and third-party components consumed through the pipeline. Implement automated scanning for known vulnerabilities and license compliance issues.
Shared Runner Risks: If using shared build infrastructure (cloud-hosted runners, shared build agents), assess and document the isolation guarantees. Shared runners may expose secrets or allow cross-tenant interference.
SaaS Dependency Governance: Evaluate and document the security posture of every SaaS platform in the pipeline chain. Obtain and review SOC 2 reports from your pipeline tool vendors as part of your vendor management program.
Availability and Confidentiality Criteria in CI/CD
Availability: If pipeline availability directly affects service delivery to customers, availability criteria come into scope. Document recovery time objectives for pipeline infrastructure and test disaster recovery procedures.
Confidentiality: Pipelines routinely handle confidential information including source code, secrets, API keys, and configuration data. Controls must protect confidential information at rest and in transit throughout the pipeline.
What SOC 2 Auditors Specifically Test For
- Evidence that controls operate consistently — not just that they exist in policy
- System-generated evidence over self-reported or manually compiled evidence
- Samples of change records showing complete approval chains
- Access review documentation showing actual remediation of identified issues
- Incident response records demonstrating that pipeline events are detected and addressed
- Completeness of the control environment — no gaps where changes bypass the pipeline
Common Control Deficiencies in CI/CD Environments
| Deficiency | Impact | Typical Finding |
|---|---|---|
| Emergency access procedures not formalized | Uncontrolled bypass of change management | CC8.1 exception — changes deployed without required approval |
| Service accounts with excessive permissions | Violation of least-privilege principle | CC6.3 deficiency — access exceeds business requirement |
| Inconsistent MFA enforcement | Unauthorized access risk | CC6.2 deficiency — authentication controls not uniformly applied |
| No monitoring of pipeline configuration changes | Undetected weakening of controls | CC7.1 deficiency — changes to control environment not detected |
| Access reviews not covering pipeline systems | Stale or inappropriate access persists | CC6.3 deficiency — periodic review does not cover all in-scope systems |
| No segregation of duties enforcement | Single individual can author and deploy changes | CC8.1 deficiency — insufficient separation of incompatible duties |
Related Resources
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- Core CI/CD Security Controls
- Dual-Compliance Architecture
- How Auditors Review CI/CD
New to CI/CD auditing? Start with our Auditor’s Guide.
