GDPR in Digital World – How to Go About It?
GDPR - the most important principles and impacts. Your web integrator needs to know it well.
While talking other topics, we aimed to capture the essence of digital transformation, and to show the ideal state we aspire to be in (and which we are more or less already in) in our projects. Today’s article is going to outline our approach to implementation and give useful recommendations, which you can use. The text is primarily constituted as a set of suggestions based on consultations with both business colleagues and external experts.
Let me make a " disclaimer " - this article definitely cannot answer all of your GDPR questions. This issue is overly complex, but I will try to cover at least topics that are more or less relevant to all. If I miss something, feel free to let me know and I will be happy to try and add some information.
Where to Start?
To correctly implement guidelines, which will ensure your business compliance with GDPR you, need to accurately map how you work with personal data. GDPR works with concepts such as "data controller" and "data processor". For the purpose of this article I will deal with both roles, which may concern a larger part of readers (I shall not consider a "data recipient", as that regards primarily the public sector).
I focus here on the client data processing, as most of these facts are easily transferable to internal employee data. GDPR extends the concept of personal data (the directive uses the term "subject data") to e-mail addresses, IP addresses, photo records, etc., as well as it defines "sensitive data" such as biometric records (subject to a stricter regime). Each of these data must also have a clearly defined agenda, under which it is processed, and that's why you have to focus on the procedural description of how to handle this information - take it as an exercise similar to obtaining ISO certification.
Although the sentences above may sound like we first need to look at the data from which we try to deduce what is needed, the process should actually go the other way round. You want to define the agendas you have to deal with within your application / business / day-to-day operations and then clearly define the data that will be necessary to work with them. GDPR contains the right of the person to know what data is stored about them, and can request data edit or deletion, if the data is not necessary for the purpose it was collected for. Similarly to software design, where technology has a purpose, this principle also applies to personal data and thus the focal point needs to be such a purpose. So, focus on it with due attention. An example of this can be an online credit calculator, serving as the basis for concluding a loan contract, where a financial institution needs to meet requirement of "prudence". This is why they need to know the name, surname, place of residence, but also the date of birth and social security number, in order to enable submission for scoring as part of the registry of debtors check. On the other hand, no such extent of information gathering is needed in case of a simple inquiry form, where basic identification data and contact details will suffice. Yet, both processes need to comply with the relevant procedural requirements.
What Does the User Have to Give Consent to?
Before you collect any data, you have to make sure to correctly advise the user of your intention to use his data. A very important and at the same time difficult to grasp point of GDPR is the duty to clearly and comprehensibly inform users about the need to process personal data, whatever that means. One of the ideas is to shorten user terms and conditions (of the popular EULA license that nobody ever reads), but that's all we can say for this advice. That is why it is necessary to clearly define internal processes of data processing, and to clearly publish it in each case. Concerned persons should be advised to what extent their personal data will be processed, for what purpose, for whom, for how long and how it will be handled. Therefore, the user should be clear about when he can expect his data to no longer be recorded for the particular reason intended. The goal is clear - to provide users with information they we can orientate in, that is understandable, and that is not a wall text of 100+ pages. You will never get the user to study everything carefully, but you can try not to discourage him in 2 seconds.
Granting the consent itself is another tricky topic. Consent as such must always be a voluntary, concrete, informed and unambiguous manifestation of free will. As a rule of thumb, you can use a simplified view of when it is required, and when not. In case of personal data based on law (including statutory exceptions and bans) or a justified legitimate interest of an administrator (CRM, contractual relationships, etc.) consent is not required. In other cases it is.
As I have outlined earlier, there are also categories of sensitive personal data (biometrics, signature, etc.), which require a so-called explicit consent to processing. To illustrate, consider the above inquiry form where the user fills in ‘regular’ data - for which suffices the currently commonly used phrase " I hereby give my consent to the processing of my personal data...", or a it may just be a note saying “by submitting this form, you consent to the processing of your personal data” (this also applies to volunteered data, such as, a mobile phone number filled in even when not required). Although when you need explicit user activity we get into a different situation. No opt-out access is possible in pre-filled checkboxes; you need a clear confirmation of consent, for example, by ticking a box. Do not forget to record this kind of information, including the timestamp (i.e., John Smith gave his consent on 8th February, 2018, which is why his data will be stored for say 15 years). And if you are not an institution with the necessary legal denomination, you can never require, let alone further process, data on faith, ethnicity, health state etc. The first case is called unambiguous consent, while the second explicit consent. If you don’t see the difference at the first glance, I don’t blame you. But don’t despair ... The tenth time you will have read it you will have come to terms with it, though you will probably still not understand.
Pseudonymized and Anonymized Data
At this point, you have already decided what data you want to collect, and you have clearly explained to users how you handle it. Yet, this fun part still far from being over, and you have to decide how to actually store data. Data anonymization is certainly not new, but then there is also another GDPR pillar, the concept of "pseudonymization", which needs to be reflected here too. In the following considerations, I will primarily work with relational database models, simply as outside their world I have not yet been able to model the situation in my mind. Pseudonymization itself is nothing terribly worrying and complex - for new clients. It is splitting "user data" and "personal data". Personal data is defined by the directive (i.e. "Richard Bacon, date of birth 5th June 1967"); and in user's data it would be something as "has a mortgage contract with maturity of 15 years, fixation of 5 years, interest 2.8%". The goal is to be able to "conceal" the user's personal identity at the data level and store it in the database in a way where you are be able to simply link it thanks to a general key – hence relational databases.
Thanks to data pseudonymization, there is a rapid change in the architectural concept of user data processing. While so far we tried to link everything to unique keys such as email address, social security number (yes, they can be two same ones), etc., now we get a completely different tool, the abstract key that will not only be the unique identifier of a user (Richard Bacon will have an ID no. 189743), but it will also work for the user in, say, a product portfolio (189743 user has a mortgage, consumer loan and a current account). To link purely anonymized data (for example, general Google Analytics data or similar tools), you will just know that you have a Google user with a gid6575 ID that is somehow moving around your site. Then, sooner or later, he will log in to your client interface, where you will be able to tell this phantom gid6575 actually has ID no. 189743, which is our dear Richard, and now you got all the facts together. Such a data split will make the data seem unclear at first glance as in what belongs to whom, but at the same time through simple database queries you can link them again and work with them further.
Splitting is Cool, but Why?
Here we come to one of the key points of GDPR, and client rights to further data processing, one of which is also the "right to erasure / right to be forgotten". Every end user can request both from the administrator and the personal data processor a complete list of the agendas his or her personal data is tied with and which must be issued to him without delay and free of charge, or for a fee of "purposefully used costs", such as fees for file storage, etc. (exception is excessive abuse of this right, while the time span for change is not specified). Users can also request to get the data delivered to a third-party in a machine-readable format to speed up their transmission. Although, I have thought about many possible ways to use this scenario, the only thing I have been able to come up with is that this would work as a whip for the government itself, as I have never encountered a similar problem in the private sector. An absolute novelty is represented by the said law to be erased, since similar requests have been dealt with only through applying the user "invalidating" attribute in the system, but sometimes his record was still there - which is no longer sufficient. But there are cases when erasure should not occur, for example, if the law maintains prescribes certain data.
If you keep logically split data, you will be able to modify only the "link" record outlined above and the user's personal data itself. However, thanks to this split, you will still be able to use "client" data for statistical purposes, modelling and hypothesis creation, which feels like the biggest threat for everyone today. Historical data is the ultimate basis for product portfolio maintenance and modification, behavioural modelling, statistical evaluation of success, etc. However, to make it not so simple, GDPR addresses the issue of "profiling", which will most likely be solved already at the level of web browsers. End users will be able to not be automatically identified without their knowledge and consent. In addition, it may be a bit of a solace that information on deceased persons is excluded from GDPR scope, which makes it a little easier (though not very much).
What is Next?
As I mentioned at the beginning, this article is of a very limited scope. I have not mentioned at all when and why to designate a "Data Protection Officer ". As to tighten data management for hardware, the directive also prescribes a duty to report all security incidents in personal data databases within 72 hours, in a process considering and describing the risks of leakage of personal data, and many other aspects. Alas, the issue of GDPR is as extensive as very few regulations I had the honour to review.
As I mentioned earlier, our company is still in the midst of implementing internal standards to meet the GDPR, and we are sure it won’t be over by the end of 2018 – i.e. until the whole system of organizational and technical measures gets settled. However, I hope the above lines provide at least a basic insight into what you'll have to manage in next 4 months, to be "GDPR compliant". It is not much of a surprise that the European Union allows certification as to meet GDPR requirements, which has resulted in literal popping up of various certification authorities. But, I expect that, like ISO-9001 certification, it will do more harm than good in a year or two.
But what I definitely recommend is a lengthy, but a very interesting study of the EU-wide directive itself, which can be found here: http://eur-lex.europa.eu/legal-content/CS/TXT/?uri=CELEX%3A32016R0679
The so-called Working Group 29 focuses on explaining some of the somewhat vague topics of the directive, so you can also get inspiration here: http://ec.europa.eu/justice/data-protection/article-29/index_en.htm
If you are not interested in reading the nearly 90 pages of the General Regulation, check at least an amendment to the law that will be very relevant to us: https://apps.odok.cz/veklep-detail?pid=KORNAQCDZPW5
In case you don’t like even that, I recommend at least a short list of the Office for Personal Data Protection about what the GDPR is about: https://www.uoou.cz/zakladni-prirucka-k-gdpr/ds-4744/archiv=0&p1=3938
And finally, for lovers of standard hard copy editions, one more good publication at the end (though long, with nearly 500 pages) of Wolters Publishers Kluwer - GDPR / General Regulation on the Protection of Personal Data. The book is long, but it tries to interpret the individual passages of the regulation in quite a human language.
I wish everyone good luck, energy and strong nerves in the upcoming challenging months. And to cheer you up a bit, next time we shall change the topic a little, to talk Customer Journeys and Human Cantered Design, which will take us beyond regulatory duties into intriguing and more creative understanding of our customers.