eCommerce Compliance – PCI meets GDPR

Victor Santoyo – Account Executive

Thank you, Val. As Val mentioned, in a moment we’re gonna be speaking on GDPR and some of the basic principles and how they may apply to some practices you may have in place. He also touched on the idea that I’m the usual presenter, so if you’ve been following our webinars over the last six months, yes, I’ve been making an appearance here or there. To be fair to everyone joining today, whether you’re new or been with us before, I’m gonna share a little bit more about myself and who I am.

I’ve been with Sucuri now about three years plus, ongoing now. Born and raised in Miami, Florida. So, if you’re local, I’m happy to share the city with you. I love Cuban coffee, anyone who’s tasted it or enjoyed it knows the immediate benefits of having such. I’m hoping that fuels me today. I’m also the proud new parent to two new kittens that stumbled on my front door a couple weeks back. I know cats and the internet seem to sort of go hand-in-hand, I figured why not introduce them so there they are on your left-hand side.

To the task at hand, why we’re here. Val mentioned, of course, the frenzy about GDPR and the new standard that was put in place about six days ago. What I kinda wanna key in on during our presentation today is sort of: A) what the basic principles of it are. The requirements themselves are long and complex, so there’s not going to be a single solution that will ultimately address and help with the entire regulation as a whole. However, there are aspects of it that can be simplified. So, better understanding and might be putting you in a better position as an organization or as a business to ensure that you remain compliant.

Second item we’ll touch on will be how that may compare to another common compliant regulation most eCommerce businesses follow, which is PCI data security standard. At the end, I’ll touch on a number of items that’ll be essential suggestions and best practices that can apply to both. So, understanding if you have a habit built in already, just extending that habit to accommodate what the GDPR is looking to address is ultimately gonna be very fruitful to you.

Let’s start, of course, with the basic idea. Who does the GDPR apply to? Most have this broad understanding, and I’ve seen some confusion on this, that this is an EU based thing so those in the Union ultimately are gonna be the ones that have to worry about this. That’s not entirely true. If you process data as an organization, business, shop, whatever it is that you accomplish with your online presence, if you process data that includes those that belong to anyone living or working within the EU then you actually will be held to those aspects of the initiative as well. An example would be a US company that might collect the data from European-based members or even employees, as such you have to fall in line with the GDPR standard as well. Keep in mind, understand your audience, understand who works for you. This is gonna be something that will have to apply to you if you do have any presence over in that part of the world.

Chris Hodson … I was combing through a lot of articles over the last few months just better understanding and CSO Online is actually a really good online website for security news and stuff like that, if you wanna look over there. Chris Hodson had this really interesting quote that I liked. It’s part of sort of what the principle that I mentioned in regulation five, but I think it’s a very succinct summary of what we’re looking to accomplish.

“GDPR is concerned with ensuring that organizations have a legitimate, legal purpose for the collection and processing of personal data”.

That’s actually really well put, I think. I think it’s understanding that as someone who may visit and provide information to Amazon or to my security vendor or another provider, I wanna ensure that the data I’m providing has a legitimate legal use and that it’s being processed correctly. I think a good foundation as to where we’re starting and why this is a very important initiative moving forward as data privacy and protection becomes a larger topic of conversation.

In terms of the questions to ask yourself around these two particular points, what are we doing as an organization? These are probably the six questions I think that will probably best help you understand internally, if you haven’t already, what you’re doing as an organization. If the GDPR may not necessarily apply to you but you’re here to understand it more thoroughly, this may also have some good understanding for you as terms of what you’re doing with the data of those that you collect it from.

So let’s start with the first one. Do any visitors that you’re collecting data from, and as I mentioned, including employees, reside in the EU? You have to understand that. Citizens or those that work, this is something that will apply to you. Even if your organization or your company is based outside of the Union. Whether an Indian-based company or working out of the States, if you can answer yes to this question that you have to worry about this as well.

Second question: Do you have a process for breach notification? This is really important. You have to understand that part of what we’ve mandated [inaudible 00:13:02] is that any information or anything that can identify an individual that then has been breached then has to be notified to either your base or to the individual themselves. Do you have a process in place to A) of course, be notified of it and of course to then address that with the people impacted?

Next question: Is your organization aware of what personal data means under this new GDPR standard and how to properly handle that data? I would say that this is really key. The GDPR, and I might have overlooked describing what it stands for, General Data Protection Regulation, this is not an IT, this is not a support or an engineering issue. This is an organizational issue. Anyone that has access to any type of data that can personally identify someone, an individual, needs to have to understand the policies the organization has in place so that we can better be aware of what we need to be doing or how to handle that data. Who should have access to it? Well, we’ll dive into this more but I just wanna hammer this point, this isn’t IT issue, this is organization issue.

Question four: Have you given the visitor the right to access their information? If someone comes asking about where the data is and what is being stored, do you have a way to be able to deliver that data to that particular individual, free of charge, of course? So, that’s something to keep in mind.

Fifth question: Does your organization have a process for erasing a visitor’s data at their request? Online, you might see phrases like, “The right to forget”. Essentially, that’s what this is. The right to forget information. The right for a visitor to come to an organization saying, “We’d like you to scrub the data that you have pertaining to me”. This kinda goes back to some of the other things about your organization that we’ll touch on. Can you access it? Who has it and where can this be done?

Question number six: Does your organization hold and process data only if it’s absolutely necessary? I think this is really important. I think a lot of different organizations and businesses do their best to just collect as much data as possible, “What data can work for us? Let’s stash this data here in this file server and figure it out later”. At this point, especially when it comes to data privacy and protection and the increasing threat of breaches, I think it’s really key that we evaluate the risk of having data that we don’t absolutely need. This type of what will be risk assessment, we’ll touch at this on the end, is important because if you have … It’s no different, and I’ll make this analogy for website developers and owners, if you have software and plugins and tools that are not being used and are just running out of date, if you don’t use it you should lose it. Same applies here with data.

Data. I keep throwing this word around but what applies and what specific things are we looking for for data? The GDPR and the PCI data security standard have two different definitions. We’ll dive a bit now into sort of how they compare and contrast. Under the GDPR, you’re going to see a very thorough definition of what data is, personal data. Ultimately, it’s just anything that would identify you as an individual. Your name, your location, general account number, could be your phone number, it could be your email, anything like that. Anything of that nature is personal data, okay? So, we have to think really broadly about all the data that we’re collecting as it pertains to an individual. Let’s compare that to the PCI data security standard, where we’re more focused on cardholder data. At minimum, this could just be your primary account number. Banking, routing, credit card, whatever method that is. It could also be the name of the cardholder, the expiration date, addresses. Still, it’s very specific to cardholder data. PCI data is included under GDPR but it’s not necessarily the other way around, so that’s just one key differentiation there.

Let’s go a little further. We compare these two major compliance regulations that are very prominent. How do they differ? Where do they differ? First things first, of course, our understanding the scope. We just touched on the data, what the differences are there. The regulations themselves are also very different. I would say one thing understanding is GDPR describe the requirements that you’ll need in order to achieve compliance, whereas PCI will be more specific. They’ll explain how exactly you can achieve that, what expectations you can meet in order to gain compliance for those specific requirements. GDPR is a bit more broad, so it’s more complex. PCI is a bit more narrow-minded, or narrow-focused, I should say. In doing that, it can actually help you working toward GDPR compliance fees. The fees for GDPR, if you haven’t heard of those already, are quite large versus PCI which vary. One thing to note if you’re found in breach of both, and remember, a breach in PCI data security centered will mean essentially a breach under GDPR. The fees will basically stack on top of each other. If you’re found in breach of both that is big trouble, so let’s make sure that you’re addressing both needs. I’m hoping at the end of this presentation you have tools and resources in order to effectively get both done.

The two do cross paths in a number of ways, so what I’m gonna do now is sort of go through a number of examples that allow you to better understand: A) Where PCI data security requirements and those practices can help toward at least taking a step toward compliance in GDPR. I don’t want to confuse you. Because you’re compliant in PCI does not automatically mean that you’re compliant in GDPR but some of the practices that you exercise under being compliant with PCI can help.

Moving along, let’s touch on a few examples. This will be the basic structure here, you’ll have a GDPR article on the left and you’ll have a PCI security alignment on the right. The descriptions here will be more key on the italicized parts so I just wanna focus on that. Let’s talk on the first right. The principles relating to processing personal data. We’ll go into one of the descriptions under Article 5.

“Processed in a manner that ensures appropriate security of data, including protection against unauthorized and unlawful processing, included and against accidental loss, destruction or damage”. Let’s key in on something there: “Protection against unauthorized or unlawful processing”, meaning if there’s been a breach or an improper use of that data. Under PCI, when we talk about some of the measures placed along strong access control measures, there’s a particular aspect where to remain compliant essentially means that you have some of those procedures in place. Especially when we’re identifying your payment terminal, gateway processor and where the data is stored and inspected. Because you’re protecting against unauthorized processing, on a cardholder data if you just extend some of those processes out, or any of those tools that you’re using across all data, can help you in alignment towards making sure that under this article … You can argue, of course, that I’m doing, what I’m perfectly doing to protect against unauthorized access of this data and ultimately loss, damage and all that.

Another example will be data protection by design and by default. This will be another key phrase you might see a lot and because it’s sort of like a good banner phrase, right? Data protection by design, but more importantly by default. By default. This is something moving forward we have to understand, we have to protect against. Making sure that we have solutions in place that validate the permissions granted to users or those who have access to the data. Making sure that we’re auditing any events in which that data has changed, or has been illegally accessed, that’s not up to the data under the GDPR. This falls right in line with that PCI alignment and requirements in cardholder protection by design and by default. It mandates a daily review of your security events and logs to ensure that cardholder data is properly controlled. I mean, if we just expand on and remove cardholder data to just ensure that all data is properly controlled, you’ve taken your step towards ensuring that you have the proper protection by design and by default.

Moving onward, sticking to article 32. One of the subsections there is the security of processing, the ability to ensure ongoing integrity, availability, reliance of those systems and services. The integrity of that system processing that data and all that. That aligns right with the second main section of the data security standard, which is on requirements three and four, securing your cardholder data, making sure the data at rest is encrypted and in transit over public networks, as well. Maintaining the integrity of that data, right? The availability of that data, so even if in a case like this the data is breached, it is encrypted. Encryption is gonna be the key here. This will be something … A practice you might have in place to secure cardholder data will help you on the other side, as well. Another aspect of article 32 is the regular testing, assessing and evaluation of your technical measures to ensure the security of that process. That’s essentially the entire requirement 11 of PCI data security center, where you’re regularly monitoring and testing systems, identifying risks and potential access points that may be unauthorized. If you’re already doing this for your systems to address cardholder data, or maybe it’s built out to address data in general, that is an aligned, perfect, good step where you can ensure that you’re properly testing and evaluating the effectiveness of that.

You’re starting to see, right? There’s a lot of bleeding in terms of how one practice can definitely help with the other. One of the things we actually addressed in some of the questions is risk, making sure we minimize risk. What data do we have? The last example I sort of want to touch on is just that.

Article 35 under the GDPR is essentially data protection impact assessments, you see there. Essentially is an organization or business will assess the impact of any type of processing that is likely to result in high risk and the rights of the individual. Idea realistically being impacting the type of data that you have and the process in which you have it and what risk that carries to those that that data belongs to. On the data security standard that’s no different than maintaining a security policy that deals with the same issues. In fact PCI, as mentioned earlier, will give specific guidance on that. An example of what they’ll ask for, of course, is performing annual inspections upon changes into your environment. So, have you made any migrations in your systems or tools? Have you acquired another business in which now you’re absorbing more data? Have you relocated? Is that affecting how that data is stored?

The next example there, identifying really important or critical assets, threats to those assets, vulnerabilities involved.

Lastly, resulting in a formal document analysis of the risk that you’re seeing there, right? If we’re already analyzing the risk to remain compliant under PCI DSS, then in a sense we’re already doing a similar analysis of risk for the GDPR. One thing, of course is, I keep saying this, expand your scope on that. If we’re only analyzing risk for cardholder data under PCI, what do we need to do to expand our risk assessment across the board? If we can do that without having to take too many new measures on, then great, we’ve already addressed that.

We’re going to go into some of the best practices now for compliance. A lot of this might just be me regurgitating what I’ve mentioned so far, but they’re important keys and they’re important practices just as an organization that you can use. If you’re not necessarily gonna be compliant for the GDPR, or maybe you’ll be moving toward a new business or initiative that may not be compliant for PCI or have a requirement for, these are still good policies to have just in terms of data protection. I’ll go through each of the ones right here but I feel like they’re pretty self-explanatory. Of course the slides that will be made available at the end, you’ll be able to gather this list.

Create a policy on how long data is stored. It can be deleted as soon as the threshold time period for that storage is reached. Essentially, going back to one of those first few questions, “How long are we keeping this data for what is absolutely necessary to have it for?”. If we can dictate that and know that then we can have the policy in place that’ll have answered questions for individuals about, “How long are you keeping this data?”. “Well, we have a policy we keep this data for 90 days”. Great. We know at 90 days, we have a policy in place to remove that data from our storage, from our file server, mobile devices, whatever it is, however it is that we’re managing this data.

Provide access only to those intended to access it. I would tell you that some developers or front desk clerks don’t necessarily have business accessing financial data, like a financial controller should. That’s gonna be one key point to understand. In fact, to that point in terms of who should access that data, you’re also gonna hear a bit more about if you’re a larger organization addressing data en masse or evaluating data en masse, the appointment of a data protection officer. That will be someone, of course, that will have to be included in this conversation so if you’re an organization large enough to warrant that position then that’s absolutely something to consider.

Moving on, making sure you’re monitoring those that are accessing those systems and the data itself. Making sure that we’re, again, auditing changes in order to identify anomalies or unusual events relating to the handling of that data. So, if something happens, being able to identify that. Establishing a work flow to warn those data protection officers or whoever else you need to alert, whether it’s a sysadmin or anyone else, about the integrity of that data being compromised or breached. Ensuring that the data you have is rendered unreadable anywhere it’s stored. That can be portable media, backup drives, logs, wherever it is that you have that data physically located. Making sure it is rendered unreadable. This is something that’s specifically dictated in PCI DSS, something that absolutely helps in your GDPR compliance and essentially it’s the encryption of that data. We touched on that earlier, data at rest and all that.

Finally, and I kinda wanna keep highlighting this one, the internal assessment of the data your organization collects. Create an assessment of risk for that. Identify whether it is an actual need to store that data. If you don’t use it then lose it. It’s ultimately gonna be something that will pay dividends down the line so things don’t slip through the cracks. If you can properly identify [inaudible 00:29:28] you have, then you know what you’re looking for. Then if you know what you’re looking for, basically you run through this list again. You know how long it needs to be stored for, who should access it, etc. etc.

Having said that, thank you for the time. I hope everyone took something away from here, whether it’s a good practice or an understanding that everyone under your roof is under the same page, just remember this isn’t an IT issue like people like to deflect a lot, this is organization. Everyone should be on the same page and know what this means and how to best handle data that we’re ultimately responsible for.

With that, of course, that means Securi, as well, is committed to the protection of the data we collect. We’ve taken measures, of course, to ensure our compliance, including upgrades to our products and work flows, to our contractual terms of service and privacy policies, which are readily available on our site. You’ll have my email at the end. If you need a direct link you can reach out and we can provide that after the webinar. As well, we’ve done extensive reviews of our existing processes to ensure that we’re meeting and exceeding the requirements mandated by the GDPR. Of course, some of you may require this so if you need a data processing addendum, there’s an email there at the bottom that you see, gdpr@securi.net. It’s the best place to reach out and even ask anything related to our compliance or anything that you may need related to this initiative.

With that, I will hand it back to Val and I would be happy to address any questions. Before doing so, just want to make sure if you want any more information about other things related to GDPR, PCI compliance, which we talk on regularly, we do have a newsletter that you can subscribe to. It’s also available on our blog on the sidebar in which you can register. Val, with that, if you have any questions I’d be happy to take them.