Watch to learn how GDPR compliance impacts you and how to prepare for the May 25th effective date.
Having issues accessing the video above? Watch the video here.
The EU General Data Protection Regulation (GDPR) not only applies to organizations operating in the EU, but also to organizations outside the EU that process Personally Identifiable Information (PII) from the EU. This webinar covers GDPR 101 basics and includes a Q&A session. In this webinar, Gary Glover (CISSP, CISA, QSA, PA-QSA) discusses:
This webinar was hosted on January 25th, 2018.
0:00 Alright everyone. Welcome to today's webinar GDPR 101, what you need to know. Our presenter today is Gary Glover who is the Vice President of Assessments at SecurityMetrics and he has about 13 years of experience in the PCI audit realm. So we're happy to have him presenting today. One quick reminder, we will be sending out a recording of this presentation for your review.
0:27 Thanks very much everybody. I appreciate your time today and hopefully this will be worthwhile. This is just an introduction to GDPR. Most of the industry is still waiting to find out more about it and how things are going to be interpreted. We'll talk a little bit more about that as we go on. Our audience today is from the EU or anybody processing personal information data for subjects that live in the EU. It could be American companies, it could be companies from other countries all over the world.
1:08 GDPR applies to those organization located within the EU and outside if they handle data for those within the EU. I want to make sure that we're clear on that. So, following the GDPR guidelines will be very important for those companies.
1:31 Let's talk about what we're going to do today. We're going to talk about how GDPR compliance impacts you and your company. We're going to talk a lot about clarifying some of the GDPR requirements as much as we can at this time. As time goes on, continue to be watching for further information from SecurityMetrics and other security providers as they learn more about GDPR and how it's being interpreted. We're also going to talk about some data security best practices. One part of the GDPR essentially says, “Do good data security.” So we'll talk about what we feel that means. I've been in the security industry for about 13 years now and SecurityMetrics has been around since that time. We've been working heavily in the payment card industry as well as the healthcare industry here in the United States for companies all over the world.
2:30 Starting off we're going to get into some basics. What is the GDPR (General Data Protection Regulation)? It replaces the EU's Data Protection Directive. It's got some numbers after it 95/46/EC and it was designed to harmonize data privacy laws across Europe and to protect and Empower all EU citizens data privacy and reshape the way organizations across the region approach data privacy. So that's an official statement. Different countries were doing slightly different things for data protection throughout the EU and this is meant to unite them under one regulation to rule them all.
3:19 So after four years of preparation and debate, the general data protection regulation was finally approved by EU Parliament on April 14, 2016. It went into effect 20 days later, was published in the EU official journal in May 2016 and will be directly applicable to all member states two years after that date. That date is coming up this year on May 25th of 2018. At that time organizations who aren't following GDPR or have had a data breach might face heavy fines.
4:02 I don't know that anybody can say you're guaranteed any fines right now but there may be things that various regulation bodies begin looking at. I want to discuss the word compliance in terms of these new regulations. Often in the security industry when you hear the words compliance or certificate of compliance it goes along with some security standards, specific requirements and testing procedures clearly defined that set at least a low bar for meeting a specific requirement. An example might be the Payment Card Industry Data Security Standard, PCI DSS. You can be audited as an entity and your procedures tested and evidence gathered to prove that you are compliant to that specific standard.
5:08 And then if you are found compliant, you get an attestation of compliance signed and provided by the company or the auditor who did the assessment. Laws and regulations like GDPR and HIPAA are not in all cases easy to interpret. So this is different than a specific standard with exacting requirements and exacting testing procedures. I want to make sure we're clear on that. There are some things in GDPR that are pretty easy and obvious to interpret for example, GDPR states that you have to have an opt-in choice from a data subject before you can store process or transmit their personal information. That's pretty clear and you could probably determine that as met or not met as something that's fairly obvious. It’s built right into the regulation or the law, but others are more difficult to interpret. For example, the comment in GDPR that says, “Protect your data by design and default.”
6:09 So how do you say that you're perfectly compliant or meeting an exacting standard to that? It’s really it's subjective. There is no standard to compare it with. So my point is, be informed, be wary, be reasonable. It's basically impossible to say with absolute clarity that an entity is 100% compliant with GDPR or to provide a certificate of compliance because there is no specific standard with testing procedures to find out. Perhaps that will come later in the industry. I know that there are various supervisory authorities are working on all kinds of different checklists and things like that, so as time goes on there may be more public audit protocols published, then words like ‘compliance’ and ‘certificates’ may be able to be used but at this time that's a difficult thing.
7:02 So as you are addressing your GDPR effort and meeting the requirements that are defined there, make sure that you're being wary and you're avoiding people or companies that promise compliance or promise a certificate.
7:24 You can be addressing GDPR regulations very carefully, documenting your results, making plans, following plans, showing risk analysis results that are giving you the confidence that you're following the principles in the GDPR. This will also provide confidence to any other regulatory body that may ask for proof that you are following these requirements.
7:45 That was a long discussion but I wanted to make sure that we got that clear.
7:51 GDPR, why should I care? People like to use scare tactics out there in the industry and this is probably a pretty good one. They're saying that people who are not following the GDPR guidelines can be fined up to 20 million Euros or four percent of their annual Global turnover, revenue is a term often used here in the United States, for the preceding financial year whichever is greater. That's a maximum fine. There isn’t a guideline that says this will be it. It might be less, it may not even be at all. So there are potential penalties. We're not saying that the sky is falling. You just need to be informed about the possible results.
8:48 It helps you and your company to understand what your risk tolerance is make plans.
8:58 Notice though. There is also a tiered approach to fines. For example, you might not be fined 4% you may be fined 2% if you don't have your records in order per Article 28 of the GDPR or not notifying the Supervisory Authority and Data Subject about a breach or not conducting an impact assessment. For these smaller pieces of the GDPR you might only be fined a smaller amount. However, it's important to note that these rules apply to both controllers of data, people who supply information and processors meaning people who may take information from other entities to then process and return the results.
9:39 It also helps us to understand that the cloud services will not be exempt from GDPR enforcement. As an example, in January of this year, there was a data breach. This one in the UK, maybe many of you have read about it. There was a company that lost a bunch of data, 3 million customer records, but it happened clear back in 2015. That company, Carphone Warehouse, was fined 400,000 pounds, 552,000 US dollars. It was assessed just this January 10th by the Information Commissioner's Office the ICO in the UK.
10:31 So I'm guessing most likely that is being fined under the EU Data Protection Directive. I haven't really found that. However, to get that kind of fine there had to be some pretty obvious bad practices and security. There's a quote by Elizabeth Denim, Information Commissioner in the UK stating, “A company as large, well resource and established as Carphone Warehouse should have been actively assessing the state of their security systems and ensuring systems were robust and not vulnerable to such attacks. Carphone Warehouse should be at the top of the game when it comes to cybersecurity and it’s concerning that the systemic failures we found related rudimentary, commonplace measures.” So, it’s pretty obvious that they were doing some pretty major things wrong. It has to be something that's that is dangerous to data.
11:34 When do I have to worry about GDPR? It was approved in April of 2016 so you have until May 25th, 2018 to begin complying with these regulations and following them. Right now, we don't know who these Supervisory Authorities will go after or how aggressively they'll go but after May 25th of this year, they possibly can go after organizations. Recent blogs by the UK's Information Commissioner Elizabeth Denim gives us some idea of at least one of the Supervisory Authorities point of view and what will happen. You can go to their website and to their blog and look at some of these I really have enjoyed some of her statements.
12:27 She sounds very reasonable very understanding and if you're messing up really bad, then you should get in trouble but if you are doing your best and moving towards fulfilling the requirements, I don't think that office is out to get anyone or make big examples of a company. The upcoming GDPR deadline is not the end of the world. It's not a Y2K kind of a thing.
13:05 I think at times we all got caught up when a line is drawn in the sand and we fear the worst. People need to do business with PII and other people that you do business with may get caught up in this feeling and we need to help them understand that businesses should be progressing forward and not backward or staying stagnant when it comes to GDPR. The upcoming GDPR deadlines might be interpreted as, “You fail you pay.” However I think it can be interpreted more like, “Okay, let it be known that on this date, we all agree that GDPR requirements are in place. You need to work on them in a proactive manner after thinking a lot about it.” I believe that I lean more towards that second interpretation. I think it is a little bit more likely rather than, “We're calling you on May 26th and saying that you fail and therefore you have a fine.” Being in an audit or legal department does make us want to think in absolutes when giving advice to a company, it's our job. So definitely you should be serious and working on it in a proactive way. However, many of you will most likely have issues to resolve even on May 25th. Some of these issues may even take a little bit of time to finish. Businesses have known about this change for two years, so it's serious and the regulation will begin on the 25th.
14:38 However, I think being able to show your company's moving forward is very important, especially if you have a data breach after May the 25th. If you do have data breach and can't show proactive work on following GDPR, then enforcement of the regulation probably could go much harder.
All right, enough long-winded stuff. I want to quickly go through some terms that are in use in GDPR that you may hear in the industry. A Data Controller is an entity that determines the purpose and means for which PII is processed. So that's somebody who's saying, “I would like this information, I need to get it.” A Processor might be somebody who processes personal data on behalf of the controller. Supervisory Authorities are those independent public authorities established by a member state in the EU to represent the people and oversee and monitor businesses as they are working with entities personal information.
Another term that you hear in GDPR is Pseudonymisation. That's a process that's transforming personal data in such a way that resulting data can't be attributed to a data subject without use of other information, things like encryption and data separation can do that. It's an odd term and personal data that has been pseudonymised or key coded can fall within the scope of GDPR depending on how difficult it is to attribute the pseudonym to a particular individual.
Any personal data, which is defined as information relating to an identified or identifiable natural person or data subject falls within the scope of the GDPR regulation. However, it may not apply to data that does not relate to and identifiable natural person or to data rendered anonymous in such a way that the data subject is no longer identifiable. Note that anonymous data is different than pseudonymous data. It's kind of a weird thing. Pseudonymous data can be data being protected using something like encryption, hashing or tokenization algorithms or it may be removing or obscuring direct identifiers and holding them in separate distinct databases that can only be rematched using a key of some sort. It sounds kind of complex. However, I think a lot of people may think, “Well if I can just do that that I'm totally out. I don't have to do anything.”
17:23 The use of pseudonymization may not get data out of scope for GDPR but it does allow the relaxing of some provisions for using personal data for secondary purposes, for example, scientific or historical research. It also may help with meeting the regulations Data Security by Design requirements. So, you may be able to apply those principles to make your life a little easier, but it is not a silver bullet that gets you out of GDPR.
18:00 I think we all kind of know what a Data Breach is. If you lose, accidentally or unlawfully destroy, alter or in some other way disclose or provide access to personal data that's being stored, processor or transmitted. So that's what a Data Breach would be.
18:20 So we talked a little bit quickly about who enforces GDPR, the Supervisory Authorities. There is supposed to be one identified in each of the countries in the EU that have signed up for GDPR. For example, the Information Officers Commissioner's Office in the UK would probably be an example of an SA.
18:46 It would be a good idea to start identifying who your SAs are. The SAs are the ones that would be responsible for issuing fines. Note that GDPR does not say anywhere that fines are independently cumulative. It's assumed that the maximum is the maximum across all of the entities SAs. In other words. If you did something really horrible like lost millions and millions of records and it was total negligence on your part, perhaps they would go to the maximum of 4% or the or the 20 million euros, but you're not going to get 20 million euros from every different EU SA.
19:37 So let's talk about some International concerns. I know that there are a lot of people here on the webinar today from the United States. Discovering who your SAs are is currently kind of a hard part. GDPR, the way it's written, doesn't require you to deal with every single SA in every member state that you work with. There is a provision for an entity to select a lead Supervisory Authority. That's article 29 of the GDPR. If you're a company is entirely incorporated inside the EU, you work only in the EU and you deal with people and other companies that are Incorporated there then wherever your main place of business is, that is probably where you would say, “That's my Supervisory Authority.” If I was in the in the UK, perhaps that would be the ICO office. If I was in Germany, perhaps it would be the lead Supervisory Authority there. You may still do business with Germany if you're in the UK, or with the UK if you're in Germany, but the lead supervisory Authority would be the one that you would deal with for all kinds of issues. You would not have to be dealing with all of them.
20:59 So it's important that you select and document the lead Supervisory Authority and for companies that have a major presence in the EU, you can select a single one. Now, let's talk about a US companies just for a second.
21:22 If a US company has a physical presence in the EU, then you can say you have an establishment or a place of business in the EU. Then you could select a lead Supervisory Authority in that country. It's a very detailed process, there's a whole article on it, article 29 Data Protection Working Party. You can look it up, it's linked in many of the websites. Now if you are a US company or a company that's outside of the EU that does not have an established presence or an establishment in the EU, this GDPR cooperation and consistency mechanism that we've talked about only applies to controllers with that establishment within the EU. If a company does not have an establishment in the EU, the mere presence of a representative in Member State like one person, may not trigger the One-Stop shopping kind of system.
22:30 It probably means that Controllers without any establishment in the EU must deal with all the local Supervisory Authorities in every Member State that they are active in through that process. So think about how it applies to your company. Obviously it can be quite complex. You may have to deal with a whole bunch of them or it could be very simple. You may only have to deal with one SA if you have a presence in the EU.
23:02 With all of that background, what do I do now? Well, obviously an important thing to do is to learn about the GDPR requirements. This is not a know all end all webinar about everything GDPR. We're just giving you some ideas here. There are some great websites out there to learn about it. I have really enjoyed the information on the ICO website, ico.org.uk. I think that's a really nice summary. If you like to go, there's a link on their first page that will get you down to the GDPR information. So start working on it start understanding it start reading about it start figuring out what things you don't have in place.
23:48 There are many checklists and services available. SecurityMetrics is working on one that you can potentially use soon. Start finding things that you need to fix and start fixing them. You also need to think about all the documentation that may be required. Perhaps are a lot more things that need to be written down and processes documented. You need to either create all that or maybe find people who have packages of these types of documentation that you can modify. Documentation will be a pretty big task for meeting GDPR regulations.
24:28 So how does GDPR match up with general data security? I've been working in this industry for a lot of years and data security is data security. You should have a firewall you should be good at watching out for viruses. You should update your systems. You should have controls and policies and procedures over who has access to the data. There are those elements that are common in all of these security regulations or standards.
25:05 So, GDPR does encompass some basic data protection principles, basically in one statement that they make and we'll talk about it a little bit later. Does that mean that if you're compliant in other publicly regulated data security initiatives like PCI DSS or in the SOC type 1 or type 2 or ISO 27000 27001. Are you doing some of those things then? Yeah, you may have some controls around data security that can already be in place. I'm assuming that's what a lot of people meant when they answered in the poll that, “Yes, I'm kind of sort of ready.” And you may already be ready in areas that you've got data protection.
The thing about it that's different, for example, if you are PCI DSS kind of person, GDPR may require additional scope because now you have to think not about just one type of data, but personal information can be much larger. Defining personal information is one of the hard parts and actually kind of a fuzzy part in this GDPR as well. How can you really determine an individual from a certain piece of data that you have?
26:24 That's something that all companies are going to have to go through and think about. So specifically let's say PCI DSS versus GDPR if your PCI DSS compliant are you totally done with GDPR? No. There might be some data security crossovers. The biggest difference between these two regulations is PCI DSS is focused on card data while GDPR focuses on personal data of any kind including names, addresses and phone numbers. So if your personal data that you handle is exactly and only card data, then the scope would be very similar, it may be exact and you may be a long way towards the GDPR security requirements. So it really depends. PCI DSS may not be directly relatable with the GDPR but it can help in some of those obligations by implementing and providing technical measures to protect against data breaches.
27:33 PCI DSS is pretty deep in data security specifics, firewalls, all kinds of different regulations on antivirus, around coding practices, etc. GDPR is more in-depth in other things like processes for notification and privacy issues and the ability to delete data, things like that, but they all imply data security.
28:00 So let's go into some GDPR requirements. The first thing you need to do is discover and clearly document where all of the data that you're trying to secure is. Where does it flow in and out of your organization? It's amazing how many places personal information can get to. When you do the detailed analysis of what kind of data you get and from where it's like Jurassic Park, the movie, where all of the dinosaurs weren't supposed to be able to get out of this area and weren’t supposed to reproduce yet they did anyway.
28:50 Anyway, that's like sensitive data, it just gets into places where it's not supposed to be. So the hard part is finding it under what tree or computer or cabinet door or warehouse or wherever this data resides, and mapping it. It's a basic principle of all security efforts, you can't protect what you don't know is there. So this process consists of assigning a person or a group that has been enabled and empowered, to go through all the departments and groups in your company and searching for PII or personal information with various types of tools. You can use regular expression search tools. We have one called PIIscan.
There are all kinds of different things that you can use, interviews, reviewing documents, mapping software data flow, talking to developers, etc.
29:46 So once you know where all of that data is and where it flows it's critical to document this information in the form of network diagrams, data flow diagrams and process descriptions. Often people are quite surprised at how much data they have, where it is used and by what groups it is used by.
30:09 So that's the same for any kind of security. This is one of the main things at the very top of GDPR that you need to start doing and it’s something you can start doing today and figuring it out. You can make progress today by starting those diagrams and starting those discussions in your companies.
30:35 Communicating privacy information in privacy notices. As I mentioned GDPR as a lot of core principles on communicating with those that you obtain PII from but these core principles are quite extensive in this regulation. The communication can be provided directly to an individual who's giving you the PII or to an entity that provides PII to you that has been previously collected. So these principles center around clear communication to data owners on what data you're getting, why you need it and how it's going to be treated. This communication is required to be very transparent and easy to understand and easy to find on websites or in documentation for any of your customers. This communication needs to explain things such as: What is my lawful basis? Why are you getting my data. Why do you need it? What's the lawful basis? How long will you keep it? What are the data subjects rights regarding the data that you're processing and storing for them?
31:53 So having clear communications, processes, documentation, website notices, all kinds of things like that are going to be very important for GDPR regulation.
32:09 Here is a little bit more detail on an individual's rights, the rights of the data owners. This is not going to be all of the rights that are documented in GDPR but a few of them. There's this Right to Portability. The users may want to request a copy of their personal data in a portable file format that can be transferred to another entity. Maybe a download into a CSV file. That's something that you're going to have to think about as a company. If somebody wants to move from your company to another company that does exactly the same thing, how closely do you have to provide data to them to move it around. The right to erasure. Your data subjects have the right to request that their data be deleted. I've read so much recently on this because this is a tough topic in GDPR and one that is still under a lot of debate and people are trying to figure this out.
33:04 The Right to Erasure doesn't necessarily mean the right to absolutely forget for all time with no traces whatsoever. It means that if it's possible, if it's something that can be done that makes sense and I don't need the data for defending myself legally. We don't have time to go into all of the ins and outs of that but the ICO website has some really great text and wording and guidance on all of these individual rights. I recommend that you go there and start reading about this stuff.
33:47 The Right to Object. A customer may say, “I want to opt out of direct marketing. I object to receiving emails from you.” This is an interesting one too because, what if somebody says to you, “I want to be erased, I want you to forget me.” And then what if you happen to get their name and email from a different source. Unless you kept a record of what their data was, you can't know to compare. There are all kinds of really weird things that get into this. Don't take this as policy or setting actual requirements. These are just some of the things that we here at SecurityMetrics are trying to figure out regarding our own GDPR compliance effort. So it's something that even the security guys are having to deal with. How do you interpret this? And so how do I say that I have forgotten somebody and won't ever email them again if I don't keep something about them that tells me to watch for them.
There's some pretty obvious ones. Don't profile people. Somebody should be able to say, “I think you're profiling me for marketing purposes, I want you to quit that.” You must require explicit consent for that. Do some more research on that.
35:19 Again, we haven't gotten into everything here. The action that you have is to document how you would do some of these things or how you would provide this data electronically, how long might it take and when does it become very hard to do. That's where these subject access requests come in. In the the old regulation of the EU you could take up to 40 days to provide a subject with data access but now it's down to 30 days. If you had a huge amount of data and it was difficult or time-consuming, you could say, “I need more time than that,” but you have to be able to justify it.
36:16 So you also have to provide this data pretty much free of charge, unless it becomes manifestly unfounded or excessive. If you do refuse a request, you have to tell the individual why and that they have the right to complain to the Supervisory Authority. But you must do this without undue delay at least within one month. There are all kinds of really subtle details to this law. And again, I think if I were you I would start with some of the interpretations of it rather than going directly to the regulation. The regulation itself is reads like a law and it's hard to understand. So again, things like the ICO website have been really great for helping me understand it. Basically you need to be able to have documentation explaining your company’s need to obtain personal information. It needs to be legal. Document it and then make that documentation available to the individuals whose data you gather. You have to have a good reason for getting this data.
37:23 Consent is another thing that is part of GDPR. Consent must be obtained from individuals before you begin processing storing or transmitting their personal data. It’s an opt-in process. It can't be a quick pop up to inform them that you have something on your website somewhere that says that if you enter data here you can send it, like inferring consent. It has to be a physical opt-in. So make sure your process considers this and make the modifications necessary to make it a clear opt-in choice by individuals. Record that choice in logs. This choice can't be slipped into a big terms and condition statements it needs to be separate. So make sure you have clear and concise privacy documentation available to all individuals.
38:20 Consent for children is something that is mentioned specifically. These privacy notices have to be written in simple language that children will understand. There's a whole lot more detail in the law about this but we won't get into it. The hard part here is how old is the child and how do I write this?
38:47 If the child can't read it then somebody else has to be read it or the parent has to read it and understand it. In the EU obtaining parental consent is required for anyone under 16 and in the UK it is anyone under the age of 13.
39:10 Reporting breaches. If you detect a breach you've got to take care of it, that means you've got to report it. You've got to have policies and procedures to be able to detect it, investigate it and you need to have an incident response plan. You've got to report these personal data breaches to your Supervisory Authority within 72 hours after awareness of the breach. There are a lot of problems when someone is breached and they don't do anything about it or they try to cover it up. Don’t go there. If an individual is facing an adverse impact, you have got to contact that individual directly.
39:58 With the pseudonymization that we talked about earlier, you may be able to mitigate this if all of your data was encrypted and that's all they got. If it was very hard or almost impossible for them to turn the encrypted data back into PII then you can say, “Well I don't need to inform all of those people.”
Data protection officers. There's a provision in the regulations that says that you should have a data Protection Officer if you're a certain type of a company. Typically these are public authorities or bodies with really large systematic monitoring of huge amounts of people on a large scale. Maybe there are health records or large amounts of personal data for various types of items that you're collecting like convictions or offenses. If so, you may want to say, “Hey, this is a big enough deal, we have so much stuff, we need to have a Data Protection Officer defined.” There are some rules about who that person can report to and what some of the roles are. Even if you don't fall into one of these big company categories, we highly recommend appointing either a person or a group as a data Protection Officer, or at least a committee. It’s very important that DPO needs to have knowledge, support and authority to carry out his role effectively.
Things get a little bit murkier in the U.S. for companies without a physical presence in the EU. According to some sources, GDPR addresses this issue by requiring companies without an establishment in the EU to designate a representative located in the EU. You may read some of these things and say, “Oh my gosh, what am I going to do?” Don't freak out, just go figure out what this is. Let's wait for the law to be defined a little bit more etc. The best thing you can do is start working on the things that you have direct control over. I don't think that this means you have to run out and hire somebody in the UK just so you can say that you do this. React with reasonableness. They make this statement, “Data Protection by Design and Default is an express legal requirement in GDPR,” and to me that's kind of an understatement. It reminds me of the Star Wars movie when Anakin said to Obi-Wan, "Why else do you think we were assigned to her, if not to find the killer? Protection is a job for local security, not for Jedi. It's overkill, Master, and so an investigation is implied in our mandate." So likewise this quick statement has a whole lot of stuff that's implied. Implementation of effective data security measures applied to your systems and processes is implied in that Data Protection by Design statement. Security is an implied mandate. This one statement itself can create a myriad of other data protection and security requirements that are not specifically defined by the GDPR law but are well known to the data security industry.
So you may be familiar with many of them as we said if you're undergoing PCI DSS or ISO or SOC or other security assessments. You can use things like the Data Protection Impact Assessment, that's an ISO risk assessment process, to figure out what's critical in design and implementation. We're going to talk about that a little more on the next slide.
Data Protection Impact Assessments need to be conducted when specific risks might affect the rights and freedoms of data subjects. Things like, if a new technology is being deployed you need to do another one. Obviously, you should do one at the beginning as you're starting this. If a profiling operation is likely impacting individuals significantly, you need to do one. When there’s a large scale processing of special categories of data, you need to make sure you are doing one. It's almost the same process as defined in the ISO 800-30. It's a risk assessment that we use to gather information from your data mapping exercise.
44:29 Security Considerations. We're getting close to the end. Again, that one statement implies a lot of things. Here at SecurityMetrics we have forensics division that does investigations after the breach and here are some of the main things that are causes of a breach. Number one is remote access security, through insecure remote access. That's Data Protection by Design. You should have this in place. You should do web application security design. You should have good web edge firewall security. You should be doing external vulnerability scans to check if essentially all your doors are locked and nobody can see in the windows of your websites and other systems. Wireless network password policies. Malware prevention. Physical security. All these things. On top of that there are some Best Practices. You should be getting a penetration test. You should do encryption or pseudonymisation of data. You should do file Integrity monitoring. Security training. Patching. Internal vulnerability scans.
45:29 The lists go on and on. These are things that in my mind are implied by that one simple statement in the GDPR. So what are our quick takeaways? Start working on privacy and disclosure documents. Start reading about the law. Do some data mapping as soon as you can. Performing the risk analysis and GAP assessments is going to be important in your business. And those are the things that you would want to focus on. Many companies help with this sort of thing, SecurityMetrics also does this kind of stuff.
46:06 If you process large amounts of data, make sure that you are thinking about, ”What would I have to do to see how close I am to following some of these requirements.” Don't ignore this law. We are available for questions.
46:23 Just so you know, here at SecurityMetrics we will have some GDPR early bird pricing if you'd like to go through some of those early early adopter tools. This will help you get ready. I think we have just a few minutes to take some questions and I'm happy to do that at this time. Thanks Gary.
That was a great webinar and it covered a broad range of topics. We had several questions come in. So what we'll do now is try to address some of the questions that are more broad and that apply to the largest amount of people here in attendance today. We probably will go a few minutes past the hour so you're welcome to stay on if you have a little bit of extra time. If not again, this is being recorded and we will send this recording out to you.
47:28 So one question that we had come in a few times during the webinar is, “Can I get a little bit of clarification on who the GDPR is directed to? Is it just to the EU Community? Is it more Global? And as a result of brexit, does this still apply to the UK?” So here's what I know. GDPR is directed towards data of EU subjects. So if you are a company that gets data that may contain individual personal information about somebody who lives in the EU whether you are in the EU or not, this law applies to you. So if you're in the United States and you are getting data from people in the EU then it applies to you. If you are in Brazil and you're getting data from people in the EU it applies to you.
48:32 So it doesn't matter what country you are in, The EU is saying, “This is our data. This is the data of the EU people. We want our data to be handled well.” And that's what it applies to. As far as Brexit goes. The UK will probably have something either identical or very similar to GDPR. I would assume that it's going to be identical. The ICO office in the UK will be the ones that are going to be managing that so it's probably no change. I don't know what the subtleties might be for international interaction in the EU and the UK's version of GDPR when all that happens, but I wouldn't at this point worry about it. I would just say let's just consider that it is all the same.
49:34 Great. Another question that we had come up a few times is relating to small businesses. “How does the GDPR impact small businesses, especially for those with minimal credit card transactions?” Small businesses have smaller risk. And I guess it's the same as with any data security law. With PCI, small businesses are required to do less as far as validation goes in that space. You don't have to have to have an on-site audit and other stuff. However, it still applies to you. And if you are negligent and lose data, even if it's a small amount, there is a potential that you may be found out. If my data is lost and is being used and it's and it's discovered by an SA or reported to an SA then regardless of your company size, you're going to be subject to these laws. So you better have some sort of preparation and defense. I don't think it really matters there. There might be less things to do. Maybe you do try to do more stuff on your own or maybe you work with a company that can help you out. That's up to you.
50:54 Great. Another question that we had come in. We had quite a few people asking about the right to Erasure. Can we get a little further clarification on that? For example, how does it impact organizations that are required to keep information for a certain amount of time and also how to interpret for cloud-based services.
51:18 So for the first part of that question, there is a provision in the Erasure area of GDPR that says yes, you may need to defend yourself legally. So let's say I'm a forensics company and somebody says, “I don't want you to keep any of my data that was lost in this forensic,” for whatever reason they say, “I want my data erased.”
51:52 You can say, “Sorry, we need this for an ongoing legal investigation so no, we won't.” So yes, there are different things that can can be reasonable and accepted exceptions to saying “Erase me and all of my of my traces.”
52:14 For example here at SecurityMetrics. We have to keep security records of audits that we do for three years. It's just part of something that we're required to do by a number of entities. So we do that and we wouldn't erase it even if somebody asked it to because we're being required by another entity to keep it.
52:32 So those kind of things you could do as long as you can defend it. Don't just ignore it, think about how you're going to defend it. They're reasonable people in these organizations as far as I understand. The other half of that was “How to interpret for cloud-based services.”
I don't know that I would interpret it any differently for cloud-based services.
53:08 Either your computer is in a cloud or your computer is not in a cloud or your contracting with a company like Salesforce or others to store data for you. You may need to address that with them and talk to them and say, “How are you helping me make sure that the data that I send to you is secure.” GDPR has parts where it says you've got to go outward a little bit and make sure that you're making correct decisions.
53:38 You know, I wouldn't go with Steve's local contact list if he doesn't really care or want to do anything about data security. You want to go with somebody who understands some of these regulations. Awesome. All right, so we have time for just a couple more questions here. We did have several people say that they are also complying with the PCI DSS and they asked if we could briefly go over that again. “For those that are PCI Compliant, what is the level of effort required to comply with the GDPR? Are payment card details protected under GDPR?” So absolutely, payment card information is protected under GDPR. Parts of that data are personally identifiable, obviously. So is it in scope? Yes. If you're already PCI DSS compliant, if you're a small store and the only PII data that you're getting is in the form of credit card information (names, addresses, etc.) on the chip or in the swipe or typed in or whatever then your scope may be identical. So, you need to feel really good about the security guidelines if you’re complaint, you've done well.
55:11 There may be some other things like opt-in, data, privacy notification, documentation and process. The first part of GDPR has a lot of documentation and a lot of process. The last part which says, “Do Data Protection by Design,” is the PCI part. You may have security policies and procedures in place for security and PCI DSS, that would be helpful in GDPR but it's not going to be all of it. So is the work less? Indeed it is. Can I give a percentage? I really don't know. It depends on if you take those names and addresses and send them to a Marketing Group and does the Marketing Group do something different with them. Do you send information to a sales group that does more stuff? I don't know. That's that's going to be your decision. But be careful about scope when you're using any part of your PCI data and sending it to other places.
56:13 All right. So one more question. A few people would like a little more clarification on breach notification.
56:24 Notification of breaches. We probably don't have a lot of time to go into that other than you have 72 hours to notify your Supervisory Authority. Or if you are a US company and don't have a presence in the EU then I would assume you have to inform all Supervisory Authorities of the people whose data you may have, so that could be a pretty big task. As far as incident response and breach, if you're if you're worried about it, then make sure you have an incident response procedure well-documented and written down. Then you’ll know who to call, when to call and who's going to be responsible to call. Have a little book they open up so they can just go through the steps and don't have to run around going, “What do we do, what do we do?” Know exactly what you should do, practice it in your mind, think it out and do your best to to report it. I’ve found that it's always better to report than it is to hide. A lot less money exchanges hands that way.
57:32 Another question. As far as the timeline for processors and controllers. Is it 72 hours from when a processor tells the controller? As soon as you're aware of a breach you got 72 hours. If you're a processor, you have SAs and if you're you're a processor for a controller then yeah, I would let the controller know within the same amount of time. And if you're a controller and know that one of your processors has a problem, then there might be two pathways and this might be getting reported by two different entities, the controller and the processor.
58:15 All right. Well, I think that's all the time we have today for questions. Apologies if we did not get to your individual question during this webinar. But again, if you did chat in a question to us today, we will be reaching out to you on an individual basis. Thanks everyone for your attendance today for our GDPR 101 webinar and look forward to seeing you in our next webinar.
.svg)
