Managed IT and Cybersecurity for Columbus Medical and Dental Practices

What does the HIPAA Security Rule require of a small medical practice?

HIPAA’s applicability section, 45 CFR 164.104, covers health plans, health care clearinghouses, and any health care provider who transmits health information in electronic form in connection with a covered transaction. The Security Rule’s own applicability section, 45 CFR 164.302, applies those standards to covered entities and business associates alike. There is no threshold for headcount, revenue, or number of providers. A two-dentist office and a hospital system are equally covered, so long as the practice transmits health information electronically in connection with a covered transaction.

A provider that conducts no covered electronic transaction is not a HIPAA covered entity. Ohio law does not simply fill that gap. ORC 1349.19(B)(2) requires notice to affected Ohio residents in the most expedient time possible, and in no case later than 45 days following discovery of the breach or notification of it. Those 45 days are the outside edge. The requirement is the most expedient time possible, the same way it works under HIPAA. Two further limits matter. First, ORC 1349.19(F)(2) excludes HIPAA covered entities from that section entirely. The exclusion turns on status, so the section does not reach them even for a breach of ordinary business records such as payroll. Second, for everyone else it reaches only the narrow category of “personal information” that section defines (essentially a name paired with a Social Security number, a driver’s license or state ID number, or a financial account number with its security code), and only where the breach is reasonably believed to create a material risk of identity theft or other fraud. A breach of clinical records alone can fall outside it entirely. Read ORC 1349.19.

Two requirements sit at the center of the Security Rule. The first is a risk analysis, meaning an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the electronic protected health information (ePHI) a covered entity holds. The second is risk management, meaning security measures sufficient to reduce those risks to a reasonable and appropriate level. Both are required implementation specifications.

Other specifications are labeled addressable, including encryption of stored ePHI and encryption in transmission. Addressable is widely misread as optional. It is not. The rule calls for an assessment of whether the safeguard is reasonable and appropriate for the environment, and implementation of it where it is. Where it is not, the reasoning is documented and an equivalent alternative measure goes in place where one is reasonable and appropriate. The rule does let a covered entity weigh its size, complexity, technical capabilities, and the cost of security measures. That shapes how compliance is reached. It does not change whether it is required. Working out what a risk analysis like this actually finds in a specific practice, and turning it into security measures rather than a document that sits in a drawer, is the starting point of our cybersecurity and virtual CISO work with medical and dental practices.

How far does an EHR vendor’s security reach?

Not to the practice’s own equipment. An EHR host secures its own platform. It is a business associate, and it is directly liable under the Security Rule for what it holds. Its responsibility does not extend to the workstations, the email or the network on the practice side. The rule calls for a written business associate agreement giving satisfactory assurances that the vendor will appropriately safeguard the information. What that agreement does not do is move a covered entity’s own obligations onto the vendor.

The risk analysis has to cover all the ePHI a covered entity creates, receives, maintains or transmits. That includes the workstation in the operatory, the laptop at the front desk, the email that carries a referral, the multifunction scanner, and the wireless network clinical devices share with everything else. None of that lives inside the EHR.

If a business associate suffers a breach of unsecured PHI, it has to notify the covered entity without unreasonable delay and no later than 60 calendar days after it discovers the breach. The covered entity’s duty to notify patients runs from its own discovery, and the standard at 45 CFR 164.404(b) is without unreasonable delay and in no case later than 60 calendar days. Those 60 days are the outside edge. Acting without unreasonable delay is what the rule asks for. Depending on the relationship, a vendor’s discovery can count as the covered entity’s discovery, which is a question worth settling in the contract before it matters.

Patient letters are not the end of it. 45 CFR 164.408 also calls for a report to HHS: contemporaneously with the patient notices if the breach affected 500 or more people, and within 60 days of the end of the calendar year if it affected fewer. A large breach can also require notice to prominent media outlets under 45 CFR 164.406. Either way, the letter goes out with the practice’s name on it. Covering the practice’s side of that line, the workstations, the network, and the email the EHR never touches, is Managed IT and Cyber Security work, separate from whatever the EHR vendor already secures on its own platform.

What does a ransomware attack mean for a practice under HIPAA?

OCR’s position is that when ransomware encrypts unsecured ePHI, an impermissible disclosure has occurred and a breach is presumed. The way out is a demonstration, through a documented four-factor risk assessment under 45 CFR 164.402, that there is a low probability the protected health information was compromised. The covered entity carries that burden of proof. So the line between an IT incident and a reportable breach with patient notification often comes down to how good the logging and documentation were before the attack.

The Security Rule already anticipates this. Under the contingency plan standard, a data backup plan, a disaster recovery plan and an emergency mode operation plan are all required specifications. Periodic testing and revision of the plan is an addressable specification, at 45 CFR 164.308(a)(7)(ii)(D).

Beyond that minimum, what actually survives a ransomware event is backups you have restored from, copies an attacker holding your admin credentials cannot reach, and a written answer to how you keep seeing patients while systems are down. For most practices an honest risk analysis points at those anyway, because 45 CFR 164.308(a)(1)(ii)(B) asks for security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. Network operations and ongoing security work sit on top of that. In practice, a backup you have restored from is the floor.

Can your practice actually evidence the controls its cyber renewal asks about?

The renewal questionnaire is short, and the questions on it are narrower than they look. Is multifactor authentication enforced on email and on remote access. Is endpoint detection running on every workstation and server. Are backups tested by restoring from them. Do staff complete security awareness training, and how often. You sign the form, so the answers are yours to stand behind. The work sits in the evidence: being able to hand someone a document showing the control was in place on the day you signed.

For a small practice the gap usually shows up in the exceptions. Multifactor authentication is either enforced by policy or it is not, and most practices find accounts sitting outside it. The usual ones are a shared front-desk login, the mailbox the scanner sends to, and a service account a legacy imaging system uses to authenticate. Evidencing “enforced” means producing the policy, the accounts it covers, and the exceptions written down with a reason next to each. Endpoint coverage evidences the same way, as a coverage report measured against a device inventory, which means a laptop left off the inventory is not counted in the report and is not running the agent either. A restore test evidences as a date, the systems restored and the result. Training evidences as completion records with names on them.

None of this comes from your EHR host. The vendor’s security attestation describes the platform it runs. It does not describe the equipment on your side of that line. Your side is what the questionnaire is asking about, and the same side the Security Rule risk analysis reaches. Cloud IT services put the tenant controls in place, and cyber security work covers the user access controls and password policies underneath them. Managed firewall protection and Network Operations Center work cover the firewalls, switches, access points and wireless behind those answers. Network monitoring and system administration keep the device inventory current enough to measure coverage against, backup and disaster recovery produces the dated restore records. Compliance-as-a-Service work is where those artifacts are tracked between renewals, so the next questionnaire is a file you update instead of a month of asking around.

Is the HIPAA Security Rule changing, and what is in force today?

HHS published a proposed rule on January 6, 2025 that would tighten the Security Rule considerably, adding requirements around multifactor authentication, encryption, asset inventories and network maps, network segmentation and penetration testing, and removing the distinction between required and addressable specifications. The comment period closed on March 7, 2025. It has not been finalized and it has not been withdrawn. HHS has since moved that rulemaking to the long-term actions list in its regulatory agenda, naming July 2027 as the anticipated date for final action, after an earlier 2026 target passed with no final rule. The version in force today is the Security Rule as adopted in 2003 and amended by the 2013 Omnibus Rule. That is the version to plan against.

That said, almost everything the proposal would mandate is something an honest risk analysis would flag anyway, so the work is not wasted. The place to start is finding out where you actually stand. The Security Analysis is a paid, truly independent assessment mapped to 38 compliance frameworks, and it costs $349. It is a diagnostic that shows you where you stand. It is not the Security Rule risk analysis itself. That one is a broader assessment of all the ePHI a covered entity creates, receives, maintains and transmits, and this is a starting point for it. It is built as something you keep and act on. There is no sales call attached to it. You can start it at https://outreach.ttscyber.com/analysis.