HIPAA Software Testing Checklist: What Auditors Actually Look For
HIPAA software testing verifies that a system protects patient health information (PHI) at every point it's created, stored, transmitted, or displayed — not just that the app functions correctly. An auditor isn't scoring your test coverage percentage; they're checking whether PHI can leak through a role misconfiguration, an unencrypted log line, or a third-party integration nobody reviewed.
Below is the eight-point checklist we run before signing off on a healthcare release, plus the questions auditors ask about each control.
1. Access controls and role-based permissions
Every role in the system — clinician, billing staff, patient, admin — should see only the PHI it needs. Test this by attempting to access records outside a role's scope directly through the API, not just through the UI. A hidden button isn't access control; a rejected API call is.
Session timeout and re-authentication for sensitive actions (viewing a chart, exporting records) need explicit test cases, since these are the controls auditors ask about first.
2. Audit logging
HIPAA requires that every access to PHI is logged with who, what, when, and from where. Test that logs are actually written for read access, not just writes — most teams instrument create/update/delete and forget that a clinician simply viewing a record is also a loggable event.
Verify logs are tamper-evident and that log data itself doesn't leak PHI into a less-protected system (a common failure: PHI ending up in application logs shipped to a general-purpose logging tool).
3. HL7/FHIR interoperability
If the system exchanges data with EHR/EMR platforms, validate message conformance against the HL7 v2 or FHIR profile you've committed to, including edge cases: partial messages, malformed segments, and out-of-order delivery. A malformed HL7 message shouldn't silently corrupt a patient record — it should reject and alert.
4. Encryption in transit and at rest
Confirm TLS is enforced on every endpoint that touches PHI, including internal service-to-service calls, not only the public-facing API. At-rest encryption should be verified at the database and backup level — a backup snapshot stored unencrypted is still a HIPAA finding.
5. De-identification and minimum necessary
Where data is used for analytics or shared with a downstream service, test that de-identification actually removes all 18 HIPAA identifiers, not just the obvious ones like name and SSN. Fields like admission dates, device identifiers, and geographic subdivisions smaller than a state are frequently missed.
6. Business Associate Agreement (BAA) boundary testing
Any third-party service touching PHI — analytics, error tracking, email — needs a signed BAA, and your testing should confirm PHI never flows to a vendor without one. This means checking error-tracking payloads and analytics events for accidental PHI leakage, which is one of the most common real-world violations.
This includes your cloud hosting provider itself — a BAA with your application vendor doesn't cover the infrastructure layer underneath it.
7. Mobile and API-specific PHI handling
Mobile apps and public APIs are frequently the weakest link in an otherwise well-tested system. Test that mobile local storage, cached API responses, and push-notification payloads never contain PHI in plaintext, and confirm API rate-limiting and authentication can't be bypassed to enumerate patient records by iterating over IDs.
8. Breach-notification and incident-response readiness
Auditors increasingly ask for evidence that your incident-response plan has been tested, not just written. Run a tabletop exercise simulating a PHI exposure and confirm your breach-notification timeline — HIPAA requires notifying affected individuals within 60 days — is actually achievable with your current logging and monitoring, not just achievable on paper.
The checklist at a glance
A one-line summary of what each control area covers and why it's the specific thing an auditor probes for:
| Control area | What we test | What the auditor is checking |
|---|---|---|
| Access controls | Role-scoped API access, session timeout, re-auth on sensitive actions | Can a user reach PHI outside their role? |
| Audit logging | Read access is logged, logs are tamper-evident, no PHI in general logs | Is there a trail for every PHI touch? |
| HL7/FHIR interop | Message conformance, malformed/partial message handling | Does bad data corrupt records or get rejected? |
| Encryption | TLS everywhere, at-rest encryption including backups | Is PHI ever exposed in transit or storage? |
| De-identification | All 18 HIPAA identifiers removed, not just the obvious ones | Can de-identified data be re-identified? |
| BAA boundaries | No PHI flows to a vendor without a signed BAA | Are third parties (incl. cloud hosting) covered? |
| Mobile & API | No plaintext PHI in local storage/cache, no ID enumeration | Is the weakest surface actually tested? |
| Incident response | Tabletop-tested breach notification within 60 days | Is the response plan real or just documented? |
This is exactly the kind of work we do for clients.
Security & Compliance Testing →Frequently Asked Questions
- Is HIPAA compliance testing the same as HIPAA certification?
- No — there's no official HIPAA certification body. Compliance testing verifies your controls against the HIPAA Security and Privacy Rules; a compliance-readiness assessment gives you audit-ready evidence, but only an actual audit (internal or by a regulator) confers formal standing.
- How often should healthcare software be retested for HIPAA compliance?
- At minimum with every release that touches PHI handling, access control, or third-party integrations, plus a full regression pass on a quarterly or semi-annual cadence depending on your risk profile.
- Do we need a signed BAA with our cloud hosting provider?
- Yes — if your cloud provider (or any subprocessor) touches PHI in any form, including backups, you need a BAA with them specifically. A BAA with your application vendor doesn't cover the infrastructure layer underneath it.