Up to top

How to find where Personal Data is stored in JD Edwards for GDPR

By Roland Bullivant | 10 Mar 2017

Categories: Data Governance, Enterprise Metadata Management

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.

JD Edwards example for GDPR PII 1

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:

JDE PII worked example 2

…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 –

JDE PII worked example 3

…and now we get these results:

JDE PII worked example 4

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:

JDE PII worked example 5

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:

JDE PII worked example 6

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:

JDE PII data worked example 7

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

SIGN UP FOR SILWOOD NEWS »
Close

CUSTOMER SUPPORT

You must be registered to receive support
Please login or Register Here »


Forgot Password? Remember me

CUSTOMER REGISTRATION

Note: The token is a unique string for each Safyr license and can be found on your product delivery instructions

Already registered? Login here »

PASSWORD RESET

Enter your username
to receive your password

Login here »

Welcome to Silwood Technology. We use cookies to enhance your browsing experience. Learn more OK