SOC 2 pentest for healthcare: how health-tech SaaS turns testing into Type II evidence

SOC 2 Type II is the attestation most digital-health buyers ask for before they will send you patient data. If you are an EHR vendor, a telehealth platform, or a medical-device data backend selling into US health systems, and increasingly into EU healthcare through their procurement teams, the SOC 2 report is often the gate that opens the security review.

SOC 2 is designed for service organizations: companies that hold or process data on behalf of their customers. That describes almost every health-tech SaaS. This page focuses on one practical question: how does penetration testing fit into a SOC 2 report for a health-tech company, where the data in scope is PHI and the bar is higher than a generic SaaS.

What SOC 2 actually says about testing

SOC 2 is built on the AICPA Trust Services Criteria (TSC). The criteria describe outcomes, not tools. None of them say "run a penetration test." The ones that matter for testing evidence:

• CC4.1 covers monitoring of controls: the organization selects, develops, and performs ongoing evaluations to check whether controls are present and operating.
• CC7.1 covers detecting new vulnerabilities: the organization uses detection and monitoring procedures to identify changes to configurations that introduce new vulnerabilities.
• CC7.2 covers monitoring for anomalies: the organization monitors system components for anomalies that indicate malicious acts, natural disasters, or errors.
• CC8.1 covers change management: the organization authorizes, designs, develops, tests, and implements changes to infrastructure, data, software, and procedures.

SOC 2 does not literally require a pentest. What happens in practice is that auditors accept a penetration test as the primary evidence for CC7.1 and CC4.1, because a competent pentest demonstrates both that new vulnerabilities are being found and that the control designed to find them actually works. A vulnerability scan alone is usually read as partial evidence: it shows identification but not the depth that CC7.1 implies for a system handling sensitive data.

The Type I versus Type II distinction changes what the evidence has to prove. Type I asks whether the control is designed well on one date, so a single recent pentest report can satisfy it. Type II asks whether the control operated effectively across the observation period, so a pentest dated eleven months before the report tells the auditor almost nothing about the other eleven months.

PHI raises the bar even though HIPAA is a separate regime. SOC 2 auditors know that the data flowing through a health-tech system is patient data, and they read CC7.1 and CC7.2 evidence with that sensitivity in mind. The testing that satisfies a generic B2B SaaS auditor is often the floor, not the ceiling, for a company whose breach would expose medical records.

What auditors actually look for

Three health-tech patterns that show how the evidence conversation runs:

An EHR SaaS, first SOC 2 Type II. The product stores structured clinical records for outpatient clinics and exposes an HL7 and FHIR integration layer to labs and pharmacies. The auditor spent most of the CC7.1 review on the integration surface, not the login page. The questions: which of your PHI-carrying endpoints were tested in the last observation period, who triaged the findings, what was the time-to-remediation for anything rated High, and where is the retest evidence. The company had one annual pentest that covered the web app but had added three new FHIR endpoints mid-period that were never tested. The auditor recorded an observation: the CC7.1 evidence did not cover the full in-scope system across the period. They passed with a note requiring the integration surface to be brought into the testing scope.

A telehealth platform, second Type II. The system runs real-time video, appointment booking, e-prescribing, and a patient mobile app. The auditor focused on CC8.1 and CC7.1 together, because the platform shipped changes weekly. The questions: how do you know each change was tested before it reached patients, and how does that testing produce CC7.1 evidence rather than just a passing build. Their previous report leaned on a single point-in-time pentest, which demonstrated the control on one day of a twelve-month window. The auditor wanted evidence spread across the observation period. The platform wired continuous validation into its release pipeline so the pipeline log itself became sampleable evidence, and kept its weekly cadence.

A medical-device data backend, Type II in preparation. The company ingests telemetry from connected devices and exposes an API to hospital analytics teams. Their scoping debate was where the boundary sat. The device firmware belongs to the manufacturer; the backend that receives, stores, and serves the telemetry is theirs and is in SOC 2 scope. The auditor's early question was whether the ingestion API, the tenant-isolation boundary between hospital customers, and the PHI storage layer were all covered by CC7.1 testing. They scoped the pentest to those three surfaces and explicitly excluded device firmware in the rules of engagement, documenting the boundary so the auditor understood what was and was not being attested.

The pattern across all three: auditors care about whether the testing evidence covers the in-scope PHI-carrying system across the observation period, and whether findings flow through a documented process to closure. A strong report on a surface that omits the integration layer is weaker than a modest report that reaches every place PHI actually moves.

Where continuous AI pentest fits healthcare specifically

Health-tech SOC 2 rewards continuous validation for three concrete reasons:

1. CC7.1 continuous detection. A single annual pentest demonstrates that new vulnerabilities were detected on one day. Continuous validation of each release candidate produces a detection stream the auditor can sample across the whole observation period, which is what Type II is actually testing. For a system holding PHI, an eleven-month gap in the CC7.1 evidence is exactly the finding a careful auditor writes up.

2. Type II observation-period evidence. Type II attests to operation over time, not design on a date. Continuous testing generates dated evidence throughout the 6 to 12 month window without a scramble to package it afterward. The auditor samples the stream instead of relying on one PDF that happened to land inside the period.

3. PHI data-flow and integration surfaces. The riskiest surfaces in health-tech are the integrations where PHI crosses trust boundaries: HL7 and FHIR endpoints, lab and pharmacy connectors, EHR sync, tenant isolation between hospital customers, and patient-facing apps. These change often and are precisely where CC7.1 and CC7.2 evidence needs to reach. Continuous testing keeps pace with surfaces that a once-a-year engagement misses.

What does not satisfy a health-tech auditor: a vendor that hands you scanner output with no human triage, no retest, and no coverage of the PHI integration layer. Auditors recognize that as identification, not the full CC7.1 process.

Procurement checklist for health-tech CISOs scoping SOC 2 pentest

• Does the vendor produce evidence that maps to specific Trust Services Criteria (CC4.1, CC7.1, CC7.2, CC8.1), not a generic report you have to reinterpret for the auditor?
• Does the testing reach the PHI-carrying integration surfaces (HL7 and FHIR endpoints, EHR sync, lab and pharmacy connectors, tenant-isolation boundaries), or stop at the public web app?
• Can the vendor produce dated evidence across the full Type II observation period, rather than a single point-in-time PDF?
• Does the vendor integrate with your CI/CD pipeline so testing is part of the change-management flow that CC8.1 asks about?
• Does the vendor coordinate directly with your SOC 2 auditor and compliance platform (Vanta, Drata, Sprinto, A-LIGN, Schellman) on evidence format?
• Where is the testing data stored, and does any artefact referencing PHI stay inside the jurisdiction your customers require? For EU-facing health-tech, US-hosted evidence is a review flag.
• What is the contractual remediation SLA, and how is retest evidence packaged so High findings show a documented path to closure?

Where Fleuret fits

Fleuret runs continuous AI pentest on health-tech environments: EHR and clinical SaaS, telehealth platforms, patient portals and mobile apps, and medical-device data backends. Our findings stream into SOC 2 Trust Services Criteria-mapped evidence automatically, so CC4.1, CC7.1, CC7.2, and CC8.1 each have dated evidence across the full Type II observation period rather than a single annual snapshot. We reach the PHI-carrying integration surfaces where health-tech risk concentrates, and we integrate with GitHub Actions, GitLab CI, Vanta, Drata, and Sprinto for remediation tracking.

EU data residency by default, so evidence that references PHI data flows stays inside the EU. We do not test medical-device firmware; that stays with the manufacturer, and we scope the boundary explicitly in the rules of engagement.

If you are scoping pentest for SOC 2 Type II as a health-tech company, book a demo.

Related compliance reading

• ISO 27001 pentest for healthcare: the EU-recognized certification health systems often ask for alongside SOC 2, mapped to Annex A instead of the Trust Services Criteria.
• NIS2 pentest for healthcare: the EU regulatory regime for essential healthcare entities, relevant when your hospital customers pull vendors into their own NIS2 supply-chain obligations.