Most HIPAA checklists online cover the Security Rule and stop. The Security Rule is roughly a third of your obligation. This one covers all four rules that make up the HIPAA Administrative Simplification requirements, cites the regulation for every item, and marks each implementation specification exactly as the text does: required or addressable.
It is a working checklist. Tick items as you go and copy what is left. There is almost no Evidr in it, because the regulation does not care what software you use.
First: are you a covered entity or a business associate?
Nothing below is scoped correctly until you answer this. The categories come from 45 CFR 160.103.
- CECovered entityA health plan, a healthcare clearinghouse, or a healthcare provider who transmits health information electronically in connection with a covered transaction. All four rules apply in full.
- BABusiness associateA person or entity that creates, receives, maintains or transmits PHI on behalf of a covered entity. Most software companies in health tech are here. Directly liable for the Security Rule and the Breach Notification Rule since the 2013 Omnibus Rule, and for parts of the Privacy Rule.
- SubSubcontractorA business associate of a business associate. Same direct liability. If you hand PHI to a vendor, they are your subcontractor and you need a BAA with them.
- NeitherOut of scopeYou never touch PHI. Be careful here: support tickets, logs, screenshots and error payloads can all carry PHI without anybody deciding they should.
Required versus addressable
The Security Rule marks every implementation specification as one or the other, and this is where most programmes go wrong.
Addressable does not mean optional. Under 45 CFR 164.306(d)(3) you must assess whether the specification is a reasonable and appropriate safeguard in your environment, and then do one of three things: implement it, implement an equivalent alternative measure, or document why it is not reasonable and appropriate. Skipping it silently is not on the list. An OCR investigator will ask for that written assessment, and its absence is itself the finding.
The checklist
Grouped by rule and by CFR section. Tags mark what the regulation says, not what we recommend.
Administrative safeguards, 45 CFR 164.308
0/23The largest group and the one most often under-evidenced, because it is paperwork rather than configuration.
Physical safeguards, 45 CFR 164.310
0/10Still applies if you are entirely cloud-native. The data centre obligation passes to your provider under their BAA; your offices, laptops and disposal processes remain yours.
Technical safeguards, 45 CFR 164.312
0/9The part engineers assume is the whole of HIPAA. It is the shortest section.
Organisational, policies and documentation, 45 CFR 164.314 and 164.316
0/7Quietly mandatory and frequently missed entirely.
Privacy Rule, 45 CFR Part 164 Subpart E
0/10Applies in full to covered entities and in part to business associates. Routinely skipped by engineering teams who only read the Security Rule.
Breach Notification Rule, 45 CFR Part 164 Subpart D
0/7The clock starts at discovery, not at resolution or at root cause. Know these before you need them.
The encryption safe harbour
Encryption is addressable, not required, and this surprises people every time. The reason to encrypt anyway is not the Security Rule, it is the Breach Notification Rule.
Under the HHS guidance specified in 45 CFR 164.402, PHI that has been encrypted to the standard in that guidance is rendered unusable, unreadable or indecipherable to unauthorised persons, and its loss is therefore not a breach. No notification. No portal entry. No media call. Lose an unencrypted laptop and you are notifying; lose an encrypted one and you are filing a note.
Common questions that change the scope
No. HHS does not certify anyone, does not endorse any certifying body, and there is no official HIPAA certificate. Third-party attestations such as HITRUST CSF are widely accepted by customers as evidence of a mature programme, and a SOC 2 report can be scoped to include HIPAA criteria, but neither is a HIPAA certification. Any vendor selling you one is selling you something else.
Yes, if PHI touches them. All three offer a BAA, usually as a click-through in the console or through your account team, and it must be executed before PHI is stored. Each also publishes a list of which of their services are in scope under that BAA. Using an out-of-scope service for PHI is a gap even with the BAA signed.
The rule says periodically and does not name an interval. The working norm, and what OCR expects in practice, is annually plus after any material change to systems, operations or the threat environment. A risk analysis from three years ago against an architecture you have since replaced is treated as no risk analysis at all.
No. Properly de-identified data under 164.514 is not PHI. But the bar is specific: either Expert Determination by a qualified statistician, or Safe Harbor removal of all eighteen identifiers including dates more precise than year, all geographic subdivisions smaller than a state except the first three ZIP digits under certain conditions, and any other unique identifying number or code.
If they contain PHI, they are in scope, and the platform carrying them is a business associate needing a BAA. This is the most common accidental scope expansion we see: PHI arrives in a support ticket, a screenshot, an error payload or a log line, and nobody decided it should.
Often, yes. HIPAA sets a floor, not a ceiling, and does not pre-empt state laws that are more stringent. California, Texas and New York in particular impose additional requirements, and several states have shorter breach notification windows than the federal sixty days.
Where most programmes actually fail
Not in the technical safeguards. Ranked by how often they turn up as the gap:
- No current risk analysis, or one that was never written down. It is the most cited failure in OCR enforcement and it is the cheapest item on this list to fix.
- Addressable specifications neither implemented nor documented. Silence reads as negligence, not as a considered decision.
- Termination procedures that miss a system. Usually not production, usually a monitoring tool or a shared vault nobody inventoried.
- BAAs that exist but are untracked. You cannot say which of your forty vendors have one, which touch PHI, and which renewed with different terms.
- Right of access requests handled ad hoc. This is the most enforced Privacy Rule provision and the penalties are routine rather than exotic.
- Contingency plans written and never tested. The testing specification is addressable; the backup and disaster recovery plans themselves are required.
- Six-year retention not actually implemented, so the documentation proving a control operated in year one is gone by the time anyone asks.
A note on tooling
None of the above requires software. Small teams complete HIPAA programmes with documents and discipline, and a platform will not save a programme without an owner.
What tooling does change is the evidence burden over time. The retention requirement is six years, the evaluation is annual, training and access reviews recur, and every one of those has to be provable years after the fact. That is the part that decays in a shared drive. Evidr tracks it across HIPAA and any other framework you run, which matters mainly if you are also being asked for SOC 2 or ISO 27001 and do not want to collect the same evidence three times.