If your mobile app touches patient health data in any form, HIPAA compliance is not a nice-to-have — it is a legal obligation with penalties that range from $100 to $50,000 per violation, up to a maximum of $1.5 million per year per violation category. The Office for Civil Rights (OCR) has settled or imposed penalties exceeding $140 million since 2003, and enforcement actions have only accelerated.
Building a HIPAA-compliant mobile app is entirely achievable, but it requires deliberate architectural decisions from day one. Retrofitting compliance into an existing app is significantly more expensive and error-prone than building it in from the start. This checklist covers every major requirement you need to address.
Understanding What Triggers HIPAA
Not every health-related app falls under HIPAA. The regulation applies when three conditions converge: your app handles Protected Health Information (PHI), the data involves a covered entity (healthcare providers, health plans, or healthcare clearinghouses), and your organization qualifies as a covered entity or a business associate of one.
PHI includes any individually identifiable health information — names, dates, medical record numbers, diagnoses, lab results, prescription data, biometric identifiers, and even IP addresses when linked to health records. If your app stores, transmits, or processes any of this data on behalf of a covered entity, you are subject to HIPAA's Security Rule, Privacy Rule, and Breach Notification Rule.
A common misconception is that wellness apps and fitness trackers are automatically exempt. They may be — unless a healthcare provider prescribes the app or the data flows into a covered entity's system. When in doubt, consult a healthcare compliance attorney before making architectural decisions.
Business Associate Agreements with Cloud Providers
Any third-party service that handles PHI on your behalf must sign a Business Associate Agreement (BAA). This includes your cloud infrastructure provider, email service, analytics platform, crash reporting tool, and database host.
AWS, Google Cloud, and Microsoft Azure all offer BAAs, but the specifics vary. AWS covers over 150 HIPAA-eligible services under its BAA, including S3, RDS, Lambda, API Gateway, and Cognito. Google Cloud covers BigQuery, Cloud SQL, Compute Engine, and Cloud Storage. Azure covers most of its core services. However, signing the BAA alone is not enough — you must configure those services according to each provider's HIPAA implementation guide.
Critical details often missed: not all services from a given provider are covered. For example, AWS's standard SNS for SMS messaging is not HIPAA-eligible. You need to verify every service in your stack against the provider's current HIPAA-eligible service list. Maintain a documented inventory of every third-party service, its BAA status, and the PHI it may access.
Encryption at Rest and in Transit
HIPAA's Security Rule requires you to implement encryption as an "addressable" specification — meaning you must either implement it or document why an equivalent alternative is reasonable. In practice, there is no defensible reason to skip encryption for a mobile app in 2026.
For data in transit, enforce TLS 1.2 or higher for all API communications. Implement certificate pinning to prevent man-in-the-middle attacks. Disable fallback to older TLS versions and weak cipher suites. Your API should reject any connection attempt that does not meet minimum encryption standards.
For data at rest, use AES-256 encryption for all stored PHI. On iOS, leverage the Keychain Services API with the kSecAttrAccessibleWhenUnlockedThisDeviceOnly attribute for sensitive tokens and keys. On Android, use the Android Keystore system with hardware-backed key storage when available. For server-side storage, use your cloud provider's Key Management Service (KMS) — AWS KMS, Google Cloud KMS, or Azure Key Vault — with customer-managed keys for maximum control.
Database encryption should use Transparent Data Encryption (TDE) at minimum, with field-level encryption for the most sensitive PHI columns. Store encryption keys separately from the encrypted data, ideally in a dedicated KMS with automatic key rotation every 90 to 365 days.
Access Controls and Authentication
The Security Rule mandates unique user identification, emergency access procedures, automatic logoff, and encryption/decryption controls. For a mobile app, this translates into concrete requirements.
Implement multi-factor authentication (MFA) for all users who access PHI. At minimum, combine something the user knows (password) with something the user has (TOTP authenticator app, SMS code, or push notification). NIST 800-63B guidelines recommend against SMS-based MFA due to SIM-swapping risks, but it remains acceptable under HIPAA.
Enforce role-based access control (RBAC) so that each user can only access the minimum PHI necessary for their role. A nurse, a billing clerk, and a physician should see different data sets. Implement this at the API level, not just the UI — every endpoint must validate the requester's role and permissions.
Session management is critical on mobile. Set session timeouts between 5 and 15 minutes of inactivity for apps handling PHI. Require re-authentication after the timeout. Implement server-side session revocation so that a compromised token can be invalidated immediately. Assign a unique identifier to every user — shared or generic accounts are a HIPAA violation.
Audit Logging
HIPAA requires logging all access to PHI, including who accessed it, when, what they accessed, and from where. Your audit trail must be tamper-evident and retained for a minimum of six years.
Log every authentication event (successful and failed), every PHI access event, every data modification, every export or download, and every administrative action. Include timestamps in UTC, user identifiers, source IP addresses, device identifiers, and the specific resource accessed.
Critically, your audit logs must not contain PHI themselves. Log that "User 4782 accessed patient record 9103 at 2026-02-27T14:32:00Z" — do not log "Dr. Smith accessed Jane Doe's diabetes diagnosis." Use opaque identifiers that can be correlated with PHI only through the application's access-controlled database.
Use a centralized logging service — AWS CloudWatch Logs, Datadog, or Splunk — with write-once storage policies. Enable log integrity validation (CloudWatch Logs supports this natively with log group data protection). Set up real-time alerts for anomalous access patterns: bulk record access, access outside business hours, or repeated failed authentication attempts.
Mobile-Specific Concerns
Mobile devices introduce risks that do not exist in web-only applications. Address each of these explicitly.
Push notifications must never contain PHI. A notification that reads "Your lab results for glucose test are ready" violates HIPAA. Instead, use generic messages: "You have a new message in the app." Configure both APNs (Apple Push Notification service) and FCM (Firebase Cloud Messaging) to send data-only payloads that trigger the app to display a generic local notification.
Implement screenshot and screen recording prevention. On iOS, detect UIApplicationUserDidTakeScreenshotNotification and consider using a secure text field overlay technique to prevent screen capture of sensitive views. On Android, set FLAG_SECURE on activities displaying PHI, which blocks screenshots and screen recording and prevents the content from appearing in the recent apps thumbnail.
Biometric authentication (Face ID, Touch ID, fingerprint) is an excellent addition to your MFA strategy, but it must supplement a traditional credential, not replace it entirely. Use platform biometric APIs (LocalAuthentication on iOS, BiometricPrompt on Android) and store the authentication state securely in the platform keychain or keystore.
Implement data protection for backgrounded apps. On iOS, use the applicationDidEnterBackground lifecycle event to overlay a blur or placeholder view so that PHI is not visible in the app switcher. Enable iOS Data Protection by setting the appropriate file protection attributes. On Android, use FLAG_SECURE and clear sensitive views in onPause.
Testing and Validation
Security testing for HIPAA apps must go beyond standard QA. Conduct annual penetration testing by a qualified third party. Use the OWASP Mobile Application Security Verification Standard (MASVS) as your testing framework — it defines three verification levels, and HIPAA apps should target at least Level 2 (defense in depth).
Run automated vulnerability scanning on every build using tools like Snyk, Checkmarx, or Veracode. Integrate static application security testing (SAST) into your CI/CD pipeline. For mobile-specific analysis, use tools like MobSF (Mobile Security Framework) for automated binary analysis.
Perform regular dependency audits. The average mobile app includes 40 to 80 third-party dependencies, and each one is a potential vulnerability vector. Use npm audit, Dependabot, or Snyk to monitor for known vulnerabilities in your dependency tree.
Conduct a formal risk assessment before launch and annually thereafter. HIPAA's Security Rule explicitly requires a risk analysis that identifies threats to PHI, evaluates current safeguards, determines the likelihood and impact of each threat, and documents the resulting risk level. This is the single most-cited deficiency in OCR enforcement actions.
Ongoing Compliance
HIPAA compliance is not a one-time achievement. It is a continuous operational commitment.
Maintain comprehensive documentation of all security policies, procedures, risk assessments, and BAAs. HIPAA requires you to retain this documentation for six years from the date of creation or the date it was last in effect, whichever is later. Use a version-controlled document management system so that historical policies are preserved.
Implement continuous monitoring of your infrastructure. Set up automated alerts for unauthorized access attempts, configuration changes, and encryption failures. Review audit logs at least monthly. Conduct workforce security training at onboarding and annually — document attendance and comprehension.
Plan for breach response. HIPAA requires notification to affected individuals within 60 days of discovering a breach. Breaches affecting 500 or more individuals must also be reported to OCR and prominent media outlets. Have a documented incident response plan, test it annually with tabletop exercises, and keep your legal and PR teams in the loop.
Building a HIPAA-compliant mobile app demands rigor at every layer — from cloud infrastructure to the pixels on screen. Shortcutting any of these areas exposes your organization to regulatory penalties, civil lawsuits, and reputational damage that far exceeds the cost of doing it right. If you are planning a healthcare mobile app and need a development partner that understands these requirements deeply, we build HIPAA-compliant applications from the ground up.