Most engineering teams approach SOC 2 as a documentation exercise. They write policies, assign owners, and hope their existing systems produce enough evidence to satisfy an auditor. The teams that sail through Type II audits treat it differently: they engineer evidence production as a continuous system output, not a retrospective collection effort.
This guide covers what auditors actually request from your CI/CD pipeline, access management, and logging infrastructure — and how to ensure those systems produce clean, complete evidence by default.
What Auditors Are Testing
A SOC 2 Type II audit tests whether your controls operated consistently across the audit period. For engineering systems, this means the auditor will sample specific dates and request evidence that proves:
- Only authorised individuals could deploy to production
- Changes were reviewed and approved before deployment
- Access to production systems and sensitive data was appropriate at all times
- Anomalous access or changes triggered detection and response
- Infrastructure was configured to your stated security baseline throughout the period
CI/CD Pipeline Evidence Requirements
Your deployment pipeline is one of the most scrutinised areas in a security audit. Auditors look for:
- Approval records: Who approved every production deployment and when. Pull request merge records with required reviewer counts satisfy this if your branch protection rules are properly configured.
- Separation of duties: Evidence that the engineer who wrote the code did not also approve their own deployment to production. This requires enforcing required reviewers in GitHub/GitLab branch protection rules — and the audit log proving those rules were active throughout the period.
- Automated test gates: Evidence that security scanning, unit tests, and dependency checks ran before every production deployment. CI run logs with timestamps and pass/fail status serve as evidence.
- Change records: A linkable trail from ticket → pull request → CI run → deployment. Even a lightweight linear flow (Jira → GitHub → GitHub Actions → deployment log) satisfies this if the IDs are consistently referenced.
- Rollback capability: Documentation or demonstration that rollback procedures exist and have been tested.
Action: Export your branch protection configuration and store it alongside audit evidence. If you change it, capture before/after snapshots with timestamps.
Access Management Evidence
Access control evidence failures are the most common reason SOC 2 audits require remediation. Auditors will test:
- Provisioning and deprovisioning: Sampled joiners and leavers over the audit period. Can you show that access was granted based on an approved request and revoked within your stated SLA after offboarding?
- Access reviews: Quarterly or semi-annual records showing that someone with authority reviewed who had access to production systems and attested that access was appropriate
- Privileged access: Evidence that elevated permissions (production database access, cloud console admin, break-glass accounts) were used only when justified and logged with reason codes
- MFA enforcement: Configuration evidence and authentication logs showing MFA was required — not just available — for production system access throughout the period
- Terminated user access: Sampled departures showing access removed within 24-48 hours across your identity provider, cloud consoles, and SaaS tools
Action: Run quarterly access reviews as a formal, documented process — not an informal team check. Export the review record, who conducted it, what was reviewed, and any remediation actions taken.
Logging and Monitoring Evidence
Auditors verify that you can detect security events — and that your monitoring was active throughout the period, not just at audit time.
- Log retention: Evidence that audit logs were retained for your stated period (commonly 12 months minimum). Cloud storage lifecycle policies with Object Lock satisfy this.
- Alert configuration records: Snapshots or version-controlled definitions of your alert rules — showing they were in place throughout the audit period, not only configured after the audit started
- Incident and alert response records: A log of every security alert that fired, who triaged it, what the determination was, and whether escalation occurred. Even a simple spreadsheet or Jira project satisfies this if consistently maintained
- Vulnerability management: Evidence that dependency and container scanning ran on a defined schedule, findings were tracked, and high/critical issues were remediated within your stated SLA
Infrastructure Configuration Evidence
Configuration drift between audit samples is a common failure mode. Use infrastructure-as-code to make your baseline auditable by default:
- Store all infrastructure configuration in version-controlled IaC (Terraform, CDK, Pulumi). The git history is your configuration change log.
- Run continuous compliance checks (AWS Config rules, GCP Security Command Centre, Checkov in CI) and export compliance posture snapshots monthly
- Document your security baseline as code — encryption requirements, public access blocks, logging enablement — and alert on drift from that baseline
- Enable cloud provider audit logs (CloudTrail, Cloud Audit Logs) across all accounts and all regions from day one of your audit period
The Evidence Collection Habit That Changes Everything
Teams that pass Type II audits smoothly have one thing in common: they treat evidence as a continuous output, not a quarterly scramble. Practically, this means:
- Every access review produces a timestamped record immediately — not reconstructed later
- Every incident or alert response is logged in a system auditors can query, even if it is a simple project management tool
- Deployment pipeline logs are retained for the full audit period with immutability controls
- Infrastructure configuration is version-controlled, so the history is already the audit trail
SOC 2 readiness is largely an engineering problem. If your CI/CD, access management, and logging systems are well-designed, evidence collection becomes a reporting task rather than a project. We help compliance-focused engineering teams build this infrastructure as part of our Cloud and DevOps service. If you are preparing for a first audit, talk to our team — a short architecture review often surfaces the largest gaps early.
