TL;DR: Consent tracking breaks when OneTrust has to carry privacy choices beyond the surface, because downstream systems, identity, and proof sit outside the control boundary, according to Ketch. Privacy teams need person-level state and logged enforcement if they want opt-outs to hold across channels.
Editorial analysis by NHI Mgmt Group, based on content published by Ketch: “Configuration, not code: Why OneTrust breaks at scale—and why Ketch doesn’t”.
Key questions
Q: Why do privacy teams need person-level consent instead of browser-level consent?
A: Browser-level consent breaks as soon as a consumer changes device, browser, or session context.
Q: How do you know if an opt-out workflow is actually working?
A: Look for evidence that the request reached every system that processes the data and that the enforcement action is logged, verifiable, and reproducible later.
Q: What breaks when consent is captured but not enforced end to end?
A: The privacy programme fails at the point that matters most: downstream systems keep processing data after a choice has been made.
Practitioner guidance
- Define person-level consent state Store opt-outs and preferences against a stable person identity so the same choice can be enforced across browsers, devices, and authenticated sessions.
- Orchestrate downstream data-use changes Ensure opt-out requests trigger actual restrictions in advertising, analytics, CRM, CDP, and internal databases, not just front-end suppression.
- Log every enforcement action Keep timestamped records of the request, the propagation path, and the systems updated so proof is available without manual reconstruction.
Bottom line: Privacy enforcement fails when the platform records a choice but cannot carry it through the systems that use the data.
Glossary terms: Person-Level Consent, Downstream Enforcement, Choice Propagation Gap, Identity-Aware Workflow
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Privacy choice governance fails when consent is treated as a capture problem. The article’s central architectural point is that surface collection does not equal enforced outcome, and regulators are increasingly testing the outcome. For privacy programmes, the relevant control is not the banner itself but the ability to propagate the decision into every system that processes the data. Practitioners should treat consent as an operational policy enforcement problem, not a front-end form.
A question worth separating out:
Q: When should organisations prioritise downstream orchestration over banner design?
A: Once the organisation processes personal data in more than one system, downstream orchestration becomes the higher-value control because that is where compliance actually succeeds or fails. Banner design matters for collection, but orchestration determines whether the choice changes processing behaviour. If the platform cannot propagate the decision, the front end is only cosmetic.
👉 Read our full editorial: Privacy choice enforcement fails when consent stays tied to devices