How do I write SOC 2 policies that pass an audit?
What Makes a Policy Pass?
A SOC 2 policy passes when the auditor can read it, look at your systems, and confirm the two match. That's it. The policy doesn't need to be long or complex — it needs to be accurate.
Five Rules for Audit-Ready Policies
1. Name Your Actual Tools
Bad: "The company uses encryption for data at rest." Good: "Customer data is stored in Supabase PostgreSQL with AES-256 encryption at rest enabled by default."
2. Assign Specific Roles
Bad: "Management is responsible for security oversight." Good: "The CTO reviews access control settings quarterly. The engineering lead approves all production deployments."
3. Be Specific About Processes
Bad: "Changes follow an approval workflow." Good: "All code changes require a GitHub pull request with at least one approving review before merge. Branch protection rules enforce this on the main branch."
4. Only Claim What You Actually Do
This is the most important rule. If you write "quarterly access reviews" in your policy but you've never done one, the auditor will find that gap. It's better to set a realistic cadence and follow it.
5. Include Review Dates
Every policy should state when it was last reviewed and by whom. Auditors check that policies are current. A policy last reviewed 18 months ago raises concerns.
The Most Common Failure
| Mistake | Why It Fails | Fix |
|---|---|---|
| Generic language | Auditor can't verify vague claims | Name specific systems |
| Overpromising | Claiming controls you don't have | Write what's true |
| Copy-paste templates | Policies don't match your setup | Customize for your stack |
| Missing responsibilities | No one accountable | Assign names/roles |
Where Screenata Helps
Screenata writes policies by reading your codebase and cloud configuration. The output references your actual tools, roles, and workflows — so the policies match what the auditor will see during testing. No templates to customize, no gaps to fill.