Most failed SOC 2 projects don’t fail during the audit. They fail three months earlier, when someone signs an audit engagement letter without knowing what the company would actually be tested against.
A SOC 2 gap analysis is how you avoid that. Done properly, it tells you exactly which controls you have, which ones you only think you have, and which ones exist on paper but produce no evidence an auditor can use. Done badly, it becomes a spreadsheet of 150 green checkmarks that collapses the first time a CPA firm asks for a screenshot with a timestamp on it.
This guide walks through the full process: scoping, control mapping, evidence testing, gap classification, and remediation planning. It also covers the gaps that show up in nearly every first assessment, because after enough of these, the failure patterns get predictable.
What Is a SOC 2 Gap Analysis?
A SOC 2 gap analysis is a structured comparison between your current control environment and the Trust Services Criteria (TSC) your report will cover. The output is a prioritized list of deficiencies, each with an owner, a remediation action, and an estimated effort.
It is not the audit. No opinion is issued, no CPA firm signs anything, and nothing you find becomes part of a public record. That is precisely why it’s valuable: it’s the only phase where discovering a problem costs you nothing but time.
Gap Analysis vs. Readiness Assessment vs. Type I
These three get used interchangeably, and the sloppiness causes real budget problems. They are different things.
| Gap Analysis | Readiness Assessment | SOC 2 Type I | |
|---|---|---|---|
| Purpose | Identify what’s missing | Confirm you’re ready to be audited | Attest that controls are suitably designed |
| Performed by | Internal team or consultant | Consultant, sometimes the audit firm | Licensed CPA firm only |
| Timing | Start of the program | End of remediation | After remediation, point in time |
| Output | Gap register + remediation plan | Go / no-go recommendation | Formal report with auditor opinion |
| Cost | Low to moderate | Moderate | Full audit fee |
A gap analysis happens at the beginning. A readiness assessment happens at the end, as a dress rehearsal. Some organizations run both; smaller teams often compress them into a single exercise, which is fine as long as you’re honest about the fact that you’re doing it.
When You Should Run One
Run a gap analysis before you sign an audit engagement, not after. Specific triggers:
- A prospect or customer has made SOC 2 a condition of closing
- You’re moving upmarket and expect security questionnaires to start arriving
- You’ve added a new product, region, or major subprocessor since your last report
- Your last audit produced exceptions and you want to know why before the next cycle
- You’re switching audit firms and want a clean baseline
One anti-pattern worth naming: running a gap analysis after you’ve already committed to an observation window start date. At that point you’re not analyzing gaps, you’re documenting them for your auditor to find.
Who Should Perform It
Three options, each with a real tradeoff.
Internal team. Cheapest, and your engineers know the system better than any outsider will. The risk is that people who built a control are poorly positioned to judge whether it’s adequate. If you go internal, have someone who does not own the control do the assessment.
Independent consultant or vCISO. Brings pattern recognition across many audits. Costs money, but usually saves more than it costs by preventing scope errors.
Your audit firm. Be careful here. Under AICPA independence rules, the CPA firm issuing your SOC 2 opinion cannot design or implement the controls it will later audit. Many firms offer a limited “readiness” service that stays on the right side of that line, but if a firm offers to build your control set and audit it, that’s a red flag about the value of the resulting report.
Step 1: Lock the Scope Before Anything Else
Scope errors are the most expensive mistakes in SOC 2 because they’re discovered late and fixed slowly. Settle five things before you look at a single control.
Which Trust Services Categories? Security (the Common Criteria) is mandatory in every SOC 2. The other four are optional:
- Availability — include if you have uptime SLAs
- Confidentiality — include if customers send you data with contractual handling restrictions
- Processing Integrity — include if you process transactions where accuracy is the product (payments, payroll, analytics pipelines)
- Privacy — include only if you’re handling personal information and have committed to a privacy notice; this category is significantly heavier than teams expect
Default advice: start with Security alone, add Availability and Confidentiality if customers are explicitly asking. Adding categories later is easier than dropping them, since dropping a category between reports invites awkward questions.
What is the system boundary? Name the specific product, environments, infrastructure, and supporting business processes in scope. Corporate IT is usually in scope for access and HR controls. Your marketing website usually is not. Write the boundary down as a paragraph you’d be comfortable publishing, because a version of it will appear in Section III of the report.
Which subservice organizations? Decide between the carve-out method (you exclude the subservice provider’s controls and describe the Complementary Subservice Organization Controls you rely on) and the inclusive method (their controls appear in your report, which requires their cooperation). Carve-out is standard for AWS, GCP, and Azure.
Type I or Type II? Type I tests design at a point in time. Type II tests operating effectiveness across a window, typically three to twelve months. Most customers asking for SOC 2 mean Type II. A Type I is useful mainly as a bridge to show progress while a Type II window runs.
What’s the observation window? This is a scoping decision, not an afterthought. A three-month first window is common and defensible. Choose it after remediation, not before.
Step 2: Build Your Control Set and Map It to the Criteria
The 2017 Trust Services Criteria (with points of focus revised in 2022) organize Common Criteria into nine series:
| Series | Focus | Typical control count |
|---|---|---|
| CC1 | Control environment, governance, HR | 6–10 |
| CC2 | Communication and information | 4–8 |
| CC3 | Risk assessment | 4–8 |
| CC4 | Monitoring activities | 3–6 |
| CC5 | Control activities | 3–6 |
| CC6 | Logical and physical access | 20–35 |
| CC7 | System operations, incident response | 12–20 |
| CC8 | Change management | 5–10 |
| CC9 | Risk mitigation, vendor management | 4–8 |
A first-time Security-only scope typically lands somewhere between 60 and 120 controls. If you’re looking at 300, someone has confused controls with tasks.
Two things to get right here:
Points of focus are not requirements. The AICPA includes points of focus to illustrate what a criterion might look like in practice. Auditors do not test them one by one, and you are not obligated to implement each one. Vendors sometimes present them as a mandatory checklist. They aren’t.
Map controls to criteria, not criteria to controls. Start with what you actually do, then ask which criterion each activity satisfies. Working the other direction produces controls invented to fill boxes, which nobody performs, which become exceptions.
Step 3: Inventory What Exists Today
For every control, collect four things:
- The policy or documented expectation — does a written statement of intent exist, and has it been approved?
- The implementation — what system or human activity actually performs the control?
- The evidence source — where does proof live, and can it be exported?
- The owner — a named person, not a team, not “Engineering”
Item four is the one teams skip, and it’s the one that predicts failure. A control with no named owner will not be performed consistently over a twelve-month window.
Where to pull evidence from in practice: your IdP (Okta, Entra ID, Google Workspace), cloud provider consoles and config management, ticketing and version control (Jira, Linear, GitHub, GitLab), HRIS for onboarding and offboarding, endpoint management, log aggregation and alerting, vulnerability scanners, and the vendor register.
Step 4: Test a Sample. Do Not Trust the Policy.
This is the step that separates a real gap analysis from a self-assessment questionnaire.
For every control, pull actual evidence for at least one or two instances and inspect it as an auditor would. Ask:
- Is the population complete? If a control covers all production changes, can you demonstrate that your list of changes is complete? Auditors will ask how the population was generated, and “I exported it from Jira” is only acceptable if the query parameters are visible and reproducible.
- Is it dated? Undated screenshots are worthless. Evidence needs to be attributable to a point inside the observation window.
- Does it show the control operating, or just the tool existing? A screenshot of your SIEM dashboard proves you bought a SIEM. A ticket showing an alert triaged, investigated, and closed proves the control operates.
- Would this convince someone who doesn’t trust you? That’s the actual standard.
Score each control as: Implemented and evidenced, Implemented but not evidenced, Partially implemented, or Not implemented.
The second category is the one that surprises people. A large share of first-round gaps are controls that genuinely work but leave no artifact behind.
Step 5: Classify Design Gaps vs. Operating Effectiveness Gaps
This distinction drives your entire remediation timeline, and most gap analyses ignore it.
A design gap means the control doesn’t exist or wouldn’t achieve the criterion even if performed perfectly. Example: no formal access review process defined anywhere. Remediation is a build project. You can fix it in weeks.
An operating effectiveness gap means the control is well designed but wasn’t performed consistently. Example: quarterly access reviews are documented and assigned, but Q2’s was never completed. Remediation requires time, because you cannot retroactively create a history of consistent operation.
That asymmetry matters enormously. Design gaps affect your remediation budget. Operating effectiveness gaps affect your report date. A control performed quarterly needs at least one full cycle inside the observation window before an auditor can test it, which means a missed quarterly control can push your report out by months.
Practical implication: identify every periodic control early (access reviews, risk assessments, vendor reviews, DR tests, security awareness training, policy reviews) and get the first cycle running before your window opens.
Step 6: Risk-Rank and Build the Remediation Plan
Not every gap deserves equal urgency. Rank on two axes: likelihood of causing an audit exception, and effort to remediate.
Critical — will definitely produce a qualified opinion or exception. Missing MFA on production access, no formal change approval, terminated users retaining access. Fix immediately.
High — likely to draw a finding. Incomplete vendor register, untested incident response plan, backups never restore-tested.
Medium — creates friction and evidence burden. Manual processes with no reliable artifact trail, inconsistent ticket hygiene.
Low — polish. Policy formatting, document version control, terminology alignment.
For each gap, your remediation register should carry: gap ID, mapped criterion, description, classification (design or operating), risk rank, remediation action, owner, target date, and evidence that will prove closure. That last column is what turns a plan into something auditable.
Step 7: Set the Observation Window
Only after remediation is substantially complete. Two conditions before you start the clock:
- Every control has been performed at least once and produced usable evidence
- Every periodic control has a scheduled first occurrence inside the window
Starting the window while critical controls are still being built guarantees exceptions in your first report.
The Gaps That Show Up in Almost Every First Assessment
After enough of these engagements, the same findings recur. Check these before you check anything else.
Access reviews that have never actually happened. The policy says quarterly. The evidence says never. This is the single most common finding in first-time SOC 2 programs.
Offboarding with no proof. Access was revoked, probably within the hour, but there’s no ticket, no timestamp, no checklist. The control works and fails simultaneously.
A risk assessment performed once. CC3 expects a recurring, documented process with identified risks, evaluated likelihood and impact, and treatment decisions. A one-time slide deck from two years ago doesn’t satisfy it.
Vendor management as a spreadsheet nobody opens. CC9 wants evidence of criticality assessment, due diligence at onboarding, and periodic review. Most teams have a list of vendors and nothing else.
Emergency change process undefined. Normal changes go through PRs and approvals. Then production breaks at 2 a.m., someone pushes a hotfix, and there’s no defined path for retroactive review. Auditors always sample the exceptions.
Backups that have never been restored. Configured backups are not tested backups. Availability scope makes this mandatory; even under Security-only scope it commonly surfaces.
An incident response plan that’s never been exercised. A document with no tabletop exercise, no post-incident reviews, and no evidence anyone has read it.
Alerts nobody acts on. Monitoring is configured, alerts fire into a channel, and no one dispositions them. CC7 wants evidence of response, not just detection.
No governance evidence for CC1. Small companies struggle here because the oversight is real but informal. Board meetings happen; minutes don’t. Security responsibility is understood; it’s not documented in a job description or org chart.
Policies written but never distributed. Approved, stored in a drive folder, never acknowledged by employees. CC2 wants evidence that policies were communicated and acknowledged.
Timeline and Cost Expectations
Ranges vary by company size, existing maturity, and scope, but as a planning baseline:
Gap analysis itself: two to four weeks for a small SaaS company under Security-only scope. Longer if multiple products or business units are in scope.
Remediation: typically one to four months for a first-time program with no prior compliance work. Companies with mature engineering practices often move faster on technical controls and slower on governance documentation.
Observation window: three months minimum for a first Type II. Six to twelve months for subsequent cycles.
Total, from kickoff to a Type II report in hand: six to nine months is realistic. Anyone promising a Type II in eight weeks is either selling you a Type I or planning to explain a lot of exceptions.
On cost: a consultant-led gap analysis commonly runs in the low five figures. Compliance automation platforms reduce evidence collection labor substantially but do not replace the analysis, and configuring one badly produces confident dashboards over a broken control set. Get pricing from multiple providers, since the market varies widely.
What a Good Gap Analysis Deliverable Contains
If you’re commissioning this work, hold the deliverable to this bar:
- Scope statement — categories, system boundary, subservice organizations, intended report type
- Control matrix — every control mapped to specific TSC criteria with current status
- Gap register — each gap classified as design or operating effectiveness, risk-ranked, with owner and target date
- Evidence inventory — where each artifact lives and how it gets pulled
- Remediation roadmap — sequenced, with dependencies and a recommended window start date
- Executive summary — readable by a CEO in five minutes
If what you get back is a color-coded spreadsheet with no owners and no evidence column, you paid for a checklist, not an analysis.
Common Mistakes to Avoid
Over-scoping on the first report. Adding Privacy or Processing Integrity because they sound thorough. Each additional category adds controls, evidence, and audit hours. Add what customers ask for.
Treating the gap analysis as a documentation exercise. Writing policies to close gaps without implementing the underlying activity produces the worst outcome: a control that exists on paper, gets tested, and fails.
Assigning controls to teams instead of people. “Engineering owns this” means nobody owns it.
Ignoring Complementary User Entity Controls. If your report will include CUECs, they need to be identified during scoping, because they change what your customers are responsible for.
Confusing tool coverage with control coverage. Buying an MDM does not close an endpoint security gap. Deploying it to every device, monitoring compliance, and remediating drift does.
Starting the observation window to hit a sales deadline. The deadline doesn’t move the audit. It just moves the exceptions into the report.
Frequently Asked Questions
How long does a SOC 2 gap analysis take? Two to four weeks for a small to mid-sized SaaS company with a Security-only scope. Complex environments or multi-category scopes can extend this to six weeks or more.
Can we do a SOC 2 gap analysis ourselves? Yes. It requires someone who understands the Trust Services Criteria well enough to judge evidence sufficiency, and enough independence to be honest about controls they don’t own. Internal analyses fail most often from optimism, not lack of knowledge.
Is a gap analysis required for SOC 2? No. Nothing in the AICPA standards requires one. It’s a practical step, not a compliance obligation. Skipping it is legal and usually expensive.
Can our auditor perform the gap analysis? Sometimes, within limits. AICPA independence rules prevent the attesting firm from designing or implementing the controls it will audit. Many firms offer a restricted readiness review that stays compliant, but a firm offering to build and then audit your control set should be questioned.
What’s the difference between a gap analysis and a readiness assessment? A gap analysis identifies what’s missing at the start of the program. A readiness assessment verifies you’re prepared for the audit at the end of remediation. Some engagements combine them.
Should we do a Type I first? Only if you need something to show customers while a Type II window runs, or if your control environment is new enough that a design-only checkpoint has value. A Type I is a milestone, not a substitute.
