HIPAA Compliant App Development Checklist: 10 Controls, Evidence and Tests

Encryption is addressable under the current HIPAA Security Rule, while a documented risk analysis is required by 45 CFR 164.308(a)(1)(ii)(A). HHS risk-analysis guidance explains the requirement. Engineering leads should translate the assessment into controls that build pipelines, identity providers, endpoints, and cloud accounts can enforce and demonstrate. This HIPAA-compliant app development checklist maps ten controls to administrative, physical, and technical safeguards, with evidence to retain and an accountable owner for each.

The Security Rule also includes physical safeguards under 45 CFR 164.310, covering facility access, workstation use and security, and device and media controls. The HHS Security Rule regulations set out these requirements alongside administrative and technical safeguards. For the end-to-end process, see our guide to HIPAA compliance for software development; this checklist focuses on the evidence and tests behind each control. This article provides general information, not legal or regulatory advice.

Administrative safeguards establish the engineering baseline

1. Documented risk analysis

Regulation: 45 CFR 164.308(a)(1)(ii)(A) requires risk analysis; paragraph (B) requires risk management. Start with the complete ePHI environment, including mobile caches, APIs, queues, databases, EHR interfaces, analytics, logs, backups, and support tools.

For each flow, record the owner, access roles, retention decisions, existing safeguards, threat, likelihood, impact, and remediation decision. Our engineering recommendation is to make unresolved material risks a release decision that named security and business owners must approve.

Hypothetical worked example: A patient app retrieves FHIR Observation resources through an API and stores results locally for offline viewing.

1. Engineering maps the EHR-to-API-to-device flow and identifies the cache and crash-reporting path.

2. Security evaluates lost-device access and accidental payload disclosure.

3. Mobile engineers encrypt the cache, suppress sensitive crash payloads, and implement session termination.

4. QA tests a locked device, expired session, and failed synchronization, retaining results with the risk register.

Keep this evidence connected to the product's wider safety work when developing SaMD solutions.

Owner and evidence: Security owns the assessment; engineering owns system accuracy and remediation. Keep the versioned data-flow diagram, risk register, approval record, and mitigation retest results.

Technical safeguards protect data and identity

2. Encryption in transit and at rest

Regulation: Encryption/decryption under 45 CFR 164.312(a)(2)(iv) and transmission encryption under 164.312(e)(2)(ii) are addressable specifications. The HHS technical-safeguards guidance explains that addressable specifications require an environment-specific assessment, rather than an automatic exemption.

We recommend encryption as the default across databases, object storage, queues, backups, and mobile caches. Use managed key storage, separate key administration from application administration, and test recovery when the normal key-access path fails.

For a patient-upload workflow, check both the upload connection and the destination object store. An encrypted database doesn't protect an attachment copied into an unprotected export location.

Document the encryption boundary, including temporary files and exports. A checkbox for database encryption leaves those paths untested.

Owner and evidence: Platform engineering owns infrastructure settings; application teams own client storage and transport behavior. Keep transport configuration exports, certificate checks, key policies, storage-encryption reports, and documented decisions for any alternative safeguard.

3. Unique user IDs and role-based access control

Regulation: 45 CFR 164.312(a)(1) governs access control, 164.312(a)(2)(i) requires unique user identification, and 164.308(a)(4) addresses information access management.

Build an authorization matrix around actual clinical and operational duties. Give each human a distinct identity, scope service identities to their function, and enforce authorization at the API and data-access layers.

For example, a scheduling workflow may need patient demographics and appointments without access to clinical notes. Test that restriction through direct API requests, including attempts to change patient identifiers or cross tenant boundaries.

Emergency access under 164.312(a)(2)(ii) also needs an implementation. Define who can activate it, how access is recorded, and who reviews its use.

Owner and evidence: The customer's clinical or operational owner approves permissions; identity and application engineers implement them. Retain the access matrix, negative authorization tests, account-removal tests, access-review decisions, and emergency-access records.

4. MFA and person or entity authentication

Regulation: 45 CFR 164.312(d) requires procedures to verify the claimed identity of a person or entity seeking access to ePHI. The current rule doesn't explicitly prescribe MFA, although the risk analysis must inform appropriate authentication safeguards.

Our recommendation is MFA for human access to PHI, with particular attention to administrators, support personnel, and export workflows. Choose authentication methods and recovery procedures together; a strong login flow provides little protection if help-desk recovery bypasses it.

For a clinician portal, test login, device replacement, lost-factor recovery, and reauthentication before a bulk export. For service identities, use separately managed credentials and verify that disabling one integration doesn't interrupt unrelated workloads.

Owner and evidence: Identity engineering owns enforcement; security owns authentication policy; customer administrators own approved enrollment and recovery decisions. Keep identity-provider configuration, MFA bypass tests, recovery approvals, and service-credential revocation results.

Audit and session controls make access accountable

5. Audit logging, log review, and breach response

Regulation: 45 CFR 164.312(b) requires audit controls, 164.308(a)(1)(ii)(D) addresses activity review, and 164.308(a)(6) requires security incident procedures.

Record actor, timestamp, action, resource identifier, source, and outcome for relevant reads, writes, exports, privilege changes, and administrative actions. Avoid clinical payloads unless needed, and protect any sensitive identifiers retained in the audit system.

An export alert should lead to an investigation workflow: identify the actor, determine the affected records, preserve evidence, contain access, and escalate to the designated incident lead. A logging service without review ownership won't complete that workflow.

Regulation: A business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery of a breach of unsecured PHI, according to HHS breach-notification guidance. Treat that as an outer limit, not an internal investigation target.

Owner and evidence: Security operations owns detection and review; engineering supplies logs and scope analysis; compliance and legal own notification decisions. Retain review records, alert tests, incident timelines, and tabletop findings.

6. Automatic logoff and session management

Regulation: Automatic logoff under 45 CFR 164.312(a)(2)(iii) is addressable. Select an inactivity period through the risk analysis and document the decision, including differences between shared workstations and personal devices.

Implement session termination beyond the visible screen. Test API access after expiry, refresh-token behavior, logout, account disablement, and emergency revocation.

Consider a shared clinical tablet: hiding the patient view still leaves exposure if the previous user's session can retrieve data. Endpoint controls should also address cached records, app-switcher previews, lock-screen notifications, and workstation handling.

Test the expired session with a direct API request. A browser redirect alone doesn't prove that access ended.

Owner and evidence: Application and identity engineers own session behavior; customer IT owns managed-device policies. Keep timeout tests, revocation results, endpoint configuration, and the documented usability trade-off.

Integrity and recovery preserve clinical workflows

7. Integrity controls

Regulation: 45 CFR 164.312(c)(1) requires protection against improper alteration or destruction. Its addressable implementation specification, 164.312(c)(2), concerns mechanisms to corroborate that ePHI hasn't been improperly altered or destroyed.

Engineering should define which changes are legitimate, who can perform them, and how conflicts are handled. Validate inbound messages, protect database relationships, preserve relevant change history, and prevent retries from creating duplicate clinical records.

For a lab integration, test duplicate delivery, conflicting updates, partial processing, and a retry after a connection failure. Decide explicitly whether the system rejects, reconciles, or queues each conflict for review.

Owner and evidence: Integration engineers own message handling; application teams own write authorization and validation; clinical product owners approve reconciliation behavior. Keep duplicate-delivery tests, conflict tests, validation failures, and traceable change records.

8. Backups and disaster recovery

Regulation: 45 CFR 164.308(a)(7) establishes contingency-planning requirements, including backup, disaster recovery, and emergency-mode operation plans. Testing and revision is an addressable specification, so document its evaluation rather than treating it as universally prescribed at a fixed frequency.

We recommend encrypted backups isolated from ordinary production deletion privileges, with recovery objectives agreed with clinical and operational owners. Include storage media, disposal, and device handling under the physical-safeguard review.

For a ransomware scenario, restore into an isolated environment and test the application workflow, not just database startup. Confirm that identity, keys, integration configuration, and queued work are recoverable together.

Owner and evidence: Platform engineering owns restoration; customer operations approves recovery priorities; security reviews isolation. Retain restore logs, observed recovery time, data-gap analysis, key-recovery results, and approved corrective actions.

Vendor governance and development controls close release gaps

9. BAAs with vendors handling PHI

Regulation: 45 CFR 164.308(b) and 164.314(a) address business-associate arrangements and security contract requirements. Identify whether each vendor is a business associate or subcontractor, then put the required agreement in place before the service creates, receives, maintains, or transmits PHI.

Inventory cloud hosting, email, analytics, error tracking, observability, support systems, and AI processing. Record the specific service and configuration covered. A commercial relationship with a vendor does not establish that every product it sells is covered.

Map each PHI flow through the service, including ingestion, processing, storage, telemetry, support access, and deletion. If an analytics destination lacks appropriate coverage, remove PHI from that flow or disable it.

Owner and evidence: Legal and compliance own contractual assessment; procurement maintains agreements; engineering verifies actual routing. Keep executed BAAs, the vendor register, approved data-flow diagrams, and payload inspection results.

10. Secure SDLC and vulnerability management

Regulation: Risk management under 45 CFR 164.308(a)(1)(ii)(B), malicious-software protection under 164.308(a)(5)(ii)(B), and evaluation under 164.308(a)(8) support ongoing security work. These provisions do not prescribe a specific scanner or pipeline product.

Use threat modeling, dependency and container scanning, secret detection, code review, staging security tests, and risk-based remediation targets. HHS cybersecurity guidance identifies unpatched software vulnerabilities as risks regulated entities must assess and address.

Set release gates around exploitability and exposure. For a vulnerable dependency on a reachable PHI-processing path, block release until remediation or an approved exception. Document the compensating control, accountable owner, expiry, and retest requirement. Define penetration-test scope around the application's PHI flows and trust boundaries.

Use synthetic test data by default and keep production credentials out of CI. For how Ekipa approaches delivery, see our AI delivery framework.

Owner and evidence: Engineering owns remediation; security validates severity and exceptions; release owners enforce gates. Retain scan outputs, triage decisions, build provenance, test results, and exception approvals.

How each checklist item maps to the Security Rule

Use this table as the control-to-rule reference. The “Proof test” column adds an operational check: a retained artifact shows what was configured, while the test shows whether the control works as intended.

Checklist item	Safeguard type	Primary rule citation	Evidence artifact	Proof test
Documented Risk Analysis	Administrative	45 CFR 164.308(a)(1)(ii)(A) and (B)	Data-flow inventory, risk register, review records	Trace a representative PHI flow from collection through storage and sharing; confirm identified risks have owners and documented treatment decisions.
Encryption in Transit and at Rest	Technical	45 CFR 164.312(a)(2)(iv), 164.312(e)(2)(ii)	TLS configurations, key policies, encryption reports	Inspect deployed endpoints and storage settings; verify that unencrypted connections are rejected and protected data is encrypted.
Unique User IDs and Role-Based Access Control	Technical and administrative	45 CFR 164.312(a)(1), (a)(2)(i), 164.308(a)(4)	User and role records, access reviews, authorization scopes	Attempt access with distinct user roles; confirm each can reach only the permitted records and functions.
Multi-Factor Authentication and Person or Entity Authentication	Technical	45 CFR 164.312(d)	Identity provider settings, MFA logs, service authentication configuration	Test successful and failed authentication paths, including a missing second factor and an invalid service credential.
Audit Logging, Log Review and Breach Response	Technical and administrative	45 CFR 164.312(b), 164.308(a)(1)(ii)(D), 164.308(a)(6)	Log schemas, review records, incident runbooks	Generate a test access event and confirm it is recorded with enough detail for review; run a response exercise against a defined incident scenario.
Automatic Logoff and Session Management	Technical	45 CFR 164.312(a)(2)(iii)	Timeout settings, session revocation records, risk analysis rationale	Leave a session idle and verify timeout behavior; revoke an active session and confirm its credentials no longer grant access.
Integrity Controls	Technical	45 CFR 164.312(c)(1) and (c)(2)	Version history, integrity checks, conflict and change logs	Change a test record through an authorized path, then verify the change is attributable and unintended changes are detected or recoverable.
Backups and Disaster Recovery	Administrative	45 CFR 164.308(a)(7)	Backup records, restore test results, recovery objectives	Restore a representative dataset into a controlled environment and confirm it is usable for the intended workflow.
Business Associate Agreements With Every Vendor That Touches PHI	Administrative	45 CFR 164.502(e), 164.504(e), 164.308(b), 164.314(a)	Executed agreements and vendor register	Trace a PHI flow to each external service; confirm the relationship and permitted handling match the documented agreement.
Secure SDLC and Vulnerability Management	Administrative and technical	45 CFR 164.308(a)(1)(ii)(B), 164.308(a)(5)(ii)(B), 164.308(a)(8)	Threat models, scan results, remediation and exception records	Introduce a known vulnerable dependency in a test change and verify the release gate blocks or routes it through an approved exception process.

Plan for the proposed Security Rule update

HHS published a proposed Security Rule update on January 6, 2025, under RIN 0945-AA22. The proposal would make encryption and multi-factor authentication mandatory, among other changes, as described on the HHS Security Rule page. Track the proposal separately from the requirements used to approve releases under the current rule.

Check the HHS Security Rule NPRM page and the Federal Register record for RIN 0945-AA22 before changing compliance requirements. The proposal provides a planning signal, while the current Security Rule remains the basis for release decisions until HHS finalizes an update.

Engineering leads can prepare by inventorying systems and data flows, scheduling control tests, exercising recovery procedures, and organizing evidence. Record which proposed provisions would require changes, who owns them, and what release evidence would demonstrate readiness.

Conclusion

A HIPAA-compliant app is one where each safeguard is designed, owned, tested and evidenced, not one that passed a single review. Start from the risk analysis, assign an owner and a proof test to each of the ten controls, and keep the evidence current as the product changes. Track the proposed Security Rule update in a separate readiness record so release decisions stay tied to the rule in force. For audit preparation, see our HIPAA compliance audit guide, and for cloud setup, HIPAA compliance on AWS. To build a HIPAA-ready product with an experienced team, explore Ekipa's HealthTech engineering or book a consultation.

Frequently asked questions

What should a HIPAA compliant app development checklist include?

At minimum: a documented risk analysis, encryption in transit and at rest, unique user IDs with role-based access, strong authentication, audit logging and review, automatic logoff, integrity controls, backups and recovery, business associate agreements with vendors that handle PHI, and a secure development and vulnerability management process.

Is encryption required under HIPAA?

Under the current Security Rule, encryption is an addressable implementation specification. That means you must assess it and either implement it or document why an equivalent alternative is reasonable. In practice, most teams encrypt PHI by default, and the proposed Security Rule update would make encryption mandatory.

Does HIPAA require multi-factor authentication?

The current rule requires procedures to verify the identity of anyone accessing ePHI but does not name MFA explicitly. Your risk analysis should decide the method; MFA is a common choice for human access to PHI, and the proposed update would require it.

Does a cloud provider's BAA make the app compliant?

No. A BAA addresses the business relationship and permitted handling of PHI. The organization remains responsible for its own safeguards, risk management, operating procedures, and evidence that the application and cloud configuration work as intended.

How long does a business associate have to report a breach?

A business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovering a breach of unsecured PHI. A BAA can set a shorter deadline.