Selling software into healthcare means the security review arrives before the contract does. Putting a model into a clinical workflow means it arrives with a longer list of questions attached.
This is an account of a SOC 2 Type I engagement for a VC-backed Ontario medtech company building an AI clinical assistant: the kickoff, the gap analysis, the evidence request that came out of it, and what the first weeks of a Type I actually look like from the inside.
The company and the problem
An AI clinical assistant used by practitioners. That places the product in the path of clinical decision-making and clinical data at the same time, which is a harder starting position than a typical B2B SaaS company faces.
Health buyers do not simply ask whether you hold a report. They ask what data the model sees, whether any of it is used for training, where inference happens and in which jurisdiction, who inside your company can reach the data, how long you keep it, and what the process is when the model produces something wrong. A SOC 2 does not answer all of that by itself. What it does is get you into the conversation, and the control work behind it produces most of the answers to the rest as a by-product.
There is a second dynamic worth naming. In healthcare the person evaluating you is frequently not the person buying. A clinical lead wants the product, and a privacy officer or a security reviewer decides whether it can be adopted. Those two have different questions, and the second set is answered with documents rather than demos. Companies that treat compliance as a sales blocker tend to discover late that it is closer to a second sales process running in parallel.
Why Type I first
We scoped a Type I, and for a company at this stage that is usually the right call.
A Type I attests that controls are suitably designed as at a point in time. A Type II attests that they operated effectively across a period, which means the period has to elapse before you have anything to show. Going straight to Type II sounds more rigorous, and it is, but it also means telling a buyer who is asking today that you will have something for them in six months or more.
The Type I gets a defensible artefact into the sales conversation now. The same control set then runs through an observation window and becomes the Type II without rework, provided the controls were designed to produce evidence in the first place. That proviso is the whole game. A Type I built as a paperwork exercise, with controls that look right on paper and generate nothing, produces a painful surprise when the Type II window closes and there is nothing to sample.
So the Type I here was scoped as the first half of a Type II rather than as a standalone deliverable. Every control was designed with the question of what artefact it produces, and where that artefact lands, answered up front.
Kickoff and gap analysis
Kickoff and gap analysis opened together in mid-July.
The gap analysis is where the programme is actually shaped. It sorts everything into three categories: what exists and is documented, what exists but is not documented, and what does not exist. Those need completely different work, and teams routinely mistake the second for the third and budget accordingly.
It is common, and it was true here, to find that a company already does a good deal of the right thing. Engineers review each other's work. Access is not handed out casually. Somebody has thought about backups and about what happens when a service falls over. None of it is written down in a form an auditor can evaluate, which is a documentation problem rather than a security problem, and a much cheaper one to solve. Writing down a process that already runs takes days. Building one that does not exist takes weeks and requires people to change how they work.
The output of the gap analysis is not a score. It is the document request list.
The evidence request: 84 items
We issued a Phase 1 document request list covering 84 evidence items.
That number surprises people, and it is worth being blunt about why it is that high. An auditor does not accept a policy as evidence that a control operates. They want the artefact the control produced. A policy stating that access is reviewed quarterly evidences nothing at all. The completed review, dated, with the reviewer named and the resulting changes recorded, evidences the control. One control routinely requires several artefacts: the policy that defines it, the configuration that enforces it, and the record showing it ran.
The request spans the areas any SOC 2 covers, plus several that carry extra weight in a clinical context.
Governance and structure. Entity and legal structure documentation, an organisational chart with reporting lines, board or advisory governance documentation, and a code of conduct or ethics policy. This looks like bureaucracy and is not. An auditor is establishing who is accountable to whom before assessing whether accountability is being exercised.
People. An employee and contractor list with roles, start dates and access levels. Confidentiality and NDA agreements covering both employees and contractors. The contractor half of that is where gaps usually appear, because contractor paperwork is often handled ad hoc and rarely carries the same security obligations as an employment agreement.
Identity and access. Identity provider configuration, MFA enrolment and enforcement evidence across all users, the complete user access list with roles and permissions, RBAC role definitions with an assignment matrix, and documented provisioning and deprovisioning procedures. This cluster is the single most heavily sampled area in most SOC 2 audits.
Privacy. A finalised privacy policy rather than a draft, and the privacy impact assessment. In a clinical setting these are read closely rather than filed, and a PIA that was written to satisfy a checkbox tends to show it.
Policy inventory and ownership. Every existing policy with version numbers, and named signatories for each SOC 2 role.
That last item catches people out more than any other. SOC 2 expects named accountability, and the engineering team is not a name. Identifying the specific individual responsible for each role is a short exercise that reliably surfaces genuine gaps, because a control that belongs to everybody is a control that runs on nobody's calendar.
Where the strength was
The gap analysis surfaced something worth saying plainly, because it decided how the rest of the engagement would go.
Identity and access was already solid, which materially de-risks a Type I timeline. Identity provider configuration in place. MFA enrolled and enforced across all users rather than encouraged. RBAC role definitions with an assignment matrix rather than living in somebody's head. Provisioning and deprovisioning as documented procedures rather than tribal practice.
That cluster is where first-time SOC 2 candidates are usually weakest, and where remediation is slowest, because fixing it means changing how people get access to things and that is organisational work rather than technical work. Having it already in place at the point of the gap analysis is the difference between a comfortable programme and a stressful one.
The governance and privacy layer was in similar shape: entity and legal structure, an organisational chart with real reporting lines, board and advisory governance, confidentiality agreements covering employees and contractors, a finalised privacy policy, and a privacy impact assessment that had been written to be used rather than filed.
What was left was documentation rather than implementation, which is the good version of a gap. A security policy inventory with version numbers, a code of conduct, the access list in the form an auditor wants it, and named signatories for each SOC 2 role are all cases of writing down or reformatting something that substantially exists. None of them require anyone to change how the product is built or operated.
The questions SOC 2 will not ask you
Worth saying plainly, because it is the trap specific to this category: a SOC 2 report will not tell a health buyer what your model does with their data.
The framework was not written with machine learning in mind. It will ask whether access to data is controlled, whether changes are managed, whether incidents are handled. It will not ask whether patient data is used for training, whether a prompt containing clinical detail is retained by a model provider, how you evaluate the model for degradation, or what a clinician is supposed to do when the assistant is confidently wrong.
Buyers ask all of those, every time. The efficient move is to answer them in the same programme, while the architecture is already written down and in front of you, rather than assembling answers under time pressure during a review six months later. Most of the material overlaps with the SOC 2 work anyway: data flow diagrams, subprocessor lists, retention schedules and access controls all serve both.
What we would tell another medtech founder
Start from the evidence request, not from the policies. You will learn more about your real posture from trying to produce 84 artefacts than from any maturity questionnaire.
Name an owner for every control. If it belongs to a team rather than a person, it is probably not running on a schedule.
Get the identity and access cluster right early. It is the most heavily sampled area and the slowest to remediate, because it changes how people work.
Finalise the privacy documents. Drafts are not evidence, and in a clinical context the PIA is read rather than filed.
Treat contractor paperwork as seriously as employee paperwork. Same access, same obligations, same evidence.
Type I first is not a shortcut, provided you build it as half a Type II. Design every control around the artefact it produces, and the observation window becomes a waiting period rather than a second project.
Answer the model questions while you are already in the material. They are coming in every review regardless.
If you are working through the same problem, the HIPAA framework guide covers what US health buyers add on top, getting HIPAA-ready as a healthtech company covers the pairing, and the cost breakdowns cover what each runs to.
Engagement note. The work described here is complete and delivered. The engagement continues into audit, and the client is unnamed at this stage of the programme.