Payments Dialog is an ongoing series of conversations with payments experts about payments topics that matter to fast-growing merchants. In each session, we discuss another important subject.

In this session, Peter Mollins and Brian Hendrix from Spreedly talk through PCI compliance and why it’s so important for merchants to understand and comply with these regulations.

Payments Dialog Episode 7: What is PCI compliance for card not present?

Below is a rough transcript of this episode of Payments Dialog

Peter Mollins:      This is Peter Mollins with Spreedly, and welcome to another edition of payments dialog, it's great to have you with us. Joining me today is Brian Hendrix, also from Spreedly. Brian, welcome.

Brian Hendrix:    Thanks Peter.

Peter Mollins:      So today, as I say, we're going to be talking about PCI compliance, and would love to hear a little bit about your background, and what you do at Spreedly, and how that connects into PCI compliance.

Brian Hendrix:    Absolutely. So, from a background perspective, in a prior life to Spreedly, I spent about 10 years in the payment space while I worked at a POS company that did point of sale for higher education primarily. But I've worked with registers, standalone terminals like kiosks, handheld retros as well, mobile devices that process credit cards, and online. So I've seen quite a lot of different types of PCI implementations across the suite of products we offer, and now I am here at Spreedly as a senior product manager.

Peter Mollins:      Well terrific, well it should be a great conversation.

Brian Hendrix:    I absolutely agree, I look forward to it.

Peter Mollins:      Alright, Brian, so first of all can you give us brief overview of what PCI actually is, and what it means within the payments industry?

Brian Hendrix:    Absolutely, I mean, really, PCI compliance is a governing body that's there to help everybody process credit cards safely. We all know from what we've seen with breech after breech, and loss of credit card after credit card, and I think most of us at this point have been touched by some type of fraud. I know I've lost a few card numbers to fraud. This is an attempt to establish some minimum standards by which we should process credit cards. We're going to end up, for better or worse, talking through an absolute ton of acronyms, so I guess we've already used some - unwittingly or not.

Brian Hendrix:    PCI itself and PCISSC is an acronym, so let's maybe highlight a few of these to maybe anchor our conversation. PCISSC, that's the payment card industry PCI security standards council. This is a group that came together so we could hopefully lift ourselves out of the Wild West. Back when I very first started in point of sale, I remember looking on the first server I went to, a little old Unix box, and there were all the credit card numbers sitting completely unencrypted where folks could edit them to an extra kind of void. So that's how most point of sale used to be about 15 years ago. The PCISSC, the PCI security standards council came together from the major brands, and they created the PCI payment card industry DSS - the data security standard in 2006.

Brian Hendrix:    We really wanted to manage the evolution of the payment card industry and get out ahead of this. Visa, Mastercard, Amex, Discover, and JCB - certainly for those of us in America, you might be little less familiar with JCB, but it's the other major brand out there. We really wanted to improve that payment security and credit card security for these transactions. So as it dials into, "Does it apply to you?". If you accept, store, transmit, touch, probably almost even think about, though not quite. But if you process credit cards in any way, regardless of who's doing it on your behalf, you have PCI compliance responsibilities.

Brian Hendrix:    And there's lots of misconceptions around this. One is, even if someone else is handling this for you or someone has told you they can reduce your scope. What they can't do is eliminate it, and we'll talk a little bit more about that I'm sure as we continue on. And one other misconception that's out there: the payment brands and the acquirers are the ones that are ultimately responsible for the enforcement of the standards, not the council itself. So the council's there - think of it as a body that's there to help us understand and comply with the best minimum practices. And then the brands themselves and your acquirer are who ultimately has the stick at the end of the day.

Peter Mollins:      So that's great. Let's talk a little bit about what it means to be PCI compliant, and to be within scope. What does that actually mean?

Brian Hendrix:    Absolutely. At a technical reading of it, to be compliant with PCI means - and I sort of alluded to it a minute ago - you're meeting the minimum standards that apply to you at a very sort of general level the risks, the amount of transactions that you're processing. You've met the minimum, and maybe that's a little bit of a glib answer, but compliance does not mean you're secure. Compliance means you've met those minimums, and one of the things that I always like to point out to anyone when I talk about PCI, or when I've gone out to speak about PCI, is that if you think through every single business that has had breech - and there have been hundreds and hundreds and hundreds at this point, from the very, very large to the very, very small companies, and all of the logos you've seen come across the news.

Brian Hendrix:    Every one of them has at least one thing in common, and that is every one of them thought they were PCI compliant at the time. They had met the standards, or so they believed to be PCI compliant, but in every one that I've researched, in every one that I've read about - I used to read every single one but they've come so fast and furious at this point, it's hard to keep up. The forensics, they did a forensics on their end, ultimately find out that there's something in the business processes, or something in the network's documentation - or adjoining system in the case of one of the most famous breeches - that allowed a breech, and that was actually not compliant with the PCI standards that were set forth, or agreed to.

Brian Hendrix:    So compliance means that maybe at that point in time you were compliant, and you feel like you got your job done, but really it is very important to think of security and fraud prevention every day, it's a big debt in your daily business processes. And that's about being secure while being compliant.

Peter Mollins:      A lot of this comes back to the reputation for the merchant themselves, is that right?

Brian Hendrix:    Absolutely right, and there are some stunning figures out there. You don't really want your business to be associated with a breech anyway, regardless of what type of business that you're in. The damage that this does to you as a business - certainly if you're not already a level one service provider - being involved in a breech, you basically are subject to extra scope and extra efforts from here on out - if you manage to survive the initial fallout of the breech. So it very much goes to your reputation, it very much goes to how well you protect your customers.

Brian Hendrix:    According to one of the recent studies I read, I think the National Cyber Security Alliance, there's a correlation - I don't want to imply causation, but certainly a correlation - that we obviously think about large businesses needing to comply and those are the big headlines we see. But for SMB - for your small and medium-sized businesses - 60% of those businesses go out of business within six months after a data breech. It's not causal, but there's certainly enough of a correlation that I would not want my business to be involved in that in any way.

Peter Mollins:      Yeah, I know, that's great data. Well let's talk about the actual data that's being stored. So, what data is related to PCI, or what data is covered by the PCI mandate or regulations?

Brian Hendrix:    Absolutely. The data applying to PCI, cardholder data - you think about it about, it's just what's on your credit card, right? As well as who you are, so your name's on that card as well. So your cardholder data, a new acronym for us so far in the conversation, we have PAN - that's your primary account number. This is ultimately what makes your card unique, and yours. Those first digits in the card, the bin or what basically identifies, and we know that the first identify if it's a Visa, a Mastercard, or an Amex, and who the issuer were.

Brian Hendrix:    But after that commonality between cards, there's the bit that makes it your card, you very special card that belongs to you. That unique part is the PAN, the primary account number. You have your cardholder name, that's part of the data that's tracked here, the expiration date as well. And those data together are the cardholder data, and these are ones that, if you so wish to store that, and you have a reason to store it, or you have someone store it on your behalf, that's acceptable. These are things that you would use to do things like recurring payments, or when you store a payment method with someone to reuse it again, so you don't have to enter in your credit card every time you make a purchase on your favorite platform.

Brian Hendrix:    This data should be purged, that is the recommendation of the council - that the PAN, the cardholder name, the BIN for the front part of that card number, as well as the expiration date. This data should be purged if it's not being used. They recommend at least quarterly to purge that cardholder data, and storing it obviously exposes you to some risks, so if someone can store it on your behalf that's much better. There is data, though, that's SAD data - so sensitive authentication data. SAD data is sad, it's bad. You never, ever want to store sensitive authentication data after a purchase or transaction, for any reason. And this would be the full track data, so everything that's on the back of the mag stripe, when you swipe a card, what's read in. You don't want to store that, you want that to go away, and to store that data securely - there are methods to do that and to write over the memory, as explained by PCI - or if you work with an auditor to talk about it.

Brian Hendrix:    There's also the CVV, there's about five different names for that, but if you think about it as the three digits or four digits you enter with your card, as well as any PIN - if there's a PIN taken at any point. That data you never store, and no one should store all four.

Peter Mollins:      Okay, now you mentioned the swiping of the cards, so do you think - are there differences between that card present, where you're actually swiping that card, or using the chip or something similar, versus a card not present situation - does PCI differentiate?

Brian Hendrix:    Absolutely, they do differentiate. At the end of the day, you're accepting credit cards, so there's no lack of application here. Really primarily card not present versus card present is used to define - and here we go with another acronym - used to define what level of compliance, what you use to meet compliance. There's further nuance here, but a shorter high-level version would be: if you're taking cards in the stores, or like for my old software that I worked on, on the register itself. You're going to have to answer more controls - you own probably part of that network, you're transferring that data across the network in case, outside of a few very special circumstances, you're self-assessment - if you're allowed, because of your lower volume to self-assess your PCI - so it's called an SAQ, a self-assessment questionnaire.

Brian Hendrix:    You would have a higher number of controls, a higher number of questions you'd have to answer for a card not present, in general, compared to a card not present transaction, where you may just have a website, and you have a little bit less, there's not a physical piece of hardware there in your store, or at your place where the card data is residing even for a fraction of a second. These SAQ levels range from A to D. D is the catchall, and that's where you have a card present transaction, it is being written to memory briefly, and being sent out. Certainly, if you can't prove your way out of D, you answer D - as I recall, that's somewhere in the - 329, changes every now and again - but there's 329 different controls you have to answer. So question to think of.

Brian Hendrix:    SAQ, all the way at the top, the least stringent. That would be a situation where AEP, which is an electronic processor as well, you would think of that maybe as a website, where you have a company that are taking credit cards on your behalf. Very similar to Spreedly's setup, number of other companies where you as a merchant never actually see the card. Using an iframe that belongs to them, whether that's visible or invisible, to collect that card data on your behalf. You never see it, it doesn't really transverse your network structure, and that's just 22 controls. So, they're still very important, and each of those 22 are critical to talk about, but there's a very large range of what you have to comply with, basically - what you have to prove to be in compliance.

Brian Hendrix:    You can think in an SAQA, there's actually someone else doing a tremendous amount of work on the other end. A business like Spreedly, who is taking on a lot of that PCI burden for you, by giving you a tool to limit your own scope. You have to have a partner.

Peter Mollins:      Okay, so when you talk about these partners - and one of the things I've heard you mention before - are SAQ eligible service providers, I think they're called. Is that right, what is it that they do?

Brian Hendrix:    So SAQ eligible, again they're eligible to fill out a self-assessment questionnaire, they're part of the payments flow. But ultimately - and I'm going to go with the definition as written on this one to make sure we get it just right. It's a business entity, that is not a payment brand, but is directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity, or another business. You would think, in this case - Spreedly, where I am - is a very good example of that, or we are. We are not merchant, nor are we the processor, but we help pass that data along, so a service provider in that case. We're not needing to ring up the transaction ourselves, we're not collecting the funds, so we help that transaction along. But we still need to meet PCI compliance, because we're handling that credit card data.

Brian Hendrix:    What is not a SAQ eligible service provider would be someone that provides network services, you could think almost blindly in that case, through a fiber provider, a network provider, a cable modem provider. Otherwise, every body on the planet would be responsible for this. If they can just see this as just another piece of network traffic, they're not really part of facilitating that payments flow. They would not be a SAQ eligible service provider, so protecting businesses like a fiber provider, that type of thing.

Peter Mollins:      Alright, great. So, when you think about the PCI compliance as an audit involved, right, so why wouldn't audit be something - I mean audit doesn't sound very comfortable - but why would you want to avoid that? Let's talk about some of the details of why you would want to avoid that.

Brian Hendrix:    It's a fantastic question, I think it's one of that's on a lot of folks' minds. I'm going to answer it by maybe answering something else first, and then jumping back to it if that's alright. I think the most important thing to avoid is a breech. It's a tough thing with the mindset here. We want to avoid audits if they're costly, when it's difficult to do. But really, we should have first and foremost on our minds - we discussed a little bit earlier - avoiding a breech.

Brian Hendrix:    Looking at another recent study from IBM Security and The Ponemon Institute, the average breech around the globe - when you take a look at all the different ones from the very largest to the very smallest - we're looking almost 4 million, 3.86 million for the average breech in cost to the business, costs all around the business. The cost per record being lost is landing - this year it's up again, I think it's like 15% or so, at around $148 in cost to the business per credit card record that's lost. And for those of us that are here in the US, I've got some further bad news - that we're seeing data breeches in the US and nearly a 2 to 1 occurrence compared to the 2nd and 3rd place, Canada and Germany respectively.

Brian Hendrix:    So any concept of avoiding, embracing even using that term - we want to embrace audits if that's what's the best thing that'll help our business. Embrace the SAQ, we want to make friends with our QSAs - our qualified security assessors. If you need that audit, you should want to get that audit, because it's a lot less trouble to deal with than a breech, for sure. Now, why you would want to de-scope and offload to other parties, like a Spreedly, is because audits can be very costly. They can range pretty easily from a very, very basic merchant - that you're talking about maybe they're running few transactions, and they qualify. If you're thinking as a small merchant, you could probably be talking - based on the SAQ you're able to comply with - that you might be in the hundreds to thousands of dollars. A medium-sized business is likely in the thousands, maybe upwards in the thousands. And then as a large business, easily spending in the tens - potentially in the largest businesses, hundreds of thousands and upward.

Brian Hendrix:    There's a point at which, as well, Peter, that this stops being really an audit cost, and more of a general security cost. A lot of these firewalls and network segmentations we're doing here really are general security for your business, and are useful for a lot of other reasons than PCI.

Peter Mollins:      Okay, great. So now that we've kind of covered the basics, and some of the intermediate elements of PCI, let's talk about the chain of responsibility. So we're talking about audits, we're talking about things where there's clearly responsibility, but who is ultimately responsible to stay PCI compliant? Is it the merchant, is it the processor, who is it?

Brian Hendrix:    Each entity in the chain of the credit card transaction flowing from when it's first accepted on a card swipe, or on a website form, or any other way, is responsible themselves for PCI compliance. From the merchant, from the person that helped you set up that website - or a cash register, or whatever it may be - they're responsible for their piece of compliance. Any parties used to help process those credit cards, right on up to the carding banks themselves. Every body is responsible for their portion of the PCI chain. Think of it very much as a chain where we link together those pieces of controls. There's a responsibility matrix, it might be a bit too far down to go into, but ultimately, taking a look at each of the 12 controls - there are 12, and I think it would take a lot to list them all out and go through them here.

Brian Hendrix:    Certainly, I maybe should have opened the whole thing by saying I'm not a QSA, I'm not your QSA, so go to QSA if you have larger questions. But there's 12 basic principles that govern PCI, and each person in the chain is responsible for those principles.

Peter Mollins:      Okay, so when I was doing research for this, I came across a couple different acronyms. Can you just give me a quick rundown of what they are? SAQ, ROC, and AOC - I just keep seeing these over and over again. Can we talk a little bit about the SAQ, but would you mind just running through these for me?

Brian Hendrix:    We do, so the SAQ and ROC - in almost every circumstance, you would fill out one or the other. The SAQ I mentioned earlier is a self-assessment questionnaire. It's for businesses for qualify, that don't run the very largest number of cards, or that feel that, if they qualify, they feel that they don't need to consult with a QSA - you can fill out a self-assessment questionnaire. These are guided by certain set of levels, which we talked about a little a bit before in the conversation. We could probably have an entire dialog just on how you fit into each one. But there's four basic levels with some caveats, and they demonstrate that the controls that you're saying that you comply with - the way you prove that you comply - to send that off if you're not going to necessarily engage with a QSA - a qualified security assessor.

Brian Hendrix:    The report on compliance, the ROC or rock, as it's often called. This would be for larger service providers, Spreedly is one of those, so we work with a QSA, an auditor that comes in. We process so many credit cards that it's not appropriate to use a self-assessment questionnaire. And certainly, you can always have a ROC, even if you comply to have a self-assessment questionnaire if you're able to do that. You can move up, or have a QSA and auditor help you fill one out.

Brian Hendrix:    But when a ROC is required, then think of it as an internal document. Really, really highly sensitive description of your PCI compliance strategy, security architecture, and any compensating controls to meet all of the requirements that are out there. The QSA that you work with - that's been approved by the council - they're the ones that create that ROC, it's that internal document that really describes everything. It's your PCI everything all wrapped up into one.

Brian Hendrix:    So then you might think to yourself, "Well, if I've complied with an SAQ - if I'm small enough, or my business is appropriate to it, or I have a report on compliance - I can't really share those, that's got a lot of very private data about how I'm compliant. And it would be bad if somebody that were malicious to get that data, they'd know exactly what I'm doing to protect myself.

Brian Hendrix:    I still need something I need to share, that proves that I'm up to snuff with my security. And that would be that attestation of compliance. The attestation of compliance, the AOC, is something that you would request from us, or a service provider that you want to work with. So in the case of Spreedly, if you were to work with us, we would provide our AOC to you, and that's the outward facing proof that we are meeting our obligations under PCI to help you and protect you.

Peter Mollins:      Okay, great, that was very helpful. So, we've been talking about the challenges side of things, but now let's flip the script and talk about how people can address these. So clearly, doing the PCI compliance and the auditing and working with a QSA, or going through the checklist. Those are some good strategies to help you be familiar with some of the standards that are out there. But what are some other strategies that companies can take to ensure they're within scope.

Brian Hendrix:    Absolutely. Certainly if you want to be SAQD, or you want to go for a full ROC with the QSA, you'd be in scope pretty generally, you'll just have a tremendous amount of scope. Your credit card data, when you think about the networks that it runs on, it is any network that it runs on, and then it jumps out to another level as well, there's a hop rule when you're talking about it. So you have to look at the system and any systems connected to those that process credit card data, as we've seen in some of the breeches. Those adjacent systems can sometimes be very troublesome.

Brian Hendrix:    Really, one of the great things you can think about is, "How can I reduce the scope of credit cards within my system, reduce the risk that I have for credit on my system. And there's some really, really clever ways that you can do that, so it makes your compliance a lot easier. But you are just as compliant, if not more so, by following some of these. One of the best ways to do that is not storing or seeing credit cards at any time. Certainly at rest, and making sure that if they are crossing your network at all, that they're really handled by a third party, that is really built specifically to do this. And certainly if you need access to those credit cards again, you have someone else vault those credit cards for you.

Brian Hendrix:    It's a fairly standard industry term at this point to have a third party vault. Some of the gateways do that, Spreedly is someone that can do that for you. We're able to hold those credit cards for you, and we have built a system here that very purposefully is designed to securely hold and store - not the SAD data that we talked about earlier, and the sensitive data [inaudible 00:24:35] track data - the PANS, And the credit card data you would need to do recurring billing, or to do that saved billing. So that way you can de-scope your own application, and not have to comply with the tons and tons of controls that are out there, and have Spreedly comply for those controls for you, and we can do that on your behalf. That's probably the best way to reduce your scope.

Peter Mollins:      Okay, well great. Well, Brian this has been super helpful, but let's get out your crystal ball and then talk about some of the PCI mandates that are coming up in 2019, and what are some things that people should know going forward?

Brian Hendrix:    Yeah, absolutely. So this year there's three things that are changing - that I'm aware of, or are just changed - that are probably worth talking about. Phone based transactions are an interesting one. You'd think where someone calls in and provides a credit card number to someone maybe at a bank of phones, or a customer service person, or somebody taking that credit card over the phone - those are considered to be card not present transactions. And they certainly were afforded scope reduction, you have to train folks that handle credit card numbers, no matter what, that's part of your compliance.

Brian Hendrix:    But what's interesting is those phone-based card not present transactions haven't had an update to the way and methods in which we need to handle those, and the rules we need to follow, since their inception back in March 2011. So just back here recently in November of 2018, there's a whole new set of standards. There are quite a few, and if you think about the changes we've seen in the last 7, 8 years or so. This is going to include things like the fact that almost everyone is using IP for businesses at this point - so technically that's a network, and there's been a big update to those standards taught to you as a merchant if you're taking card not present phone-based cards, to help guide you through the most secure way to do that, so a much needed update. And that's out and available now, you can go to the PCISSC website and get ahold of that.

Brian Hendrix:    Also, maybe not quite specifically PCI, but very much in the realm of what you should be thinking about with your card security, the advent of EMV in America - the chip cards - as everyone expected in the market pushed fraud online. So fraud instances online and bot attacks have, as predicted, have gone up, up, up, and there are more and more breeches being attempted, and more and more fraud based on those stolen cards being attempted. So going in and taking a very hard look at your fraud management solutions and your fraud management strategies - if this isn't something that's front of mind for you, it absolutely needs to be. Having a fraud team, or working with excellent third party fraud vendors, is just going to be critical, in my opinion, over the next few years.

Brian Hendrix:    As we get ahold of this, certainly you see that happening in the EU right now with the advent of the PSD2, which drives SCA - more acronyms, I know - but think of it as an attempt to make sure that we prove better that the person using your credit card is you. This has been pushed very hard in Europe - it's going to be required this year in Europe - and we're beginning to see in America as well, with California passing a recent back ballot measure to protect credit cards better as well, and identity. Definitely have that in front of mind, whether or not it's exactly PCI.

Brian Hendrix:    And then finally, it's a bit of a fine hair for this conversation to split, but there's a difference between just the regular PCI standards - so PCI standards are met by merchants, folks that take credit cards, someone that's standing in front of a register, a business that has that, or someone that runs a website and accepts them, accepts the funds from those credit cards. There is a whole different set of standards for folks comply to that, for example, like I used to - create register software. We're not actually running that software, but we still need to make sure we're setting up vendors that use register software for success. And that's called PADSS - or at least have been for years - payment application data security standards. Those are getting a big heavy look in the coming year.

Brian Hendrix:    And this, what used to be called a PCI - payment card industry - PADSS that these types of vendors that create that software for you on registers or kiosks to comply to, are being changed out for a new PCI software security framework. So we're all looking forward to that, and the new standards that are coming out, and I guess will all be the newly coined, PCISSF. And if you have card present transactions, if you have point of sale systems, kiosk systems, this would be something I would recommend looking into now if you're unfamiliar with it. And talking, really, to your vendors, as it applies to them mostly - find out what their plan is. I believe that that's rolling out now, and vendors will be able, as their PADSS compliance dates come up, they'll be complying with the new PCISSF - so just make sure talk to them about their strategy.

Peter Mollins:      Okay, terrific. Well, this is a really critical topic, and Brian, really appreciate your thoughts and perspective on it. This has been good fun and really interesting.

Brian Hendrix:    Well, thanks so much, and happy to answer any questions that come up after this. I actually enjoy it quite a bit, it's wonderful to be able to help folks.

Peter Mollins:      That sounds great, Brian thanks again, and to everyone out there, again, thank you for joining us on this edition of payments dialogue, and we'll be back in the near future with another great payments topic. So, again thanks very much.

Brian Hendrix:    Thank you.