Why do SOC 2 policies need to match your actual systems?
How Auditors Test Controls
SOC 2 auditing follows a straightforward process:
- Read your policies to understand what controls you claim to have
- Examine your systems to see what controls actually exist
- Compare the two
If they match, the control passes. If they don't, it's a finding — also called an exception or deviation.
What Mismatches Look Like
| Policy Claims | Reality | Audit Result |
|---|---|---|
| "Two reviewer approvals required for all code changes" | GitHub branch protection requires 1 reviewer | Exception — policy is stricter than implementation |
| "MFA enforced for all employees" | 3 employees still use password-only | Exception — control not operating effectively |
| "Quarterly access reviews documented" | Last review was 7 months ago | Exception — control not operating consistently |
| "Automated vulnerability scanning runs weekly" | Dependabot checks on push but no weekly schedule | Exception — policy doesn't match actual cadence |
Why This Happens to Startups
Startups move fast. The authentication provider changes, the deployment pipeline gets updated, team size doubles — but the policies written three months ago still describe the old setup. Or worse, the policies were copied from templates and never matched reality in the first place.
Two Ways to Fix It
Fix the systems: If your policy says "two approvals required," update your GitHub branch protection to require two approvals.
Fix the policy: If one approval is what your team actually does (and it's acceptable to the auditor), update the policy to say "one approval required."
Either direction works. What doesn't work is a gap between the two.
Prevention
The best approach is writing policies from your systems rather than writing policies and trying to configure your systems to match. Tools like Screenata read your codebase and generate policies that describe your actual setup — eliminating the gap before the auditor arrives.