Is your E-Business Suite ERP ready for GDPR?

If there’s one thing that is causing a lot of stir within organisations at the moment it’s GRPR. As the date of enforcement approaches rapidly (25 May 2018), more and more data controllers are becoming increasingly nervous as to whether their Enterprise Systems can support the requirements of GDPR. Particularly, but not only

• Right to Access
• Right to be Forgotten
• Data Protection by Design and Default

Taking Oracle E-Business Suite as an example, being the most common ERP in use amongst large organizations, what processes and controls are in place already to support GDPR? Oracle recently released the following document
PRODUCT FEATURE GUIDE – EU General Data Protection Regulation (GDPR): Oracle E-Business Suite (12.x) (Doc ID 2363912.1)
which details (via the attached document) the products readiness in providing GDPR compliance. Unfortunately, most of the answers are are either Oracle is investigating options, and this is not a commitment to deliver such functionality within any time frame or It is a customer customisation”.

I have to say I’m particularly disappointed by the response, and I certainly wouldn’t want to be a Data Controller right now with 50 days to ensure my data management procedures are fully compliant, particularly given the huge fines which can be levied for breaches. It is somewhat understandable though why nothing has been done yet – simply because… it’s pretty complicated!
First we have the somewhat loose definition of what constitutes personal data, then there’s the problem of identifying the many different locations that is held in the ERP (and potentially external systems such as Data Warehouses), and then the final challenge of removing that data when requested/required. Let’s take a very simple set of fields:

• Name
• Email Address

Where in EBS 12.x might this data be held? A naive (yet partially correct) approach would be to say against the employee/user. However – let’s look a bit deeper.

select t.owner, t.table_name, c.column_name, t.num_rows, c.num_distinct   from all_tab_cols c, all_tables t  where t.owner=c.owner    and t.table_name = c.table_name    and c.column_name like '%EMAIL%ADDRESS%'    and t.num_rows > 0    and c.table_name not like 'XX%' order by t.owner, t.table_name, c.column_name; 

OWNER      TABLE_NAME                     COLUMN_NAME            NUM_ROWS NUM_DISTINCT ---------- ------------------------------ -------------------- ---------- ------------ AK         FWK_TBX_ADDRESSES              EMAIL_ADDRESS                 8            8 AK         FWK_TBX_EMPLOYEES              EMAIL_ADDRESS                 7            7 AP         AP_SUPPLIER_CONTACTS           EMAIL_ADDRESS              2412            6 AP         AP_SUPPLIER_SITES_ALL          EMAIL_ADDRESS              8052          915 APEX_04010 WWV_FLOW_FND_USER              EMAIL_ADDRESS                 7            6 APEX_05000 WWV_FLOW_FND_USER              EMAIL_ADDRESS                 8            7 APPLSYS    FND_USER                       EMAIL_ADDRESS              2531          412 APPLSYS    WF_LOCAL_ROLES                 EMAIL_ADDRESS            138700         2180 APPLSYS    WF_LOCAL_ROLES_STAGE           EMAIL_ADDRESS              2587            2 AR         HZ_CONTACT_POINTS              EMAIL_ADDRESS              5700         2112 AR         HZ_PARTIES                     EMAIL_ADDRESS             18489          890 AR         RA_CONTACTS                    EMAIL_ADDRESS                 7            0 AR         RA_SALESREPS_ALL_OLD           EMAIL_ADDRESS                 2            0 HR         PER_ALL_PEOPLE_F               EMAIL_ADDRESS              6132          777 IBY        IBY_PAYEE                      EMAIL_ADDRESS                 1            0 JTF        JTF_RS_GROUPS_B                EMAIL_ADDRESS                 2            0 JTF        JTF_RS_SALESREPS               EMAIL_ADDRESS                 3            0 PO         PO_HEADERS_ALL                 EMAIL_ADDRESS           1898790            0 PO         PO_HEADERS_ARCHIVE_ALL         EMAIL_ADDRESS            260480            0 PO         PO_HEADERS_DRAFT_ALL           EMAIL_ADDRESS               463            0 PO         PO_VENDOR_CONTACTS_OBS         EMAIL_ADDRESS              2120            6 PO         PO_VENDOR_SITES_OBS            EMAIL_ADDRESS              7426          481  

There are a significant number tables that hold an email address – and that is simply based on the field being called EMAIL ADDRESS! When we start looking for names, the list of possible fields if even bigger. And in any case, this doesn’t even scratch the surface of other places that such fields might be held.

• Flexfield Segments (Generally DFF, although in theory could also be KFF)
• Special Information Types
• Extra Information Types (EIT’s)
• Vendor Names – if using iExpenses
• Workflow Notification History
• Concurrent Request Parameters
• Hardcoded in custom code (yes, really! – even if just in the comments)
• In binary format such as on a scanned document (medical notes etc)

However trivial it may seem, data is data, and on an ERP system as complex and far reaching as E-Business Suite, simply finding this data can be extremely difficult. However you need to be able to – if a subject asks you to provide all personal information held about them, can you do that? Can you provide ALL personal information held about an individual? Can you erase it if requested? I’d be extremely surprised if most EBS customers were confident they could.

Oracle does provide some tools for analysing and categorising fields in your database – in reality these just use the data dictionary as we did above, but with regular expressions and sampling of data to gain a confidence rating (i.e. does the data in the field usually contain an “@”? If so it’s highly likely to be an email). they will get you some way but they aren’t going to help with the myriad of other potential sources of Personal Information that I identified above – and that isn’t an exhaustive list.
I’ll be keeping a close eye on note 2363912.1, however I don’t expect that we’ll see anything coming any time soon. It’s pretty much guaranteed that any effort by Oracle on GDPR compliance will be concentrated on their Cloud offerings as a priority over on-premise E-Business Suite systems. So for now it looks like the customer is on their own. Good luck everybody!