What HIPAA Compliance Actually Requires for a Mobile App in 2026

If you are building a mobile app that handles health data, you have probably heard the phrase "HIPAA compliant" used loosely enough to be useless. Marketing pages say "we make you HIPAA compliant." Developer forums say "just encrypt everything." Compliance officers say "we need an audit." All three are talking past each other.

This post is the operating manual we wish more healthcare mobile teams started with. It is not legal advice. But after five years of healthcare engagements across ABA therapy, e-prescribing, and EHR work, the patterns repeat. Here is what HIPAA actually requires of a mobile app, what it does not require, and where the technical work actually lives.

The legal structure most teams skip

HIPAA is three rules, not one. Understanding which rule applies to your app changes everything.

The Privacy Rule governs who can access protected health information (PHI), under what conditions, and for what purposes. It is the rule that prevents a clinic from sharing your therapy notes with your employer without your consent. For mobile apps, the Privacy Rule shows up as user consent flows, disclosure tracking, and patient-rights features (the right to access your own records, the right to correct errors, the right to know who has accessed your data).

The Security Rule governs how electronic PHI (ePHI) must be protected technically. This is the rule mobile developers spend most of their time on. It splits into three safeguard categories: administrative (policies and workforce training), physical (where servers and devices live), and technical (encryption, access controls, audit logs, transmission security). Most mobile app HIPAA work happens in the technical safeguards.

The Breach Notification Rule governs what happens when something goes wrong. If PHI is exposed in a way that wasn't authorized, the covered entity has to notify affected individuals, the Department of Health and Human Services, and in some cases the media. For mobile apps, this shows up in incident response planning, logging that lets you reconstruct what happened, and BAAs that make your subcontractors' obligations explicit.

Three rules. Most mobile teams talk like there is only one.

Covered entity vs. Business Associate (and where your app actually sits)

HIPAA's compliance burden falls on two categories of organization: covered entities and business associates.

A covered entity is a healthcare provider that transmits PHI electronically, a health plan, or a healthcare clearinghouse. If you run a therapy practice that bills insurance, you are a covered entity. If you operate a hospital, a clinic, a dental practice, a pharmacy, an insurance company, or an HMO, you are a covered entity. The compliance program lives here.

A business associate is a person or organization that performs a function on behalf of a covered entity that involves access to PHI. If you are a mobile app developer building software for a therapy practice, and that software processes PHI, you are a business associate. The covered entity is responsible for the overall program; you are responsible for the technical implementation and your own internal practices.

This matters for one critical reason: the development agency that builds your app does not "make you HIPAA compliant." Compliance is a property of the covered entity's overall program. The agency builds infrastructure that supports the compliance program. Your covered entity remains responsible for the legal designation and the regulatory relationship with HHS.

If you see an agency marketing page that says "we make you HIPAA compliant," that is either a marketing simplification or a misunderstanding of how HIPAA actually works. The honest version: "We build mobile infrastructure that supports your HIPAA program through encryption, audit logs, role-based access, BAA coverage, and secure data handling. Your compliance officer retains the program responsibility."

The Business Associate Agreement (BAA)

The BAA is a written contract between a covered entity and a business associate. Under HIPAA, a covered entity may not disclose PHI to a business associate without one. So if a development agency is going to touch your PHI, you need a BAA signed before any PHI access. Not during the engagement. Before.

A real BAA covers:

• What PHI the business associate will access
• How the PHI may be used (and not used)
• Safeguards the business associate must apply
• Requirements to report breaches and unauthorized disclosures
• Termination provisions (what happens to PHI when the contract ends)
• Subcontractor obligations (the business associate's subcontractors also need to be bound)

In practice, a well-structured healthcare mobile engagement signs the BAA before kickoff, identifies every third-party SDK in the build, confirms which of those will sign their own BAAs, and documents the chain.

The subcontractor obligation is the part most mobile teams miss. If your app uses Crashlytics, Sentry, OneSignal, Mixpanel, Amplitude, or any other third-party SDK that touches PHI, that SDK provider is a subcontractor business associate and needs to sign a BAA with the agency (or directly with you). Many popular mobile SDKs do not sign BAAs by default. Some have a "HIPAA-eligible" tier that costs more. Some refuse to sign BAAs at all. The list is dynamic and the audit catches it.

Technical safeguards: what the Security Rule actually requires

The Security Rule's technical safeguards are where the engineering work lives. Here is what they actually require, translated from the regulatory language into the mobile context.

Access controls

Each user accessing PHI in your app needs a unique identifier (no shared logins). The app needs to enforce automatic logoff after a period of inactivity. PHI access needs to be controlled by role — not every user sees every piece of PHI. And the access controls need to enforce at the API layer, not just hide things in the UI.

The most common failure mode we see: role-based access enforced in the mobile UI (a button is hidden if you don't have the role) but the API endpoint behind that button returns everything when called directly. Real role-based access enforces on the server.

Audit controls

The app needs to record, examine, and report on activity in information systems that contain ePHI. In practice: every access to PHI gets logged with the user, the timestamp, the resource accessed, and the action. The logs need to be tamper-resistant (you cannot let a user delete their own audit trail). The logs need to be reviewable by the compliance officer.

The common failure mode: logging to a generic analytics SDK that hasn't signed a BAA and treats events as marketing data. Audit logs for PHI access need to live in BAA-signed infrastructure.

Integrity

PHI must not be improperly altered or destroyed. In a mobile app, this means: data transmission integrity (TLS for everything, certificate pinning where the threat model requires it), version control on PHI records, and the ability to detect when data has been corrupted.

Transmission security

PHI in transit must be encrypted. TLS 1.2 minimum, TLS 1.3 preferred. Certificate pinning is recommended for high-sensitivity deployments. PHI in messages, push notifications, and inter-service calls all count.

Encryption (addressable, but treat as required)

The Security Rule technically lists encryption as "addressable," not "required," which means a covered entity can choose to implement it or document why not. In practice, the alternative documentation requires showing why encryption would not be reasonable and appropriate, and that documentation is hard to write defensibly. Treat encryption as required.

For mobile apps specifically:

• In transit: TLS 1.2+. Certificate pinning where the threat model justifies it.
• At rest on device: Keychain on iOS for credentials and small PHI. SQLCipher or similar for any local SQLite database holding PHI. iOS Data Protection at the file level for any cached files containing PHI.
• At rest on server: Whatever your cloud provider offers, configured correctly. AWS RDS encryption, GCP CMEK, Azure Storage encryption.

Mobile-specific gotchas most teams miss

The HIPAA rules are stack-agnostic. The mobile context creates specific vulnerabilities that desktop apps don't have.

Screenshots and screen recording

Both iOS and Android let users screenshot and screen-record the app by default. If a clinician screenshots a screen showing PHI and posts it to a team chat that hasn't signed a BAA, that's an unauthorized disclosure. The app needs to detect screenshots on iOS (via UIApplicationUserDidTakeScreenshotNotification) and disable screen recording on Android (via FLAG_SECURE on the window).

Most mobile apps don't enable these controls. Most healthcare mobile apps should.

Clipboard

The system clipboard is a side channel that survives across apps. If a user copies PHI from your app, it lives in the clipboard until another app overwrites it. Other apps can read the clipboard. iOS 14+ shows a notification when an app reads the clipboard, which can surface privacy issues. Best practice for healthcare mobile: prevent copying of PHI fields where possible, and clear the clipboard when the app backgrounds.

App backgrounding

When a mobile app backgrounds, iOS captures a snapshot of the current screen for the multitasking switcher. That snapshot can contain PHI. The app should obscure or replace the snapshot when backgrounding (typically by overlaying a privacy view in applicationDidEnterBackground).

Push notifications

Push notifications can deliver PHI to the lock screen, which is visible without authentication. If a push notification says "Dr. Smith reviewed your bipolar disorder treatment plan," that's a disclosure to whoever can see the lock screen. Best practice: keep push notifications generic ("You have a new clinical update"), with the PHI behind authenticated access in the app.

Exports and sharing

PHI can leak through email exports, AirDrop, share sheets, save-to-files, and printing. Each of these is a potential disclosure path. The app should track and gate every export action with explicit consent flows.

Backups

iCloud Backup and Google Drive backup by default include app data. If your app stores PHI locally and doesn't explicitly exclude itself from backup, that PHI ends up in iCloud (or Google Drive). The app needs to mark sensitive data as "do not back up" via URLResourceKey.isExcludedFromBackupKey on iOS and equivalent controls on Android.

Third-party SDKs and the BAA chain

The single most common HIPAA gap we surface in audits is uncovered third-party SDKs. The pattern: the agency signs a BAA, but the app uses three or four SDKs that haven't signed BAAs of their own.

Which SDKs typically need attention:

• Crash reporting (Crashlytics, Sentry, Bugsnag) — crash reports can include user state and PHI in some configurations
• Analytics (Mixpanel, Amplitude, Google Analytics for Firebase) — event properties can include PHI
• Push notifications (OneSignal, Pushwoosh) — notification payloads can include PHI
• Payment (Stripe, Braintree) — payment metadata can include diagnosis codes
• Chat / support (Intercom, Zendesk) — message bodies can include PHI

Which sign BAAs (as of 2026, verify directly with each vendor before relying on this):

• Crashlytics: not at the Spark / free tier; available at enterprise tiers
• Sentry: yes, with an enterprise contract
• Mixpanel: yes, at the appropriate plan level
• AWS, Azure, Google Cloud: yes, all three at the infrastructure level
• Twilio: yes, on certain product lines
• Stripe: yes (treating payment metadata carefully is still your responsibility)

Always verify directly with the SDK vendor at the time of the audit. The list changes.

PHI for minors and special populations

Some HIPAA rules apply differently to minors. The covered entity's policies and state law both factor in. ABA therapy data on minors is a common example we work with: the data is PHI when handled in a clinical context by a covered entity. Parental access to that data is governed by state law and the covered entity's policy.

For psychotherapy notes (a special HIPAA category), additional protections apply. The Privacy Rule treats psychotherapy notes more restrictively than other PHI, and most authorizations to disclose PHI specifically exclude psychotherapy notes unless the patient explicitly authorizes their release.

If your app handles psychotherapy notes or minor PHI specifically, your covered entity should have a written policy and the app should enforce it. The audit identifies what's in scope.

What HIPAA does NOT require

Some commonly-cited HIPAA requirements aren't actually in the rules:

• HIPAA does not require a specific encryption algorithm. It requires encryption that meets NIST standards. AES-256 is fine; so are other modern algorithms.
• HIPAA does not require multi-factor authentication. Unique user identification is required; MFA is best practice but not mandated by the rules themselves.
• HIPAA does not have a "HIPAA certification." There is no government-issued HIPAA certificate. Third-party attestations exist (HITRUST, SOC 2 Type II) but they are not HIPAA certifications.
• HIPAA does not mandate cloud vs. on-premise. Both are fine if the safeguards are implemented properly. AWS, Azure, and Google Cloud all sign BAAs and have HIPAA-eligible service tiers.
• HIPAA does not require US-only data storage. Some state laws and contractual obligations may require it, but HIPAA itself does not.
• HIPAA does not specify retention periods. The covered entity's policies and state laws set retention requirements.

Pruning these false requirements out of the project scope often saves real engineering time.

Audit-first vs build-first thinking

The most expensive HIPAA mistakes happen when teams build first and audit later. Audit-first thinking flips the order: before any code, an audit identifies what PHI the app handles, what the covered entity's compliance program requires, what third-party services will need BAAs, and what the technical safeguards look like in this specific architecture.

The audit produces a written report your compliance officer can read. The build then implements against that report. The handoff documentation traces every architectural decision back to the audit findings, so when the covered entity goes through a HIPAA risk assessment (which they should be doing periodically anyway), the mobile app's contribution to the program is documented.

This is the methodology we use on every healthcare engagement. It is not because we want to sell more audits; it is because building first and auditing later is how engagements stretch from 6 months to 18 months and budgets double. The audit step is cheap insurance against expensive retrofits.

Practical takeaways

If you read nothing else: HIPAA-aware mobile development is not magic, and it is not unattainable. It is a specific set of technical controls applied consistently across the app and its supporting infrastructure. The hard part is not the engineering. The hard part is the discipline: actually identifying every third-party SDK that touches PHI, actually enforcing role-based access at the API layer, actually logging every PHI access, actually configuring iOS and Android privacy controls.

The covered entity carries the compliance program. The mobile app carries the technical implementation. The agency carries the BAA and the documentation. Each role is real and each role has its own responsibilities. The team that confuses these roles is the team that ends up rebuilding the app two years in.