SOC 2 · Digital health & life sciences
SOC 2 Readiness for Medical Device Makers
SOC 2 readiness for a device maker covers the RPM cloud and companion-app half of the product, the part hospitals and US health systems actually expect an independent report about, not the licensed hardware itself, which SOC 2 was never built to assess. Work usually starts when a US customer's procurement team requests a report, or when a hospital deal stalls because nobody can show independent evidence for how the cloud back-end is controlled. We scope the boundary correctly so effort goes where the audience actually looks.
Reviewed by the Privacy Horizon team · Last reviewed
What you're protecting
What sits inside the SOC 2 boundary and what does not
Getting the system boundary right the first time avoids paying for controls testing on parts of the product SOC 2 was never meant to cover.
The RPM cloud service boundary
The AWS or Azure infrastructure receiving telemetry and physiological data, typically the actual subject of a hospital or US customer's audit request.
The companion app and its APIs
The interface and integration layer patients, clinicians and hospital systems use to interact with data collected by the device.
HL7/FHIR integration points
Where your cloud exchanges data with hospital systems like Epic or Oracle Health, a boundary detail that matters to auditors assessing data flow and access control.
What is explicitly out of scope
The device firmware and hardware itself, which are governed by your Health Canada licence and ISO 13485 quality system rather than a SOC 2 report.
Regulatory map
Why SOC 2 belongs here even though the device is already licensed
SOC 2 is a contractual expectation from customers, running alongside, not instead of, your regulatory obligations for the device.
A licence covers the device, not the cloud's controls
Health Canada's review addresses device safety and effectiveness, while SOC 2 addresses the operational controls around the cloud service most hospitals and US buyers cannot otherwise verify themselves.
US health system procurement expectations
US hospital and health-system buyers frequently require SOC 2 evidence for any cloud service touching patient data, independent of whatever device-level regulatory approval already exists.
ISO 13485 governs the device QMS separately
Your quality management certification continues to cover hardware and software lifecycle for the device, while SOC 2 readiness addresses the cloud service's own operational controls in parallel.
What goes wrong
What a SOC 2 gap review catches in the cloud environment
The gaps a readiness review finds here concentrate in access control and change management for the systems handling telemetry.
Access control gaps into telemetry stores
Overly broad access to physiological data, or missing access reviews, are among the fastest findings a readiness review surfaces in an RPM cloud environment.
Missing change management for OTA and cloud releases
A cloud deployment pipeline without documented change approval and rollback procedures is a common gap, especially where firmware and cloud releases are managed by different teams.
Logging and monitoring gaps for RPM data access
Insufficient audit logging of who accessed patient telemetry and when, a control auditors and hospital security teams both expect to see evidence of.
Our soc 2 for medical device makers
What our SOC 2 preparation covers for a device maker's cloud
Gap review, documentation and control build-out scoped to the RPM cloud and companion app, not the device.
System description and criteria selection
We define the cloud and companion-app service boundary explicitly, excluding hardware, and decide which Trust Services Criteria, security plus likely availability given hospital uptime expectations, belong in scope.
High-level gap review
A structured comparison of your cloud engineering and operational practice against the selected criteria, producing a prioritized remediation list.
Documentation guidance
Policies, control descriptions and the system description written to reflect how your cloud team actually operates alongside a separate hardware engineering group.
Control build-out support
Guidance on access, change-management, monitoring and vendor-management controls specific to an RPM architecture receiving continuous physiological data.
Internal review before the auditor arrives
A pre-audit check of your evidence trail, including a readiness conversation with the cloud engineers who will sit across from the CPA firm's testing team.
Ongoing support through the observation window
Light-touch guidance while a Type II observation period runs, so a drifting control gets caught internally rather than flagged as an exception in the final report.
How the engagement runs
How SOC 2 readiness proceeds for the cloud half of your product
We start by drawing the boundary correctly, since including hardware in scope by mistake wastes effort on controls SOC 2 does not assess.
Step 1
Define the service boundary
We agree explicitly that the RPM cloud and companion app are in scope and the device hardware is not, documenting the boundary for the auditor.
Step 2
Run the gap review
Your cloud environment is assessed against the selected Trust Services Criteria, producing a remediation list ordered by audit risk.
Step 3
Build out controls and documentation
Policies, access controls and monitoring are implemented or formalized for the systems actually inside the SOC 2 boundary.
Step 4
Prepare for the audit and support the observation period
We conduct an internal review before the CPA firm's fieldwork and stay engaged through a Type II observation window if that is the report type pursued.
What it costs
What drives SOC 2 readiness cost for a device maker
Cost tracks how cleanly the cloud service boundary can be separated from device engineering, how many cloud environments and hospital or US customer integrations exist, and whether availability criteria join security given hospital uptime expectations for remote monitoring.
Readiness and remediation are billed separately from the independent CPA firm's attestation fee, since we prepare you but do not issue the report ourselves. We quote readiness after reviewing your cloud architecture and the specific hospital or US deal driving the timeline.
Medical Device Makers: SOC 2 questions, answered
Often yes, if hospitals or US health systems are asking for it. A device licence addresses the safety and effectiveness of the hardware and its embedded software, while SOC 2 addresses the operational controls of the cloud service receiving telemetry, a separate audience and a separate question the licence does not answer.
Many will, since a current SOC 2 report is exactly the kind of independent evidence procurement teams look for to avoid running a full audit themselves. Some larger health systems still ask supplementary questions, but a strong SOC 2 report typically shortens that process considerably.
Just the cloud back-end and companion app in almost every device-maker engagement. Firmware and hardware are outside what SOC 2 was designed to assess, and including them in scope by mistake adds cost without producing evidence your hospital or US customers actually need.
They cover different territory and often both get requested. The MDS2 form addresses device-specific hardware, software and network characteristics for biomedical engineering, while SOC 2 addresses organizational controls over the cloud service, so many device makers end up maintaining both.
Many device makers start with a Type I to satisfy an urgent hospital or US deal, then move to a Type II once the cloud controls have an operating track record. A Type II carries more weight with larger health systems but takes longer to produce.
More for medical device makers
Other services for this niche
- Privacy & security for medical device makers — overview
- Virtual CISO
- Virtual Privacy Officer
- Penetration Testing
- Incident Response Planning
- Privacy & Security Policy Development
- Privacy & Security Training
- Vendor Security Review & Questionnaire Support
- ISO 27001 Readiness
- AI Privacy Impact Assessment
- HIPAA Readiness
About this service
What's Protecting Your Business from the Next Threat?
Don't wait for a breach to expose your vulnerabilities. Let Privacy Horizon secure your data, ensure compliance, and build lasting trust.