If you're responsible for protecting sensitive information in healthcare, you've likely been told you need to comply with HIPAA. You may also have heard that NIST guidelines offer a more robust technical foundation. The truth is, you don't choose one over the other. HIPAA is your legal floor. NIST provides the implementation depth that HIPAA often lacks.
This checklist helps you identify where you stand with both frameworks and where they overlap. Use it to audit your current program and spot gaps before OCR does.
What This Checklist Covers
This checklist addresses the core requirements of HIPAA's Security Rule alongside corresponding NIST controls, specifically from NIST SP 800-66 (the guide for implementing HIPAA Security Rule) and NIST SP 800-53 (security controls for federal information systems). You'll see where HIPAA mandates a control and where NIST offers the technical detail to implement it correctly.
You're not building two separate programs. You're using NIST's technical rigor to meet HIPAA's legal requirements.
Prerequisites
Before you start this checklist, confirm:
- You've identified your entity type. Are you a Covered Entity, Business Associate, or both? HIPAA applies to healthcare providers, health plans, healthcare clearinghouses, and their Business Associates handling ePHI.
- You know what ePHI you hold. You can't protect what you haven't inventoried. Document where Electronic Protected Health Information lives, moves, and rests.
- You have executive support. Compliance isn't an IT project. Your HIPAA Compliance Officer and Privacy Official need authority and budget.
- You understand addressable vs. required. HIPAA's Addressable Specifications aren't optional. They mean you must implement the control or document why an alternative measure achieves the same outcome.
Compliance Checklist
Risk Analysis and Management
☐ 1. Conduct a HIPAA-required risk assessment (Security Rule § 164.308(a)(1)(ii)(A))
Identify threats and vulnerabilities to ePHI across your environment. HIPAA requires this but doesn't prescribe a methodology. NIST SP 800-30 provides a structured risk assessment process with threat modeling and likelihood scoring.
Good looks like: A documented risk assessment completed within the past 12 months, covering all systems that create, receive, maintain, or transmit ePHI. Each identified risk has an assigned owner, likelihood rating, impact rating, and mitigation plan.
☐ 2. Implement a risk management program (Security Rule § 164.308(a)(1)(ii)(B))
You can't assess risk once and call it done. NIST SP 800-37 describes a continuous risk management framework with ongoing monitoring.
Good looks like: A documented process for reviewing risks quarterly, updating the risk register when new systems launch or threats emerge, and tracking mitigation progress with measurable milestones.
Access Control
☐ 3. Assign unique user IDs to all users accessing ePHI (Security Rule § 164.312(a)(2)(i), Required Specification)
No shared logins. Ever. NIST AC-2 (Account Management) adds requirements for account types, approval workflows, and periodic reviews.
Good looks like: Every user has a unique identifier. Shared "clinic" or "front desk" accounts don't exist. Your access control system logs show individual accountability for every ePHI access event.
☐ 4. Implement role-based access controls (Security Rule § 164.308(a)(4)(ii)(B), Addressable Specification)
Users should access only the ePHI necessary for their job function. NIST AC-6 (Least Privilege) provides granular guidance on privilege levels and separation of duties.
Good looks like: Documented role definitions (e.g., "Billing Clerk," "Attending Physician") with specific ePHI access permissions. New hires receive access based on their role, not by copying another user's permissions.
☐ 5. Establish emergency access procedures (Security Rule § 164.312(a)(2)(ii), Required Specification)
When your EHR goes down or a critical system fails, you need a break-glass process. NIST CP-2 (Contingency Plan) covers emergency access within broader continuity planning.
Good looks like: A documented procedure for emergency ePHI access, including who can authorize it, how it's logged, and how you review those logs afterward. You've tested the procedure in the past year.
Audit Controls and Monitoring
☐ 6. Enable audit logging on all systems handling ePHI (Security Rule § 164.312(b), Required Specification)
If you can't see who accessed what ePHI and when, you can't detect a breach or insider threat. NIST AU-2 (Audit Events) specifies which events to log; AU-6 (Audit Review) covers analysis.
Good looks like: Centralized logging for all ePHI access, with logs retained for at least six years. You review logs at least weekly for anomalies, and your SIEM alerts on suspicious patterns (e.g., after-hours access, bulk downloads).
Encryption and Transmission Security
☐ 7. Encrypt ePHI at rest (Security Rule § 164.312(a)(2)(iv), Addressable Specification)
Addressable doesn't mean optional. If you don't encrypt, document why your alternative control (e.g., physical security) is equivalent. NIST SC-28 (Protection of Information at Rest) provides encryption standards.
Good looks like: Full-disk encryption on laptops and mobile devices. Database-level or file-level encryption for ePHI repositories. Encryption keys managed separately from encrypted data, with documented key rotation procedures.
☐ 8. Encrypt ePHI in transit (Security Rule § 164.312(e)(2)(ii), Addressable Specification)
ePHI moving across networks must be protected. NIST SC-8 (Transmission Confidentiality and Integrity) specifies TLS 1.2 or higher for web traffic and secure protocols for email.
Good looks like: All ePHI transmitted over public networks uses TLS 1.2 or 1.3. Your patient portal doesn't accept unencrypted connections. Email containing ePHI uses encryption or a secure portal link, never plain SMTP.
Workforce Training and Awareness
☐ 9. Train all workforce members on HIPAA policies (Security Rule § 164.308(a)(5)(i), Required Specification)
HIPAA and NIST both require security awareness training. NIST AT-2 (Security Awareness Training) adds specifics on phishing simulation and role-based training.
Good looks like: Annual HIPAA training for all workforce members, with additional role-specific training (e.g., developers receive secure coding training). You track completion rates and require training before granting ePHI access. Phishing simulations run quarterly.
Incident Response
☐ 10. Establish an incident response plan (Security Rule § 164.308(a)(6)(i), Required Specification)
You will have a security incident. The question is whether you'll respond effectively. NIST IR-8 (Incident Response Plan) provides a framework for detection, analysis, containment, eradication, and recovery.
Good looks like: A documented incident response plan that defines roles, escalation paths, and communication protocols. You've conducted a tabletop exercise in the past 12 months. Your plan includes breach notification timelines (60 days to notify affected individuals under the Breach Notification Rule).
Business Associate Management
☐ 11. Execute Business Associate Agreements (BAAs) with all vendors handling ePHI (Security Rule § 164.308(b)(1), Required Specification)
If a vendor creates, receives, maintains, or transmits ePHI on your behalf, you need a BAA. NIST doesn't address this directly because it's HIPAA-specific, but NIST SA-9 (External Information System Services) covers third-party risk management.
Good looks like: Signed BAAs with all Business Associates, including cloud providers, billing companies, and IT support vendors. Your BAAs include required HIPAA provisions and termination rights. You maintain a current inventory of all Business Associates and review their security posture annually.
Common Mistakes
Treating NIST as optional because you're HIPAA-compliant. HIPAA tells you what to protect. NIST tells you how to protect it. OCR increasingly references NIST in enforcement actions, expecting covered entities to follow recognized security practices.
Implementing Addressable Specifications without documentation. If you choose not to implement an addressable control, you must document your alternative approach and why it's reasonable and appropriate for your organization. Silence isn't compliance.
Conducting risk assessments but not managing risk. A risk assessment gathering dust on a shelf doesn't reduce risk. You need a management process that tracks mitigation efforts and reassesses when your environment changes.
Relying solely on one framework. HIPAA is your legal mandate, but its implementation guidance is thin. NIST provides the technical depth. Federal contractors may also need NIST SP 800-171 for controlled unclassified information. Don't ignore a framework because it's not explicitly required.
Next Steps
After completing this checklist, you should have a clear picture of your gaps. Prioritize them by risk level, not by ease of implementation. A missing encryption control on a public-facing portal matters more than an incomplete policy document.
Schedule your next risk assessment now. If it's been more than a year, you're overdue. If you've launched new systems, migrated to the cloud, or changed Business Associates, your risk profile has changed.
Finally, recognize that compliance is a program, not a project. HIPAA and NIST both require continuous monitoring, periodic review, and adaptation to new threats. Build that rhythm into your operations, and you'll stay ahead of both regulatory expectations and real-world risk.
