We provide our consent every day, often without a second thought. We’ve adapted to automatically clicking through distracting ‘accept’ buttons on website pop-ups, or those obligatory checkboxes when completing various web forms. No matter what the activity is, it seems there’s always a requirement to consent to something.
In this post, I explain current and emerging regulations for consent management, how to conform to these regulations through capturing and storing privacy data, and finally, I highlight key considerations when designing and implementing a consent management framework.
The Data Protection Regulatory Landscape
The regulatory landscape is on the move. What started with the General Data Protection Regulation (GDPR) in Europe, is rippling across continents. Recent regulations include the California Consumer Privacy Act (CCPA) and the Lei Geral de Proteção de Dados (or LGPD) in Brazil. Then there’s India’s upcoming Personal Data Protection Bill (PDPB), which is set to be one of the strictest and most comprehensive data privacy laws globally. And this is just the beginning—we should anticipate similar regulations popping up for years to come.
While these current and emerging data protection regulations may vary, one common trait they all share is their primary aim: to give individuals control over their personal data while also requiring organizations to establish a legal basis for processing such data.
Data Protection Regulations: Getting Legal
The legal bases for data processing varies by data protection regulation. The GDPR and CCPA both have six legal bases, the PDPB has seven, and the LGPD has ten. Determining a legal basis for processing data is key, as all regulations articulate that data can only be processed if there’s at least one legal basis for doing so. While legal bases vary by regulation, one common basis that’s shared across all regulations is consent. And consent is always required for marketing.
“Determining a legal basis for processing data is key, as all regulations articulate that data can only be processed if there’s at least one legal basis for doing so.”
Under the basis of consent, organizations need to identify what an individual has actually consented to at the broadest level. There’s a common misconception that consent is always required for data processing—it’s not. You may not need to obtain consent if you’re providing a core service (you should use a contract instead) or have an obligation to process data to comply with a common law or statutory obligation. However, below are a few examples, where consent is required:
- Using behavioral tracking or advertising cookies on websites
- Sending marketing emails or newsletters
- Sharing personal data with other companies
In these scenarios, you need to obtain express consent (instead of implied consent).
Express Consent Versus Implied Consent
With express consent, you need to ask for someone’s consent, so they understand the question and the implications, and they can make an informed choice. Implied consent, on the other hand, is when consent may reasonably be inferred based on a person’s actions. In other words, implied consent is when you have reason to believe that a person would give you their consent if you asked for it.
What if I Already Have a Preference Center?
There’s often ambiguity on the differences between capturing consent and the role of email preference centers. Some assume that the role of a preference center is consent management. But it’s not. Consent management and preference management serve different purposes.
“Consent management and preference management serve different purposes.”
Consent management determines which individuals provided consent, why they did, via what channel and what they actually consented to. On the other hand, preference management enables individuals to choose their preferred communication frequency, interests, and alternative options to unsubscribing. However, while consent and preference management differ by function, both support each other. Individuals have a right to revoke their consent anytime, and a preference center is a common channel for individuals to exercise this right. As a result, preference management needs to be tightly coupled to consent management.
Single Source of Truth
While capturing and auditing an individual’s consent might sound pretty straightforward, the challenge is often in determining who the individual actually is. Data is typically siloed and highly fragmented across different sources, or ‘collection points’. While an individual may have consented to receiving marketing communications when they registered for a webinar or downloaded a whitepaper, they might not have opted-in when making an online purchase, or perhaps they did when completing a different transaction as a guest checkout.
This challenge is further compounded by the fact that an individual may not have a single common identifier, like an email address. They may have provided their work email address at one collection point and their personal email address at another. However, by applying identity resolution techniques to unify multiple identifiers across touchpoints, it’s possible to determine a single source of truth (or SSOT) for an individual. To do this, organizations can apply deterministic or probabilistic matching techniques, which either resolve identities based on what you know to be true, or predict to be true.
Similar to preference management, identity resolution and consent management are interconnected, and both need to be considered when designing a consent management solution. There are several different approaches to achieving identity resolution. This can be achieved declaratively through platforms such as Salesforce Customer 360 Data Manager, or Customer Data Platforms such as Amperity, mParticle, Segment, and Simon Data, to name just a few. Alternatively, where a low level of matching rule complexity is required, writing custom database queries to link records may also be an option.
“…identity resolution and consent management are interconnected, and both need to be considered when designing a consent management solution.”
Consent Management Framework Considerations
When designing a framework to collect and store an individual’s consent, there are three distinct parties to consider, each of which has a different function within a consent management framework, which are:
- Data Subject
- Data Controller
- Data Processor
These terms are directly borrowed from the GDPR, but other regulations have similar terms. For example, CCPA refers to ‘Businesses’ rather than ‘Data Controllers’ and ‘Service Providers’ rather than ‘Data Processors’. And the PDPB uses the term ‘Data Principal’ instead of ‘Data Subject’, and ‘Data Fiduciary’ instead of ‘Data Controller’. However, while terms may vary, these party types and their roles are broadly aligned across regulations.
Data Subjects are people who are responsible for providing consent. This could be a website visitor, a customer, a conference attendee, or any other representative of an individual who provides authorization for their personal data to be collected and processed.
Data Controllers provide the ‘why’ and the ‘how’ of data processing activities. They make decisions about how activities should be processed and are ultimately responsible for how the data is processed. Any organization that collects personal information of customers, website visitors, or other audiences is a Data Controller. Obligations of a Data Controller will vary by regulation, but typically includes the following responsibilities:
- Collection of personal data from an individual
- Determines what to collect
- Determine a legal basis to obtain the data
- Define when and how the data is to be used and for what purpose
- Determine how long the data is to be retained for
“Any organization that collects personal information of customers, website visitors, or other audiences is a Data Controller.”
The Data Processor is responsible for acting in line with the Controller’s instructions to process personal data. While the Data Controller and Data Processor may share similar responsibilities, a Data Processor acts on behalf of the Data Controller, that is, they operate by instructions from the Data Controller. Examples of Data Processors include a mailing house, or a digital marketing vendor. Typical responsibilities include:
- Storing data gathered by the Data Controller
- Maintain a record of all data processing activities
- Implement security measures to safeguard data
- Facilitate data exchange between platforms and organizations
A typical consent management process flow indicating the tasks and responsibilities across roles is illustrated below.
Coming to a Country Near You
While recent and emerging data privacy regulations have arguably been a catalyst for consent management, this term is not a “new idea”. International spam laws have required that individuals opt-in to marketing communications for almost two decades. However, these reforms closely fit with the data-driven world we live in today, where almost every service we use involves the collection and processing of our personal data, at some level.
Data protection is on the move, and we should brace ourselves for whatever four-letter regulations come next. While these regulations can often seem overwhelming, they actually simplify the regulatory environment for organizations, while also giving an individual more control over their data, which can only be a good thing.
If you would like to understand how you can implement a consent management framework for your organization, reach out to us today.
Disclaimer: The information provided in this post does not constitute legal advice, is not intended to be a substitute for legal advice and should not be relied upon as such. You should seek legal advice or other professional advice in relation to various governing laws and data compliance regulation matters you or your organization may have.
