Beside the tsunami of changed privacy policies, (hopefully) behind the scenes, some things have changed for the better. Let’s take a look at some of the main pillars of GDPR again.
- Assignment of a DPA (Data Protection Officer).
- Data protection – Personal data should be protected from theft and abuse.
- Breach Notification – In case of unlawful use of data (like theft) this must be reported to the respective owners.
- Data portability – Personal data should be ‘portable’, meaning it is transferable to another processor.
- Right to Access – Personal data should be made available to the owner if requested.
- Deletion by default – Personal data should not be stored longer than reasonably required for the cause it was obtained.
- Right to be forgotten – Personal data should be removed on request unless it is reasonably required (for instance by law) to keep them.
So are they all now in place, or should we still expect some privacy breaches? My guess would be the latter, but let’s also take a look at how companies can avoid them.
Protecting personal data from theft or abuse is one of the most important aspects of GDPR. As this was already quite high on the agenda of most companies, I would recommend companies to continue with their efforts on network security, access control, data encryption etc. More and more we will see multi-factor authentication as a result of these efforts.
Data portability and Right to Access
These GDPR rights are both covered by the ability to extract personal (and related) data from your systems. Depending on the company’s architectural decisions made in the past decade, this can be very difficult.
My advice (as a CRM consultant) would be to centralise customer data management to the extent where customer data is managed by a single core, in or close to the financial core and distributed to other systems only where needed. The more complex the landscape, the more complex it is to extract all data.
Deletion by default and on request
Similar to the previous topic, data archiving and deletion can be a tough one in complex system landscapes. In general, it must be centrally managed, but as some systems in the landscape might have ‘veto-rights’ where the situation in that system requires the data to stay, this can lead to extremely complex and costly interfaces, especially in a highly decentralised landscape.
So where are we now?
To conclude this, as I am not able to ‘take a look in the kitchens’ of all companies, but based on my experience I would expect that great efforts have been done, mostly cosmetic (such as privacy policies), but fully automated archiving and deletion of personal data in complex decentralised landscapes is probably still on the roadmap.
Centralisation vs Decentralisation vs Distribution in system landscapes generally follows trends. The wish for agility trends to decentralisation and Distribution, where fast implementation can take place and the system can easily be moulded to fit the specific requirements, while the wish for control trends to centralisation, where data is stored in a single place, and can easily be updated and managed.
The new challenges introduced by GDPR in my opinion require an even more critical view on system landscapes. As system architects, we should consider that each box we draw in our architectural schema introduces complexity. Personally, I prefer a single point of truth and avoid the initially appealing fast implementation of (mostly SaaS) software for specific tasks. Centralise where you can!
If you have questions, feel free to ask.