What is the difference between a policy and a procedure for SOC 2?
March 6, 20262 min readSOC 2 Policies and Documentation
Policy vs. Procedure
| Aspect | Policy | Procedure |
|---|---|---|
| Purpose | States the rule | Explains how to follow it |
| Audience | Everyone in the company | People performing the task |
| Level of detail | High-level principles | Step-by-step instructions |
| Example | "All code changes require peer review" | "1. Create PR, 2. Assign reviewer, 3. Address feedback, 4. Get approval, 5. Merge" |
| Frequency of change | Rarely (annual review) | Often (as processes evolve) |
Why Auditors Need Both
Policies alone tell auditors what you intend to do. Procedures prove it's repeatable. If your policy says "incidents are investigated within 24 hours" but you have no documented procedure for how an engineer triages an alert, the auditor may question whether the control is consistently followed.
That said, not every policy needs a detailed procedure. Focus on areas where auditors will test operating effectiveness:
Where You Need Detailed Procedures
- Incident response. How does an engineer escalate an alert? Who gets notified? What gets documented?
- Change management. How does a code change go from PR to production? What approvals are needed?
- Access provisioning and revocation. How does a new employee get system access? How is access removed when someone leaves?
- User access reviews. How often do you review who has access? What's the process?
Where Policies Alone Are Sufficient
- Data classification
- Acceptable use
- Vendor management
- Security awareness training requirements
Keep It Simple
Startups don't need a 50-page procedure manual. A clear, one-page procedure for each critical process is enough. If your team can follow the steps and the auditor can verify them, you've met the bar.