Topic starter
24/10/2026 8:53 pm
TL;DR: OneTrust captures privacy signals at the surface but leaves opt-outs, consent, and proof fragmented across devices, channels, and downstream systems, creating enforcement risk and operational drag when organisations must rely on custom engineering to make choices follow people rather than browsers, according to Ketch. Architectural enforcement, not banner capture, is what regulators are increasingly testing.
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: 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.
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.
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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →