HIPAA Policies and Procedures: A Small Practice Guide

Most guides on this topic are written by companies that sell you the documents at the end. That is not a criticism, it is just worth knowing while you read, because it shapes the answer. The message tends to be that you need 45 or 65 or 69 policies and that assembling them is a project.

The number is not the point. What an investigation asks is whether every applicable requirement is addressed in writing somewhere, whether the writing describes what you actually do, and whether you have records showing it happened. A practice with twenty well-organized policies that are true passes that test. A practice with sixty-nine purchased documents describing a workflow nobody follows fails it, and fails it worse than having nothing, because a policy you did not follow is evidence you knew the requirement.

This guide is written for the person who ended up owning compliance at a small practice without asking to: the office manager, the practice manager, the owner. It covers what the rules require, the difference between a policy and a procedure with concrete pairs, a working minimum set, what addressable really means, the retention rule that changes how you version documents, and where the proposed Security Rule update actually stands. I build the training records, document controls, and offboarding workflows this depends on at FirstHR. This is general information rather than legal advice, and HIPAA rules are under active revision, so verify current requirements before you act.

What Are HIPAA Policies and Procedures?

HIPAA policies and procedures are the written rules a covered entity or business associate adopts to comply with the Privacy, Security, and Breach Notification Rules, together with the operational steps that put those rules into daily practice. They are not optional documentation. They are themselves a requirement.

Two features of that definition drive everything else on this page.

The first is that the documentation obligation is separate from the substantive one. Doing the right thing is not enough; you have to be able to show the written rule that says you do it and the record showing that you did. An investigation is a documentary exercise, and a practice that behaves well without paperwork is in roughly the same position as one that behaves badly.

The second is that policies must be reasonable and appropriate for your organization. The Security Rule is deliberately flexible about how you meet its standards, taking your size, complexity, and resources into account. That flexibility is real and it is also frequently overread, which is the subject of the addressable section below.

Policy vs Procedure: The Distinction That Matters

A policy is a statement of what your organization does and why. A procedure is the instruction for how it gets done and by whom. Most small practices write two policies, call one of them a procedure, and end up with documents that describe intentions rather than operations.

The paired examples below show the same four topics written both ways. Read the right column and notice how little of it survives without a named owner and a timeframe.

What the Rules Actually Require

Three rules generate the obligations, and each one requires written policies of its own.

The Privacy Rule governs how protected health information may be used and disclosed and what rights individuals have over it. It requires a designated privacy official, workforce training, a complaint process, sanctions, and written policies and procedures covering its standards.

The Security Rule governs electronic protected health information specifically, through administrative, physical, and technical safeguards. Per HHS, a major goal of the rule is to protect ePHI while allowing regulated entities to adopt new technologies, which is why its requirements are written as standards with flexibility in how you meet them.

The Breach Notification Rule governs what happens after something goes wrong. Per HHS, individual notifications must be provided without unreasonable delay and no later than 60 days following discovery of a breach, and an impermissible use or disclosure of unsecured protected health information is presumed to be a breach unless you can demonstrate a low probability of compromise through a documented risk assessment.

Required vs Addressable: The Most Misread Word in HIPAA

Security Rule implementation specifications are labeled either required or addressable. Required means you implement it. Addressable means something considerably more demanding than the word suggests, and reading it as optional is one of the more expensive mistakes available in this area.

Addressable means you must assess whether the specification is reasonable and appropriate for your environment, and then take one of exactly three paths.

Notice what all three have in common. Each produces a written analysis. There is no fourth path where you decide the specification does not apply to a practice your size and move on without recording anything, which is nonetheless what happens in most small practices that have never had this explained to them.

Two more things worth knowing. Encryption of electronic protected health information at rest is currently an addressable specification, which is why so many practices have never encrypted a laptop and have no written analysis explaining that choice. And the proposed Security Rule update would remove the required and addressable distinction entirely, making all specifications required, which is covered further down.

The Minimum Policy Set for a Small Practice

Below is a working set grouped by the rule that drives it. It is not the shortest possible list and it is not a 69-document suite. It is the coverage a practice actually needs, organized so you can see the shape of it.

Two notes on using that list. First, consolidation is fine. Several of those bullets can live in one document if the document addresses each of them clearly. What you cannot do is drop a topic because it feels large for your size.

Second, the flexibility the Security Rule allows applies to how you meet a standard, not to whether the standard applies. A three-person dental office needs a contingency plan. It does not need the contingency plan a hospital needs. The document might be a page describing where backups live, how often they run, who verifies them, and what the office does if the record system is unavailable for a day. That page satisfies the standard. The absence of the page does not.

The Half of HIPAA That Is Actually an HR Job

A surprising share of what the Security and Privacy Rules require is not technical at all. It is workforce administration, and in a small practice that means it belongs to whoever handles hiring, onboarding, and departures rather than to whoever handles the computers.

The termination row is where small practices are most exposed and it is the least technical item on the list. Access that outlives employment is a finding waiting to happen, and it is discovered constantly, because nobody owns the last step. Fold it into a written IT offboarding checklist that is completed and filed rather than performed from memory, and treat the completed checklist as the compliance record it is. The same logic applies to the rest of offboarding.

Training is the second exposure and it fails in a specific way: the training happens and the record does not. Delivering compliance training without a dated log of who completed what leaves you in the position of having complied and being unable to show it. A simple training matrix with names, dates, and topics closes that gap for almost no effort.

The sanctions policy is third and it is the one people avoid writing because it feels punitive. It is required, and a published schedule applied consistently is considerably fairer than case-by-case improvisation. Align it with your existing approach to disciplinary action rather than running a parallel system.

The Documentation Standard

The Security Rule sets out three obligations about the documents themselves, separate from anything they say. All three are easy to satisfy and commonly missed.

Step three is the one that surprises people. Documentation that exists but is not reachable by the person expected to follow it fails the standard on its own terms. This is an argument for keeping the policy set wherever your team already goes for HR documents rather than in a separate compliance silo that only one person opens.

The Six-Year Retention Rule and What It Implies

Retain documentation for six years from the date of its creation or the date when it last was in effect, whichever is later. That phrasing carries a consequence most practices have not worked through.

That single rule dictates a document-control approach: version numbers, effective-from and last-in-effect dates on every document, and an archive rather than an edit history buried inside a word processor. It also means the retention question for a policy is answered per version, not per policy, which is why the register template below tracks superseded versions on their own rows.

Note that this obligation is about the compliance documentation, not about medical records themselves. Medical record retention is set by state law and varies considerably, and it is a separate schedule to maintain alongside your ordinary employee record retention rules.

Three sheets because three separate questions get asked. The register answers what policies exist, who owns them, which version is current, and when each retired version can finally be destroyed. The review schedule answers when everything is next due and where the evidence sits. The training log answers the question that comes up in almost every investigation and that almost nobody can answer from memory.

How to Write a Policy Somebody Will Follow

The failure mode in policy writing is restating the regulation. A document that paraphrases the CFR back at your front desk staff is compliant in form and useless in operation, and uselessness in operation is what an investigation eventually surfaces.

The header block on that template is doing more work than it looks. Version, effective date, last reviewed, next review due, and retain-until are what make the six-year rule administrable. Fill them in when you create the document and the retention question answers itself later.

Using Templates Without Creating a Liability

Templates are fine. Buying a policy suite is fine. What is not fine, and what quietly creates exposure, is adopting documents that describe a practice you do not run.

The reason is straightforward. Policies are read against evidence. If your policy says access reviews happen quarterly and there are no access review records, the policy has not helped you, it has established the standard you failed to meet and demonstrated that you were aware of the requirement. That is a materially worse position than having addressed the topic more modestly and actually done it.

The same discipline applies to any data protection policy or handbook language you adopt from a template. It is the reason a shorter employee handbook that matches reality outperforms a comprehensive one that does not, and it applies with more force here because the audience includes a federal regulator.

Keeping Policies Current

The Security Rule expects periodic review and updating in response to environmental or operational changes. It does not prescribe an interval, which in practice means annually plus event-driven, and the event-driven half is the one that catches people.

Put the annual review on a fixed date and attach it to your existing compliance calendar rather than treating it as a standalone project. The review itself is not long once the register exists: you are checking whether each policy still describes what you do, not rewriting from scratch.

The review record matters for a reason that is easy to miss: it is the artifact proving the review happened. Reviewing your policies and leaving no trace of it puts you in the same evidentiary position as never having reviewed them, which is the recurring theme of this entire topic.

The Proposed Security Rule Update

There is a substantial proposed overhaul of the Security Rule in circulation, and a great deal of published content describes it with more certainty than the facts support. Here is the accurate position.

The Office for Civil Rights published a Notice of Proposed Rulemaking in the Federal Register in January 2025. It would, among other things, remove the distinction between required and addressable implementation specifications and make all of them required, mandate written documentation of all Security Rule policies, procedures, plans, and analyses, and add a standard requiring a documented compliance audit at least once every twelve months.

What should a small practice do about a rule that may or may not arrive, in a form that may or may not resemble the proposal? Not restructure around it. But two of the proposed changes are worth acting on regardless, because they are already good practice and already show up in enforcement.

The first is documenting your addressable decisions. If the distinction is eventually removed, you will have to implement those specifications anyway. If it is not, you still owe the written analysis today. Either way the work is not wasted.

The second is the annual documented review. It is not currently a named standard in that form, but periodic review and updating already is, and a dated review record is the cheapest evidence available. A practice already doing this absorbs a large share of the proposed documentation burden without a project.

What Enforcement Actually Looks Like

Enforcement of the existing rules is active, and the pattern in recent settlements is consistent enough to plan around: cases are opened by a breach report or a complaint, and the finding that recurs is a missing or inadequate security risk analysis.

That matters for a small practice because the risk analysis is a required implementation specification, it is the foundation the rest of the Security Rule sits on, and it is the single most commonly absent document. HHS and the national health IT office jointly publish a Security Risk Assessment Tool built specifically to help small and medium-sized practices perform one, available from the HHS Security Rule page. It is free, and it produces exactly the artifact that is missing in most enforcement actions.

The tier structure is the part worth internalizing. Culpability drives the number, and culpability is assessed from documents. A practice that identified a risk, wrote down its reasoning, and had not finished remediating sits in a different tier than one that never looked. The Enforcement Rule also lets the agency weigh the nature and extent of the violation, the number of individuals affected, and prior compliance history, all of which are evidenced from your own records.

Worth adding that penalties are rarely the largest cost. Notification expense, the operational disruption of a corrective action plan under monitoring, state attorney general action, and the reputational effect on a local practice generally outweigh the assessment itself.

Where Small Practices Get Caught

The failure patterns repeat with unusual consistency in this area.

No risk analysis is first, and it is the finding behind most enforcement. It is a required specification, it is the basis for every other security decision, and a free federal tool exists to produce it.

Purchased policies that describe a practice you do not run is second. The documents establish the standard and the absence of records demonstrates the gap. Templates are a starting point, not a deliverable.

Treating addressable as optional is third. Three paths, all of them ending in a written analysis, and none of them being silence.

Access that outlives employment is fourth, and it is a workforce administration failure rather than a technical one. A completed offboarding checklist filed with the personnel record prevents it.

Training with no record is fifth. The training happened, the log does not exist, and the position is identical to not having trained.

Overwriting policy documents is sixth. The six-year clock runs from the date a version last was in effect, so a retired policy has to be archived rather than replaced in place.

Then the quieter ones. No named privacy or security official, or a designation that everyone knows and nobody wrote down. Business associate agreements that were signed once and never revisited as vendors changed. A policy set stored somewhere only the manager can reach, which fails the availability requirement on its own. And no index, so nobody can say which version of which policy is currently in effect, which is the question that opens every conversation with an investigator.

None of this requires a compliance department. It requires a named owner, a register, a review date, and the discipline to write down what you actually do rather than what a template says you should. That is the same infrastructure that makes the rest of HR at a small business function without a specialist, and it holds together or falls apart as one piece along with the rest of your workplace policies.

Frequently Asked Questions