Overview
A CI/CD Deployment Pipeline is the controlled, automated process used to build, test, approve, and deploy code changes into production systems. It ensures that all changes are authorized, tested, and traceable in alignment with SOC 2 CC8 change management requirements.
Step-by-Step Process
Define pipeline standards
The Engineering Lead defines required pipeline stages (build, test, security scan, approval, deploy) and documents them in the engineering handbook or repository README. This establishes the baseline controls that every release must follow. The output is an approved pipeline standard referenced by all repositories.
Role: Engineering Lead
Configure pipeline in repository
An engineer configures the CI/CD pipeline file in the application repository according to the approved standard. This includes specifying triggers, environments, and required checks. The output is a version-controlled pipeline configuration file.
Role: Software Engineer
Enforce code change approvals
Branch protection rules are configured to require peer review and passing pipeline checks before merge. The Engineering Lead verifies that no direct commits to protected branches are allowed. The output is enforced repository settings tied to user identities.
Role: Engineering Lead
Execute automated tests and scans
The pipeline automatically runs unit tests, integration tests, and security scans on each change. Failures block the pipeline and prevent deployment. The output is time-stamped test and scan results stored in the CI/CD tool.
Role: CI/CD System
Approve production deployment
For production releases, a designated approver reviews the pipeline results and approves deployment within the CI/CD tool. This ensures segregation of duties between code authors and deployers. The output is an auditable approval record with user and timestamp.
Role: Engineering Lead
Deploy to target environment
The pipeline deploys the approved build to the target environment using automated scripts. Deployment logs are generated and retained. The output is a successful deployment record tied to a specific commit and release.
Role: CI/CD System
Validate deployment outcome
Post-deployment checks such as health checks or smoke tests are reviewed to confirm system stability. Any issues are logged and remediated through the incident or rollback process. The output is documented validation results.
Role: Software Engineer
Retain deployment evidence
Pipeline logs, approvals, and deployment artifacts are retained according to the evidence retention policy. The Engineering Lead ensures evidence is accessible for audits. The output is a complete, time-stamped audit trail per release.
Role: Engineering Lead
What You Need Before Starting
- Approved CI/CD pipeline standard documentation
- Access to source code repository with admin permissions
- CI/CD tool access (GitHub Actions, GitLab CI, or Jenkins)
- Defined environments (staging, production)
Evidence Your Auditor Expects
- Version-controlled pipeline configuration file (e.g., .github/workflows/deploy.yml) with commit date
- Screenshot of branch protection rules showing required reviews and checks with timestamp
- CI/CD pipeline run log showing test results and deployment status with date and run ID
- Production deployment approval record showing approver username and approval timestamp
How This Looks In Your Tools
GitHub Actions
In the repository, go to Code > .github/workflows and create or update a workflow YAML file defining build, test, and deploy jobs. Configure triggers under “on:” (e.g., push to main) and required environments under Jobs > environment.
Navigate to Settings > Branches > Branch protection rules and enable “Require a pull request before merging” and “Require status checks to pass before merging.” Add the GitHub Actions workflow checks and require at least one reviewer.
For production approvals, go to Settings > Environments > production and enable “Required reviewers.” Approvals and deployment logs are visible under Actions > specific workflow run.
GitLab CI
In the repository, create or update the .gitlab-ci.yml file defining stages such as build, test, and deploy. Specify environment names and deployment scripts under the deploy stage.
Go to Settings > Repository > Protected Branches and protect the main branch by requiring merge requests and setting allowed approvers. Ensure pipeline success is required before merge.
For production control, navigate to Settings > CI/CD > Environments and configure protected environments with required approvers. Deployment history and logs are available under CI/CD > Pipelines and Environments.
Jenkins
Create or update a Jenkinsfile in the repository defining pipeline stages for build, test, and deploy. Configure credentials and environment variables using Jenkins > Manage Jenkins > Credentials.
In Jenkins, enable branch-based builds by configuring a Multibranch Pipeline job and linking it to the source code repository. Restrict who can trigger jobs via Manage Jenkins > Configure Global Security.
For approvals, add an input step in the Jenkinsfile for production deployment. Deployment logs and approval timestamps are stored in the Jenkins job build history.
Common Audit Findings
- Deployments without documented approval
- This occurs when production deployments are fully automated without approval gates. Prevent it by enforcing required reviewers or manual approval steps for production environments in the CI/CD tool.
- Unprotected main branch
- Auditors see this when branch protection rules are not enabled. Prevent it by requiring pull requests, reviews, and passing pipeline checks before merge.
- Missing pipeline logs for releases
- This happens when logs are not retained or are overwritten. Prevent it by configuring log retention settings and retaining pipeline run history for the audit period.
- Pipeline configuration changed without review
- This occurs when CI/CD files are editable without peer review. Prevent it by storing pipeline configurations in the repository and subjecting them to the same review process as application code.