This HIPAA compliance checklist gives healthcare app teams a practical way to confirm that the required safeguards are in place before launch and stay in place afterward. It covers whether HIPAA applies, administrative, technical, and physical safeguards, business associate agreements, breach response, and the proposed Security Rule changes still pending in 2026. Use it during planning, before security reviews, and at every major release. For a step-by-step build guide, see how to build a HIPAA-compliant app.
This checklist is general guidance, not legal advice. Confirm your obligations with qualified HIPAA counsel or a privacy officer.
Not every health app is subject to HIPAA, so the first checklist item is determining your status. HIPAA applies to covered entities, meaning most healthcare providers, health plans, and clearinghouses, and to business associates that handle PHI on their behalf. An app offered directly to consumers without a covered entity relationship may fall outside HIPAA but still face other rules. Document your conclusion, because customers and auditors will ask. Our glossary entry on HIPAA requirements explained covers the definitions.
☐ Determine whether your organization is a covered entity, a business associate, or neither. App developers building for providers or health plans are usually business associates.
☐ Confirm whether the app creates, receives, maintains, or transmits individually identifiable health information for a covered entity. If so, that information is PHI under HIPAA.
☐ If HIPAA does not apply, review FTC health data rules, including the Health Breach Notification Rule, plus state health privacy laws that may cover consumer health apps.
☐ Record your applicability analysis, the reasoning, and the date. Revisit it whenever your business model, customers, or data flows change significantly.
Administrative safeguards are the policies, procedures, and people decisions that make technical controls effective. They include assigning security responsibility, performing risk analysis, training staff, and planning for emergencies. OCR investigations frequently focus on administrative gaps, especially missing or outdated risk analyses. These items apply to the organization operating the app, so development partners and customers should agree on who owns each one before launch.
☐ Designate a named security official responsible for developing and implementing security policies. Assign a privacy official as well if your organization is a covered entity.
☐ Perform an accurate, thorough assessment of risks to ePHI across systems, vendors, and devices. Update it after significant changes and review it at least annually.
☐ Document how each identified risk is reduced to a reasonable level, with owners and deadlines. Track remediation progress and keep evidence of completed actions.
☐ Train all staff with access to PHI on security policies, phishing, and incident reporting at onboarding and periodically. Keep training records with dates and content.
☐ Maintain and apply a written policy for disciplining workforce members who violate security or privacy policies, and document every sanction that is applied.
☐ Document data backup, disaster recovery, and emergency operation procedures. Test restoration regularly so you know systems containing ePHI can actually be recovered.
Technical safeguards are the controls built into your app and infrastructure to protect ePHI. Under the current Security Rule, some are required and others are addressable, meaning you must implement them or document an equivalent alternative. In practice, OCR and enterprise customers now expect encryption and multi-factor authentication as standard, and the proposed Security Rule update would make several addressable controls mandatory. Treat every item below as expected for a modern healthcare app.
☐ Give every user a unique ID, enforce role-based access aligned to the minimum necessary standard, and include an emergency access procedure for critical situations.
☐ Require MFA for all workforce and administrative access to systems containing ePHI, and offer strong authentication options such as biometrics for patient-facing apps.
☐ Encrypt ePHI in transit using current TLS and at rest using strong encryption such as AES-256, including databases, backups, file storage, and mobile device caches.
☐ Log access, changes, exports, and logins for systems containing ePHI, protect logs from tampering, and review them on a defined schedule for suspicious activity.
☐ Protect ePHI from improper alteration or destruction using checksums, versioning, validation, and change tracking, so you can detect and correct unauthorized modifications.
☐ End inactive sessions automatically, invalidate tokens on logout, and prevent PHI from appearing in notifications, screenshots, or cached views on shared or lost devices.
Physical safeguards protect the facilities, devices, and media that store or access ePHI. For cloud-based apps, much of the data center responsibility shifts to your hosting provider, but you remain responsible for configuration, workforce devices, and media handling. Choosing a cloud provider that signs a BAA is essential, and our AWS, Azure, and GCP services team configures these environments for healthcare workloads.
☐ Host ePHI only with cloud providers that sign a BAA, and use only services covered by that agreement. Configure them securely, because a BAA does not secure misconfigured resources.
☐ Require encryption, screen locks, endpoint protection, and remote wipe on laptops and mobile devices used to access ePHI, including personal devices allowed under your policy.
☐ Securely wipe or destroy drives, devices, and media before disposal or reuse, and keep records showing what was disposed of, when, and by whom.
☐ Keep encrypted backups in separate locations, define recovery time objectives, and test restoration regularly. Ransomware resilience depends on backups attackers cannot reach.
☐ Keep production ePHI out of development and test environments. Use synthetic data for testing and restrict production access to authorized personnel.
Every vendor that creates, receives, maintains, or transmits ePHI on your behalf is a business associate and needs a signed BAA. Healthcare apps often depend on dozens of vendors, and gaps commonly appear in services teams forget handle PHI, such as error tracking, email delivery, or customer support tools. Maintain a living vendor inventory and review it whenever you add an integration, library, or service.
☐ List all vendors and services in your stack, including hosting, video, messaging, email, analytics, support, logging, and AI providers, and note which handle ePHI.
☐ Sign BAAs with every vendor handling ePHI before any PHI reaches them. If a vendor will not sign, redesign the data flow so PHI never reaches it.
☐ Confirm business associates bind their own subcontractors handling ePHI to equivalent obligations through subcontractor agreements.
☐ Review analytics, advertising, and crash-reporting SDKs for PHI collection. Remove them from screens displaying health information or confirm their vendors sign BAAs.
☐ Review BAAs, vendor security posture, and data flows at least annually and whenever vendor services or your product change significantly.
Even well-protected apps can experience security incidents, and HIPAA’s Breach Notification Rule sets specific obligations and deadlines once a breach of unsecured PHI is discovered. Preparing in advance makes the difference between an orderly response and a chaotic one. Your incident response plan should define roles, assessment steps, notification templates, and documentation, and it should be tested before you need it. Our app security services include incident readiness reviews.
☐ Document how incidents are detected, escalated, contained, investigated, and resolved, with named roles and contact details. Test the plan with tabletop exercises.
☐ For each incident involving PHI, assess the nature of the data, who received it, whether it was actually acquired or viewed, and how far risk was mitigated.
☐ Notify affected individuals without unreasonable delay and no later than 60 calendar days after discovering a breach of unsecured PHI.
☐ Report breaches affecting 500 or more individuals to HHS within 60 days, and notify media when more than 500 residents of a state are affected. Log smaller breaches for annual reporting.
☐ Retain HIPAA policies, risk analyses, incident records, and related documentation for six years from creation or last effective date, whichever is later.
In January 2025, HHS Office for Civil Rights proposed the most significant update to the HIPAA Security Rule in years. As of November 2026, it remains a proposal: no final rule has been published, the final action target has moved to July 2027, and the current Security Rule is still the standard enforced. Because many proposed controls already reflect what customers and investigators expect, preparing now reduces both risk and future rework.
☐ Monitor the Federal Register and OCR announcements. The proposal could be finalized, changed, delayed, or withdrawn, so avoid assuming its exact requirements or deadlines.
☐ The proposal would remove the addressable designation for key safeguards and require encryption and MFA with limited exceptions. Implementing both now aligns with current expectations.
☐ Maintain an inventory of technology assets and a map showing how ePHI moves through your systems. Both were proposed requirements and support better risk analysis today.
☐ The proposal included regular vulnerability scanning and annual penetration testing. Establishing that cadence now strengthens security and simplifies future compliance.
☐ Review BAAs for clear security expectations, incident reporting timelines, and verification rights, since the proposal emphasized stronger oversight of business associates.
Our work and story have been picked up by news outlets and databases worldwide.
As featured on
A HIPAA compliance checklist should cover applicability, administrative safeguards like risk analysis and training, technical safeguards like access controls, MFA, encryption, and audit logs, physical safeguards, business associate agreements, breach notification procedures, and documentation retention. Healthcare apps should also track proposed Security Rule changes still pending in 2026.
No. HHS does not publish an official certification checklist, and there is no government HIPAA certification for apps. HHS and NIST provide guidance and a security risk assessment tool. Organizations demonstrate compliance through documented safeguards, risk analyses, policies, and evidence that controls are implemented and maintained.
No. As of November 2026, the Security Rule update proposed in January 2025 has not been finalized, and its final action target has moved to July 2027. The current Security Rule remains in force. Many proposed controls, such as MFA and encryption, are already expected by customers and investigators.
HIPAA requires an accurate and thorough risk analysis and ongoing risk management, but does not set a fixed frequency. Most organizations review it at least annually and whenever systems, vendors, or data flows change significantly. Regular updates also demonstrate good faith during OCR investigations.
Yes, if the developer creates, receives, maintains, or transmits PHI on behalf of a covered entity, such as hosting data or providing support with access to production systems. Developers working only with synthetic data and no PHI access may not need one, but document that clearly.
Confirm applicability, map PHI, select BAA-covered vendors, and build encryption, MFA, access controls, and audit logging from the start, supported by policies, training, and incident response. Our healthcare app development team builds these safeguards into every project from discovery onward.
Offer this checklist as a gated PDF download (email capture) to turn the page into a lead magnet. Keep the full checklist visible on the page as well, so it remains indexable and AI-Overview eligible.
Tell us what you’re building. Our team will get back to you within one business day with a clear, no-obligation plan.
