HIPAA Compliance Readiness Checklist

Step 1: Conduct a risk analysis

A HIPAA risk analysis identifies where PHI lives across your systems, what threats and vulnerabilities could compromise it, and the likelihood and impact of each. This isn't a one-time exercise — conduct it at least annually, and whenever a significant change occurs: a new system handling PHI, a new vendor with data access, or after any security incident. Document the analysis itself, not just its conclusions — auditors and regulators expect to see the methodology and evidence behind a risk determination, not just a summary claim that "risk is low."

Map every system, application, and storage location that touches PHI, including ones that might not be obvious — a customer support ticketing system that includes patient messages, a backup system that retains old PHI records, an analytics tool receiving even de-identified data derived from PHI. Missed systems in this mapping are one of the most common gaps found during a formal audit.

Step 2: Implement administrative safeguards

Administrative safeguards are the policies and organizational processes that govern how your organization manages PHI security. This includes designating a Privacy Officer and Security Officer by name (even in a small organization, these roles need a named accountable owner, not a diffuse "the team handles it"), a documented workforce training program covering PHI handling procedures, a sanctions policy for employees who violate PHI handling rules, and a documented process for granting, reviewing, and revoking system access as employees join, change roles, or leave.

Access review deserves particular attention: a former employee retaining system access to PHI after departure is a common, entirely preventable compliance gap. Build access revocation into your standard offboarding process as a required, checked step, not an informal afterthought that depends on someone remembering.

Step 3: Implement physical safeguards

Physical safeguards address the physical security of systems and devices that access PHI — facility access controls limiting who can physically reach servers or workstations with PHI access, workstation security policies (screen locks, positioning that prevents shoulder-surfing in shared spaces), and a documented, secure device disposal process ensuring PHI is unrecoverable from decommissioned hardware. For organizations operating fully in the cloud with no on-premises PHI storage, this category is lighter but not absent — device disposal policy for employee laptops and any physical access controls at your own offices still apply.

Step 4: Implement technical safeguards

Technical safeguards are the system-level controls protecting PHI in your applications and infrastructure: encryption of ePHI both at rest and in transit using modern, strong ciphers with proper key management (encryption alone, without sound key management, provides weaker protection than it appears to); role-based access control ensuring users can only access the minimum PHI necessary for their function; unique user identification for every person and system account, never shared logins; audit controls logging who accessed what PHI and when; and automatic session logoff after a period of inactivity.

For organizations building AI systems that touch PHI — a clinical decision support tool using RAG over patient records, for example — technical safeguards extend to the AI pipeline itself: ensure embeddings generated from PHI stay within your controlled infrastructure boundary, and that the model provider's terms don't permit training on your data. See data residency for the jurisdictional dimension of this requirement.

Step 5: Establish vendor management and Business Associate Agreements

Any vendor with access to PHI on your behalf requires a signed Business Associate Agreement before any data is shared — this is a legal requirement, not optional documentation. But signing a BAA alone doesn't satisfy your compliance obligation; you're also expected to exercise due diligence on the vendor's actual safeguards, not just the contract. Request their SOC 2 report, ask about their specific HIPAA-relevant technical controls, and establish a periodic review cadence rather than treating the BAA as a one-time signing event.

Maintain a current inventory of every vendor with PHI access — this list should be reviewed at the same cadence as your annual risk analysis, and updated immediately whenever a new vendor relationship starts or an existing one changes scope. See vendor due diligence checklist for regulated industries for the complete vendor evaluation framework this step depends on.

Step 6: Build and test breach notification procedures

HIPAA requires notifying affected individuals generally within 60 days of discovering a breach, with additional requirements — including media notification — for breaches affecting 500 or more individuals in a state or jurisdiction. The 60-day clock starts at discovery, not at the actual breach event, which makes fast, reliable breach detection its own compliance requirement, not just notification speed after the fact.

Document the specific process: who is notified internally first, how the scope and severity of a breach gets assessed, who drafts and approves external communications, and how affected individuals are actually contacted. A breach notification process that exists only as an untested document is a real risk — run at least one internal tabletop exercise simulating a breach scenario to surface gaps in the documented process before a real incident forces you to discover them under pressure.

Step 7: Document training and conduct ongoing audits

Workforce training on PHI handling needs to happen at onboarding and periodically thereafter (annually is standard practice), with attendance and content documented — "we trained everyone" without records to demonstrate it doesn't satisfy audit expectations. Beyond training, conduct routine internal audits of your actual practice against your documented policies: are access reviews genuinely happening on schedule, is the risk analysis actually current, are technical safeguards still correctly configured after infrastructure changes. Document these audits and any remediation taken — this audit trail is itself evidence of a functioning, sustained compliance program, which is what regulators and auditors are actually assessing, not just a point-in-time policy document.

Complete readiness checklist

How HIPAA penalties are actually structured

HHS's Office for Civil Rights (OCR) enforces HIPAA civil penalties using a four-tier structure based on the organization's degree of culpability, not a flat fine regardless of circumstance. The lowest tier applies when the organization didn't know, and reasonably couldn't have known, about the violation. The next tier applies when the violation occurred due to reasonable cause but not willful neglect. The two highest tiers apply to willful neglect — the difference between them is whether the violation was corrected within 30 days of discovery. Penalty amounts scale up meaningfully at each tier, and OCR adjusts the specific dollar ranges periodically for inflation, so check the current HHS-published figures directly for precise amounts rather than relying on a fixed number that may be outdated by the time you read it.

The practical implication of this tiered structure: a documented, executed risk analysis and readiness program is itself part of your defense if an incident occurs, since it demonstrates the organization exercised reasonable diligence rather than willful neglect — the same documentation this checklist calls for repeatedly is what separates a lower-tier penalty from a higher-tier one when OCR investigates an incident.

What an OCR audit or investigation actually looks like

OCR investigations are typically triggered by a filed complaint, a reported breach, or — less commonly — a randomly selected compliance audit. In an investigation, OCR requests documentation demonstrating your compliance program: the risk analysis, policies and procedures, training records, BAAs with relevant vendors, and evidence of how a specific incident (if one occurred) was handled. Organizations that can produce this documentation promptly and completely fare meaningfully better than organizations that have to reconstruct it under investigation pressure — which is the practical argument for maintaining this documentation continuously as a standing practice, not compiling it retroactively when a complaint or breach forces the issue.

A useful readiness test: if OCR requested your complete compliance documentation tomorrow, could you produce it within a few business days, complete and current? If the honest answer involves significant reconstruction work, that gap itself is the highest-priority item to close before anything else on this checklist.

Self-assessment: how to score your own readiness

Score each of the seven steps above 0-2: 0 if the requirement isn't addressed at all, 1 if it's partially addressed or exists but isn't current/tested, 2 if it's fully implemented, documented, and current. A total score of 12-14 suggests genuine readiness. A score of 7-11 indicates real gaps worth addressing before any formal audit exposure, even if nothing is critically broken. A score below 7 warrants treating HIPAA readiness as an urgent priority, not a background task — at that level, the organization likely has genuine, material compliance exposure.

Weight the vendor management and technical safeguards categories most heavily when interpreting your score — gaps in access control or vendor BAAs tend to represent higher actual risk exposure than a training-documentation gap, even though both count equally in a simple point total. Use this scoring as a prioritization tool for where to focus remediation effort first, not as a precise compliance certification — a genuine compliance determination requires a qualified auditor's formal assessment, not a self-scored checklist.

Common gaps found in HIPAA readiness reviews

Risk analysis that's stale or was never actually updated. A risk analysis document from two years ago, with no evidence it's been revisited despite system changes since, doesn't satisfy the "at least annually, and after significant changes" requirement — even if the original document was thorough at the time it was written.

Incomplete vendor inventory. Organizations frequently underestimate how many vendors actually touch PHI — analytics tools, customer support platforms, and backup services are commonly missed because they're not the "obvious" PHI-handling systems like the EHR itself.

Untested breach response. A written breach notification policy that has never been exercised, even informally, tends to reveal significant gaps the first time it's actually needed — unclear ownership, missing contact information, or an approval chain that doesn't function under real time pressure.

Scaling readiness expectations by organization size

HIPAA's requirements apply regardless of organization size — a small healthcare startup and a large hospital system face the same underlying obligations — but the practical implementation reasonably scales. A small organization may combine the Privacy Officer and Security Officer roles in one person, use off-the-shelf tools with built-in HIPAA-eligible configurations rather than building custom infrastructure, and run leaner but still-documented training and audit processes. What doesn't scale down is the documentation itself — even a small organization needs a real, current risk analysis and real, signed BAAs; "we're too small for this to matter" is not a recognized exception under the regulation and won't hold up under an OCR investigation regardless of organization size.

Larger organizations face a different scaling challenge: more systems, more vendors, and more employees make comprehensive coverage harder to maintain consistently, which is why larger organizations typically need dedicated compliance staff and more formal, recurring audit cadences rather than relying on the same informal diligence that might suffice for a five-person team.

What Code Ninety does

Code Ninety builds HIPAA safeguards into system architecture from the first sprint of any healthcare engagement, conducts risk analysis as a standard discovery-phase deliverable rather than an afterthought, and signs Business Associate Agreements before any PHI is shared with client systems. Code Ninety delivers healthcare interoperability solutions for hospital and payer systems.

Frequently asked questions

Related reading

• → Is SOC 2 Type II enough for healthcare data?
• → Vendor due diligence checklist for regulated industries
• → HL7 vs FHIR