HIPAA Security Rule checklist
A HIPAA Security Rule compliance checklist that follows the rule's own order: administrative, physical and technical safeguards, organizational requirements, and policies and documentation. Each standard is written as an engineering or operations task, with required and addressable items marked.
For founders, CTOs, CIOs and security officials at covered entities and business associates that create, receive, maintain or transmit electronic protected health information (ePHI).
What is a HIPAA Security Rule checklist?
A HIPAA Security Rule checklist lists every standard and implementation specification in 45 CFR 164.308 to 164.316 as a task you can assign and evidence. This free checklist from Agnotic Technologies follows the rule's own structure, marks each item required or addressable, and shows which safeguards are in place and which still need a documented decision.
Last reviewed by the Agnotic Technologies engineering team
What do required and addressable mean?
The Security Rule uses two kinds of implementation specification. The distinction decides what a tick on this checklist has to prove.
Implement it
A required specification must be implemented as written. Risk analysis, unique user identification and the data backup plan are examples. There is no documented alternative.
45 CFR 164.306(d)(2)
Implement it, or decide and document
An addressable specification is still mandatory to assess. You implement it if it is reasonable and appropriate, or you document why it is not and implement an equivalent alternative measure where one is reasonable and appropriate.
45 CFR 164.306(d)(3)
Meet the standard itself
Some standards, such as audit controls and workstation use, have no separate implementation specification. You must meet the standard; how you do it is yours to decide and document.
45 CFR 164.306(c)
How to decide an addressable item
Ask whether the specification is a reasonable and appropriate safeguard in your environment, judged by how much it would protect ePHI.
If it is, implement it and record the evidence.
If it is not, write down why, then implement an equivalent alternative measure if one is reasonable and appropriate, and record that too.
Keep the written decision with your other Security Rule documentation for six years.
Which Security Rule standards does your organization meet?
Work through the five parts in order. Tick an item only when you can point to evidence: a document, a configuration, a log sample, a test result or a signed agreement. Your ticks stay in this browser tab and are not sent to Agnotic.
0 of 42 standards evidenced · 20 required still open
Administrative safeguards (45 CFR 164.308)
0/17Who decides, who is trained, how risk is managed and how incidents and outages are handled.
Physical safeguards (45 CFR 164.310)
0/8Buildings, rooms, workstations, devices and media. Cloud hosting shifts some of these to your provider, which is why the BAA and its evidence matter.
Technical safeguards (45 CFR 164.312)
0/9The controls built into the software and infrastructure that hold ePHI.
Organizational requirements (45 CFR 164.314)
0/3What your business associate agreements and plan documents must say.
Policies, procedures and documentation (45 CFR 164.316)
0/5The paper trail an auditor, a customer's security review or your own successor will ask for.
How is this different from the HIPAA app engineering checklist?
Agnotic publishes two HIPAA checklists. They cover the same rule from two directions.
HIPAA Security Rule checklist (this page)
Organised by the rule: 164.308 to 164.316 in order, every standard and implementation specification included, written for the organization as a whole. Use it to check coverage of the whole rule, prepare for a security review or brief a security official.
HIPAA app engineering checklist
Organised by app build task: access, audit logging, encryption, vendors and recovery. It picks the controls an engineering team builds into one product and maps each back to the rule. Use it when you are shipping an app that handles ePHI.
Open the HIPAA app engineering checklistA product team usually needs both: this page for the organization's obligations, the engineering checklist for the build.
How do you work through the checklist?
Gather the owners
The security official, the engineering lead, whoever runs IT or cloud, and the person who signs vendor contracts.
Start with 164.308
The risk analysis comes first because every later decision, especially on addressable items, refers back to it.
Tick only with evidence
A policy document, a screenshot of a configuration, a log sample, a restore test or a signed agreement. If you cannot show it, leave it open.
Decide the addressable items
For each one you do not implement, write why and what you do instead, using the steps above.
Record gaps and owners
Put open items in your risk management list with a named owner, then run the checklist again after the next change.
What should you do with the gaps?
Not every open item has the same weight. This table sorts open items by what the rule says about them.
| Open item | What the rule says | What to do next |
|---|---|---|
| Required item open | Must be implemented; no alternative is allowed (164.306(d)(2)). | Treat it as a blocker. Give it an owner and a date before ePHI goes into, or stays in, the system. |
| Addressable item open, no decision | Must be assessed and either implemented or documented with an alternative (164.306(d)(3)). | Make the decision now. An undocumented addressable item is a gap even when the control exists. |
| Addressable item with a documented alternative | Acceptable when the reasoning and the alternative are recorded. | Keep the record with your documentation and review it at the next evaluation. |
| Standard with no evidence | The standard must be met; the method is yours (164.306(c)). | Write down how you meet it and collect evidence for the next review. |
| Vendor with ePHI and no agreement | A written contract is required before PHI is shared (164.308(b), 164.314(a)). | Sign the business associate agreement or stop the data flow. |
| Documentation older than the last change | Documentation must be reviewed and updated for changes (164.316(b)(2)(iii)). | Update the policy or risk analysis and date the revision. |
Which rule sections back this checklist?
Each fact is quoted from, or summarised from, the regulation text on eCFR.
The HIPAA Security Rule lets a covered entity or business associate meet an addressable implementation specification either by implementing it, or by documenting why it is not reasonable and appropriate and implementing an equivalent alternative measure where that is reasonable and appropriate.
Source: 45 CFR 164.306(d)(3) (eCFR)The HIPAA Security Rule requires an accurate and thorough risk analysis of the potential risks and vulnerabilities to the confidentiality, integrity and availability of ePHI.
Source: 45 CFR 164.308(a)(1)(ii)(A) (eCFR)The Security Rule requires covered entities and business associates to retain their policies, procedures and other required documentation for six years from the date of creation or the date it was last in effect, whichever is later.
Source: 45 CFR 164.316(b)(2)(i) (eCFR)A HIPAA covered entity may share protected health information with a business associate, such as a software vendor, only under a business associate agreement that commits the vendor to safeguard it.
Source: 45 CFR 164.502(e) and 164.504(e) (eCFR)The HIPAA Breach Notification Rule requires covered entities to notify affected individuals of breaches of unsecured protected health information, and business associates to notify the covered entity.
Source: 45 CFR Part 164 Subpart D (eCFR)
What can this checklist not tell you?
- Whether you are compliant
- Compliance rests on your risk analysis, your documented decisions and your evidence, judged against your environment. A ticked list is the start of that record, not the record itself.
- That you are HIPAA certified
- There is no HIPAA certification. The Security Rule (45 CFR Part 164 Subpart C) sets standards and implementation specifications and does not create any certification for products or companies. Agnotic describes its work as HIPAA-ready engineering for that reason.45 CFR Part 164 Subpart C on eCFR
- Whether HIPAA applies to you
- That depends on whether you are a covered entity or a business associate under 45 CFR 160.103. Consumer health apps outside HIPAA may fall under other rules instead.
- Your Privacy Rule and Breach Notification Rule duties
- This checklist covers the Security Rule (Subpart C) only. The Privacy Rule (Subpart E) and the Breach Notification Rule (Subpart D) add their own requirements.
- Legal advice
- This page is engineering and operations guidance from a software development services company, not legal advice. Have privacy or legal counsel confirm what applies to your organization.
Which Agnotic services pick up from the gaps?
When the open items are engineering work, this is what Agnotic Technologies builds for clients.
- HIPAA app engineering checklistThe same rule organised by app build task: access, audit logs, encryption, vendors and recovery.
- HIPAA compliant software developmentApps and platforms built with the Security Rule safeguards designed in from the first sprint.
- HIPAA requirements for software teamsHow the Security Rule turns into architecture and infrastructure decisions.
- Business associate agreement (BAA)What a BAA is and when a vendor needs one.
- Epic integration planning checklistPlan an Epic integration before you write code, including the security review it will meet.
- Healthcare software scope builderPut the open items into a full product scope before a scoping call.