Implementation Best Practices: Universal Consent & Preference Management

1. Introduction

The below are considerations and best practices to keep in mind when implementing Universal Consent & Preference Management. By following these guidelines, organizations can maximize the effectiveness of their OneTrust implementation.

2. Key Considerations

2.1 Regulations & Frameworks

Identify the core regulations and frameworks driving your implementation. OneTrust supports a wide range of privacy laws and standards, including GDPR, U.S. State Privacy Laws, LGPD, HIPAA, PIPEDA, and APPI.

Best Practices:

  1. Conduct a thorough analysis of which regulations apply to your organization. This ensures your implementation focuses on the most relevant compliance requirements, avoiding wasted effort on non-applicable regulations.

  2. Prioritize implementation based on the most critical or imminent compliance needs. This approach allows you to address the most pressing regulatory requirements first, reducing compliance risk and demonstrating progress to stakeholders.

  3. Consider industry-specific frameworks (e.g., NIST for government contractors) that may apply. Industry-specific frameworks often have unique requirements that go beyond general privacy regulations. Incorporating these ensures a more comprehensive compliance approach.

2.2 Key Stakeholders

Identify stakeholders who own systems and data processes across your organization. Successful implementation requires collaboration across multiple departments.

Best Practices:

  1. Form a cross-functional privacy team including representatives from Legal, IT, Information Security, HR, and key business units. Include individuals who act as DPOs for legal entities, if applicable. Also consider including internal contacts for third parties. Privacy impacts all areas of an organization. A diverse team ensures comprehensive coverage of privacy concerns and promotes organization-wide buy-in.

  2. Clearly define roles and responsibilities for each stakeholder in the OneTrust implementation process. Clear roles prevent duplication of effort, ensure all necessary tasks are covered, and create accountability for specific aspects of the implementation.

  3. Establish regular communication channels and meeting cadences for the privacy team. Consistent communication keeps all stakeholders informed, allows for timely problem-solving, and maintains momentum throughout the implementation process.

  4. Identify executive sponsors to champion the implementation and secure necessary resources. Executive support is crucial for overcoming organizational barriers, securing budget and resources, and emphasizing the importance of the privacy program across the organization.

2.3 Organizational Structure

Determine how to represent your organization's structure within OneTrust. This will impact data visibility, access controls, and reporting capabilities.

Best Practices:

  1. Decide if mirroring your actual organizational hierarchy within OneTrust, including the different sub-organizations/brands is relevant to you, for example if you would prefer different brands within your organization to only have visibility of their own digital assets. However, it is not always necessary for every business and may lead to an overcomplicated set-up.

  2. Implement role-based access control (RBAC) to ensure appropriate data access and permissions. RBAC enhances data security, prevents unauthorized access, and ensures users only see information relevant to their roles and responsibilities.

  3. Plan for future organizational changes and ensure your structure is scalable. Organizations evolve over time. A flexible, scalable structure in OneTrust reduces the need for major reconfigurations as your organization changes.

  4. Consider language requirements if multi-lingual use is applicable to your organization.

3. Scope

3.1 Identity Management

Identity Management is a key component of interacting with Data Subjects – especially when leveraging multiple products within the same solution. Having a consistent definition of a Data Subject is pivotal throughout this implementation.

Best Practices:

  1. Identifiers:

    Decide what logic to use for identifiers across the modules in scope and throughout the eco-system. The simpler the logic, the better. Consider using one common identifier such as Email, Phone, or custom ID to handle data subjects – the Email identifier being the most common (especially when it comes to Marketing use cases), and giving access to several out-of-the-box features leveraging emails from OneTrust (Double Opt-In, Acknowledgement Emails, One-Time passcodes to access Preference Centers, etc.). While OneTrust has capabilities in multiple identifiers and merging, it’s usually more straightforward to have a uniform data model across your eco-system. Note that Privacy Rights Automation web forms usually rely on an email or a phone number, making those IDs ideal; if another type of identifier is used, there might be a need for custom logic later down the line if there was a requirement to link profiles from Consent and Privacy Rights Automation.

  2. Identity Management Solution:

    Decide whether your organization needs an integration with an Identity Management solution. One crucial way of handling identifiers is to rely on an Identity Management solution to either generate IDs for each data subject and/or handle merging and other logic on data subjects.

  3. Data Subject Journey:

    Decide what the data subject journey will look like. Map (through a diagram, mockups, or simply a list of steps) all the actions through which a Data Subject gets created for the first time within your eco-system, and all subsequent actions through which they can update their consent preferences.

3.2 Data Retention Policies

Holding onto personal data longer than you need for purposes you collected presents risks to most privacy laws. When setting up data retention policies within OneTrust, they should align with company-defined data retention policies. Data should be purged once it's no longer needed for the original purpose collected unless legally required.

For more information, see Setting Up Consent Retention Policies.

Best Practices:

  1. Decide how long you want to retain data subjects, what criteria you will use to define when a data subject no longer needs to be retained, and if you will need to maintain receipts. Usually, customers set up the OneTrust retention rules to delete Data Subjects after a certain period, once their consent has expired or has been withdrawn. However, you will need to consider the regulations in place within the market you’re implementing and the recommendation of the company’s privacy team to decide on those timeframes and requirements.

3.3 Country/Market

It is crucial to choose whether the implementation will be carried out across the whole organization or for a specific market/country/entity. It is also key to identify the structure within the OneTrust environment – this will drive the way objects are created and data is collected/segregated.

For more information, see Organizational Hierarchy Best Practices and Managing Organizations.

Best Practices:

  1. OneTrust advises implementing one country or market first, while keeping in mind the broader company during the Design. Good practices such as naming conventions and leveraging the organizational structure can be of great benefit in making the platform easier to scale.

  2. Most companies would break their organizational structure into regions and countries and/or into brands and sub-companies, depending on the way they operate. Breaking it down first into regions and countries might be the most relevant depending on the company’s eco-system and the way the organization operates – it also allows to focus on a country or market MVP.

4. Configuration

4.1 Purposes

While those can be discussed with your OneTrust consultant or representative, having a good idea of the purposes for which consent is collected today would help speed-up design activities.

For more information, see Setting Up Purposes of Processing.

Best Practices:

  1. Companies typically leverage OneTrust to collect and store consent related to Marketing activities (such as sending out newsletters) and use the purpose preferences mentioned below to collect additional information. It is very important to remember to assign the purposes and subsequent objects listed in this section, to the right organizational structure.

4.2 Purpose Preferences

Similarly to purposes, preferences can be discussed during design workshops, however it is key to understand the level of granularity for which consent will be collected.

For more information, see Adding and Editing Purpose Preferences.

Best Practices:

  1. Typical preference examples are the frequency and the format of newsletters / marketing communications and/or their content (i.e., what type of newsletters does the Data Subject want to receive? Which topics are they interested in?),

4.3 Data Elements

It’s important to consider whether additional metadata will be collected along with the consent records, to update a Data Subject profile. Those could be fields such as First Name, Last Name, etc. They can also be used to apply conditional logic onto the end-goal Preference Center and display certain fields and purposes accordingly. Thus, collecting roles, locations, and other significant data for your processes might be useful.

For more information, see Managing Data Elements.

Best Practices:

  1. First Name, Last Name and Location are the most common data elements used when determining how to display and collect data from a OneTrust Hosted Web Form or Preference Center. However, additional fields such as IDs related to the systems used within the company might be relevant to be stored in OneTrust (CRM IDs, etc.).

4.4 Collection Points

Strongly linked to the scope of the project and chosen roll-out methods, identifying the touchpoints that need to integrate with OneTrust would be a key driver for this implementation to know which technical resources/owners would need to be involved.

For more information, see Using Collection Points and Available Types.

Best Practices:

  1. OneTrust typically recommends focusing on a subset of touchpoints, such as a registration web forms, newsletters sign-up web forms and – if needed – an inbound interface from one of your systems. API Collection Points do provide the most flexibility, however, for a quick implementation – the use of a JavaScript SDK, embedded web form or hosted web form is more efficient, especially if there are no other links yet between the chosen touchpoint and the rest of the eco-system.

4.5 Preference Centers

Similarly, there is a need to decide the number and scope of Preference Centers that will need to be implemented. Will you choose a global Preference Center for the whole organization, or one per country/brand/market/entity?

For more information, see Creating a Multi Page Preference Center.

Best Practices:

  1. Both approaches mentioned above are valid, and both may be implemented – in which case, we’d strongly recommend starting out with a chosen country/brand/market. We most commonly see companies implement a Preference Center focusing on one market first, as a Minimum Viable Product (MVP).

4.6 Outbound Integrations

Depending on all the above, what would be the systems OneTrust needs to push data (consent records and other potential meta-data) to? This will be crucial to ensure OneTrust is best leveraged across your eco-system(s).

For more information, see:

Best Practices:

  1. If there is a middleware in your current eco-system, it might be worth leveraging it – limiting the number of outbound interfaces between OneTrust and your systems makes the implementation more scalable over time. Limiting the amount of logic happening on the OneTrust Integration Workflows is also a good practice to simplify implementation and maintenance.

4.7 Historical Data Import

Will there be an import of existing consent records into the platform? If so, it is key to start thinking of the volume and how it can be exported from its current location and transformed to match the OneTrust expected format.

For more information, see Bulk Importing Consent Records.

Best Practices:

  1. There is typically a need to import existing records and a data transformation exercise might need to occur, in which case it is good practice to have someone with technical abilities (when it comes to handling data through editors or code) involved in this workstream. It is key to remember to import in batches, starting with a subset, and testing and double-checking each import in the platform. It is also recommended to thoroughly ensure that no non-required settings are turned on, on bulk import collection points (for instance, Double Opt-In or any other email triggering setting should be turned off, unless explicitly needed for a re-consent use case). It is essential that any expiration necessary for Magic Links be decided and configured in advance of the import taking place.

5. Leveraging Other Modules

Authenticated consent allows overriding of the default random ID (generated by OneTrust) whenever a consent record is generated through the Cookie or Mobile App Banner (or Connected TV). This would allow you to use a chosen identifier, such as an email or custom ID.

For more information, see Cross-Domain and Cross-Device Consent.

Best Practices:

  1. Decide if Authenticated Consent (tool within Consent Rate Optimization) is required. Using a chosen identifier would allow you to share consent given by a user on one Website or Applications across your other managed Websites and Applications. This is achieved through linking consent to a unique user identifier, which can be shared across the protected OneTrust cloud to additional devices or browsers where the user chooses to roam, safely creating a seamless user experience.

5.2 Unified Profile

Unified Profile is a feature that would allow for the creation of Data Subjects Profiles within Universal Consent & Preference Management for users interacting with the OneTrust CMP product.

For more information, see Connecting CMP Preferences with Universal Consent & Preference Management Profiles.

Best Practices:

  1. Decide if Unified Profile is required. If yes, Data Subjects will be created in OneTrust and will enable the usage of Universal Consent & Preference Management APIs and the triggering of Integration Workflows to send consent to outbound systems – consider which systems would need to consume this information. Most importantly, if you do plan on leveraging the Preference Center for Cookie-related consent, this feature is required. If the feature is not used, consent coming from Cookie Banners and Mobile / Connected TV Banners will only generate receipts in the platform.

5.3 Adding Notices to the Preference Center

Privacy Notices can also be added to the Preference Center, either through a hyperlink or iframe.

For more information, see Integrating Privacy Notices.

Best Practices:

  1. Decide if the notice should be added to the Preference Center. The most common approach is to add the notice as a hyperlink. This is the best practice if the notice also contains the dynamic Cookie List (automatically pulled from our Cookie SDK) as the notice would need to be hosted on the same domain as the Cookie SDK to work properly. Otherwise, if the notice is relatively short, a hosted link can be generated from the Privacy Notice Management module and added as an iframe onto the Preference Center.

If there is a need to collect consent for Universal Consent Purposes within a Mobile application, this is possible using the Universal Consent Purposes Banner that is available within the Mobile App Consent solution. This banner will allow collection of consent for purposes like promotional emails, newsletters, SMS messaging, etc. that typically require an integration with a third-party system like Salesforce and Marketo. After a Universal Consent transaction is collected, integration workflows can be triggered within the OneTrust tool.

For more information, see Universal Consent Purposes for Mobile App Consent.

Best Practices:

  1. Decide if there is a need or opportunity to collect marketing consent through a Mobile Banner. If you would like to ensure that you are collecting marketing consent via your mobile application via the OneTrust out-of-the-box UI, this is recommended. It is also recommended to have configured Authenticated Consent (and Unified Profile if relevant) to ensure that the consent is tied to a specific user.