Most engineering teams approach their first SOC 2 audit the wrong way. They spend weeks configuring tools and writing policies, then get surprised during fieldwork when the auditor asks for a timestamped screenshot proving that the quarterly access review happened in Q2. The tool ran. The review happened. There is just no record of it.
SOC 2 Type II audits cover an observation period, typically 6 months for a first engagement and 12 months for renewals. The 2024 CBIZ SOC Benchmark Study analyzed 193 SOC 2 reports and found an average of 124 controls per report. The audit is not a point-in-time assessment. It is a longitudinal sampling exercise. Every control must produce verifiable evidence across the entire period.
This checklist focuses on what cloud infrastructure engineers actually need to build and document.
What SOC 2 Actually Audits on Cloud Infrastructure
SOC 2 is built on nine Common Criteria (CC) categories defined by the AICPA. Only the Security criteria (CC1 through CC9) are mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional add-ons. As of 2024, 64.4% of SOC 2 reports include Confidentiality in scope, up from 34% in 2023, which means more engineering teams are getting pulled into data classification and access segmentation requirements they did not anticipate.
Cloud infrastructure is the primary evidence surface for six of the nine CC categories. The infrastructure generates the logs, enforces the access controls, manages the encryption keys, and hosts the change management audit trails.
Figure: SOC 2 Common Criteria mapped to their primary cloud infrastructure evidence sources
What auditors do not assess directly: the cloud provider’s own infrastructure layer. AWS, GCP, and Azure each hold their own SOC 2 reports. You inherit those infrastructure-layer controls. You are fully responsible for everything above the hypervisor, which means your application stack, your identity configuration, your operational workflows, and your evidence collection.
The Access Control Checklist (CC6)
CC6 is the most sampled criterion in SOC 2 audits. It covers identity, authentication, provisioning, deprovisioning, and access reviews. For cloud-native teams, it has more failure modes than any other area.
MFA coverage. MFA must be enforced on every privileged path to production, not just the primary cloud console. Auditors check the cloud provider (AWS, GCP, Azure), version control (GitHub, GitLab), CI/CD platforms, production databases, and any SaaS tool with access to customer data. A team that enforces MFA on AWS but not on GitHub fails CC6, even if no one has exploited the gap.
Quarterly access reviews. Policy must require quarterly reviews. Evidence must prove each review happened. For a 12-month audit, auditors sample Q1, Q2, Q3, and Q4 independently. Missing one quarter is a finding even if the other three are clean. The evidence format matters: raw exports from IAM, timestamped screenshots with visible system context, and approval records from whoever signed off on the review.
Offboarding. Auditors pull a list of all employee terminations during the observation period and sample a subset, sometimes 100% if the population is under 25. For each termination, they verify that accounts were disabled with a timestamp that matches or precedes the HR termination date. A two-day gap between termination and account disablement is a finding.
| Resource Type | MFA Required | Review Cadence | Evidence Format |
|---|---|---|---|
| Cloud console (AWS / GCP / Azure) | Yes, all accounts | Quarterly | IAM export with timestamp |
| GitHub / GitLab | Yes, all members | Quarterly | Org audit log export |
| CI/CD (GitHub Actions, Jenkins) | Yes, admin accounts | Quarterly | Pipeline access log |
| Production databases | Yes, human access | Quarterly | DB user list with last login |
| Third-party SaaS (Jira, Datadog, etc.) | Yes, if prod data | Quarterly | Admin-generated user report |
| Service accounts / API keys | Rotation policy | Annually | Rotation log with dates |
Service accounts require a different approach. Long-lived AWS access keys attached to IAM users are a finding. Auditors expect IAM roles for service-to-service communication and documented key rotation schedules for any long-lived credentials that cannot be replaced with role-based access.
Logging, Monitoring, and Alerting (CC7)
CC7 covers the operational evidence layer: what your infrastructure logs, how long those logs are retained, and what alerting you have configured. Three specific failures appear consistently in audit findings.
Log coverage gaps. AWS CloudTrail must be enabled in all regions, not just your primary region. Single-region CloudTrail is one of the most common AWS-specific findings. For GCP, Cloud Audit Logs must cover both Admin Activity and Data Access log types. For Azure, Monitor diagnostic settings must be configured at the subscription level, not just per-resource.
Log retention mismatch. A 30-day CloudWatch log retention setting does not survive a 6-month or 12-month audit. Retention must cover the full observation period plus a buffer. The standard practice is 12-month minimum retention in the primary log store, with archive tiers (S3 Glacier, GCS Archive) for cost management. Auditors cannot retroactively recover logs that were rotated out during the observation period.
Alerting evidence. Having GuardDuty or Security Command Center enabled is not sufficient. Auditors expect evidence that alerts are being reviewed and acted on. That means a documented process for triaging security findings, tickets created for each finding above a threshold, and evidence that the process ran during the observation period.
Figure: Log sources flow through SIEM to generate timestamped, audit-ready evidence records for CC7 compliance
Vulnerability scanning connects to CC7 and CC3. SOC 2 does not mandate a specific scanning tool or cadence, but auditors treat monthly vulnerability scans as table stakes for CC3.2 (Risk Assessment) and expect evidence that scan findings were reviewed and remediated on a documented schedule. Annual penetration tests cost $5,000-$15,000 for a typical SaaS application and provide the strongest evidence for this criterion.
Change Management and Secrets Hygiene (CC8 and CC6.7)
CC8 is the change management criterion. For engineering teams running CI/CD pipelines, it has one specific failure mode that trips up nearly every first-time audit: retroactive change tickets.
The control requires that every production change have a corresponding change ticket created before the deployment begins. Auditors verify this by comparing deployment timestamps in CloudTrail or CI/CD audit logs to the ticket creation timestamps in your change management system. A ticket created five minutes after a deployment is a finding. Auditors sample across the full observation period, which means a single team’s habit of creating tickets after the fact will generate multiple findings.
The operational fix is to require a ticket ID in the CI/CD pipeline configuration before a deployment job can be triggered. The ticket ID becomes part of the deployment log, and the creation timestamp is verifiable in Jira or ServiceNow.
| Evidence Type | What Auditors Check | Common Finding |
|---|---|---|
| Change tickets | Creation timestamp vs. deployment timestamp | Ticket created after deployment |
| Approval records | Approver name, timestamp, ticket reference | Self-approval without second reviewer |
| Test environment | Evidence deployment ran in staging first | No staging environment reference in ticket |
| Rollback plan | Documented rollback procedure in ticket | No rollback procedure documented |
Secrets hygiene (CC6.7). API keys, database credentials, and tokens stored in .env files, config files, or version control are a direct SOC 2 finding. Auditors check by reviewing your secrets management policy and then asking for evidence of implementation, which means configuration exports showing that your secrets management tool (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault) is in active use for production credentials. A policy that says “we use a secrets manager” without configuration evidence is treated as an unverified claim.
Encryption requirements are specific. AES-256 for data at rest is the standard. TLS 1.2 minimum for data in transit, with TLS 1.3 increasingly expected by auditors. Key rotation schedules, commonly 90 days, must be documented and verifiable through key management logs.
The 10 Most Common Audit Findings
These are the control failures that appear most frequently in qualified SOC 2 opinions, ordered by recurrence:
---> -> Access review gaps: Quarterly reviews happened, but no documented evidence exists. Policy says reviews occur; no screenshots, exports, or approval records prove they did. -> Incomplete offboarding: Former employees retain access to GitHub, cloud consoles, or SaaS tools after their HR termination date. Auditors sample terminations and verify timestamps. -> MFA coverage gaps: MFA enforced on the cloud provider but not on GitHub, CI/CD platforms, or production databases. Every privileged path to production requires MFA. -> Change management retroactivity: Deployment timestamps in CI/CD logs predate change ticket creation timestamps. Auditors compare both automatically. -> Log retention mismatches: CloudWatch or equivalent logs set to 30-day retention in systems subject to a 6-month or 12-month observation period. -> Secrets in code or config: API keys or database credentials in .env files, Kubernetes secrets without encryption at rest, or hardcoded values in version control. -> Untested incident response: An incident response plan exists as documentation, but has no evidence of a tabletop exercise or actual incident during the observation period. -> Vendor risk gaps: Incomplete inventory of third-party vendors with access to customer data, outdated security assessments, or no documented process for reviewing vendor SOC 2 reports. -> Policy over-promising: Security policies written aspirationally, stating controls as facts without verifiable implementation evidence. Auditors require proof, not statements. -> Backup restoration untested: Backup jobs complete successfully, but no documented restoration test exists. The control requires evidence of successful restoration, not just backup completion.
Figure: The three root causes behind qualified SOC 2 audit opinions—missing evidence, operational gaps, and unverified policies
--->Building Evidence Workflows That Survive Sampling
The pattern across all ten common findings is the same: the control runs, but it leaves no verifiable record. A quarterly access review that happens in a spreadsheet and gets deleted is not a control. An incident response tabletop exercise that produces no written debrief is not a control. Auditors can only assess what they can see.
Building audit-ready evidence means treating every control execution as a record-keeping event. Access reviews must export from IAM to a dated file stored in a location auditors can access. Offboarding tickets must include timestamps and account disablement confirmation. Change tickets must be created before deployments and linked to deployment logs.
| Control Area | Evidence Format | Retention Requirement | Sampling Risk |
|---|---|---|---|
| Access reviews | IAM export, approval email or ticket | Full observation period | 4 samples (one per quarter) |
| Offboarding | HR ticket + account disablement screenshot | Full observation period | 100% if fewer than 25 terminations |
| Change management | Change ticket + deployment log with matching timestamps | Full observation period | 25 samples minimum |
| Incident response | Tabletop debrief or incident postmortem | Full observation period | 1-2 per period expected |
| Log retention | Retention policy config + log export from earliest date | 12 months minimum | Auditors check oldest log date |
| Vendor assessments | Vendor SOC 2 report + internal review record | Annual | All in-scope vendors |
Compliance automation platforms (Vanta, Drata, Secureframe) reduce this burden by integrating with AWS, GitHub, Okta, and HR systems to collect evidence continuously. Teams using these platforms report roughly 50% shorter audit timelines and up to 80% reduction in ongoing maintenance effort. The tradeoff is integration maintenance: the platform is only as reliable as the integrations feeding it.
Before you build a control, define the evidence the control will produce. Not after. If a control cannot produce a verifiable, timestamped record, it cannot survive audit sampling. Start there.
