Preparing for GDPR: EU Regulations Impacting Your Master Data Management

Preparing for GDPR: Master Data Management (MDM)
Photo Credit: Freddie Salmen

If you are amongst the thousands of companies that must comply with GDPR, you might consider addressing MDM and GDPR simultaneously to save both time and money.  If you aren’t sure whether you need to comply with GDPR, there are three critical questions that every US company should be asking about GDPR compliance.

MDM involves identifying your customer data, determining who accesses that data and then creating a governance program. However, an MDM system implementation does not automatically make you GDPR-compliant. For example, GDPR’s definition of personal data includes non-master data such as online behaviors.  The good news is that a lot of the work you are doing for MDM is the same work you will need to do to ensure GDPR compliance. So if you are already involved in an MDM project, going one step further to architect for specific GDPR requirements—such as “the right to be forgotten”—can be far easier than addressing this issue independently from the ground up.

Architecting MDM for GDPR Incorporation

So how do you architect MDM for GDPR? Let’s take a quick look at some of the questions addressed in each type of project—both internal and external systems—and how these projects align.

Master Data Management (MDM)

In the case of MDM, you must consider the following:

  • Where is your customer data located today?
  • Where is it being updated?
  • Who or what has access to the data?
  • Do you have a single source of the truth?
  • How is the data being secured?

General Data Protection Regulation (GDPR)

In the case of GDPR, you must consider all of the questions involved in MDM andothers, including the following:

  • For what purpose are your systems using the data?
  • What steps are required to delete the data if necessary?
  • What steps are required to make the data portable if necessary?
  • What steps are required to provide human intervention in decision processes that are typically based on algorithms?

As you can see, both projects seek to answer several of the same questions about who is using your data and where that data is used and/or replicated. In fact, nearly every MDM-related measure is something you’ll need to address in an effort to ensure GDPR compliance. So this leaves many wondering about what additional work is involved in architecting for GDPR compliance. Most companies must architect a tracking system to determine how and why a customer’s personal data is being used. They also need to architect measures to accommodate the “right to be forgotten” and the “right to data portability and the “right to explanation”.”

Architecting for GDPR’s “right to be forgotten” entails the following considerations:

  • You must understand your data architecture, where data exists throughout the organization and where the data is primarily managed/processed within your organization.
  • You must understand traceability; that is, where entities and attributes travel to other service providers, archives, users, etc. This includes:
    • The flow and movement of data. You will need to map out your data flow to understand how it propagates within your organization and outside of your organization.
    • Where the data originates and what processes are used to alter, update and store this information.
    • The data propagation system currently in place. For instance, one entry may be disbursed to 10 different systems, creating an information-sharing network of sorts.

Architecting for GDPR’s “right to data portability” is covered under a seemingly simple directive that belies potentially complex requirements. These requirements state that, “Where technically feasible, the data subject should have the right to have the personal data transmitted directly from one controller to another.” Some of the details, such as the exact format and mechanism for data transmission—and the need to encrypt the data—have thus far been decided by the companies that are required to be GDPR-compliant. Even if the EU has yet to codify the exact methods, you’ll need to be ready to pull and transmit the data in question when the requests start flowing into your offices. Furthermore, your architecture will need to evolve as technology evolves because the GDPR requires responses “with due regard for the state of the art”.

With MDM, your master data is used as a primary data source to drive other systems. This makes it easier to handle data lineage/sourcing and traceability—that is, who is using your data now, who is using it downstream and who is getting backfeeds—since these issues are central to GDPR. In both project types, you must understand the total data lifecycle.

At Primitive Logic, we have more than 30 years of experience helping our clients with digital business transformations, enterprise data management, system security, and compliance.  Addressing GDPR compliance has the added benefit of making your data more valuable to your business.  We are here to answer any questions that may arise during this complex and potentially stressful process. If you are involved in one of these projects in the near future, we invite you to reach out to the team at Primitive Logic.

Follow Jill Reber on Twitter at @PrimitiveCEO.

Jill Reber, August 2017