HIPAA compliance typically adds a 15–30% premium over an equivalent non-regulated build — the cost of getting it wrong (breach notification, fines, lost trust) is far higher. This checklist is for product owners, CTOs, and compliance leads scoping a custom healthcare application that touches Protected Health Information (PHI).
Before You Start
- [ ] Confirm whether you're a Covered Entity, a Business Associate, or both — this determines which HIPAA obligations apply directly to you
- [ ] Identify every place PHI will be created, stored, transmitted, or displayed in the application, including logs, backups, and analytics tools
- [ ] Decide on your hosting model: HIPAA-eligible cloud services (AWS, Azure, GCP all offer BAAs) versus a dedicated compliant host
- [ ] Get a signed Business Associate Agreement (BAA) in place with every vendor that will touch PHI, including your hosting provider and any third-party APIs
Administrative Safeguards
- [ ] Appoint a named Privacy Officer and Security Officer (can be the same person in a small team)
- [ ] Document a formal risk analysis covering every system that touches PHI, updated at least annually
- [ ] Write and distribute a workforce training program on PHI handling, with signed acknowledgment
- [ ] Establish a documented incident response and breach notification procedure with defined timelines (60 days to notify affected individuals under the Breach Notification Rule)
Technical Safeguards
- [ ] Verify encryption at rest for all PHI-containing databases and backups
- [ ] Verify encryption in transit using TLS 1.2 or higher for every API and web endpoint
- [ ] Implement role-based access control (RBAC) so users only see the minimum PHI necessary for their role
- [ ] Enforce multi-factor authentication for any account with PHI access, especially admin accounts
- [ ] Confirm audit logs capture every PHI access event with user, timestamp, and action, and that logs cannot be modified or deleted by application users
- [ ] Set automatic session timeouts for idle sessions on any screen displaying PHI
Physical Safeguards
- [ ] Confirm your hosting provider's data center physical security controls are documented in their compliance reports (SOC 2, ISO 27001)
- [ ] If any on-premises servers or workstations touch PHI, document physical access controls for those locations
- [ ] Establish device disposal procedures that guarantee PHI is unrecoverable from decommissioned hardware
Testing and Validation Before Launch
- [ ] Run a penetration test focused specifically on PHI access paths, not just general application security
- [ ] Validate that de-identified or test data is used in all non-production environments — never real PHI in staging or dev
- [ ] Confirm that mobile apps or SMS/email notifications don't leak PHI into channels without a BAA (e.g., unencrypted push notification payloads)
Vendor / Partner Evaluation Criteria
| Criterion | Weight | Notes |
|---|---|---|
| Track record building HIPAA-compliant software | High | Ask for a reference client, not just a claim |
| Willingness to sign a BAA directly | High | Non-negotiable — walk away if a vendor won't sign |
| Documented technical safeguard implementation | High | Get specifics: encryption standard, RBAC model, audit logging |
| Post-launch compliance support (annual risk reviews) | Medium | Compliance isn't a one-time build; budget for ongoing reviews |
Red Flags to Watch For
- A development partner unwilling to sign a Business Associate Agreement
- "HIPAA-compliant by default" claims for a generic cloud template with no documented technical safeguards
- No plan for annual risk analysis updates after launch
- Real PHI used in staging or QA environments
How to Use This Checklist
Work through Administrative, Technical, and Physical safeguards as three separate workstreams with named owners. Treat this as a pre-launch gate — nothing touching PHI should reach production until every item is checked and documented, since documentation is what regulators and auditors will actually ask for after an incident, not intent.