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:
- 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!