SOC 2 Compliance Checklist: Everything You Need Before Your Audit

Walking into a SOC 2 audit without a checklist is like deploying to production without a runbook. You'll probably get through it, but you'll miss things you could have caught in advance — and those gaps delay your report by weeks.

This is the checklist we wish we'd had. It covers the 6 CC controls, the 7 required policies, the evidence your auditor will look for, and the pre-audit tasks that most first-timers miss.

---

Part 1: Access Controls (CC6.1 – CC6.3)

CC6.1 — Logical Access

What auditors look for: Evidence that only authorised users have access to your production systems, and that you review access regularly.

Pre-audit checklist:

• [ ] Export a user list from every system that touches production: GitHub, AWS, your cloud database, your identity provider (Okta, Google Workspace, etc.), Jira, Slack
• [ ] Cross-reference against your HR system / employee list. Every account belongs to a current employee or an explicitly approved service account
• [ ] Document your onboarding process: how does a new engineer get access to GitHub and AWS?
• [ ] Document your offboarding process: how is access revoked when someone leaves? Is it automated?
• [ ] Run an access review: have a manager confirm that every team member's access level is still appropriate
• [ ] No shared credentials or shared accounts (each person has their own login)
• [ ] Service accounts are documented, have owners, and rotate their credentials

Evidence examples:

• IAM user list from AWS (screenshot or export)
• GitHub org member list
• Okta user export
• Offboarding checklist or process documentation
• Access review sign-off (even a signed email works)

---

CC6.2 — Multi-Factor Authentication

What auditors look for: MFA enforced at the organization level, not just recommended.

Pre-audit checklist:

• [ ] GitHub org MFA enforcement enabled (Settings → Authentication security → Require two-factor authentication)
• [ ] AWS root account MFA enabled (hardware or virtual)
• [ ] All IAM users have MFA enabled (or you're using SSO which requires MFA)
• [ ] Your identity provider (Okta, Google) has MFA required for all users
• [ ] No MFA exceptions without a documented risk acceptance
• [ ] Phishing-resistant MFA (FIDO2/hardware keys) for privileged accounts — required for stricter auditors

Evidence examples:

• GitHub org MFA settings screenshot
• AWS root MFA configuration screenshot
• Okta MFA policy configuration

---

CC6.3 — Role-Based Access Control

What auditors look for: Access granted by role, not individually. Principle of least privilege.

Pre-audit checklist:

• [ ] GitHub teams configured with appropriate permissions (engineers in an engineers team, not individual repo access)
• [ ] AWS IAM roles used instead of IAM users where possible
• [ ] Production AWS access restricted to a small group with documented justification
• [ ] No wildcard permissions (*:*) unless explicitly justified
• [ ] Privileged access (admin, production root) has additional controls (MFA, approval workflow)
• [ ] Access request process documented: who approves new access?

Evidence examples:

• AWS IAM roles and policies
• GitHub teams and repository access matrix
• Access request approval workflow

---

Part 2: System Monitoring (CC7.1)

What auditors look for: You log what happens in your production environment and review those logs.

Pre-audit checklist:

• [ ] AWS CloudTrail enabled in all regions — not just your primary region. Auditors check this.
• [ ] CloudTrail logs delivered to an S3 bucket with versioning enabled
• [ ] S3 bucket has Object Lock or MFA Delete — logs must be immutable
• [ ] CloudTrail log retention: minimum 1 year, best practice 7 years
• [ ] CloudWatch (or equivalent) alerting on: failed console logins, API key use from unexpected locations, privilege escalation, root account use
• [ ] Log access is restricted: not everyone can delete logs
• [ ] Alerting actually goes somewhere: on-call rotation, PagerDuty, Slack with an owner

Evidence examples:

• AWS CloudTrail configuration screenshot (multi-region enabled)
• S3 bucket policy (versioning + Object Lock)
• CloudWatch alarm configurations
• Sample alert tickets from your on-call system

---

Part 3: Vulnerability Management (CC7.2)

What auditors look for: You know about vulnerabilities in your codebase and have a process for fixing them.

Pre-audit checklist:

• [ ] GitHub Dependabot alerts enabled across all repos
• [ ] Dependabot security updates enabled (auto-PRs for vulnerable dependencies)
• [ ] SLA defined for vulnerability remediation: e.g., Critical = 24 hours, High = 7 days, Medium = 30 days
• [ ] Process for handling vulnerabilities: who is responsible? How are they tracked?
• [ ] Annual penetration test completed (many auditors require this for Type II)
• [ ] Pen test findings tracked to remediation
• [ ] Container image scanning if you use Docker (Trivy, ECR scanning, Snyk)
• [ ] No known Critical or High vulnerabilities left open without documented risk acceptance

Evidence examples:

• Dependabot settings screenshot
• Vulnerability SLA policy document
• Pen test report and remediation tracker
• Open/closed Dependabot alert history

---

Part 4: Change Management (CC8.1)

What auditors look for: Code can't reach production without review.

Pre-audit checklist:

• [ ] Branch protection enabled on all production branches (main, master, release/*)
• [ ] At least one required reviewer on every PR — ideally two for high-risk changes
• [ ] Required status checks: CI must pass before merge
• [ ] No force-push to main, or force-push requires admin override with audit trail
• [ ] Deployment process documented: how does code get from PR merge to production?
• [ ] Emergency change process documented: what happens when you need to hotfix at 2am?
• [ ] Change log / release notes maintained

Evidence examples:

• GitHub branch protection settings screenshot (per repository)
• PR history showing approvals (pull from GitHub API for Type II)
• CI pipeline logs
• Deployment runbook

---

Part 5: Policies (Required Documents)

SOC 2 requires seven written policies. These must be approved by management, communicated to employees, and reviewed annually.

• [ ] Information Security Policy — the master policy that governs everything else
• [ ] Access Control Policy — who gets access to what and how
• [ ] Incident Response Plan — how you detect, contain, and recover from security incidents
• [ ] Business Continuity / Disaster Recovery Plan — how you recover from a major outage
• [ ] Encryption Policy — data-at-rest and data-in-transit encryption requirements
• [ ] Vendor Risk Management Policy — how you assess and monitor third-party vendors
• [ ] Acceptable Use Policy — rules for using company systems

For each policy, confirm:

• [ ] Management sign-off (with date)
• [ ] Distributed to all employees (email, Notion, Confluence — doesn't matter, just provable)
• [ ] Annual review scheduled
• [ ] Version history maintained

---

Part 6: People Controls

The things auditors check that most first-timers forget:

• [ ] Background checks completed for all new hires (or documented reason why not)
• [ ] Security awareness training completed by all employees annually — screenshot or export of completion records
• [ ] Confidentiality / NDA signed by all employees and contractors
• [ ] Employee handbook references security expectations and acceptable use
• [ ] Code of conduct in place

---

Part 7: Vendor and Third-Party Management

• [ ] Sub-processor list maintained (all vendors who process customer data)
• [ ] Data Processing Agreements (DPAs) signed with all sub-processors
• [ ] Annual security review completed for critical vendors: cloud provider, identity provider, monitoring tools
• [ ] Process for adding new vendors: who approves? What's the security review process?

---

The 5 Things First-Timers Miss

1. CloudTrail in all regions. Enabling it in us-east-1 only and thinking you're done is the most common mistake. Auditors check every region.

2. Log immutability. Turning on CloudTrail isn't enough. Your auditor will ask if logs could be tampered with. Enable S3 Object Lock or MFA Delete.

3. Offboarding evidence. "Yes, we revoke access when people leave" isn't enough. Your auditor wants tickets, emails, or system records showing access was actually revoked — for everyone who left during the observation period.

4. Pen test timing. Many companies book their pen test the week before the audit. Bad move — you need time to remediate findings. Budget for the pen test 6–8 weeks before your target audit end date.

5. Policy distribution evidence. Writing great policies is half the work. You also need to prove employees received and acknowledged them. A signed policy acknowledgement form (even a Google Form) is fine.

---

Ready to See Where You Stand?

Don't walk into your audit guessing. Circinova connects to your GitHub and AWS in minutes and gives you a live readiness score across all 6 CC controls — with plain-English explanations of every gap and exactly what evidence your auditor needs.

Start your free SOC 2 readiness scan →

No credit card required. No sales call.