SOC 2 y Seguridad CI/CD

SOC 2: Trust Service Criteria Applied to the Software Delivery Lifecycle

SOC 2 has become the de facto assurance standard for SaaS providers, technology service organisations, and any company whose customers require independent verification of security controls. A SOC 2 Type II report — issued by a CPA firm following the AICPA Trust Service Criteria — provides stakeholders with evidence that an organisation’s controls are not only designed appropriately but have operated effectively over a sustained period.

For organisations that deliver software through CI/CD pipelines, the pipeline itself is a system component that directly affects the security, availability, and processing integrity of the services under examination. This hub page provides comprehensive guidance on mapping Trust Service Criteria to CI/CD controls, preparing for Type II audits, and building the sustained evidence trail that auditors require.

SOC 2 Framework Overview

SOC 2 is governed by the AICPA’s Trust Service Criteria (TSC), which define five categories of controls: Security (the Common Criteria, required for all SOC 2 engagements), Availability, Processing Integrity, Confidentiality, and Privacy. The Security criteria — designated CC1 through CC9 — form the foundation and are always in scope.

Type I vs Type II

  • Type I: Evaluates the design of controls at a specific point in time. Useful for initial assurance but limited in scope — it confirms that controls exist but does not verify they operate consistently.
  • Type II: Evaluates both the design and operating effectiveness of controls over a defined audit period, typically six to twelve months. This is the standard that customers and partners expect, and it requires sustained evidence of control operation.

The SOC 2 report includes the auditor’s opinion, a description of the system, the control criteria tested, the tests performed, and the results. Any control exceptions — instances where a control did not operate as designed — are documented and may qualify the auditor’s opinion.

Why CI/CD Is in Scope

The system description in a SOC 2 report defines the boundaries of what is being examined. CI/CD pipelines are system components that directly affect the security posture of the services delivered to customers. They control how code moves from development to production, how changes are approved, how vulnerabilities are identified, and how access to production environments is governed.

Excluding CI/CD from the system boundary creates a significant gap that auditors and sophisticated customers will question. If the pipeline can deploy arbitrary code to production without controls, then the controls on the production environment itself are undermined. Modern SOC 2 engagements increasingly recognise this and expect the software delivery infrastructure to be included within scope.

Trust Service Criteria Mapped to CI/CD Controls

CC6 — Logical and Physical Access Controls

CC6 addresses how the organisation restricts logical and physical access to system components. In CI/CD environments, this translates to:

  • Role-based access control (RBAC): Pipeline permissions must be assigned based on job function, with clearly defined roles for developers, reviewers, approvers, and deployers.
  • Multi-factor authentication (MFA): All access to CI/CD platforms, source code repositories, and deployment targets must require MFA, particularly for administrative and deployment actions.
  • Access reviews: Periodic reviews of who has access to pipeline configurations, secrets, and production deployment capabilities, with documented evidence of review outcomes and remediation of excessive permissions.
  • Least privilege for pipelines: Pipeline service accounts and automation credentials must be scoped to the minimum permissions required, with separate credentials per environment and regular rotation.
  • Secrets management: Credentials, API keys, tokens, and certificates used by pipelines must be stored in dedicated secrets management systems — never hardcoded in pipeline configurations or source code. Access to secrets must be logged and auditable.

CC7 — System Operations

CC7 requires the organisation to detect and respond to anomalies and security events. For CI/CD:

  • Pipeline monitoring: Continuous monitoring of pipeline execution for failures, unexpected behaviour, configuration changes, and performance anomalies.
  • Anomaly detection: Alerting on unusual patterns — deployments outside normal hours, builds triggered by unknown accounts, unexpected changes to pipeline configurations, or deviations from established deployment patterns.
  • Incident response integration: Pipeline security events must be integrated into the organisation’s incident response process, with defined escalation paths and response procedures for pipeline compromise scenarios.
  • Capacity management: Pipeline infrastructure must be monitored for capacity constraints that could affect availability, with scaling processes documented and tested.

CC8 — Change Management

CC8 is often the most scrutinised criterion in CI/CD environments because the pipeline is the primary mechanism through which changes reach production:

  • Code reviews: All changes must undergo peer review before merging, with review evidence captured in the version control system. Branch protection rules should enforce this technically, not rely on policy alone.
  • Approval workflows: Production deployments must require explicit approval from authorised personnel, with system-enforced approval gates that cannot be bypassed.
  • Deployment gates: Pipeline stages should include quality gates — security testing, functional testing, compliance checks — that must pass before promotion to the next environment.
  • Rollback capability: The organisation must demonstrate the ability to roll back deployments quickly and reliably, with tested rollback procedures and evidence of rollback execution when required.
  • Segregation of duties: The person who writes code should not be the same person who approves its deployment to production. Pipeline configurations should enforce this separation technically.
  • Environment separation: Development, staging, and production environments must be distinct, with separate configurations, credentials, and access controls for each.

CC9 — Risk Mitigation

CC9 addresses how the organisation identifies, assesses, and mitigates risks from business relationships and external dependencies:

  • Third-party dependency risk: Open-source libraries and external packages consumed by pipelines must be assessed for vulnerabilities, licence compliance, and supply chain risk through Software Composition Analysis (SCA) and SBOM generation.
  • SaaS tool governance: CI/CD platforms, artifact registries, and other SaaS components in the delivery chain must be evaluated for security posture, with vendor risk assessments maintained and reviewed periodically.
  • Shared runner risks: Where CI/CD runners are shared across projects or teams, the risks of cross-contamination, secret exposure, and resource exhaustion must be assessed and mitigated through isolation measures.

Availability Criteria

When Availability is included in the SOC 2 scope, CI/CD pipelines must demonstrate:

  • Deployment reliability: Pipelines must operate reliably with defined SLAs, monitored uptime, and documented procedures for handling pipeline failures.
  • Rollback capability: The ability to revert to a known-good state rapidly when a deployment introduces availability issues.
  • Disaster recovery: Pipeline infrastructure must be included in disaster recovery plans, with defined RTOs and RPOs and regular testing of recovery procedures.

Confidentiality Criteria

When Confidentiality is in scope, the following CI/CD controls apply:

  • Secrets protection: Pipeline credentials, API keys, and tokens must be encrypted at rest and in transit, with access restricted to authorised processes and personnel.
  • Artifact encryption: Build artifacts and container images stored in registries should be encrypted, with access controlled and logged.
  • Data classification: Information processed by pipelines — source code, configuration data, test data — must be classified according to the organisation’s data classification scheme and handled accordingly.

Type I vs Type II: What Changes for CI/CD

The difference between Type I and Type II is particularly significant for CI/CD environments. A Type I audit can verify that pipeline controls are configured correctly at a point in time — branch protection rules are enabled, approval gates exist, security scanning is integrated. This is a snapshot.

A Type II audit requires evidence that these controls operated consistently over the entire audit period, typically six to twelve months. This means the organisation must demonstrate:

  • Every production deployment during the audit period followed the approved change management process
  • Access reviews were conducted at defined intervals and findings were remediated
  • Security testing ran on every build and vulnerabilities were addressed within defined SLAs
  • Monitoring alerts were responded to within defined timeframes
  • No control exceptions occurred, or exceptions were documented with compensating controls

CI/CD pipelines are uniquely well-suited to Type II evidence because they produce continuous, system-generated, timestamped records of every action. The key is ensuring that logging is comprehensive, retention meets the audit window, and evidence can be retrieved efficiently when auditors request it.

Common Control Deficiencies

The following deficiencies are frequently identified during SOC 2 Type II examinations of organisations with CI/CD pipelines:

  • Inconsistent approval enforcement: Approval gates exist but are bypassed for «emergency» deployments without documented exception processes, creating control exceptions in the audit report.
  • Missing access reviews: Access to CI/CD platforms and deployment credentials is not reviewed at regular intervals, or reviews are conducted but lack evidence of remediation for identified issues.
  • No evidence of monitoring: Pipeline monitoring tools exist but there is no evidence that alerts were reviewed, triaged, or acted upon during the audit period.
  • Gaps in change management documentation: Some deployments cannot be traced back to approved change requests, or the linkage between code changes, reviews, approvals, and deployments is incomplete.
  • Shared credentials: Pipeline service accounts or deployment credentials are shared across environments or teams without individual accountability.
  • Insufficient log retention: Pipeline logs are purged before the end of the audit window, making it impossible to provide evidence for the full audit period.
  • Unmanaged third-party risk: Third-party CI/CD plugins, actions, or dependencies are used without vendor risk assessment or security evaluation.

Deep Dive Articles

Explore detailed guidance on specific aspects of SOC 2 compliance in CI/CD environments:

Related Content

Cross-Framework References

SOC 2 controls frequently overlap with requirements from other regulatory frameworks. Organisations subject to multiple compliance obligations can build a unified control environment: