Achieving GDPR compliance is impossible without Data Management and Data Governance. That's a bold statement but it is borne out by any in-depth examination of the tasks necessary to achieve compliance.
Let's take a look at a few of the things that regulators require when interacting with organizations around personal data and GDPR:
- In the case of a Data Breach where personal data is involved, both the regulatory body and the impacted individuals must be informed in as timely a manner as possible, generally within 72 hours of the breach being discovered.
- European citizens who desire to be removed from an organization's data stores ("right to be forgotten") must have their data eliminated, if not relevant for other legal purposes e.g Anti money laundering.
- An understanding of the levels of risk involved via a Privacy Impact Assessment ("PIA") where the level of risk broken down by asset must be examined.
Each of these need data management in order to even take the first steps towards satisfying these requirements!
Let's examine these three requirements one by one.
When a data breach occurs, chaos ensues inside an organization. The Data Protection Officer must guide their team and hope that IT is able to rapidly track down which systems, databases or computers were exposed to hackers in a timely fashion. Unless you've already mapped out which personal data is inside those systems and know where (or whether!) they're encrypted or masked, you've got a BIG job ahead of you before you're ready to make your report to regulators and inform your customers, employees or marketing targets that their data has been exposed. Doing this "on the fly" after a breach would be difficult without a "map" of where personal data (and which personal data type!) lies within the aforementioned systems, databases and computers.
The right to be forgotten
When an EU citizen invokes their "right to be forgotten" from your organization's data stores, action needs to be taken. Even if your company has mapped out where personal data lies across the organization, you're still going to need to find that one individual that made the request - and be certain to a high degree that the data you've found is related to them. The search for the occurrences of the individual's data can either be done beforehand, again creating a "map" but this time of whose information resides where or post-request. The first approach requires more work up front but will allow you to respond quickly to requests. The second will take time and could lead to problems if regulators decide to impose stringent time limitations on how long organizations have to comply with these requests.
The Privacy Impact Assessment
Regulators expect organizations that manage personal data to know and be able to communicate where personal data is present in IT systems and to have conducted a Privacy Impact Assessment ("PIA") which ranks personal data risk exposure by system.
The Data Management implications of GPDR
The implication of just these three GDPR requirements, hardly an exhaustive list, is that you need "total control" over your data. This starts from knowing where all your data, including personal data, resides. This requires a "census" of your systems and data stores. In order to perform this census, you need to judge which data is personally identifiable information (PII) out of all the data present in your organization. This needs to be stored in a catalog, a guide if you will, of all your data. This is a core component of a branch of Data Management known as Data Governance.
How do you catalog or do a census of the personal data in your organization? You need to start with figuring out where your data is - this is a manual task unless you have strong data governance in place - part of an overarching "Data Strategy" for your company.
Most organizations don't have either a Data Strategy (only the most "mature" organizations from an IT governance usually do) or strong Data Governance in place. Some do, mostly Banks and Insurance companies who have been subject to increasingly stringent regulation over the past decade as global financial mega-crises have been followed by more contained, but still significant, crises based on credit and equity devaluation. This means that organizations in the financial sector, generally speaking, have started to get a handle on ("govern") their data as regulators that require calculation of risk levels demand not only the results of the calculations but also a clear "map" of where the data used in the calculations originated, what transformations they underwent as they moved through the systems
With the high level of complexity of the IT systems in most companies, a manual approach just isn't feasible because of the volumes of both the data itself as well as the metadata (data about data) that must be examined. Automated recognition of which type of personal data ("Tokens") has been found while searching through systems is a must. The results of this have to feed into that master catalog of where personal is present in your organization's systems in a flexible, fit for purpose system that can adapt to your organization's needs. Finally, if you intend to be ready to respond quickly to "right to be forgotten requests", the map of whose data sits where needs to be prepared up front by creating a Master Data catalog of where each individual's personal data resides.
Organizations are quickly coming up to speed in terms of knowledge of what GDPR is going to require of them when it begins to be enforced on the 25th of May 2018. Many, however, are being slow off the mark in beginning their implementation. With just over a year left, the complexity and broad distribution (even unintended) of personal data across even medium sized organizations data stores is going to have many companies racing against time as the deadline becomes closer and closer. Non-compliance is not an option given the fines of up to 20.000.000 euro or 4% of global revenue. Data Management, Data Governance and Master Data Management (MDM) are key components to any approach that will lead to compliance. If you're not actively working towards compliance now, you need to be!
Pingback: Is data science keep pace with product designers needs?
Pingback: Compliance: Is a solid data management strategy and platform enough? - The Data Roundtable
Pingback: General Data Protection Regulation GDPR: What’s the story? - Hidden Insights
Pingback: Whenever there is data, GDPR comes in play - Bright Data
I see similarities with rules & regulations on hygiene - with GDPR as the rule book ondata-hygiene, safety & security.
I wonder if insurance companies have already cottoned on to this, as companies wili want to legaly protect themselves against claims of non-compliancy with GDPR.
Layers will have a field day with this.