SOC 2 Type II for Digital Health: A First-Time Customer Field Guide

Updated for 2026, The nine-to-twelve-month first-Type-II window still holds, and every digital health first-time customer call now opens with an AI architecture question alongside the Trust Services Criteria. Pair this guide with our HIPAA AI architecture reference implementation and the AWS Bedrock for healthcare BAA briefing before the auditor's first AI-control question lands. Why your first Type II is harder than your fifth The counter-intuitive thing about a SOC 2 Type II report is that the framework is not the hard part. Trust Services Criteria fit inside a single PDF. The control narratives are repetitive. The evidence asks are predictable. A founder reading the AICPA's published criteria for the first time will conclude, reasonably, that this is a six-month project. The first one is not a six-month project. The first one is nine to twelve months, sometimes longer when an auditor's calendar slips a quarter, and the partners have not yet seen a digital health company on its first Type II finish in less than that without taking on findings the founder later regrets. The reason is structural and worth naming up front, because the founder who understands it will scope correctly and the founder who does not will end the engagement with a report they cannot sell. A first Type II is not the second half of a Type I. It is a different audit shape. A Type I is a point-in-time attestation: on this date, controls existed and were designed to operate. A Type II is an observation-window attestation: across a defined period, typically six months on the first run, twelve thereafter, controls existed, were designed correctly, and operated as designed without exception. The shift from "designed" to "operated" is the entire difference. Designing a control takes a week. Operating a control reliably for six months while the engineering team ships features, the company hires three new engineers, the procurement function turns over, and a vendor migration breaks the access provisioning workflow, that takes the rest of the year. The second Type II is materially easier than the first for three reasons that do not apply to a first-time customer. The control set is already running; the operators already know what evidence the auditor wants and where it lives; and the auditor relationship is established, which means the request list arrives a week earlier and the back-and-forth is shorter by half. None of that is true on the first run. On the first run, the company is simultaneously designing controls, training operators on how to run them, building the evidence-collection muscle, and learning how a specific auditor reads exceptions. For a digital health SaaS in particular, the first Type II is harder than the same first Type II would be for a general-purpose B2B SaaS. A digital health company carries HIPAA obligations on top of the SOC 2 control set, and a serious auditor will probe the boundary between the SOC 2 attestation and the HIPAA Security Rule, not because Type II audits HIPAA, but because the Type II report is going to be read by enterprise health system buyers who will treat it as evidence the company is HIPAA-defensible. Auditors who specialize in healthcare SaaS know how to scope the report so it does that work. Auditors who do not, will not, and the founder finds out when their first enterprise prospect rejects the report on a procurement review. The right way to plan a first Type II is the way the partners plan it with regulated SaaS clients on the readiness side: a 9–12 month project with four named phases, a 36-control work surface, and an auditor selection that happens before the gap remediation rather than after. The 36 controls that drive 80% of audit findings The Trust Services Criteria contain more than 36 individual controls. The full Common Criteria set runs from CC1 (control environment) through CC9 (risk mitigation), and depending on the additional categories the company opts into, Availability, Confidentiality, Processing Integrity, Privacy, the total can run past sixty. The partners do not recommend studying all of them line-by-line on a first Type II. The audit experience has a Pareto shape: a working 36-control subset drives roughly four out of every five findings the partners read across digital health Type II reports. We list them in the order an auditor encounters them. CC1, Control Environment (3 controls). The board's role in security oversight, the entity's commitment to integrity, and the organizational structure with documented security responsibilities. On a first-time engagement, the finding is almost always documentation: the company has a CTO who functions as the security owner, but no written role description, no board charter referencing security oversight, and no organizational chart that shows the reporting line. The fix is paper. The auditor still requires the paper. CC2, Communication and Information (3 controls). The internal security policy is communicated to the workforce; relevant security information is communicated externally; a process exists for reporting security concerns. The finding pattern is the security policy was distributed once, two years ago, to a workforce that has since doubled. New hires never countersigned. The control is not policy authorship; it is policy operation. CC3, Risk Assessment (3 controls). A documented risk assessment exists, is reviewed at a defined cadence, and informs the control design. The first-time finding is the risk assessment is a slide deck the founders made at the seed stage and have not revisited since. Auditors want a living risk register with owners on each risk and dated review evidence for the observation window. CC4, Monitoring Activities (2 controls). The organization monitors control operation and evaluates deficiencies. This is where internal control testing lives, a quarterly attestation that someone other than the operator is checking the control is firing. Most first-timers do not have this; building it during the observation window is the most common timeline-killer. CC5, Control Activities (3 controls). The company has selected and developed control activities that mitigate risks to acceptable levels. This is a wrapper for the more specific items below. Findings here are usually CC6/CC7/CC8 findings surfaced at a higher level. CC6, Logical and Physical Access (8 controls). The single largest finding cluster on a first Type II. Access provisioning, access review, privileged access, password policy, MFA coverage, termination-day deprovisioning, physical access, and encryption posture. Common patterns: a former engineer's GitHub access still active 90 days after termination, an admin account in the production database with no MFA, encryption-at-rest enabled on the primary database but not on the snapshot bucket, MFA enforced on the SSO but not on the break-glass admin path. CC7, System Operations (5 controls). Vulnerability management, monitoring, incident response, change management, and the boundary between change and emergency change. First-time findings concentrate on incident response, the runbook exists but no incident has been tabletop-tested in the observation window, and on emergency change, where engineers who hotfix production at 2 a.m. do not file a retroactive change ticket. CC8, Change Management (3 controls). Authorized changes follow a defined process, are tested before deployment, and are tracked to completion. The finding pattern is the company has a change process for backend and infrastructure changes, but the marketing site, the customer-facing dashboard, and the data pipeline have separate ad-hoc deployment paths. Each path without a change record produces an exception. CC9, Risk Mitigation (2 controls). Risk mitigation activities for business disruptions and vendor risk. This is where vendor management lives, and it is the silent killer covered in its own section below. Confidentiality (2 controls). For a digital health company, confidentiality is almost always in scope. The finding pattern is the company has encryption posture but no data classification policy, so the auditor cannot tell what counts as confidential and what does not. Availability (2 controls). Backup, recovery, and continuity. The first-time finding is the recovery plan exists on paper but has not been exercised in the observation window, so the auditor cannot test that the control operated. That is 36 controls. The rest of the TSC catalog matters and the auditor will test it, but on a first-time digital health Type II, those 36 are where the engagement either succeeds or generates the findings the founder will explain to procurement teams for the rest of the year. Type I to Type II: the six-month observation window timing problem Most first-time digital health customers approach the Type II via a Type I first. The logic is sound: a Type I attestation in month four gives the company a saleable artifact while the observation window for the Type II runs from month four through month ten, with the report landing in month twelve. Sales gets something to send to procurement; the audit clock keeps ticking; the company books revenue against the Type I while finishing the Type II. The timing problem is that the Type I and the Type II observation window are usually scoped in the same engagement letter, and most first-time founders sign that letter before they understand what they are committing to. The auditor needs things in a fixed order. First, the system description, how the service works, what is in scope, what subservices the company depends on, and where the trust boundary sits. Then the control narratives mapped to TSC. Then evidence the controls were designed and operating on the Type I attestation date. Then, and this is where the timing breaks down, evidence the controls operated continuously across the observation window. What the auditor needs and what the auditor wants diverge across the observation window. What the auditor needs is documented evidence the control fired on the dates sampled. What the auditor wants is that the control fires the same way every time, that operators know it exists, and that exceptions are rare enough that a sample of ten or twenty firings will not surface them. The gap between need and want is the gap between a clean report and a report with exceptions. The practical implication is when to start. A first-time observation window cannot productively start until the controls are designed, the operators are trained, and the evidence-collection workflow is in place. Starting earlier to compress the calendar produces a window in which the controls evolved during the observation, which is the pattern that generates exceptions. A sober plan starts the window at month four only if the gap remediation in months one through three actually closed every gap. Otherwise the window should start later and sales should sell against the Type I in the meantime. The auditor will accept any defensible window. The founder usually picks the earliest defensible window, which is also the riskiest. The partners coach clients toward a window that starts a month after the Type I attestation date, long enough that the gap remediation has settled, short enough that the report still lands inside the year. The cost of the extra month is one month of revenue acceleration on the Type II artifact. The cost of starting the window too early is exceptions in the report, which prospects read and competitors weaponize. Vendor and sub-processor management as the silent killer Type II audits live at the third-party boundary, and the third-party boundary is where digital health companies are most exposed. A digital health SaaS does not run the model; the model is hosted elsewhere. The SaaS does not run the EHR integration; that goes through Redox or Health Gorilla or a direct FHIR connection. The SaaS does not run its own observability; that is Datadog. Each vendor on that list is a sub-processor under the company's customer-facing data processing terms, and each one is a control surface the Type II auditor will examine. The finding pattern is consistent. The company has a vendor list in a Notion document, last updated when the security lead joined eighteen months ago. Half the vendors are still in use; a third have been replaced and not removed; a quarter of the active vendors are not on the list at all because they were procured by engineering with a credit card. The auditor asks for the vendor inventory, the company produces the Notion document, and the first finding is "vendor inventory is not complete or current." The next layer is the BAA chain. A digital health company that touches PHI is a HIPAA business associate to its customers and must have BAAs in place with every sub-processor that touches PHI on its behalf. The Type II auditor reading a digital health report will pull the BAAs because enterprise health system buyers expect that work to have been done. The findings cluster: BAAs with the model vendor but not with the orchestration layer (the same pattern we documented in the HIPAA AI architecture guide); BAAs with the primary cloud but not with the observability vendor that ingests log content; BAAs that name a sub-processor the company stopped using six months ago; BAAs without a sub-BAA flow-down clause, so the company cannot evidence that vendors carry the obligation forward. The annual review is the third layer. The TSC require vendor risk to be assessed at a defined cadence, in practice once a year, with documented evidence. The first-time finding is the company has never run a vendor review, or the review was a single email asking the vendor for their SOC 2 report, with no evaluation, no scoring, and no decision recorded. The mechanical fix on the first Type II is a vendor inventory built from procurement records, expense reports, and engineering's cloud bills, reconciled against the Notion list and the BAAs on file. Every vendor with PHI exposure goes on a tiered review schedule. Every vendor without a current BAA is escalated to a fix list with an owner and a date. The reason this is the silent killer is that the work does not feel like security work to a founder. It feels like procurement administration. It is treated as a quarter-time task assigned to whoever has the bandwidth, and on a first-time Type II it is the cluster of findings the partners have to clean up under audit pressure rather than at leisure. Auditor selection: who actually understands healthcare SaaS The single most consequential decision on a first-time Type II is which auditor signs the report. The framework is the framework. The controls are the controls. The auditor's interpretation of the framework, their familiarity with the vertical, and their reputation in the buyer community are what determine whether the report sells. There are roughly four auditor categories, and the partners have seen first-time digital health customers in each. Big Four firms. The brand is unambiguous; an enterprise health system reading a Big Four-attested SOC 2 will not raise an eyebrow. The price is unambiguous in the other direction; a first-time Type II at a Big Four runs at a multiple of any other category, and the partners assigned to a small engagement are usually senior managers on rotation, not the named partner on the engagement letter. The fit is a company that is already fundraising at a stage where the auditor's brand is part of the diligence story, or that has a Series C+ customer who requires a Big Four signature explicitly. Below that bar, the price is hard to justify. The partners maintain a comparison page on the Big Four SOC 2 question for founders weighing this specifically. Mid-market firms. Brand is real but not Big Four; price is meaningfully lower; partner-level attention is more available. The fit is a Series B+ digital health company selling into IDNs and large regional health systems where the procurement team will Google the auditor and accept any name on a recognizable list. This is the most common rational choice the partners see and the one they coach toward when a first-time customer asks. Healthcare-specialist boutique firms. A smaller set with explicit healthcare SaaS specialization. The brand is recognized inside the healthcare-buyer community even when it is not recognized outside. Price sits between the mid-market and the generalist boutique. The advantage is the auditor knows what HIPAA-adjacent scoping looks like, knows which controls a hospital procurement team will scrutinize, and writes the system description in language that sells. The partners default to recommending this category for clients whose buyers are exclusively healthcare. Generalist boutique firms. Regional CPA firms that added a SOC 2 practice in the last five years. Price is the lowest. Brand is functionally absent outside the firm's region. Work product is variable. The fit is narrow, a company selling to small clinics or non-hospital buyers where the procurement bar is low and the price difference is decisive. The partners do not generally recommend this tier for a company with serious enterprise health system ambitions. Five questions to ask any auditor before signing the engagement letter. First: how many digital health or healthcare SaaS Type II engagements has the firm completed in the last 24 months? The answer should be a number, not a category. Second: which named partner will sign the report, and what is their schedule across the engagement? "We have a deep bench" is the wrong answer. Third: how does the firm scope the boundary between SOC 2 and HIPAA, and how is that boundary written into the system description? Fourth: what is the firm's policy on observation-period exceptions, how are they written, what is the negotiation surface? Fifth: which subservice organizations does the firm carve out by default versus inclusion, and how does that decision change for digital health? The auditor selection happens before the gap remediation, not after. A founder who picks the auditor in month seven of a 12-month plan has lost the firm's input on scoping, system description, and observation window, which is the input that determines whether the report comes out clean. The 12-month readiness sequence The partners run first-time Type II readiness against a four-phase, twelve-month sequence. Compression below twelve months is possible, the partners have done it on engagements where the company started with a mature security posture from a prior fundraise, but compression below nine months has not, in our experience, produced a clean report on a first-time Type II. The sequence is named below; the Pass-Audits service tracks it directly and the SOC 2 readiness framework page is the public version of the methodology. | Phase | Months | Named Activities | Output | |---|---|---|---| | Phase 1, Scoping | 1–2 | TSC scoping decision (which categories beyond CC). System boundary definition. Subservice carve-out / inclusion decisions. Auditor selection and engagement letter. Initial control inventory mapped to TSC. Risk assessment v1. | System description draft. Auditor selected. Control-to-TSC matrix. Risk register v1. | | Phase 2, Gap Remediation | 3–6 | Gap analysis against the 36-control work surface. Vendor inventory and BAA chain audit. Policy authorship and workforce attestation. Access review and deprovisioning workflow build. Encryption posture audit. Change management process formalization. Incident response runbook + tabletop. | All controls designed and operating. Evidence-collection workflow live. Operators trained. Tabletop completed. | | Phase 3, Observation Window | 7–10 | Six-month observation period (or four-month variant for compressed first-year). Evidence collection on every control firing. Internal control testing each quarter. Vendor annual review executed and documented. Mid-window auditor check-in. Exception management discipline. | Six months of operating evidence. Internal test memo. Vendor review memo. Mid-window auditor sign-off on direction. | | Phase 4, Audit Fieldwork and Report | 11–12 | Auditor request list response. Sample-pull responses. Walkthroughs. Management response to any draft exceptions. Report drafting, partner review, final issuance. | Issued SOC 2 Type II report. Bridge letter for the gap to next year's report. | A few notes on the phasing first-timers underestimate. Phase 1 looks light on the table. It is not. The scoping decisions in months one and two determine the cost and timeline of every later phase. Carving in too many subservices doubles the evidence work in Phase 3. Carving out too many makes the report less saleable. The TSC category decision is similar, adding a category is cheap in Phase 1 and expensive in Phase 3. Most first-time digital health companies should add Confidentiality and Availability and hold off on Privacy until renewal. Phase 2 is where the 36-control work happens. The partners structure it as a parallel workstream with three lanes, policy and documentation, technical controls (the CC6 cluster), and operational controls (CC7/CC8/CC9). Each lane has a named owner. Sequential gap remediation produces a four-month phase that takes seven. Parallel remediation produces a four-month phase that takes four. Phase 3 is the calendar phase. Six months does not compress. The discipline is not building anything new; it is making sure the controls keep firing. Most first-time engagements that fail in Phase 3 fail because the company kept shipping product features and the security team did not have the bandwidth to keep the evidence-collection workflow current. The mid-window auditor check-in, which the partners always negotiate into the engagement letter, is the early-warning system. Phase 4 is auditor-driven. The pace is set by the auditor's calendar, QA cycle, and partner-review schedule. A first-time customer who has not budgeted a full eight weeks for fieldwork and report issuance will be surprised. The bridge letter at the end, covering the gap between the report's observation end and the next report's observation start, is the artifact most first-timers forget to ask for and that procurement teams expect to see. Where the Diagnostic Fits: SOC 2 Readiness for Digital Health, and three actions a founder can take this month When a digital health SaaS engages the partners on the Diagnostic for SOC 2 readiness, the engagement is a fixed-scope, fixed-price written assessment that runs ahead of the auditor selection, not after. The output is a 30–50 page readiness report mapped to the 36-control surface above, with a phase-by-phase plan, a vendor and BAA gap register, an auditor selection memo with named candidates from the four categories, and a remediation sequence the founder can run with internal resources or a productized vCISO retainer. The report stands on its own; the partners do not need to be retained to act on it. The Diagnostic is paired with the Pass-Audits service and the SOC 2 readiness framework. For digital health companies whose primary buyer is a healthcare system or IDN, it is the first written piece of evidence that the company is approaching the audit as a discipline rather than an event. Three actions any digital health founder or security lead can take this month, regardless of whether they engage the partners. 1. Build the real vendor inventory, not the Notion one. Pull procurement records, expense reports, and cloud bills. Reconcile against the documented vendor list. Flag every vendor that handles PHI without a current BAA. Most first-time customers find at least three gaps on a serious first pass. 2. Run the Phase 1 scoping decision before talking to auditors. Decide which TSC categories are in scope (CC mandatory; Confidentiality almost always; Availability usually; Privacy rarely on a first run). Decide the system boundary. Decide which subservices are carved out. Write the first draft of the system description. The founder who walks into auditor conversations with a written scoping memo gets better engagement letters. 3. Map the company's existing controls to the 36-control work surface above. The Readiness Checklist paired with this guide is structured exactly that way. For each of the 36, mark Met / Partial / Missing, with a one-line note on evidence. The first pass is a half-day exercise. The output is the foundation of the Phase 2 gap remediation plan and the most useful artifact a founder can hand to a prospective auditor. Three actions, one month, no engagement required. If the inventory or the scoping or the control mapping turns up gaps the company cannot close internally, or if the auditor selection is large enough that getting it wrong is expensive, the Diagnostic is where the partners come in. Two to three weeks, fixed price, written report you keep regardless. The SOC 2 Type II Readiness Checklist for Digital Health, paired with this guide, is the 36-control working document with a Met / Partial / Missing column, a vendor inventory worksheet, an auditor selection scorecard, and a phase-by-phase timeline template. Use it on the first scoping conversation, on every quarterly check-in, and through the observation window. The audit is not the event; the audit is the artifact the work produces.