How do I write an access control policy for SOC 2?
March 6, 20262 min readSOC 2 Policies and Documentation
What an Access Control Policy Covers
Access control is one of the most heavily tested areas in a SOC 2 audit. Your policy maps to CC6.1 through CC6.8 and defines how your organization manages who can access what — from cloud infrastructure to your application code to customer data.
Key Sections
| Section | What to Document |
|---|---|
| Access provisioning | How new employees get system access |
| Role-based access | What roles exist and what each can access |
| Least privilege | How you limit access to what's needed |
| MFA requirements | Which systems require multi-factor authentication |
| Access revocation | How access is removed when someone leaves |
| Access reviews | How often you review who has access and why |
| Shared accounts | Your stance on shared credentials (ideally: prohibited) |
Example Policy Statements
- "All employees authenticate via Google Workspace SSO with hardware key MFA required."
- "AWS console access is restricted to the CTO and senior engineers. Access is provisioned through IAM roles with least-privilege policies."
- "When an employee leaves, their Google Workspace account is suspended within 4 hours by the CTO. This automatically revokes SSO access to all connected applications."
- "Access reviews are conducted quarterly. The CTO reviews all active user accounts across Google Workspace, AWS, GitHub, and Supabase."
What Auditors Test
- Provisioning: Pick a recent hire — was access granted according to policy?
- Termination: Pick a recent departure — was access revoked promptly?
- Access reviews: Show evidence of your most recent quarterly review.
- MFA: Verify MFA is enforced (not just available) across critical systems.
- Privilege levels: Confirm that not everyone has admin access.
Common Startup Mistakes
- Everyone is admin. Early-stage startups often give all engineers full admin access. Before your audit, implement role-based access — even simple "admin" vs. "developer" roles help.
- No offboarding process. Document and follow a checklist for removing access when someone leaves.
- No access reviews. Set a quarterly calendar reminder to review active accounts. Export the user list, confirm each person still needs access, and document the review.