Who the HIPAA Security Rule applies to

If you searched the exact question, here is the answer in one sentence:

The HIPAA Security Rule applies to covered entities and their business associates, with respect to electronic protected health information (ePHI) they create, receive, maintain, or transmit.

That is the language from 45 CFR § 164.302. Everything else, the safeguards, the risk analysis, the breach reporting flowchart your lawyer sent you, is downstream of that one sentence. The interesting part is figuring out which bucket your company is in, because that determines whether a federal regulator can walk in and ask to see your policies. HHS publishes a covered-entity/business-associate overview that links to the CMS decision tool if you want to pressure-test your answer before your lawyer does.

The two groups the rule covers

The Security Rule does not apply to "companies that handle health data." It applies to two specific legal categories defined elsewhere in HIPAA:

Covered entities. Three sub-types, spelled out in 45 CFR § 160.103:

• Health plans, insurers, HMOs, Medicare, Medicaid, employer group health plans above a size threshold.
• Health care clearinghouses, entities that translate non-standard health information into standard formats (and vice versa) for billing.
• Health care providers who transmit any health information electronically in connection with a HIPAA-standard transaction. The "electronic transmission" trigger is what pulls most modern clinics and hospitals in.

Business associates. Any person or organization that performs a function or activity on behalf of a covered entity that involves the use or disclosure of PHI. A SaaS vendor hosting patient records for a clinic is the textbook example. So is a billing processor, a cloud EHR, a data-analytics firm running models over claims data, and a subcontractor those vendors hire to help.

The Omnibus Rule in 2013 extended direct liability to business associates. Before Omnibus, only covered entities could be fined by OCR. After Omnibus, your SaaS company can be fined directly, which is why your enterprise health customers started asking for BAAs around that time. If you build SaaS for clinics or payers, our HIPAA compliance for SaaS walkthrough covers what the BAA actually obligates you to do.

If you signed a Business Associate Agreement, you accepted the Security Rule. Read the BAA once before the first incident rather than during it.

The one thing the rule does not cover

The Security Rule only covers ePHI, protected health information in electronic form. Paper charts, verbal disclosures, and faxes are governed by the HIPAA Privacy Rule, which is a separate body of regulation at 45 CFR Part 164 Subpart E.

This trips people up. A clinic that keeps paper charts in a filing cabinet still has a HIPAA problem if the cabinet is unlocked, but it is a Privacy Rule problem, not a Security Rule problem. The two rules overlap in purpose and diverge in mechanics.

If your company is pure SaaS, the Security Rule is the one you will spend 99% of your time on.

What the rule actually requires

The Security Rule organizes its requirements into three categories of safeguards. Every covered entity and business associate has to address all three.

Administrative safeguards (§ 164.308). The paperwork layer. A designated Security Official, a written risk analysis, workforce training, sanction policies, access management procedures, contingency plans, and periodic evaluations. This is where the rule spends most of its text.

Physical safeguards (§ 164.310). Facility access controls, workstation use and security, and device and media controls. For a cloud-native company this is largely inherited from your hosting provider, which is why AWS, Azure, and GCP all publish BAA-eligible services lists. You still have to document the inheritance.

Technical safeguards (§ 164.312). Access control, audit controls, integrity, person-or-entity authentication, and transmission security. This is where encryption, logging, MFA, and TLS live. The rule is technology-neutral by design: it specifies what must happen, not how.

Inside each category, requirements are split into "required" and "addressable" implementation specifications. "Addressable" does not mean optional. It means you must either implement the specification, implement an equivalent alternative, or document why the specification is not reasonable for your environment. Skipping an addressable spec without documenting the reasoning is the single most common finding in OCR investigations.

The risk analysis is the anchor

If you only do one thing under the Security Rule, do the risk analysis required by § 164.308(a)(1)(ii)(A). Every OCR settlement we have read mentions it, either because the entity did not have one or because the one they had was a four-page PDF from 2018. OCR's own guidance on risk analysis is the primary source worth reading before you pay anyone to do one for you.

A real risk analysis identifies where ePHI lives, what could go wrong, how likely each scenario is, and what you are doing about it. It is the document your auditor, your BAA partner, and eventually OCR will all ask for. Date it, sign it, and refresh it when your architecture changes.

How this maps to SOC 2

SOC 2 and HIPAA live in different regulatory worlds but test overlapping controls. Access control, audit logging, encryption in transit and at rest, incident response, change management, vendor oversight, all of it shows up in both the Security Rule and the Trust Services Criteria.

We see SaaS companies use a SOC 2 Type II report (see what SOC 2 actually is) as the scaffolding for their HIPAA program, layer HIPAA-specific policies and a risk analysis on top, and sign BAAs without needing a separate HIPAA audit. OCR does not "certify" anyone, there is no HIPAA stamp to collect, so a well-scoped SOC 2 plus a documented HIPAA program is what most enterprise health buyers actually want to see. If you need something stronger, HITRUST is the usual next step.

(What a SOC 2 report actually tells your buyer walks through how procurement teams read that report.)

Who the rule does not apply to

A few categories worth naming, because founders ask:

• Life insurers, workers' comp carriers, and most employers handling their own employee health data. They are not covered entities under HIPAA.
• Consumer wellness apps that do not contract with a covered entity. A direct-to-consumer sleep tracker is outside HIPAA, though the FTC Health Breach Notification Rule may still reach it.
• De-identified data that meets the Safe Harbor or Expert Determination standards at § 164.514. Once data is properly de-identified, it is no longer PHI and the Security Rule no longer applies to it.

Being outside HIPAA does not mean being outside the law. State privacy laws, the FTC Act, and sector rules can all reach health data that HIPAA does not.

What to do this week

1. Decide, in writing, whether your company is a covered entity, a business associate, or neither. Have your lawyer confirm.
2. If you are a business associate, pull every BAA you have signed and map the ePHI flows they cover.
3. If you do not have a current risk analysis, schedule one. "Current" means this architecture, not last year's.
4. If you are preparing for a SOC 2 and your customers are in healthcare, tell your auditor on day one. Control design choices are cheaper to make early than to retrofit.

---

If you are mid-questionnaire and trying to figure out whether a SOC 2 plus a HIPAA program is enough for your buyer, get in touch. We do the accounting and the audit (see our compliance services); we do not sell a HIPAA certification, because there isn't one to sell.