8 focus areas to get consent right

These days there is a lot of commotion about GDPR (General Data Protection Regulation). Most companies have begun assessments, and have some insight into where they stand, often in the form of a gap analysis. Many providers and consultants are eager to help in this area, but it is a lot easier for someone to point out that there are gaps and that something should be done, than to go in depth and talk about specifics. Basically, suggest what should be done and how.

If we focus on the topic of consent, there are certain realities that need to be considered regardless of the solution or technology. So, let’s look at some of them.

1. Personally Identifiable Information (PII) usually exists in a number of systems, applications and databases or storage. Thus, we will have to deal with a PII in a distributed scenario, and apply some form of mechanism to manage this, either as a one-off or as an ongoing process.

2. The distributed nature of PII will not go away. This means that over time, even after we deploy some consent or PII management solution, it will continue to show up in many places. New systems and applications will be deployed, data will be captured in new places, our partner ecosystem will change, and much more. Trying to limit this is a very difficult and costly task and has the added downside of limiting business opportunities and momentum.

3. PII data must be matched across sources to some form of identity. Meaning, if we are looking for PII and how to manage it, we need to have a concept of who the person is, and it must be applicable across the different sources of information. A purchase record in the ERP system belongs to the same person as a preference checkbox in the loyalty system. Without connecting the dots to the same identity, we cannot implement efficient processes and tools for managing this. A by-product of this should be the ability to have better data quality.

4. Consent information is usually also distributed. Consents usually follow the distributed nature of PII as well. We might have checkboxes in preferences in a web application, newsletter and marketing checkboxes stored in a marketing automation solutions. There are also written consents and much more. In addition, we might have various instances of systems and applications for specific legal entities or geographies with duplication, and therefore potentially incorrect information.

5. Consent distribution can (and should be) be limited. Consent information should be treated a little different from PII mentioned above. In this area we can (and should) limit the various places consent is captured and managed. We want to allow people to manage their consents in a central location, so every new place we need to check or update for consent changes introduces complexity. While this does place restrictions on solutions, it has the benefit of knowing that we are using the same consent information across all channels. If we cannot limit the distribution of consent information, then we will need to implement a flexible solution that allows efficient capture and re-distribution of data across multiple systems and applications.

6. Changes to consent or fundamental parts of PII must trigger some business rules in a predictable way. If a person changes their consent, our reaction to it must be predictable. Also, this change should be made available to processes and tools that may depend on the consent being provided. Moreover, changes to fundamental parts of PII might include new ways to identify that person across sources, so we need to know what to do when changes occur for instance in address information, email, asking for data deletion, etc. If these business rules are centralized they will be easier to manage. Also, if consent is centralized, triggering the business rules will be better managed as well.

7. The processes and tools that make use of consent must check for consent and purpose through some mechanism. Processes and tools used in an organization for things like marketing automation, direct marketing, newsletters campaigns, etc. must somehow check or verify that they indeed have the necessary consent for those they are targeting. There are multiple ways of implementing such mechanisms, but if they are to be trusted, they should at least make sure that it is possible for such processes and tools to somehow check or query something to get an accurate and up-to-date response. In some cases, this might mean having a consent API in place, in other cases it might mean pushing updated consents to systems and applications that make use of them. The thing to avoid is having stale data, or data that might not be authoritative (i.e. coming from the source). Any mechanism chosen should support legacy systems that cannot easily query an API, but API should most likely be the preferred option. Typical functionality in such an API could be (pseudo-code):

   • Get all persons that have consented to [purpose] using [data] (optionally using [channel])

   • Does [person] consent to [purpose] using [data] (optionally using [channel])

   Up to this point all the realities mentioned are mostly concerned with compliance. However, if we are to stop at compliance, we know that this will be pure cost. Not cost reduction or saving, but just cost. Pure cost scenarios are, as we know, difficult to get funding for (we allocate what we must, but no one really wants this). Also, pure cost scenarios often have difficulties getting alignment and traction within an organization.

   But shouldn’t all the effort we put into these initiatives have some business values we can leverage? After all, we are connecting identities (for instance customer identities) in a central location. We are creating insights into customer preferences that can be shared across the organization. We are perhaps creating granularity in consents that expands our options in marketing. And we have a common identity for customers across systems and applications. So let’s also look at another aspect.

8. Other customer-related initiatives should be able to leverage our efforts and create added value. We should be able to do things with our consent efforts that can provide clear and specific business value. Following could be typical areas of interest.

   • Build a personal identity solution. Why not re-use this for authentication (customer authentication, etc.) and maybe even authorization? 
   • Integrate consent management with other self-service processes that the person has (loyalty programs, preferences, booking/order etc.)? 
   • New digital initiatives that involve these persons (customers for instance) could re-use efforts to reduce necessary amount of code for authentication, thereby reducing risk and duplication and increasing ROI.
   • Other processes in the business could use this central identity for added value in:
     • Customer interactions
     • Analysis and reporting
     • Customer insight and behavior

   Finding these business values will make it much easier to implement a working solution for consent, providing compliance while integrating that with other business interests. That is a far better starting point for closing GDPR gaps than a pure cost solution.

Conclusion

It could be very beneficial to look at getting consent right from an identity-centric perspective. The gaps identified could then be filled using industry best-practices from already-existing solution areas, such as Identity Management and Master Reference Data Management, which increases the availability of expertise in the market. Furthermore, by looking at the realities of a consent approach, one could create a feasible and desirable foundation for digital initiatives.