Meld je aan voor een gratis proefversie van SAP Sales Cloud, SAP Service Cloud, SAP Marketing Cloud of SAP Commerce Cloud van 30 dagen en doe zelf praktische ervaring op. Deze proef geeft je toegang tot een vooraf geladen systeem met voorbeeldgegevens waarmee je inzicht krijgt in de oplossing.
Na je aanmelding nemen wij contact met je op om je wensen af te stemmen. We komen bij je op bezoek om uitleg te geven waarna je 30 dagen zelf de SAP-oplossing kunt ervaren.
Om aan de slag te gaan met de GRATIS PROEF vul je de onderstaande gegevens in.
With GDPR being effective for more than 2 months, we can carefully start to look what the impact was on our organizations and business processes. And see how your business is handling questions from persons requesting data removal.
Central versus Local
As mentioned in an earlier blog by my colleague Pieter, the easiest way to manage the data is have it centrally managed. However most companies have to deal with their existing infrastructure, and will have to deal with multiple systems where personal data is stored and/or processed. Of course, the size and complexity of the organization also makes an enormous difference – for international players, the challenges are much greater than for small local enterprises. On the other hand, most of the personal data is for local usage (local clients, employees) which are probably stored in a local system only and/or local entity within the global system. In real-world data removal requests, this implies that most business will have to check the several systems/environments to be sure the data removal request is handled correctly across all systems. Your business should by now have a correct working procedure where data is stored, what kind of personal data is stored in these environments, and who is the responsible person for any data information/removal requests for that environment.
Removal request process
Usually a data removal request is received by a local sales office or customer call center. Important is that these employees are well trained how to handle these requests: they should have the agreed process at hand, and forward the request to the centrally assigned person responsible within the organization responsible for GDPR related requests. This central coordinator distributes the request to the various data owners within the various systems. All these data owners must respond with the agreed time slot back to the coordinator.
Thereafter the original requester can be informed about the successful removal, probably via the central coordinator. Interesting side note is that all communication around the removal request probably will contain the information which needs to removed, so this will trigger a new trail of data (in the email- or ticketing system). Since there is a legal ground to store this data (prove that the data removal process is handled correctly) we can assume this data trail should be kept for future reference for some time.
Ad-hoc versus tooling
Before May 25, no clear insight was available about the number of removal requests that a business could expect. Now your business has two months experience, and should have a better insight in the amount of requests and the amount of work involved acting up on them. This is also the right moment to review whether your business can handle the lookup and removal requests using the standard system tools, or if it is a lot of work for each case, and some additional tooling is needed. Think e.g. of your SAP system with several custom tables where also user-related data is stored and which are not searchable by the standard SAP tooling. A custom ‘GDPR-lookup’ program might help your team in such cases.
Now after 2 months into the GDPR era, it is a good moment for business to review the amount of requests received, and see whether the internal processes to handle removal requests are sufficient and workable, or if maybe some additional tooling is needed to streamline the process.