Does a SOC 2 report satisfy HIPAA?

No. SOC 2 and HIPAA overlap in topics such as access control, logging, encryption, training and incident response, so the same controls and evidence can support both. HIPAA is a law with its own requirements, including a risk analysis and business associate agreements, and a SOC 2 report is not a determination that you meet them. Confirm your HIPAA obligations with counsel.

Is a business associate agreement part of SOC 2?

No. A BAA is a contract HIPAA requires between a covered entity and a business associate, or between a business associate and its subcontractor. It is negotiated and signed separately from your SOC 2 work. An auditor may look at whether you have appropriate contracts with vendors that handle sensitive data, but the BAA itself is a legal document, not a control report.

A customer asked for HITRUST. Is SOC 2 enough?

Ask that customer. HITRUST is a separate framework and assessment program, and some health systems and payers prefer it for vendors. Some customers accept a SOC 2 report instead and others do not, so it is worth asking before you commit to either.

We are a consumer health app, not a business associate. Does any of this apply?

SOC 2 applies if your customers or partners ask for it. HIPAA may not, depending on who you work with and how, which is a question for counsel. Health apps outside HIPAA can be subject to the FTC Health Breach Notification Rule and to state health privacy laws. Selecting health data in the generator still makes sense if you hold health information, because the policies then treat it as Restricted; edit the BAA wording if no BAA applies.

Do our vendors need their own SOC 2 reports?

SOC 2 does not require every vendor to have one. Your Vendor and Third-Party Risk Management Policy says to obtain and review a current assurance report, such as a SOC 2 report, from the vendors you depend on. For vendors that handle PHI, the BAA is a separate requirement on top of that review.

SOC 2 for healthtech and digital health companies

Updated 23 October 2026

Health systems, payers and digital health buyers often ask vendors for a SOC 2 report alongside HIPAA questions. The two overlap but answer different things: SOC 2 is an attestation report on your controls, while HIPAA is a law with its own requirements for anyone handling protected health information on a covered entity's behalf. This page covers how they fit together, which policies to start with and what to select in the free generator.

Why health systems and payers ask for SOC 2

Hospitals, clinics, payers and life sciences companies review a vendor's security before sharing patient data, and a SOC 2 report is one of the documents they commonly request.
If you create, receive, maintain or transmit protected health information on behalf of a covered entity, you are a business associate under HIPAA and the customer will ask you to sign a business associate agreement. Its security team then wants evidence that the safeguards behind it exist.
Health data is among the most sensitive data a customer can share, so reviewers look closely at who can access it, what is logged and how a breach would be handled.
Consumer health apps that fall outside HIPAA may still be subject to other rules, such as the FTC Health Breach Notification Rule, and partners ask how that data is protected too.

Trust Services Categories commonly requested

Security is in every SOC 2 report. The other categories are optional and are added when customers ask for them or your contracts make commitments they cover. What follows is what health systems and payers commonly request, not a rule; agree on the scope with your auditor before the examination period starts.

Category	Why it comes up	In the generator
Security	Included in every SOC 2 examination. The common criteria cover governance, risk assessment, access, change management, monitoring, incident response and vendor risk.	Always
Confidentiality C1.1, C1.2	Commonly added when contracts define information you have agreed to protect and dispose of, such as clinical data sets or data shared by research and pharma partners.	Yes
Availability A1.1, A1.2, A1.3	Commonly requested when clinicians or patients depend on the product to deliver care, for example scheduling, telehealth or clinical workflow tools.	Yes
Privacy	Commonly requested for patient-facing products. It covers notice, choice, use, retention and disclosure of personal information, and overlaps in topic with HIPAA's privacy obligations without replacing them.	No

The generator’s scope question offers Security, Availability and Confidentiality. If your auditor scopes Privacy, the 22 policies are still a starting point (the Privacy and Data Protection Policy covers notice, use, retention and data subject requests), but those criteria need controls and evidence beyond what the policies describe.

Other frameworks that come up, and how they relate to SOC 2

Each framework below is published by its own standards body or regulator; the links go to them. This is a general description, not legal advice: whether a law or contract applies to you is a question for counsel.

The HIPAA Security Rule

The HIPAA Security Rule (45 CFR Part 164, Subpart C) requires covered entities and business associates to maintain administrative, physical and technical safeguards for electronic protected health information, starting with a risk analysis. Many SOC 2 controls address the same topics: access control, audit logging, encryption, security awareness training, incident response and contingency planning, so the same evidence can often support both. NIST SP 800-66 Rev. 2 is a resource guide for implementing the Security Rule.

Keep in mind: A SOC 2 report does not satisfy HIPAA. The Security Rule has specific requirements, such as a documented risk analysis of electronic PHI, that a SOC 2 examination does not test unless the engagement is designed to address them, and your HIPAA obligations are a question for counsel.

Sources: HIPAA Security Rule (HHS) · 45 CFR Part 164, Subpart C (eCFR) · NIST SP 800-66 Rev. 2: Implementing the HIPAA Security Rule

Business associate agreements

A business associate agreement (BAA) is the contract HIPAA requires between a covered entity and a business associate, and between a business associate and its subcontractors that handle PHI. It sets the permitted uses of PHI, the safeguards you apply and your duty to report breaches. You also need BAAs with your own vendors that store or process PHI for you, such as your hosting provider.

Keep in mind: A BAA is separate from SOC 2. Signing one does not produce a SOC 2 report, and a SOC 2 report does not take the place of one. Have counsel review BAA terms, and confirm each vendor offers a BAA for the services and plan you actually use before PHI goes in.

Sources: Business associates (HHS) · Sample business associate agreement provisions (HHS)

Breach notification rules

HIPAA's Breach Notification Rule sets notification duties after a breach of unsecured PHI, and a BAA sets your duty to report breaches to the covered entity. For some health apps and personal health record vendors outside HIPAA, the FTC Health Breach Notification Rule sets its own duties. Your incident response policy should point to whichever applies rather than restate them.

Keep in mind: Which rule applies, and the deadlines it sets, depends on your role and your contracts. Confirm it with counsel before an incident, not during one.

Sources: HIPAA Breach Notification Rule (HHS) · FTC Health Breach Notification Rule, 16 CFR Part 318 (eCFR)

HITRUST

HITRUST is a separate framework and assessment program run by the HITRUST Alliance. Some health systems and payers ask vendors for a HITRUST assessment instead of, or as well as, a SOC 2 report.

Keep in mind: Ask each customer which report it accepts before committing to either; the two are not interchangeable for every buyer.

Sources: HITRUST Alliance

The 6 policies that matter most

All 22 policies apply to every company that uses them. These are the ones health systems and payers read most closely, so review them first and make sure every statement matches how you actually operate. The template index lists the full set.

P22 Privacy and Data Protection Policy: With health data selected, it states that PHI is processed only under a business associate agreement and limited to the minimum necessary for the permitted purpose.
P06 Data Classification and Handling Policy: Classifies PHI as Restricted, keeps it out of email and chat and limits where it may be stored and who may access it.
P03 Access Control Policy: HIPAA and SOC 2 reviewers both focus on who can reach patient data, how that access is approved and how often it is reviewed.
P12 Logging and Monitoring Policy: Access to PHI needs to be traceable. The Security Rule includes audit controls, and SOC 2 auditors test that security events are logged and reviewed.
P13 Incident Response Policy: Holds the steps for deciding whether an incident is a reportable breach and who notifies customers under the BAA.
P16 Vendor and Third-Party Risk Management Policy: With health data selected, vendors that handle PHI sign a business associate agreement before any PHI is shared, and each one is reviewed.

What to select in the generator

These answers change the policy text for health technology companies. The other questions (company, product, tools, owners, review cadence) are the same for everyone.

Question	Answer	What it changes
Sensitive data handled	Health data (PHI)	Adds PHI rules to the privacy, data classification, encryption, vendor, retention, incident response, acceptable use and HR security policies, including BAA requirements and Restricted handling. If no BAA applies to you, edit that wording before adopting the policies.
Sensitive data handled	Personal data (PII)	Patients' and clinicians' names and contact details are personal data even where they are not PHI. Selecting it adds data processing agreement and breach notification wording.
Trust services categories in scope	Confidentiality	Add it if your auditor has scoped it. The data classification and related policies then add rules for identifying, protecting and disposing of information you have agreed to keep confidential.
Key vendors and subprocessors	Your hosting provider and every vendor that stores or processes PHI	Named vendors appear in the vendor and incident response policies, which is where a reviewer looks for your BAA coverage.

Questions an auditor may ask

Walkthrough questions in a SOC 2 examination follow the criteria, but the examples an auditor picks depend on what your product does. These are the kind that come up for health technology companies; the auditor interview prep sheet lists the questions per criterion with the sentences in your policies that answer them.

Which systems store or process PHI, and how do you know it is not in others, such as logs, analytics or support tools?
Which vendors handle PHI, and do you have a signed BAA with each one?
How is access to PHI approved, and when was it last reviewed?
Is access to patient records logged, and who reviews those logs?
How do you decide whether a security incident is a breach that has to be reported, and who makes that decision?
How are backups that contain PHI protected, and when did you last test a restore?

Free tools for this

SOC 2 readiness self-assessment: A quick score and a prioritized list of gaps.
Vendor security questionnaire template: Review every vendor that will touch PHI before it does.
Data retention schedule template: Record how long each kind of health and personal data is kept and how it is disposed of.
Incident response plan template: Severity levels and notification steps to adapt to your BAA and breach rules.
Security questionnaire answers: Draft answers to a health system's security questionnaire from your policies.
System description template: Describe where PHI lives and which vendors are subservice organizations.

Other industries

Frequently asked questions

Does a SOC 2 report satisfy HIPAA?: No. SOC 2 and HIPAA overlap in topics such as access control, logging, encryption, training and incident response, so the same controls and evidence can support both. HIPAA is a law with its own requirements, including a risk analysis and business associate agreements, and a SOC 2 report is not a determination that you meet them. Confirm your HIPAA obligations with counsel.
Is a business associate agreement part of SOC 2?: No. A BAA is a contract HIPAA requires between a covered entity and a business associate, or between a business associate and its subcontractor. It is negotiated and signed separately from your SOC 2 work. An auditor may look at whether you have appropriate contracts with vendors that handle sensitive data, but the BAA itself is a legal document, not a control report.
A customer asked for HITRUST. Is SOC 2 enough?: Ask that customer. HITRUST is a separate framework and assessment program, and some health systems and payers prefer it for vendors. Some customers accept a SOC 2 report instead and others do not, so it is worth asking before you commit to either.
We are a consumer health app, not a business associate. Does any of this apply?: SOC 2 applies if your customers or partners ask for it. HIPAA may not, depending on who you work with and how, which is a question for counsel. Health apps outside HIPAA can be subject to the FTC Health Breach Notification Rule and to state health privacy laws. Selecting health data in the generator still makes sense if you hold health information, because the policies then treat it as Restricted; edit the BAA wording if no BAA applies.
Do our vendors need their own SOC 2 reports?: SOC 2 does not require every vendor to have one. Your Vendor and Third-Party Risk Management Policy says to obtain and review a current assurance report, such as a SOC 2 report, from the vendors you depend on. For vendors that handle PHI, the BAA is a separate requirement on top of that review.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.