HIPAA software development checklist — Privacy Rule, Security Rule, BAA

Sophie Laurent Legal & Compliance Lead, YuSMP Group · GDPR, HIPAA and EU AI Act practitioner

Does HIPAA apply to me? CE, BA, and the HITECH expansion

HIPAA (Public Law 104-191, 1996) and its regulations at 45 CFR Parts 160 and 164 apply directly to Covered Entities (CEs): health plans, healthcare clearinghouses, and healthcare providers that transmit any health information in electronic form in connection with a transaction for which HHS has adopted a standard (definition at 45 CFR 160.103).

The HITECH Act of 2009 and the 2013 Omnibus Rule extended most of the Privacy Rule and all of the Security Rule directly to Business Associates (BAs) — any person or entity that creates, receives, maintains, or transmits Protected Health Information on behalf of a CE. BAs include cloud providers, SaaS vendors, billing companies, transcription services, data analytics firms, and now — per HHS sub-regulatory guidance — AI inference providers when PHI passes through.

If you ship software that touches Protected Health Information, you are almost certainly a Business Associate. The HHS test is functional: do you have access to PHI in the course of providing services to a CE? If yes, BA status and the BAA requirement apply, regardless of contract framing.

Note the carve-out for "conduit" status (HHS Guidance, 2013): pure-transmission services (ISPs, postal services) that only transiently access PHI are not BAs. Cloud providers explicitly do not qualify for the conduit exception per the same guidance, because they store PHI even momentarily.

2026 penalty tiers and the HHS enforcement posture

Civil monetary penalties under 45 CFR 160.404, as adjusted for inflation in the 2024 Federal Register update, run on a tiered culpability scale. The 2026 figures, per the most recent HHS adjustment:

Criminal penalties under 42 USC 1320d-6 add prison sentences of 1–10 years for knowing violations and offences committed with intent to sell PHI for personal gain. State Attorneys General also have HITECH-conferred enforcement power. 2024–2025 saw OCR resolution agreements consistently land in the USD 1–5M range, with the Anthem and Premera settlements continuing to anchor the upper bound.

HHS published a Notice of Proposed Rulemaking in December 2024 to strengthen the Security Rule, including making most "addressable" specifications "required", mandating multi-factor authentication, encryption of ePHI at rest and in transit by default, asset inventories, and annual compliance audits. We treat the NPRM as the operating standard for any HIPAA build starting in 2026 — finalisation is widely expected in 2026–2027.

Privacy Rule essentials (45 CFR 164.500–534)

The Privacy Rule governs uses and disclosures of PHI in any form (paper, oral, electronic). For software builders, the operative provisions:

• 164.502 — Uses and disclosures generally. PHI may be used or disclosed only as the Privacy Rule permits or requires, or as authorised by the individual.
• 164.502(b) — Minimum necessary. Limit PHI to the minimum necessary for the intended purpose. In software: role-based access control and field-level visibility, not "everyone sees everything".
• 164.508 — Authorisations. Marketing, psychotherapy notes, sale of PHI — require specific written authorisation. Implementation: explicit consent flows with revocation paths.
• 164.514 — De-identification. Two safe harbors: Expert Determination (statistical) and Safe Harbor (remove 18 identifiers). De-identified data is outside HIPAA. Treat the de-identification pipeline as security-critical — re-identification is a breach.
• 164.520 — Notice of Privacy Practices. Required of CEs; BA contracts often require BA compliance with the CE's NPP.
• 164.524 — Right of access. Individuals must be able to access their PHI within 30 days (one 30-day extension allowed). Software must support patient data export in machine-readable formats (HHS guidance, 2020 OCR right-of-access initiative).
• 164.526 — Right to amend. Patients can request amendments; the system must accept and route amendment requests.
• 164.528 — Accounting of disclosures. 6-year history for non-treatment, non-payment, non-operations disclosures — the audit log must be designed for this from day one.

Security Rule technical safeguards (164.302–318)

The Security Rule governs electronic PHI (ePHI) only and is the rule software teams touch every day. It is organised into three safeguard groups, each with "Standards" (mandatory) and "Implementation Specifications" (Required or Addressable). "Addressable" does not mean optional — it means you must implement it or document a reasonable and appropriate alternative.

Administrative Safeguards — 164.308

• 164.308(a)(1) Security Management Process — risk analysis, risk management, sanction policy, information system activity review. The risk analysis is the foundation of the entire Security Rule programme; HHS findings consistently cite missing or stale risk analyses as the root cause in major settlements.
• 164.308(a)(3) Workforce Security — authorisation/supervision, clearance, termination procedures.
• 164.308(a)(4) Information Access Management — access authorisation, establishment and modification. Quarterly access reviews are now considered table-stakes.
• 164.308(a)(5) Security Awareness and Training — periodic training, security reminders, malware protection, login monitoring, password management.
• 164.308(a)(6) Security Incident Procedures — identify, respond, document, mitigate.
• 164.308(a)(7) Contingency Plan — data backup, disaster recovery, emergency mode operation, testing and revision, applications and data criticality.
• 164.308(a)(8) Evaluation — periodic technical and non-technical evaluation against the standard.
• 164.308(b) Business Associate Contracts — written satisfactory assurances (BAA) before allowing BA access.

Physical Safeguards — 164.310

Facility access controls (164.310(a)), workstation use and security (164.310(b)/(c)), device and media controls including disposal, re-use, accountability and backup (164.310(d)). For cloud-native SaaS the physical controls are largely inherited from the cloud BAA, but workstation policies for developer laptops touching ePHI in non-production environments are still yours to write and enforce.

Technical Safeguards — 164.312

This is the section your engineering team must implement directly. Five standards:

• 164.312(a) Access Control. Unique user identification (Required), emergency access procedure (Required), automatic logoff (Addressable — in practice required), encryption and decryption (Addressable — in practice required).
• 164.312(b) Audit Controls. Hardware, software, and procedural mechanisms that record and examine activity in information systems containing ePHI. No specified retention but 164.316(b)(2) sets 6 years for related documentation.
• 164.312(c) Integrity. Mechanism to authenticate ePHI — protect from improper alteration or destruction. Cryptographic hashes, digital signatures, write-once storage for audit logs.
• 164.312(d) Person or Entity Authentication. Verify identity before granting access. MFA is now treated as the floor.
• 164.312(e) Transmission Security. Integrity controls and encryption of ePHI in transit. TLS 1.2+ everywhere, no exceptions.

Breach notification: the 60-day clock (164.400–414)

Breach notification was added by HITECH and codified at 45 CFR Subpart D. A "breach" is the acquisition, access, use or disclosure of unsecured PHI in a manner not permitted by the Privacy Rule and that compromises security or privacy (164.402). Four-factor risk assessment determines whether notification is required; the presumption is that an impermissible use or disclosure is a breach unless the four-factor analysis demonstrates low probability of compromise.

The safe harbor: if PHI was encrypted to the HHS/HITECH guidance standard (NIST SP 800-111 at rest, NIST SP 800-52 / FIPS 140-2 validated TLS in transit), the loss event is not a reportable breach. Encryption is the single highest-leverage control in the entire HIPAA technical stack.

BAAs and the subcontractor chain

The BAA requirement at 45 CFR 164.504(e) is non-negotiable. Required elements:

• Permitted and required uses and disclosures of PHI by the BA.
• BA will not use or disclose PHI other than as permitted or required.
• BA will implement appropriate safeguards (Security Rule for ePHI).
• BA will report breaches and security incidents.
• BA will ensure subcontractors agree to the same restrictions (164.308(b)(2), 164.502(e)(1)(ii)).
• BA will make PHI available for individual access, amendment, and accounting.
• BA will return or destroy PHI at termination (if feasible).
• BA will make compliance practices available to HHS.
• Termination for material breach.

Build a BAA inventory now if you do not have one. We see programmes where Postgres on a HIPAA-eligible RDS instance is properly under BAA, but logs flow to a non-HIPAA observability stack — an instant violation. Every downstream service that even transiently sees ePHI needs a BAA.

Cloud, LLMs, mobile and IoT — ePHI in modern stacks

Modern HIPAA realities go beyond what the 1996 statute imagined. Practical implications:

• Cloud. AWS, GCP, Azure publish HIPAA-eligible service lists. Sign the BAA before sending ePHI. Restrict ePHI workloads to eligible services only. Be careful with "shadow" services analysts spin up.
• LLMs. AWS Bedrock, Azure OpenAI Service and Vertex AI offer BAA-covered usage. Consumer ChatGPT and Claude.ai are not BAA-covered — even pasting PHI into a developer console is a breach. For RAG over PHI, the embedding store, vector DB, and retrieval logs all hold ePHI and need full BAA coverage. Our HIPAA-compliant software development practice treats the LLM stack as a first-class ePHI surface.
• Mobile. iOS and Android health apps that handle PHI must use Keychain / Keystore for credentials, enforce biometric or PIN gate, disable backup of ePHI to user iCloud / Google Drive unless under BAA (neither is), and pin certificates.
• IoT and remote monitoring. Device-to-cloud transport encryption, device identity rotation, secure boot, and tamper-evident logging. FDA 510(k) overlay for class-II/III devices.

A HIPAA-compliant SDLC in 8 pillars

1. Risk analysis per 164.308(a)(1)(ii)(A), refreshed annually and after material change. Use NIST 800-30 methodology; auditors recognise it.
2. Workforce training per 164.530(b) for everyone touching PHI; documented in an LMS with completion attestations.
3. Least-privilege access with quarterly access reviews per 164.308(a)(4); SCIM-provisioned, JIT for production access, role definitions versioned.
4. Audit logging in tamper-evident store (object lock, append-only) with 6+ year retention to satisfy 164.316(b)(2); log every PHI read, write, delete and export, with user, timestamp, source IP, and record identifier.
5. Encryption at rest (AES-256, KMS-managed keys) and in transit (TLS 1.2+, FIPS 140-2 validated crypto modules where feasible); BYOK for enterprise tenants.
6. Backup, DR, and tested contingency plan per 164.308(a)(7); RTO/RPO documented per system, restoration tested at least annually.
7. BAA chain mapped, refreshed annually, gated through procurement.
8. Incident response runbook with the 60-day breach clock baked in, tested twice yearly via tabletop, integrated with on-call paging.

The technical checklist auditors actually use

• Unique user IDs — no shared accounts, ever.
• MFA enforced for every account with PHI access, no exceptions for "admin convenience".
• Session timeouts ≤ 15 minutes for clinical interfaces, ≤ 30 for back-office.
• Automatic logoff implemented and tested.
• Encryption at rest with KMS-managed keys; key rotation policy documented and executed.
• TLS 1.2+ everywhere; weak ciphers disabled; HSTS preload.
• Audit logs append-only, immutable, with integrity verification (HMAC or signed); 6-year retention.
• PHI export audit trail with field-level resolution.
• De-identification pipeline validated against Safe Harbor or Expert Determination, with re-identification risk re-tested annually.
• Production database access via JIT only, every session recorded.
• Backups encrypted, geographically diverse, restore-tested.
• Vendor BAA inventory current; every PHI-touching service in scope.
• Risk analysis current, signed, dated within last 12 months.
• Incident response runbook current, last tabletop within 6 months.
• Workforce training records current, last cycle within 12 months.

Top 10 violations we see in pre-audit reviews

1. Risk analysis missing or 3+ years stale.
2. Logs flowing to a non-BAA observability vendor (Datadog default, Sentry default, etc.).
3. Developer "shadow" access to prod with no JIT, no recording.
4. Shared service accounts, often dev-era leftovers.
5. De-identification implemented as ad-hoc SQL, not a validated pipeline.
6. Mobile app caches PHI to local storage without encryption.
7. ChatGPT or Claude.ai used by support staff with real PHI — instant breach.
8. Backups encrypted in transit but stored decrypted on a CDN cache.
9. No BAA with email provider despite PHI in support ticket bodies.
10. Incident response runbook references the 60-day clock but no one has paged it in 18 months.

If you are scoping a HealthTech build or remediating a HIPAA programme, we run fixed-price gap assessments through HIPAA-compliant software development; we have shipped these in tandem with SaaS development and custom software programmes, and a fractional CTO with shipped HIPAA experience usually pays back inside the first two months on de-risking alone.

FAQ

Do I need to be HIPAA compliant if I am only a vendor?

If you create, receive, maintain or transmit PHI on behalf of a Covered Entity, yes — you are a Business Associate under 45 CFR 160.103, HITECH-extended Security Rule and most of the Privacy Rule apply directly, and you owe a BAA.

What does the Security Rule technically require?

164.312 Technical Safeguards: access control with unique IDs and emergency access (164.312(a)), audit controls (164.312(b)), integrity (164.312(c)), authentication (164.312(d)) — with MFA as the 2026 floor — and transmission security with TLS 1.2+ (164.312(e)).

How long do I have to report a breach?

CE: notify individuals within 60 days of discovery (164.404); HHS contemporaneously if 500+; annual log if <500. BA: notify CE within 60 days (164.410), usually contractually shortened to 5–30.

Does encryption give a breach-notification safe harbor?

Yes, if encrypted to the HHS/HITECH guidance standard — NIST 800-111 at rest, NIST 800-52 / FIPS 140-2 in transit. Keys must be separate from ciphertext.

Can I use AWS, GCP, Azure for ePHI?

Yes — sign the BAA first, restrict to HIPAA-eligible services, implement KMS encryption, IAM least privilege, full audit logging, VPC isolation. Check the eligibility list quarterly.

What does a HIPAA-compliant SDLC look like?

Eight pillars: risk analysis, workforce training, least-privilege access, audit logging with 6-year retention, encryption, contingency plan, BAA chain, incident response with the 60-day clock baked in.

HIPAA is not a checklist. It is an operating posture.

Teams that ship HIPAA cleanly treat compliance as a build-time artefact: BAA-gated procurement, encrypted-by-default services, audit logs generated by the framework not by hand, MFA enforced from day one, risk analysis on a calendar. Teams that treat HIPAA as an end-of-project audit always miss something material and pay for it during an OCR investigation.

Last updated 26 May 2026. References to sections are to 45 CFR Parts 160 and 164. Nothing in this article constitutes legal advice for a specific situation.