HHS guidance on tracking technologies explains how websites and apps may disclose protected health information through analytics, advertising, and similar tools. Covered entities and business associates should review pixels, tags, and scripts, limit data shared with third parties, and update notices and access controls. The main risk is sending health-related page, form, or search data to outside services.
What HHS means by tracking technologies on health websites
HHS is treating tracking technologies as a privacy and disclosure problem, not just a web analytics problem. The practical issue is whether a pixel, tag, script, SDK, or similar tool can cause protected health information to leave the site or app when a person visits a page, completes a form, or uses search or appointment features. That makes the inventory of trackers and the data they can observe the first thing to understand.
The guidance matters because the same tool can behave very differently depending on where it is placed and what data it sees. A tracker on a generic marketing page is not the same as one embedded on a symptom checker, patient portal, or prescription refill flow. The relevant question is not whether the organisation intended to share health data, but whether the technology can transmit page content, identifiers, or user behaviour that reveals a health condition or care interest.
What organisations should examine and control
Start by identifying every tracker in the site and app stack, including third-party pixels, tag managers, embedded widgets, chat tools, analytics SDKs, and advertising scripts. Then map each one to the pages, events, and fields it can see. If a tool can observe form entries, search terms, URL parameters, or page metadata that reveal health information, treat it as part of the privacy boundary and not as a harmless marketing add-on.
From there, the control focus is data minimisation and vendor discipline. Limit what is sent to outside services, review whether the tool is necessary at all, and make sure disclosures in notices match actual data flows. If access controls or consent flows exist, they should reduce exposure before data leaves the environment, not merely document it after the fact. NIST Privacy Framework is useful here because it frames the discipline as governing collection, use, and disclosure rather than only securing the website perimeter.
Why tracking technologies create a disclosure and governance problem
These tools are risky because they can silently move sensitive information into a third party’s environment where the covered entity or business associate no longer controls downstream use. That creates exposure even when the website itself looks routine. The danger is highest when trackers are embedded in pages that reveal treatment interest, diagnoses, medication questions, appointment details, or insurance-related interactions.
HHS guidance is also operationally relevant because it forces organisations to distinguish between internal measurement and external sharing. Basic logging or first-party measurement may be manageable, but ad-tech style collection can create a much wider disclosure path. A useful governance reference point is EU General Data Protection Regulation (GDPR), especially the principles around data minimisation and privacy by design, because they reinforce the same design discipline even though the legal regime is different.
Risk and Threat Considerations
Tracking technologies can expose health-related browsing, form, and search activity to third parties that were never intended to receive it. The risk is not only privacy loss, it is also uncontrolled redistribution of sensitive data through ad-tech, analytics, and embedded service providers.
Failure mechanism: A script or pixel loads on a sensitive page, captures identifiers or page content, and transmits them to an external endpoint before the organisation has a chance to filter or suppress the data.
Impact: The organisation can create an unapproved disclosure of protected health information, lose visibility into downstream use, and increase legal, contractual, and reputational exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-8 — Spam Protection and Input Validation | Supports controlling browser-exposed data paths and malicious script delivery risks. |
| Recommendation — Restrict and validate third-party script sources before they can collect or transmit sensitive data. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Applies because tracking tools can disclose sensitive data beyond intended protection boundaries. |
| Recommendation — Protect sensitive data flows so trackers cannot export more than intended. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Relevant because HHS tracking guidance centers on preventing improper disclosure of health-related data. |
| Recommendation — Document and enforce privacy requirements for third-party tracking on sensitive pages. | ||
| GDPR | Article 5 — Principles relating to processing of personal data | Directly aligns with minimisation and controlled disclosure concerns raised by tracker use. |
| Recommendation — Minimise personal data sent through analytics and advertising tools. | ||
| OWASP ASVS | V14 — Data Protection | Relevant where web and app integrations expose sensitive user data to external services. |
| Recommendation — Design web flows so sensitive fields are not exposed to third-party scripts. | ||
Practitioner Guidance
What to verify: Confirm which trackers run on patient-facing, member-facing, and intake flows, then verify what data each one can observe at the browser or app layer. A tracker is materially different if it can see free-text fields, query parameters, or page paths that imply health status.
Decision rule: If a tracker can receive sensitive page context or user-entered data, treat it as a disclosure control problem and either remove it, constrain it, or redesign the integration before trusting any privacy notice or vendor promise.
Practitioner takeaway: The key judgement is whether the organisation can explain every outbound data flow from a sensitive page to a third party, because if it cannot, the tracker is already part of the privacy risk.
Related resources from NHI Mgmt Group
- Tracking Technologies Guidance (HHS)
- How should healthcare organisations control tracking technologies in patient portals?
- How should organisations apply NIST password guidance when users manage many accounts across work and personal systems?
- Why does device fingerprinting often work better than cookies for tracking suspicious devices?