GDPR came into play 3 months ago, but companies are still struggling. One of the main concerns is related to the systems and databases where they hold customer data – be it personal, operational or experience data.
A significant number of Oracle Service Cloud (OSvC) administrators and super-users have recently contacted me, asking what actions to take to ensure they are GDPR-compliant. Like so many other technology vendors, Oracle is developing the platform.
Last week the OSvC product/development teams at Oracle and the OSvC All Stars got together to review the features available, look at the roadmap, and discuss what other solutions or developments could help the companies who use OSvC.
The truth is that the features that will help comply with GDPR are being released since 17C (Aug 2017), and there is a very busy roadmap, with other features coming.
1. The Bulk Delete API was released in 17C for Incident and Opportunity objects, expanded in 17D for Contacts and Custom objects, and expanded further in 18A for Accounts and Organisation objects. It allows you to efficiently delete large data sets, having the flexibility to select the data to delete using ROQL queries.
2. Until now, when you created a test environment, you would get a clone of your instance with all your data. The difference is that the emails had a .invalid suffix. Having real/production data in a test environment could be a GDPR breach. Since release 18B it is possible for administrators to create a test instance without standard transactional data.
3. Various enhancements to the Audit Log are going to be released in the next few versions of OSvC. 18C provides the ability to capture viewing of Contact records, as well as report downloads. 18D and 19A will introduce Field Level Audit Logs on individual attributes of the Contact object. And to answer your questions re. space, the Audit Logs will be written to a secondary store, unloading the primary database.
4. A Bulk Data Extract capability will be available from release 18D, for Incident and related sub-objects. This would be supported by an asynchronous REST API that will allow you to extract large volumes of data, into compressed .csv files. Enabling organisations to archive data that is old or not needed, but needs to be retained.
5. Deleting OSvC interfaces was something that companies struggled with, as it usually went wrong, impacting other interfaces. Since 18C this capability was enhanced by Oracle, allowing you to contact Customer Care and request interface deletion, to reduce database size.
6. The Data Lifecycle Policies user interface is available since release 18A, and allows you to easily manage data lifecycle policies for objects. In 18A it supported a limited number of transactional objects, 18B brought it to Incident archive/purge, and 18C for Custom Objects and indexed system attributes on Incident and Contact objects.
7. Finally, in release 18C you can redact or anonymise sensitive information in Incident Threads.
Thanks for your detailed information.
Thanks,
Mohan
Great info, Yes a lot of organizations are struggling still because of the unclear limits.
Thanks a lot.