Both, because the risk sits at the intersection of data handling and code execution. Treating tags only as a web team concern leaves privacy, security, and ownership gaps unresolved, while treating them only as data inventory misses the runtime behaviour that creates leakage.
Why tag management sits between governance and security
Tag management is not just metadata administration, and it is not just frontend code. Tags often carry business context, consent signals, analytics identifiers, and routing logic, while also loading third-party scripts or altering page behaviour at runtime. That makes the subject a governance issue about ownership and permitted data use, and an application security issue about execution, integrity, and trust boundaries.
Teams that only manage tags as a marketing or web operations task tend to miss who approves what data is collected, what the tag is allowed to do, and how changes are reviewed. Teams that only classify tags as inventory miss the fact that a tag container can execute code, call external services, and create new data flows after page load.
What the security and data paths actually are
The main risk is that a tag can both observe data and influence runtime behaviour. A single container can collect user attributes, set cookies, trigger network requests, and inject scripts, which means the same control surface affects privacy, confidentiality, and application integrity. That is why tag governance needs data rules for collection and retention, plus application security rules for code provenance, change control, and execution constraints.
This dual nature also changes ownership. Data governance should define what data a tag may capture, whether consent is required, where data can flow, and who is accountable for classification and retention. Application security should define how tags are approved, tested, sandboxed, monitored, and removed when no longer required. If either side is missing, organisations usually end up with gaps in review, weak accountability, or uncontrolled external dependencies.
- Consent and purpose limitation belong to the data governance side.
- Script injection, supply chain trust, and runtime tampering belong to the application security side.
- Third-party tracking, pixel sprawl, and opaque data egress need both views at once.
How to organise controls without splitting the problem
Use one operating model with two control lenses. Data owners should approve the purpose, data categories, and downstream sharing for each tag or tag vendor. Security owners should approve the technical placement, script source, versioning, loading conditions, and monitoring for abuse or unexpected behaviour. The control fails if either approval happens in isolation.
OWASP ASVS is useful for the application side because it reinforces verification of authentication, session handling, access control, and secure runtime behaviour. On the data side, the NIST Privacy Framework is a strong fit because tag management often determines what personal data is collected, disclosed, and governed in practice. For teams that also use agent-like or highly dynamic tooling in their web stack, NHIMG’s OWASP Agentic Applications Top 10 is a useful reminder that runtime authority and tool-like behaviour need explicit boundaries.
Risk and Threat Considerations
Tag managers create concentrated risk because a small configuration change can alter what data is collected and what code runs across many pages. That makes them attractive to both accidental misuse and malicious abuse, especially when third-party tags are added without tight review or when stale tags keep collecting data after the original business need has ended.
Failure mechanism: An unreviewed or compromised tag can expand data collection, redirect data to an unexpected destination, or introduce code that changes page behaviour outside the original approval scope.
Impact: The result can be privacy leakage, consent violations, script injection, unreliable analytics, and a wider attack surface that is difficult to detect from ordinary application review alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Tag managers load and execute web-facing code that affects runtime security and access flows. |
| Recommendation — Verify tag-loaded scripts with the same scrutiny used for sensitive web-service behavior. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Tags should only access the data and runtime capabilities they need. |
| CM-3 — Configuration Change Control | Tag changes can alter page behavior, data collection, and third-party calls. | |
| AU-2 — Event Logging | Tag changes and runtime behavior need auditability for investigation and accountability. | |
| Recommendation — Restrict tag permissions to the minimum data and execution scope. Require review and approval before modifying production tag configurations. Log tag deployment and change events so unexpected behavior can be traced. | ||
Practitioner Guidance
What to prioritise: Treat every tag as both a data decision and a code decision. If a tag handles personal data, third-party calls, or user tracking, require a named business owner and a technical owner before it is approved.
What to verify: Confirm the exact data elements collected, the destinations they reach, the conditions under which the tag loads, and the rollback path if behaviour changes. A tag that cannot be described clearly enough for both privacy review and runtime review is not ready for production.
Decision rule: If the concern is only “what data is this tag storing,” you are under-scoping the problem. If the concern is only “can this script run,” you are also under-scoping it. The control must cover both governance and execution.
Practitioner takeaway: Tag management should be owned as a shared control surface, not handed to one team by default, because the real failure mode is unmanaged crossover between data use decisions and application execution risk.
Related resources from NHI Mgmt Group
- When should organisations treat a data governance platform as part of security architecture?
- Should organisations treat data destruction as part of security governance?
- Should organisations treat data discovery as part of IAM governance?
- How should organisations connect data security posture management with access governance?