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

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

TL;DR — HIPAA for software in one paragraph

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 point where our HIPAA-compliant software development engagements begin, mapping every PHI flow before a line of remediation code is written. 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.

What counts as PHI: the 18 HIPAA identifiers

Protected Health Information is any individually identifiable health information held or transmitted by a Covered Entity or Business Associate that relates to a person's past, present, or future physical or mental health condition, healthcare provision, or payment for care. HHS specifies 18 categories that must be removed before data is considered de-identified under the Safe Harbor method (164.514(b)(2)):

1. Names
2. Geographic data smaller than state — street address, city, county, precinct, ZIP code (first 3 digits restricted for populations <20,000)
3. Dates (except year) directly related to an individual — birth, admission, discharge, death
4. Phone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate or licence numbers
12. Vehicle identifiers and serial numbers, including licence plate numbers
13. Device identifiers and serial numbers
14. Web URLs
15. IP addresses
16. Biometric identifiers — fingerprints, voice prints, retinal and iris scans
17. Full-face photographs and comparable images
18. Any other unique identifying number, characteristic, or code

In practice, combinations matter as much as individual fields. A diagnosis code plus ZIP code plus age can re-identify an individual even without a name. Design your data models with this in mind from day one: field-level encryption, fine-grained RBAC per identifier category, and export controls that strip all 18 categories before data crosses the ePHI perimeter. Treat IP addresses as PHI in any log that also contains a health condition — a common blind spot in analytics pipelines.

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.

2026 HIPAA Security Rule changes — what developers must implement now

The 2024 NPRM is the most significant revision to the Security Rule since the 2013 Omnibus Rule. Finalisation aside, OCR enforcement posture already reflects the new expectations. Below is a direct comparison of the old rule versus the 2026 operating standard for engineering teams:

The practical implication for engineering teams: treat every "Addressable" specification in 164.312 as a hard requirement. Document every implementation decision with a risk-justified rationale signed by a named officer. OCR auditors will specifically request justification for any "Addressable" specification that deviates from the reference implementation — and in 2024–2026 resolution agreements, absence of such documentation has been consistently cited as an aggravating factor in penalty calculation.

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.

Mobile app HIPAA checklist — iOS and Android

Mobile health applications present ePHI exposure surfaces that the core Security Rule text does not fully itemise. If your app handles PHI on a patient's personal device, the following controls are required in addition to the platform-agnostic safeguards above:

• Keychain (iOS) / Keystore (Android) for all credential and token storage. PHI tokens, session keys, and API secrets must never be stored in NSUserDefaults, SharedPreferences, unencrypted local SQLite, or the plain file system. Use the OS-provided secure enclave; on Android 9+, use StrongBox-backed keys where available.
• Biometric or PIN gate on every foreground resume. Automatic logoff under 164.312(a) applies to mobile: the app must re-authenticate after backgrounding beyond the timeout threshold — typically 5–15 minutes for clinical interfaces.
• Disable cloud backup for ePHI. iOS backs up app data to iCloud and Android backs up to Google Drive by default. Neither platform offers a consumer BAA. Exclude ePHI databases and files from the respective backup APIs (NSFileProtectionComplete + allowsCloudEncryption: false on iOS; android:allowBackup="false" or selective exclude rules on Android).
• Certificate pinning. Man-in-the-middle attacks on mobile TLS are common in healthcare Wi-Fi environments. Pin your API certificate fingerprint and fail closed on mismatch; use backup pins and a rotation window to avoid hard-locking on certificate renewal.
• Screenshot and screen-recording prevention. Set FLAG_SECURE on Android Activities containing PHI; monitor UIScreen.captureDidChange on iOS and blank the screen during capture. PHI visible on a screenshot is PHI disclosed.
• Jailbreak and root detection. A rooted device can read Keystore/Keychain content directly. Use a commercial detection library (SafetyNet Attestation / Play Integrity API on Android; DeviceCheck on iOS) and fail-close or restrict privileges on detection.
• Offline data controls. Limit ePHI cached locally to what the user's current session genuinely requires; time-bound the offline window (24 hours is a defensible maximum for most clinical contexts); re-encrypt the local cache on device re-lock.
• Push notification hygiene. Notification previews must not display PHI. Use generic message bodies ("You have a new message from your care team") rather than clinical content, even when the device is unlocked. Notification payloads that include PHI require the same BAA coverage as the API itself.

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.

HIPAA-compliant software development cost: 2026 estimates

HIPAA compliance is not a line item — it is an engineering discipline embedded throughout your SDLC. For a typical SaaS product built HIPAA-capable from scratch, compliance-specific work adds 25–40% to project cost. For a retrofit — compliance added to an existing, non-compliant system — the overhead runs 60–150% because architectural violations (unencrypted databases, shared accounts, missing audit logs) require invasive re-engineering, not configuration changes.

A Series A HealthTech company building a new EHR-adjacent platform should budget $150k–$350k for HIPAA engineering on a $500k–$1M product scope. Annual maintenance — monitoring, re-testing, training cycles, BAA refresh — runs $40k–$120k/year. Compare those numbers to the Tier 4 penalty ceiling of $2.13M per violation category per year and the ROI arithmetic is straightforward. Our HIPAA-compliant software development fixed-price assessments scope your specific architecture and produce a line-by-line remediation budget so cost surprises happen at estimate time, not audit time.

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.

How much does HIPAA-compliant software development cost?

For a new build, HIPAA engineering typically adds 25–40% to project cost. Major line items: encryption and key management ($15k–$40k), MFA and access controls ($10k–$25k), audit logging infrastructure ($15k–$35k), risk analysis ($8k–$20k), BAA vendor review ($5k–$15k), and an annual penetration test ($15k–$30k). A Series A HealthTech product at a $500k–$1M scope should budget $150k–$350k for HIPAA-specific engineering. Retrofitting compliance onto an existing non-compliant system typically costs 60–150% more because architectural violations — unencrypted databases, shared accounts, missing audit logs — require invasive re-engineering rather than configuration changes.

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.