The SOC 2 controls that actually move the needle (and the ones that don't)

The SOC 2 controls that actually move the needle

The Trust Services Criteria list 60+ controls. Most readiness vendors will tell you to implement all of them. Most auditors actually only deeply care about 12. Knowing which is which lets you focus the limited engineering attention you have on the work that determines whether you pass.

These are the ones we see auditors actually scrutinize, in order of how often they appear as findings.

The high-stakes 12

1. Logical access — least privilege + revocation on offboarding. The single most common finding category. The auditor will pick a sample of terminated employees and check whether their access was revoked within your stated SLA (usually 24 hours). They'll also pick a sample of current employees and check whether their access matches their role. Spreadsheets of access reviews are evidence; the actual revocations are the control.

2. Quarterly access reviews. Owner of each system (production AWS, production database, GitHub, Okta) reviews who has what access and signs off. If you don't have written evidence of the last four reviews, this is a finding regardless of how good your real access hygiene is.

3. Change management with separation of duties. A code change to production requires a PR, review by someone other than the author, and a CI/CD pipeline log showing the deploy. Direct production database changes need a documented approval. The auditor will sample 10-20 production changes and ask for the PR + reviewer evidence.

4. Vulnerability management. You scan regularly (this is where CyberGrid fits), you have a documented severity → SLA mapping, you remediate within the SLA. Auditors want to see a ticketing system or tracker with closed vulns + dates. A pen test once a year is part of this evidence.

5. Incident response. Documented runbook. Evidence of at least one incident exercise per year. Logs from any real incidents in the audit period, showing the runbook was followed.

6. Vendor management. List of critical third-party vendors (cloud, payment, data processors). For each, evidence you reviewed their SOC 2 or equivalent at onboarding and re-reviewed during the audit period. AWS / GCP / Azure SOC 2 reports go in this binder.

7. Backup + restore tested. You back up production data. You test that you can restore from backup. The auditor will ask for evidence of a restore test in the audit period — a date, who did it, what they restored, did it succeed.

8. Logging + monitoring. Production systems produce logs. Logs are retained for at least the period you commit to in your policy (typically 1 year). Critical events trigger alerts to a real person. Evidence: screenshots of alerts firing, or a sample of investigated alerts.

9. Encryption in transit and at rest. TLS 1.2+ everywhere (the pen test report you submit will prove this). Database encryption at rest (cloud-provider default usually counts). Encryption key management documented.

10. Security awareness training. Every employee completes security training annually. Evidence: completion records from your LMS. Auditors will sample 10-20 employees and ask for the completion certificate.

11. Risk assessment. A document, dated within the audit period, that lists risks to the system, scores them, and identifies mitigating controls. Most companies do this once a year. The actual quality of the analysis matters less than the existence of the document.

12. Confidentiality controls if you store customer data. If "C" is in your scope (most SaaS SOC 2 reports include it), you need a control specifically for customer data classification, retention, and destruction. Evidence of customer data destruction within your stated SLA after contract termination.

The mostly ceremony list

These show up in TSC but rarely produce findings if you have anything reasonable in place. Don't ignore them but don't over-engineer them either.

• Physical security. "We use AWS" satisfies this for most SaaS. Reference AWS SOC 2.
• Code of conduct. A two-page PDF. Done.
• Acceptable use policy. Same.
• Background checks. Documented vendor and a sample of HR records.
• Change advisory board. Most modern SaaS doesn't have one. The PR-and-review process plus the deploy pipeline log satisfies this for auditors who understand modern engineering practice. If you draw an auditor who insists on a formal CAB, request a different one — they're not the right fit for a modern SaaS.

Where the work actually goes

The work breakdown in the typical 90-day readiness:

• 15% — policy library. Twenty-plus policies, all written, all mapped to the criteria. CyberGrid (and similar vendors) provide a starting library you tailor.
• 35% — control implementation. Actually setting up the access reviews, the change management discipline, the vendor binder, the incident runbook.
• 25% — evidence pipeline. GRC platform (Drata, Vanta, Secureframe) connected to AWS, GitHub, Okta, Slack, etc. so evidence flows automatically.
• 15% — risk assessment + DR test + incident exercise. One-time work that produces dated artifacts.
• 10% — security training + access review cycle. Set up the recurring processes.

The 12 controls above absorb maybe 75% of the actual implementation effort. The remaining controls are mostly documentation and mapping work. If you spend 80% of your time on the 12 and 20% on everything else, you'll pass.