← Writing
Vendor Evaluation22 Jul 2026 · 5 min read

HIPAA Vendor Checklist for Analytics and Monitoring

A BAA review starts with the actual telemetry flow, purchased service, enabled features, and operating model.

Direct answer: A BAA does not by itself approve an analytics or monitoring vendor for PHI. First map whether PHI can reach the vendor, verify the exact covered service and features, then configure fields, integrations, access, retention, and incident handling around that approved data flow.

Analytics and monitoring vendors often present security certifications, healthcare customers, encryption, and a statement that a BAA is available. Those signals help create a shortlist. They do not establish that the product configuration being purchased can receive the data the application will send.

HHS says a cloud provider that creates, receives, maintains, or transmits ePHI on behalf of a covered entity or business associate is itself a business associate, even when it stores encrypted ePHI without the key. The parties need an appropriate BAA, and the regulated organization still needs its own risk analysis and safeguards.

Sources reviewed: HHS cloud-computing guidance, HHS sample BAA provisions, and HHS tracking technology guidance.

Scope: This checklist helps engineering, product, security, privacy, procurement, and legal teams ask the same questions. It is not legal advice or a compliance certification.
Gate 1

Determine whether PHI reaches the vendor

Do not begin with the contract. Begin with a data-flow diagram. Include the SDK, collection endpoint, storage, dashboards, alerts, exports, integrations, support access, subprocessors, backups, and AI features.

Inventory both intentional fields and ambient data:

  • User, account, patient, member, appointment, encounter, and device identifiers
  • URLs, titles, referrers, query strings, search terms, and campaign parameters
  • Errors, stack traces, request bodies, logs, breadcrumbs, and local variables
  • Events, properties, user profiles, cohorts, session replay, heatmaps, and recordings
  • Clinical content, free text, documents, prompts, model responses, and support artifacts
  • IP addresses, location, timestamps, installation IDs, and other linkable metadata

If PHI cannot reach the vendor because the architecture enforces a validated no-PHI schema, document and test that boundary. If PHI can reach it, proceed as a business-associate use case unless the responsible legal and privacy teams determine otherwise.

Gate 2

Verify the exact BAA scope

Ask the vendor to identify the legal entity that signs the BAA and the plans, products, regions, APIs, and features it covers. Confirm whether the BAA must be executed through sales, an enterprise order form, an online addendum, or another process before data collection begins.

AreaQuestionEvidence
CustomerIs the correct covered entity or business associate named?Executed agreement and order form
ServiceIs the exact analytics or monitoring product covered?Covered-services schedule
FeaturesAre replay, logs, profiling, AI, support, exports, and integrations included?Feature-specific terms or written confirmation
RegionDoes scope change by hosting or processing location?Data-location and transfer terms
SubprocessorsDo equivalent restrictions flow down?Subprocessor list and BAA language
TimingWhen does coverage begin?Effective date before first PHI event
Gate 3

Review permitted uses and secondary use

HHS sample BAA provisions require the agreement to establish permitted and required uses and disclosures, prohibit incompatible further use, require safeguards, address incidents, flow restrictions to subcontractors, and provide for return or destruction at termination.

For analytics and monitoring, ask whether customer data is used for product improvement, benchmarking, advertising, model training, abuse detection, human support, or aggregated insights. Identify defaults and opt-ins. Contract terms, product settings, and actual technical behavior must agree.

Gate 4

Assess technical controls

Collection

Field allowlists, SDK hooks, tag controls, IP handling, request filtering, replay masking, payload limits, and opt-in collection.

Access

SSO, MFA, role-based access, project isolation, support access, service accounts, exports, and administrative audit logs.

Protection

Encryption, key management, tenant isolation, region controls, backups, secure development, vulnerability management, and testing.

Operations

Retention, deletion, incident response, breach notice, availability, recovery, evidence preservation, and termination assistance.

Certifications and reports can support the assessment, but controls still need to map to the product's own risks. A SOC 2 report does not decide whether a raw patient form should be attached to an error.

Gate 5

Inspect integrations and exports

Every destination is another disclosure. List chat alerts, email, issue trackers, source-control integrations, data warehouses, reverse ETL, advertising platforms, messaging tools, experimentation systems, notebooks, downloaded CSV files, and AI assistants.

For each destination, record:

  • Fields transferred and purpose
  • Whether PHI is possible
  • Vendor and agreement status
  • Access roles and auditability
  • Retention, deletion, region, and subprocessors
  • Owner and approval date

Disable integrations by default. Enable them after review, not simply because the vendor offers a button.

Gate 6

Plan for mistakes and change

Assume an unsafe event will eventually pass a filter. The operating plan should explain how to stop collection, identify affected records, restrict access, delete data from active systems and backups where applicable, preserve evidence, notify the vendor, assess whether an incident or breach occurred, and document corrective action.

Also monitor vendor change. New SDK defaults, AI features, integrations, subprocessors, terms, regions, and retention behavior can change an approved data flow. Assign an owner and review material changes before adoption.

Decision record

Do not approve with unresolved gates

DecisionMeaning
Approved for PHIExecuted BAA and reviewed service scope, data flow, controls, integrations, and operating plan
Approved without PHIArchitecture enforces and tests a no-PHI schema; vendor receives no PHI
Pilot onlySynthetic data in an isolated environment while contract or controls remain incomplete
RejectedRequired agreement, control, transparency, or operating capability is unavailable

Record the decision, assumptions, evidence, owners, approved features, prohibited uses, review date, and triggers for reassessment. A vendor approval should be specific enough that an engineer can tell whether a proposed feature falls inside it.

Related reading

Apply the checklist

Responding to Suspected PHI Exposure

Use the vendor incident channel, preserve records, scope downstream access, and keep notification decisions with authorized owners.

Amazon Macie for HIPAA

Use sensitive-data discovery to find possible PHI in S3 and route findings into a controlled response process.

Sentry vs Crashlytics

Compare monitoring contracts, data collection, and practical deployment boundaries.

Mixpanel vs Google Analytics

Compare healthcare product analytics and public-site measurement.

Configure Sentry Without PHI

Turn the vendor decision into SDK, scrubbing, replay, access, and testing controls.

Analytics Events Without PHI

Design a controlled event taxonomy and validation pipeline.

Official references: HHS cloud-computing guidance, HHS sample BAA provisions, and HHS tracking technology guidance.

Need a vendor and BAA stack review?

I can help map the telemetry path, separate BAA coverage from product configuration, and turn vendor decisions into engineering controls.

Start a project inquiry

Please do not send patient information, PHI, credentials, or private system details by email.