Compliance

HIPAA & the BAA Process

Updated July 14, 2026

Strategic AI Architects signs a Business Associate Agreement before any client work that touches protected health information begins. Every build for a Medicare, ACA, health, or life insurance agency runs on HIPAA-eligible AWS and Azure services, keeps analytics server-side and consent-gated, and logs every access to client data for six years.

The short version: if your website collects a birthdate, a ZIP code, a medication, or a plan selection, it is handling PHI, and the tracking scripts on that page are the single most common HIPAA exposure we find. This page explains the risk, the law behind it, and exactly how we build and remediate sites so an insurance agency can quote, capture, and follow up without turning every visitor into a liability.

Want us to walk your agency through it? Book a strategy call or call (312) 933-7021 and we will map the process to your book of business. Already have a live site? Start with the free AEO Audit, then bring it up to code with Up to Code.

The risk

Why a tracking pixel is a HIPAA liability on an insurance site

Answer first: a standard Google or Meta pixel dropped on a Medicare or ACA page can send a regulator-defined disclosure of protected health information to an ad platform that never signed a Business Associate Agreement. That is the exposure, and it is where the money and the lawsuits are.

Here is the mechanism. When a visitor lands on a page about a health condition, a coverage type, or an enrollment step, the browser fires a tag that ships their IP address, device identifiers, and often the URL of the health page itself to a third party. The HHS Office for Civil Rights, in its bulletin on the use of online tracking technologies, is explicit that an individually identifiable visit to a health-related page can itself be PHI, even when the person never fills out a form. Combine that identifier with a page about diabetes plans or a subsidy calculator, and you have made a disclosure.

In July 2023 the FTC and HHS went further and sent a joint warning to roughly 130 hospital systems and telehealth providers about the privacy and security risks of online tracking. The pattern is settled: identifiers plus a health context, sent to a vendor without a BAA, is the violation. Insurance agencies selling Medicare, ACA, and health plans sit inside the same exposure, usually without knowing it, because the pixel came bundled with a marketing template years ago.

Do you sign a Business Associate Agreement?

Yes. Strategic AI Architects signs a BAA before any work that creates, receives, maintains, or transmits protected health information (PHI) begins, not after launch. The signed agreement is part of your onboarding paperwork.

Under HHS guidance on business associates, a vendor that handles PHI on behalf of a covered entity is a business associate and must operate under a written BAA. Insurance agencies selling Medicare, ACA, or health products are squarely in that world, so we treat every quote form, plan finder, and lead record as PHI from the first day of a Digital Foundation build. Subcontractors that touch the same data sign downstream BAAs before they get access. The chain matters: a BAA with us that leaks through an unsigned analytics vendor is still a gap, which is why we account for every service in the data path, not just our own servers.

Which HIPAA-eligible AWS and Azure services do you use?

Only services covered by our signed cloud BAAs. On AWS that means HIPAA-eligible services such as EC2, S3, RDS, Lambda, and CloudFront under the AWS Business Associate Addendum. On Azure it means services inside Microsoft's HIPAA and BAA scope, such as App Service, Azure SQL Database, and Blob Storage.

PHI is never routed through a service outside that eligibility list. Data is encrypted at rest with AES-256 and in transit with TLS 1.2 or newer, storage buckets holding lead data are private by default, and access keys are scoped to the minimum each worker needs. When a client already has a cloud account, we verify their BAA with the provider is executed before any health data lands in it. Encryption and access scoping are also what turn a lost laptop or a misconfigured bucket from a reportable breach into a non-event, which is the practical reason the safeguards are not optional.

How is tracking kept server-side?

Answer first: no client-side GA4, Google Tag Manager, or Meta Pixel fires on pages tied to health conditions, coverage, or enrollment. Analytics run server-side, behind a consent gate, with identifiers stripped or truncated before any event leaves the site.

The distinction that decides everything is where the tag runs. A client-side pixel executes in the visitor's browser and reports straight to the ad platform, so you never control what leaves. Server-side, first-party collection reverses that: the event hits our server first, we decide what is allowed to continue, and only a scrubbed, consented signal is forwarded. Concretely, on every SAA build:

• 01
  Consent before measurement

  Nothing is tracked until the visitor consents, so a health-page visit is never silently logged to a third party.
• 02
  IP truncation

  IP addresses are truncated or dropped, breaking the identifier-plus-health-context link that HHS defines as PHI.
• 03
  No form content in payloads

  Names, birthdates, medications, and plan selections never ride along in an analytics or conversion payload.
• 04
  Server-posted conversions

  Conversions post from our servers on a first-party basis, so you keep measurement without the browser-side leak.

This is precisely the exposure OCR describes in its online tracking bulletin, where an IP address or device identifier combined with a visit to a health-related page can itself be PHI. Not sure what your current site is firing? Run the free audit and it will flag every client-side pixel on your Medicare and ACA pages.

Remediation

What if my site is already leaking? Up to Code

If the audit finds client-side pixels, a thin privacy policy, or forms posting to unsigned vendors, the fix is Up to Code, our HIPAA website remediation service at $5,997 plus $197 per month. It is the repair path for agencies that already have a live site rather than a fresh build.

Remediation moves your existing site to server-side, consent-gated tracking, rewrites the privacy policy to reflect what is actually collected and shared, replaces or reconfigures any form or chat tool that transmits health data without a BAA, and hardens hosting onto HIPAA-eligible infrastructure. You keep your domain, your content, and your rankings. What changes is the plumbing underneath, so the same pages that convert today stop creating the disclosure that regulators are penalizing. Building new instead? A Digital Foundation site ships compliant from day one, starting at $497 per month, or $997 per month for Digital Foundation Plus.

What audit trails exist?

Every build ships with three logs: access logs (who viewed or exported lead data, and when), change logs (every deployment and configuration change, tied to a person), and data-flow logs (where each lead record traveled, from form to CRM to carrier hand-off). All three are retained for six years, matching HIPAA's documentation retention requirement.

Logs are reviewed on a set schedule, anomalies trigger alerts rather than waiting for a quarterly report, and clients can request their log history at any time. This is the evidence layer that matters when a client, a carrier, or a regulator asks a simple question: who touched this record, and where did it go? Without those three logs, the honest answer is usually a shrug, and a shrug is what turns an inquiry into a finding. Agencies on our Enterprise tier get expanded logging with scheduled compliance reports and a named point of contact for security reviews and incident response.

HIPAA questions agencies ask us