The SOC 2 Readiness Gaps We See Most Often (and How to Close Them)

The gaps are predictable, which is good news

After enough SOC 2 readiness assessments, you stop being surprised. The Trust Services Criteria are broad, but the places where organizations fall short are remarkably consistent. The same six or seven gaps account for the bulk of findings, whether the company is a ten-person startup chasing its first enterprise deal or a scale-up tightening up before a Type 2 observation window.

That predictability works in your favour. If the failures are common, they are also well understood, and closing them is mostly a matter of sequencing the work correctly rather than discovering problems the week before fieldwork. This piece walks through the gaps we flag most often, why each one happens, and what closing it looks like in practice.

Gap 1: Policies that exist on paper but not in practice

The single most common finding is a mismatch between what your policies say and what your team actually does. Someone downloaded a template pack, filled in the company name, and filed it away. The access control policy mandates quarterly user reviews that no one has ever performed. The incident response policy names a team that does not exist. An auditor tests whether a control operates, not whether a document describes it, and a policy nobody follows can be worse than no policy at all, because it documents a commitment you are visibly missing.

Closing this gap means treating policies as descriptions of real behaviour. Write down what you genuinely do, commit to a cadence you can sustain, and run the process at least once before the audit period so there is evidence the control is live.

• Rewrite templated policies to match your real workflows, not aspirational ones.
• Strip out commitments you cannot meet on the stated cadence, such as monthly reviews you will only do quarterly.
• Run each recurring control once during the observation window so a real artifact exists.
• Assign a named owner to every policy so someone is accountable for keeping it current.

Gap 2: Access management that drifted

Access control is where most companies leak findings. Former contractors still have active accounts. Engineers carry production access they needed once for a migration and never lost. There is no documented process for granting, reviewing, or revoking access, so provisioning happens over chat and deprovisioning happens whenever someone remembers. Multi-factor authentication is enabled for most tools but not all, and no one can prove which.

These are not exotic problems, and they are not hard to fix. They require turning ad hoc habits into a repeatable process with a paper trail. The auditor wants to see that access is granted deliberately, reviewed periodically, and removed promptly when someone leaves.

• Run a full access review across every system that touches customer data, and remove what is stale.
• Tie deprovisioning to your offboarding checklist so departures trigger account removal the same day.
• Enforce multi-factor authentication everywhere it is available, and document any tool where it genuinely is not.
• Schedule recurring access reviews, keeping a record of who reviewed what and when.

Gap 3: No evidence, or evidence nobody can find

SOC 2 is, at its core, an evidence exercise. You can be doing everything right and still struggle through an audit because you cannot produce proof on demand. We routinely meet teams who follow good practices but have no screenshots, no exported logs, no ticket history, and no central place to keep any of it. When the auditor requests evidence for a control over the observation period, the scramble begins.

The fix is to decide, control by control, what artifact proves it works and where that artifact lives, before the audit window starts. For a Type 2 report this matters even more, because you need evidence spread across the entire period, not a single snapshot captured the day before fieldwork. Our companion answer on the documents and evidence you need for a SOC 2 audit lays out the typical request list.

• Map each in-scope control to the specific artifact that demonstrates it, such as a config screenshot, an access review export, or a ticket.
• Centralize evidence in one repository so collection is not a treasure hunt.
• Capture evidence on the control's natural cadence throughout the period, not all at once at the end.
• Keep timestamps and approver names intact, since auditors care that the control ran when it was supposed to.

Gap 4: Vendor and subprocessor blind spots

Your security posture includes the vendors you rely on, and this catches a lot of fast-growing companies off guard. There is no inventory of the third parties handling customer data, no record of having reviewed their security, and no contractual language covering data protection. SOC 2 expects you to manage vendor risk, which means knowing who your subprocessors are and having done diligence on the critical ones.

This does not mean auditing every SaaS subscription. It means maintaining a living inventory, reviewing the vendors that touch sensitive data, and keeping their security reports or attestations on file.

• Build a vendor inventory that flags which third parties access or store customer data.
• Collect SOC 2 reports, ISO 27001 certificates, or completed security questionnaires from your critical vendors.
• Confirm your contracts include data protection and breach notification terms.
• Re-review high-risk vendors on a set cadence rather than only at onboarding.

Gap 5: Risk assessment treated as a checkbox

A formal, documented risk assessment underpins much of SOC 2, yet it is one of the most frequently missing or hollow artifacts we encounter. Either there is no risk assessment at all, or there is a one-time spreadsheet from many months ago that no one has revisited. Auditors look for evidence that you identify risks to your systems and data, evaluate them, and decide how to respond on a recurring basis.

The exercise has real value beyond the audit. A genuine risk assessment is how you decide which controls matter most for your business, so it is worth doing properly rather than reverse-engineering one to satisfy a requirement. Most organizations refresh it at least annually, and after any material change to the business or its systems.

• Document your risks, their likelihood and impact, and the controls that address each one.
• Record your treatment decisions, including risks you knowingly accept.
• Refresh the assessment on a defined schedule and after major changes, such as a new product line or cloud migration.
• Connect identified risks back to the controls in your SOC 2 scope so the two stay aligned.

Gap 6: An incident response plan that has never been tested

Many teams have an incident response document, but far fewer have ever exercised it. The plan names roles that have since changed hands, references contacts who have left, and has never been walked through by the people who would actually run it during an event. SOC 2 wants assurance that you can detect, respond to, and recover from a security incident, and an untested plan offers thin assurance.

Closing this gap is inexpensive. A short tabletop exercise, where the team talks through a realistic scenario, surfaces the gaps quickly, gives you an artifact showing the plan was tested, and means the first time you use it is not during a real breach.

• Update the plan so roles, escalation paths, and contact details are current.
• Run a tabletop exercise against a plausible scenario and document what you learned.
• Define how incidents are logged and tracked so there is a record if one occurs.
• Confirm the breach notification obligations that apply to your jurisdictions and customers, which vary by where you and your data subjects are.

Gap 7: Starting too late to earn a clean Type 2

The last gap is about timing rather than a specific control. A Type 2 report covers how your controls operated over a period, commonly three to twelve months, so controls put in place a week before fieldwork cannot produce a full period of evidence. We regularly meet teams under deal pressure who want a Type 2 next month, when the honest answer is that the observation window has not yet begun.

The way to avoid this is to run a readiness assessment early, remediate the gaps, and then start the clock with confidence that controls are genuinely operating. Many companies bridge the wait with a Type 1 report, which attests to the design of controls at a point in time, while their Type 2 window accrues. Building that runway in is the difference between a clean report and a long list of exceptions.

Close the gaps before the clock starts

None of these gaps is difficult in isolation. What trips companies up is discovering all of them at once, late, with a customer deadline looming. A structured readiness assessment turns that scramble into a plan: it surfaces the gaps while you still have time to close them, sequences the remediation sensibly, and gives you a realistic timeline to a clean report.

If you are weighing whether you are ready to start, or unsure how long the path really is, that is exactly the conversation our team has every week. Map your gaps first, fix them deliberately, and let the audit confirm what you have already built rather than expose what you have not.

Related reading

• What are the most common gaps in a SOC 2 readiness assessment
• What documents and evidence do you need for a SOC 2 audit
• SOC 2 type 1 vs type 2
• How to prepare for a security questionnaire