HIPAA gap analysis: a Security Rule checklist

Somewhere between 2003 and now, the industry decided a HIPAA gap analysis is an annual exercise. A spreadsheet in Q1, a remediation plan by Q2, a folder nobody opens until next year.

Read the Security Rule and you will not find that anywhere.

What 45 CFR 164.308(a)(8) actually requires is a periodic evaluation, “based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information.” There is no interval in that sentence. There is a trigger.

That distinction is the whole subject of this blog. Below is a complete Security Rule checklist you can work through, standard by standard, with every provision cited. It will tell you where you stand today. What it cannot do is stay true, because the environment it measured keeps moving after you close the file.

This guide focuses on the Security Rule (45 CFR Part 164, Subpart C): the controls protecting electronic protected health information, or ePHI. It is written for business associates managing health information on a customer’s behalf, as well as covered entities. The checklist covers Security Rule safeguards and documentation; it is not a complete Privacy Rule assessment. You may also see this exercise called a HIPAA gap assessment.

What a HIPAA gap analysis is, and how it differs from a risk analysis

A HIPAA gap analysis compares your current safeguards with the HIPAA requirements that apply to your organization, then turns missing or incomplete safeguards into a remediation plan.

A gap analysis is not a HIPAA risk analysis. It asks which required controls are in place, measured against the regulation. A risk analysis, required in its own right under 45 CFR 164.308(a)(1)(ii)(A), asks a different question: it weighs how likely a threat to ePHI is and how much harm it would do.

The two exercises inform each other. A gap review can identify missing safeguards, while the required risk analysis evaluates threats and vulnerabilities across the ePHI you create, receive, maintain, or transmit. Its findings also inform which safeguards are reasonable and appropriate. A control checklist cannot replace that analysis, and HIPAA does not prescribe a separate gap-analysis exercise at all. HHS explains the distinction in its guidance on gap analysis and risk analysis; its risk-analysis guidance sets out the broader assessment.

That last point is worth sitting with. The gap analysis is not a HIPAA requirement. It is a tool the industry built to make an open-ended obligation tractable. Useful, widely used, and entirely our invention, which also means the shape of it is ours to change.

‍

{{ banner-image }}

The three HIPAA Security Rule safeguard categories

The Security Rule sorts its requirements into three categories of safeguards, and mapping your controls against them is the core of a HIPAA Security Rule gap analysis. Together the three categories hold 18 standards and 36 implementation specifications, at 45 CFR 164.308, 164.310, and 164.312. Every standard is mandatory. Every implementation specification carries a label: Required or Addressable.

Addressable does not mean optional. It means you assess whether the specification is a reasonable and appropriate safeguard in your environment, and then either implement it, or document why it is not and put an equivalent measure in its place where one is reasonable and appropriate (45 CFR 164.306(d)). The label sits on the specification, not on the standard above it, and 22 of the 36 specifications are Addressable, which is where most teams misread the rule.

So a finding is not only a control you skipped. It is also an Addressable specification you never assessed, or assessed and never wrote down. That second kind is the one that surprises people, because the safeguard can be entirely adequate and the record still fails: 164.306(d) asks for the assessment and the decision, not just the outcome. Under HIPAA, the reasoning is the evidence. A control with no documented rationale behind it is a control you cannot defend.

Administrative safeguards

Administrative safeguards are the policies and the people that run your security program: the security management process, the required risk analysis and risk management, workforce clearance and termination, training, incident response, and contingency planning (45 CFR 164.308). This is the largest group, at 9 standards and 21 implementation specifications. A finding here often looks organizational rather than technical. A departed employee whose access to ePHI was never revoked defeats the termination-procedures specification at 164.308(a)(3)(ii)(C), and an incident procedure with no evidence of identifying, responding to, and documenting incidents needs closer review against 164.308(a)(6)(ii).

Physical safeguards

Physical safeguards govern the buildings, workstations, and devices that touch ePHI: facility access controls, workstation use and security, and the receipt, movement, disposal, and re-use of hardware and media (45 CFR 164.310), across 4 standards and 8 implementation specifications. A finding here is the kind an auditor can photograph. A drive made available for re-use without removing ePHI fails the media re-use specification at 164.310(d)(2)(ii), and a workstation left in an open area with a standing session into a records system defeats the workstation-security standard at 164.310(c).

Technical safeguards

Technical safeguards are the controls inside your systems: access control, audit controls, integrity, authentication, and transmission security (45 CFR 164.312), across 5 standards and 7 implementation specifications. A finding here hides in configuration. A shared login used by several administrators defeats the unique-user-identification specification at 164.312(a)(2)(i), because no record can then show which person opened a patient file, and ePHI sent across a network with no safeguard against interception leaves the transmission-security standard unmet at 164.312(e).

Configuration is also where the calendar problem bites hardest. An administrative finding tends to sit still — a policy that was wrong in March is usually still wrong in November. A technical one does not. The shared login gets created in week three of an incident and never cleaned up. The storage bucket policy changes during a migration. These are the findings an annual review is least equipped to catch, and the ones most likely to matter.

The Security Rule protects electronic PHI. The Privacy Rule reaches PHI in any form and governs its use and disclosure. A complete HIPAA review therefore needs separate Privacy Rule and Breach Notification work alongside the security checklist. For business associates, that includes applicable duties imposed directly by the Rules as well as duties in their business associate agreements. HHS’s business-associate guidance explains that relationship.

A 4-step HIPAA gap-analysis process

Running a HIPAA compliance gap analysis is the same discipline as any compliance gap analysis, aimed at one regulation. Four steps carry it from scope to a plan you can act on.

1. Scope the ePHI and the systems and vendors that touch it. Start from all the ePHI you create, receive, maintain, or transmit (45 CFR 164.306(a)(1)), then map the systems that hold it and the vendors that handle it on your behalf. Determine which vendors and subcontractors meet the business-associate definition from their functions and data flows. A business associate agreement records responsibilities; outsourcing does not make that ePHI disappear from the assessment.

2. Assess current safeguards against each requirement. Go standard by standard through 164.308, 164.310, and 164.312, then check the applicable organizational and documentation requirements in 164.314 and 164.316. For each Required specification, check implementation and evidence. For each Addressable one, assess whether it is reasonable and appropriate. Implement it when it is; otherwise document why, and implement an equivalent alternative when that is reasonable and appropriate. Keep the assessment and decision with the control record (45 CFR 164.306(d) and 164.316(b)(1)). Track Privacy Rule findings separately so a completed security checklist cannot be mistaken for full HIPAA coverage.

3. Document and prioritize the gaps by risk. Record every gap in writing, and rank remediation using the potential harm to ePHI and the findings of your risk analysis. The regulation does not prescribe a scoring scale, so use a consistent method and explain the priority. Keep the required Security Rule documentation for six years from creation or its last effective date, whichever is later (45 CFR 164.316(b)(2)(i)); this is a documentation-retention rule, not a universal retention period for every patient record.

4. Build a remediation plan, then re-test. Give each gap an owner and a date, close it, and verify the fix. Then keep going — and this is the step where the regulation is more demanding than the convention. 164.308(a)(8) calls for a periodic evaluation without ever naming a period, and ties subsequent evaluation to environmental or operational changes affecting the security of ePHI. 164.306(e) adds a standing duty to review and modify security measures “as needed.” Neither sentence contains a number.

Keep the record specific enough for someone else to verify the fix. For an account that should have been removed, record the affected system, termination date, system owner, removal evidence, and the follow-up check. For an untested recovery plan, record the system, test owner, test date, result, and outstanding actions. These are examples of remediation records, not extra HIPAA requirements. User access review software supports the first workflow, while findings management keeps owners and follow-up work visible across the program.

HIPAA never told you to do this annually

The Security Rule uses the word periodic. It never says how often.

Here is 164.308(a)(8), the Evaluation standard, in full:

“Perform a periodic technical and nontechnical evaluation, based initially upon the standards implemented under this rule and, subsequently, in response to environmental or operational changes affecting the security of electronic protected health information, that establishes the extent to which a covered entity’s or business associate’s security policies and procedures meet the requirements of this subpart.”

Read it again. There is no interval. There is a starting point and then a trigger, and the trigger is change.

It is not the only provision that works this way. 164.306(e) creates a standing duty: review and modify your security measures “as needed to continue provision of reasonable and appropriate protection” of ePHI. And 164.316(b)(2)(iii) — a Required implementation specification, not an Addressable one — says to “review documentation periodically, and update as needed, in response to environmental or operational changes affecting the security of the electronic protected health information.”

Three provisions. Not one of them contains a number. Two of them name change explicitly as the thing that sets the clock.

So where did annual come from? It came from the cost of the method. When the assessment is people interviewing other people and collecting screenshots into a spreadsheet, it takes weeks of senior time, and an exercise that expensive happens once a year. The calendar was never an interpretation of the rule. It was a concession to what the work costs, and it hardened into something that feels like a requirement because everyone did it.

That is a reasonable adaptation to a real constraint. It is also the thing worth revisiting, because the constraint is the part that changed.

The honest counterpoint. HHS’s proposed Security Rule update cuts partly against this argument, and it is better to say so than to let a reader find it. Among other things, the proposal would have regulated entities review and test the effectiveness of certain security measures at least once every 12 months, in place of the current general maintenance requirement. If that lands, a calendar gets written into the Security Rule for the first time.

Read it for what it is: a floor being set because an open-ended obligation proved hard to enforce. A floor tells you the minimum. It does not tell you whether your safeguards held last Tuesday, when someone widened a storage policy during a migration. And notice that even the proposal keeps the trigger — its asset inventory and network map requirement runs “at least once every 12 months and in response to a change in the regulated entity’s environment or operations.”

Why the interval is not an academic question. HHS’s own Report to Congress records 663 breaches of unsecured PHI affecting 500 or more individuals occurring during 2024, affecting approximately 242.9 million people. IBM’s 2026 Cost of a Data Breach report puts the average healthcare breach at $6.64 million and marks healthcare’s fifteenth consecutive year as the costliest industry. The environment those breaches happened in was not the environment anyone assessed in January.

None of this makes an annual gap analysis wrong. It makes it a snapshot, and the rule is asking a question about a state. The distance between those two things is where the findings live.

HIPAA Security Rule gap analysis checklist

This HIPAA Security Rule gap analysis checklist gives you standard-level readiness questions. A “no” is a finding to investigate; “not sure” means the evidence or assessment needs work. For an Addressable specification, record the reasonableness assessment, the implementation decision, and any appropriate equivalent measure. The questions point you to the relevant provisions; completing them does not substitute for examining every applicable implementation specification.

Administrative safeguards (45 CFR 164.308)

• Do you have a security management process, including a completed risk analysis and a risk-management plan, to prevent, detect, contain, and correct security violations? (164.308(a)(1))
• Is one named security official responsible for your security policies and procedures? (164.308(a)(2))
• Do workforce procedures grant ePHI access to the right people and remove it at clearance and termination? (164.308(a)(3))
• Is access to ePHI authorized in line with the Privacy Rule? (164.308(a)(4))
• Is there a security awareness and training program for the whole workforce, leadership included? (164.308(a)(5))
• Can you identify, respond to, document, and mitigate security incidents? (164.308(a)(6))
• Do you have a data backup plan, a disaster recovery plan, and an emergency-mode operation plan for systems that hold ePHI? (164.308(a)(7))
• Do you run a periodic evaluation, and re-run it when your environment or operations change? (164.308(a)(8))
• Do you hold written business associate agreements with satisfactory assurances from every business associate, and every subcontractor if you are one? (164.308(b))

Physical safeguards (45 CFR 164.310)

• Is physical access to systems and the facilities that house them limited to authorized people? (164.310(a))
• Are the proper functions and physical surroundings of workstations that access ePHI defined? (164.310(b))
• Are there physical safeguards on every workstation that can reach ePHI? (164.310(c))
• Do you govern the receipt, movement, disposal, and re-use of hardware and media that hold ePHI? (164.310(d))

Technical safeguards (45 CFR 164.312)

• Do technical policies limit ePHI access to authorized people and software, each with a unique user ID and an emergency-access procedure? (164.312(a))
• Do audit controls record and examine activity in systems that hold ePHI? (164.312(b))
• Is ePHI protected from improper alteration or destruction? (164.312(c))
• Do you verify that anyone seeking ePHI is who they claim to be? (164.312(d))
• Is ePHI protected from unauthorized access while it travels across a network? (164.312(e))

Documentation (45 CFR 164.316)

• Are your policies, procedures, and required records kept in writing, available to the people who need them, retained for 6 years, and reviewed and updated as your environment changes? (164.316(b))

One more pass, when you have finished. Go back through your answers and mark, next to each one, the date the evidence behind it was produced. Not the date you answered — the date the underlying record was generated. Most teams doing this for the first time find a spread of several months, with the technical answers resting on the oldest evidence, because those were the ones somebody had to go and fetch. That spread is the real output of the exercise. It tells you how much of your HIPAA position is a measurement and how much is a memory.

Covered entities vs business associates

If you create, receive, maintain, or transmit PHI to perform a covered function or service on behalf of a covered entity, you may be a business associate under 45 CFR 160.103. Handling health-related data by itself does not settle that status: the relationship and function matter. A subcontractor that performs such work for a business associate can itself be a business associate. Establish the role before deciding which obligations and contracts the gap review must cover.

A covered entity is a health plan, a health care clearinghouse, or a health care provider that transmits health information electronically in connection with a covered transaction (45 CFR 160.103). The Security Rule’s standards apply to covered entities and business associates alike, so the safeguard categories and the checklist above read the same for both.

The applicable Privacy Rule duties and the chain of contracts differ. Business associates have direct regulatory obligations; their contracts do not replace them. HHS lists the duties for which business associates are directly liable, including Security Rule compliance, impermissible uses and disclosures, and certain reporting and subcontractor obligations. Check both the applicable Rules and the BAA. A breach of unsecured PHI also triggers the business associate’s notice duty to the covered entity without unreasonable delay and no later than 60 calendar days after discovery (45 CFR 164.410); a contract may require faster notice. Your review needs to trace those responsibilities up to customers and down to relevant subcontractors.

For a business associate that already runs other compliance programs, existing access, incident-response, and recovery controls can provide a starting point for HIPAA. Confirm their HIPAA scope and supporting evidence before treating a requirement as covered. That is what supports HIPAA compliance management: retaining the regulatory detail while keeping controls and evidence current.

What the proposed Security Rule update would change

HHS’s Office for Civil Rights published a notice of proposed rulemaking on January 6, 2025 (90 FR 898) — the first substantial reworking of the Security Rule since 2013. The comment period closed March 7, 2025 with 4,747 comments. As of September 2026 there is no final rule, and HHS’s own page is unambiguous: “While the Department is undertaking this rulemaking, the current Security Rule remains in effect.”

Do not plan around an imminent deadline. The rule has slipped twice in the Unified Agenda and now sits under Long-Term Actions with a target of July 2027, having previously carried a May 2026 target. It is not withdrawn, and it is not close.

What it proposes matters anyway, because the direction of travel is legible even from a draft. Among the changes:

• The Required and Addressable distinction goes away. All implementation specifications would become required, with specific, limited exceptions. The proposal also adds an explicit multi-factor authentication requirement; MFA is not an existing Addressable implementation specification being relabeled.
• Encryption of ePHI at rest and in transit, with limited exceptions.
• Multi-factor authentication, with limited exceptions.
• Network segmentation.
• Vulnerability scanning at least every six months, and penetration testing at least every 12 months.
• An asset inventory and network map, refreshed at least every 12 months and in response to a change in the environment or operations.
• A compliance audit at least every 12 months.

The NPRM’s regulatory impact analysis estimates first-year costs across the industry at roughly $9 billion, and about $6 billion annually for the following four years.

Read the list as a group and the pattern is hard to miss. Every one of these is a standing condition rather than a document: an inventory that is current, a network that is segmented, scans that recur, authentication that holds. The direction is away from the periodic attestation and toward the operating state — which is the same direction the existing rule has been pointing since 2003, in language nobody was forced to act on.

If your program can only answer these questions once a year, the proposal is not the problem. The method is.

Frequently asked questions

What is a HIPAA gap analysis?

A HIPAA gap analysis compares current safeguards with applicable HIPAA requirements and records missing or incomplete measures for remediation. This guide supplies a Security Rule checklist for covered entities and business associates. A complete HIPAA assessment also needs the Privacy Rule and Breach Notification requirements applicable to the organization. The gap exercise does not replace the required Security Rule risk analysis.

How often do I need to do a HIPAA gap analysis?

HIPAA does not require a gap analysis at all, so there is no prescribed frequency for one. What it requires is a periodic evaluation under 164.308(a)(8), performed initially against the standards and subsequently in response to environmental or operational changes affecting the security of ePHI, plus an ongoing duty under 164.306(e) to review and modify security measures as needed. No interval appears in either provision. The common annual cadence is industry practice, not a regulatory floor — and if your environment changes materially between reviews, an annual cadence does not satisfy the change trigger on its own.

How is a HIPAA gap analysis different from a HIPAA risk analysis?

A gap analysis asks whether applicable safeguards are implemented and supported by evidence. The required risk analysis under 45 CFR 164.308(a)(1)(ii)(A) evaluates potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. Gap findings can inform risk analysis, and risk-analysis results inform safeguard decisions; neither exercise should be treated as a substitute for the other.

What does a HIPAA gap analysis cover?

The checklist on this page covers administrative, physical, and technical Security Rule safeguards, plus supporting documentation and business-associate responsibilities. It is a starting point for reviewing the cited requirements and their implementation specifications. Privacy Rule use-and-disclosure obligations and breach-notification procedures require their own applicable checks.

Who needs a HIPAA gap analysis, covered entities or business associates?

Covered entities and business associates both have Security Rule obligations, and both can use a gap analysis to find missing safeguards. A separate gap-analysis exercise is not itself a HIPAA requirement. Establish your role and the ePHI in scope, then check the obligations that apply directly and through your contracts.

Is there an official tool for a HIPAA gap analysis?

HHS publishes the Security Risk Assessment (SRA) Tool as a recognized starting point. Its own materials are candid about the limit: “The target audience of this tool is medium and small providers; thus, use of this tool may not be appropriate for larger organizations.” NIST SP 800-66 Revision 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide, published February 2024, is the current official implementation guidance and tabulates every standard and specification.

For a larger, multi-framework program, requirement-level mapping can support evidence reuse across HIPAA, ISO 27001, PCI DSS, and FedRAMP. Scheduled collection and configured analysis can surface exceptions in technical evidence for an owner to review between audits. A mapping records a relationship; it does not declare either requirement satisfied.

Where to go next

Work the checklist. It will tell you where you stand, and that is worth knowing.

Then ask the harder question the Security Rule has been asking since 2003: not whether your safeguards were reasonable and appropriate in January, but whether they are reasonable and appropriate now, and whether you could show it. A program running HIPAA alongside ISO 27001, PCI DSS, and FedRAMP on one set of controls has outgrown the one-time questionnaire long before it has finished filling one in.

Requirement-level control mapping shows where a safeguard and its evidence support more than one framework while preserving each framework’s scope. Scheduled evidence collection refreshes technical records between reviews, so the answer to “are we compliant right now?” has data behind it rather than a date. Policies, contracts, physical safeguards, and reasonable-and-appropriate decisions still need people to review them, and should — the rule asks for human judgment and so do we.

HIPAA compliance management covers how that works in practice.

Compliance is an audit outcome. Confidence is a security outcome. The checklist gets you the first. Knowing what your systems are doing today is how you get the second.

‍