Skip to content
Audit-Checklist

Healthcare Privacy · Data Privacy & Law

HIPAA Security Rule for HealthTech: ePHI, BAAs, and OCR-ready evidence

How HealthTech teams run a Security Rule program — risk analysis, safeguards, BAAs, and what OCR and customers actually ask for.

6 min read

If you create, receive, maintain, or transmit ePHI for a covered entity, you are likely a business associate. A SOC 2 helps sales; it does not replace the Security Rule. OCR still starts with whether you did an organization-wide risk analysis — not whether you bought a pen test.

The paired checklist is the safeguard walk. This note is the judgment: what counts as ePHI in a modern stack, when a vendor needs a BAA, and why “addressable” never meant “skip encryption.”

HealthTech questionnaires in 2026 still ask for risk analysis, BAAs, and encryption. If those three are weak, the rest of the Security Rule conversation will not save the deal — or an investigation.

Required versus addressable, in practice

Addressable does not mean optional. It means implement the specification or document an equivalent alternative that reasonably protects ePHI. Encryption is addressable on paper and expected in practice, including for breach safe-harbor analysis under the Breach Notification Rule.

BAAs before sharing ePHI with hosting, support, transcription, or AI vendors is still the gap that shows up in questionnaires and investigations. A SOC 2 from the vendor is not a BAA. A click-through TOS is not a BAA.

The Security Rule is a floor for ePHI. State law, FDA-ish quality systems, and HITRUST customer demands may sit on top. Do not let a Security Rule checklist become the entire HealthTech story if your buyer asked for HITRUST.

OCR investigations still read like operational stories: who had access, whether encryption was in place, whether the risk analysis mentioned the system that was actually breached. A binder of policies dated after the incident is not a program. Date the analysis, name the assets, and keep the evaluation cycle visible.

Decisions the checklist will not make for you

Is this product even in HIPAA? Wellness, de-identified data, and “we only see tokens” arguments fail when logs, backups, or support screenshots still hold identifiers or clinical context. Map data flows before you claim out of scope.

Covered entity versus business associate versus subcontractor changes the contract pack and the OCR story. That is counsel plus your customer’s legal team, not a badge on this site.

How deep a risk analysis must go is a professional judgment. A pen test is a control assessment. OCR’s guidance still wants an organization-wide analysis of threats to ePHI confidentiality, integrity, and availability.

Where HealthTech stacks leak ePHI

Application logs, tickets, session replay, and product analytics often hold names, MRNs, or clinical notes. Treat them as in-scope systems, not “just ops.” If you cannot BAA the vendor, do not send them ePHI.

Skipping a documented risk analysis and relying only on a pentest is the classic OCR finding pattern. Keep documentation for the six-year retention expectation: policies, analyses, and evaluations.

Workforce access from unmanaged devices and shared admin in the EHR-adjacent SaaS are where technical safeguards die. The checklist will mention access; the architecture has to enforce it.

Customers will ask for a risk analysis dated this year, a BAA inventory, and encryption status — often before they ask for a SOC 2. If those three are a scramble, the Security Rule program is not ready for enterprise HealthTech sales, regardless of how good the pentest PDF looks.

How to use the paired checklist

Run it with security, engineering, and the person who signs BAAs in the same pass. A completed checklist with no BAA tracker is incomplete.

If customers are asking for HITRUST, use this note for the Security Rule floor and the HITRUST field note for the scored assessment. They are not substitutes.

Work required specifications first (risk analysis, assigned security responsibility, access, audit controls) so “addressable” debates happen in context. Then use the pitfalls list on the checklist page as a pre-mortem: logs, BAAs, and “we skipped encryption because it was addressable” are still how deals and investigations go badly.

What teams get wrong

Addressable specifications are optional if we are a small startup.
Size may affect what is reasonable, but you still implement or document an equivalent. “We are small” is not an equivalent to encryption or access control. Document the decision with a date and an owner, or implement the specification.
SOC 2 covers HIPAA.
SOC 2 may reuse evidence. It does not create BAAs, a Security Rule risk analysis, or OCR safe harbor. Map the controls; do not swap the regimes. Buyers who ask for both want both stories, not a translation layer.
If we tokenize, we have no ePHI.
Tokens, logs, backups, and support tools often still contain ePHI or are designated record sets. Follow the data, not the architecture slide. If a human can reconstruct who the patient was, treat it as in-scope until counsel says otherwise.

When the checklist is enough — and when it is not

  • Use the checklist to inventory ePHI systems, BAAs, and safeguard evidence before a customer security review.
  • Use healthcare privacy counsel (and often a vCISO who has sat OCR investigations) for scope, BAAs, and incident notification under the Breach Notification Rule.
  • Escalate on any suspected breach of unsecured ePHI, a customer demanding a BAA you have not signed, or a product change that newly stores clinical data.
  • This is not legal advice and not a substitute for the Security Rule, HHS guidance, or your customer’s contract.

Related checklists

Related field notes

The checklists and field notes provided on this website are for educational and informational purposes only. They do not constitute legal, financial, or professional advice. Completing a checklist does not guarantee compliance, certification, or immunity from audits. Always consult with a certified auditor or legal counsel for your specific organizational needs. Full disclaimer