Consent Manager Specifications
This document outlines functional and technical requirements for implementing consent management across web (and optionally mobile) in a way that supports common privacy obligations (e.g., GDPR/ePrivacy and other regional consent regimes). A consent manager should present clear notices, capture granular user choices, enforce those choices by controlling non-essential tags, and record actions for auditability. Where advertising ecosystems are involved, the implementation may integrate with industry consent signaling standards (e.g., IAB TCF) or equivalent mechanisms. The goal is legally valid consent (informed, specific, freely given) while maintaining good UX and performance.
A CMP should: 1) Identify and categorize cookies/trackers (or define categories aligned to your tag inventory). 2) Prevent non-essential tags from firing before consent where required. 3) Provide a clear preference center with granular choices. 4) Record user actions (grant/update/withdraw) for auditability. 5) Support consistent consent across related domains/apps where applicable. 6) Provide an easy mechanism for users to update or withdraw consent.
Consent interfaces are commonly implemented as a non-blocking banner or modal, but the appropriate approach depends on jurisdiction and business context. Technically, the CMP script should load efficiently (e.g., async/defer where appropriate) while ensuring consent enforcement runs before non-essential tags. Avoid designs that coerce consent or restrict access unless your legal assessment explicitly supports that approach.
For ad-tech ecosystems, the IAB Transparency and Consent Framework (TCF) is a common standard for communicating user choices to participating vendors (via a consent string). Outside ad-tech, many implementations rely on an internal consent state enforced through a tag manager or application logic. Global Privacy Control (GPC) is another signal used in some regimes to express privacy preferences via browser settings.
Cross-domain consent can be implemented by storing a consent token (e.g., an ID plus preferences/metadata) in a first-party context and syncing preferences through a backend service. The goal is to apply a consistent consent state across related domains while respecting browser limitations and user expectations. Third-party cookies are increasingly restricted, so server-side or first-party approaches are typically preferred.
Good consent UX generally includes: 1) No pre-ticked boxes. 2) 'Reject' should be as easy to choose as 'Accept' (avoid dark patterns). 3) Plain, intelligible language. 4) Granular options by purpose/category. 5) Accessibility aligned to recognized standards (e.g., WCAG 2.1) where applicable.
CMPs commonly integrate with tag managers (e.g., GTM) by setting a consent state and/or pushing events (e.g., consent_update) into a data layer. Tags are then configured to fire only when the required consent category is present. The same pattern can be applied without a tag manager by enforcing consent in application code.
CMP scripts can affect Core Web Vitals if they block rendering or delay interactivity. To reduce impact, keep the CMP lightweight, serve it efficiently (CDN/caching), and avoid heavy main-thread work. Consent enforcement logic should run early enough to control non-essential tags without causing visible page flicker or user experience delays.
Common tests include: 1) Clear cookies/storage and confirm non-essential tags do not fire prior to consent where required. 2) Confirm 'Accept' enables only the selected categories. 3) Confirm 'Reject' leaves non-essential tags disabled. 4) Validate that consent actions are logged (grant/update/withdraw) with the notice/version shown. 5) If using a consent string standard (e.g., TCF), validate it with appropriate tooling. 6) Verify withdrawal/changes take effect across tags and systems.
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2026-02-09 | WatchDog Security GRC Wiki Team | Initial publication |