SOC 2 Gap Analysis: How to Run One and Fix What It Finds

A SOC 2 gap analysis compares the controls you run today with the Trust Services Criteria in your report scope, then turns every difference into a fix with an owner and a date. It is not an audit and it produces no report. It is the step between deciding you need SOC 2 and booking an auditor, and it is where you find out, privately and cheaply, what would otherwise surface as an exception in front of a customer.

This guide walks through what a gap analysis covers, how to run one step by step, which evidence to gather, how to rank the gaps, and how long the work tends to take.

TL;DR

• A SOC 2 gap analysis is an internal or advisor-led comparison of your current controls against the criteria in scope. It is separate from the audit itself.
• Start with scope: Security is always in, and the other categories (availability, confidentiality, processing integrity, privacy) are chosen by what your customers expect of your service.
• Collect real evidence, not intentions: access reviews, logs, vulnerability tickets, incident records and change records.
• Fix structural gaps first (no risk assessment, undocumented procedures), then the technical and operational work that needs longer lead times.
• Finish remediation well before a Type I or Type II examination starts, so the auditor sees working controls.

Table of Contents

• What a SOC 2 gap analysis is, and what it is not
• Who needs one and when
• Step 1: Set the scope
• Step 2: Inventory the controls you already run
• Step 3: Map controls to the criteria
• Step 4: Check the evidence, not the intention
• Common gaps first-time organizations find
• Step 5: Prioritize and remediate
• How long does a gap analysis take?
• How the gap analysis prepares you for Type I and Type II
• Doing it yourself, with an advisor, or with a provider
• Perspective
• Get audit-ready with Nexus
• FAQ
• Sources

What a SOC 2 gap analysis is, and what it is not

SOC 2 is an examination of a service organization's description of its system and the controls that relate to security, availability, processing integrity, confidentiality or privacy. The AICPA describes it as an assertion-based examination of a service organization's controls, carried out by an independent CPA firm. Management states what the controls are, and the auditor tests whether that statement holds.

A gap analysis sits in front of that. Think of it as a dress rehearsal with no consequences:

Because nobody outside your company relies on a gap analysis, you can be blunt. A weak finding costs you a ticket, not a qualified opinion.

If you want the wider picture of readiness work, including how the assessment fits the audit calendar, our guide to a SOC 2 readiness assessment covers it. The terms overlap: a readiness assessment is, in practice, a gap analysis plus a plan.

Who needs one and when

The typical trigger is commercial. A prospect's security questionnaire asks for a SOC 2 report, a procurement team stalls, or a larger customer makes it a contract condition. SaaS companies, managed service providers, data processors and healthcare technology vendors see this most often.

Run the analysis when:

• You are pursuing a first SOC 2 report and have never been examined.
• You are moving from a Type I to a Type II report and need to know which controls will not hold up over months.
• You have changed your system materially: a cloud migration, a new product line, a new data store, or a change of infrastructure provider.
• A prior report carried exceptions and you want to confirm the fixes before the next period begins.

Startups often assume this is a problem for later. In our experience it is easier to build controls into a young environment than to retrofit them, which is why we wrote about cloud compliance for startups.

Step 1: Set the scope

Everything else depends on scope, so spend real time here. Define three things.

The system. Which product, platform or service will the report describe? Include the infrastructure, software, people, procedures and data that support it. Leave out corporate systems that do not touch customer data, but be able to explain why.

The criteria. Security, often called the Common Criteria, applies to every SOC 2 report. The other four categories are optional. Choose them by asking what your customers rely on you for:

• Availability if you commit to uptime or recovery targets.
• Confidentiality if you hold information customers have designated confidential, such as contracts or source code.
• Processing integrity if your service performs calculations or transactions that must be complete and accurate.
• Privacy if you collect personal information directly and make commitments about its use.

More categories mean more controls to evidence and more audit work, so add them when a customer or contract demands it, not by default.

The period. For a Type II report, decide the observation window. A gap analysis should assume you will need to show controls operating consistently across that whole window, not on the day the auditor arrives.

Step 2: Inventory the controls you already run

Most organizations have more controls than they can document. Before you compare anything, write down what exists, grouped by area:

• Governance: policies, risk assessment, board or leadership oversight, security roles.
• People: background checks, onboarding and offboarding, security awareness training.
• Access: single sign-on, multi-factor authentication, role definitions, privileged access.
• Operations: logging, monitoring, vulnerability scanning, patching, backups.
• Change management: code review, approvals, separation between development and production.
• Incident management: response plan, on-call duty, post-incident reviews.
• Vendors: inventory, due diligence, contract terms.

For each control, record the owner, how it operates (automated or manual), how often it runs and where the proof lives. If you cannot name an owner, you have already found a gap.

Step 3: Map controls to the criteria

Now place each control against the criteria in your scope. The criteria describe outcomes, not specific tools. The 2017 Trust Services Criteria were issued with revised points of focus in 2022, and the AICPA's own materials make the same point: the service organization identifies the controls it has designed and operates to meet the criteria. There is no fixed list you must copy.

Three outcomes are possible for every criterion:

1. Met. A control exists, has an owner, operates as described and leaves evidence.
2. Partly met. The control exists but is informal, inconsistent or undocumented.
3. Not met. No control addresses the criterion.

Scoring each criterion on a simple scale makes the output usable. A scored analysis records where each criterion stands and then turns remediation needs into a roadmap with a realistic timeline, which is far easier to defend to leadership than a loose list of worries.

Step 4: Check the evidence, not the intention

This is the step that separates a useful gap analysis from a comfortable one. An auditor does not accept "we do that." They want proof the control operated. For each control, pull the artifact and ask whether a stranger could verify it.

Typical evidence by area:

Strong evidence is dated, attributable and specific. A signed access review with the reviewer's name and date beats a screenshot of a user list. Vulnerability tickets that show when an issue was found, when it was fixed and whether that met your own SLA beat a statement that you patch regularly.

For a Type II report, evidence must show controls were active throughout the audit period. That means a gap analysis should test samples across several months, not one convenient week. If your quarterly access review happened twice in a year and the policy says four times, that is a finding.

Two areas deserve extra attention because they fail often and cost time to fix:

• Logging. Many teams collect logs but cannot show anyone reviews them or that retention matches policy. Our overview of the role of logging in cloud security explains what good looks like.
• Vulnerability handling. Scans are common; documented, dated remediation is not. See our write-up on a vulnerability remediation process aligned with CISA guidance.

Common gaps first-time organizations find

The same issues come up again and again in first-time assessments:

• Missing or outdated policies, or policies nobody has acknowledged.
• No formal risk assessment, or one done once and never revisited.
• Insufficient logging and monitoring.
• Access reviews done informally, if at all.
• No penetration test, or no record of fixing what it found.
• A vendor list with no risk tiering.
• Incident response plans that have never been exercised.
• Shared accounts and offboarding delays.

Cloud environments add a particular trap: assuming the provider's controls cover yours. Under the shared responsibility model, your cloud provider secures its infrastructure and you secure your configuration, identities and data. We explain where that line falls in why cloud security shared responsibility matters. Vendor risk is the other frequent blind spot, covered in our guide to types of third-party cybersecurity risks.

Some gaps are not technical at all. Missing policy documents, unclear ownership and undocumented procedures delay examinations more often than missing tools. Organizations in education technology, for example, often juggle several overlapping compliance tracks at once, such as CIPA compliance consulting for school-facing services alongside SOC 2, and the shared lesson is the same: write the policy, assign the owner, keep the record.

Step 5: Prioritize and remediate

A findings list with 60 items and no order is paralyzing. Rank by two questions: how much does this gap threaten the audit, and how long will it take to fix?

Tier 1: structural gaps. These undermine everything else. An absent risk assessment is the classic example, along with undocumented procedures for key controls. Without them, other controls have nothing to hang from. Fix these first.

Tier 2: documentation and formalization. Policies, procedures, role descriptions, training records and access review templates. These can often be closed within weeks because the work is writing and agreeing, not engineering.

Tier 3: technical and operational controls. Rolling out multi-factor authentication everywhere, building centralized logging, introducing a change approval workflow, standing up an on-call rotation. These need longer lead times because they involve tooling, testing and habit change.

Tier 4: refinements. Improvements that strengthen the program but would not cause an exception.

For every item, the remediation plan should name an owner, set a deadline, estimate the effort and state what evidence will exist when it is done. A roadmap without owners and dates is a wish list.

Two practical habits help:

• Fix the cause, not the instance. If one terminated employee kept access for two weeks, repair the offboarding process rather than removing one account.
• Start generating evidence as soon as a control goes live. For Type II, the clock on proof starts when the control starts operating.

How long does a gap analysis take?

There is no single answer, and published figures vary widely with company size, scope and starting maturity. As a working rule, the assessment itself is the short part: a small, well-scoped environment can often be reviewed in a few weeks, while a larger multi-product environment takes longer because evidence collection spans more systems and teams.

Remediation is the variable that drives the calendar. Documentation fixes move quickly. New technical controls and operational processes take longer, and anything requiring budget approval, vendor onboarding or engineering capacity adds more. Type II examinations then require an observation period during which controls must operate, so plan backward from the date a customer needs the report.

Factors that stretch the timeline:

• Scope that includes more categories than customers require.
• No single owner for the program.
• Evidence scattered across tools and individuals.
• Heavily manual controls that depend on people remembering.
• A fast-changing environment, where infrastructure changes during remediation.

Factors that shorten it:

• Tight scope tied to a real customer requirement.
• Automated evidence collection from your identity, cloud and ticketing systems.
• Executive sponsorship, so decisions are made in days rather than weeks.
• An advisor who has seen the same gaps before.

Conduct the assessment well before the audit so there is time to fix what it finds. If you schedule the audit first and the analysis second, you have inverted the point.

How the gap analysis prepares you for Type I and Type II

For a Type I examination, the auditor evaluates whether controls are suitably designed at a point in time. A gap analysis directly prepares you: if every criterion is marked met, with an owner and a document behind it, design questions are largely answered.

For a Type II examination, design is only half the story. The auditor tests whether controls operated effectively across the period. Your gap analysis should therefore include a sampling exercise: pick a control, pull every instance from the last quarter and see whether any are missing. Gaps in operation are harder to cure after the fact, because you cannot go back and perform last month's review.

A sensible sequence for most first-time organizations is: gap analysis, remediation, a short period of internal evidence collection, then the examination. Whether you go straight to Type II or start with Type I depends on what your customers will accept, so ask them before you decide.

Doing it yourself, with an advisor, or with a provider

Small teams can run a first gap analysis internally using the steps above, provided someone owns it and the people assessing a control are not the ones who operate it. Self-review has a known blind spot: you grade your own work generously.

An outside practitioner adds an independent view, experience of what auditors typically test and often the ability to implement the fixes. If you take that route, look for one team that can assess, remediate and then keep the controls running, so the findings do not land in a queue nobody owns.

Perspective

Most SOC 2 projects we see stall for the same reason: the gap analysis is done by one party, the fixes belong to a second, and the day-to-day security operations belong to a third. Findings fall between them.

We built Nexus around the opposite idea. When cybersecurity, cloud management, IT operations and compliance sit with one provider under a single SLA, a gap such as weak logging or an unreviewed access list has one accountable owner from discovery through remediation and into continuous monitoring.

That matters because SOC 2 is not a document you produce once. It is a record that your controls keep working. Our 24/7 threat detection and monitoring, vulnerability management and incident response generate the same evidence your auditor will ask for, as a by-product of running security properly. Our senior practitioners work directly with your team, and our pricing is flat-rate and predictable, so a compliance project does not turn into surprise invoices.

Our advice is simple: scope tightly, test the evidence, fix the structural gaps first, and put someone accountable for every line on the roadmap.

Nick - Sr. Executive

Get audit-ready with Nexus

Nexus delivers compliance assessments for SOC 2, HIPAA, PCI-DSS and ISO 27001, alongside the cybersecurity, cloud and managed IT services that keep controls running once the assessment ends. If a gap analysis shows you need new logging, access controls, backup and recovery or monitoring, we can handle that under one agreement rather than several. Explore our IT and cybersecurity services or start from the Nexus home page.

Nexus does not publish prices for these services, so the quickest way to scope an engagement is to talk to our team about your systems and the report your customers expect.

FAQ

Is a SOC 2 gap analysis required before an audit?

No. SOC 2 does not require a gap analysis, and the auditor does not ask for one. In practice, most first-time organizations do one because it reveals problems while they can still be fixed quietly. Skipping it often means discovering the same problems as audit exceptions.

What is the difference between a gap analysis and a readiness assessment?

The terms are used almost interchangeably. Both compare current controls with the applicable criteria. A readiness assessment usually adds a remediation plan and sometimes a mock walkthrough of the audit, while a gap analysis can be the narrower comparison. Neither results in an attestation report.

Can the same firm that does my gap analysis perform my SOC 2 audit?

The examination must be performed by an independent CPA firm, and independence rules limit how much advisory work a firm can do for the same client. Use an advisor for the gap analysis and remediation, and confirm with your chosen CPA firm how it treats prior advisory work before you engage either.

Which Trust Services Criteria should I include?

Security is part of every report. Add availability, confidentiality, processing integrity or privacy only when your customers' expectations or contracts call for them, since each added category increases the controls you must evidence.

How often should I repeat a gap analysis?

Repeat it before each annual examination cycle and after any major change to your system, such as a migration or a new product. A lighter internal review each quarter helps you catch drift in controls before it becomes an audit finding.

Sources

• SOC 2 Reporting on an Examination of Controls at a Service Organization, AICPA
• Cyber Safety Consulting Services, CIPA compliance consulting

Recommended

• A SOC 2 readiness assessment: what it is and how to run one
• How security orchestration works: a SOC practitioner's guide
• Free security audit checklist for small businesses