OneTrust Consent Management

OneTrust is one of the most widely deployed privacy and consent management platforms. It covers cookie consent, DSAR automation, ROPA management, third-party risk assessments, and policy management across multiple jurisdictions.

This guide addresses implementation decisions that are not covered by OneTrust's own documentation: how to configure the consent model correctly for GDPR, how to integrate consent signals with downstream CRM and marketing systems, and what the common misconfigurations look like before an audit.

OneTrust product structure

OneTrust is a platform, not a single product. Organisations frequently purchase the wrong modules for their use case or purchase modules they do not configure. The relevant modules for GDPR in a CRM/marketing context:

Module	Function	GDPR relevance
Consent & Preferences	Cookie consent banner, preference centre, consent record storage	Core — required for any website with EU visitors
DSAR Automation	Intake form, identity verification, workflow routing, response assembly	Required for Article 15–22 compliance at scale
Data Mapping	Automated discovery of data flows, ROPA population	Required for Article 30 compliance
Privacy Policy Management	Version control and publication of privacy notices	Supporting — keeps notice versions linked to consent records
Third-Party Risk Management	Processor agreements, vendor assessments	Supporting — required for Article 28 processor agreements
Assessment Automation	DPIAs, LIAs, TIAs	Required for high-risk processing and cross-border transfers

Do not purchase the full platform if you only need cookie consent. The modules you leave unconfigured will create false confidence that the obligations they cover are being met.

Cookie consent configuration

OneTrust's banner builder is the most visible component. Several configuration decisions determine whether it produces valid consent:

Purpose categories

OneTrust's default categories (strictly necessary, performance, functional, targeting) map to IAB TCF purposes. GDPR does not require this taxonomy — it requires purposes to be described in plain language. If your actual use of targeting cookies does not match the IAB description, reclassify or write custom purpose descriptions.

Prior action / implied consent mode

Some older OneTrust configurations use "prior action" — treating scroll or continued browsing as consent. This was deprecated by the ICO in 2023 guidance. Verify your configuration requires explicit affirmative action before non-essential cookies are set.

Granularity

Each sub-purpose should be individually toggleable where technically feasible. A single "accept all" / "reject all" binary is compliant but leaves no room for contacts who want some tracking and not others. More granular banners convert fewer contacts to full consent but produce a more defensible consent record.

Geo-targeting

OneTrust supports geolocation-based banner variants. EU visitors should see a full consent banner. Visitors from non-GDPR jurisdictions can see a simpler notice. Verify the geolocation database is current and that the default for unresolved locations is the most restrictive variant.

CRM integration

OneTrust's consent records are only valuable if they reach the CRM. This is the integration that most implementations get wrong.

Salesforce connector

OneTrust has a native Salesforce integration that writes consent events to the Individual object. Configuration requirements:

• Individual objects must be linked to Contact records — not created in isolation
• Consent purpose codes in OneTrust must map to data use purposes configured in Salesforce's Privacy Center
• Withdrawal events must trigger a Salesforce Flow that updates opt-out fields on related Lead, Contact, and Campaign Member records

HubSpot / Marketo / Pardot

No native connectors. Integration requires OneTrust webhook → middleware (Zapier, MuleSoft, or custom) → CRM API. The webhook fires on consent event; the middleware must handle deduplication and error retry. Without retry logic, withdrawal events that fail silently leave the contact eligible for continued marketing.

Custom CRM integration

OneTrust exposes a REST API. The consent status endpoint returns the current status by purpose for a given identifier. The event API provides a webhook stream of all consent changes. Query the status API on every data activation (before email send, before ad list upload) rather than relying on a sync that may be stale.

DSAR workflow configuration

OneTrust's DSAR module requires configuration that reflects your actual data architecture:

Identity verification

Determine the identity verification method before building the workflow. OneTrust supports email verification, knowledge-based authentication, and integration with identity verification services. The method must be proportionate to the sensitivity of the data — full identity verification for a request to access financial records; email confirmation may be sufficient for a marketing preferences request.

System connections

OneTrust's data discovery scans connected systems to identify records belonging to the requesting individual. Configure connections to every system that holds personal data: CRM, marketing platform, support system, data warehouse, HR system. Unconnected systems must be handled through a manual step in the workflow — the workflow must include this step explicitly, not silently omit it.

Response assembly

OneTrust's response builder compiles data from connected systems. Configure the redaction rules to prevent third-party data (records about other individuals) from appearing in the response. Test with synthetic requests that include edge cases: contacts with common names, contacts who appear in both CRM and support systems under different identifiers.

Deadline tracking

GDPR requires response within one calendar month, extendable to three months for complex requests. OneTrust's deadline tracker must be configured with the correct calendar, including jurisdiction-specific rules where you operate in multiple countries.

Common misconfigurations

Scripts firing before consent

The most common audit trigger. Analytics and advertising scripts load in the page <head> before OneTrust can fire the consent signal. The fix is to wrap non-essential scripts in OneTrust's OptanonWrapper or to move them to load after consent is confirmed. Verify with a cookie audit tool (e.g. Cookiebot Scanner, OneTrust's own cookie scanner) after any tag manager change.

Consent records not linked to CRM contacts

OneTrust writes consent to an Individual record, but if that record is not linked to the Contact, the consent history is inaccessible from the CRM. An agent processing a DSAR cannot see the consent history without leaving the CRM. Fix: configure the Individual-Contact link in the Salesforce connector setup, and audit existing Individual records for linkage gaps.

ROPA populated manually and not maintained

OneTrust's Data Mapping module can auto-discover processing activities from connected systems. If it is configured but not connected, or connected but the discovery has not been run since initial setup, the ROPA is stale. Schedule automated discovery quarterly and assign a data owner responsible for reviewing flagged changes.

Assessment Automation not triggered for high-risk processing

DPIAs are mandatory for processing likely to result in high risk to individuals — systematic monitoring, large-scale special category processing, novel technology. OneTrust's screening questionnaire determines whether a DPIA is required. If no one is completing the screening questionnaire before new processing activities begin, the obligation is being missed systematically.