A HIPAA-compliant cloud provider doesn't make your app compliant. Here's what encryption, BAAs, audit logging, and access controls actually require.
Codestreaks Team
A founder came to us last year with a familiar setup: an app that let patients message their care team, view lab results, and schedule visits. He'd already picked a "HIPAA-compliant" cloud provider and figured the rest was a checkbox exercise for legal to sort out before launch. It isn't. HIPAA doesn't certify apps, and no cloud provider ships compliance by default. What it ships is a set of controls you're allowed to build on top of, and the building part is entirely on you.
This isn't another "what is HIPAA" explainer. If you want the general case for why healthcare apps need to earn trust and how retention works in this space, we've written that piece already. This one is narrower: what a mobile engineering team actually has to implement, in code and infrastructure, to make a HIPAA-compliant mobile app real rather than aspirational.
Protected health information isn't just diagnosis codes and lab values. Under HIPAA, PHI is any information that can identify a patient and relates to their health, treatment, or payment for care. A device ID tied to an appointment reminder is PHI. A push notification payload that includes a patient's first name and "your prescription is ready" is PHI. Crash logs that capture a screen name like MedicationDetailScreen/patient_id=4471 are PHI, sitting in a third-party crash reporting dashboard that nobody on your team thought to audit.
The first engineering task on a compliant build isn't encryption or access control. It's mapping every place PHI enters, moves through, and leaves the system: API payloads, local device storage, push notification content, analytics events, log lines, error reports, and backups. Teams skip this step because it's tedious and doesn't produce a demo-able feature. It's also the step that determines whether every downstream control actually covers what it needs to cover.
TLS 1.2 or higher for everything in transit, AES-256 for data at rest, on the device and in the database. That part is close to table stakes at this point and most teams get it right for the obvious paths: the API, the primary database. Where it breaks down is the paths nobody thinks of as "the database."
Local device storage is the usual gap. iOS and Android both make it easy to cache API responses, session tokens, or offline data in plaintext, in shared preferences or a SQLite file that any app with the right permissions (or a jailbroken device) can read. If your app caches appointment details for offline access, that cache needs the same encryption standard as your production database, not a "we'll get to it" item. Backups are the other one. A nightly database snapshot encrypted at rest is good; a snapshot copied to a developer's laptop for debugging, unencrypted, is a breach that already happened and nobody noticed yet.
This is the single most common misunderstanding we run into, and it's worth stating flatly: AWS, GCP, and Azure will sign a Business Associate Agreement and offer HIPAA-eligible services. That agreement covers their infrastructure. It says nothing about how you configured it.
A misconfigured S3 bucket sitting behind a HIPAA-eligible AWS account is still a misconfigured S3 bucket. An RDS instance with encryption at rest enabled but a security group open to 0.0.0.0/0 is still exposed. The cloud provider's compliance program covers the shared responsibility model's infrastructure half. Access policies, application-level encryption, key management, logging configuration, and everything your code does with the data it receives, that's the other half, and it's yours. We've seen teams treat the BAA with their cloud vendor as the finish line and stop there. It's the entry ticket, not the certificate.
A BAA is a contract that makes a vendor legally accountable for how it handles PHI on your behalf. You need one with anyone who can technically access PHI, not just the ones handling it on purpose. That list is usually longer than teams expect: the cloud provider, the SMS or push notification service, the customer support tool if support agents can see patient messages, the error monitoring service if stack traces include patient data, the analytics platform if events carry any identifiable field.
The order matters. A vendor needs a signed BAA in place before PHI touches their systems, not after you notice it happened. Plenty of popular SDKs, general-purpose analytics and crash reporting tools especially, either won't sign a BAA at all or will only do so on an enterprise tier you're not on. If a vendor won't sign, the answer isn't to use it anyway and hope the data stays generic. The answer is to either configure it so PHI never reaches it, or don't use it in the PHI-adjacent parts of the app.
HIPAA's audit control requirement means your system needs to record who accessed what PHI, when, and what they did with it, in a way that can be reconstructed after the fact. Not "we could probably figure it out from application logs if we had to." An actual, queryable audit trail: user identity, timestamp, the specific record accessed, and the action taken (view, edit, export, delete).
This has to be designed in, not bolted on after a security review flags it. Every endpoint that reads or writes PHI needs an audit event, and that log needs to be tamper-resistant (append-only, ideally separate from your general application logs so a developer debugging an unrelated issue isn't casually scrolling through patient access history). Retention matters too. Six years is the common baseline teams plan around, and logging infrastructure that wasn't designed for that retention window from day one gets expensive and awkward to fix later.
"Only authorized staff can access patient data" is a sentence in a compliance document. Whether it's true depends entirely on what your role-based access control actually enforces in code. Every account, human or service, should have the minimum access it needs and nothing more. A support engineer troubleshooting a billing issue doesn't need read access to clinical notes. A background job that syncs appointment times doesn't need write access to the full patient record.
Multi-factor authentication for any account with PHI access, automatic session timeouts (especially on mobile, where a phone left open on a table is a real access path), and a de-provisioning process that actually revokes access the day someone leaves, not whenever IT gets around to it. None of this is exotic engineering. It's ordinary access control work, done with the assumption that it will be audited, because it will be.
If we had to name the single most common technical failure on HIPAA-adjacent builds, it's this: a team locks down the primary database and API correctly, then drops in a third-party analytics or crash reporting SDK without auditing what it actually captures. These SDKs are built for generic mobile apps. They log screen names, user properties, network request bodies, sometimes full stack traces including local variables, by default, because that's useful for debugging a shopping app.
In a healthcare app, that same default behavior means a crash report can include a patient's name, condition, or medication in a request body that gets shipped straight to a vendor with no BAA in place. This isn't a hypothetical. It's the most repeated pattern in mobile compliance reviews: the core system is fine, and the leak comes from a dependency nobody scoped for PHI exposure specifically. Every third-party SDK in a HIPAA-adjacent app needs its own audit: what does it capture by default, can that be scrubbed or disabled, and does the vendor sign a BAA if any of it could contain PHI.
A pattern we see across compliance-sensitive builds, not just healthcare ones: a team arrives with a demo that impressed everyone in the room and falls apart on real data. The demo passes because it's tested against five clean, hand-picked patient records where every field is populated correctly and the happy path always runs. Production doesn't look like that. A malformed record, an offline sync retry, a support agent's debug session, each is a path the demo never exercised, and each is a path where an audit log entry can silently fail to write or a PHI field can slip into a log line nobody reviewed. Most of the real engineering work on a compliant build isn't the first version that passes review. It's the reliability work that makes the controls hold under the traffic patterns a demo never sees.
Does hosting on AWS or GCP with a signed BAA make my app HIPAA compliant? No. The cloud provider's BAA covers their infrastructure under the shared responsibility model. How you configure access, encryption, and logging on top of that infrastructure is on your team, and it's usually where compliance gaps actually live.
Do we need a Business Associate Agreement with every vendor our app touches? Only with vendors that can access PHI, but that list is often longer than expected: SMS/push providers, customer support tools, error monitoring, and analytics platforms all count if PHI can reach them. Get the BAA signed before PHI touches the system, not after.
What counts as PHI in a mobile app, beyond obvious medical records? Anything that identifies a patient and relates to their health, treatment, or payment. Push notification text, crash log screen names tied to patient IDs, and cached offline data can all qualify even when nobody labeled them "medical data."
How long do we need to keep audit logs for HIPAA? Six years is the common baseline most teams plan around. Audit logging infrastructure that wasn't designed for that retention window from the start tends to get expensive to retrofit.
Is HIPAA compliance a one-time certification we get before launch? No, and there's no official HIPAA certification body to begin with. It's an ongoing set of controls, encryption, access, audit logging, vendor agreements, that has to hold up under real usage and gets reassessed as the app and its vendors change.
If you're scoping a HIPAA-adjacent mobile build, or inheriting one where you're not confident the controls actually hold, that's worth a real conversation before more code gets written on top of it. We've shipped 30+ projects to production since 2024, and every engagement comes with 100% code ownership, which matters more than usual here: if an agency won't hand over the repo on a build that touches patient data, that's a compliance risk with your name on it, not theirs. Free 30-minute scoping call, two business day response either way. See how we approach mobile app development or start a project.
