The technical implementation of your IT landscape has to be GDPR-compliant
Standard relationship between Data Protection Officer and Company
It is common knowledge by now and understood by most companies that they not only need a Data Protection Officer but also must comply with data protection regulation in general. As more specialized data protection knowledge is often not available in-house, companies tend to hire an external Data Protection Officer (DPO) who takes over this responsibility.
Any person, often only after having taken a seminar with the local Chamber of Commerce, can offer such services to companies. Hence, as the need for external Data Protection Officers was rising over the last years, the number of external officers was sharply increasing. Furthermore, a number of specialized DPO companies popped up trying to standardize and automate as much of the required tasks to be able to service a larger number of customers at an attractive price.
As data protection is often seen as a topic that is more or less preventing business instead of supporting it and hence is not overly popular in organizations, the external officers generally try to keep their involvement as low-key as possible. This generally translates in them just performing a kick-off audit, providing a data privacy policy for the webpage, and a reference book how to react when customers exercise their rights as data subjects, e.g. demanding deletion of their data or requesting information. Data Processing Agreements may be checked upon request. And that is often all that happens.
Technical Competence of Data Protection Officers
Because Data Protection Officers often know much about the law but not enough about technology, actual GDPR conformity of the technology employed is rarely verified, resulting in data protection only on paper. Companies, on the other hand, shy away from the cost of a proper data protection audit and often do not even see the point of them.
The result, all too often, is a privacy concept that is fine in theory but simply does not work in practice due to poor technical implementation.
Improper implementation of IT tools endangers GDPR compliance
Here are two examples highlighting insufficient implementation of well-intentioned privacy measures.
Case Study 1: Non-conform Use of Cookie Consent Banner
Most companies running a webpage know that they need to have a cookie consent solution requesting users for permission to store and transfer their data to certain third parties. As not to reinvent the wheel, companies mostly use a cookie consent provider to follow their legal obligation.
While the "legal" implementation is mostly standardized based on provided templates (necessary vs. marketing/additional cookies), the technical implementation is often not properly done. In many cases, the user selection either does not have any influence at all on which data is processed and transferred (the so-called placebo cookie banner), or companies have a wrong understanding of what cookie is a "necessary" one for displaying their webpage. In some cases, the refusal of cookie consent even leads to additional transfer of data, most probably due to a mistake in the technical implementation.
Case Study 2: Non-conform Use of Identity and Access Management Solution (IAM)
In today's world, most digital companies have to process personal data of their customers. To simplify processes, typically customers can sign-up and manage their personal data on their own in an online store, an e-mail client, an online seat booking system, or a member portal just to name a few. Consequently, the customer login is the heart of any customer relationship and whoever has the login credentials has access to the customer's personal data. This fact is often not well understood on board level and executives even do not know if and which Identity & Access Management tool they have in place. But it should be the core of any Data Protection initiative.
Many executives are not aware of the vulnerability of those data and use insufficient tools such as the directory function of a Content Management System (CMS). As this function was originally developed for a different purpose, even basic security standards are often not met. Bugs are often patched only with timely delay or if falls on an open-source community to solve them.
Other companies come up with their own Identity and Access Management solution but often forget that a solution needs continuous support and improvements even after the original implementation. Security audits, vulnerability tests and other security checks must be done regularly to keep the Identity & Access Management solution up to date and secure.
Finally, companies may use third party solutions to manage the personal login data of their customers. On average, this way yields the highest level of security as security expert build and update the solution continuously. However, as most solutions are provided by non-European providers, the data is all too often not stored GDPR-compliant as personal customer and data is transferred to a non-European server or to European servers of a non-European provider. This is a violation of the GDPR even though the solution might be bullet-proof in terms of technology.
Conclusion: action required
Organizations should act. Noncompliance with applicable data protection regulation is not only bad business and can result in data and reputational loss, but it can also be expensive on the legal side. Companies – and their executives and officers – may easily find themselves subject to fines and liability.
We at Engity think it is a good idea to protect personal data and comply to privacy regulation not just on paper but also in the actual technical realization; to be proactive rather than to wait for regulatory action, demands by customers, or legal action by competitors.