SOC 2 Type II for Healthcare SaaS: What the Audit Actually Tests

Healthcare buyers stopped treating SOC 2 as a nice-to-have somewhere around 2023. Today a hospital procurement team will ask for the report before they will take a second call. What most engineering teams get wrong is not whether to do it — it is assuming SOC 2 is a security review. It is not. It is an audit of whether you actually did, every day for months, the things your policies say you do.

1. Why SOC 2 Became a Healthcare SaaS Requirement

SOC 2 is not a law. Nobody fines you for lacking one. It is an attestation report issued by a licensed CPA firm under AICPA standards, saying that an independent auditor examined your controls and formed an opinion about them. That voluntary status is exactly why it spread so fast: procurement teams needed a way to compare vendors without running their own security review of every one, and SOC 2 became the shared vocabulary.

In healthcare specifically, three things converged. Hospital and health-plan security reviews got formalised into standard questionnaires that have a SOC 2 line item. Cyber-insurance underwriting started asking for it. And the number of small digital-health vendors touching PHI grew faster than any buyer’s ability to assess them individually. The result is that a healthcare SaaS without a SOC 2 report now fails a procurement gate that has nothing to do with whether the product is secure.

2. What SOC 2 Type II Actually Requires for Healthcare

Strip away the framework language and a Type II examination asks you for three things.

A written description of your system. What the service does, what infrastructure it runs on, who the users are, where the data boundaries sit, and which controls you claim. This is management’s assertion, not the auditor’s — you write it, and you are accountable for it being accurate.

Controls mapped to Trust Services Criteria. For each criterion in scope, a stated control that addresses it. Not a tool, not a vendor — a control: a thing a person or system does, on a defined cadence, with an owner.

Evidence that the controls operated across the whole window. This is the part that separates Type II from every other compliance exercise. The auditor samples. If your policy says access reviews happen quarterly and the window is nine months, they will ask for three access reviews with dates, participants, and outcomes. Two out of three is a finding.

That third requirement is where healthcare teams get hurt, because it is retroactive. You cannot decide in November to have a clean Type II covering the year. The evidence either exists for those months or it does not.

3. The Five Trust Services Criteria — and Which Ones to Scope

SOC 2 is organised around five Trust Services Criteria. Only one is mandatory.

The Security criterion — usually called the Common Criteria, referenced as CC1 through CC9 — covers control environment, communication, risk assessment, monitoring, access controls, change management, and incident response. It is the bulk of the work. The other four add discrete control sets on top.

Healthcare teams routinely over-scope here, and it is expensive. Scoping all five because it sounds more impressive adds audit fees, remediation work, and ongoing evidence burden without closing a single extra deal. Ask your three largest prospects what their security review actually requires. In our experience most healthcare procurement asks for Security, sometimes Availability, and almost never Processing Integrity.

One genuine exception: if your product does clinical calculation — dosing, risk scoring, eligibility determination — Processing Integrity is worth scoping, because it maps to a question buyers will ask anyway.

4. Type I vs Type II: Which One Closes Deals

Type I is a point-in-time opinion: as of a specific date, were the controls suitably designed. Type II is an over-a-period opinion: across an observation window, did those controls operate effectively.

The common path is Type I first to unblock a pilot, then Type II. That works. What does not work is treating Type I as a milestone that means you are close — a clean Type I says nothing about whether you can sustain the controls, and sustaining them is the entire content of Type II.

5. SOC 2 vs HIPAA vs HITRUST in Healthcare

These three get conflated constantly, and they answer different questions.

HIPAA is US law. It applies to covered entities and business associates handling PHI, it is not optional, and there is no certificate at the end — you are compliant or you are exposed. Our HIPAA guide for startups covers what actually matters at the beginning.

SOC 2 is a voluntary attestation about your controls, issued by an auditor, used as a procurement artifact. It is not healthcare-specific.

HITRUST CSF is a certifiable framework built to harmonise HIPAA, SOC 2, ISO 27001, and others into one control set. Some large hospital systems prefer or require it. It costs meaningfully more and takes longer.

The overlap is real enough to exploit. The audit-logging architecture that satisfies HIPAA is close to what SOC 2 CC7.2 expects; we go into the specifics in our guide to what HIPAA audit logs must capture. Encryption controls likewise — see PHI encryption requirements. If you also handle EU patient data, GDPR for US healthcare apps is the fourth column, and it does not fold as neatly.

6. What SOC 2 Type II Costs and How Long It Takes

Numbers vary by scope, auditor, and how much remediation you need. As of 2026 the market ranges look roughly like this:

• Audit fees: from around 15,000 USD for a small firm doing a Security-only Type I, up to 80,000 USD and beyond for a Big Four firm examining all five criteria under Type II.
• Compliance automation platforms: 10,000–50,000 USD per year for tools like Drata, Vanta, Secureframe, or Sprinto. These automate evidence collection, which is the actual recurring burden.
• Internal engineering time: 200–600 hours across an audit cycle for evidence collection, remediation, and auditor interaction. This is the cost line teams consistently forget, and it is usually the largest one.
• Penetration test: most auditors expect an annual third-party pen test. Budget separately.

On timing: the observation window is the floor. A 6-month window plus fieldwork and report issuance means roughly 8 months from the day your controls start operating cleanly to the day you have a report in hand — and that assumes you were already operating them. Teams that begin remediation at kickoff should add 2–4 months before the window even opens.

7. The Controls Engineers Actually Have to Build

Most SOC 2 content is written for compliance managers. Here is the engineering-side list — the things that require code or infrastructure rather than a policy document.

• Audit logging with integrity. Append-only, server-side timestamps, actor identity, action, resource, and old/new values. Retained for the full window at minimum.
• Anomaly alerting, not just log collection. CC7.2 expects detection and response. Logs nobody reviews are a deficiency, not a control.
• Role-based access control with reviewable state. You must be able to produce, on demand, who had access to what on a given date.
• Automated deprovisioning. SCIM or equivalent, wired to your identity provider, so termination revokes access same-day without a human remembering.
• Change management enforcement in CI. Branch protection, required reviews, no direct pushes to production. The evidence is the PR history — make it airtight rather than reconstructing it later.
• Backup with tested restore. Not backup configuration. An actual restore, performed on a schedule, with a written result.
• Encryption in transit and at rest, with documented key management and rotation.
• Vendor inventory with evidence of review, not just a list with a SOC 2 checkbox.

If you are building the underlying application rather than retrofitting one, most of this is architecture that is cheap on day one and expensive in year two. VertiComply generates healthcare applications with access control, audit logging, change tracking, and backup infrastructure already wired in — the same controls SOC 2, HIPAA, and HITRUST all ask about from different angles. Our guide to building a HIPAA-compliant healthcare app covers the architecture in depth.

8. Six Findings That Fail Healthcare SOC 2 Audits

These are the recurring ones. None are exotic.

1. Type I passed, Type II failed on access reviews. The control was designed to run quarterly and ran sporadically, with no evidence trail. This is the most common Type II failure by a wide margin.
2. Vendor management with no evidence of actual review. The inventory exists. The tiering exists. What is missing is proof anyone read a vendor’s SOC 2 report or acted on it.
3. Change management bypassed under pressure. Hotfixes pushed directly, emergency tags that skip review, merges without approval. Auditors sample production changes and find these immediately.
4. Logging without monitoring. Logs stream into a SIEM that nobody has opened in months. No alerting rules, no documented response.
5. Backup restore tested on paper only. Policy says quarterly restore tests; engineering last restored a backup 18 months ago. Easy for an auditor to verify, and easy to fail.
6. Offboarding that takes days. Termination routes through HR queues and IT tickets, leaving access live for 3–7 days. SOC 2 expects same-day revocation.

Notice how many are operational rather than technical. That is the pattern: healthcare teams generally build reasonable systems and then fail to prove they ran them consistently.

9. How to Verify Someone Else’s SOC 2

The reverse problem comes up constantly in healthcare procurement — you need to confirm a billing platform, EHR connector, or messaging vendor is genuinely SOC 2 compliant. A logo on a trust page is not evidence. Ask for these:

• The actual report, under NDA. A SOC 2 report is not public. If a vendor only offers a certificate or a badge, they may hold a SOC 3 or nothing at all.
• The report type and period. Type II with a window ending within the last 12 months. An expired Type II is a yellow flag; a Type I marketed as “SOC 2 certified” is a red one.
• The auditor’s opinion. Read it. Qualified opinions exist and vendors do not volunteer them.
• The scope. Which criteria, and which systems. A report covering the marketing site and not the product is not unheard of.
• Exceptions and management responses. Findings are normal. Findings with no remediation plan are not.
• Complementary user entity controls. The list of things the report assumes you do. Most people skip this section, and it is the one that transfers work onto your side.

Note that terminology matters here and vendors blur it deliberately: SOC 2 is an attestation, not a certification. Nobody is “SOC 2 certified.” A vendor using that phrase is either imprecise or hoping you are.

If you would rather assess your own readiness before commissioning an audit, our free SOC 2 readiness checker walks the 24 questions an auditor works through across all five criteria and returns your gaps by category — no account required to see the result. It scores control design, which is what you can control before the window opens; only the audit itself tests operating effectiveness. The SOC 2 framework reference has the criteria breakdown, and HITRUST and ISO 27001 sit alongside it if a buyer has asked for those instead.

10. Frequently Asked Questions

What are the SOC 2 Type II requirements for healthcare?

The same five Trust Services Criteria that apply to any service organisation, with Security mandatory and the other four scoped to your commitments. There is no healthcare-specific SOC 2 variant. What differs in healthcare is the surrounding context: buyers usually want SOC 2 alongside HIPAA compliance, often ask about PHI handling in the system description, and sometimes prefer HITRUST CSF instead. The audit itself tests whether your stated controls operated effectively across a 6-12 month observation window.

Is SOC 2 required for healthcare SaaS?

Not by law. SOC 2 is voluntary and carries no regulatory penalty. In practice it functions as a procurement requirement: hospitals, health plans, and enterprise healthcare buyers routinely require a SOC 2 Type II report during vendor due diligence, frequently alongside HIPAA attestations. The commercial cost of not having one is losing deals, not paying fines.

How much does a SOC 2 Type II audit cost in 2026?

Audit fees range from roughly 15,000 USD for a small firm doing a Security-only Type I to 80,000 USD and above for a Big Four firm examining all five criteria under Type II. Add 10,000-50,000 USD per year if you use a compliance automation platform, budget for an annual penetration test, and expect 200-600 hours of internal engineering time across the cycle. That engineering time is usually the largest real cost and the one most often left out of the budget.

What is the difference between SOC 2 Type I and Type II?

Type I evaluates whether controls are suitably designed at a single point in time and takes 4-8 weeks. Type II evaluates whether those controls operated effectively across a period, typically 6-12 months, and requires operational evidence for the whole window. Type II is what enterprise healthcare procurement expects. Type I is useful to unblock pilots but does not substitute for it.

Does SOC 2 cover HIPAA?

No. They overlap substantially on access control, audit logging, encryption, and incident response, but SOC 2 is an auditor attestation about controls you chose to describe, while HIPAA is a legal obligation with specific required safeguards, breach notification duties, and business associate agreements. A SOC 2 report does not make you HIPAA compliant and a HIPAA program does not produce a SOC 2 report. Run them as one controls program with two outputs.

How do I verify a vendor is SOC 2 compliant?

Request the full report under NDA rather than accepting a badge or trust-page logo. Check that it is Type II, that the observation period ended within the last 12 months, that the scope covers the product you are buying rather than adjacent systems, and that the auditor issued an unqualified opinion. Read the exceptions section and the complementary user entity controls, which list the responsibilities the report assumes you handle on your side.

How long does it take to get SOC 2 Type II?

Plan on roughly 8 months minimum from clean controls to report in hand: a 6-month observation window plus 4-8 weeks of fieldwork and report issuance. If you are starting from scratch, add 2-4 months of remediation before the window opens, because evidence generated during remediation does not count. Teams that turn on evidence collection early, even with imperfect controls, shorten this considerably.

Can we rely on our cloud provider’s SOC 2?

Partially. AWS, GCP, and Azure publish SOC 2 reports covering the controls they manage: physical security, network segmentation, hypervisor isolation. You inherit those. You remain responsible for everything in your half of the shared responsibility model, which is application security, access management, change control, data classification, and monitoring. Auditors expect you to document that split explicitly.

Last reviewed 12 August 2026. Cost and timeline figures are market ranges observed in 2026 and vary substantially by auditor, scope, and starting posture — treat them as planning estimates, not quotes. SOC 2 is an AICPA attestation engagement, not a certification.