Master data management is not the answer to GDPR compliance

Register now

Recently, a number of associates who are expert consultants in related areas have commiserated with me about the lack of uptake in consulting services in North America related to the European Union’s GDPR (General Data Protection Regulation) remediation/preparation.

With that perspective in mind, here are two GDPR perspectives that we all can kick around the water cooler.

1. MDM can be part of the solution ... but it is NOT the solution

We all know that master data management (MDM) systems generally provide a centralized view of the customer (among other domains). And we have internally championed that this is “best” or “golden” copy of all key data/attributes related to customer/prospect. And by inference/indirection, we can infer that any data catalog/dictionary/glossary managing the MDM hub will maintain data lineage information sufficient to allow us to track potentially *all* customer information that IT manages for the business.

However, the vast majority of us understand that this is *not* a complete view but rather the best fit-for-purpose data. Additionally, a data catalog or business glossary (loosely described as “passive data governance by many) can further augment that view of customer by enabling business users to document other sources of that party domain’s data (customer in this discussion). And IT professionals further augment the corporate view of customer by implementing metadata dictionaries that track where used and other lineage info for the benefit of the development staff.

So it is humanly possible to determine/document where most, if not all, of an organization’s customer data resides (including derived copies). For example, MDM assists the DPO (data protection officer – a GDPR-mandated role) or his/her designee organization to respond to data subject rights requests for all data on me and you.

Bottom line: By themselves, neither data governance nor MDM offer sufficient capabilities to meet GDPR requirements. Together, we are much more empowered as an organization.

And now ... what happens to our party data when the person invokes right to be forgotten (RTBF)?

One solution is “anonymization” – for example, redact all that person’s data. At the same time, however, it is vital to still retain the business value of the information. Auditors must be able to trace back all the lineage as to where the MDM’s data originates. Such access to where the data is stored must insure that PII (personally identifiable info) cannot be unscrambled. Moreover, “relationships/interactions” are maintained, but not the PII data.

To further complicate the matter, let’s remind ourselves that certain interactions need to be legally retained – e.g., banking transactions. If a bank knows about a relationship between husband and wife, then all such info cannot be maintained.

Exceptions to GDPR include finance/banking, insurance (car accidents, health claims). GDPR is a *constant* in the previously shifting shadowy language of consent, where info must now be collected by consent.

Everyone can tell Google to “take a hike” and forget all their browsing history and stop serving up ads (in effect). Also, Facebook in the past exercised a member’s RTBF, however, all their previous interactions were still there. Now Facebook must completely remove all that information.

Another area where RTBF does not fully apply is in clinical studies where firms are required to keep info about patients from tests/trials, etc.

For more information on best practices in GDPR solutions for Financial Services (banks, insurers) and Pharma/Med Devices, I often reach out to leading practitioners in those areas such as Fresh Gravity whose CEO/founder Ajit Kumbhare has a practice dedicated to GDPR for pharma and financial services. Their open source, vendor neutral, metadata management solution Gravity Metadata Management Engine (GraMME) was developed to solve the metadata challenges, privacy and compliance needs of today's data-driven enterprise.

For example, one challenge to GDPR compliance is that personal data may (and certainly will) include non-master data. This data may reside in applications outside the boundaries of MDM. Hence GDPR compliance requires software systems that manage the compliance across enterprise applications and not just within MDM.

2. MDM can actually aggravate GDPR non-compliance

MDM systems err heavily on the side of False-Negatives (HIPAA, etc.). Examples include: “MariO Smith” vs “MariA Smith” or same date-of-birth, but last digit of Tax ID off-by-one. This is because the original match algorithm requirements, such as HIPAA, forced the MDM project to intentionally err heavily on the side of false-negative match errors (not matching the same person’s records).

In other words, it was better to have millions of false-negatives than risk a single false-positive (incorrectly matching different people’s records). This means MDM pulls the compliance meter out of whack as such False-Negatives assure that you can’t erase all a customer’s records if you can’t find all their records. This violates GDPR Article 17 also known as Right to Erasure/Right to be Forgotten.

Thus IT and business executives will be blindsided by a massive GDPR risk which is that their GDPR compliance for “Subject Access” (such as “Right to Erasure”) relies on an *unreliable* MDM single customer view.

GDPR “moves the match goalposts” by now imposing huge fines on false-negatives.

For example, Right to Erasure requires deleting *all* of an individual’s records despite nickname variations, different email addresses and data quality issues. Executives must use their governance, risk and compliance (GRC) teams to audit MDM customer hubs with an urgent priority to quantify their GDPR risk by focusing on the key question: “how many MDM False-Negative errors, and are new errors being added faster than old errors are being found & fixed?”

Even without a rigorous match accuracy audit, executives can get a rough idea by simply comparing the match results between their MDM, CRM, CIF and other single customer view platforms. The degree those match results conflict can provide a rough indication of deeper match accuracy problems that were previously dismissed as only “minor mistakes.”

But now with GDPR, what people believed a minor lapse could lead to a huge financial penalty and massive negative publicity.

My go-to consultant for issues regarding the intersection of GDPR and identity resolution/matching is DataDelta whose CEO, Ed Allburn, has spent 15-plus years in MDM and now specializes in GDPR, among other contemporary MDM/DQ/matching issues. One of the data points he cites is “Nearly half of UK adults polled intend to activate new personal data rights” (OnePoll/SAS survey, May 2017).

In short, clearly GDPR is unlike the Y2K hysteria many of us collectively lived through 20 years ago. GDPR is not an event. Similar to having children, it is a commitment and responsibility for the remainder of your IT (adult) life.

For reprint and licensing requests for this article, click here.