HIPAA is not a product you install. It is a set of safeguards you implement and have to be able to prove. Here is what the rule actually asks of your technology, and what practices in western Kentucky are usually missing.
The phrase “HIPAA compliant” gets attached to firewalls, backup products, email services, and IT companies. It is close to meaningless. HIPAA compliance is an organizational state made of technical safeguards, physical safeguards, written policies, workforce training, and documented risk decisions. A product can support it. No product confers it, and neither does an IT provider.
What an IT provider genuinely owns is the technical half: access control, encryption, audit logging, integrity, authentication, transmission security, and the contingency planning that makes recovery possible. We can also produce the evidence that those controls exist, which is where most small practices come up short. The safeguards are frequently in place. The documentation proving it, on the day somebody asks, is not.
That gap between doing it and being able to show it is the recurring theme of this page. It matters most in the three situations where a practice actually gets asked: a breach investigation, a cyber-insurance renewal questionnaire, and a payer or partner security review. In all three, an undocumented control counts for very little.
We work with medical practices, dental offices, and specialty clinics across Murray, Calloway County, and western Kentucky. What follows is what we look for, what the rule requires, and where the realities of practice technology — imaging equipment on ten-year-old operating systems, vendors with strong opinions, schedules that cannot absorb a lost afternoon — make the textbook answer the wrong one.
What the Security Rule Asks For
These map to the technical and physical safeguard sections of the HIPAA Security Rule. Everything here is implementable in a ten-person practice without an enterprise budget.
Unique accounts for every person — no shared "frontdesk" login — with role-based permissions so the billing coordinator and the hygienist do not see the same things. Automatic logoff on unattended workstations, and an emergency access procedure documented for the situations where normal controls have to be bypassed.
Full-disk encryption on every workstation and laptop, encryption in transit for anything crossing a network, and encrypted backups. Addressable in the rule's language, indefensible to skip in practice — and properly encrypted data that goes missing generally does not become a reportable breach.
Logging on systems that hold ePHI, retained long enough to be useful, and reviewed rather than merely collected. When somebody asks who accessed a record and when, the answer needs to exist before the question is asked.
Controls that prevent improper alteration or destruction of records, and mechanisms that verify a person is who they claim to be — which in 2026 means multi-factor authentication on email, remote access, and any cloud-hosted EHR, not a password policy alone.
The rule requires a data backup plan, a disaster recovery plan, and an emergency mode operation plan. All three are required implementation specifications, not suggestions, and the third one is the one nearly every small practice is missing: how you keep seeing patients while the systems are down.
Documented handling of hardware moving in and out of the practice, and verified sanitization before any device holding ePHI is disposed of, sold, or returned at lease end. Copiers and imaging workstations are the two most commonly forgotten.
The Most Commonly Missing Item
If a practice we assess is missing one thing, it is this. The Security Rule requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information — and requires that you can produce it on request.
It is not a vulnerability scan, a checklist from a vendor, or a certificate. It is a document that says where the data is, what could happen to it, how bad that would be, and what you chose to do. It must be reviewed periodically and after significant changes, which means a copy from four years ago and two servers back does not satisfy it.
We do not write your policies or run your compliance program — that belongs inside the practice, usually with your privacy or security officer and often with a compliance consultant. What we provide is the technical half: the accurate inventory of where ePHI lives, what controls are actually in place, and what the real gaps are. That is the part most risk analyses get wrong, because it is the part that requires actually looking at the network.
A missing or stale risk analysis is one of the most frequently cited findings in federal enforcement actions against small practices. It is also one of the cheapest to fix.
Business Associate Agreements
Any vendor that creates, receives, maintains, or transmits protected health information on your behalf is a business associate. An IT provider with administrative access to systems holding ePHI is unambiguously one, and the agreement belongs in place before access is granted rather than chased down afterward.
It is worth reading rather than filing. Three things to check: whether it covers subcontractors the provider uses (many do not, and cloud backup or monitoring vendors sit downstream of your IT company), what breach notification timeline it commits them to with you, and what happens to any ePHI they hold when the relationship ends.
Then apply the same standard across the rest of your vendor list. Practices are usually diligent about the EHR and the billing company and much less so about the imaging vendor with permanent remote access, the answering service, the shredding company, and the IT provider who has been there twelve years on a handshake. An inventory of every business associate, with a current signed agreement and a note about what access they hold, takes an afternoon to build and closes a real gap.
Contingency Planning
Three of these five are required implementation specifications, not optional ones. Most practices have the first, have never written the second, and have never heard of the third.
| Specification | Status | What it means in a small practice |
|---|---|---|
| Data backup plan | Required | Retrievable exact copies of ePHI. In practice: practice management databases, imaging archives, document stores, and anything on a local drive that nobody remembers is there. |
| Disaster recovery plan | Required | A documented procedure to restore lost data. Not a product — a written sequence naming what comes back first, who does it, and how long it should take. |
| Emergency mode operation plan | Required | How the practice continues to protect ePHI and keep operating during an emergency. This is the paper-charting, phone-tree, reschedule-the-afternoon plan, and it is the most commonly missing of the three. |
| Testing and revision procedures | Addressable | Periodic testing of the plans above. Addressable, but a plan nobody has ever tested is functionally a hypothesis — and the test is what turns "we have backups" into a known recovery time. |
| Applications and data criticality analysis | Addressable | Which systems matter most and in what order they must return. Ten minutes of thought here changes a recovery from improvised to sequenced. |
Two practical requirements sit underneath all five. Backups of ePHI must be encrypted, including the off-site copy, and at least one copy must be out of reach of anything that compromises the network — immutable, air-gapped, or held in an account with separate credentials. Ransomware that encrypts a practice server and the backup drive plugged into it has taken both, and that scenario is the reason practices end up paying.
“Addressable” is also worth translating, because it causes real confusion. It does not mean optional. It means you implement the specification, or document why it is not reasonable and appropriate in your environment and implement an equivalent alternative. An undocumented decision to skip an addressable item is simply a gap.
Dental, Clinic & Specialty Specifics
Practice technology has constraints that general IT advice ignores. These six come up in nearly every practice we assess.
Cone beam, panoramic, intraoral sensors, ultrasound, and lab analyzers frequently ship with a controller PC the manufacturer will never certify on a current OS. Replacing a working five-figure unit over an operating system is rarely the right call. Segmentation, removing internet access, dedicated accounts, and pushing images to a modern backed-up server are — with the decision and the compensating controls written into the risk analysis.
Dentrix, Eaglesoft, Open Dental, and most clinic EHRs have firm opinions about SQL versions, server specifications, backup methods, and which antivirus exclusions are required. Work against the vendor's requirements and you lose support at the worst possible moment. We configure to their specifications and coordinate with their support rather than around it.
A practice that cannot see charts is not merely inconvenienced. Schedules get rebuilt, patients get turned away, and clinical decisions get made with less information. Recovery time objectives for a practice have to be set against the schedule, not against a generic service level.
Referrals, imaging, and insurance correspondence all end up in the inbox. That makes email retention, multi-factor authentication, and a secure send option a compliance concern rather than a convenience. Mailbox compromise is the most common route to a reportable breach at practices this size.
Imaging vendors, PM software support, billing companies, and equipment manufacturers all hold remote access. Each one is a business associate and a potential entry point. A current inventory of who can reach your network, through what tool, and under which agreement is straightforward to keep and almost never kept.
Front-desk and clinical turnover in a small practice is steady. Accounts that outlive employment are an audit finding and a genuine risk. Offboarding needs to be a checklist that runs the same day, covering the PM system, email, imaging, cloud services, and building access.
Our Scope
We own the technical safeguards and the evidence behind them. We do not write your privacy policies, run your training program, or serve as your compliance officer — those belong inside the practice, and any IT company claiming otherwise is overselling.
We work inside whatever practice management and imaging systems you already use, to their vendors’ specifications, rather than asking you to change software your entire workflow depends on. And we are in Murray, so when something needs hands on the hardware between patients, that is a drive rather than a dispatch queue.
FAQ
No IT company can, and any that says otherwise is selling something. HIPAA compliance is a combination of technical safeguards, physical safeguards, administrative policies, workforce training, and documented risk management — and the administrative half belongs to the practice, not the vendor. What an IT provider can do is implement and maintain the technical safeguards correctly, produce the evidence that they exist, support the required risk analysis, and sign a business associate agreement covering their own role. Anyone offering a "HIPAA compliant" product that makes you compliant by purchase has misunderstood the rule or is hoping you have.
Yes, and it is the single most commonly missing item in small practices. The Security Rule requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information — and it requires you to be able to produce it. It is not a checklist or a scan result. It identifies where ePHI actually lives, what could go wrong, how likely and how damaging each scenario is, and what you decided to do about it. It also has to be reviewed periodically and after significant changes, which means a one-time analysis from four years ago does not satisfy it.
Technically it is "addressable" rather than "required," which is one of the most misunderstood words in the rule. Addressable does not mean optional — it means you must implement it, or document a reasoned explanation of why it is not reasonable and appropriate in your environment and implement an equivalent alternative. In practice, for laptops, backups, portable media, and anything crossing a network, there is no defensible reason not to encrypt in 2026. There is also a strong practical incentive: properly encrypted data that is lost or stolen generally does not trigger breach notification, because it is not considered unsecured protected health information.
Yes. Any vendor that creates, receives, maintains, or transmits protected health information on your behalf is a business associate, and IT providers with administrative access to systems holding ePHI are squarely in that category. The agreement should be signed before access is granted, not afterward. It is worth reading rather than filing: check that it covers subcontractors the provider uses, specifies breach notification timelines to you, and addresses what happens to any ePHI they hold when the relationship ends. A provider who hesitates to sign one, or who sends a one-paragraph version, is telling you how seriously they take the obligation.
This is extremely common — cone beam, panoramic, ultrasound, and lab equipment routinely ship with a controller PC that the manufacturer will not certify on a current operating system, and replacing the equipment is a five-figure decision. The answer is compensating controls rather than pretending the risk is not there. Isolate the machine on its own network segment or VLAN with strict rules about what it can reach, remove internet access entirely where the workflow allows, restrict it to a dedicated account with no email and no browsing, keep images flowing to a modern, backed-up server rather than living on the controller, and document the decision and the controls in your risk analysis. That documentation is what turns an unavoidable technical constraint into a managed risk.
Three things at once, and only the first is technical. Clinically, you cannot see charts, so you either run on paper or reschedule — for a busy practice that is thousands of dollars a day before anything else. Legally, ransomware affecting ePHI is presumed to be a reportable breach unless a documented four-factor risk assessment demonstrates a low probability of compromise, which starts a notification clock. Practically, you have to rebuild while continuing to see patients. The variable that decides how bad all three get is whether you had off-site, immutable backups and had actually tested a restore — practices that recover in a day almost always have both, and practices that pay almost always discovered their only backup was on the same network that got encrypted.
The compliance obligations are identical; the technology is not. Dental practices are typically heavier on imaging — intraoral sensors, panoramic and cone beam units, each with its own vendor software and often its own dedicated workstation — and lighter on interoperability. Medical clinics tend to carry more integration load: an EHR exchanging data with labs, pharmacies, clearinghouses, and a patient portal, plus more remote access for providers. Dental practices more often run their practice management system on a local server, which makes on-premise backup and server health critical. Clinics are further into cloud-hosted EHRs, which shifts the emphasis toward internet reliability, endpoint security, and identity management.
Almost everything HIPAA asks for technically is ordinary security practice applied consistently and written down. For the underlying work, see cybersecurity in Murray, KY and backup and disaster recovery. If you are weighing providers, our IT pricing guide lists the questions that make competing quotes comparable.
A free assessment covering where ePHI lives, which safeguards are really in place, whether a restore has ever been tested, and what the gaps are — written down, ranked, and yours to keep.
Murray, KY 42071 • Serving Calloway County and western Kentucky
Ready to Transform Your Technology?
Let’s discuss how we can help streamline your IT infrastructure, improve security, and accelerate your business growth with our comprehensive technology solutions.
Ready to discuss your technology needs? Our team of experts is here to help you find the perfect solution for your business. Contact us today for a free consultation.
Phone
(270) 807-1000Service Area
Murray, KY & Western Kentucky — Remote Support Available Nationwide
Support Hours
24/7 Emergency Support
For urgent technical issues or emergency support, our team is available 24/7 to ensure your systems stay operational.