HIPAA Cybersecurity Requirements for Small Healthcare Businesses

This article provides general educational information about HIPAA requirements. It is not legal advice. Healthcare businesses with specific compliance questions should consult a qualified healthcare attorney or HIPAA compliance professional.

The Most Important Thing to Know Before Reading This Article

HHS published a proposed update to the HIPAA Security Rule in January 2025 — the most significant proposed overhaul in more than two decades. As of August 2026, that proposed rule is not yet final. The OMB’s Unified Agenda now targets July 2027 for final action, pushed back from an earlier spring 2026 target.

The proposed rule is not law. The current HIPAA Security Rule — the one adopted in 2003 and last substantially updated in 2013 — is what the Office for Civil Rights (OCR) enforces today.

Here is what that means practically: OCR is actively enforcing the existing Security Rule in 2026, including issuing four ransomware settlements in a single notice. And OCR’s enforcement under the existing rule has moved squarely in the direction of what the proposed rule would mandate — specifically, scrutinising MFA, encryption, risk analysis, and business associate agreement management in virtually every investigation.

The honest framing for small healthcare businesses: implement MFA, encryption, documented risk analysis, and tested backup now — not because the proposed rule requires it yet, but because OCR is already treating those controls as expected under the existing “addressable” framework, and because the direction of healthcare cybersecurity regulation is unambiguous regardless of when the final rule publishes.

This article covers both: what the current rule requires, and what the proposed rule would change — so you can build a compliance programme that protects you today and positions you for what is coming.

Who HIPAA Applies To

HIPAA applies to two categories of organisations, both of which carry the same Security Rule obligations.

Covered entities: Healthcare providers who transmit any health information electronically (this includes virtually every practice that bills electronically), health plans, and healthcare clearinghouses. Small healthcare businesses that fall into this category include: physician practices, dental offices, optometry practices, mental health and counselling practices, chiropractic practices, physical therapy practices, pharmacies, and any other provider that transmits health information in electronic form.

Business associates: Any organisation that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity. This includes: electronic health record (EHR) vendors, medical billing companies, healthcare IT providers, cloud storage services storing PHI, transcription services, medical transcription companies, practice management software vendors, and any MSP or IT provider with access to systems containing PHI.

If you are a business associate, you have the same Security Rule obligations as a covered entity. Your covered entity clients must have a Business Associate Agreement (BAA) with you, and you must comply with the Security Rule independently.

What HIPAA does not apply to: Businesses that receive health information only in their capacity as employers (employee health plan data is different from patient health data), businesses with no electronic health information, and entities whose only contact with health information is through truly de-identified data.

What Protected Health Information (PHI) and ePHI Are

Protected Health Information (PHI) is individually identifiable health information — information that relates to an individual’s physical or mental health condition, the provision of healthcare, or payment for healthcare, and that can identify the person.

Electronic Protected Health Information (ePHI) is PHI in electronic form — stored on computers, transmitted over networks, held in cloud services, or processed by any electronic system. The HIPAA Security Rule applies specifically to ePHI.

PHI includes: patient names combined with health information, dates (birthdate, admission dates, discharge dates), geographic data smaller than state level, telephone and fax numbers, email addresses, Social Security numbers, medical record numbers, account numbers, health plan beneficiary numbers, certificate or licence numbers, device identifiers, URLs, IP addresses when associated with health information, biometric identifiers, and full-face photographs.

De-identified data — with all 18 identifiers removed — is not PHI and is not subject to HIPAA.

The Three Categories of HIPAA Security Rule Safeguards

The current HIPAA Security Rule organises its requirements into three categories of safeguards. Every covered entity and business associate must implement all three. Within each category, individual requirements are labelled either “required” (must be implemented as written) or “addressable” (must be implemented, implemented with an equivalent alternative, or documented as not reasonable and appropriate with reasoning).

The critical point on addressable: “addressable” has never meant optional. OCR’s enforcement record demonstrates this clearly — organisations that have treated addressable specifications as discretionary have faced penalties. In practice, the distinction between required and addressable has primarily given small organisations flexibility in how they implement a control, not whether to implement it at all.

Administrative Safeguards

Administrative safeguards are the policies, procedures, and management practices that form the foundation of your HIPAA security programme. They are the most commonly cited deficiencies in OCR enforcement actions.

Security Risk Analysis (Required)

The single most important HIPAA Security Rule requirement, cited in nearly every OCR enforcement action and investigation. You must conduct a thorough, accurate, and documented assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your organisation.

A Security Risk Analysis (SRA) must:

• Identify the scope of ePHI — where it is created, received, maintained, and transmitted
• Identify and document threats and vulnerabilities to ePHI in each location
• Assess the likelihood that each threat would exploit each vulnerability
• Assess the potential impact of each vulnerability being exploited
• Determine the current level of risk for each vulnerability
• Document all findings

The SRA must be current — OCR expects it to be repeated annually and updated whenever there are significant changes to the environment (new software, new locations, new staff, new systems). A one-time SRA from 2020 is not compliant. A SRA that identifies risks but documents no action taken is not compliant.

OCR scrutinises whether organisations have acted on identified risks over time, not just documented them. Repeatedly deferring the same control year after year is increasingly indefensible in enforcement.

Risk Management (Required)

Implement security measures sufficient to reduce risks and vulnerabilities identified in the SRA to a reasonable and appropriate level. Document what actions you are taking in response to identified risks and track progress.

Workforce Training (Required)

Implement procedures for authorising and supervising workforce members who work with ePHI. Train all workforce members on policies and procedures regarding ePHI protection. Document training completion and content.

Information Access Management (Required)

Implement policies for authorising access to ePHI. Only staff who need ePHI to perform their job functions should have access, and access should be limited to only the ePHI they need (minimum necessary principle).

Security Incident Procedures (Required)

Implement policies and procedures to address security incidents — identify, respond to, mitigate harm from, and document security incidents and their outcomes. Maintain an incident log, even for minor incidents. This documentation is requested in OCR investigations.

Contingency Plan (Required)

Implement policies for responding to emergencies that damage systems containing ePHI. A contingency plan must include:

• Data backup plan
• Disaster recovery plan
• Emergency mode operation plan
• Testing and revision procedures
• Application and data criticality analysis

Under the proposed rule, organisations would be required to achieve a 72-hour Recovery Time Objective (RTO) and 48-hour Recovery Point Objective (RPO). Implement these standards now as best practice regardless of final rule timing.

Business Associate Agreements (Required)

Every business associate — any entity that handles ePHI on your behalf — must have a signed BAA with your organisation before receiving any PHI. The BAA must:

• Establish the permitted and required uses of PHI by the business associate
• Require the business associate to implement appropriate safeguards
• Require the business associate to notify you of security incidents involving your PHI
• Require return or destruction of PHI at the end of the relationship
• Require the business associate to make its practices available for OCR review

BAA management is one of the highest-frequency deficiencies OCR finds. Common gaps: BAAs that have never been signed with cloud storage providers, EHR vendors, billing services, or IT providers; BAAs that are outdated; BAAs that do not address the business associate’s sub-contractors.

Critically: AI tools that access ePHI — AI scribes, clinical decision support tools, ambient documentation tools — require BAAs. This is an emerging enforcement focus. Verify that any AI tool your practice uses has an HIPAA-compliant BAA available and signed before connecting it to ePHI.

Workforce Sanctions (Required)

Implement and apply appropriate sanctions against workforce members who fail to comply with security policies.

Physical Safeguards

Physical safeguards protect the physical infrastructure — buildings, rooms, devices — where ePHI is stored or accessed.

Facility Access Controls (Required)

Limit physical access to electronic information systems and the facilities in which they are housed to authorised users only. This includes: locking server rooms, restricting physical access to workstations with patient records, and maintaining visitor logs.

Workstation Use and Security (Required)

Implement policies for the proper use of workstations that access ePHI. Position screens so patient information is not visible to unauthorised individuals. Lock workstations when unattended (screen lock after inactivity).

Device and Media Controls (Required)

Implement policies for the receipt and removal of hardware and electronic media containing ePHI. Before disposing of a device, ensure ePHI is securely wiped. Document disposal of devices containing ePHI. Track movement of devices containing ePHI.

Technical Safeguards

Technical safeguards are the technology controls that protect ePHI and control access to it. This is the area of most active OCR enforcement focus in 2025–2026, and the area where the proposed rule would make the most significant changes.

Access Controls (Required)

Implement technical policies to allow only authorised persons to access ePHI. Specifically:

Unique user identification (Required): Every user must have a unique identifier — no shared logins, no shared accounts, no generic credentials used by multiple staff members. If your EHR or scheduling system has a single login shared among staff, this is a current violation.

Emergency access procedure (Required): Establish procedures for obtaining necessary ePHI during an emergency when normal access controls cannot be used.

Automatic logoff (Addressable): Implement automatic session termination after a defined period of inactivity. In practice, OCR expects this to be implemented on all workstations and applications accessing ePHI.

Encryption and decryption (Addressable): Under the current rule, encryption is listed as addressable — organisations can document an alternative approach. In practice, OCR expects encryption, and the proposed rule would make it mandatory. Implement encryption at rest and in transit now.

Multi-Factor Authentication (Addressable under current rule; proposed as required)

Under the current Security Rule, MFA is not explicitly listed as a required control — but it falls under the access control and authentication requirements, and OCR has cited inadequate authentication controls in enforcement actions.

Under the proposed rule, MFA would be mandatory for all access to ePHI systems, with no size exception. OCR is already scrutinising MFA in breach investigations.

The practical position for small healthcare businesses: implement MFA on all systems that access ePHI — your EHR, your practice management system, your email, your cloud storage, your billing software. Do this now, not when a final rule eventually requires it.

Audit Controls (Required)

Implement hardware, software, or procedural mechanisms that record and examine activity in information systems containing ePHI. Maintain audit logs. Know what your EHR and practice management system log, and periodically review those logs.

Integrity Controls (Addressable)

Implement policies and procedures to protect ePHI from improper alteration or destruction. Electronic mechanisms to confirm ePHI has not been altered or destroyed must be implemented.

Transmission Security (Addressable)

Implement technical security measures to guard against unauthorised access to ePHI being transmitted over an electronic communications network. In practice, this means TLS encryption for any ePHI transmitted electronically — email with ePHI, patient portal messages, telehealth transmissions.

The Proposed Rule Changes: What Would Be Different

As of August 2026, the proposed HIPAA Security Rule update remains a proposal. OCR’s regulatory agenda had targeted spring 2026 for finalization; the OMB’s Unified Agenda now targets July 2027. The proposal may be finalized in modified form, delayed further, or (less likely given the regulatory trajectory) substantially revised.

The direction is clear regardless of timing. The proposed rule’s core changes:

Elimination of “addressable” vs “required” distinction: The proposed rule would remove the flexibility that has allowed organisations to document alternatives to specific controls. All specifications would become required, with narrow technical exceptions. This codifies what OCR has already been enforcing through the existing addressable framework.

MFA mandatory for all ePHI access: Every system accessing ePHI would require MFA. No size exceptions.

Encryption mandatory at rest and in transit: Encryption would become a required safeguard, not addressable. The proposed rule specifies encryption for all ePHI stored on any electronic media and all ePHI in transit over any network.

Network segmentation required: Covered entities would be required to segment networks so ePHI systems are isolated from general business traffic.

Written asset inventory and network map: An annual reviewed inventory of technology assets and a network map showing ePHI data flows.

Vulnerability scanning every six months; annual penetration testing.

15-day critical patch cycle; 30-day high-severity patch cycle.

One-hour workforce access termination from the time a member leaves.

72-hour Recovery Time Objective; 48-hour Recovery Point Objective for contingency plans.

Business associate notifications within 24 hours of activating an incident response or contingency plan.

Annual compliance audit requirement.

For small practices with limited IT budgets: the 180-day compliance period after a final rule is published gives time to implement. The organisations that will struggle most are those that wait until a final rule publishes to start. Starting now reduces both implementation cost and the risk of enforcement under the existing rule in the interim.

HIPAA Cybersecurity Checklist for Small Healthcare Businesses

Use this checklist against your current programme. Requirements marked (R) are required under the current Security Rule. Requirements marked (A) are currently addressable but expected by OCR. Requirements marked (P) are from the proposed rule — implement as best practice.

Administrative

• ☐ (R) Documented Security Risk Analysis completed within the past 12 months
• ☐ (R) Risk management plan documenting actions taken in response to SRA findings
• ☐ (R) All workforce members trained on HIPAA policies — completion documented
• ☐ (R) Access authorisation policy defining who can access which ePHI
• ☐ (R) Security incident procedures and an active incident log
• ☐ (R) Contingency plan including data backup, disaster recovery, and emergency mode procedures
• ☐ (R) BAAs signed with every business associate before they receive PHI
• ☐ (R) BAAs reviewed and updated annually
• ☐ (R) BAAs in place for all cloud services, EHR vendors, billing services, IT providers, and AI tools accessing ePHI
• ☐ (A) Workforce sanctions policy for HIPAA violations
• ☐ (P) Technology asset inventory reviewed annually
• ☐ (P) Network map documenting ePHI data flows

Physical

• ☐ (R) Physical access to server rooms and workstations containing ePHI restricted to authorised staff
• ☐ (R) Workstation screen position and lock policy implemented and followed
• ☐ (R) Device disposal procedures ensuring secure wiping of ePHI before disposal

Technical

• ☐ (R) Unique user identifiers for every user — no shared logins on any system containing ePHI
• ☐ (R) Automatic logoff on workstations and applications after inactivity (A)
• ☐ (R) Audit logging enabled on EHR and systems containing ePHI; logs reviewed periodically
• ☐ (A) MFA implemented on all systems that access ePHI — EHR, email, cloud storage, billing software
• ☐ (A) Encryption at rest on all devices and storage containing ePHI
• ☐ (A) Encryption in transit (TLS) on all ePHI transmitted electronically
• ☐ (A) Anti-malware protection on all systems that access ePHI, actively updated
• ☐ (A) Patches applied to operating systems and applications within defined timelines
• ☐ (P) Vulnerability scanning conducted at least every six months
• ☐ (P) Annual penetration testing
• ☐ (P) Network segmentation separating ePHI systems from general traffic
• ☐ (P) Critical patches applied within 15 days; high-severity patches within 30 days

Backup and Recovery

• ☐ (R) Tested, current backup of all ePHI
• ☐ (R) Backup copy stored off-site or in a separate cloud environment
• ☐ (R) Backup restoration tested — not just backed up but verified restorable
• ☐ (P) Recovery Time Objective of 72 hours; Recovery Point Objective of 48 hours documented and tested

OCR Enforcement: What Small Practices Are Actually Fined For

Small healthcare practices are not immune from OCR enforcement. The agency has specifically pursued small providers in recent years.

The most common violations in OCR enforcement actions against smaller providers:

No documented Security Risk Analysis. This is the most frequently cited violation. Not having conducted an SRA, having an outdated SRA, or having an SRA that was conducted but never acted upon are all cited in enforcement settlements. OCR considers a risk analysis fundamental — if you have done nothing else, document a current SRA.

Missing or inadequate Business Associate Agreements. Cloud services, EHR vendors, billing companies, IT providers — any entity with access to ePHI requires a BAA. Enforcement actions consistently cite gaps in BAA coverage.

Inadequate access controls and authentication. Shared logins, generic credentials, former employees with active accounts, no MFA on remote access — all cited in recent OCR investigations.

Insufficient encryption. Unencrypted laptops, unencrypted backup drives, unencrypted email transmissions of ePHI — regularly cited in breach-related enforcement.

No workforce training documentation. Training must be conducted and completion documented. “We train staff informally” is not adequate.

HIPAA penalty tiers (current rule):

Penalties are per violation and can apply for each affected individual’s records. A small practice breach affecting 500 patients has the potential for significant penalties even at Tier 1. The practical risk for a small practice: a single ransomware incident that exposes patient records can trigger OCR investigation, and an investigation that finds no SRA, no BAAs, and no MFA training is the path to a penalty settlement.

The Technology Controls That Matter Most

Translating HIPAA requirements into specific technology implementations:

Electronic Health Records (EHR): Verify your EHR is HIPAA-compliant (virtually all commercial EHRs are). Ensure you have a signed BAA with your EHR vendor. Enable audit logging within the EHR. Implement unique user accounts with MFA for all staff. Review access levels — clinical staff do not need access to billing functions; billing staff do not need access to clinical notes beyond what their role requires.

Email security: Never transmit ePHI via unencrypted email. Use a HIPAA-compliant secure messaging platform or encrypted email service. Many practices use their EHR’s patient portal for secure messaging — verify the portal has a BAA. If using Microsoft 365 or Google Workspace, sign the Microsoft or Google BAA and enable appropriate security controls.

Cloud storage: Google Drive, Dropbox, and OneDrive are usable for ePHI only with a BAA and appropriate security configuration. If you haven’t signed a BAA with your cloud storage provider, ePHI stored there is a HIPAA violation.

Laptops and mobile devices: All devices containing ePHI must have full-disk encryption enabled and automatic screen lock. Laptops lost or stolen without encryption are one of the most common triggers for breach notification and OCR investigation.

Backup: Maintain tested, encrypted backups of all ePHI in a location separate from the primary copy. A backup on the same server that gets hit by ransomware provides no protection. Test restoration periodically — a backup that cannot be restored is not a backup.

Anti-malware and patching: Endpoint protection on every device that accesses ePHI. All software patched and updated promptly. Healthcare is the most frequently targeted sector for ransomware — endpoint protection and patching are not optional.

Telehealth platforms: If you conduct telehealth visits, your telehealth platform requires a BAA. Most major telehealth platforms (Doxy.me, Zoom for Healthcare, Microsoft Teams with HIPAA BAA) provide BAAs.

Business Associate Agreements: The Most Common Gap

BAA management is the highest-frequency deficiency OCR finds, and it is also one of the most straightforward to address. Every vendor with access to ePHI requires a signed BAA before they can access it.

Vendors that commonly require BAAs and are commonly overlooked:

• Cloud storage services (Google Drive, Dropbox, Microsoft OneDrive)
• Email platforms (Microsoft 365, Google Workspace)
• EHR and practice management vendors (most provide BAAs; verify yours is signed)
• Medical billing services
• Telehealth platforms
• IT support providers and MSPs with access to systems containing ePHI
• Transcription services
• Cloud backup services
• AI documentation tools (AI scribes, ambient documentation)
• Patient scheduling software that stores PHI
• Any analytics or business intelligence tool connected to clinical data

For large vendors (Microsoft, Google, major EHR vendors), BAAs are typically available for acceptance in account settings or through a process documented on the vendor’s HIPAA compliance page. For smaller vendors, you may need to issue a BAA to them directly or use their provided template.

Review BAA status at least annually. When you adopt a new tool, BAA status is a pre-deployment checklist item — not something to address after the tool has been running for six months.

What to Avoid

Don’t treat the proposed rule delay as permission to pause. The proposed rule is not yet final. The current Security Rule is. OCR issued four ransomware settlements in 2026 under the existing rule. The controls the proposed rule would mandate — MFA, encryption, documented risk analysis — are already expected under the existing “addressable” framework. Waiting for a final rule to implement them is waiting until you’ve had a breach.

Don’t conduct a Security Risk Analysis once and consider it done. OCR expects an annual SRA, updated whenever significant changes occur. An SRA from three years ago that has never been updated or acted upon is worse than a current one — it demonstrates awareness of risks that were then ignored. The SRA is a living document tied to a risk management programme, not a one-time exercise.

Don’t assume a BAA template from the internet is adequate. BAAs must meet HIPAA’s specific content requirements. Templates from non-legal sources may be missing required provisions. Have any BAA template you use reviewed by a healthcare attorney, or use BAAs provided by the vendor’s legal team.

Don’t use shared login credentials on any ePHI system. Every OCR investigation looks at access controls. Shared logins make it impossible to audit who accessed patient records when. Unique identifiers for every user are a required specification — not addressable, not flexible.

Don’t neglect mobile devices. Smartphones and tablets accessing the practice’s email or EHR portal contain ePHI. Lost or stolen unencrypted mobile devices are a leading cause of breach notification reports. Implement a mobile device management policy that requires encryption, screen lock, and remote wipe capability on any device accessing ePHI.

Final Verdict

HIPAA cybersecurity compliance for a small healthcare business is not optional, not scalable by practice size, and not something that gets easier by deferring it. The current Security Rule requires administrative, physical, and technical safeguards that every covered entity and business associate must implement regardless of how many patients they see or how many staff they employ.

The honest practical priority list for a small practice that is not yet fully compliant:

1. Conduct a current, documented Security Risk Analysis. This is the single most frequently cited deficiency in OCR enforcement and the foundation of every other HIPAA security decision.
2. Audit your Business Associate Agreements. List every vendor with access to ePHI. Confirm a signed BAA is in place for each. Sign any that are missing.
3. Enable MFA on all systems that access ePHI. EHR, email, cloud storage, billing software, telehealth platform. Do this regardless of the proposed rule’s finalisation status.
4. Encrypt all ePHI at rest and in transit. Enable full-disk encryption on all laptops and workstations. Verify cloud services encrypt data. Use TLS for all ePHI transmissions.
5. Implement unique user identifiers and eliminate shared logins. Every staff member who accesses ePHI must have their own account.
6. Implement and test backup. Encrypted, off-site backup for all ePHI. Test restoration. Document RTO and RPO targets.
7. Train staff and document it. Annual HIPAA training with completion records. Security incident reporting procedures that staff actually know.

The proposed rule will eventually become final in some form. When it does, the practices that have implemented the controls above will have a manageable incremental compliance programme. The ones that haven’t will face a comprehensive implementation requirement on a compressed timeline — during which OCR enforcement continues.

Frequently Asked Questions

Does HIPAA apply to my small solo practice?

Yes, if you transmit any health information electronically — which includes billing to Medicare, Medicaid, or any insurance plan electronically. Nearly every healthcare provider that accepts insurance is a covered entity. If you operate on a strictly cash-pay basis with no electronic transmissions of health information, HIPAA may not apply, though state-level health privacy laws may still impose obligations. Consult a healthcare attorney if you’re genuinely uncertain about your covered entity status.

What is a Security Risk Analysis and how often do I need to do it?

A Security Risk Analysis (SRA) is a documented assessment of the risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your organisation. It must identify where ePHI exists, what threats exist to it, how likely those threats are, what the potential impact would be, and what controls you have in place to mitigate them. OCR expects an SRA to be conducted at least annually and updated whenever significant environmental changes occur — new software, new staff, new locations, new systems, or after any security incident. An SRA conducted once years ago and never updated does not satisfy the requirement. Several HIPAA-specific SRA tools and templates are available from HHS and from commercial HIPAA compliance platforms; for a small practice, these guided tools are typically adequate.

What is a Business Associate Agreement and who needs one?

A Business Associate Agreement (BAA) is a legally required contract between your practice and any entity that creates, receives, maintains, or transmits ePHI on your behalf. Before any third party handles your patients’ ePHI, a signed BAA must be in place. Common business associates include EHR vendors, billing services, IT support providers, cloud storage services, telehealth platforms, and AI documentation tools. For major vendors (Microsoft, Google, major EHR companies), BAAs are typically available for acceptance through the vendor’s account settings or HIPAA compliance page. For smaller vendors, you may need to provide or negotiate a BAA. If a vendor refuses to sign a BAA or claims not to need one despite handling your PHI, you cannot use that vendor for ePHI — that is a compliance violation.

Is the proposed HIPAA Security Rule update in effect in 2026?

No. As of August 2026, the proposed rule is not final. HHS published a Notice of Proposed Rulemaking on January 6, 2025, and the public comment period closed March 7, 2025. OCR has not yet published a final rule; the OMB’s Unified Agenda now targets July 2027 for final action. The current HIPAA Security Rule — the one adopted in 2003 — remains the law OCR enforces. However, the controls the proposed rule would mandate (MFA, encryption, documented risk analysis) are already expected by OCR under the existing addressable framework, and OCR’s enforcement posture in 2026 reflects those expectations. Implement these controls now rather than waiting for finalization.

What is the difference between HIPAA’s Privacy Rule and Security Rule?

The HIPAA Privacy Rule governs how covered entities may use and disclose PHI in any form — paper, oral, or electronic. It establishes patient rights to access, amend, and receive an accounting of disclosures of their health information. The HIPAA Security Rule applies specifically to electronic PHI (ePHI) and requires administrative, physical, and technical safeguards to protect it. Both rules apply to covered entities and business associates. This article focuses on the Security Rule’s cybersecurity requirements. The Privacy Rule’s requirements — notice of privacy practices, patient access rights, minimum necessary principle, authorisation requirements for certain disclosures — are a separate compliance area that small practices must also address.

This article provides general educational information about HIPAA Security Rule requirements. It is not legal advice. The proposed HIPAA Security Rule update described is as of August 2026 and not yet final; requirements may change upon finalization. Healthcare businesses with specific compliance questions should consult a qualified healthcare attorney or HIPAA compliance professional. For authoritative guidance, see the HHS Office for Civil Rights HIPAA resources and the HHS HIPAA Security Rule.

Related reading on SmallBiz Defense:

• Best Backup Solutions for Small Business in 2026: Cloud + On-Premise (Tested)
• Best Multi-Factor Authentication (MFA) Apps for Business in 2026 (Reviewed)
• Security Awareness Training for Small Business: KnowBe4 vs Proofpoint vs Cofense (2026)