7 Common SOC 2 Readiness Gaps
Most companies do not fail a SOC 2 audit. They arrive unprepared, collect a list of exceptions, and spend an extra quarter remediating findings they could have closed months earlier with a fraction of the effort. The audit did not create the gaps. It simply found them.
The encouraging part is that these gaps remain entirely predictable. Auditors sample the same control areas in nearly every engagement, and the same handful of weaknesses appear again and again. Teams do not fail because they are careless; they fail because these controls require operational discipline over months, rather than a document written the week before fieldwork begins.
At Foxcove, we deliver audit-ready IT compliance services for growing businesses by running readiness assessments for startups and scaling companies preparing for their first SOC 2 report or renewing an existing one. This guide covers the seven gaps we find most consistently, why auditors care about each, what evidence they demand, and how long your team realistically needs to close them.
First, Understand What a Readiness Gap Actually Is
A readiness gap represents any place where a control does not exist, does not operate consistently, or lacks evidence.
That third category catches most teams by surprise. You may genuinely review access every quarter, but if nobody exported the review, recorded the approver, and dated it, the auditor considers the control absent. To an auditor, unevidenced is indistinguishable from nonexistent.
This distinction matters heavily under a Type II report. A Type I evaluates whether you designed controls correctly at a single point in time. A Type II evaluates whether you operated them effectively across an observation window of several months, and auditors sample throughout that window. You cannot repair a gap in the third month during the ninth month.
The AICPA's Trust Services Criteria define exactly what auditors evaluate. Reading them before your readiness assessment tells you precisely what evidence the auditor will ask you to produce.
Gap 1: Access Reviews That Teams Never Perform or Record
Auditors spend the bulk of their time evaluating access control, making user access reviews the single most common exception we see.
What auditors expect:
They demand proof that an authorized leader reviewed who holds access to which systems, on a defined schedule, and actively confirmed or revoked each entitlement. They want the review artifact, the reviewer's name, the date, and proof that IT resolved the identified issues.
Why teams miss it:
Teams conduct the review informally. A manager glances at a user list in Slack and approves it. They generate no export, no sign-off, and no record. Six months later, the auditor has nothing to sample. Alternatively, the team performs the review once right before the audit, which fails a Type II observation window that expected a quarterly cadence.
How to close it:
Define the cadence in your policy (quarterly remains the common expectation) and calendar it with a named owner.
Export the entitlement list from each in-scope system at review time and retain it securely.
Record the reviewer, the date, the decisions made, and the specific IT ticket that removed unnecessary access.
Review cloud consoles, source control, CI/CD pipelines, identity providers, and production databases, not just the HR system.
Realistic time to close: Two to four weeks to establish, then ongoing. You cannot backfill missed periods.
Gap 2: Orphaned Accounts After Offboarding
Auditors routinely cross-reference your terminated employee list against active accounts in every in-scope system. Any account that outlives its owner triggers an immediate finding, and it remains one of the hardest exceptions to argue away because the evidence is unambiguous.
The usual cause stems from a manual offboarding process spanning too many systems without a central checklist. IT disables the identity provider promptly, but a contractor's source control account, a shared cloud console login, or a SaaS tool procured by a single department remains active for months.
How to close it:
Maintain a definitive inventory of every system holding company or customer data.
Build a strict offboarding checklist covering all systems, enforcing a required completion window (e.g., 24 hours). If your team struggles to execute this internally, leaning on professional device management and help desk support for startups ensures timely and accurate offboarding.
Route access through your identity provider using single sign-on (SSO) wherever possible, ensuring one revocation locks multiple systems.
Eliminate shared credentials, which make individual revocation impossible by design.
Retain the completed checklist for every departure as your definitive evidence.
Realistic time to close: Three to six weeks, spending most of that time building the system inventory.
Gap 3: Inconsistent Multi-Factor Authentication (MFA)
Nearly every company enables MFA somewhere. Auditors look for it everywhere that matters. Coverage gaps appear in highly consistent places: administrative consoles, VPN access, CI/CD pipelines, service accounts, and legacy applications that predate the SSO rollout.
A single unprotected administrative path undermines the entire control. Auditors treat partial MFA coverage as a finding, not as partial credit.
How to close it:
Inventory every authentication path into production, including automation and break-glass accounts.
Enforce MFA through conditional access policies rather than user-by-user configuration.
Document exactly how service accounts and automation authenticate, since they cannot use MFA and require compensating controls.
Produce a unified coverage report you can hand to an auditor without manual assembly.
Realistic time to close: Two to five weeks, depending heavily on your legacy system count.
Gap 4: Vendor and Third-Party Risk Management
Teams feel least prepared for this gap because it feels like paperwork rather than security. Auditors completely disagree: your vendors process your customers' data, meaning their failures immediately become your incidents.
What auditors expect:
A maintained vendor inventory, a risk classification for each vendor, documented due diligence before onboarding, collected assurance artifacts (like the vendor's own SOC 2 report), and evidence of periodic reassessment. That final item breaks most programs: teams perform the initial review, but skip the annual re-review entirely.
Federal guidance on supply chain and third-party risk from CISA outlines the exact expectations that auditors apply, providing a useful, neutral reference when building your program.
How to close it:
Build the vendor inventory directly from accounting records, not from memory. Finance knows every vendor you pay.
Classify each vendor by data sensitivity and business criticality; reserve deep reviews strictly for the critical tier.
Collect each critical vendor's SOC 2 or ISO 27001 report and record who reviewed it and when.
Set an annual reassessment schedule with a named owner and place it on the calendar.
Add a security review gate to procurement so new vendors enter the program automatically.
Realistic time to close: Four to eight weeks for the first full cycle.
Gap 5: An Incident Response Plan That Has Never Been Tested
Almost every company preparing for SOC 2 maintains an incident response (IR) plan. Far fewer have actually tested one, and auditors explicitly ask for evidence of testing rather than evidence of authorship.
An untested plan fails rapidly in practice. During a real incident, teams discover the escalation contact left the company, nobody holds the authority to officially declare an incident, and the communication plan omits customers entirely.
What auditors expect:
A documented plan defining severity levels, roles, escalation paths, and notification obligations.
Evidence of at least one tabletop exercise or test during the observation window, recording the participants and the date.
Documentation of any real incidents, including timelines, response actions, and post-incident reviews.
Evidence that lessons learned physically changed the plan.
How to close it:
Run a two-hour tabletop exercise against a realistic scenario—a compromised administrator credential or a vendor breach exposing customer data. Record who participated, what decisions surfaced, where the plan failed, and what you changed as a result. That record serves as your evidence. The exercise reliably reveals more gaps than the plan document ever did. NIST's incident handling guidance (SP 800-61) provides the process model most mature programs adopt.
Gap 6: Policy Documentation That Nobody Follows
Policies represent the easiest gap to quickly "fix" and one of the easiest for auditors to catch. Downloaded templates create a specific, painful failure mode: the policy describes sophisticated controls the company does not actually operate.
Auditors test practice against policy. If your policy claims you perform quarterly access reviews, but you actually perform them annually, your own policy generates the exception. Teams frequently act surprised that an aggressive policy harms them more than a modest, accurate one.
What auditors expect:
Policies covering the criteria in scope, formally approved with a recorded approver and date.
Evidence of annual review, even when nothing changed in the text.
Proof that employees received and acknowledged the policies.
Daily practice that flawlessly matches what the policy dictates.
How to close it:
Write policies that describe what you actually do, then improve the practice and update the policy in tandem.
Record formal approval with a named approver and date.
Distribute the documents through a system that captures digital acknowledgment, and embed policy review into onboarding.
Set an annual review calendar with a designated owner.
Realistic time to close: Three to five weeks, plus the ongoing effort of tracking acknowledgments.
Gap 7: Monitoring and Logging With No Evidence of Review
Most teams enable logging. Auditors ask a different question entirely: who looks at it, how often do they look, and what happened when a warning appeared? Alerts that fire into an unattended Slack channel demonstrate collection, not monitoring.
What auditors expect:
A defined logging scope covering authentication, administrative actions, and configuration changes.
Log retention that precisely meets your stated policy period.
Alerting configured for defined, security-relevant events.
Evidence that a human reviewed and triaged alerts, including the ones dismissed as benign.
How to close it:
Route security alerts into a ticketing system rather than a chat channel. Tickets automatically create a review record, capturing who triaged each alert and what they concluded. Tune noisy alerts aggressively; an alert stream nobody can process produces neither security nor audit evidence.
Realistic time to close: Three to six weeks.
Readiness Gap Summary
| # | Gap | Primary Evidence Auditors Request | Time to Close |
|---|---|---|---|
| 1 | Access reviews not performed or recorded | Dated review exports with reviewer sign-off | 2-4 weeks + ongoing |
| 2 | Orphaned accounts after offboarding | Completed offboarding checklists per departure | 3-6 weeks |
| 3 | Inconsistent MFA coverage | Coverage report across all auth paths | 2-5 weeks |
| 4 | Vendor risk management gaps | Vendor inventory, assurance reports, reassessment log | 4-8 weeks |
| 5 | Untested incident response plan | Tabletop exercise record and post-incident reviews | 2-3 weeks |
| 6 | Policy documentation mismatch | Approved policies plus employee acknowledgments | 3-5 weeks |
| 7 | No evidence of log or alert review | Triage tickets showing alerts reviewed by a human | 3-6 weeks |
Closing all seven gaps typically takes eight to twelve weeks of focused effort. Start this process long before your observation window opens, because several of these controls require months of consistent operation to produce the evidence an auditor will sample.
Close the Gaps Before the Auditor Finds Them
Closing these seven gaps requires zero sophisticated security engineering. They simply require someone to own each control, define its cadence, and guarantee the operation leaves a permanent record. That lack of ownership forms the true gap, and it explains why companies with brilliant engineering teams still collect painful audit exceptions.
Foxcove runs SOC 2 readiness assessments and provides fractional CISO leadership for startups and scaling companies across San Francisco, Portland, and the greater Bay Area. We identify your gaps against the criteria in scope, build a prioritized remediation plan with named owners and dates, and manage the auditor relationship so your engineering team stays focused on building the product.
Talk to a Foxcove expert today to schedule a readiness assessment before your observation window officially opens.
Frequently Asked Questions
1. What are the most common SOC 2 readiness gaps?
The seven most common include: missing or unrecorded access reviews, orphaned accounts after offboarding, inconsistent multi-factor authentication coverage, weak vendor and third-party risk management, an untested incident response plan, policy documentation that contradicts practice, and monitoring environments that lack evidence of alert review.
2. How long does it take to close SOC 2 readiness gaps?
Individual gaps typically take two to eight weeks each. Closing all seven commonly requires eight to twelve weeks of focused, parallel effort. Because several controls need months of consistent operation to generate samplable evidence, you must start well before your observation window opens.
3. Why do auditors focus so much on access reviews?
Excessive or stale access serves as the most common path to a real data breach, making access control the area auditors sample most heavily. They demand evidence that a named reviewer examined entitlements on a strict schedule and that IT actually resolved the identified issues.
4. What evidence do auditors want for vendor risk management?
Auditors expect a maintained vendor inventory, a risk classification per vendor, documented due diligence before onboarding, collected assurance artifacts (like the vendor's own SOC 2 report), and evidence of periodic reassessments. Programs usually fail at the annual reassessment stage.
5. Does an incident response plan need to be tested for SOC 2?
Yes. Auditors ask for evidence of testing, not just authorship. Running a tabletop exercise during the observation window and recording the participants, date, findings, and resulting plan changes satisfies the expectation.
