Many merchants we meet often tells us this: They are not in scope because they only do EDC (electronic data capture) – or payment terminal – transactions and these belong to the bank. Therefore, the bank has to ensure these are compliant and merchants do not need PCI-DSS since they do not store credit card.
Upon this, it’s the prevailing myth that storing credit card information is what PCI-DSS is all about, and as long as we avoid this, we don’t need to be PCI.
While non-storage of credit card does reduce scope SIGNIFICANTLY, it’s not the only thing PCI is harping about. It’s pretty clear in the standard itself:
PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.
I don’t blame the merchants. They already have a hard enough time competing in a new digital landscape of virtual buyers and getting margins from their products – the last thing they need is a consultant coming in, brandishing some sort of standard called the PCi-DSS and the only thing that flashes through their minds is: How much is this sucker going to cost me, now ?
But it is what it is and we try to make our client’s (or in many cases, not even our clients, but anyone who calls us – and doesn’t even need to pay) life easier – and provide enough information for them to decide whether they need consultation, help or go it alone for PCI.
Yes – we technically consult them to potentially not consult with us.
But we believe in the long run, trust is something every consultants or advisors need to earn and it’s not something that comes with the territory. In fact, if I had a ringgit for every joke made about CON-SULTANS…we wouldn’t need to make any more new sales.
Anyway back to PCI. So the question to ask back the merchant is simply: “Great that you don’t store – but do you process card data?”
“No we don’t, the bank does it.”
“You don’t handle card data?”
“Handle? As in physically handle?”
“Yes”
“Of course (now somewhat flustered) – how do we get customer card if we don’t handle it?”
So in that sense – they answer their own question – if they are not there (handling the card), there is no transaction and no processing of card. Therefore, they are involved in the processing of card data. Does PCI apply? Yes, it does.
How does PCI apply?
Again, I am not going into the story of levels (how do be validated) vs controls (what to be validated) – already covered in previous posts on this, recently here .
But before our merchants get discouraged, most of their scope is very limited and in fact, I recommend them to try and go it alone.
Scenario 1
Their EDC connects directly to the bank through a dial up or cellular. No storage of card.O Only flow is to receive card, dip it, wave it and pass it back to the customer. That’s it.
Look at SAQ B. Last check, there are 41 questions. You don’t really have too much complexity in there, except to just ensure information security policy is there, physical security of the EDC is there etc. It’s not that difficult and really, most merchants should try to at least get these done.
Scenario 2
Their EDC connects to the bank via the merchant broadband.
This becomes trickier as this means the card data potentially passes through devices in the customer premise. This also includes when the branch locations sends credit card information back to the HQ and uses the HQ own internet set up to send to the acquirer. Another permutation here is that the acquirer would have their own equipment in the customer HQ where all branch data is consolidated to and sent.
The above scenario is more often found in very large Merchants.
In this case, the best bet we can go for is SAQ B-IP, with around 82 questions. Again, card data cannot be stored (full 16/15 PAN) or Sensitive Authentication data like CVV or track or PIN cannot be stored. In this case, PCI can still accept SAQ B-IP but most of the interim systems will be in scope for SAQ B-IP controls.
The trick here is really the SAQ B-IP requirement:
“The standalone IP-connected POI devices are not connected to any other systems within the merchant environment (this can be achieved via network segmentation to isolate POI devices from other systems);”
This is not as easy as it sounds as many environments still have their EDC all in a flat network as any other systems, and part of the requirement will need these EDCs to be properly segmented out to avoid pulling in the entire corporate into scope. This becomes complicated further if EDCs connect via wireless.
Another thing to be aware of is that you probably need a letter or confirmation from the acquirer that the entire card flow is encrypted end to end – meaning from the EDC all the way to acquirer environment, rendering the merchant environment as simply a transition point. Think of a road, being used by an armored truck that the merchant has no access to, as they do not have access to the encryption keys.
Other than that, depending on the number of segments you have – segmentation penetration testing is probably another headache you need to look at. However, this can be done via sampling, so consult with either the QSA or PCI expert for an idea of what an acceptable sampling is. Due to the risk being rather low, the challenge here is just to ensure that all setup is standardised across stores.
Your EDC shouldn’t be relying on your POS machine to send card data or process. The POS should only be passing transactional information and any information obtained from the EDC should be truncated PAN (if necessary) or only transaction information.
There you go.
With these, you can probably navigate through the initial headache of PCI for your merchant environment! Let us know at pcidss@pkfmalaysia.com if you have further questions! Since we sometimes consult you not to consult us, it would definitely be an interesting discussion!
