GDPR Right to be Forgotten and Consent: Lessons Learned (Part 2)

26 Feb, 2018

Lessons Learned from applying right to be forgotten (RTBF) and consent across thousands of applications and databases

In the previous blog I have presented the pros and cons of application-centric approach compared to the database-centric approach for applying consent and RTBF.

In this blog, I will provide insights to yet a third approach known as the Master Data Management (MDM) approach for GDPR. Just to clarify, MDM is not a technology, and neither is it platform or a product. Instead, it is rather an implementation methodology.

The approach of MDM is to build a consolidated customer list that uses APIs to communicate with applications, databases and big data environments and manage each customer record with different consent and Right to be Forgotten (RTBF) flags. With this methodology, the GDPR journey does not start by implementing GDPR in your top-risk applications or in your high-throughput databases, but rather with creating a hub with a single customer view.

Once this MDM hub exists, then comes the “simple” process of having hundreds of business applications, databases, big data and tools call the MDM hub and get the consent/RTBF of the customer. These applications need to validate the customer state in the MDM central hub when performing all customer data-flows and processes. Not so simple, as you can imagine…

Although creating a single customer view that would benefit the business seems like a great way to approach the GDPR, the problem lies in having to build the MDM first and then embedding it to the various applications. This introduces the following caveats:

  1. MDM projects start with long analysis of the source customer list. Should it come from the CRM, front-office, ERP or other fifty core applications and data sources.
  2. After qualifying the sources, the “master” list needs to fitted into a single database, both for historical data as well as procedures to maintain accurate master list for new customer onboarding. This involves discovering a customer data model in each of the sources and building an Extract, Transfer and Load (ETL) process loading.
  3. Cleansing the customer data at different sources into a “single truth” that can be retrofitted to the source applications for consent and RTBF.

BUT – The journey to GDPR does not stop when the MDM is created! It is mere the starting point:

Once the MDM is ready, APIs need to be embedded into all source applications to retrofit consent and RTBF back on the corresponding data-flows and processes. For some applications, coding APIs into applications requires costly code-changes, while for others changing code is not even possible (e.g., packaged applications, reporting tools such Business Objects/Cognos, old fat-client tools as well as free-hand DBA/developer tools).

Organizations that try onboarding an MDM solution experience the complexities and cost involved.

My recommendation: Although MDM seems like the “right” methodology to go with, IT complexity, resource restrictions and the ticking GDPR clock require a more practical methodology which I will present in the next blog.

Want to see our product in action? Join us for a Demo!
Apply for this Job

Or send your resume at
Thank for you applying
We will be in touch shortly.