Introduction to the GDPR personal data challenge
Working out where computer systems store Personal Data (PD) data that needs to be reviewed in the context of compliance with the General Data Protection Regulation (GDPR) is a challenge in any environment.
However, it presents even more of a problem where the PII data is in one or more of the big Application Packages from Oracle, SAP, Salesforce or Microsoft.
The following example describes how to use our software Safyr® to ‘scope’ the potential tables that store ‘relevant’ data in a JD Edwards system. In this case we are using ‘Date of Birth’ as the piece of data as an example.
Of course, most JD Edwards systems have been customised to some degree. Safyr ensures that you are working with the system as implemented at your organisation by extracting the metadata from your own installation, including those customisations.
WorkED Example: finding personal Data in JD edwards
We can do a search for definitions of ‘Date of Birth’ in what Safyr® calls a Data Element. A Data Element is a definition of a field, independent of its place in a table.
This gives us 6 hits.
We need to use our common sense to decide if each of these is relevant to our requirement. The last one, for example (Secure Date of Birth Flag) is not actually a date but a flag. In fact the definition of this field:
…shows it is a flag to indicate if a date of birth needs to be secured.
So that probably does not class as the kind of ‘GDPR-relevant’ information we want. For the other matches, we can see which Tables ‘use’ this Data Element –
…and now we get these results:
Now we can add these to what Safyr calls a ‘Subject Area’ – this is like a folder where we can group tables we want to remember:
We could do this for the other Data Elements until we had assembled a list of all the Tables with a ‘Data of Birth’ (in our system, this results in only 1 more table being added to the Subject Area).
We can now review these tables in more detail:
Notice the Row Count – this is the number of Rows in each table. There may be no point considering Tables that contain no data for our GDPR exercise. Filtering these out gives:
So there are 8 tables (in our JD Edwards system) containing the Personal Data type ‘Date of Birth’. This whole exercise has taken about 5 minutes. These results can then be shared with other tools and technologies to support a GDPR initiative.
We could do something similar for Bank Details, Credit Card Numbers……and we’d then have a very good handle on those tables that contain the kind of data we need to think about for GDPR.