Is Braze HIPAA Compliant? Engagement Platform Risks

Yes, Braze can be used HIPAA compliantly, but only inside a narrow lane that most engagement teams will drift out of without noticing. Braze publishes a HIPAA Business Associate Addendum, operates a dedicated HIPAA cluster, and permits protected health information for engagement, retention, CRM, and marketing purposes only. It explicitly forbids storing medical records or images and forbids sending messages containing diagnoses or test results. Curve is the HIPAA-compliant tracking and attribution layer that keeps the advertising side of that program clean, with a signed BAA on every plan.

The direct answer, in more detail

Braze is unusual among engagement platforms in that it did the work. Braze states that its HIPAA cluster complies with the Security and Privacy rules of HIPAA as applicable, that it engaged legal counsel specializing in HIPAA to run a risk analysis of the environment, and that it reviewed each safeguard against those rules. It publishes a Business Associate Addendum that becomes part of the Master Subscription Agreement.

Protected health information passed to Braze is stored on a separate database cluster rather than mixed into the general environment. That separation is the operational core of the arrangement, and it means the instance your account sits on is a compliance-relevant fact rather than an infrastructure detail. Confirm your placement with Braze rather than assuming it.

So the honest verdict is conditional and it has two conditions. First, you have to actually execute the addendum and be provisioned correctly. Second, and more demanding, you have to stay inside what the addendum permits. That second condition is where healthcare teams fail, because Braze is a powerful platform and the boundary is drawn in a place that cuts across normal engagement practice.

What the Braze BAA actually covers

Braze permits PHI submission for engagement, retention, customer relationship management, and marketing purposes. Within that scope it takes on the usual business associate obligations: use and disclose PHI only as the addendum permits, safeguard it, and handle it consistently with what you could lawfully do yourself.

Then it draws two hard lines, and both are worth quoting closely.

• No medical records or medical images. Braze states that the customer shall not store or submit medical records or medical images to the Braze Services. This rules out the pattern of syncing an EHR extract into user profiles so that campaigns can be personalized against clinical history.
• No diagnoses or test results in messages. Braze states that the customer shall not send any messages through the Braze Services containing diagnoses, test results, or similar sensitive medical information, and disclaims liability for HIPAA violations arising from customers doing so anyway.

That disclaimer matters more than it looks. It tells you exactly where the risk lands if a campaign goes out with clinical content in it. The vendor has documented the prohibition and allocated the consequence to you.

The practical reading is that Braze will hold the fact that a person is your patient, and will hold engagement data about them, under a BAA. It will not be your clinical messaging system, and it will not be a shadow EHR.

Where Braze is genuinely fine

Inside its lane Braze is a strong fit for healthcare, and the lane is wider than a cautious reading suggests.

Onboarding sequences for a new patient. Reactivation campaigns for people who have not booked in a year. Appointment confirmation flows that carry a time and a link rather than a reason for the visit. Adherence and check-in nudges that reference a program generically. Cross-channel orchestration across push, in-app, email, and SMS for a digital health app. All of that is engagement, all of it can involve PHI in the sense of identity plus patient status, and all of it stays inside the addendum.

The discipline is in message content and profile content, not in whether the person is a patient. Being a patient of a named practice is itself PHI. Braze's BAA is designed to accommodate exactly that, which is what separates it from platforms that refuse health data outright.

The scope trap: attributes, segments, and data exports

Braze's strength is that it can hold rich per-user attributes and segment on anything. That is also the mechanism by which teams exceed the addendum.

Three specific patterns to watch:

• Clinical attributes on the user profile. Someone maps diagnosis codes, medication names, lab flags, or eligibility decisions into custom attributes so campaigns can branch on them. Individually each mapping solves a real personalization problem. Together they reconstruct a medical record inside a system whose BAA says medical records must not be stored there.
• Segment names that carry clinical meaning. A segment called after a specific treatment is a clinical statement about every user in it, and segment membership travels into exports, reports, and audience syncs where the name is the only context anyone sees.
• Event and data streaming to downstream tools. Braze can stream engagement data out to warehouses and partner systems. Every destination in that stream is a separate vendor question, and the BAA you hold with Braze does not follow the data to a third party you connected yourself.

There is also an AI dimension now. Generative and agentic features across engagement platforms are governed by their own terms, and coverage often depends on which cluster and which feature set you are on. Treat every newly enabled AI capability as a question for your account team, not as an inherited permission.

The architecture that works

The pattern that holds up over time keeps clinical meaning out of the engagement platform while keeping enough signal to run good campaigns.

• Send state, not content. Instead of syncing a diagnosis, sync a neutral flag that a workflow can branch on. The clinical system knows what "program B, week 3" means. Braze does not need to.
• Link out rather than tell. Anything clinical goes behind authentication. The message carries a reason to log in, not the information itself. This is the correct approach on every channel, and it satisfies both the Braze prohibition and the plain reality that push notifications and SMS render on locked screens.
• Name everything neutrally. Segments, canvases, campaigns, and custom events. A neutral naming convention costs nothing and removes clinical meaning from every artifact that leaves the platform.
• Audit the outbound connections separately. Every warehouse sync, partner integration, and audience destination is its own contractual analysis.

The failure mode is convenience creep. Nobody decides to build a clinical database in a marketing tool. It accumulates one useful attribute at a time.

Where the ad tracking problem shows up

Engagement platforms sit next to advertising platforms, and the connection between them is where a well-run Braze implementation still leaks.

Two paths matter. The first is audience sync. Braze audiences pushed to Meta or Google for retargeting and lookalike modeling carry their meaning with them. Meta and Google do not sign BAAs for their advertising products, so an audience whose membership implies a health condition is a disclosure to a vendor with no agreement in place. Your Braze BAA does not extend to the destination.

The second is the website itself. Braze's web SDK and your ad pixels both observe the same pages. If the site runs a standard Meta Pixel or a raw Google tag, condition-revealing page URLs and a persistent browser identifier are already going to those platforms independent of anything Braze does. That is the mechanism behind healthcare pixel litigation that has cumulatively crossed $100 million in settlements, with Advocate Aurora settling at roughly $12.225 million. The plaintiffs' theory does not require a diagnosis to have been transmitted. It requires that an identifiable person's health interest was disclosed to a third party.

A healthcare team can therefore do everything right inside Braze and still have the exposure sitting in its tag manager. We walk through that collection layer in detail in our piece on why client-side pixels create HIPAA exposure and what server-side tracking changes.

How Curve handles the advertising side of a Braze program

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare. It does not replace Braze. It takes the layer Braze's BAA does not reach, which is everything that leaves for an ad platform.

The Curve tracking script installs on your site in place of the Meta Pixel and Google tag. Events go to Curve's US-hosted infrastructure rather than straight to the ad platforms. From there:

• Per-destination field mapping controls what forwards. Only fields you explicitly map reach a given destination, configured separately for each one. Page URLs, form values, and service-line detail stay behind unless you deliberately map them. The default is that nothing goes.
• Identifiers are hashed. Email, phone, and name are SHA-256 hashed to each platform's conversion API requirements before forwarding.
• Neutral event aliases replace descriptive names. The ad platform sees a generic conversion signal rather than a name that discloses the program or treatment, which is the same naming discipline that keeps Braze segments clean.
• PHI-pattern detection monitors payloads. Curve flags PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences. It is a monitoring layer that tells you when an upstream change started sending something new. The protection itself is the field mapping plus the hashing.
• Bridge tokens preserve attribution across handoffs. When a user clicks out to a separate booking or intake tool, attribution normally breaks at the moment it becomes valuable. Bridge tokens carry it across.
• Offline conversion uploads close the loop. Bulk CRM or EHR outcomes match back to the original ad click by click ID, so revenue reporting never requires exporting a patient list to an ad platform.

Clean conversions forward server-side to Meta CAPI, Google Ads Enhanced Conversions, TikTok Events API, Microsoft, and LinkedIn. Because the path is server-side, ad blockers and browser tracking prevention stop suppressing it, which usually raises measured conversion volume. Every Curve plan includes a signed BAA. For the mechanics of the server-side path itself, see our Meta Conversions API implementation architecture for healthcare.

What to check in your own Braze implementation

1. Confirm the addendum is executed and your instance is provisioned for PHI. Get the cluster placement in writing from your account team.
2. Export the full custom attribute list and read it as a clinician would. Anything that names a condition, medication, or result is outside the addendum's scope.
3. Review every segment and canvas name. Rename anything whose label alone discloses clinical meaning.
4. Read the message library for diagnoses and results. The prohibition is on content, and campaigns written a year ago do not audit themselves.
5. List every outbound data connection and ask, for each destination, whether that vendor has signed a BAA with you.
6. Check every audience sync to an ad platform and ask what the membership implies about the people in it.
7. Inspect what your website sends to ad domains during a test visit. Our free compliance scanner does the first pass automatically.

Frequently asked questions

Does Braze sign a BAA?

Yes. Braze publishes a HIPAA Business Associate Addendum that forms part of the Master Subscription Agreement, and it permits PHI for engagement, retention, CRM, and marketing purposes. Confirm execution and instance placement with your account team, since the addendum is periodically revised.

Can I send appointment reminders through Braze?

Generally yes, if the message carries a time, a location, and a link without disclosing the reason for the visit. A reminder that names the procedure or the clinical service crosses into the content the addendum prohibits.

Can I store lab results or diagnosis codes as user attributes?

No. Braze states that customers must not store or submit medical records or medical images, and prohibits messages containing diagnoses or test results. Keep those in your clinical system and pass Braze a neutral flag instead.

Does the Braze BAA cover data I stream to other tools?

No. Your agreement with Braze governs Braze. Once data reaches a warehouse, a partner integration, or an ad platform, the terms of that destination apply, and most advertising destinations do not offer a BAA at all.

Do Braze AI features fall under the same coverage?

Not automatically. Coverage for AI capabilities depends on the specific feature and the cluster your workspace runs on. Treat each newly enabled AI feature as a question to put to Braze in writing before PHI flows through it.

If Braze is covered, why do I still need a separate tracking layer?

Because the exposure most healthcare advertisers carry is not in the engagement platform. It is in the pixels on the website and the audiences pushed to ad platforms, neither of which any Braze agreement reaches.

Where to start

Braze is one of the engagement platforms that will genuinely sign for PHI, which makes it a reasonable choice for healthcare. The work is staying inside the lane: neutral attributes, neutral segment names, no medical records, no diagnoses or results in message bodies, and a fresh contractual analysis for every downstream destination you connect.

The part no engagement platform covers is advertising. Curve replaces the client-side pixels with server-side collection, per-destination field mapping, hashed identifiers, neutral event aliases, and bridge-token attribution, so Meta and Google receive conversion signal without receiving health signal. A signed BAA is included on every plan. Run the free compliance scanner against your site to see what is leaving right now, or visit curvecompliance.com to walk through the architecture.

Reviewed August 2026. Vendor BAA policies change. Confirm current terms with the vendor.