Dana Whitfield found out her company had a SOC 2 problem on a Tuesday afternoon, in a Zoom call with a procurement director who wouldn't stop smiling politely while delivering bad news. Cordant Analytics, the mid-market retail analytics platform where Dana ran security and compliance, had just spent four months courting a logistics conglomerate worth $2.4 million in annual recurring revenue. The deal was verbally done. Then the conglomerate's vendor security team sent over their standard onboarding packet, and line one of the requirements read: "Vendor must provide a current SOC 2 Type II report covering the in-scope system, issued within the last twelve months."
Cordant didn't have one. Cordant had never had one. Dana had eleven weeks before the prospect's internal deadline to either produce a miracle or watch the deal slip to a competitor who already had a report on file. Her CEO's question in the all-hands that followed was blunt: "How far away are we, really?" Dana didn't have an honest answer, because nobody had ever measured the distance. That's the problem a gap analysis exists to solve — not "are we compliant," which is a vague and slightly meaningless question, but "here is our current control state, here is what the criteria require, and here is the itemized, prioritized, costed list of what stands between the two."
This article is about that measurement exercise: the specific, repeatable method for running a SOC 2 gap analysis before you ever talk to an auditor.
Who This Is For and What You'll Walk Away With
This is written for the person who has just been told "we need SOC 2" and has to figure out where to start — a first-time compliance lead, a security engineer wearing a GRC hat, or a founder who can't yet justify a full-time hire. You'll walk away with a concrete method: how to scope the assessment, how to assess each control against the criteria, how to rate maturity honestly, how to build and prioritize a gap register, and how to turn that register into a remediation roadmap your leadership team can actually fund and track. We'll also cover the DIY-vs-tool-vs-consultant decision, because the right answer changes depending on your team size, deadline, and how much you already have documented.
Gap Analysis vs. Readiness Assessment: Same Neighborhood, Different Job
These two terms get used interchangeably in vendor marketing, and that sloppiness costs people time. A SOC 2 readiness assessment is the broader pre-audit program — it typically includes the gap analysis as one component, but also covers auditor selection, scoping decisions, policy development, evidence infrastructure, and timeline planning end to end. The gap analysis is narrower and more mechanical: it is specifically the exercise of comparing your current-state controls, control by control, against the Trust Services Criteria you've selected, and producing a scored, prioritized list of deltas. Think of readiness as the campaign and the gap analysis as the reconnaissance report that the campaign is built on.
Dimension | Gap Analysis | Readiness Assessment |
|---|---|---|
Primary question | Where do our controls stand today vs. the criteria? | Are we, as an organization, ready to start the audit? |
Typical duration | 2–4 weeks | 6 weeks – 6 months |
Core output | Gap register with severity ratings | Full pre-audit program plan |
Includes scoping decisions | Assumes scope is set, or sets it as step one | Owns the scoping decision |
Includes remediation execution | No — hands off to a roadmap | Often includes remediation oversight |
Includes auditor selection | No | Sometimes |
Who typically runs it | Internal compliance/security lead, or a narrow consulting engagement | Internal team + consultant, often over months |
Best analogy | A home inspection report | The full renovation project |
If you only read one distinction in this article, make it this one: a gap analysis is a diagnostic instrument, not a program. It tells you what's broken. It does not, by itself, fix anything, staff the fix, or manage the calendar — that's the remediation roadmap and, at the program level, the readiness assessment.
"People ask me to 'do a gap analysis' and mean three completely different things — sometimes it's a two-hour conversation, sometimes it's a six-week project with forty interviews. I always start by asking what decision the output needs to support. If the answer is 'tell the board how far we are,' that's a two-week diagnostic. If the answer is 'build our entire compliance program,' that's not a gap analysis anymore, that's readiness." — Tom Okafor, Founder, Bastion Assurance Partners
Why Run One Before the Audit Starts
The uncomfortable truth about SOC 2 audits is that auditors are not there to help you pass. A CPA firm's job under SSAE 18 is to independently test whether your controls are suitably designed and, for a Type II report, operating effectively over the review period — and to say so honestly, even if the answer is "no, with exceptions." Walking into fieldwork without having assessed yourself first means you're finding out about your gaps at the same time the auditor is documenting them in a working paper. That's the expensive way to learn.
A gap analysis run four to twelve weeks before the observation period begins buys you three things: time to fix design gaps before they become tested exceptions, evidence that your organization takes the process seriously (which matters when you're negotiating scope and fees with your CPA firm), and a defensible answer to the leadership question Dana got asked — "how far away are we, really" — with numbers behind it instead of a shrug.
Cost of Skipping the Gap Analysis | Typical Consequence |
|---|---|
Discover a missing control mid-fieldwork | Scramble remediation under auditor scrutiny, risk of qualified opinion |
No prioritization of findings | Team burns weeks on low-impact fixes while high-severity gaps sit open |
No cost estimate before committing to a date | Budget overruns, emergency tooling purchases |
Leadership has no visibility into true state | Executive sponsorship erodes when surprises surface late |
Auditor first to identify design gaps | Damaged auditor relationship, harder future negotiations |
When to Run the Gap Analysis
Timing matters more than most first-timers expect. Run it too early — before you've picked your Trust Services Criteria and defined your system boundary — and you'll assess the wrong scope. Run it too late, and you lose the runway needed to actually close what you find. The sweet spot sits after scoping is roughly settled but well before you'd sign an engagement letter with an auditor: enough time exists to close medium-severity gaps and start the Type II observation clock deliberately rather than by accident. For a full calendar view of how this slots into a broader program, see the SOC 2 readiness timeline.
Milestone | Typical Timing Relative to Audit Start | Gap Analysis Role |
|---|---|---|
Scope and TSC selection finalized | T-minus 8–12 weeks | Prerequisite input |
Gap analysis conducted | T-minus 6–10 weeks | Core diagnostic |
Gap register prioritized, roadmap built | T-minus 5–8 weeks | Output of this process |
High/critical gaps remediated | T-minus 2–6 weeks | Execution phase |
Auditor engagement letter signed | T-minus 4–6 weeks | Parallel track |
Type II observation period opens | T-0 | Controls must already operate |
Fieldwork / evidence pull | End of observation period | Auditor tests what you assessed |
The Gap Analysis Method: Six Steps
Everything below is the actual mechanical process — not a philosophy of compliance, but the sequence of work a competent analyst (internal or external) executes to turn "we don't know where we stand" into a scored, actionable register. It's the same sequence whether you're doing this yourself in a spreadsheet or a consultant is doing it with a GRC platform behind the scenes.
Step | Name | Core Output |
|---|---|---|
1 | Scope confirmation | Locked system boundary + selected TSC categories |
2 | Control inventory build | Full list of applicable criteria mapped to your environment |
3 | Control-by-control assessment | Design + implementation status per control |
4 | Maturity rating | Standardized score per control |
5 | Evidence spot-check | Confirmation the evidence trail exists (or doesn't) |
6 | Gap register + prioritization | Ranked list feeding the remediation roadmap |
Step 1: Scope Confirmation
You cannot run a gap analysis against a moving target. Before assessment work starts, lock two things: the system boundary — which products, environments, infrastructure, and data flows are actually in scope — and which Trust Services Criteria beyond the mandatory Security category apply. Getting this wrong is the single most common source of wasted gap-analysis effort; assess against a scope that later expands or contracts and half your findings become irrelevant. This decision deserves its own dedicated process — see SOC 2 scope definition — but the gap analysis should not proceed until scope is at minimum in a stable draft state.
Trust Services Category | Required? | Include If... |
|---|---|---|
Security (Common Criteria) | Always required | Every SOC 2 report, no exceptions |
Availability | Optional | You've made uptime/SLA commitments customers rely on |
Processing Integrity | Optional | Your system processes transactions, calculations, or data pipelines customers depend on for accuracy |
Confidentiality | Optional | You handle confidential business data under contractual protection beyond normal security |
Privacy | Optional | You collect/process personal information as a core part of the committed system function |
"The scoping conversation always wants to happen halfway through the gap analysis, not before it. Someone on the assessment team says 'wait, does this cover our mobile app or not?' three weeks in. Lock scope on paper, get it signed off by whoever owns the customer relationship, and only then start assessing controls. Otherwise you're aiming at fog." — Renata Silva, Director of Compliance, Cordant Analytics
Step 2: Build the Control Inventory
With scope locked, map every applicable criterion — all nine Common Criteria series (CC1 through CC9) plus any selected additional categories — against your actual environment. This isn't copying a generic checklist; it's translating each criterion into a control statement specific to your systems, your team structure, and your tooling. This mapping exercise is substantial enough that we cover it as its own topic — see SOC 2 control matrix: mapping controls to criteria — but at minimum, the gap analysis needs a working inventory before assessment can begin. A thin inventory (treating "access control" as one line item) produces a thin, useless gap analysis. A granular inventory (separate line items for provisioning, deprovisioning, privileged access, and periodic access review) produces findings someone can actually act on.
Common Criteria Series | COSO Principle Area | Typical Control Count in Inventory |
|---|---|---|
CC1 — Control Environment | Tone at the top, governance, org structure | 5–8 |
CC2 — Communication and Information | Internal/external comms, policy distribution | 3–5 |
CC3 — Risk Assessment | Risk identification, fraud risk, change-driven risk | 4–6 |
CC4 — Monitoring Activities | Ongoing/separate evaluations, deficiency communication | 3–4 |
CC5 — Control Activities | Control selection, technology controls, policies | 3–5 |
CC6 — Logical and Physical Access | Access provisioning, authentication, encryption, physical | 10–15 |
CC7 — System Operations | Detection, incident response, recovery, change | 6–9 |
CC8 — Change Management | SDLC, testing, approval, deployment | 4–6 |
CC9 — Risk Mitigation | Vendor risk, business disruption | 3–5 |
Step 3: Control-by-Control Assessment
For each item in the inventory, the assessor determines two things: does a control exist that is designed to meet this criterion, and if so, is it actually implemented and operating today. This is done through a blend of methods — no single technique gives you the full picture, and relying on just one (usually "ask someone in Slack") is how gap analyses miss real problems.
Assessment Method | What It Confirms | Typical Use |
|---|---|---|
Document review | Policies, standards, and procedures exist and are current | Governance and policy-driven controls (CC1, CC2, CC5) |
Interview | Control owner's understanding and actual practice | Every control category, especially process-driven ones |
System observation / screen-share | The control as configured in the live system | Access control, encryption, logging, MFA |
Walkthrough | A single instance traced start to finish | Complex processes: onboarding, change management, incident response |
Technical testing / sampling | The control operated correctly across multiple instances | High-risk controls where a single walkthrough isn't sufficient |
Artifact pull | Tickets, logs, approvals as physical proof | Anything that will need to become audit evidence later |
A walkthrough deserves special mention because first-timers underuse it. Walking through one real onboarding ticket end to end — from access request through approval, provisioning, and the eventual offboarding — surfaces gaps that a policy document review never will, because policies describe the intended process and walkthroughs reveal the actual one. If those two disagree, you've found your gap.
Step 4: Rate Maturity, Not Just Presence
A binary "have it / don't have it" rating flattens the most useful signal a gap analysis produces. A control that exists on paper but isn't consistently followed is a very different risk than a control that's fully automated and enforced by tooling — and it needs a different remediation approach. Use a five-point maturity scale, applied consistently across every control in the inventory, so the gap register can later be sorted and compared apples-to-apples.
Maturity Level | Label | Description |
|---|---|---|
0 | Not Present | No control exists; criterion is unaddressed |
1 | Ad Hoc | Control happens informally, undocumented, person-dependent |
2 | Defined | Documented policy/procedure exists, but implementation is inconsistent |
3 | Implemented | Control is consistently applied but not yet evidenced or monitored |
4 | Managed | Control operates consistently with evidence captured routinely |
5 | Optimized | Control is automated, monitored, and improved based on metrics |
For a Type II audit, the practical target is Level 4 for every in-scope control before the observation period opens — Level 3 controls will likely pass a walkthrough but generate exceptions once an auditor samples multiple months of evidence, because "consistently applied but not evidenced" is functionally invisible to a sampling-based test.
"The scariest gap analysis finding isn't 'control doesn't exist.' It's 'control exists, everyone swears it works, and there's zero evidence trail.' That's a Level 3 masquerading as a Level 4, and it's the single most common thing I find in first-time assessments. The fix usually isn't a new control — it's just turning on logging for a control that was already there." — Sam Ostrander, GRC Manager, Meridian Cloud Storage
Step 5: Spot-Check the Evidence Trail
Before finalizing a rating, pull a small sample of the actual audit evidence the control would need to produce — an access review spreadsheet, a set of closed change tickets, a training completion log — and check whether it exists, is complete, and covers a defensible time period. This step catches the gap between "we do this" and "we can prove we did this," which is functionally the only gap an auditor cares about. A deeper treatment of building the evidence program itself lives in SOC 2 evidence collection; here, the goal is narrower — just confirm evidence exists at all before you rate a control higher than Level 2.
Control Area | Evidence to Spot-Check | Red Flag If Missing |
|---|---|---|
Access provisioning | Signed access request + approval per new hire | No formal request trail, access granted via ad hoc Slack message |
Access deprovisioning | Termination ticket + revocation timestamp | Revocation happens days after last day, or isn't logged |
Change management | Pull request + approval + deployment log | Changes deployed without documented review |
Vulnerability management | Scan reports + remediation tickets with dates | Scans run but findings never tracked to closure |
Incident response | Incident ticket with timeline and resolution | No formal incident log; incidents handled verbally |
Vendor risk | Vendor risk assessments on file | No due diligence records for critical subservice organizations |
Security training | Completion records by employee and date | Training assigned but completion not tracked |
The Gap Register: Turning Findings Into a Working Document
Everything from Steps 1 through 5 feeds one artifact: the gap register. This is the single most important deliverable of the entire exercise, and it's worth building deliberately rather than as a byproduct. A good gap register is a living spreadsheet or GRC-tool export that every stakeholder — engineering, HR, IT, legal — can filter to see exactly what's owed from their function.
Field | Purpose | Example |
|---|---|---|
Gap ID | Unique reference for tracking | GAP-014 |
Criterion | Which TSC/CC criterion is affected | CC6.1 |
Control Area | Human-readable category | Logical access — privileged accounts |
Current State | What exists today | Admin access granted manually, no periodic review |
Required State | What the criterion needs | Documented, reviewed, least-privilege admin access |
Maturity Rating | 0–5 score from Step 4 | 2 (Defined) |
Severity | Critical / High / Medium / Low | High |
Owner | Accountable individual | IT Manager |
Estimated Effort | Rough sizing | 3 weeks, 1 FTE |
Target Close Date | Deadline before observation period | Week 6 |
Status | Open / In Progress / Remediated / Verified | Open |
A control deficiency belongs in this register the moment it's identified, even if remediation is trivial — the register is your record that the organization found and tracked its own gaps, which auditors and prospects alike read as a sign of a functioning program, not a weakness to hide.
Prioritizing the Gaps: Impact, Effort, and Criticality
Not every gap deserves the same urgency, and treating them all equally is how teams burn their runway polishing low-value findings while a critical one sits open until week ten. Score each gap on two axes — business impact if left open, and effort required to close it — then use that scoring to sequence the remediation roadmap.
Severity Tier | Definition | Typical Example | Target Close Window |
|---|---|---|---|
Critical | Control absent on a criterion directly tied to a customer commitment or CC6 access/security core | No encryption at rest on customer database | Immediately, before anything else |
High | Control present but materially weak; likely to generate an audit exception | Access reviews happen but are undocumented | Before observation period opens |
Medium | Control gap unlikely to cause a report exception but weakens the overall program | Policy exists but hasn't been reviewed/re-approved annually | During observation period, early |
Low | Cosmetic, documentation-only, or best-practice gap | Policy wording inconsistent across documents | Opportunistic, low priority |
Priority Matrix | Low Effort | High Effort |
|---|---|---|
High Impact | Do first — quick wins that materially reduce risk | Schedule early — biggest roadmap item, start immediately given lead time |
Low Impact | Do when convenient — batch with other small fixes | Deprioritize — revisit post-audit unless required by criterion |
"I make every client rank their own gap register before I give them my opinion. Half the time they already know which three things are scary — they just haven't said it out loud in front of the CFO yet. The prioritization exercise is as much about organizational honesty as it is about methodology." — Lauren Fitch, CPA, Audit Partner, Fitch & Marsh LLP
From Gap Register to Remediation Roadmap
The gap register tells you what's wrong. The roadmap tells you who fixes it, in what order, by when, and with what resources — and it's a distinct deliverable with its own methodology, covered in depth in SOC 2 remediation planning. For the purposes of the gap analysis itself, your job is to hand off a register that's already sequenced well enough that a project plan can be built from it in a single working session, not a multi-week negotiation about what matters.
Roadmap Phase | Typical Duration | Contents |
|---|---|---|
Phase 1 — Critical fixes | Weeks 1–3 | All critical-severity gaps; blockers to starting observation period |
Phase 2 — High-severity closure | Weeks 3–6 | High-severity gaps; evidence-trail fixes for existing controls |
Phase 3 — Medium-severity, parallel to observation start | Weeks 5–10 | Medium gaps closed while Type II clock is already running |
Phase 4 — Low-severity and polish | Ongoing | Documentation cleanup, policy wording, minor process gaps |
Each gap should also carry a corrective action plan — owner, root cause, fix, and verification method — rather than just a target date. A date without a documented fix approach is a wish, not a plan, and it's the fastest way for a roadmap to slip. Where the root cause isn't obvious (a recurring access-review failure, say), a quick root cause analysis before assigning the fix usually saves a re-open later — patching the symptom without understanding why the control drifted tends to produce the same gap again in the next assessment cycle.
DIY vs. Tool-Assisted vs. Consultant-Led
This is the decision most first-time compliance leads agonize over, and the honest answer is that it depends on team bandwidth, internal expertise, and how much runway you have before the observation period needs to open. All three paths can produce a legitimate gap analysis; they trade off cost, speed, and objectivity differently.
Approach | Cost Range (Illustrative) | Time to Complete | Best Fit | Watch-Outs |
|---|---|---|---|---|
DIY (spreadsheet + internal team) | $0 direct cost, significant internal time | 4–8 weeks part-time | Small teams with an internal security/compliance owner and prior audit exposure | Blind spots from internal bias; no external benchmark; easy to under-scope |
Tool-assisted (GRC/compliance automation platform) | $6,000–$25,000/year (illustrative, platform-dependent) | 1–3 weeks with guided workflows | Teams wanting continuous tracking beyond a one-time exercise | Platform's built-in control library still needs customization to your real environment |
Consultant-led | $8,000–$30,000+ for a standalone engagement (illustrative) | 2–4 weeks | First-time SOC 2 programs, complex environments, tight deadlines needing outside credibility | Quality varies widely; vet for CPA-adjacent or auditor-facing experience, not just sales polish |
The three approaches aren't mutually exclusive — a common and effective pattern is a tool-assisted internal pass to build the inventory and pull the low-hanging findings, followed by a short consultant engagement to stress-test the register and validate maturity ratings before they go to the board. That hybrid tends to be the best value: you avoid paying consultant rates for data entry, but you still get an outside set of eyes on your self-scoring, which is exactly where internal bias creeps in.
"Every internal team rates their own controls a half-point too generous, every single time. It's not dishonesty, it's proximity — you know why the exception happened last quarter and you've mentally already 'fixed' it even though nothing changed in the system. That's the value an outside reviewer adds, even in a DIY-heavy program: recalibration, not reinvention." — Tom Okafor, Founder, Bastion Assurance Partners
Common Gap Patterns: What First-Time Assessments Usually Find
After enough of these, patterns emerge. The specific gaps vary by company, but the categories they cluster in are remarkably consistent across first-time SOC 2 programs — which is useful, because it lets you sanity-check your own register against what's typical before you present it upward.
Common Criteria | Typical Gap Found | Root Cause Usually Is |
|---|---|---|
CC1 — Control Environment | No documented org chart / responsibility matrix for security | Grew organically, never formalized |
CC2 — Communication | Policies exist but were never formally distributed/acknowledged | Policy writing treated as one-time project, not an ongoing process |
CC3 — Risk Assessment | No formal, periodic risk assessment; risk lives in people's heads | No owner assigned, no cadence set |
CC4 — Monitoring | No process for tracking identified deficiencies to closure | Findings get fixed ad hoc but never logged |
CC5 — Control Activities | Controls not mapped explicitly to criteria | Controls exist for good engineering reasons, not compliance reasons — mapping was never done |
CC6 — Access Controls | No periodic access review; deprovisioning inconsistent | Manual, ticket-driven offboarding with no enforcement checkpoint |
CC7 — System Operations | Incident response exists informally, not documented/tested | No tabletop exercise ever run |
CC8 — Change Management | Some changes deployed without documented approval | Hotfix path bypasses standard review under time pressure |
CC9 — Risk Mitigation | Vendor risk assessments missing for critical subservice organizations | Vendor onboarding predates any formal security review step |
Visualizing the Process
flowchart TD
A[Scope Confirmation] --> B[Build Control Inventory]
B --> C[Control-by-Control Assessment]
C --> D[Maturity Rating 0-5]
D --> E[Evidence Spot-Check]
E --> F[Gap Register]
F --> G{Prioritize: Impact x Effort}
G --> H[Critical Gaps - Fix Immediately]
G --> I[High Gaps - Fix Before Observation]
G --> J[Medium/Low Gaps - Fix in Parallel]
H --> K[Remediation Roadmap]
I --> K
J --> K
K --> L[Observation Period Opens]
L --> M[Type II Audit Fieldwork]Case Study: Cordant Analytics Closes the Gap in Eleven Weeks
Back to Dana Whitfield's Tuesday-afternoon problem. With eleven weeks on the clock and a board demanding a real number, Dana ran a hybrid gap analysis: two weeks of internal self-assessment using a GRC platform's control library as a starting inventory, followed by a one-week consultant review to stress-test the ratings. The result was a register of 31 findings — 4 critical, 9 high, 12 medium, 6 low. The critical findings were almost all clustered in access control (CC6): no periodic access review process, shared admin credentials on the production database, and encryption at rest missing on one backup store that had been exempted from the original infrastructure hardening pass. None of the four critical items were technically hard to fix — the hardest part was that nobody had ever inventoried them, because no single owner had visibility across engineering, IT, and HR simultaneously.
Cordant closed all four critical items in the first three weeks, all nine high items by week seven, and opened its Type II observation period at week eight with medium and low items running in parallel. The Type II report — issued nine months later, covering a six-month observation period — came back unqualified, with two minor exceptions in access-review timeliness that the team had already flagged as residual risk going in. The $2.4 million deal signed the week the report was delivered. Total gap-analysis-to-report cost, illustratively, ran just under $40,000 across consultant time, tooling, and one contract engineer for the encryption remediation — a fraction of the deal it unblocked.
"The number that mattered to my board wasn't 'we have gaps.' Every company has gaps. The number that mattered was 'here are 31 specific items, here's what they cost to fix, here's the date we'll be done.' That's what turns a vague compliance ask into a project the CFO will actually approve." — Dana Whitfield, VP of Security & Compliance, Cordant Analytics
Case Study: A FinTech's Near-Miss on Key Management
Jae-won Park led security at Quillhaven Pay, a payments-adjacent FinTech processing transactions on behalf of several sponsor-bank partners. Quillhaven had been through a Type I SOC 2 the year before and assumed the Type II gap analysis would be a formality — mostly confirming that the same controls were still in place. The gap analysis instead surfaced a critical finding nobody expected: the encryption key used to protect stored payment metadata had never been rotated since initial deployment, and there was no documented key management procedure at all, despite a policy document that claimed one existed.
Had that gap gone uncaught, it would very likely have generated an exception under CC6.1 during Type II testing — the auditor would have sampled the key's age against the stated rotation policy and found a direct contradiction. Because the gap analysis caught it eight weeks before the observation period opened, Quillhaven's engineering team implemented a proper rotation schedule with a hardware-backed key management service, documented the procedure, and had two full rotation cycles logged as evidence before fieldwork began. The eventual report came back unqualified.
"Type I gave us false confidence. Design existing at a point in time isn't the same as design that's been operating consistently, and our gap analysis was the first time anyone actually traced the key management control from policy to implementation to evidence. It's the whole reason gap analyses shouldn't just be a rubber stamp on last year's report." — Jae-won Park, Head of Security, Quillhaven Pay
The Tooling Landscape
Compliance automation platforms have made the mechanical parts of a gap analysis faster, but it's worth being clear-eyed about what they do and don't replace. They accelerate the inventory-building and evidence-collection steps significantly; they do not replace the judgment calls in Steps 3 and 4, where someone still has to decide whether a control is genuinely Level 4 or a hopeful Level 3. If you're shortlisting a platform to run or track your own gap analysis, our roundup of the best SOC 2 compliance software compares control-library depth and evidence-automation coverage across the leading options.
Tool Category | What It Speeds Up | What Still Needs a Human |
|---|---|---|
GRC / compliance automation platforms | Pre-built control libraries mapped to TSC, automated evidence pulls from connected systems | Customizing the library to your actual environment; validating maturity ratings |
Spreadsheet templates | Low-cost structuring of the register | Everything — no automation, pure manual tracking |
Vulnerability/config scanners | Objective technical evidence for CC6/CC7 controls | Interpreting findings against criteria language |
Policy management tools | Version control and distribution/acknowledgment tracking | Actually writing policies that reflect real practice |
Access review tools | Automating periodic access certification | Deciding who should have access in the first place |
Common Pitfalls in a First-Time Gap Analysis
Pitfall | Why It Happens | How to Avoid It |
|---|---|---|
Assessing against an unlocked scope | Scoping decision deferred or informally made | Get scope signed off in writing before assessment starts |
Treating the gap analysis as a checklist exercise | Rushed timeline, pressure to show a fast answer | Insist on evidence spot-checks, not just self-attestation |
No maturity scale, just pass/fail | Simpler to execute, seems faster | Use the 0–5 scale — it's the difference that drives real prioritization |
Gap register never gets a prioritization pass | Findings dumped into a spreadsheet with no owner assigned | Require severity, owner, and target date on every row before calling it done |
Confusing gap analysis with full readiness | Vendor sells "readiness" but delivers a shallow checklist | Clarify deliverables and scope in any consulting SOW up front |
No follow-up verification after remediation | Team assumes "fixed" means "closed" | Re-test remediated items before observation period opens, not after |
"The pitfall I see most is a gap register that gets built once and never opened again until the auditor asks for it. A gap register is a working document. If nobody's updated the status column in six weeks, it's not tracking remediation — it's a historical artifact." — Priya Rangan, VP of Engineering, Cordant Analytics
Roles and Responsibilities
A gap analysis fails quietly when responsibility is assumed rather than assigned. Before work starts, get explicit agreement on who does what — this RACI-style breakdown is a reasonable starting template.
Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Scope confirmation | Compliance lead | Executive sponsor (CEO/CTO) | Sales/customer success | Full leadership team |
Control inventory build | Compliance lead / consultant | Compliance lead | Engineering, IT, HR leads | Control owners |
Control assessment interviews | Assessor (internal or consultant) | Compliance lead | Individual control owners | — |
Maturity rating and register | Assessor | Compliance lead | Executive sponsor for critical items | Board/leadership |
Prioritization | Compliance lead | Executive sponsor | Engineering leadership (effort estimates) | All control owners |
Remediation execution | Individual control owners | Compliance lead | Assessor (for re-verification) | Executive sponsor |
Cost and Timeline Expectations
These figures are illustrative and will vary by company size, environment complexity, and how much documentation already exists — but they're a reasonable planning baseline for a mid-market SaaS or service organization running its first gap analysis.
Company Profile | Typical Gap Analysis Duration | Typical Findings Count | Illustrative Cost Range |
|---|---|---|---|
Early-stage startup (under 30 employees, single product) | 2–3 weeks | 15–25 | $5,000–$15,000 |
Mid-market SaaS (30–200 employees) | 3–5 weeks | 25–40 | $10,000–$30,000 |
Complex/multi-product org (200+ employees, multiple environments) | 5–8 weeks | 35–60+ | $20,000–$60,000+ |
For a full breakdown of budgeting across the entire compliance program, not just the gap analysis, see SOC 2 cost management.
How This Connects to the Rest of Your Pre-Audit Program
A gap analysis doesn't happen in isolation, and treating it as a one-off deliverable is how findings quietly die in a spreadsheet nobody revisits. Once your register exists, it should feed directly into an ongoing internal audit program — a lighter-weight version of the same control-by-control testing, run on a cadence, so the maturity ratings you assigned during the gap analysis get re-validated rather than assumed to still be true six months later. It should also inform a final pre-audit checklist pass in the weeks immediately before you sign the engagement letter, which acts as your last confirmation that everything the gap analysis flagged as critical or high has actually closed — not just been assigned an owner and a hopeful date.
One distinction worth restating because it trips up almost every first-time program: the gap analysis measures inherent risk against your control environment and produces a snapshot of residual risk once existing controls are accounted for. It is not itself a form of risk treatment — it identifies where treatment is needed and leaves the decision of how (mitigate, accept, transfer, or avoid) to the roadmap and its owners. Keeping that boundary clear stops the exercise from sprawling into a full risk-management program when what leadership actually asked for was a diagnostic.
Program Component | Relationship to the Gap Analysis |
|---|---|
Scope definition | Prerequisite input — must be locked before assessment starts |
Control matrix | The inventory the gap analysis assesses against |
Gap analysis (this article) | Produces the scored, prioritized register |
Remediation planning | Converts the register into an executed project plan |
Internal audit program | Re-tests the same controls on an ongoing cadence post-remediation |
Pre-audit checklist | Final confirmation pass immediately before engagement |
Auditor selection | Runs in parallel — informed by scope, not by gap-analysis findings |
Gap Analysis as a Business Accelerant, Not Just a Compliance Task
It's worth reframing the whole exercise before you close this out. A gap analysis feels like defensive work — closing holes, avoiding embarrassment in front of an auditor — but the organizations that get the most value out of it treat the finished register as a sales asset, not just a compliance artifact. A prioritized, actively-tracked gap register is proof to a skeptical prospect's security team that your organization doesn't just claim to take SOC 2 seriously — it can show the paper trail. That distinction increasingly closes deals on its own, well before the report is even in hand, and it's exactly the material that feeds SOC 2 sales enablement conversations once your program matures. The findings don't stop being useful once remediation closes, either — the same register becomes the input for identifying post-audit improvement opportunities in the next cycle, so the organizational memory compounds instead of resetting every year.
The version of this story nobody wants is the one where the gap analysis becomes a shelf document — thorough, accurate, and completely ignored the moment the immediate deal pressure eases. The version that actually pays off treats the register as a living operational artifact: reviewed monthly, tied to owners with real deadlines, and revisited every time scope changes. That's the difference between a company that passes its first audit by accident and one that builds a compliance program it can sustain.
Get Started: Tools to Run Your Own Gap Analysis
You don't need to build every piece of this from scratch. PentesterWorld's SOC 2 Gap Analysis Tool walks through the same six-step method covered here — scoping, inventory, assessment, maturity rating, evidence check, and prioritization — in a guided format that outputs a ready-to-use gap register. Pair it with the SOC 2 Trust Services Criteria Mapping Template to build your control inventory faster, or the SOC 2 Control Matrix / RACI Template if you're assigning ownership across a larger team. If you're earlier in the process and still deciding whether you're ready to start this exercise at all, the "Are You SOC 2 Ready?" quiz is a five-minute gut check, and the SOC 2 Glossary is worth bookmarking for every term in this article and the ones still ahead of you.
Whichever path you choose — DIY, tool-assisted, or consultant-led — the goal is the same one Dana Whitfield needed answered on that Tuesday afternoon: a real number, not a shrug, standing between where your controls are today and where a clean report needs them to be.