Most teams don't fail a SOC 2 audit on exotic controls. They stall on five predictable gaps - and they usually find them a fortnight before the auditor arrives, when there's no time left to fix them cleanly.
A SOC 2 report is an auditor's opinion that the controls you claim to run actually operated over a period of time. That last phrase - over a period of time - is where readiness lives or dies. A control you turned on last week has no evidence trail; a Type II report needs three to twelve months of it. Here are the five gaps we see block reports again and again, and how to close them before they cost you the timeline.
1. Access reviews that never actually happened
Almost every Trust Services Criteria set hinges on access control, and auditors test it hard. The failure pattern is boring: joiners get access quickly, leavers keep it for months, and no one runs a periodic review to catch the drift. When the auditor asks for evidence of your quarterly access review, a screenshot of the current user list is not it - they want the review that was performed, by whom, what was flagged, and what was remediated.
- Fix it early: schedule access reviews on a recurring calendar with a named owner, and keep the signed-off output every cycle.
- Tie de-provisioning to your HR offboarding so it is automatic, not a favour someone remembers to do.
2. Logging you have, monitoring you don't
Collecting logs is not monitoring. SOC 2 expects that security-relevant events are not just stored but reviewed and acted on. Teams often have a SIEM full of data and no evidence that anyone looked at an alert, triaged it, and closed it. That gap turns a control you technically own into a control you can't prove.
If a tree falls in your SIEM and no analyst triages it, the auditor treats the control as not operating.
A 24×7 monitoring function - in-house or an MDR partner - closes this by producing a continuous, timestamped trail of detection and response that maps directly to the criteria.
3. Vendor risk that stops at a spreadsheet
Your report covers your subservice organisations too. Auditors will ask how you assess critical vendors and what you do when one of them has a weakness. A one-time spreadsheet from onboarding is not a program. You need evidence that you review vendor security posture on a schedule and that you actually review their SOC 2 or ISO reports when they arrive.
4. Change management without a paper trail
The control everyone assumes they pass - and frequently doesn't. Auditors sample production changes and ask to see the request, the review/approval, the testing, and the deployment record. If changes go to production from a personal branch with no ticket, there is nothing to sample. The fix is not more process; it's making the process leave evidence automatically - pull-request approvals, CI logs, and ticket references that link back to the deploy.
5. Policies that don't match reality
The fastest way to lengthen an audit is to hand over a beautiful policy set that describes a company you are not. If your incident-response policy promises a 15-minute triage SLA you have never met, the auditor now has a finding. Policies should describe what you genuinely do, and what you do should be evidenced. Where there is a gap, close the operational gap first - then write the policy to match.
The pattern behind all five
Notice the common thread: none of these are about buying a tool. They are about controls that produce evidence continuously rather than controls you scramble to reconstruct. Readiness is mostly the discipline of instrumenting your existing controls so that passing the audit is a by-product of operating normally.
If you're heading toward a first SOC 2 or a renewal and want a blunt readiness assessment - what's genuinely ready, what will block the report, and how long each gap takes to close - that's exactly the kind of scoping call we do.
← Back to Insights