Purpose of This Readiness Assessment
This self-assessment checklist is designed for organizations preparing for a SOC 2 Type II examination that includes CI/CD pipelines within the audit scope. Use it to identify control gaps, prioritize remediation efforts, and build confidence that your pipeline environment will withstand auditor scrutiny.
For each checklist item, assess your current state as Yes (fully implemented and evidenced), Partial (partially implemented or lacking evidence), or No (not implemented). Items assessed as Partial or No require remediation before the audit period begins.
CC6: Access Controls Checklist
| # | Control Item | Status (Y/P/N) | Evidence Required | Remediation Guidance |
|---|---|---|---|---|
| 6.1 | RBAC is configured across all pipeline platforms (repository, build system, artifact registry, deployment tools) | RBAC configuration exports, role definitions document | Define standard roles (developer, reviewer, approver, admin) and map to each platform’s permission model | |
| 6.2 | MFA is enforced for all human accounts accessing pipeline systems | MFA policy configuration, enrollment reports, exception log | Enable MFA organization-wide; document any technical exceptions with compensating controls | |
| 6.3 | Service accounts follow least-privilege principle with documented justification for each permission | Service account inventory, permission justification matrix | Audit all service accounts; remove unnecessary permissions; document business justification for remaining permissions | |
| 6.4 | Quarterly access reviews are scheduled and cover all pipeline systems | Review schedule, completed review records, remediation evidence | Establish recurring calendar events; assign review owners; create standard review template | |
| 6.5 | Onboarding/offboarding procedures include pipeline system access provisioning and deprovisioning | HR integration documentation, deprovisioning checklists, timeliness records | Add pipeline systems to IT onboarding/offboarding checklists; automate where possible | |
| 6.6 | Emergency and break-glass access procedures are documented and require post-use review | Emergency access procedure document, usage logs, post-use review records | Document emergency access procedure; implement alerting on emergency access use | |
| 6.7 | Secrets and credentials are managed through a dedicated secrets management solution (not hardcoded) | Secrets management tool configuration, scan results showing no hardcoded secrets | Implement secrets management tool; run secret scanning across all repositories | |
| 6.8 | Network access to pipeline infrastructure is restricted to authorized networks and personnel | Network configuration documentation, firewall rules, VPN/zero-trust configuration | Implement network restrictions; document allowed access paths | |
| 6.9 | Pipeline runner/agent access is isolated and cannot access resources beyond their defined scope | Runner configuration, isolation documentation, network segmentation evidence | Configure runner isolation; implement network segmentation for build environments |
CC7: System Operations Checklist
| # | Control Item | Status (Y/P/N) | Evidence Required | Remediation Guidance |
|---|---|---|---|---|
| 7.1 | Pipeline configuration changes are logged and monitored with alerts for unauthorized modifications | Monitoring configuration, alert rules, sample alert notifications | Implement configuration change monitoring; configure alerts to security team | |
| 7.2 | Anomaly detection is in place for unusual pipeline activity (off-hours builds, unusual deployment patterns) | Anomaly detection rules, baseline documentation, alert history | Define normal pipeline behavior baselines; configure anomaly alerts | |
| 7.3 | Pipeline incidents are integrated into the organization’s incident response program | IR plan covering CI/CD, incident classification criteria, escalation procedures | Update IR plan to include CI/CD scenarios; train IR team on pipeline-specific incidents | |
| 7.4 | Pipeline infrastructure capacity is monitored and managed to prevent degradation | Capacity monitoring dashboards, scaling policies, capacity planning documents | Implement capacity monitoring; establish scaling thresholds and procedures | |
| 7.5 | Backup and recovery procedures exist for pipeline configuration and infrastructure | Backup schedules, recovery procedures, recovery test results | Implement pipeline configuration backups; document and test recovery procedures | |
| 7.6 | Logging is centralized with defined retention periods meeting audit requirements | Log aggregation configuration, retention policy documentation, storage verification | Centralize pipeline logs; configure retention to cover audit period plus buffer | |
| 7.7 | Security event alerts have defined response procedures and assigned owners | Alert response playbooks, owner assignments, response time SLAs | Create response playbooks for each alert type; assign and train owners |
CC8: Change Management Checklist
| # | Control Item | Status (Y/P/N) | Evidence Required | Remediation Guidance |
|---|---|---|---|---|
| 8.1 | All production changes require peer code review by a qualified reviewer who is not the author | Branch protection rules, merge request settings, sample review records | Configure branch protection; enforce minimum reviewer requirements | |
| 8.2 | Formal approval is required before deployment to production, with approval documented and attributed | Deployment approval configuration, approval logs with timestamps and approver identity | Implement deployment approval gates; ensure approvals are logged with attribution | |
| 8.3 | Segregation of duties is enforced — the author cannot approve or deploy their own changes | SoD enforcement configuration, validation reports showing no self-approvals | Configure technical enforcement preventing self-approval; run validation reports | |
| 8.4 | Automated security scanning (SAST, SCA, secrets detection) runs on every change with defined thresholds | Pipeline configuration showing scan steps, threshold settings, gate enforcement logs | Integrate security scanning tools; define severity-based thresholds; configure blocking gates | |
| 8.5 | Automated testing gates prevent deployment when quality criteria are not met | Test gate configuration, pass/fail logs, test coverage reports | Define minimum quality criteria; configure automated enforcement | |
| 8.6 | Rollback procedures are documented, tested, and can be executed within defined timeframes | Rollback procedure documentation, test records, execution time measurements | Document rollback procedures; schedule and conduct rollback testing | |
| 8.7 | Emergency change procedures are documented with enhanced controls (post-implementation review, expedited approval) | Emergency change procedure document, emergency change log, post-implementation review records | Define emergency change procedure; implement tracking and mandatory post-review | |
| 8.8 | Environment segregation prevents development/test changes from directly affecting production | Environment architecture documentation, access restrictions between environments | Implement environment segregation; restrict production access to deployment automation | |
| 8.9 | Change records provide complete traceability from requirement to production deployment | Sample change records showing end-to-end traceability, linking tools configuration | Configure issue-to-deployment linking; ensure all changes reference a tracked work item | |
| 8.10 | Pipeline-as-code changes are subject to the same review and approval process as application changes | Branch protection on pipeline configuration files, review records for pipeline changes | Extend branch protection to pipeline definition files; treat as production changes |
CC9: Risk Mitigation Checklist
| # | Control Item | Status (Y/P/N) | Evidence Required | Remediation Guidance |
|---|---|---|---|---|
| 9.1 | A complete inventory of third-party components and dependencies consumed through the pipeline exists | Software Bill of Materials (SBOM), dependency inventory reports | Implement SBOM generation; run dependency inventory across all projects | |
| 9.2 | Automated dependency scanning identifies known vulnerabilities with defined remediation SLAs | Scan configuration, vulnerability reports, SLA documentation, remediation tracking | Implement dependency scanning; define severity-based remediation SLAs | |
| 9.3 | Pipeline SaaS vendors have been assessed for security and their SOC 2 reports reviewed | Vendor assessment records, SOC 2 report reviews, risk acceptance documentation | Request SOC 2 reports from all pipeline vendors; conduct and document assessments | |
| 9.4 | Shared infrastructure risks (shared runners, multi-tenant build environments) are assessed and mitigated | Risk assessment documentation, mitigation controls, isolation verification | Assess shared infrastructure risks; implement dedicated runners where risk warrants | |
| 9.5 | License compliance for open-source components is monitored and managed | License scanning configuration, compliance reports, approved license list | Implement license scanning; define approved license list; establish review process for exceptions | |
| 9.6 | Supply chain attack vectors (dependency confusion, compromised packages) are assessed with preventive controls | Threat assessment documentation, private registry configuration, package verification settings | Implement private registries or proxies; configure package signature verification | |
| 9.7 | Third-party integration access (webhooks, API tokens, OAuth apps) is inventoried and reviewed periodically | Integration inventory, access scope documentation, periodic review records | Inventory all integrations; document access scopes; schedule periodic reviews |
Gap Analysis: How to Prioritize Remediation
After completing the assessment, categorize findings using the following priority framework:
| Priority | Criteria | Remediation Timeline | Examples |
|---|---|---|---|
| Critical | Control is absent; directly affects audit opinion | Immediate (within 2 weeks) | No approval enforcement, no access reviews, no logging |
| High | Control is partially implemented; evidence gaps exist | Within 30 days | MFA not universal, reviews incomplete, some systems excluded |
| Medium | Control exists but evidence quality is insufficient | Within 60 days | Manual evidence, incomplete documentation, informal processes |
| Low | Control enhancement opportunity; not audit-critical | Within 90 days | Automation improvements, additional monitoring, enhanced reporting |
Recommended Preparation Timeline (6 Months Before Audit)
| Timeframe | Activity | Deliverable |
|---|---|---|
| Month 1 | Complete this readiness assessment; identify all gaps | Completed checklist with gap analysis and prioritized remediation plan |
| Month 2 | Remediate Critical and High priority gaps | Updated control implementations, evidence generation confirmed |
| Month 3 | Remediate Medium priority gaps; begin evidence collection validation | All controls operational, evidence retrieval tested |
| Month 4 | Conduct internal dry-run assessment using auditor sampling methodology | Internal assessment report with findings |
| Month 5 | Address dry-run findings; train teams on evidence production and interview preparation | Remediation complete, team preparation sessions conducted |
| Month 6 | Final readiness review; confirm all evidence streams are active and complete | Readiness confirmation, evidence index, point-of-contact list for auditors |
Related Resources
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- Audit Day Playbook
- How Auditors Review CI/CD
- Core CI/CD Security Controls
New to CI/CD auditing? Start with our Auditor’s Guide.
