The 2026 HIPAA Compliance Checklist for Developers and IT Teams

If you're building or maintaining software that touches protected health information (PHI), HIPAA compliance isn't something you can hand off to legal and forget about. The technical safeguards are your responsibility.

This checklist covers the requirements that actually matter for development and IT teams in 2026 — not the administrative fluff that compliance consultants pad their reports with.

Access Controls (45 CFR § 164.312(a))

The Security Rule requires unique user identification, emergency access procedures, automatic logoff, and encryption/decryption. Here's what that means in practice:

• Unique user IDs for every system user — No shared accounts. Ever. This includes service accounts, database connections, and API keys. Every action touching PHI needs to trace back to an individual.
• Role-based access control (RBAC) — Implement the minimum necessary standard. A billing clerk doesn't need access to clinical notes. A developer doesn't need production PHI access for debugging.
• Automatic session timeout — Idle sessions must terminate. The specific timeout depends on the risk context — a workstation in a shared nurse's station needs a shorter timeout than a locked server room terminal.
• Emergency access procedures — Document and test break-glass procedures for when normal authentication fails during a patient care emergency.
• Multi-factor authentication — Not explicitly required by the 2026 rule text, but any risk analysis that concludes MFA isn't necessary for ePHI systems won't survive OCR scrutiny.

Audit Controls (45 CFR § 164.312(b))

Every system containing ePHI needs audit logging:

• Who accessed what data
• When they accessed it
• What they did (read, write, delete, export)
• From where (IP address, device identifier)

Your audit logs themselves are compliance artifacts — they need tamper protection, retention policies (minimum 6 years for HIPAA documentation), and regular review processes. Dumping everything to a log file that nobody reads doesn't satisfy the requirement.

Encryption Requirements (45 CFR § 164.312(a)(2)(iv) and (e)(1))

• Data at rest — AES-256 for databases, file systems, backups, and removable media containing ePHI. Full-disk encryption on every device that might store PHI, including laptops, phones, and USB drives.
• Data in transit — TLS 1.2 minimum (TLS 1.3 preferred) for all ePHI transmission. This includes internal network traffic, not just external-facing APIs. If your microservices communicate PHI over plaintext HTTP internally, that's a finding.
• Key management — Documented procedures for key generation, distribution, storage, rotation, and destruction. HSMs or cloud KMS for production environments.

Integrity Controls (45 CFR § 164.312(c)(1))

Mechanisms to confirm ePHI hasn't been altered or destroyed improperly:

• Database integrity checks — Checksums, hash verification, or similar mechanisms for critical ePHI stores
• Transmission integrity — Message authentication codes or digital signatures for ePHI in transit
• Change management — Version control, code review, and deployment pipelines that prevent unauthorized modifications to systems handling PHI

Backup and Disaster Recovery (45 CFR § 164.308(a)(7))

• Retrievable exact copies of ePHI — Automated, tested backups with documented recovery procedures
• Disaster recovery plan — Document RPO (Recovery Point Objective) and RTO (Recovery Time Objective) for every system containing ePHI
• Testing — Actually restore from backups regularly. An untested backup is Schrödinger's backup — it simultaneously works and doesn't work until you try it.
• Geographic redundancy — For cloud deployments, ensure backups exist in a separate region/availability zone

Vulnerability Management

• Patch management — Document patching timelines. Critical vulnerabilities in ePHI systems should be patched within days, not months.
• Penetration testing — At least annual, covering all ePHI-accessible systems
• Vulnerability scanning — Automated, continuous scanning of infrastructure and applications
• Software composition analysis — Know your dependencies. A vulnerable library in your patient portal is your vulnerability.

Business Associate Requirements

If you're a vendor handling PHI for a covered entity (or a subcontractor of one):

• Business Associate Agreement (BAA) — Must be executed before any PHI access. No exceptions, no verbal agreements.
• Subcontractor chain — If you use AWS, GCP, or Azure for PHI workloads, you need a BAA with them. Same for any SaaS tools that might touch PHI (logging services, monitoring tools, email providers).
• Breach notification obligations — Business associates must report breaches to the covered entity within 60 days. Your incident response plan needs to account for this.

The Risk Analysis Foundation

Every item on this checklist should trace back to your Security Risk Analysis (SRA). The SRA identifies where ePHI lives, what threats exist, and what controls are needed. Without it, you're implementing controls based on guesswork rather than assessed risk.

For a detailed breakdown of how to structure your compliance checklist around assessed risks, this resource covers the full framework: HIPAA Compliance Checklist 2026

Automating Compliance Tracking

Manually tracking all of these requirements across an organization is where compliance programs break down. Spreadsheets get outdated, documentation gaps appear, and remediation items fall through the cracks.

Modern compliance platforms maintain a living view of your compliance posture — tracking which controls are implemented, which have gaps, and what remediation is needed. For an overview of how automated compliance management works in practice: HIPAA Compliance Solutions

---

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance tracking, and security programs.