GDPR and ePrivacy: Compliance Nightmares for Open-Source Projects?
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Konstantinidis, Giannis
While the EU's GDPR and ePrivacy (now undergoing reform) provide people with additional control over their personal data, they do expect organisations to perform significant adjustments to their processes and workflows and to implement particular measures. Most open-source projects make no exception and are consequently expected to comply with the extensive legal and technical requirements; not to forget software developers, engineers and technologists who are additionally tasked with implementing privacy-enhancing mechanisms. The participants of this session will explore the fundamental requirements of the GDPR and the current ePrivacy Directive and will also discover the important connections between the GDPR and the upcoming ePrivacy Regulation. More importantly, they will be presented with the most frequent Do's and Don'ts of the post-GDPR era. Last but not least, the session will highlight and showcase some of the best practices adopted by the wider free and open-source software community and provide an opportunity to brainstorm about the next steps to further improve compliance.
 Welcome to the second day of FOSCON 2019 or FOSCON 14. I hope it's a great that I do this in English because the talk will be in English. I hope you had a good night and are fresh and are very interested to hear something about privacy concerns because GDPR hit us last year and there's a big field that a lot of people are scared about even if they consider privacy as a good thing. But to be compliance can be a nightmare or not. This will be the talk that Janice is giving you. GDPR and ePrivacy compliance nightmare for open source projects because there's, you know, that open source projects are much harder to control than other projects in a lot of directions because you don't have this very strong structure. Well, Janice is in the field of open source stuff since a lot of years. He worked in context of Mozilla for six years and was with Fedora for nine years, which sounds like a very long experience in the area and I'm very happy to have him here. Have fun. Thank you. Good and tug. And thank you for coming despite it's still quite early in the morning. In this presentation, I'm going to provide an in-depth introduction to the most important, to the most fundamental organizational and processing requirements of the GDPR, which generally isn't a very easy thing to do as the GDPR is one of the most complex pieces of EU legislation. It does span across 88 pages and includes 99 articles. So it would be impossible to cover every single aspect of the GDPR. We would be focusing on the key aspects instead. In addition, I will be doing a brief comparison between the main focus areas of the GDPR and the current privacy directive and I will also be mentioning some important things about the upcoming E-Privacy Regulation, which is expected in the coming years, only in the coming years. So let's begin with a brief introduction to the GDPR. The GDPR was published in its finalized form in April 2016 and it became fully applicable from the 25th of May 2018 onwards. There was therefore a two years grace period under which we would have expected most organizations, at least the colossal organizations, to be fully compliant with the requirements of the regulation. However, it's been more than one year since the regulation was put into full effect and a lot of organizations, both colossal organizations and also smaller entities, have no idea what their legal obligations are and they haven't performed the consequent changes to their business activities and processes. The GDPR replaces the previous directive for privacy protection, for data protection, which was directive 95-46, which I believe was no longer adequate if we take into account the vast advancements we have noticed in the ICT world the last 20 to 30 years. While the GDPR is a very good thing for EU data subjects as it empowers them with additional controls over their personal data and it also provides the harmonization of data protection laws across the European Union, the GDPR is a regulation which means that it's legally binding and applicable to all 28 EU member states. Maybe it's 27 now, who knows what's going to happen in the coming months. Whereas EU directives are, let's say, guidelines that need to be followed by EU member states and then also need to be transposed into national laws. So while the GDPR has some benefits for the users for the data subjects and also provides us with a harmonization of data protection laws across the European Union, it still brings a lot of nightmares to smaller organizations and especially open source projects. On the one hand, we have colossal companies who have lots of money and resources and can probably afford if they want to determine their legal obligations and perform the subsequent changes to their processes. And on the other side, we have smaller entities, we have small and medium sized enterprises, open source projects who are still supposed to comply with extensive legal and technical requirements but are, however, lacking the proper resources. And another thing, of course, is increasing awareness around privacy data protection matters so that at least we should proceed with the minimum changes that are required, with the bare minimum changes. In any case, the GDPR may impose harsh penalties to perpetrators who are found to be incompliant which can go as high as 20 million euros or it could equal to amounts as high as 4% of the annual global turnover of a company. So Article 4 of the GDPR provides us with the essential terminology that is being used throughout the legal text of the GDPR. Personal data is any kind of information that can be correlated, that can be linked to an identifiable natural living person. Names, home addresses, email addresses, mobile phone numbers, phone numbers generally. Even location data, for example, when we have mobile phones that transmit the GPS coordinates of their users, all those examples constitute personal data. In addition to the generic form of personal data, there are also the special categories of personal data which can be, for example, medical records, biometric data, genetic data, information in trade unions, political opinions, religious beliefs, and so on and so forth. And the GDPR has additional safeguards for the processing of special categories of personal data. Now, processing is an umbrella term that refers to any kind of operation or set of operations that apply to particular pieces or even sets of personal data. The collection of personal data, the recording of personal data, the alternation, the modification, the destruction, the deletion, everything pretty much, every possible action that can be performed on data and on sets of data constitutes processing. The GDPR has three main categories of actors that are referenced throughout the entire legal text. Data subjects are the natural living persons, we are data subjects. They are the natural living persons to who personal data refer. Data controllers identify the purposes and means of data processing and data processors, like the term suggests, process data on behalf of controllers. Now in order to help make this a bit easier to understand, imagine there is a boat and inside the boat there is the captain of the boat who is in the context, who would be in the context of the GDPR, the data controller, he or she gives orders to the crew members and then you have the crew members who execute the orders of their captain and the crew members would be the data processors. However, in the context of the GDPR, an entity can assume both the roles of a controller and the processor at the same time, depends on the case. And there are also some cases when two or more controllers can jointly determine the purposes and means of data processing and therefore we call them joint controllers. More information on the classification of controllers and processors later on. The GDPR admittedly has a very wide scope of application. There is the material scope which is described by article two and it pretty much does not make any distinction between automated and non-automated processing. So even if we take pieces of paper and pencils and write down personal data manually, it's still considered to be processing. The good thing about the material scope is that it provides a few exemptions. For example, if data processing activities are done for purely personal reasons, let's say in the course of household activities, then such activities are exempted from the scope of application of the GDPR. So it's definitely okay to maintain address books to have your contacts without the need of obtaining consent or generally speaking adhering to the extensive requirements of the GDPR as such an activity is accepted from the scope of application of the GDPR. And in addition to the material scope, there is the territorial scope which involves establishments within the EU who subsequently process personal data relating to EU residents. And in addition, it can also include establishments outside of the EU as long as they provide goods or services to people, to data subjects within the EU regardless of whether payment is required. And this is where a lot of open source projects can potentially fall into the scope of application of the GDPR, open source projects that are established outside of the EU, that is. So moving on. Now the organizational requirements, here are some of the most fundamental organizational requirements which apply, let's say, to the whole organizational structure of an entity that processes personal data. There are the principles of data protection by design and by default under article 25, which pretty much tells us that controllers and processors should handle personal data and they should respect, they should protect personal data right from the start and they should also apply the highest levels of available protection. Article 30 obliges both controllers and processors to maintain records of processing activities. More information on maintaining records is about to follow. Article 32 titled security of processing obliges both controllers and processors to implement appropriate technical and organizational measures to ensure the ongoing confidentiality, integrity and availability of personal data. And speaking, the GDPR does not recommend particular measures with a few exceptions, for example the encryption and pseudonymization of personal data, but generally it's not being very specific with regards to the actual measures that need to be implemented. It's up to the entities, it's up to the organizations to determine what needs to be done and what needs to be avoided. If personal bridge is okay, the controller is supposed to notify the respective data protection authorities within 72 hours if possible from the moment that a particular database has been observed. This is a requirement by article 33 and there is also article 34, which in some cases may oblige the controller to additionally notify the affected data subjects. Generally, when it comes to articles 33 and 34, there are specific conditions that apply. In some cases, for example, when there is a systematic monitoring of data subjects on a large scale, for example, when there are CCTV cameras in the premises of a company, etc., or for example, when there is processing of sensitive personal data, the special categories of personal data we talked about earlier, then the controller might be obliged to perform an additional assessment called the data protection impact assessment. There are methodologies out there for conducting such an assessment. It is my personal estimation that most, I'm not saying all open source projects, it is my personal estimation that most open source projects do not need to perform data protection impact assessments. Don't take this for granted, it really depends from case to case, depends what kind of processing activities are actually taking place. In some other cases, there might also be the need to appoint a person called the data protection officer who oversees all the data processing activities of the organization that he or she represents and generally provides recommendations. The last two obligations are covered by articles 35 and 37, respectively. Again, don't take my word for granted, it really depends from case to case, whether an entity needs to perform DPAs and also needs to appoint DPOs. Article 5 provides us with the principles behind the lawful processing of personal data. It does say that personal data need to be processed in a lawful, fair and transparent way, which if you ask me, it's something very unclear. What does fairness mean? But anyways, there are some principles such as the principle of purpose limitation, which asks that personal data are processed for specific and legitimate purposes and they are not further processed for additional purposes which are incompatible with the original purposes they were initially collected for. The data minimization principle tells us that we should collect the minimum amount of personal data needed for a particular and legitimate purpose. And we should not be collecting additional pieces of personal information if they are not needed for an actual purpose. Accuracy tells us that we should make sure that personal data are accurate and up to date. Storage limitation sets an expiration date, let's say, on sets of personal data and we should be discarding sets of personal data if they no longer serve any purpose. And as we have already seen before, controllers and processors need to ensure the ongoing integrity and confidentiality of personal data, which is also a requirement under Article 32, the technical and organizational measures we talked about. Article 6 establishes six different legal basis under which processing can be considered to be lawful. The most common of them all is perhaps consent. We have users that sign up for a service, that sign up for a website, for an account, and most of the times there's a sign up form, there is a check box always, they tick that check box and indicate that they consent to the processing of their personal information, their personal data, but consent is only one out of six possible legal basis that an organization can rely on. So there is a wrong misconception that consent is the only way for the lawful processing of personal data, which is a very wrong misconception. There might be a contract between two parties or a contract among more than two parties and this contract could ideally include clauses about data processing activities and also sections about the protection of personal data and therefore a contract may be able to govern the data protection, the data processing activities that take place. An entity, an organization might be processing personal data because it has to comply with illegal obligation, which doesn't affect a lot of projects, doesn't concern a lot of open source projects. Processing may also be lawful in order to protect the vital interests of a data subject whenever a data subject is unable to freely provide consent. An organization might be performing public tasks such as the administration of justice, which doesn't concern all open source projects, I would say either, not just most, but all open source projects, but again, don't take everything for granted. And last but not least, there is the principle, the legal justification of legitimate purposes. Legitimate purposes are perhaps the most flexible legal base of them all and organizations can rely on legitimate purposes for a variety of reasons as long as they do it in a reliable and justified manner. For example, keeping security logs can be done without the consent of data subjects because entities, organizations, that process personal data, have an obligation under article 232 called the security of processing to implement the technical and organizational measures and therefore can rely on legitimate interests. It's in their legitimate interests to protect their online infrastructure. It would also be impossible to request consent. It would be very hard, not impossible, but very hard to request consent from users in order to store IP addresses. It would be chaotic, it could be chaotic if you think about it. So what we should keep from this is that consent is not the only way of processing personal data in a legitimate way. There are six legal bases in total that we can consider as long as data processing activities are done in a lawful manner and are meanwhile compatible with the rest of the requirements of the GDPR. Data subjects are empowered with a set of rights. A lot of these principles already existed in the previous data protection directive but are now further reinforced with the GDPR. When communicating with controllers and processors, data subjects should receive transparent information using easy-to-understand language, plain English, plain German, and so on and so forth without the legal jargon, without many technical details so that everybody can understand what's going on without the need to be technical literate or to be knowledgeable about legal procedures, legal jargon. So data subjects have the right of access, which isn't just about receiving a list and descriptions of the personal data that an organization holds on their behalf. It's about receiving actual copies of their personal data. And yesterday I read a German court. I do not remember which court exactly actually reinforced the idea of having decided that, yes, data subjects should receive an exact copy and not just lists with descriptions. So I believe that this was a very important decision and it's going to play an important role in the future exercising of the rights of data subjects. The right of rectification provides data subjects with the possibility of requesting a change, a correction of their personal data in case something is not up to date or is not accurate. Data subjects have the right to erasure, also linked to the right to be forgotten, which is in turn linked to the Google Spain case if you are aware of the Google Spain case, which I believe was a very important milestone for the establishment of the right to be forgotten. So pretty much under specific conditions you have the right to ask for the deletion of all your personal data from a specific organization. Again, there are a few exceptions to this, depends on the case. In some cases, data subjects may also have the right to request the restriction of processing of their personal data and also to object to the further processing of their personal data. And last but not least, and very importantly, it's very important nowadays because we have seen the rise of cloud computing, data subjects have the right to data portability. Pretty much controllers are expected to be able to export personal data under machine readable formats so that users, so that data subjects can freely move from one service provider to another service provider. So this is visualization of the organizational and processing requirements we have talked about in the previous slides. I have already actually, somebody else actually uploaded the slides for me on the website of Frostcon. Everything is available at Creative Commons. So you are free to take in-depth looks later on. Now a few things about compliance assessment. We talked about maintaining records of processing activities. What do they mean? There are a few guidelines out there. For example, there are some guidelines set by the Working Party 29. And generally speaking, here are a few things that you need to consider when creating and maintaining records of processing activities. First of all, it's for sure that you need to provide a friendly name for the processing activity which is involved. Just a name that can help you quickly identify for which processing activity you are talking about. You need to specify the controller or the controllers that are involved with this particular processing activity. Likewise, you need to do the same for processors, for any processors. Your description should mention what kind of data processing activities are taking place, exactly what is done, what kind of activities are performed on the sets of data. It should briefly mention the data flows within the infrastructure of your company. It should mention who has access to those particular sets of data. It should also justify why those particular people have access to the sets of data. And it should mention also the storage method. Where are the data sets being stored? Is it inside the file cabinet? Is it in your online infrastructure, your offline digital infrastructure? Where is it located? Does it use a combination of storage methods? You have to be specific about where the data is stored and what happens to the personal data inside your organization. Also, what kind of data are involved? Is it personal data? Is it special categories of personal data or is it a combination of both? What about the legal justification? Is there any legal justification at all? If there is no legal justification, then most likely processing is unlawful and you need to reconsider your data processing activities. Security measures. What kind of particular security measures are set in place to protect the personal data involved in this specific processing activity? Do you believe that those measures are adequate and provide reasonable protection? What about the processing principles we talked about earlier under Article 5? Is everything processed in a lawful manner and in a transparent way? And last but not least, what about the data subjects? How can they exercise their rights? Are there any mechanisms in place for, let's say, obtaining copies of their personal information? How do you handle data subject requests? And when it comes to running an organization-wide GDPR assessment to determine those things that we talked about earlier, where mostly, I mean, the records of processing activities mostly take into account the processing activities themselves. Now when running organization-wide GDPR assessments, here are four plus four basic questions that you can ask yourselves in order to help determine a basic compliance level within your organization. I'm not saying that this is an exhaustive list. It's definitely not an exhaustive list. And there are a lot of factors that may additionally need to be considered from case to case. But these are nevertheless eight basic questions that you can ask yourselves. So first of all, does the organization fall under the scope of application of the GDPR? Is it established in the EU and processes data that relate to EU residents? Is it based outside of the EU and meanwhile provides goods or services to EU-based data subjects? What's going on here? If an organization is neither based within the EU and is not offering goods or services to EU-based residents, then perhaps it's not affected by the GDPR's scope of application and there isn't anything else that you need to do about it. I mean, GDPR does not apply to you. But it is my understanding that most open source projects generally fall under the GDPR's scope of application and you need to acknowledge all the organizational and processing requirements of the GDPR inevitably. Because most open source projects have a very global outreach. There will be a Q&A part in the end. Please write it down. Thanks. Thanks a lot. So what about the roles of the organization? Is it a data controller? Is it a data processor? Is the combination of both? Or is it a joint controller with another organization? Has it implemented appropriate technical measures to protect their infrastructure in general? Does it maintain records of processing activities? If yes, are they regularly checked and updated? Has the organization published a privacy policy? Now the GDPR does not mention anything about having privacy policies, but there are articles 13 and 14 which expect the controller to inform data subjects whenever personal information has been updated from the data subjects themselves or from another source. And generally speaking, having an easy to understand and comprehensive privacy policy is the de facto thing to do. More information on drafting privacy policies is about to follow. Has the organization embraced the principles of data protection by design and by default that we saw earlier? Does it protect personal data right from the start? And does it provide the highest available levels of data protection? Has the organization published procedures for data bridges? Again, the GDPR does not specifically ask for procedures for data bridges. However, there are several requirements that need to be taken into account. And again, it's a very nice thing to have an available procedure for handling data bridges which can be very helpful in under stressful situations. Again as a reminder, articles 33 and 34 oblige the controllers under specific conditions to inform the data protection authorities and the affected data subjects whenever they experience a data bridge. Last but not least, does the organization in question need to appoint a data protection officer? If yes, has the organization appointed one? What are the roles and scope within the organization? And now is the fun part, let's say, with cookie consent banners. I am sure that a lot of you swear in front of their computer screens every time one of these banners pops up. And some of them are admittedly very annoying. But they are what I call a necessary evil. This particular implementation is very much unethical and is not compliant with the GDPR. It does not let data subjects, okay, I think that it can be observed pretty well. So it does not let data subjects witness what kind of information are being shared with the website, what kind of information is being collected by cookies. There is a hyperlink, I'm not sure if you can see that. There is a hyperlink which has more info. If you click on that hyperlink, most of the times that I have seen, it just redirects you to the privacy policy of that particular website which happens to be a poorly written privacy policy as well. There is an X button next to the that's fine button, which is ironic, nothing is fine with this particular implementation. There is an X button, if you click on that button, nothing happens. You don't actually reject the installation of cookies into your web browser. You just choose to ignore that annoying banner. Again, this is a very much unethical implementation and it is not compliant with the GDPR. If you do know somebody who uses such kind of cookie compliance banners, please tell them to opt for a more sophisticated solution. Such as this, I am not saying that you should go ahead and implement this particular solution, but this is a very nice and very sophisticated solution which is compliant with the regulation. It lets users see exactly what kind of information is being served with their website in question and it lets them opt in for the additional processing of their personal information. So, please do not choose cookie consent banner implementations like this one. Please go for something like this instead. A very important thing, if your web platform only stores session cookies, then you don't need to obtain consent. You need to inform your users that your website installs session cookies on their browsers, but you don't really need to obtain consent. So keep that in mind. I see a lot of websites that are just installing session cookies on people's browsers and they put cookie consent banners, which is unnecessary. Now when it comes to sign up forms, I hope you can see what's going on. So there is a sign up form on the left which is not compliant and there is another one on the right which is compliant. As you can see the sign up form on the left forces users to additionally sign up for the newsletter besides accepting the terms of use and privacy policy, which is an unethical and incompatible practice with the requirements of the GDPR. Whereas on the compliant form on the right, there are two separate check boxes, one for accepting the terms of use and privacy policy and then there is also another one for optionally subscribing to the newsletter. Furthermore, if we ask for additional pieces of information such as phone numbers, we should justify why those additional pieces of information are needed in the first place. Here for example, we ask for the phone number of the user. On the form on the right, you might notice that there is a small section under the text field which says that inputting that particular piece of information is optional. If the user chooses to sell that information with their website, it can be used to send the user text messages with verification codes for two factor authentication purposes, etc. So we make sure that we justify why those additional pieces of information are needed. Now privacy policies, it is my belief that we should refrain from using privacy policy generators. It's okay to draw some inspiration from their generated texts, but it's most of the privacy policy generators out there produce insufficient privacy policies which do not cover aspects in detail. A privacy policy should explain exactly what kind of processing activities are taking place. It should explain how data subjects can exercise their rights. It should provide them with an option. It should reference how can data subjects submit complaints at their respective data protection authorities in case their data subject access requests are not sufficiently handled. So again, I would recommend not choosing privacy policy generators. It's okay to draw some inspiration. But if you don't feel very comfortable with producing a privacy policy on your own, then you should probably ask somebody else to do that for you. Don't just go ahead and use privacy policy generators without drafting a sufficiently written privacy policy. Now I'll be describing some things about the current privacy directive which was published in 2002 and was later amended twice. It was amended once in 2006. This particular amendment caused a lot of, you know, protests, sparked a lot of interest among advocates, digital rights organizations as it did introduce data retention practices by telecommunication providers. It was later declared invalid in 2014, if I'm not mistaken. And there was another amendment in 2009. So the privacy directive has a much more specific focus than the directive for data protection and now the GDPR. It does have a more specific focus. It focuses exclusively on traditional electronic communications and involves, generally speaking, telephony, internet service providers and email service providers. And among its focus areas, its key focus areas are browser cookies, unsolicited communications for marketing purposes, user tracking, et cetera. But one of the major flaws, let's say, of the current privacy directive is that it doesn't concern alternative communication options, telecommunications options. So it does not concern over the top communications, for example, such as VoIP services, streaming services, instant messaging services, which is exactly what the upcoming ePrivate regulation wants to fix. And additionally, the ePrivate regulation, the upcoming ePrivate regulation is expected to influence machine-to-machine communications as well, especially among IoT devices, where we don't have any modernized pieces of legislation covering communications among IoT devices yet. And very importantly, it's going to be a regulation. Like we said earlier, regulations are applicable and legally binding to all 28 minus 1 EU member states, whereas the directives need to be transposed into national laws and therefore does not provide the same level of harmonization across the EU member states. Furthermore, the privacy regulation may additionally involve non-personal data, such as data relating to legal persons. Remember that the GDPR is about personal data that relate to natural living persons. And in a broader term, we can safely assume that the ePrivate regulation will be less specialist. It will specialize into specific matters, such as the matters we have seen in this slide, whereas the GDPR will retain its much broader scope of application. It will be less generalist. Now are a few additional resources that I would like to share with you before closing the main part of the session. There is the GDPR checklist at gtprchecklist.io, which is also published under open licenses. I don't remember the particular license, but everything is posted on GitHub. So the source code of this particular website is publicly available under an open source, friend open source software license. And this particular website provides an intuitive way of being informed about the most important organizational and processing requirements of the GDPR. Pretty much what we have seen throughout this session in a comprehensive and laid out manner. And there is also GDPR tracker at gtprtracklist.io, which compares well-known internet services in terms of their GDPR compliance efforts. Just a reminder that my slides are already available on the website of Frostcon, so you can have a look at any time you want. Everything is available under Creative Commons. Now here are also a few links about the GDPR and lean data practices, which is one of the most recent campaigns launched by Mozilla. Mozilla has been very much advocating for data protection and privacy for many years now. And with our recent campaign about lean data practices, we recommend that companies should process the minimum amount of personal information needed and should perform appropriate measures in order to safeguard personal data. Not just because it's the ethical thing to do, but also more importantly, because it's a good thing performance-wise. So that would be all for now. We have ended our main part of this session. I will now proceed with the Q&A session, which I have asked not to be recorded online and generally on video. And I'm doing this because the GDPR is a very complicated legal text, and generally cases may vary, one from another, and I don't want to be responsible for sending wrong messages to online viewers. So you are free to ask questions. Please understand that there are several factors that need to be acknowledged, so I might not be available to answer your questions adequately in under one or two minutes, let's say.
 Welcome to the second day of FOSCON 2019 or FOSCON 14.  I hope it's a great that I do this in English because the talk will be in English.  I hope you had a good night and are fresh and are very interested to hear something about  privacy concerns because GDPR hit us last year and there's a big field that a lot of  people are scared about even if they consider privacy as a good thing.  But to be compliance can be a nightmare or not.  This will be the talk that Janice is giving you.  GDPR and ePrivacy compliance nightmare for open source projects because there's, you  know, that open source projects are much harder to control than other projects in a lot of  directions because you don't have this very strong structure.  Well, Janice is in the field of open source stuff since a lot of years.  He worked in context of Mozilla for six years and was with Fedora for nine years, which  sounds like a very long experience in the area and I'm very happy to have him here.  Have fun.  Thank you.  Good and tug.  And thank you for coming despite it's still quite early in the morning.  In this presentation, I'm going to provide an in-depth introduction to the most important,  to the most fundamental organizational and processing requirements of the GDPR, which  generally isn't a very easy thing to do as the GDPR is one of the most complex pieces  of EU legislation.  It does span across 88 pages and includes 99 articles.  So it would be impossible to cover every single aspect of the GDPR.  We would be focusing on the key aspects instead.  In addition, I will be doing a brief comparison between the main focus areas of the GDPR and  the current privacy directive and I will also be mentioning some important things about  the upcoming E-Privacy Regulation, which is expected in the coming years, only in the  coming years.  So let's begin with a brief introduction to the GDPR.  The GDPR was published in its finalized form in April 2016 and it became fully applicable  from the 25th of May 2018 onwards.  There was therefore a two years grace period under which we would have expected most organizations,  at least the colossal organizations, to be fully compliant with the requirements of the  regulation.  However, it's been more than one year since the regulation was put into full effect and  a lot of organizations, both colossal organizations and also smaller entities, have no idea what  their legal obligations are and they haven't performed the consequent changes to their  business activities and processes.  The GDPR replaces the previous directive for privacy protection, for data protection, which  was directive 95-46, which I believe was no longer adequate if we take into account the  vast advancements we have noticed in the ICT world the last 20 to 30 years.  While the GDPR is a very good thing for EU data subjects as it empowers them with additional  controls over their personal data and it also provides the harmonization of data protection  laws across the European Union, the GDPR is a regulation which means that it's legally  binding and applicable to all 28 EU member states.  Maybe it's 27 now, who knows what's going to happen in the coming months.  Whereas EU directives are, let's say, guidelines that need to be followed by EU member states  and then also need to be transposed into national laws.  So while the GDPR has some benefits for the users for the data subjects and also provides  us with a harmonization of data protection laws across the European Union, it still brings  a lot of nightmares to smaller organizations and especially open source projects.  On the one hand, we have colossal companies who have lots of money and resources and can  probably afford if they want to determine their legal obligations and perform the subsequent  changes to their processes.  And on the other side, we have smaller entities, we have small and medium sized enterprises,  open source projects who are still supposed to comply with extensive legal and technical  requirements but are, however, lacking the proper resources.  And another thing, of course, is increasing awareness around privacy data protection  matters so that at least we should proceed with the minimum changes that are required,  with the bare minimum changes.  In any case, the GDPR may impose harsh penalties to perpetrators who are found to be incompliant  which can go as high as 20 million euros or it could equal to amounts as high as 4% of  the annual global turnover of a company.  So Article 4 of the GDPR provides us with the essential terminology that is being used  throughout the legal text of the GDPR.  Personal data is any kind of information that can be correlated, that can be linked to an  identifiable natural living person.  Names, home addresses, email addresses, mobile phone numbers, phone numbers generally.  Even location data, for example, when we have mobile phones that transmit the GPS coordinates  of their users, all those examples constitute personal data.  In addition to the generic form of personal data, there are also the special categories  of personal data which can be, for example, medical records, biometric data, genetic data,  information in trade unions, political opinions, religious beliefs, and so on and so forth.  And the GDPR has additional safeguards for the processing of special categories of personal  data.  Now, processing is an umbrella term that refers to any kind of operation or set of operations  that apply to particular pieces or even sets of personal data.  The collection of personal data, the recording of personal data, the alternation, the modification,  the destruction, the deletion, everything pretty much, every possible action that can  be performed on data and on sets of data constitutes processing.  The GDPR has three main categories of actors that are referenced throughout the entire  legal text.  Data subjects are the natural living persons, we are data subjects.  They are the natural living persons to who personal data refer.  Data controllers identify the purposes and means of data processing and data processors,  like the term suggests, process data on behalf of controllers.  Now in order to help make this a bit easier to understand, imagine there is a boat and  inside the boat there is the captain of the boat who is in the context, who would be in  the context of the GDPR, the data controller, he or she gives orders to the crew members  and then you have the crew members who execute the orders of their captain and the crew members  would be the data processors.  However, in the context of the GDPR, an entity can assume both the roles of a controller  and the processor at the same time, depends on the case.  And there are also some cases when two or more controllers can jointly determine the  purposes and means of data processing and therefore we call them joint controllers.  More information on the classification of controllers and processors later on.  The GDPR admittedly has a very wide scope of application.  There is the material scope which is described by article two and it pretty much does not  make any distinction between automated and non-automated processing.  So even if we take pieces of paper and pencils and write down personal data manually, it's  still considered to be processing.  The good thing about the material scope is that it provides a few exemptions.  For example, if data processing activities are done for purely personal reasons, let's  say in the course of household activities, then such activities are exempted from the  scope of application of the GDPR.  So it's definitely okay to maintain address books to have your contacts without the need  of obtaining consent or generally speaking adhering to the extensive requirements of  the GDPR as such an activity is accepted from the scope of application of the GDPR.  And in addition to the material scope, there is the territorial scope which involves establishments  within the EU who subsequently process personal data relating to EU residents.  And in addition, it can also include establishments outside of the EU as long as they provide  goods or services to people, to data subjects within the EU regardless of whether payment  is required.  And this is where a lot of open source projects can potentially fall into the scope of application  of the GDPR, open source projects that are established outside of the EU, that is.  So moving on.  Now the organizational requirements, here are some of the most fundamental organizational  requirements which apply, let's say, to the whole organizational structure of an entity  that processes personal data.  There are the principles of data protection by design and by default under article 25,  which pretty much tells us that controllers and processors should handle personal data  and they should respect, they should protect personal data right from the start and they  should also apply the highest levels of available protection.  Article 30 obliges both controllers and processors to maintain records of processing activities.  More information on maintaining records is about to follow.  Article 32 titled security of processing obliges both controllers and processors to implement  appropriate technical and organizational measures to ensure the ongoing confidentiality, integrity  and availability of personal data.  And speaking, the GDPR does not recommend particular measures with a few exceptions,  for example the encryption and pseudonymization of personal data, but generally it's not  being very specific with regards to the actual measures that need to be implemented.  It's up to the entities, it's up to the organizations to determine what needs to be done and what  needs to be avoided.  If personal bridge is okay, the controller is supposed to notify the respective data  protection authorities within 72 hours if possible from the moment that a particular  database has been observed.  This is a requirement by article 33 and there is also article 34, which in some cases may  oblige the controller to additionally notify the affected data subjects.  Generally, when it comes to articles 33 and 34, there are specific conditions that apply.  In some cases, for example, when there is a systematic monitoring of data subjects on  a large scale, for example, when there are CCTV cameras in the premises of a company,  etc., or for example, when there is processing of sensitive personal data, the special categories  of personal data we talked about earlier, then the controller might be obliged to perform  an additional assessment called the data protection impact assessment.  There are methodologies out there for conducting such an assessment.  It is my personal estimation that most, I'm not saying all open source projects, it is  my personal estimation that most open source projects do not need to perform data protection  impact assessments.  Don't take this for granted, it really depends from case to case, depends what kind of processing  activities are actually taking place.  In some other cases, there might also be the need to appoint a person called the data protection  officer who oversees all the data processing activities of the organization that he or  she represents and generally provides recommendations.  The last two obligations are covered by articles 35 and 37, respectively.  Again, don't take my word for granted, it really depends from case to case, whether  an entity needs to perform DPAs and also needs to appoint DPOs.  Article 5 provides us with the principles behind the lawful processing of personal data.  It does say that personal data need to be processed in a lawful, fair and transparent  way, which if you ask me, it's something very unclear.  What does fairness mean?  But anyways, there are some principles such as the principle of purpose limitation, which  asks that personal data are processed for specific and legitimate purposes and they  are not further processed for additional purposes which are incompatible with the original purposes  they were initially collected for.  The data minimization principle tells us that we should collect the minimum amount of personal  data needed for a particular and legitimate purpose.  And we should not be collecting additional pieces of personal information if they are  not needed for an actual purpose.  Accuracy tells us that we should make sure that personal data are accurate and up to  date.  Storage limitation sets an expiration date, let's say, on sets of personal data and we  should be discarding sets of personal data if they no longer serve any purpose.  And as we have already seen before, controllers and processors need to ensure the ongoing  integrity and confidentiality of personal data, which is also a requirement under Article  32, the technical and organizational measures we talked about.  Article 6 establishes six different legal basis under which processing can be considered  to be lawful.  The most common of them all is perhaps consent.  We have users that sign up for a service, that sign up for a website, for an account,  and most of the times there's a sign up form, there is a check box always, they tick that  check box and indicate that they consent to the processing of their personal information,  their personal data, but consent is only one out of six possible legal basis that an organization  can rely on.  So there is a wrong misconception that consent is the only way for the lawful processing  of personal data, which is a very wrong misconception.  There might be a contract between two parties or a contract among more than two parties  and this contract could ideally include clauses about data processing activities and also  sections about the protection of personal data and therefore a contract may be able to govern  the data protection, the data processing activities that take place.  An entity, an organization might be processing personal data because it has to comply with  illegal obligation, which doesn't affect a lot of projects, doesn't concern a lot of  open source projects.  Processing may also be lawful in order to protect the vital interests of a data subject  whenever a data subject is unable to freely provide consent.  An organization might be performing public tasks such as the administration of justice,  which doesn't concern all open source projects, I would say either, not just most, but all  open source projects, but again, don't take everything for granted.  And last but not least, there is the principle, the legal justification of legitimate purposes.  Legitimate purposes are perhaps the most flexible legal base of them all and organizations can  rely on legitimate purposes for a variety of reasons as long as they do it in a reliable  and justified manner.  For example, keeping security logs can be done without the consent of data subjects  because entities, organizations, that process personal data, have an obligation under article  232 called the security of processing to implement the technical and organizational measures  and therefore can rely on legitimate interests.  It's in their legitimate interests to protect their online infrastructure.  It would also be impossible to request consent.  It would be very hard, not impossible, but very hard to request consent from users in  order to store IP addresses.  It would be chaotic, it could be chaotic if you think about it.  So what we should keep from this is that consent is not the only way of processing personal  data in a legitimate way.  There are six legal bases in total that we can consider as long as data processing activities  are done in a lawful manner and are meanwhile compatible with the rest of the requirements  of the GDPR.  Data subjects are empowered with a set of rights.  A lot of these principles already existed in the previous data protection directive  but are now further reinforced with the GDPR.  When communicating with controllers and processors, data subjects should receive transparent information  using easy-to-understand language, plain English, plain German, and so on and so forth  without the legal jargon, without many technical details so that everybody can understand what's  going on without the need to be technical literate or to be knowledgeable about legal  procedures, legal jargon.  So data subjects have the right of access, which isn't just about receiving a list and  descriptions of the personal data that an organization holds on their behalf.  It's about receiving actual copies of their personal data.  And yesterday I read a German court.  I do not remember which court exactly actually reinforced the idea of having decided that,  yes, data subjects should receive an exact copy and not just lists with descriptions.  So I believe that this was a very important decision and it's going to play an important  role in the future exercising of the rights of data subjects.  The right of rectification provides data subjects with the possibility of requesting a change,  a correction of their personal data in case something is not up to date or is not accurate.  Data subjects have the right to erasure, also linked to the right to be forgotten, which  is in turn linked to the Google Spain case if you are aware of the Google Spain case,  which I believe was a very important milestone for the establishment of the right to be forgotten.  So pretty much under specific conditions you have the right to ask for the deletion of  all your personal data from a specific organization.  Again, there are a few exceptions to this, depends on the case.  In some cases, data subjects may also have the right to request the restriction of processing  of their personal data and also to object to the further processing of their personal  data.  And last but not least, and very importantly, it's very important nowadays because we have  seen the rise of cloud computing, data subjects have the right to data portability.  Pretty much controllers are expected to be able to export personal data under machine  readable formats so that users, so that data subjects can freely move from one service  provider to another service provider.  So this is visualization of the organizational and processing requirements we have talked  about in the previous slides.  I have already actually, somebody else actually uploaded the slides for me on the website  of Frostcon.  Everything is available at Creative Commons.  So you are free to take in-depth looks later on.  Now a few things about compliance assessment.  We talked about maintaining records of processing activities.  What do they mean?  There are a few guidelines out there.  For example, there are some guidelines set by the Working Party 29.  And generally speaking, here are a few things that you need to consider when creating and  maintaining records of processing activities.  First of all, it's for sure that you need to provide a friendly name for the processing  activity which is involved.  Just a name that can help you quickly identify for which processing activity you are talking  about.  You need to specify the controller or the controllers that are involved with this particular  processing activity.  Likewise, you need to do the same for processors, for any processors.  Your description should mention what kind of data processing activities are taking place,  exactly what is done, what kind of activities are performed on the sets of data.  It should briefly mention the data flows within the infrastructure of your company.  It should mention who has access to those particular sets of data.  It should also justify why those particular people have access to the sets of data.  And it should mention also the storage method.  Where are the data sets being stored?  Is it inside the file cabinet?  Is it in your online infrastructure, your offline digital infrastructure?  Where is it located?  Does it use a combination of storage methods?  You have to be specific about where the data is stored and what happens to the personal  data inside your organization.  Also, what kind of data are involved?  Is it personal data?  Is it special categories of personal data or is it a combination of both?  What about the legal justification?  Is there any legal justification at all?  If there is no legal justification, then most likely processing is unlawful and you need  to reconsider your data processing activities.  Security measures.  What kind of particular security measures are set in place to protect the personal data  involved in this specific processing activity?  Do you believe that those measures are adequate and provide reasonable protection?  What about the processing principles we talked about earlier under Article 5?  Is everything processed in a lawful manner and in a transparent way?  And last but not least, what about the data subjects?  How can they exercise their rights?  Are there any mechanisms in place for, let's say, obtaining copies of their personal information?  How do you handle data subject requests?  And when it comes to running an organization-wide GDPR assessment to determine those things  that we talked about earlier, where mostly, I mean, the records of processing activities  mostly take into account the processing activities themselves.  Now when running organization-wide GDPR assessments, here are four plus four basic questions that  you can ask yourselves in order to help determine a basic compliance level within your organization.  I'm not saying that this is an exhaustive list.  It's definitely not an exhaustive list.  And there are a lot of factors that may additionally need to be considered from case to case.  But these are nevertheless eight basic questions that you can ask yourselves.  So first of all, does the organization fall under the scope of application of the GDPR?  Is it established in the EU and processes data that relate to EU residents?  Is it based outside of the EU and meanwhile provides goods or services to EU-based data  subjects?  What's going on here?  If an organization is neither based within the EU and is not offering goods or services  to EU-based residents, then perhaps it's not affected by the GDPR's scope of application  and there isn't anything else that you need to do about it.  I mean, GDPR does not apply to you.  But it is my understanding that most open source projects generally fall under the GDPR's  scope of application and you need to acknowledge all the organizational and processing requirements  of the GDPR inevitably.  Because most open source projects have a very global outreach.  There will be a Q&A part in the end.  Please write it down.  Thanks.  Thanks a lot.  So what about the roles of the organization?  Is it a data controller?  Is it a data processor?  Is the combination of both?  Or is it a joint controller with another organization?  Has it implemented appropriate technical measures to protect their infrastructure in  general?  Does it maintain records of processing activities?  If yes, are they regularly checked and updated?  Has the organization published a privacy policy?  Now the GDPR does not mention anything about having privacy policies, but there are articles  13 and 14 which expect the controller to inform data subjects whenever personal information  has been updated from the data subjects themselves or from another source.  And generally speaking, having an easy to understand and comprehensive privacy policy  is the de facto thing to do.  More information on drafting privacy policies is about to follow.  Has the organization embraced the principles of data protection by design and by default  that we saw earlier?  Does it protect personal data right from the start?  And does it provide the highest available levels of data protection?  Has the organization published procedures for data bridges?  Again, the GDPR does not specifically ask for procedures for data bridges.  However, there are several requirements that need to be taken into account.  And again, it's a very nice thing to have an available procedure for handling data  bridges which can be very helpful in under stressful situations.  Again as a reminder, articles 33 and 34 oblige the controllers under specific conditions to  inform the data protection authorities and the affected data subjects whenever they experience  a data bridge.  Last but not least, does the organization in question need to appoint a data protection  officer?  If yes, has the organization appointed one?  What are the roles and scope within the organization?  And now is the fun part, let's say, with cookie consent banners.  I am sure that a lot of you swear in front of their computer screens every time one of  these banners pops up.  And some of them are admittedly very annoying.  But they are what I call a necessary evil.  This particular implementation is very much unethical and is not compliant with the GDPR.  It does not let data subjects, okay, I think that it can be observed pretty well.  So it does not let data subjects witness what kind of information are being shared with  the website, what kind of information is being collected by cookies.  There is a hyperlink, I'm not sure if you can see that.  There is a hyperlink which has more info.  If you click on that hyperlink, most of the times that I have seen, it just redirects you  to the privacy policy of that particular website which happens to be a poorly written privacy  policy as well.  There is an X button next to the that's fine button, which is ironic, nothing is fine with  this particular implementation.  There is an X button, if you click on that button, nothing happens.  You don't actually reject the installation of cookies into your web browser.  You just choose to ignore that annoying banner.  Again, this is a very much unethical implementation and it is not compliant with the GDPR.  If you do know somebody who uses such kind of cookie compliance banners, please tell  them to opt for a more sophisticated solution.  Such as this, I am not saying that you should go ahead and implement this particular solution,  but this is a very nice and very sophisticated solution which is compliant with the regulation.  It lets users see exactly what kind of information is being served with their website in question  and it lets them opt in for the additional processing of their personal information.  So, please do not choose cookie consent banner implementations like this one.  Please go for something like this instead.  A very important thing, if your web platform only stores session cookies, then you don't  need to obtain consent.  You need to inform your users that your website installs session cookies on their browsers,  but you don't really need to obtain consent.  So keep that in mind.  I see a lot of websites that are just installing session cookies on people's browsers and  they put cookie consent banners, which is unnecessary.  Now when it comes to sign up forms, I hope you can see what's going on.  So there is a sign up form on the left which is not compliant and there is another one  on the right which is compliant.  As you can see the sign up form on the left forces users to additionally sign up for the  newsletter besides accepting the terms of use and privacy policy, which is an unethical  and incompatible practice with the requirements of the GDPR.  Whereas on the compliant form on the right, there are two separate check boxes, one for  accepting the terms of use and privacy policy and then there is also another one for optionally  subscribing to the newsletter.  Furthermore, if we ask for additional pieces of information such as phone numbers, we should  justify why those additional pieces of information are needed in the first place.  Here for example, we ask for the phone number of the user.  On the form on the right, you might notice that there is a small section under the text  field which says that inputting that particular piece of information is optional.  If the user chooses to sell that information with their website, it can be used to send  the user text messages with verification codes for two factor authentication purposes, etc.  So we make sure that we justify why those additional pieces of information are needed.  Now privacy policies, it is my belief that we should refrain from using privacy policy  generators.  It's okay to draw some inspiration from their generated texts, but it's most of the privacy  policy generators out there produce insufficient privacy policies which do not cover aspects  in detail.  A privacy policy should explain exactly what kind of processing activities are taking  place.  It should explain how data subjects can exercise their rights.  It should provide them with an option.  It should reference how can data subjects submit complaints at their respective data  protection authorities in case their data subject access requests are not sufficiently  handled.  So again, I would recommend not choosing privacy policy generators.  It's okay to draw some inspiration.  But if you don't feel very comfortable with producing a privacy policy on your own, then  you should probably ask somebody else to do that for you.  Don't just go ahead and use privacy policy generators without drafting a sufficiently  written privacy policy.  Now I'll be describing some things about the current privacy directive which was published  in 2002 and was later amended twice.  It was amended once in 2006.  This particular amendment caused a lot of, you know, protests, sparked a lot of interest  among advocates, digital rights organizations as it did introduce data retention practices  by telecommunication providers.  It was later declared invalid in 2014, if I'm not mistaken.  And there was another amendment in 2009.  So the privacy directive has a much more specific focus than the directive for data protection  and now the GDPR.  It does have a more specific focus.  It focuses exclusively on traditional electronic communications and involves, generally speaking,  telephony, internet service providers and email service providers.  And among its focus areas, its key focus areas are browser cookies, unsolicited communications  for marketing purposes, user tracking, et cetera.  But one of the major flaws, let's say, of the current privacy directive is that it doesn't  concern alternative communication options, telecommunications options.  So it does not concern over the top communications, for example, such as VoIP services, streaming  services, instant messaging services, which is exactly what the upcoming ePrivate regulation  wants to fix.  And additionally, the ePrivate regulation, the upcoming ePrivate regulation is expected  to influence machine-to-machine communications as well, especially among IoT devices, where  we don't have any modernized pieces of legislation covering communications among IoT devices  yet.  And very importantly, it's going to be a regulation.  Like we said earlier, regulations are applicable and legally binding to all 28 minus 1 EU member  states, whereas the directives need to be transposed into national laws and therefore  does not provide the same level of harmonization across the EU member states.  Furthermore, the privacy regulation may additionally involve non-personal data, such as data relating  to legal persons.  Remember that the GDPR is about personal data that relate to natural living persons.  And in a broader term, we can safely assume that the ePrivate regulation will be less  specialist.  It will specialize into specific matters, such as the matters we have seen in this slide,  whereas the GDPR will retain its much broader scope of application.  It will be less generalist.  Now are a few additional resources that I would like to share with you before closing  the main part of the session.  There is the GDPR checklist at gtprchecklist.io, which is also published under open licenses.  I don't remember the particular license, but everything is posted on GitHub.  So the source code of this particular website is publicly available under an open source,  friend open source software license.  And this particular website provides an intuitive way of being informed about the most important  organizational and processing requirements of the GDPR.  Pretty much what we have seen throughout this session in a comprehensive and laid out  manner.  And there is also GDPR tracker at gtprtracklist.io, which compares well-known internet services  in terms of their GDPR compliance efforts.  Just a reminder that my slides are already available on the website of Frostcon, so you  can have a look at any time you want.  Everything is available under Creative Commons.  Now here are also a few links about the GDPR and lean data practices, which is one of the  most recent campaigns launched by Mozilla.  Mozilla has been very much advocating for data protection and privacy for many years  now.  And with our recent campaign about lean data practices, we recommend that companies should  process the minimum amount of personal information needed and should perform appropriate measures  in order to safeguard personal data.  Not just because it's the ethical thing to do, but also more importantly, because it's  a good thing performance-wise.  So that would be all for now.  We have ended our main part of this session.  I will now proceed with the Q&A session, which I have asked not to be recorded online and  generally on video.  And I'm doing this because the GDPR is a very complicated legal text, and generally cases  may vary, one from another, and I don't want to be responsible for sending wrong messages  to online viewers.  So you are free to ask questions.  Please understand that there are several factors that need to be acknowledged, so I might not  be available to answer your questions adequately in under one or two minutes, let's say.
2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_0_179.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_180_251.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_252_359.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_360_2027.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2028_2183.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2184_2231.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2232_2279.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2280_2327.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2328_2375.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2376_2423.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2424_2471.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2472_2519.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2520_2579.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_2580_3983.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_3984_4655.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_4656_4991.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_4992_5759.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_5760_5807.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_5808_6083.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_6084_9395.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_9396_17339.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_17340_23315.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_23316_23423.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_23424_31439.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_31440_31787.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_31788_36311.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_36312_36443.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_36444_36995.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_36996_37043.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_37044_40115.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_40116_40319.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_40320_42599.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_42600_46091.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_46092_49163.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_49164_51767.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_51768_52583.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_52584_52715.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_52716_53651.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_53652_56087.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_56088_58415.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_58416_58511.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_58512_63467.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_63468_63575.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_63576_65099.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_65100_66527.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_66528_66791.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_66792_66875.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_66876_67199.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_67200_67259.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_67260_67583.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_67584_67643.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_67644_67763.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_67764_67883.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_67884_67979.png 2019_-_GDPR_and_ePrivacy__Compliance_Nightmares_fo_EyodrS91-5k_67980_68002.png