The rule is written for organisations with a compliance department. Most practices do not have one. Here is the honest minimum, and what auditors actually ask for.
The HIPAA Security Rule is about twenty pages of regulation that has generated several thousand pages of guidance, almost all of it written for organisations with a compliance function. A fourteen-person dental practice or a three-partner therapy clinic does not have one of those, and the gap between what the rule expects and what a small practice can realistically do is where most of the anxiety lives.
What follows is not legal advice, and you should read the actual rule or take proper counsel before relying on anything. What it is: the shape of what is required, written for somebody who has to actually do it.
The structure, in one paragraph
The Security Rule has three groups of safeguards: administrative, physical and technical. Within those, each requirement is either required or addressable. Addressable does not mean optional. It means you either implement it, or you document why it is not reasonable for your organisation and what you do instead. The documenting-why is the part people skip, and it is the part that turns a gap into a finding.
That is the whole structure. Everything else is detail.
The risk analysis is the one you cannot skip
If you do one thing, do this. A documented risk analysis is explicitly required, it is the first thing requested in any investigation, and its absence is the most commonly cited failure in enforcement actions.
It does not have to be elaborate. For a small practice it is a document that lists:
- Where electronic protected health information actually lives. All of it. The practice management system, yes, but also the email where referrals arrive, the scanner that drops files on a shared folder, the laptop somebody takes home, the backup drive in the cupboard, the messaging app two staff use because it is faster.
- What could reasonably go wrong with each one.
- How likely and how bad.
- What you are doing about it, or why you have accepted it.
A practice of fifteen people can produce this in a day and a half. The hard part is the first bullet, because the list is always longer than anyone expects, and because the items nobody mentions are usually the risky ones.
Review it annually and after any significant change. Date it. An undated risk analysis is a document somebody wrote once.
Business associate agreements, and the trap in them
Anyone who handles PHI on your behalf needs a business associate agreement. Your IT provider, your cloud backup vendor, your billing company, your shredding service, your practice management software vendor.
Two things practices get wrong.
Having the agreement is not the same as the vendor being suitable. A signed BAA from a provider who stores your backups unencrypted in a jurisdiction you have not asked about protects you contractually and not much else. Ask what they actually do.
The list is never complete. The transcription service somebody started using last year, the new online booking tool, the AI note-taking assistant a clinician trialled. Each of these is a business associate relationship created by a person who was solving a practical problem and was not thinking about the Security Rule. Put a standing item on the agenda: what new tools are we using.
The technical controls that matter most
The rule is deliberately technology-neutral, which is correct and unhelpful. In practice, for a small practice running on Microsoft 365 or Google Workspace, the controls that close the most real risk are these.
Multi-factor authentication on everything. Required in spirit under access control, and the single highest-value control available to you. Stolen credentials are how most small-practice breaches start.
Encryption at rest and in transit. Addressable rather than required, which surprises people. In practice, modern cloud platforms do this by default and your documentation should say so. The gap is usually local: the laptop without disk encryption and the backup drive in the drawer.
Unique user accounts. Required. The shared reception login used by four people is the most common violation in small practices and it defeats every audit control downstream of it.
Automatic logoff. Addressable. Set it on workstations in clinical areas. This is one of the few requirements written with a physical waiting room in mind.
Audit controls. Required. You need to be able to reconstruct who accessed what. Check that your practice management system logs this, how far back, and whether anyone has ever looked.
Breach notification, and the sixty-day clock
If PHI is disclosed without authorisation, you have obligations with deadlines, and the clock starts when you discover it or reasonably should have.
The practical implication is that you need two things written down before anything happens: who decides whether an event is a reportable breach, and who they call. A practice discovering a possible breach on a Friday afternoon should not also be discovering that nobody knows the process.
Write a one-page incident procedure. Names, numbers, first three steps. Put it somewhere findable that is not the system that might be down.
The most expensive part of a small breach is usually not the breach. It is the two weeks lost deciding what to do while the notification deadline runs.
Training, and making it not useless
Training is required, annual, and almost universally delivered as a video nobody watches.
The version that works in a small practice is twenty minutes, in person or on a call, twice a year, built around what actually happens to practices like yours. What a phishing email asking for a payroll change looks like. Why the shared login matters. What to do if a laptop goes missing. Who to tell if you think you have clicked something.
Record that it happened, who attended, and what was covered. That record is the evidence.
What an auditor actually asks for first
In the investigations we have supported, the opening requests are consistent and short:
- 1.Your current risk analysis, with its date.
- 2.Your written policies and procedures.
- 3.Evidence of workforce training.
- 4.Your business associate agreements.
- 5.Your incident response documentation, and any incidents.
Notice that four of the five are documents rather than technology. A practice with good controls and no documentation looks worse on paper than a practice with mediocre controls that are written down. That is not a reason to let the controls slide. It is a reason to take the paperwork as seriously as the configuration, because it is the paperwork that gets examined.
A reasonable sequence
If you are starting from nothing, this order keeps the pressure where the risk is:
Do the risk analysis first, because everything else is prioritised by it. Turn on MFA everywhere while you are writing it, because it does not need the analysis to be obviously worth doing. Then close the inventory gaps the analysis found, in order. Then write the policies to match what you now actually do, which is much easier than writing them first and trying to live up to them.
