A health system asks for your SOC 2 report before they'll even look at your product demo. That's the moment most digital health vendors realize compliance isn't optional paperwork, it's the gate standing between them and a signed contract. If you're wondering how to get SOC 2 compliance, you're likely already feeling that pressure from a prospect or investor.

Getting certified means walking through a defined sequence: picking your Trust Services Criteria, running a readiness assessment, closing gaps, completing a Type 1 audit, then sustaining controls for months before your SOC 2 Type 2 certification audit. There's no shortcut around the audit itself, but there's a lot you can do to shrink the timeline and the cost.

This guide walks through each stage of the process, from scoping your audit to choosing an auditor, what the whole thing typically costs, and where vendors integrating with EHR systems like EPIC run into extra compliance demands around HIPAA and SMART on FHIR. If you're building healthcare software, you'll see how these requirements stack, and where a managed compliance path can save you months of internal effort.

What SOC 2 compliance actually involves

SOC 2 compliance isn't a certificate you hang on the wall. It's an attestation report written by an independent CPA firm, following standards set by the American Institute of Certified Public Accountants (AICPA), stating whether your organization's controls meet a defined set of criteria over a specific period. Vendors say "SOC 2 certified" out of habit, but technically you're attested or reported on, not certified. What a health system's security team actually cares about is the report content, the controls you've documented, and whether an auditor tested them, not a logo on your website.

The five Trust Services Criteria

Every SOC 2 audit is scoped against the AICPA's Trust Services Criteria (TSC). Security is mandatory for every report. The other four are optional, and you pick them based on what your product does and what your customers ask for.

Criterion	What it covers
Security	Protection against unauthorized access, required for all SOC 2 reports
Availability	System uptime, monitoring, and disaster recovery
Processing Integrity	Accuracy and completeness of data processing
Confidentiality	Protection of sensitive business and client information
Privacy	Handling of personal information, collection through disposal

Healthcare vendors handling patient data almost always add Confidentiality, and sometimes Availability if their app supports clinical decision-making that can't tolerate downtime.

Type 1 vs. Type 2 reports

A Type 1 report evaluates whether your controls are designed correctly on a single date. A Type 2 report goes further: it evaluates whether those same controls actually operated effectively over an observation window, typically three to twelve months. Type 2 requires an auditor to pull evidence across that entire period, not just check a policy document once.

A Type 1 report proves your controls exist; a Type 2 report proves they worked, and that's the one health systems actually ask for.

Most enterprise buyers, including hospital systems evaluating a vendor for EPIC integration, will only accept a Type 2 report. Some vendors start with a Type 1 to get a report in hand quickly, then roll straight into the Type 2 observation period. That sequencing is common, but understand going in that a Type 1 alone rarely closes a deal with a health system procurement team.

Who actually issues the report

Only a licensed CPA firm operating under AICPA attestation standards can issue a SOC 2 report. You can't self-certify, and a security consultant without CPA licensure can't sign off on the final report even if they did all the remediation work with you. That firm will test your evidence, interview your staff, and write an opinion letter that goes into the final report package.

For healthcare vendors specifically, SOC 2 doesn't replace HIPAA, it complements it. A SOC 2 report demonstrates your security and confidentiality controls to a business audience, while HIPAA compliance addresses your legal obligations around protected health information. Health systems reviewing an EPIC-integrated app will typically want to see both a signed Business Associate Agreement and a current SOC 2 Type 2 report before they let your application anywhere near a patient chart.

Step 1. Choose your trust services criteria and report type

Scoping comes before anything else. Before you touch a single control, decide which Trust Services Criteria apply to your product and which report type you're actually pursuing. Get this wrong and you'll pay an auditor to test controls nobody asked for, or worse, discover mid-audit that your scope missed something a prospect requires.

Start with what your customers ask for

Nothing beats direct evidence here. Pull up the last five security questionnaires or vendor risk assessments you've received from prospects and look for patterns. If health systems keep asking about uptime guarantees for a clinical workflow tool, add Availability. If you're processing PHI and storing it beyond the transaction itself, Confidentiality is almost automatic. Security is non-negotiable in every SOC 2 report, so your real decision is which of the other four criteria to layer on top.

Scope your SOC 2 report around what your customers will actually ask to see, not around what looks impressive on a compliance page.

Don't add criteria speculatively. Every additional criterion means more controls to design, more evidence to collect, and a longer, more expensive audit. A ten-person digital health startup rarely needs Processing Integrity unless its core function is financial or clinical calculation accuracy that customers explicitly rely on.

Decide between Type 1 and Type 2 early

Your report type decision shapes your entire timeline. A checklist for this decision:

• Do you have a signed contract or LOI waiting on a SOC 2 report? If yes, a Type 1 can buy you time while you build toward Type 2.
• Is your buyer a hospital system or large enterprise? They'll almost certainly require Type 2 before final signature.
• Have your controls been running consistently for at least three months? If not, you're not ready for a Type 2 observation window yet.
• Are you under investor pressure for a compliance milestone? A Type 1 satisfies that faster than waiting for a full Type 2.

Most healthcare vendors we see land on the same sequence: a Type 1 report to unblock early deals, followed immediately by a Type 2 observation period once controls have had time to run.

Document your scoping decision

Write down your rationale for the criteria and report type you've chosen, even informally. Your auditor will ask why you scoped the engagement the way you did, and a documented answer signals that this was a deliberate business decision, not a guess. This document also becomes useful later when a health system's procurement team asks why Confidentiality is in scope but Availability isn't, a question that comes up more often than you'd expect once you're negotiating an EPIC integration contract.

Step 2. Run a gap analysis against SOC 2 requirements

Once you know your scope, the next move is finding out how far you are from meeting it. A gap analysis compares your current policies, technical controls, and documentation against every criterion in scope and flags what's missing. Skip this step and you'll find out about missing controls from your auditor, at auditor rates, months into a paid engagement. Most vendors treat this as the point where how to get SOC 2 compliance stops being abstract and starts turning into a real project plan.

Map controls to your chosen criteria

Build a control matrix that lists each requirement under your selected Trust Services Criteria, then rate your current state against it. A simple structure works fine for a first pass:

Control area	Current state	Gap severity
Access control (MFA, least privilege)	Partial, no MFA on admin accounts	High
Change management	Documented but not enforced	Medium
Incident response plan	None exists	High
Vendor risk management	Ad hoc reviews only	Medium
Encryption at rest and in transit	Fully implemented	None

Rating severity this way lets you prioritize remediation instead of tackling gaps in whatever order you notice them.

Decide who runs the assessment

You can run a gap analysis internally using AICPA's published criteria, or bring in a readiness assessor who's done this dozens of times and knows what auditors flag most often. Internal reviews save money but often miss controls that look fine on paper and fail under audit scrutiny, things like access reviews that happen but aren't logged, or backups that run but were never tested with a restore. A paid readiness assessment typically costs a few thousand dollars and often pays for itself by catching issues before your formal audit clock starts.

A gap analysis that misses a control doesn't make the problem disappear, it just moves the bad news to a more expensive point in the process.

Prioritize gaps by audit risk, not convenience

Sort your findings by what would actually block a clean audit opinion, not by what's easiest to fix first. Missing incident response documentation and absent access reviews are the two gaps that most often derail a first-time SOC 2 audit, so start there even if they're harder than smaller items like updating a stale org chart. For healthcare vendors specifically, check your gap analysis against HIPAA-adjacent requirements too, since access logging and breach notification procedures tend to overlap heavily between the two frameworks, and closing one gap often closes the other.

Step 3. Remediate gaps and implement controls

Once your gap analysis names the problems, the real work starts. Remediation means turning gap findings into actual policies, technical configurations, and documented processes that an auditor can test. This step usually takes longer than teams expect, especially for a first-time SOC 2 effort, because half the work isn't building new tools, it's writing down what you already do so it holds up as evidence.

Fix technical gaps first

Start with controls that require infrastructure changes, since those take the longest to implement and stabilize. Multi-factor authentication on admin accounts, encryption at rest and in transit, centralized logging, and automated backup testing all fall into this category. If you're running on AWS, Azure, or GCP, most of these controls map directly to native security services those providers already document for compliance purposes, so check your cloud provider's own security documentation before building anything custom.

Remediation isn't about buying new tools, it's about making your existing security work provable to someone who wasn't in the room when you built it.

Write the policies your controls need

Every technical control needs a paired policy document that an auditor can read and match against what they observe. At minimum, plan to draft:

• Access control policy, covering provisioning, review cadence, and deprovisioning
• Incident response plan, with defined roles and escalation timelines
• Change management policy, describing how code and infrastructure changes get approved
• Vendor risk management policy, covering how you assess subprocessors
• Data retention and disposal policy, especially important if you're touching PHI

Don't copy a generic template and leave it unedited. Auditors notice when a policy references processes your team doesn't actually follow, and a mismatch between paper and practice is one of the fastest ways to draw follow-up questions during fieldwork.

Build the habits your controls depend on

Controls fail Type 2 audits when they exist on day one and quietly stop happening by month three. Access reviews, log monitoring, and vendor reassessments all need an owner and a calendar, not just a policy stating they should happen. Assign each recurring control to a specific person, put the review cadence on a shared calendar, and track completion somewhere your future self can find it.

For healthcare vendors, this stage is where HIPAA safeguards and SOC 2 controls should get implemented together rather than sequentially. Access logging built for HIPAA's audit control requirement, for example, often satisfies a SOC 2 Security criterion with zero extra engineering work if you design it once with both frameworks in mind.

Step 4. Collect and organize your audit evidence

Once controls are running, you need proof they're running, and that proof is what an auditor actually tests. Evidence collection is the unglamorous middle of a SOC 2 project: screenshots, exported logs, signed policy acknowledgments, ticket histories. Vendors who wait until the week before fieldwork to gather this material almost always scramble, because a Type 2 audit asks for evidence spanning your entire observation window, not a single snapshot.

Build an evidence inventory before the audit starts

Map every control in scope to the specific artifact that proves it happened, and note how often you need to capture it. A basic inventory looks like this:

Control	Evidence type	Collection frequency
Access reviews	Signed review log or ticket	Quarterly
MFA enforcement	Admin console screenshot or policy export	At audit start and end of window
Incident response	Tabletop exercise notes, any real incident tickets	As they occur
Backup testing	Restore test logs	Monthly
Vendor risk reviews	Completed vendor questionnaires	Annually or per new vendor

Building this table early tells you exactly what to automate versus what to track manually, and it becomes the checklist your auditor will effectively be grading you against.

Automate what you can

Manual evidence collection is where SOC 2 projects quietly fall apart. Someone forgets to export the access review, a screenshot gets taken from the wrong environment, or a log rotates out before anyone saves it. Where possible, set up automated exports from your identity provider, cloud logging service, and ticketing system so evidence generates itself on a schedule instead of depending on someone's memory in month seven of a twelve-month window.

Evidence you have to reconstruct after the fact is evidence an auditor will trust less than evidence that was captured automatically as it happened.

Centralize storage so nothing goes missing

Scattered evidence across email threads, personal drives, and Slack messages is the fastest way to lose a paper trail. Pick one location, whether that's a dedicated compliance folder, a GRC tool, or even a well-organized shared drive, and require every control owner to drop evidence there on the same cadence you defined in your inventory. For healthcare vendors, this stage matters even more, since your evidence set often needs to demonstrate HIPAA-adjacent controls like PHI access logging alongside standard SOC 2 artifacts, and an auditor reviewing an EPIC-integrated app will expect that overlap to be documented cleanly, not assembled after the fact from scattered sources.

Step 5. Select an auditor and complete the SOC 2 audit

With controls running and evidence flowing into a central location, you're ready for the part that actually produces the report: the audit itself. Choosing an auditor matters more than most first-time vendors expect, since the firm you pick shapes both the cost and the smoothness of fieldwork. Only a licensed CPA firm can issue the final opinion, but within that pool there's a wide range in healthcare experience, turnaround time, and how much hand-holding they offer during the process.

Vet auditors on healthcare fluency, not just price

Ask every candidate firm how many healthcare or health-tech clients they've audited, and specifically whether they've reviewed vendors integrating with EHR systems like EPIC. An auditor unfamiliar with PHI handling will spend extra billable hours getting oriented to your environment, and that cost lands on you. A short comparison worth running before you sign an engagement letter:

Factor	Why it matters
Healthcare client history	Fewer clarifying questions, faster fieldwork
Typical turnaround time	Affects when you can hand a report to prospects
Pricing structure	Fixed fee vs. hourly changes your risk exposure
Communication style	Determines how much friction you'll feel during fieldwork

The cheapest auditor on your shortlist often costs the most once you account for delays caused by unfamiliarity with healthcare compliance.

Know what fieldwork actually looks like

Once you sign, the auditor requests your evidence inventory, interviews control owners, and samples specific instances rather than reviewing every ticket or log line. For a Type 2 audit, expect them to pull evidence from multiple points across your observation window, not just the start and end dates, so gaps in the middle of the period will surface. Fieldwork for a first Type 2 report commonly runs four to eight weeks depending on how organized your evidence is going in.

Respond to findings before the report gets written

Auditors typically flag exceptions during fieldwork rather than saving them for the final letter, giving you a window to explain context or, in some cases, fix a minor issue before the report closes. Treat every auditor question as a chance to demonstrate the control actually works, not as an inconvenience to brush past. Once fieldwork wraps, the AICPA's attestation standards require the firm to issue a written opinion, either unqualified, qualified, or adverse, and an unqualified opinion is the one health system procurement teams expect to see before they'll sign off on an EPIC integration.

Step 6. Maintain compliance after you get your report

Getting your report signed doesn't end the work, it just starts a new cycle. A SOC 2 Type 2 report covers a fixed observation window, and health system buyers expect a current report, not one from eighteen months ago sitting in a shared drive. Treat compliance as an ongoing operating rhythm rather than a project with a finish line, because your next audit clock is already running the moment the last one closes.

Keep your control owners active year-round

Hold your assigned control owners to the same cadence you built during remediation. Quarterly access reviews, monthly backup tests, and annual vendor reassessments don't pause just because the audit is over. If anything, this is where most second-year vendors get caught, because the pressure of an active audit disappears and evidence collection quietly slips. Keep the same calendar reminders and ownership assignments running, and treat any missed cadence as a control failure worth investigating immediately, not a minor scheduling slip.

Compliance doesn't fail on audit day, it fails in the quiet months when nobody's checking whether the controls still run.

Plan your next observation window immediately

Most vendors renew on an annual cycle, with a new Type 2 observation window starting right where the last one ended. Gaps between reports raise red flags for procurement teams, since a lapsed report suggests controls stopped running rather than just paperwork lapsing. Build your renewal timeline backward from your busiest sales season, since a report that expires mid-negotiation with a health system can stall a deal that was otherwise ready to close.

Update controls as your product and infrastructure change

New features, new subprocessors, and new infrastructure all shift your risk surface, and your controls need to keep pace. A checklist worth revisiting each quarter:

• Have you added any new vendors or subprocessors handling customer data?
• Has your infrastructure changed providers or added new services since the last audit?
• Have you launched features that touch PHI in new ways?
• Has your team grown enough that access provisioning needs a formal review?
• Are your incident response contacts and escalation paths still accurate?

Answering yes to any of these means updating your control documentation before your next audit, not during it.

Watch for HIPAA and SMART on FHIR drift

Healthcare vendors face an extra layer here, since HIPAA obligations and SMART on FHIR integration requirements evolve alongside your SOC 2 scope. Review your Business Associate Agreements annually alongside your SOC 2 renewal, and confirm your EPIC integration still meets current SMART on FHIR specifications, since EHR vendors update their standards more often than most compliance teams track on their own.

Where to go from here

Getting SOC 2 compliance is a sequence, not a sprint: scope your criteria, find your gaps, remediate, gather evidence, survive fieldwork, then keep the whole system running long after the auditor leaves. None of these steps disappear just because you're moving fast, but the order you tackle them in determines whether you're ready when a health system asks for your report.

If you're building a healthcare product that also needs to integrate with EPIC, that SOC 2 work runs parallel to a separate technical lift: SMART on FHIR development, App Orchard submission, and ongoing maintenance of the integration itself. That's the piece most teams underestimate, and it's exactly what stalls contracts even after compliance is squared away.

You don't have to build that integration from scratch while your compliance team handles the rest. See how VectorCare gets your EPIC integration live in weeks instead of months, fully SOC 2 and HIPAA aligned from day one.