HIPAA Compliance Checklist: The IT Compliance Checklist for 2026

The HIPAA compliance checklist, condensed

HIPAA compliance comes down to nine pieces of work: confirm you are covered by the law, run a documented risk analysis, implement the administrative, physical and technical safeguards of the Security Rule, sign business associate agreements with every vendor that touches protected health information, train your workforce, prepare for breach notification, and keep documentation for six years. This checklist walks through each item in the order an OCR investigator or auditor would ask about them.

1. Confirm HIPAA applies to you (it probably does)

HIPAA covers two groups. Covered entities are health plans, healthcare clearinghouses and providers who transmit health information electronically. Business associates are any organization that creates, receives, maintains or transmits protected health information (PHI) on a covered entity's behalf: billing companies, cloud hosts, analytics vendors, transcription services, IT providers.

The second category is where software companies get caught out. If your SaaS product stores or processes PHI for a hospital, clinic or health plan customer, you are a business associate and directly liable under the Security Rule, whether or not you think of yourself as a healthcare company. Subcontractors of business associates are pulled in too.

2. Run the risk analysis first, not last

The security risk analysis (45 CFR 164.308(a)(1)) is the foundation the rest of the Security Rule stands on, and a missing or stale one is among the most commonly cited failures in OCR enforcement actions. It has to identify where PHI lives across your systems, the threats and vulnerabilities to it, the likelihood and impact of each, and the controls you have in place.

Two practical points. First, it must be documented; an analysis that lives in someone's head does not exist as far as an investigator is concerned. Second, it must be kept current: rerun it when you add systems, vendors or products that touch PHI, not just once at go-live.

3. Administrative safeguards

• Name a security officer. One identified person responsible for the security program. Small organizations can combine this with the privacy officer role.
• Manage workforce access. Procedures for authorizing, reviewing and terminating access to PHI. Offboarding matters as much as onboarding; a departed employee with live credentials is a reportable incident waiting to happen.
• Train the workforce. Security awareness training for everyone who touches PHI, at hire and periodically after, with completion records you can produce. Most teams run this through a corporate training platform so completions are tracked automatically instead of chased by email.
• Plan for incidents and contingencies. A security incident procedure, a data backup plan, a disaster recovery plan and an emergency mode operation plan.
• Evaluate periodically. HIPAA requires you to assess how well your safeguards are working whenever your environment changes materially.

4. Physical safeguards

• Facility access controls. Limit physical access to systems holding PHI: locked server rooms, badge access, visitor logs. For cloud-hosted teams, this largely means inheriting your provider's controls and covering them in the BAA.
• Workstation and device policies. Rules for where and how workstations access PHI, screen locking, and physical positioning in shared spaces.
• Device and media controls. Procedures for disposal, reuse and movement of hardware and media containing PHI, including sanitization before disposal.

5. Technical safeguards: the HIPAA IT compliance checklist

The technical safeguards are where IT and security teams live, and where most audit questions land. This table is the short version to run against every system that stores or transmits PHI:

Encryption at rest and in transit is formally an "addressable" specification rather than a required one, but treat that word carefully: addressable means you must implement it or document a reasonable, equivalent alternative. In an investigation, unencrypted PHI on a lost laptop is close to indefensible, and encrypted data that is breached generally qualifies for the breach notification safe harbor. Encrypt everything and the question disappears.

6. Sign BAAs with every vendor that touches PHI

Every vendor that creates, receives, maintains or transmits PHI for you needs a signed business associate agreement before PHI flows: cloud providers, email platforms, analytics tools, support desks, subprocessors. An inventory of which vendors touch PHI, with the BAA status and renewal date of each, is one of the first documents to have ready. This is also where HIPAA compliance meets vendor risk management: a BAA makes a vendor accountable on paper, but assessing and monitoring their actual security posture is what keeps their breach from becoming yours.

7. Prepare breach notification before you need it

The Breach Notification Rule sets deadlines that are unforgiving if you start planning after discovery. Affected individuals must be notified without unreasonable delay and no later than 60 days after discovery. Breaches affecting 500 or more people must be reported to HHS within that same 60 days (and draw media notification duties); smaller breaches are logged and reported to HHS annually. Business associates must notify the covered entity, on the timeline the BAA specifies. Write the playbook now: who assesses, who drafts notices, who files with HHS.

8. Document everything, keep it six years

HIPAA requires policies, procedures, risk analyses, training records and incident documentation to be retained for six years from creation or last effective date. When OCR investigates, the difference between a defensible program and a penalty often comes down to what you can produce in writing, dated, with evidence it actually operated.

9. Make the checklist continuous, not annual

Every item above decays. Access gets over-provisioned, a new vendor slips in without a BAA, training lapses for new hires, the risk analysis ages past the last product launch. Running the checklist once a year means living with months of silent drift in between. This is the job HIPAA compliance software exists to do: map your controls to the Security Rule safeguards, collect the evidence continuously, track BAAs and their renewals, and flag the gap the day it opens instead of the week before an audit. Scrutineer does exactly that, alongside the same evidence base it uses for SOC 2 and ISO 27001, and keeps you audit-ready year-round. Worth stating plainly: there is no official HIPAA certification, and no software makes you compliant by itself. What you can have is a documented, evidenced, continuously monitored program, which is what regulators actually look for.

Frequently asked questions

What are the three main rules of HIPAA?

The Privacy Rule, which governs how PHI may be used and disclosed; the Security Rule, which sets the administrative, physical and technical safeguards for electronic PHI; and the Breach Notification Rule, which dictates who must be told what, and how fast, when PHI is compromised. The HITECH Act extended enforcement and made business associates directly liable.

Is there an official HIPAA certification?

No. HHS does not recognize any HIPAA certification, and no certificate makes you compliant or shields you from enforcement. Vendors selling "HIPAA certification" are selling training or assessment services, which can be useful, but compliance is demonstrated through your documented risk analysis, safeguards, BAAs and evidence that they operate.

How often should we run a HIPAA risk assessment?

The rule requires it to be accurate and current rather than naming a frequency. In practice: rerun it at least annually, and additionally whenever you add systems, products or vendors that touch PHI, migrate infrastructure, or experience a security incident. A risk analysis dated three product launches ago will not hold up in an investigation.