Home / Guides / HIPAA IT for small practices
HIPAA IT requirements for small practices, in plain English
The HIPAA Security Rule is written to be scalable — which is good news for a five-doctor clinic and confusing for everyone. Here's what it actually requires of your IT, straight from the rule, without the compliance-vendor theatrics.
The HIPAA Security Rule requires small practices to protect electronic patient data (ePHI) with three kinds of safeguards — administrative, physical, and technical — anchored by a mandatory risk analysis. It's deliberately scalable to your size, doesn't mandate specific products, and starts with one question: where is our patient data, and what could go wrong with it? The most-cited enforcement failure is the simplest: never doing the risk analysis.
Small medical, dental, and rehabilitation practices get squeezed between two bad sources of HIPAA advice: compliance vendors who imply you need to buy everything, and forum threads that imply you need nothing. The rule itself is calmer and clearer than either. We've built systems for healthcare providers — including a hospital where security and uptime were patient-safety issues — so here's the plain-English version, grounded in what the HHS Security Rule actually says.
First, the vocabulary that trips everyone up
ePHI is electronic protected health information — patient data in electronic form (your EHR, imaging, emails about patients, backups). Notably, the Security Rule covers electronic data specifically; paper records fall under the Privacy Rule instead. A covered entity is you — the provider. A business associate is any vendor that handles ePHI on your behalf: your EHR host, your IT provider, your cloud backup service. Since the HITECH Act, business associates are directly liable under the Security Rule too, and you're required to have a Business Associate Agreement (BAA) with each — which is why "does this vendor sign a BAA" is a gating question, not a nicety.
The rule is scalable — and that's the point
HHS designed the Security Rule to be "flexible, scalable, and technology neutral." It explicitly tells you to choose measures reasonable and appropriate for your size, your technical capabilities, the cost, and your actual risks. A five-person clinic is not held to a hospital's implementation — but it is held to the same standards, sized appropriately. That word "reasonable" is doing real work: it's why there's no official checklist of products, and why the rule keeps pointing back to your own risk analysis as the thing that decides what's reasonable for you.
The three safeguards, in practice
Administrative safeguards — the biggest bucket
These are the policies, people, and processes — and per the rule, this is the largest category. In plain terms, a small practice needs: a Security Management Process (built on the risk analysis, below); an assigned security official — one named person responsible, even part-time; workforce access controls so staff can reach only the ePHI their role needs; security awareness training for everyone; incident response procedures for suspected breaches; and a contingency plan — which explicitly includes data backup and disaster recovery so care continues if systems fail. That last one maps directly to real IT work, covered in our managed IT and backup practices.
Physical safeguards — the world of doors and drives
Controlling physical access to systems and data: facility access controls (the server or network closet is locked, access is limited), workstation security (screens with ePHI aren't visible from the waiting room; devices lock when unattended), and device and media controls — governing how hardware and media holding ePHI move in and out, and requiring that ePHI is properly removed before a device is reused or disposed. The old workstation sold with the patient database still on it is a textbook physical-safeguard failure.
Technical safeguards — the IT controls
The technology protecting ePHI: access control (unique logins, so only authorized people reach ePHI — and audit trails mean something), audit controls (record and examine activity in systems holding ePHI), integrity controls (ensure ePHI isn't improperly altered or destroyed), authentication (verify people are who they claim — in practice, strong authentication and MFA), and transmission security (guard ePHI moving over networks — encryption in transit). Encryption appears here as an addressable specification, which is widely misunderstood — see the FAQ.
The one thing you cannot skip: the risk analysis
If you do nothing else, do this. The Security Rule requires an "accurate and thorough" risk analysis of the threats and vulnerabilities to your ePHI, and it's the foundation the entire rule rests on — every other safeguard's implementation depends on what your risk analysis found. It's also, by a wide margin, the most common finding in HHS enforcement actions: practices penalized after a breach are repeatedly cited for never having conducted a proper risk analysis in the first place. A right-sized analysis for a small practice answers: where does ePHI live (EHR, devices, cloud, backups, email), what could go wrong (theft, ransomware, snooping, loss), how likely and how bad, and what will we do about each. Written down, dated, and revisited when things change. HHS even publishes guidance to help you do it.
A practical starting sequence for a small practice
Turn the rule into a to-do list: 1) conduct the risk analysis — it defines everything else; 2) appoint your security official and get BAAs signed with every vendor touching ePHI; 3) close the technical basics — unique logins, MFA, encryption on laptops and in transit, audit logging on the EHR; 4) lock the physical layer — screens, closets, device disposal; 5) write the short policies the rule requires and train staff; 6) stand up the contingency plan — tested backups and a downtime procedure, because in healthcare an outage is a patient-safety event, not just an IT one; 7) keep documentation, which the rule requires you to retain for six years. Much of steps 3–6 overlaps our general security checklist — HIPAA mostly adds the documentation and the risk analysis on top of good hygiene.
What a breach actually triggers (and why prevention is cheaper)
The Security Rule doesn't stand alone — it sits next to the Breach Notification Rule, and understanding what a breach sets in motion is the clearest argument for doing the boring prevention. If unsecured ePHI is compromised, a covered entity generally must notify affected individuals, notify HHS, and — for larger breaches — notify the media, within defined timeframes. Business associates must notify the covered entity. That's before the reputational damage, the patient trust erosion, and the HHS investigation that frequently follows and asks, first, to see your risk analysis. This is why the cheap path is prevention framed as documentation: the same controls that reduce breach likelihood (access control, encryption, audit logs, tested backups) also produce the evidence that a breach was handled responsibly and that you weren't negligent — which materially affects how an investigation goes. One note the rule makes practically important: encrypted ePHI that's lost or stolen may not trigger notification at all, because encrypted data rendered unreadable can fall outside "unsecured" PHI. That single fact turns encryption from a checkbox into a business decision with direct financial consequences — a stolen encrypted laptop can be a non-event, while the same laptop unencrypted is a reportable breach.
Frequently asked questions
Is encryption required by HIPAA?
It's an "addressable" specification — which does not mean optional. Addressable means you must implement it where reasonable and appropriate, or document a legitimate reason why not and use an equivalent alternative. In practice, for laptops, portable media, and data in transit, encryption is almost always reasonable and appropriate — and choosing not to encrypt is a decision you'd have to defend after a breach. Treat it as required unless you have a documented, defensible exception.
Do small practices actually get audited or fined?
Yes. HHS's Office for Civil Rights enforces the rule across entities of all sizes, and small practices appear in resolution agreements — frequently after a breach triggers investigation, with the missing or inadequate risk analysis cited as a core failure. The risk analysis is both the requirement and the thing most likely to be examined.
Does our IT company make us HIPAA compliant?
They implement and maintain many technical and physical safeguards, and they're a business associate who must sign a BAA and meet the rule directly — but compliance is the practice's legal responsibility. A good IT partner does the risk analysis with you, closes technical gaps, and gives you documentation; they can't absorb your accountability, and any vendor claiming to "make you HIPAA certified" is overselling — there's no official HIPAA certification.
What's a Business Associate Agreement and who needs one?
A BAA is a required written contract obligating a vendor that handles your ePHI to protect it under the Security Rule and report incidents. You need one with every such vendor — EHR host, IT provider, cloud backup, billing service. No BAA means you can't lawfully share ePHI with them, and their breach becomes squarely your problem.
Are we a covered entity or a business associate?
Covered entities are health plans, clearinghouses, and providers who transmit health data electronically for standard transactions — most practices. Business associates are vendors handling ePHI on their behalf (IT providers, EHR hosts, billing). If you provide care and bill electronically, you're almost certainly a covered entity; if you serve those who do, you're likely a business associate — and both must meet the Security Rule.
How often should we redo the risk analysis?
The rule requires ongoing, periodic review rather than a fixed interval — practically, review annually and whenever something material changes: a new EHR, a move, a new service line, or after any incident. It's a living document, not a one-time certificate, and dating each revision is part of the compliance evidence.
Run our HIPAA risk analysis Who we work with
Sources: HHS — Summary of the HIPAA Security Rule (45 CFR Part 160 and Part 164, Subparts A and C). General information, not legal advice; confirm your obligations against the Security Rule and, where warranted, with counsel.