SOC 2 for healthtech: what hospitals and health plans review

So the useful question is narrower. What does a hospital or a health plan need from you, and which parts of it can a SOC 2 report answer? The table sets the two side by side. It is not legal advice about your agreement, and your buyer’s counsel decides what its contract requires.

HIPAA and SOC 2 are different things

HIPAA’s Security Rule sets the administrative, physical and technical safeguards that covered entities and business associates must put in place for electronic protected health information (ePHI).⁴ It starts with a risk analysis: an accurate and thorough assessment of the risks to the confidentiality, integrity and availability of that data. HHS describes the rule as flexible, scalable and technology neutral. It tells you what to protect. It leaves the how to you.

A SOC 2 works the other way round. A CPA firm examines your controls against the Trust Services Criteria and gives an opinion on whether they were suitably designed and, in a Type 2, whether they operated across a period.² The opinion speaks to the criteria in scope. It does not say whether you meet HIPAA.

The ground they cover overlaps. Access control, workforce training, incident response, risk assessment and vendor management appear in both. One set of controls can feed your HIPAA risk analysis and your SOC 2 at once. Keep the two documents apart anyway, because two different readers will check them.

When you are a business associate

HHS defines a business associate, in general, as a person or organization that creates, receives, maintains or transmits protected health information (PHI) on behalf of a covered entity.¹ Its own examples include a health app developer that contracts with a covered entity to serve its patients, an IT vendor that supports systems holding ePHI, and a third-party chatbot on a provider’s patient portal.

Encryption does not change the answer. A cloud provider that stores only encrypted ePHI, and holds no key to it, is still a business associate.³ And a subcontractor that handles PHI for a business associate is a business associate too. That chain runs through you to your own vendors.

The agreement has required contents. Under the Privacy and Security Rules, it must:

• describe the uses and disclosures of PHI you are permitted and required to make;
• bind you not to use or disclose it beyond the agreement or what law requires;
• require you, and any subcontractor, to comply with the applicable Security Rule requirements;
• require you to report security incidents, including breaches of unsecured PHI.

You must also sign one with each subcontractor before you disclose PHI to it. A business associate is directly liable for complying with certain provisions of the HIPAA Rules.¹ The report cannot carry that for you.

Why the hospital asks for a report

HHS answers this directly in its cloud guidance. The HIPAA Rules do not expressly require a cloud provider to give customers documentation of its security practices, or to let them audit it.³ But customers may require documentation of safeguards or audits, through the agreement or a service level agreement, based on their own risk analysis. That is where the request for a SOC 2 comes from.

The same guidance lists what a service level agreement can address: system availability, backup and data recovery, how data is returned when the service ends, security responsibility, and limits on use, retention and disclosure. Each has a home in a SOC 2. Availability covers the first two. Your deletion and export controls cover the third, and your system description assigns the fourth, including what the customer must do on its side. How to word complementary user entity controls covers that half.

Which Trust Services Criteria to put in scope

Security is the one category every SOC 2 includes. The other four are optional, and each tests something different.⁵

Availability

Whether the system is available for operation as committed, including backup and recovery. It fits when a service level agreement promises uptime or recovery times.

Confidentiality

Whether information designated as confidential is protected and disposed of as committed. It fits when your agreements make those commitments about patient or customer data.

Privacy

Whether personal information is collected, used, retained, disclosed and disposed of in line with the notice you publish. It fits when patients use your product directly under your own privacy notice.

Processing Integrity

Whether processing is complete, valid, accurate, timely and authorized. It fits when you compute claims, billing or results that a buyer relies on.

The scoping tool walks each decision against your contracts. In Polara GRC you add them in the assessment or from your account settings, until the engagement letter is signed or the audit is requested. Whatever you choose goes into the report and the examination.

When a buyer names a different report

Read the request. Some contracts and vendor policies name an assessment from another program, run against that program’s own control framework. A SOC 2 report does not meet that term unless the buyer agrees to accept it. Ask in writing which report the buyer accepts before you commit to either.

If your product sends patient data to a model provider, that provider is part of the same chain. The guide for AI companies covers the carve-out and the vendor file. The same structure, with a different buyer, applies to HR and payroll software and to education technology.