Code or scripts that record user activity on websites or mobile apps. In healthcare, these tools can collect clicks, page views, device identifiers, IP addresses, geolocation, and other signals that may reveal sensitive health information when tied to a person or patient interaction.
What Online Tracking Technology Does
Online tracking technology is the code layer that observes activity across websites and mobile apps, then stores signals that can be used to recognise a browser, device, or user journey. The technology itself may be small, but its privacy impact can be large because even ordinary interaction data can become identifying when combined.
In practice, tracking tags, pixels, SDKs, and embedded scripts often serve analytics, advertising, or product optimisation purposes. The security and privacy question is not just whether the code works, but what it collects, where that data flows, and whether people would reasonably expect that collection in a given context.
Common Tracking Signals and How They Are Used
Tracking tools commonly capture page views, clicks, referrers, IP addresses, device or browser identifiers, and session timestamps. Mobile tracking SDKs can also collect app events, advertising identifiers, and coarse location data, while cross-site scripts may correlate activity across sessions and properties.
These signals are useful because they allow measurement, attribution, fraud detection, and personalisation. They are also sensitive because each signal may be harmless on its own but become more revealing when joined with account data, health content, or repeated visits to specific pages. That is why online tracking often raises privacy concerns even when the code is framed as a business analytics tool.
Why Tracking Can Become a Security and Privacy Problem
Online tracking technology can expand the number of parties that receive user activity data, which increases exposure and reduces the organisation’s control over how that data is reused. In regulated or sensitive environments, a seemingly ordinary tracker can reveal interest in specific services, conditions, or workflows.
Tracking can also create hidden dependency risk: a site may rely on third-party scripts that change over time, collect more than intended, or pass data to additional domains. For readers who want the privacy-control side of this subject, the NIST Privacy Framework is a useful companion because it frames tracking as a privacy-risk and data-governance problem, not only a web analytics feature.
Governance, Consent, and Control Boundaries
The main governance issue is boundary control: organisations need to know which trackers are present, what they send, and whether the collection matches the stated purpose. The same page can contain first-party measurement code, ad-tech scripts, and embedded third-party functionality, but those components do not carry the same trust or disclosure obligations.
Tracking also intersects with data minimisation and transparency. If a tool captures more detail than the product requires, or if it creates a durable identifier that persists longer than needed, the organisation may lose proportionality between the business purpose and the data collected. For organisations aligning technical controls to privacy obligations, EU General Data Protection Regulation (GDPR) is often the clearest external reference because it connects purpose limitation, minimisation, security of processing, and privacy by design to this kind of collection.
Risk and Threat Considerations
Online tracking technology can expose more than usage analytics. When trackers collect identifiers, URLs, form metadata, or repeated visit patterns, they may reveal sensitive interests or interactions, especially in healthcare, finance, or other high-context environments. The risk grows when third-party code expands the data sharing surface beyond what users expect.
Failure mechanism: Overcollection, third-party redistribution, and identifier persistence can turn a routine tracking implementation into a privacy leak or a compliance issue, even without any obvious breach.
Impact: The result can be sensitive inference, loss of user trust, unnecessary data exposure, and downstream regulatory or contractual consequences if the tracking footprint is broader than disclosed or justified.
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 and NIST CSF 2.0 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 | AU-6 — Audit Record Review, Analysis, and Reporting | Tracking data creates activity records that must be reviewed for inappropriate collection or leakage. |
| AC-22 — Publicly Accessible Content | Tracking tags on public pages affect what data is exposed to outside parties. | |
| Recommendation — Review tracking outputs for unexpected data collection and investigate anomalies in telemetry flow. Control what telemetry is exposed on public pages and restrict unnecessary third-party scripts. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Tracking technology may process personal data and therefore needs privacy controls and disclosure. |
| Recommendation — Classify tracker-collected data and apply privacy controls before enabling collection. | ||
| GDPR | Art. 5 — Principles relating to processing of personal data | Online tracking often involves personal data processing governed by minimisation and purpose limitation. |
| Recommendation — Limit tracking to the stated purpose and minimise collected identifiers and events. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Tracker-collected data may be stored and later reused beyond the original collection point. |
| Recommendation — Protect stored telemetry and restrict retention to the minimum needed for the business purpose. | ||
Practitioner Guidance
What to watch for: Treat trackers as governed data-processing components, not decorative analytics. The practical question is whether each script, SDK, or pixel is necessary, disclosed, and constrained to the minimum signals needed for the stated purpose.
Common misunderstanding: A tracker is not safe simply because it does not collect names or medical notes. Device signals, IP data, event timing, and URL paths can still become identifying or sensitive when tied back to a person or a specific journey.
Practitioner takeaway: The safest tracking design is usually the one that is intentionally narrow, documented, and reviewed as part of privacy and security governance rather than added by default.
Related resources from NHI Mgmt Group
- When should organisations prioritise technology and automation over manual third-party risk tracking?
- How should cannabis operators use access control and tracking technology to support compliance without creating blind spots in day-to-day operations?
- How should organisations prepare for CCPA enforcement when using online tracking technologies and cookie-based data collection?
- Why does the shift to online work and service delivery increase identity risk for banks, healthcare providers, and technology companies?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
