A SOC 2 gap analysis is the single most effective way to find out where your security controls fall short before an auditor does it for you. For healthcare vendors building integrations with EPIC EHR systems, SOC 2 compliance isn't optional, it's a prerequisite that health systems expect before they'll even consider your product. Skipping this step, or doing it poorly, can mean months of rework and blown timelines right when you're trying to close contracts.

The problem is that most vendors underestimate what's involved. SOC 2 covers five Trust Services Criteria, security, availability, processing integrity, confidentiality, and privacy, and each one contains dozens of control points where gaps can hide. Without a structured approach, you're essentially guessing at your readiness. A proper gap analysis gives you a clear, prioritized list of what needs fixing and how far you are from audit-ready.

At VectorCare, we handle SOC 2 compliance as part of our managed SMART on FHIR platform, so healthcare vendors launching into EPIC don't have to build and maintain those controls from scratch. But whether you're using a platform like ours or managing compliance independently, understanding the gap analysis process is critical to making informed decisions about your security posture.

This guide walks you through every step of conducting a SOC 2 gap analysis, from scoping your environment and mapping controls to identifying common deficiencies and preparing for your formal audit. You'll also find a practical checklist to keep the process on track.

What a SOC 2 gap analysis covers

A SOC 2 gap analysis compares your current security controls against the American Institute of CPAs (AICPA) Trust Services Criteria and identifies every place where your environment falls short of what an auditor will expect to see. The analysis doesn't just flag missing policies. It surfaces gaps in technical controls, vendor management practices, access provisioning, incident response procedures, and evidence collection, giving you a complete picture of your actual compliance posture before any auditor steps in.

For healthcare vendors building integrations with EPIC, this is especially high-stakes work. Health systems review your SOC 2 report as part of vendor due diligence, and gaps discovered during the audit carry far more weight than gaps you found and remediated yourself before the audit began. Running the analysis early puts you in control of that narrative.

The Five Trust Services Criteria

The AICPA defines five Trust Services Criteria (TSC) that form the backbone of any SOC 2 report. Security, also called the Common Criteria, is the only mandatory category. You select the remaining four based on what your product does and the commitments you've made to customers in your service agreements.

Every SOC 2 audit starts with the Security category, and gaps there will affect your entire report regardless of which additional criteria you select.

Trust Services Criterion	What it covers
Security (required)	Logical and physical access controls, encryption, monitoring, and incident response
Availability	System uptime, performance monitoring, and disaster recovery
Processing Integrity	Accuracy and completeness of data processing
Confidentiality	Protection of data designated as confidential
Privacy	Collection, use, retention, and disposal of personal information

For healthcare vendors integrating with EPIC, Security and Availability are the criteria health systems scrutinize most closely. Many contracts also trigger the Privacy criterion because your application handles protected health information (PHI) that flows through FHIR APIs.

What the Analysis Actually Measures

A SOC 2 gap analysis doesn't produce a pass/fail score. Instead, it produces a gap register: a structured list of every control point where your current state doesn't match the required state. Each item in the register captures the control reference, what the auditor expects, what you have in place today, and the severity of the shortfall.

The analysis evaluates controls across four dimensions. Policy documentation asks whether you have written policies covering each control requirement. Technical implementation asks whether the control is actually active in your systems. Evidence collection asks whether you can prove the control is operating consistently. Operational consistency asks whether what's happening in practice matches what your policies say. A control that exists on paper but isn't enforced in your environment counts as a gap just as much as a missing policy does.

The Scope of Evidence You Need to Collect

Auditors don't accept your word that controls are working. They require documented, time-stamped evidence that each control operated during the audit period. Before you can close a gap, you need to know exactly what type of evidence the corresponding control requires.

Common evidence types include:

• Access review logs showing quarterly user access reviews were completed
• Vulnerability scan reports with remediation dates for critical findings
• Change management tickets demonstrating an approval workflow was followed
• Encryption configuration screenshots from cloud infrastructure dashboards
• Vendor security assessments for third parties who process your data
• Incident response records documenting how security events were handled

Knowing what evidence each control demands lets you build collection processes into your daily operations rather than scrambling to reconstruct records when your audit window opens.

Step 1. Define scope and choose Type 1 or Type 2

Scope is the foundation of your entire SOC 2 gap analysis. Before you can identify gaps, you need to define exactly which systems, teams, and services fall inside the audit boundary. Auditors will test only what you've declared in scope, and health systems reviewing your report will scrutinize that boundary closely. Starting with a vague or overly broad scope wastes remediation effort on systems that don't affect your customers, while a scope that's too narrow can undermine the report's credibility.

Setting Your Scope Boundary

Your scope should capture every system that stores, processes, or transmits customer data as part of the service you're selling. For healthcare vendors building EPIC integrations, this typically includes your FHIR API layer, any cloud infrastructure hosting your application, your identity provider, and the internal tools your team uses to manage customer environments.

Walk through the following questions to draw a defensible scope boundary:

• Which cloud accounts or data centers run production workloads?
• Which personnel roles have access to production data or configuration?
• Which third-party vendors process customer data on your behalf?
• Which internal systems feed data into or out of your production environment?
• Which development or staging systems share network access with production?

Document your answers in a scope statement before you move to any control testing. Auditors expect a written scope statement as part of the evidence package, so drafting it now saves work later.

Type 1 vs. Type 2: Which Report to Target

A Type 1 report captures whether your controls are designed correctly at a single point in time. A Type 2 report evaluates whether those controls operated effectively over an observation period, typically six to twelve months. The distinction matters because health systems increasingly require Type 2 reports before signing contracts.

If you're pursuing SOC 2 for the first time and need a report quickly to support a sales cycle, a Type 1 gives you a credible starting point while your Type 2 observation period runs in parallel.

Choose Type 2 as your end goal from the beginning, even if you plan to issue a Type 1 first. That means implementing controls and evidence collection processes now, rather than retrofitting them once your Type 1 is complete. Every month you operate with functioning controls counts toward your Type 2 observation window.

Step 2. Inventory systems, vendors, and data flows

Once you've locked in your scope, the next job is to document every system, third-party vendor, and data flow that touches customer information within that boundary. Auditors use your inventory to verify that you've identified all the places where controls need to operate. A missing system in your inventory means a missing control in your audit, which translates directly into a finding on your report.

Build Your System Inventory

Your system inventory should capture every asset that processes, stores, or transmits data covered by your SOC 2 scope. For healthcare vendors working with EPIC integrations, this list typically grows longer than expected once you account for logging services, secrets managers, and CI/CD pipelines that touch production credentials.

Document each system using a consistent format:

Field	What to capture
System name	The service or tool name and version where applicable
Owner	The internal team or individual responsible
Data sensitivity	Whether it processes PHI, confidential data, or neither
Hosting location	Cloud provider, region, or on-premises
Access method	How users and services authenticate to the system
In-scope or out	Whether it falls inside your declared audit boundary

Work through this inventory with your engineering and DevOps teams, not just from memory. Engineers often have shadow services or staging environments that share production credentials, and those belong in scope.

Map Your Vendor Relationships

Third-party vendors are one of the most common sources of gaps in a SOC 2 gap analysis. Auditors expect you to maintain a list of every sub-processor or vendor that handles customer data on your behalf, along with evidence that you've reviewed their security posture.

If a vendor breaches your customer data, the auditor will ask whether you performed adequate due diligence before onboarding them.

For each vendor in scope, record the data they access, the contract type, whether a Business Associate Agreement (BAA) is in place if PHI is involved, and when you last reviewed their SOC 2 report or security documentation. Vendors without current SOC 2 reports require an alternative security review, such as a completed security questionnaire, before your audit period closes.

Trace Your Data Flows

Your data flow documentation shows auditors exactly how information enters, moves through, and exits your environment. Draw or diagram the path that customer data takes from the moment it enters your system through any transformations, storage locations, API calls to external services, and final outputs.

Pay particular attention to FHIR API calls that pull patient data from EPIC, since auditors will trace that data's path through your entire stack to confirm encryption and access controls are applied at every hop.

Step 3. Map controls to the trust services criteria

Control mapping is where your SOC 2 gap analysis becomes concrete. You take every system and vendor you documented in Step 2 and match your existing controls against the specific requirements in each Trust Services Criterion. The output is a structured control matrix that shows, for every AICPA requirement, exactly what control you have in place today and whether it fully satisfies the requirement or leaves a gap that an auditor will flag.

Build a Control Mapping Spreadsheet

Your control matrix is the core artifact of the entire gap analysis. Build it as a spreadsheet with one row per AICPA control point and columns that capture your current implementation status, the control owner, and the type of evidence each control requires.

Column	What to capture
Criteria reference	AICPA control ID (e.g., CC6.1, CC7.2)
Requirement description	Plain-language summary of what the auditor expects
Current control	What you have in place today
Control owner	The person or team responsible
Status	Met / Partial / Gap
Evidence required	Log, screenshot, policy document, etc.

Work through the AICPA's Trust Services Criteria document row by row. For each control point, assess whether your current implementation fully meets the requirement, partially meets it, or doesn't exist at all. Assign every gap row an owner immediately so remediation responsibility is clear before you move to the next step.

Handle the Common Criteria First

The Common Criteria, which cover the Security category, apply to every SOC 2 report regardless of which additional criteria you've selected. Completing the Common Criteria mapping before moving to Availability, Privacy, or other categories gives you the broadest picture of your risk exposure and reveals gaps that affect the rest of your report.

Finish your Common Criteria mapping before tackling any additional criteria. Every other category builds on your security foundation, so gaps there compound across the entire report.

When you map controls in the Security category, pay particular attention to logical access controls (CC6.1 through CC6.8) and change management (CC8.1). These two control areas produce the most findings in first-time SOC 2 audits and take the longest to remediate because they typically require both updated policies and technical enforcement changes inside your identity provider or cloud infrastructure settings.

Step 4. Test controls and collect audit-ready evidence

Control mapping tells you what controls should exist. Testing tells you whether those controls actually work the way you documented them. For every control marked "Met" in your matrix, you need to run a test that confirms the control is operating and collect the evidence an auditor would need to verify that independently. A control you can't prove is a gap in the eyes of your auditor, even if the technical implementation is solid.

Run Control Tests Before the Auditor Does

Testing controls before your formal audit lets you surface failures while you still have time to remediate them. For each control in your matrix, define a specific test that confirms the control is active and functioning. Access control tests should include pulling a current user list from your identity provider and verifying that every active account belongs to a current employee with a documented access approval. Change management tests should walk through a recent deployment ticket and confirm it contains an approval, a test result, and a rollback plan.

Run your control tests on a sample of real activity records, not on a demonstration or sandbox environment, because auditors will want to see evidence tied to your actual production systems.

Availability controls require uptime data and incident records from your monitoring platform. Encryption controls require configuration exports or screenshots showing encryption settings are active at rest and in transit. Assign each test to the control owner listed in your matrix, and set a deadline so tests don't stack up at the end of your observation period.

Build an Evidence Collection Template

Your SOC 2 gap analysis produces the most value when you pair it with a structured evidence log that captures exactly what an auditor will request. Use the template below as a starting point and expand it to match your full control matrix.

Control ID	Control description	Test performed	Evidence file	Collection date	Collected by
CC6.1	Logical access restricted to authorized users	Pulled IAM user list and confirmed no inactive accounts	iam-user-export-2026-03.csv	2026-03-31	DevOps lead
CC7.2	Vulnerability scans conducted and reviewed	Ran scanner, reviewed findings, documented remediation	vuln-scan-report-2026-03.pdf	2026-03-28	Security lead
CC8.1	Changes follow approval workflow	Reviewed 10 recent PRs for approvals and test results	change-log-sample-Q1.xlsx	2026-03-30	Engineering lead

Store all evidence files in a centralized, access-controlled repository with a folder structure that mirrors your control matrix. Label each file with the control ID and collection date so nothing gets misplaced when your audit window opens.

Step 5. Prioritize gaps and write a remediation plan

Once your control matrix is complete and your tests have confirmed which gaps are real, you need to turn that gap register into a structured remediation plan. Not all gaps carry the same risk, and treating every item as equally urgent will spread your team too thin. The goal of this step in your SOC 2 gap analysis is to rank each gap by the severity of the exposure it creates and the effort required to close it, then assign owners and deadlines before your audit period opens.

Score Each Gap by Risk and Effort

Scoring gaps lets you sequence remediation work so high-risk, low-effort fixes go first. A missing MFA requirement on your cloud console is both critical and fast to fix, making it a clear priority over rewriting an access control policy that requires legal review. Use a simple two-axis scoring approach to rank every gap in your register.

Assign each gap a risk score from 1 to 3 based on how directly it would cause an auditor to issue a finding or how significantly it exposes customer data. Then assign an effort score from 1 to 3 based on the time and resources needed to close it. Multiply the two scores to get a priority number, and work through your list in descending order.

Gaps that score a 9 on this scale (high risk, high effort) need to start immediately, even if they won't close quickly, because auditors will ask for evidence of active remediation progress.

Build Your Remediation Plan Document

Your remediation plan is a living document that tracks every gap from identification through resolution. Build it as a table that connects directly to your control matrix so owners can update status without hunting across multiple files.

Gap ID	Control ref	Gap description	Risk score	Effort score	Priority	Owner	Target close date	Status
G-01	CC6.1	MFA not enforced on production console	3	1	9	DevOps lead	2026-05-01	In progress
G-02	CC7.2	No formal vulnerability scan schedule	3	2	6	Security lead	2026-05-15	Not started
G-03	CC9.1	Vendor security reviews not documented	2	2	4	Legal/compliance	2026-06-01	Not started

Review this plan weekly with your control owners until all high-priority gaps are closed. Update the status column in real time so you have a clear record of remediation activity that your auditor can review as supporting evidence.

Common SOC 2 gaps that cause audit delays

Even a well-structured SOC 2 gap analysis will surface the same categories of gaps across most first-time audits. Knowing which deficiencies appear most often lets you focus remediation effort on the areas that produce the most audit findings, rather than discovering them when your auditor submits their initial request list and your timeline collapses.

The gaps below don't just delay audits; they often force vendors to restart their observation period, which can cost six months or more in timeline.

Access control and identity management gaps

Logical access controls are the single most common source of audit delays. Auditors test whether you restrict access based on job function, enforce MFA on all privileged accounts, and review active user accounts on a regular schedule. Many vendors have access restrictions configured but cannot produce quarterly access review records that prove those restrictions were consistently maintained throughout the audit period.

The three most frequent access control gaps are:

• No MFA on cloud consoles, code repositories, or identity providers
• Active accounts belonging to former employees or contractors who no longer need access
• No documented access approval process showing that someone with authority approved each user's permissions before they were granted

Fixing these gaps requires both a technical configuration change and a recurring operational process. Enable MFA enforcement at the identity provider level, then build a calendar-based access review task into your security workflow so you generate evidence automatically each quarter.

Vendor management and evidence gaps

Third-party vendor management consistently surfaces as a gap because most teams track vendor relationships informally rather than through a documented process. Auditors will request your vendor inventory, the security assessments you performed before onboarding each vendor, and copies of current SOC 2 reports or security questionnaires for every sub-processor that touches customer data.

Two additional gaps appear frequently across both vendor management and general evidence collection:

• Policies that exist in draft form but were never formally approved or distributed to employees
• Evidence files that are incomplete, mislabeled, or tied to a non-production environment instead of your actual production systems

Both gaps signal to auditors that your controls exist on paper but lack operational maturity, which is exactly the finding that pushes vendors into a second audit cycle.

Next steps for staying audit-ready

Completing a soc 2 gap analysis is not a one-time event. Your controls drift the moment your team ships new infrastructure, onboards a new vendor, or changes access permissions without updating your documentation. Build a quarterly review cycle into your security calendar so you catch new gaps before they compound into audit findings. Schedule access reviews, re-run vulnerability scans, and verify that your evidence repository reflects your current production environment every 90 days.

For healthcare vendors integrating with EPIC, the compliance burden runs deeper than SOC 2 alone. You also need to maintain HIPAA controls, SMART on FHIR standards, and EPIC App Orchard requirements simultaneously, which adds layers of operational overhead that many teams underestimate until a health system contract is on the line. If you want to eliminate that overhead entirely and launch a compliant EPIC integration in weeks instead of months, explore VectorCare's managed SMART on FHIR platform and see how quickly you can go from gap analysis to production.