HIPAA Policies and Procedures: A Small Practice Guide
Which HIPAA policies and procedures you need, how a policy differs from a procedure, the six-year retention rule, and how to run them at a small practice.
This guide shows a small practice which policies and procedures the Health Insurance Portability and Accountability Act (HIPAA) rules require, and how to keep them true. 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 several dozen policies and that assembling them is a project.
The number is not the point. An investigation asks 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 several dozen 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.
The 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 would rather you finish with a short set you can follow than a binder you cannot. I build the training records, document management, and task 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.
A covered entity is a health care provider, health plan, or clearinghouse that the rules apply to. A business associate is an outside vendor that handles patient information on behalf of one.
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.
| Policy | Procedure | |
|---|---|---|
| Answers | What and why | How, who, and when |
| Audience | Everyone, plus investigators and auditors | The person performing the task |
| Changes | Rarely, when intent or law changes | Often, when systems, vendors, or staff change |
| Length | A paragraph or two | As long as the steps need |
| Names people | By role, if at all | Yes, by role and ideally by position title |
| Produces | A standard to be measured against | Records that prove the standard was met |
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. Under 45 CFR 164.530, 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 (ePHI) specifically, through administrative, physical, and technical safeguards. Per the Department of Health and Human Services (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.
HHS also says 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.
Per HHS guidance, 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.
Encryption is the common example. Under 45 CFR 164.312, 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.
The proposed Security Rule update would remove the required and addressable distinction entirely, making nearly 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 full commercial 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 small dental office needs a contingency plan. It does not need the contingency plan a hospital needs.
A contingency plan for a small office might be a single 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.
Nick Anisimov, FirstHR founderThe 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.
| Requirement | What it actually is | Where it lives day to day |
|---|---|---|
| Workforce authorization and clearance | Deciding and recording who may access what, by role | Hiring and role changes |
| Termination procedures | Removing all access when someone leaves or moves roles | Offboarding |
| Security awareness and training | Delivering training and keeping dated records of who completed it | Onboarding and annual training |
| Sanctions policy | A published, applied disciplinary schedule for policy violations | Employee relations |
| Privacy training | Training on privacy policies as necessary and appropriate for each role | Onboarding |
| Documentation of all of the above | Retaining every record for six years | Personnel and compliance files |
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 the termination step 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.
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 four obligations about the documents themselves, separate from anything they say. All four are easy to satisfy and commonly missed, and a fifth, the retention rule, gets its own section next.
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. Per HHS, the Privacy Rule sets no retention period for medical records. State law governs that period and varies considerably, so it is a separate schedule to maintain alongside your ordinary employee record retention rules.
| A | B | C | D | E | F | G | H | I | J | |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Policy number | Policy title | Rule | Citation | Owner | Version | Approved | Effective from | Last in effect | Retain until |
| 2 | P-01 | Designation of Privacy and Security Officials | Privacy and Security | 164.530(a) | Practice manager | 2.0 | 2026-01-12 | 2026-02-01 | Current | Open |
| 3 | P-02 | Minimum Necessary Access by Role | Privacy | 164.502(b) | Practice manager | 1.3 | 2026-01-12 | 2026-02-01 | Current | Open |
| 4 | S-04 | Workforce Termination Procedures | Security | 164.308(a)(3) | Practice manager | 1.1 | 2025-11-03 | 2025-12-01 | Current | Open |
| 5 | S-04 | Workforce Termination Procedures | Security | 164.308(a)(3) | Practice manager | 1.0 | 2024-06-10 | 2024-07-01 | 2025-11-30 | 2031-11-30 |
| 6 | ||||||||||
| 7 |
The workbook has 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 rule text 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 skeleton below puts those six rules into a structure you can copy once per policy, so the owner, the timeframe, and the records each procedure produces are fields you have to fill rather than sections you can quietly leave out.
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 shown that you knew 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.
| Trigger | What to revisit | Typical window |
|---|---|---|
| Scheduled annual review | The full policy set against actual practice | Same month each year |
| New system or vendor with access to PHI | Access management, business associate agreement, risk analysis | Before go-live |
| Security incident or breach | Incident response, the specific control that failed, training | Within the response |
| New workforce member or departure | Access provisioning or removal, training record | At hire and final day |
| Change of privacy or security official | The designation policy itself, and every policy naming that role | Immediately |
| New location or a move | Facility access controls, workstation security, device controls | Before occupancy |
| Change in federal or state law | Whatever the change touches | Before the effective date |
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.
Dwight SchruteSales3 people
Darryl PhilbinWarehouse1 person
Kelly KapoorCustomer Service1 personThe Proposed Security Rule Update
A substantial overhaul of the Security Rule has been proposed but not finalized, and a great deal of published content describes it with more certainty than the facts support. The Office for Civil Rights (OCR) published a Notice of Proposed Rulemaking in the Federal Register in January 2025.
According to the HHS fact sheet, the proposal would, among other things, remove the distinction between required and addressable implementation specifications and make nearly 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 nearly all of 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 and the foundation the rest of the Security Rule sits on. It is also commonly missing: according to the HHS report on its 2016-2017 HIPAA audits, most covered entities and business associates had failed to implement the Security Rule requirements for risk analysis and risk management.
HHS and the national health IT office jointly publish a Security Risk Assessment Tool built specifically to help small and medium-sized practices perform a risk analysis, available from the HHS Security Rule page. It is free, and it produces exactly the document whose absence keeps turning up as a finding in OCR settlements.
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 HHS 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.
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 penalty itself.
Where Small Practices Get Caught
Small practices tend to get caught on the same six things. The first is having no risk analysis, and it is the finding that keeps recurring in enforcement. It is a required specification, it is the basis for every other security decision, and a free federal tool exists to produce it.
The second is purchased policies that describe a practice you do not run. The documents establish the standard and the absence of records demonstrates the gap. Templates are a starting point, not a deliverable.
The third is treating addressable as optional. There are three paths, all of them ending in a written analysis, and none of them is silence.
The fourth is access that outlives employment, which is a workforce administration failure rather than a technical one. A completed offboarding checklist filed with the personnel record prevents it.
The fifth is training with no record. The training happened, the log does not exist, and the position is identical to not having trained.
The sixth is overwriting policy documents. 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 there are the quieter failures. One is having no named privacy or security official, or a designation that everyone knows and nobody wrote down. Another is leaving business associate agreements untouched after they were signed, even as vendors changed.
A policy set stored somewhere only the manager can reach fails the availability requirement on its own. And with no index, 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.
The same infrastructure 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. If you do one thing this week, build the register: every policy, its owner, its current version, and its next review date.
Frequently Asked Questions
What are HIPAA policies and procedures?
HIPAA policies and procedures are the written rules a covered entity (a provider, health plan, or clearinghouse) or business associate (a vendor handling patient information for one) puts in place to comply with the Privacy, Security, and Breach Notification Rules. Policies set out what the organization does and why. Procedures assign the work: who acts, what they do, and by when. The Security Rule makes both mandatory, calling for reasonable and appropriate policies kept in writing, which can be electronic, along with a record of any action or assessment the rules say must be documented. The Privacy Rule has a parallel requirement for its own standards.
What is the difference between a HIPAA policy and a procedure?
A policy is a statement of intent, the what and the why. A procedure is the operational detail, the how and the who. A policy might state that workforce access to protected health information is limited to what each role requires. The matching procedure names the person who maintains the role-to-access table, states that permissions are adjusted within one business day of a role change, and says where the record of that change is kept. A useful test: if the text does not name a person, an action, and a timeframe, it is still a policy rather than a procedure.
How many HIPAA policies and procedures are required?
There is no fixed number in the regulation. Commercial template suites run to several dozen documents, but the size of a suite reflects how finely the same substance is sliced rather than a difference in obligation. The rules do not prescribe titles or a format either: the Security Rule asks for reasonable and appropriate policies, kept in written form, which may be electronic. What matters is coverage: every standard and implementation specification that applies to your organization has to be addressed somewhere in writing, and you have to be able to find it. A practice that consolidates related topics into 20 well-organized policies is in the same position as one with 60, provided nothing is missing.
Do small practices need the same HIPAA policies as large organizations?
Yes. The requirements do not scale down with headcount. A solo practitioner and a hospital system are subject to the same standards, and both must have written policies and procedures addressing them. What the Security Rule does allow is flexibility in how you meet those standards, taking into account your size, complexity, technical infrastructure, and the cost of the measures. That flexibility changes the depth and cost of your controls. It does not remove any topic from the list or excuse the absence of a written policy.
How long must HIPAA policies and procedures be retained?
Keep each document for six years, counted from whichever is later: the day it was created or the last day it was in effect. Most people overlook the second option. A policy you retire is not free to discard, because its six years begin on the date it was replaced. That is how an old version can still be sitting in your files after the document that replaced it has itself been replaced. In practice, a policy file should never be edited in place. Issue a numbered new version, archive the old one, and record the dates each version governed.
Can I use a HIPAA policy template?
Yes, and templates are a sensible starting point, but only if you tailor them to what your organization actually does and then operate them. A template that describes procedures you do not follow is worse than no template at all, because it establishes that you knew the requirement and documents a gap between your stated process and your real one. Investigators read policies against evidence of what happened. Take a template, delete what does not apply, rewrite the procedures to name your real people and systems, and keep records showing the procedures ran.
Who is responsible for HIPAA policies and procedures?
The organization must designate a privacy official responsible for developing and implementing its privacy policies and procedures, and must identify a security official responsible for the Security Rule policies and procedures. In a small practice this is very often the same person, typically the practice manager or the owner, and that is permitted. What is not permitted is leaving the role unassigned or implied. The designation should be written down with a name and a date, because it is one of the first things an investigation asks for.
What does addressable mean in the HIPAA Security Rule?
Addressable is not a synonym for optional. For each addressable specification you first judge whether it is reasonable and appropriate for your practice as written, weighing your size, complexity, and resources. If it is, you put it in place. If it is not, you document why and adopt an alternative that reaches the same goal. If neither the specification nor an alternative fits, and the standard can still be met, you may do neither, but you must write down that analysis. Every route ends with a written record, so silently skipping an addressable item is a mistake that tends to be expensive.
Are the new HIPAA Security Rule requirements in effect?
No. The proposal is still only that, a proposal. The Office for Civil Rights put a Notice of Proposed Rulemaking in the Federal Register on January 6, 2025. If adopted, it would turn nearly every implementation specification into a requirement, require every policy, procedure, plan, and analysis under the Security Rule to be written down, and add a compliance audit at least once every 12 months. Public comment ended in March 2025 with more than 4,600 comments posted to the docket, and in December 2025 over 100 health care organizations, including hospital systems and medical societies, sent HHS a joint letter urging it to withdraw the proposal. No final rule has been published. The most recent federal regulatory agenda files it under long-term actions and projects final action for July 2027, though agenda dates are not binding. Until something changes, the existing Security Rule is what applies.
Make HR the easy part of running your business
Onboarding, e-signatures, training and core HR in one place. Up and running in 5 minutes.
- 7-day free trial
- No credit card required
- Cancel anytime