SOC 2 Gap Analysis for Startups: Find the Work Before the Audit
Run a SOC 2 gap analysis before your startup starts its evidence period. Compare scoped criteria with real controls, source proof, owners, and a dated fix plan.
A SOC 2 gap analysis gives your startup a list of work to finish before it relies on a proposed audit date or Type 2 evidence period. Define the service and criteria you plan to include, compare them with controls that really run, then check whether you can retrieve dated proof from the systems that run those controls. Give each gap an owner, fix, deadline, and closure test. A green percentage cannot replace those decisions or the CPA firm’s examination.
What should the gap analysis compare?
The AICPA Trust Services Criteria provide the criteria for controls relevant to Security, Availability, Processing Integrity, Confidentiality, and Privacy. Start with the service boundary and categories you propose, then map each applicable criterion to your actual risks, commitments, and controls. Ask a CPA firm to review the proposed scope and report plan before you rely on them for an examination.
Check four different things for each control:
Design
Inspect the activity, trigger, owner, systems, and a safe walkthrough. A gap exists if a policy says access is reviewed but no one knows which accounts or when.
Operation
Before the proposed period, inspect a recent real occurrence if the control already runs. If the control is new, mark operation as pending. Once the period starts, check its first due occurrence. A planned review that never happened is an operating gap.
Proof
Find a dated source record and any review decision the control requires. Mark future period proof as pending until the activity occurs. A dashboard showing current access does not show the result of a prior review.
Coverage
Check whether the control covers the scoped service and proposed period. A review of production accounts may omit a support system with customer access.
Do not mark a missing artifact as a failed control without checking what happened. Likewise, a saved screenshot does not prove an activity operated as designed. A walkthrough can test the design, but it cannot replace a missed control occurrence in a Type 2 period. Record which fact is known, which is still unverified, and who can check the source.
How do you make a gap record someone can close?
Use one row per finding. Record a safe source reference and the query or retrieval steps beside the judgment so another authorized owner can repeat the check. Keep restricted exports in their source system or an approved store, not in Git. A small team’s working row can look like this:
| Field | Example for a production access review |
|---|---|
| Scope and criterion | Production access; proposed Security criterion and related control |
| Current state | Owner reviews the main identity directory monthly |
| Source checked | Safe references to the directory export, review ticket, and removal tickets for the last review |
| Gap | A support tool with customer access is absent from the reviewed population |
| Action and owner | Engineering lead adds the tool to the source inventory and review procedure |
| Due date | Before the next scheduled review and before relying on the proposed period |
| Closure check | Reviewer reconciles the tool’s user export to the review list and records decisions and removals |
This row is a management example, not an AICPA-prescribed control or a promise that the CPA firm will accept it. The exact systems, cadence, and evidence depend on your service and control design. The controls guide shows how to write those activities from the scoped risks rather than copying a generic list.
Which gaps should you fix first?
Sort by dependency and exposure, not by how quickly someone can turn a cell green. Resolve an unknown service boundary or report goal first because it changes the rest of the analysis. Next, address controls that do not operate, especially where a customer commitment or a real system risk depends on them. Then fix source access and evidence retrieval before the first occurrence you intend to rely on. Documentation and wording still matter, but a polished policy cannot create a missed operating record.
For each fix, record the date the new procedure began, the owner who ran it, the first real result, and the reviewer who checked it. Keep exceptions and failed tests visible. If a Type 2 period is already under way, do not backdate work or treat a later fix as proof that an earlier control occurred. Discuss the period impact with the CPA firm.
The AICPA description criteria are used to prepare and evaluate management’s description of the system. If the gap analysis changes the service boundary, providers, or control story, carry that correction into the description rather than leaving two versions of the system in your records.
When is the analysis done?
Close a finding only when the owner completes the fix and another person can check the result against the stated closure test. Leave a decision trail for accepted scope exclusions and unresolved work. Reopen the analysis after a material change to the service, vendor set, system access, control procedure, or report plan.
Use the audit readiness checklist later to test the exact date or period, management documents, evidence coverage, and Type 2 populations before fieldwork. That gate asks whether management can support the proposed examination; it does not issue the report or decide whether evidence is sufficient.
FileGRC can hold proposed scope, controls, owners, gap decisions, and safe evidence references in a Git-native GRC workspace. JSON holds structured records, Markdown holds long-form work, and Git supplies the change history. Starter records are proposals, not compliance claims. Your source systems run the controls and produce their records; management verifies the facts, and the CPA firm performs the examination.
Run your SOC 2 program as files in Git.
Keep policies, controls, work, and evidence indexes in a repository your team and agents can inspect. Add optional FileGRC Autopilot email and Slack reminders to keep work moving.
Frequently asked questions
What is a SOC 2 gap analysis?
It is management's comparison of the planned SOC 2 scope and criteria with the controls the company has designed, operates, and can support with source records. Each gap needs an owner, action, deadline, and a check that the fix works. It is preparation, not a SOC 2 examination.
When should a startup run a SOC 2 gap analysis?
Run an initial analysis after defining the service boundary and proposed criteria, before relying on a candidate Type 2 evidence period. Recheck after a material change in the service, systems, vendors, controls, or report goal. Confirm the proposed scope and timing with the CPA firm.
Is a missing policy the same as a missing control?
No. A missing policy is a documentation or approval gap. A missing control means the required activity is not designed or operating. A control may operate without a retrievable record, which creates a separate evidence gap. Record these separately so the fix addresses the actual problem.
Can a readiness score show that we will pass SOC 2?
No. A percentage can hide a critical missing control, an out-of-scope system, or an untested evidence source. Management can track open work, but the CPA firm determines its examination procedures, evaluates evidence and exceptions, and issues the report.
Can we close a Type 2 gap by creating a record later?
You can fix a process and preserve the date it began working. Do not backdate a control, approval, or evidence record to imply it operated earlier. Discuss any gap inside the planned period with the CPA firm because later work does not recreate past operation.
Does FileGRC perform the gap analysis for us?
FileGRC can keep proposed scope, controls, owners, evidence references, and reviewable changes in a Git-native GRC workspace. Management must verify actual control operation and resolve gaps in the source systems. A CPA firm performs the SOC 2 examination and judges evidence.