HIPAA Privacy Rule vs Security Rule: What Each Covers, Who Complies

HIPAA Privacy Rule vs Security Rule: The Short Answer

The HIPAA Privacy Rule governs how covered entities and business associates may use and disclose protected health information in any form, and gives patients rights over that information, while the HIPAA Security Rule requires administrative, physical, and technical safeguards for protected health information that is created, received, maintained, or transmitted electronically. That is the whole distinction in one sentence. The Privacy Rule answers who may see this data and why. The Security Rule answers how you keep the electronic copy confidential, intact, and available.

Both rules come from the Health Insurance Portability and Accountability Act of 1996 and both are enforced by the HHS Office for Civil Rights (OCR). They sit next to each other in Title 45 of the Code of Federal Regulations: the Privacy Rule in 45 CFR Part 164, Subpart E, and the Security Rule in Subpart C. A paper chart, a fax, and a hallway conversation are all covered by the Privacy Rule. Only the database, the EHR, the email, and the backup tape are also covered by the Security Rule.

The two rules overlap by design. The Privacy Rule imposes a general duty at 45 CFR 164.530(c) to maintain "appropriate administrative, technical, and physical safeguards" for all PHI. The Security Rule turns that duty into a detailed specification for the electronic subset. If you build or run software that touches patient data, you live under both. This guide walks through what each one demands, who has to comply, how the other HIPAA rules fit, and what the requirements look like when translated into an engineering backlog.

The Four HIPAA Rules, Plus the Omnibus Rule

HIPAA itself, signed on August 21, 1996, is a statute about insurance portability and administrative simplification. The rules people mean when they say "HIPAA compliance" are regulations HHS issued under Title II of that statute, most of them in the 2000s, plus the amendments Congress ordered through the HITECH Act of 2009. Four rules do the heavy lifting, and one omnibus rulemaking in 2013 rewired all of them.

The Omnibus Rule matters more than its name suggests. Before 2013, a business associate answered only to the covered entity that hired it. After September 23, 2013, business associates and their subcontractors became directly liable to OCR for Security Rule compliance and for the Privacy Rule provisions that apply to them. The same rulemaking replaced the old "significant risk of harm" breach standard with a presumption that any impermissible use or disclosure is a breach unless a four factor risk assessment shows a low probability of compromise.

Two other families of HIPAA regulation exist but rarely come up in a privacy or security conversation: the Transactions and Code Sets standards (X12 837 claims, 835 remittances, ICD-10 and CPT code sets) and the Identifier standards such as the National Provider Identifier. They belong to administrative simplification and are enforced by CMS rather than OCR.

Who Must Comply: Covered Entities and Business Associates

HIPAA applies to organizations, not to health data in the abstract. The definitions at 45 CFR 160.103 name three kinds of covered entity, and every other regulated party is a business associate of one of them.

• Health care providers such as hospitals, physician practices, dentists, pharmacies, labs, and therapists, but only if they transmit health information electronically in connection with a HIPAA standard transaction such as an X12 837 claim or a 270 eligibility inquiry. A cash only practice that never bills a payer electronically can sit outside HIPAA, though state law usually still applies.
• Health plans, meaning insurers, HMOs, Medicare, Medicaid, TRICARE, and employer sponsored group health plans. Self administered plans with fewer than 50 participants are excluded.
• Health care clearinghouses, the entities that translate nonstandard health data into standard transactions or back again, including billing services and claims switches that reformat data in the process.

Business associates and subcontractors

A business associate is any person or organization that creates, receives, maintains, or transmits PHI on behalf of a covered entity for a HIPAA regulated function, or that provides legal, actuarial, accounting, consulting, data aggregation, management, administrative, accreditation, or financial services involving PHI. EHR vendors, cloud hosting providers, medical billing companies, transcription services, patient engagement platforms, and any software firm with production access to patient data all qualify. Since the Omnibus Rule, a subcontractor of a business associate is itself a business associate, all the way down the chain.

HHS made an important clarification in its 2016 cloud computing guidance: a cloud service provider that stores encrypted ePHI is a business associate even if it never holds the decryption key and never views the data. Maintaining PHI is enough. That is why Amazon Web Services, Microsoft Azure, and Google Cloud all offer a business associate agreement, and why you need one signed before a single patient record lands in a bucket. Organizations that do not fit either definition, such as life insurers, employers acting as employers, workers compensation carriers, most schools, and most consumer fitness apps, are outside HIPAA entirely. If you also serve EU residents, a separate regime applies, which we cover in GDPR for healthcare data.

What a business associate agreement must contain

A HIPAA business associate agreement (BAA) is the written contract that 45 CFR 164.504(e) and 164.314(a) require between a covered entity and each business associate, and between a business associate and each subcontractor. The regulation dictates the minimum terms. A compliant BAA must:

• Describe the permitted and required uses and disclosures of PHI by the business associate, and prohibit any other use or disclosure except as required by law.
• Require appropriate safeguards, including full Security Rule compliance for any ePHI the business associate handles.
• Require the business associate to report any use or disclosure not provided for by the contract, including breaches of unsecured PHI and security incidents.
• Require the same restrictions and conditions to flow down to every subcontractor through a written agreement.
• Make PHI available for individual access, amendment, and accounting of disclosures, and carry out any Privacy Rule obligations the covered entity delegates.
• Make internal practices, books, and records available to the HHS Secretary for compliance review.
• Return or destroy all PHI at termination where feasible, and authorize the covered entity to terminate the contract if the business associate violates a material term.

A BAA is a legal floor, not a security control. Deciding which vendors get PHI at all, what evidence they must show, and how you monitor them over time is a separate discipline that we cover in BAA and vendor risk management.

What Is PHI? The 18 Identifiers and De-identification

Protected health information (PHI) is individually identifiable health information that a covered entity or business associate holds or transmits in any form, relating to a person's past, present, or future physical or mental health, the care they received, or payment for that care, where the information identifies the person or provides a reasonable basis to identify them. The definition at 45 CFR 160.103 carves out three exceptions: education records covered by FERPA, employment records a covered entity holds in its role as an employer, and records of people who have been deceased for more than 50 years.

Health information alone is not PHI. A blood pressure reading with nothing attached to it is just a number. A name next to an appointment date at an oncology clinic is PHI, and so is an appointment reminder with no diagnosis at all, because the fact of receiving care from a specific provider is itself health information. The Privacy Rule lists 18 identifiers at 45 CFR 164.514(b)(2) that, combined with health information, make the record identifiable:

• 1. Names
• 2. Geographic subdivisions smaller than a state, including street address, city, county, precinct, and ZIP code (the first three digits of a ZIP may remain if the area holds more than 20,000 people)
• 3. All elements of dates except year that relate to the individual, including birth, admission, discharge, and death dates, and all ages over 89
• 4. Telephone numbers
• 5. Fax numbers
• 6. Email addresses
• 7. Social Security numbers
• 8. Medical record numbers
• 9. Health plan beneficiary numbers
• 10. Account numbers
• 11. Certificate and license numbers
• 12. Vehicle identifiers and serial numbers, including license plates
• 13. Device identifiers and serial numbers
• 14. Web URLs
• 15. IP addresses
• 16. Biometric identifiers, including finger and voice prints
• 17. Full face photographs and any comparable images
• 18. Any other unique identifying number, characteristic, or code, except a re-identification code that meets the rule's conditions

Safe Harbor vs Expert Determination

De-identified data is not PHI and falls outside HIPAA. The Privacy Rule offers two routes at 45 CFR 164.514(b). Under Safe Harbor, you strip all 18 identifiers and have no actual knowledge that the remaining data could identify anyone. It is mechanical and easy to audit, but it destroys dates and geography, which limits analytics and model training. Under Expert Determination, a qualified statistician applies accepted methods, documents that the risk of re-identification is very small, and records the analysis. It preserves far more utility but requires expertise and a defensible written opinion. A third option, the limited data set at 164.514(e), keeps dates and city level geography under a data use agreement for research, public health, and operations. Building a repeatable pipeline for any of these is the work described in PHI de-identification services.

PHI vs ePHI vs PII

The HIPAA Privacy Rule in Detail

The Privacy Rule works from a simple premise: a covered entity may not use or disclose PHI except as the rule permits or requires. Everything else in Subpart E is either a permission, a condition on a permission, or a right handed to the individual. The rule took effect for most covered entities on April 14, 2003, and its core structure has not changed since the 2002 modifications and the 2013 Omnibus Rule.

Permitted uses: treatment, payment, and health care operations

Under 45 CFR 164.506, a covered entity may use and disclose PHI for its own treatment, payment, and health care operations (TPO) without asking the patient. Treatment covers care coordination and referrals. Payment covers billing, claims, eligibility, and utilization review. Health care operations covers quality improvement, credentialing, training, audits, and business planning. Section 164.512 adds twelve public interest permissions, including disclosures required by law, to public health authorities, for health oversight, in judicial proceedings, to law enforcement under specific conditions, for research with IRB or privacy board approval, and to avert a serious threat to health or safety. Incidental disclosures, such as a name overheard at a nursing station, are permitted so long as reasonable safeguards and the minimum necessary standard were applied.

The minimum necessary standard

Section 164.502(b) requires covered entities to limit uses, disclosures, and requests for PHI to the minimum necessary to accomplish the purpose. Under 164.514(d), that means identifying which workforce roles need which categories of PHI and restricting access accordingly. The standard does not apply to disclosures to or requests by a provider for treatment, disclosures to the patient, uses under a valid authorization, disclosures to HHS, or disclosures required by law. For a software team, minimum necessary is the regulatory root of role based access control, and it is the reason a scheduler should not be able to open clinical notes. We cover the design side in healthcare identity and access management.

Authorizations

Anything outside TPO and the public interest permissions requires a written authorization under 164.508. Three uses always require one: disclosure of psychotherapy notes, most marketing communications, and any sale of PHI. A valid authorization must describe the information, name who may disclose and who may receive it, state the purpose, carry an expiration date or event, be signed and dated, and explain the right to revoke. With narrow exceptions, a provider may not condition treatment on signing one.

Patient rights

The Privacy Rule gives every individual a set of enforceable rights over their PHI. These are the provisions OCR has enforced most aggressively in recent years through its Right of Access Initiative, launched in 2019, which has produced dozens of settlements against providers that ignored or slow walked records requests.

• Right of access (164.524): inspect and obtain a copy of PHI in a designated record set within 30 days of the request, with one 30 day extension allowed. Fees must be reasonable and cost based. If the records are electronic and the patient asks for an electronic copy, it must be provided in the requested form if readily producible, and the patient may direct the copy to a third party.
• Right to amend (164.526): request correction of inaccurate or incomplete PHI, with a response due within 60 days.
• Accounting of disclosures (164.528): a list of certain disclosures made in the prior six years, excluding those for TPO and those authorized by the patient.
• Right to request restrictions (164.522): a covered entity may generally decline, but since the Omnibus Rule it must honor a request to withhold information from a health plan when the patient paid out of pocket in full.
• Confidential communications: the right to be contacted at an alternative address or by an alternative method.
• Notice and complaint: the right to receive a Notice of Privacy Practices and to complain to the covered entity or to OCR without retaliation.

Notice of Privacy Practices

Section 164.520 requires covered entities to publish a Notice of Privacy Practices (NPP) in plain language that explains how PHI may be used and disclosed, lists the patient rights above, states the entity's legal duties, and names a contact for complaints. Providers with a direct treatment relationship must give the notice no later than the first service delivery, make a good faith effort to get a written acknowledgment, post it where patients can see it, and publish it on any website that describes their services.

The 2024 reproductive health privacy rule

In April 2024, HHS finalized a Privacy Rule amendment titled HIPAA Privacy Rule to Support Reproductive Health Care Privacy, published at 89 FR 32976 with a compliance date of December 23, 2024. It prohibited using or disclosing PHI to investigate or impose liability on anyone for seeking, obtaining, providing, or facilitating lawful reproductive health care, and it required a signed attestation from anyone requesting potentially reproductive health related PHI for health oversight, judicial, law enforcement, or decedent purposes. The rule also added NPP content requirements with a February 16, 2026 deadline.

That rule has since been contested in federal court. In June 2025, the US District Court for the Northern District of Texas, in Purl v. HHS, vacated the reproductive health provisions on a nationwide basis, while the underlying Privacy Rule and the Part 2 related NPP changes were not disturbed. The legal status of the attestation and use limitation requirements should be treated as unsettled until appeals and any new rulemaking conclude. Teams that already built attestation workflows should keep them, since several states impose similar protections under their own law. Confirm the current posture with counsel before relying on this summary.

The HIPAA Security Rule in Detail

The Security Rule, at 45 CFR 164.302 through 164.318, sets four general requirements under 164.306(a): ensure the confidentiality, integrity, and availability of all ePHI you create, receive, maintain, or transmit; protect against reasonably anticipated threats; protect against reasonably anticipated impermissible uses or disclosures; and ensure workforce compliance. Section 164.306(b) then adds the principle that makes the rule workable for a two physician practice and a national health system alike: flexibility of approach. Each organization chooses measures that fit its size, complexity, technical infrastructure, cost, and the probability and criticality of the risks it faces. The rule is deliberately technology neutral, which is why it never names a cipher or a vendor.

The safeguards are organized into three families, plus organizational requirements at 164.314 and documentation requirements at 164.316. Together they contain 18 standards, each with implementation specifications that are either required or addressable.

Administrative safeguards (45 CFR 164.308)

Nine standards make up the administrative safeguards, more than half the rule: the security management process (risk analysis, risk management, a sanction policy, and information system activity review), an assigned security official, workforce security, information access management, security awareness and training, security incident procedures, a contingency plan with data backup, disaster recovery, and emergency mode operation, periodic evaluation, and business associate contracts. These are the governance and process controls, and OCR looks for their documentation first in any investigation.

Physical safeguards (45 CFR 164.310)

Four standards cover the physical layer: facility access controls, workstation use, workstation security, and device and media controls, which includes disposal, media reuse, accountability for hardware movement, and data backup before equipment moves. In a cloud deployment most facility controls are inherited from the provider and evidenced through its SOC 2 report and your BAA, but workstations, phones, and removable media remain yours. How that shared responsibility line is drawn is the subject of our cloud security page.

Technical safeguards (45 CFR 164.312)

Five standards define the technical layer. Access control requires unique user identification and an emergency access procedure, with automatic logoff and encryption and decryption as addressable specifications. Audit controls require hardware, software, or procedural mechanisms that record and examine activity in systems containing ePHI. Integrity calls for a mechanism to authenticate ePHI and confirm it has not been altered or destroyed improperly. Person or entity authentication requires verifying that anyone seeking access is who they claim to be. Transmission security covers integrity controls and encryption for ePHI in transit. Section 164.316 then requires written policies and procedures, and retention of all documentation for six years from creation or last effective date, whichever is later.

Required vs addressable

Every implementation specification is labeled required or addressable under 164.306(d). Required means implement it. Addressable does not mean optional. It means you must assess whether the specification is reasonable and appropriate for your environment, implement it if so, and if not, document why and implement an equivalent alternative where reasonable. Encryption of ePHI at rest is addressable, which is why so many OCR resolution agreements involve a stolen unencrypted laptop and a covered entity that never wrote down why it skipped encryption. In practice, treat encryption, automatic logoff, and strong authentication as required. No auditor has ever accepted "it was addressable" as a defense.

Risk analysis

The risk analysis at 164.308(a)(1)(ii)(A) is a required specification and the single most cited failure in OCR enforcement actions. It must be an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI the organization holds, not just the EHR. OCR's 2010 guidance and NIST SP 800-66 Revision 2 (2024) describe an acceptable methodology: inventory where ePHI lives, identify threats and vulnerabilities, assess current controls, rate likelihood and impact, and document the result. The analysis then feeds a risk management plan. It is a living document, not an annual checkbox. Our HIPAA risk assessment page covers the method in depth.

The December 2024 proposed rule

On December 27, 2024, HHS announced a notice of proposed rulemaking to modernize the Security Rule for the first time since 2013, published in the Federal Register on January 6, 2025. The proposal would remove the required versus addressable distinction and make nearly every specification mandatory. It would require multifactor authentication, encryption of ePHI at rest and in transit with limited exceptions, a written technology asset inventory and network map updated at least annually, vulnerability scanning every six months and penetration testing every twelve, patching of critical vulnerabilities within 15 days, the ability to restore critical systems within 72 hours, segmentation of networks, and an annual compliance audit. Business associates would have to verify their safeguards to covered entities in writing every year.

The comment period closed on March 7, 2025. At the time of writing the rule remains a proposal and is not enforceable, and its final form, if any, may differ. Check the Federal Register and the HHS OCR Security Rule page for the current status before building to it. That said, every proposed control already appears in the HHS 405(d) Health Industry Cybersecurity Practices and in most SOC 2 and HITRUST scopes, so building to the proposal now carries little regret.

HIPAA Breach Notification Rule Timelines

A breach under 45 CFR 164.402 is an acquisition, access, use, or disclosure of PHI not permitted by the Privacy Rule that compromises the security or privacy of the information. Since the Omnibus Rule, every impermissible use or disclosure is presumed to be a breach unless the covered entity or business associate demonstrates a low probability of compromise through a documented four factor risk assessment: the nature and extent of the PHI involved, the unauthorized person who used or received it, whether the PHI was actually acquired or viewed, and the extent to which the risk has been mitigated.

Notification duties attach only to unsecured PHI, meaning PHI that was not rendered unusable, unreadable, or indecipherable through encryption or destruction consistent with HHS guidance. Encrypted data with an uncompromised key is not a reportable breach when the device is lost. Three narrow exceptions also apply: unintentional acquisition by a workforce member acting in good faith within their authority, inadvertent disclosure between two authorized people at the same entity, and a good faith belief that the recipient could not reasonably have retained the information.

Discovery means the first day the breach is known, or by exercising reasonable diligence would have been known, to any workforce member or agent other than the person who committed it. Sixty days is an outer limit, not a target, and OCR has penalized organizations for waiting until day 59 without justification. Many state breach laws impose shorter clocks, and the FTC Health Breach Notification Rule covers health apps that fall outside HIPAA. The full incident response sequence, from containment through the OCR portal submission, is laid out in our HITECH breach notification guide.

Related Guides

These guides cover the neighboring concepts this article refers to, each written in the same answer first format.

• Healthcare Interoperability Explained: HIE, TEFCA, USCDI, Cures Act and SMART on FHIR: the four levels of interoperability, TEFCA, USCDI and SMART on FHIR.
• What Is Conversational AI? How It Works, Types and Enterprise Use Cases: how conversational AI works and how it differs from chatbots and agents.
• What Is Agentic AI? Definition, Architecture, Examples and Risks: what makes AI agentic, the autonomy levels and the controls that keep agents safe.
• Social Determinants of Health (SDOH): Definition, Examples and Data: the five SDOH domains, Z codes and the Gravity Project data standards.

Enforcement, Penalty Tiers and Common HIPAA Violations

HHS OCR enforces the Privacy, Security, and Breach Notification Rules through complaint investigations, breach report reviews, and compliance audits. Most cases close with technical assistance or voluntary corrective action. The serious ones end in a resolution agreement with a monetary settlement and a multi year corrective action plan, or in a formal civil money penalty. Since the HITECH Act, state attorneys general may also sue under HIPAA, and the Department of Justice prosecutes knowing violations criminally under 42 USC 1320d-6, with penalties of up to ten years in prison and a $250,000 fine when PHI is obtained for commercial advantage or malicious harm.

The amounts above are the HITECH statutory figures. HHS adjusts them for inflation every year under the Federal Civil Penalties Inflation Adjustment Act, and the 2024 adjustment lifted the per violation ceiling above $71,000 and the annual cap above $2.1 million per provision. Separately, in April 2019 HHS issued a Notice of Enforcement Discretion stating it would apply lower annual caps by tier, $25,000 for Tier 1 rising to $1.5 million for Tier 4 before adjustment, and that policy remains in effect until HHS changes it through rulemaking. Each violated provision carries its own cap, and OCR counts each day of noncompliance as a separate violation, so multi million dollar outcomes are common. The largest HIPAA settlement on record remains Anthem's $16 million agreement in 2018 following a breach affecting nearly 79 million people.

The pattern in OCR's published resolution agreements is consistent: a missing or superficial risk analysis, unencrypted devices, no audit log review, and denied or delayed patient access requests account for the majority of settlements. A structured approach to closing those gaps, in order, is the subject of our HIPAA compliance playbook.

Privacy Rule vs Security Rule: Side by Side

With the detail in place, the comparison is straightforward. The Privacy Rule is about permission and rights. The Security Rule is about protection of the electronic copy. Most real world compliance failures involve both at once, because an unauthorized disclosure of ePHI is a Privacy Rule violation caused by a Security Rule gap.

In a small organization the Privacy Official and Security Official are often the same person. In a health system they sit in different departments, compliance and IT security, which is exactly where requirements fall between the cracks. A useful discipline is to trace every Privacy Rule permission or right to the Security Rule controls that enforce it: minimum necessary to access control, accounting of disclosures to audit logging, right of access to a patient portal and an export path, and TPO limits to data flow diagrams that show which systems exchange what.

What This Means for Software Teams

Regulatory text does not ship. Engineering controls do. Here is how the two rules translate into a healthcare application backlog, with the provision each item satisfies.

• Encryption at rest and in transit. AES-256 for storage, TLS 1.2 or higher for transport, keys in a managed KMS with rotation. This satisfies the addressable encryption specifications at 164.312(a)(2)(iv) and 164.312(e)(2)(ii), and, if implemented consistent with NIST guidance, moves lost data out of the "unsecured PHI" category so a lost device is not a reportable breach.
• Role based access control and unique identities. Every user gets a unique ID (164.312(a)(2)(i)), roles map to the minimum necessary categories defined under 164.514(d), and multifactor authentication covers every path to production. Shared service accounts with PHI access are a finding waiting to happen.
• Immutable audit logs. Record who viewed, created, changed, exported, or deleted each PHI record, with timestamps (164.312(b)). Retain for six years (164.316(b)(2)), review them on a schedule (164.308(a)(1)(ii)(D)), and make them queryable enough to produce an accounting of disclosures under 164.528.
• A signed BAA with every cloud and SaaS vendor that touches PHI. AWS, Azure, and Google Cloud all sign one, but only for the services listed in their BAA scope. Using an out of scope service for PHI voids the coverage. Email, analytics, error tracking, and customer support tools need the same review.
• De-identification pipelines for analytics and AI. Apply Safe Harbor or Expert Determination before data leaves the production boundary for reporting, model training, or vendor demos, and prove it with a documented method.
• Patient access in 30 days or less. A portal or API that lets a patient download their record in a usable format satisfies 164.524 and aligns with the ONC Cures Act Final Rule, which requires FHIR R4 patient access APIs from certified EHR vendors and prohibits information blocking.
• A risk analysis that reflects the actual architecture. Every new data store, integration, and vendor updates the ePHI inventory and the risk register. If your risk analysis predates your current cloud account, it is not thorough.
• Third party evidence. Because HIPAA offers no certification, buyers ask for SOC 2 Type II reports and HITRUST assessments as proof that the controls exist and operate. We compare the two in SOC 2 and HITRUST for healthcare.

None of these are exotic. What separates a defensible system from a liability is that they are designed in at the data model and infrastructure layer rather than retrofitted, and that each control is traceable to the provision it satisfies. That traceability is the deliverable Bonami produces alongside the code in every HIPAA compliant software development engagement.

Common Misconceptions About the HIPAA Rules

There is no such thing as HIPAA certification

HHS does not certify, endorse, or recognize any HIPAA certification program for organizations or software, and OCR has said so directly. A vendor that calls itself "HIPAA certified" bought a training course or a third party seal. What exists instead are frameworks and attestations, SOC 2, HITRUST CSF, and NIST based assessments, that provide independent evidence of controls. They are valuable, but they are not a HIPAA certificate, and they do not shift liability.

HIPAA compliant hosting does not make your application compliant

A BAA with AWS or Azure covers the physical data centers, the hypervisor, and the managed services in scope. It does not configure your IAM policies, encrypt your database volumes, enable your audit trails, patch your containers, or restrict your engineers' access. Under the shared responsibility model, everything above the infrastructure line is yours. Most cloud breaches involving PHI trace to a misconfigured storage bucket or an overly permissive role, both of which sit squarely on the customer side.

Wellness and fitness apps are usually not covered

A consumer app that a person downloads and uses on their own, with no covered entity involved, is not regulated by HIPAA even if it stores heart rate, sleep, or menstrual cycle data. The same app becomes a business associate the moment a hospital or health plan contracts with it to serve patients or members. Data outside HIPAA is not unregulated: the FTC Health Breach Notification Rule, updated in 2024, applies to health apps and connected devices, and states including Washington, Nevada, and Connecticut have passed consumer health data laws with private rights of action or attorney general enforcement.

Small organizations get no exemption

The Security Rule's flexibility of approach scales the controls to the organization, not the obligations. A solo practitioner still needs a risk analysis, policies, training, and a BAA with every vendor. OCR has settled cases with practices of a handful of clinicians, and the Right of Access Initiative in particular has focused on small providers.

Encryption is addressable, but skipping it is not a real option

Addressable means you must decide, document, and defend. No organization has successfully defended a decision not to encrypt ePHI on portable devices, and the December 2024 proposed rule would remove the choice entirely. Treat encryption as required today and the question disappears.