If you are involved with data management or data governance, I am guessing you have read, or at least heard about the new European Union General Data Protection Regulations (GDPR). GDPR comes into force in May, 2018.
It’s aim is to protect the personally identifiable information (PII) of EU citizens and to give them more control over their personal data.
As the summary on the EU site states:
“The GDPR strengthens existing rights, provides for new rights and gives citizens more control over their personal data. These include:
The rules also extend the scope of the data which PII covers: “..‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person…”
Chapter IV, Article 24 states that the “controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation.” This means knowing where the PII data is and what is being done with it.
In contrast to previous legislation, these new rules apply to any company that stores and processes EU citizen data regardless of where the processing or data storage takes place.
In addition and very importantly, the potential penalties for non compliance or not reporting a data breach are significantly higher than under the previous rules.
So what has all this to do with CRM and ERP systems? Well if your organisation collects, stores or does anything else with data of a personal nature, for example relating to your customers, then it is important that you are able to meet these requirements. Also many organisations use CRM and ERP packages as their systems of record and therefore the individual’s PII is there.
Do you know what data your Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) systems have about your customers? If so can you explain why you store it and what you do with it? Will you need to erase some of it?
Of course it is likely that you will not solely be storing PII in systems of this type. It will often be found in web applications such as online stores, home-grown systems, spreadsheets and many many more. Usually finding PII here is not a huge challenge and there are some tools available to help.
If you do store PII data in your CRM and ERP systems and they are in the form of packages from SAP, Salesforce, Oracle or Microsoft and you cannot already begin to answer the questions above quickly, easily and confidently then yes, it might be time to become a little anxious.
The reason is that even before they have been customised to meet your specific requirements, these systems are very large, very complex, with very opaque data models. Add in a layer of customisation to the data model by adding or changing tables, fields etc. and you are compounding an already difficult challenge.
This means for example that finding where you are storing Social Security numbers or other pieces of key PII amongst say the 90,000+ tables in an SAP system is not a trivial task. Using normal methods it will often take days or weeks to locate the subset of tables which are relevant for each data item. Even then you may have a quite justifiable concern that not everything has been found or that the information you have located is not accurate.
Of course, in order to locate PII in any system it is commonly important to be able to identify the relevant metadata which relates to it. It might, in certain instances, be possible to profile data to get a sense of what is being stored. However in the case of many business focused systems that will not be possible unless one knows their data structures intimately and so a clear understanding of the data model, or metadata, which underpins them is critical.
If you can access and understand it your application metadata will be the best and most accurate way to identify the appropriate PII and how it is used.
In this context it is your friend and ally – as long as you can quickly and easily find and use it.
In many systems it will be a simple matter. There may be some up to date documentation, for example, or its database schema can be reverse engineered quickly with a modeling tool.
Making a friend of metadata in large packages from SAP, Oracle, Salesforce or Microsoft is more of a challenge. They are a bit prickly and present a variety of hurdles to a long lasting and fruitful relationship.
For example for most of them, their System Catalogues contain no business names or descriptions for tables and fields, and no information to tell you the relationships between tables. Trying to put together a model of PII in this way would be difficult and would probably not meet the requirements without the associated business descriptions.
Another consideration is that these vendors do not provide a usable reference data model or metadata glossary and if they did, it would not be accurate because in almost all implementations of their packages, significant customisations have been made.
Even more complexity can be added if you have more than one implementation of a system and their underlying data models are different.
To make friends with your packaged application’s valuable, but hidden metadata and get the most out of it, your best bet is to find something which understands it. Such a tool would know where it is, how to access and extract it and then how to be able to present it in such a way as to be able to search, analyse, filter and identify the those data objects relevant for PII and GDPR.
This is what our product Safyr® does. It makes it possible to find PII data in large, complex and customised packages from SAP, Oracle, Salesforce, Microsoft and others, quickly and easily.
Silwood Technology are hosting a webinar on 12th April 2017 which will help you to understand some of the data issues raised by GDPR. It will also provide some practical approaches for solving them and demonstrate how Safyr can help with packaged systems, click here to register.
I have also provided links to a couple of worked examples:
In the first we show how Safyr can be used to find tables which hold any specific type of PII data in an SAP system with over 98,000 tables, view here.
In the second example we show how to do this quickly and accurately for an Oracle JD Edwards system, view here.
The approach would work for any of the major packages supported by Safyr.
You must be registered to receive support
Please login or Register Here »
Note: The token is a unique string for each Safyr license and can be found on your product delivery instructionsAlready registered? Login here »
Enter your username
to receive your password