It still amazes me the amount of effort some people and organizations expend in vain and silly attempts to “avoid” PCI compliance. But an entire industry has popped up that claims to have just such “magical” solutions.
First and foremost is the fact that when your organization signed the merchant agreement to accept payment cards with your acquiring bank, you agreed to comply with the PCI DSS. Unless your organization is willing to stop accepting payment cards, you are stuck with complying with the PCI DSS.
What you can do though is implement solutions that minimize your PCI scope and therefore simplify your PCI compliance efforts. For those of you that need to cut to the chase, here are the ONLY solutions that minimize your PCI scope.
- If you operate a brick and mortar retail store, implement a point-to-point encryption (P2PE) validated solution or end-to-end encryption (E2EE) solution – both with tokenization. Do NOT enter primary account number (PAN) and sensitive authentication data (SAD) through anything other than the P2PE/E2EE terminal. This will reduce your scope to those requirements in SAQ P2PE.
- If you conduct mail order and/or telephone order (MOTO), use a P2PE/E2EE solution with tokenization. Do NOT enter PAN and SAD through anything other than the P2PE/E2EE terminal. This will reduce your scope to those requirements in SAQ P2PE.
- If you have an eCommerce Web site, use a redirect solution such as PayPal or an iFrame solution from a transaction processor such as those available from Vantiv, Elavon or TrustCommerce with tokenization. Implementing either of these solutions will reduce your scope to the requirements in SAQ A.
- If you need to do recurring transactions, do not store card information at all. Have your transaction processor send back reusable tokens instead when a customer puts a card on file. Your processor can also likely provide you with a service to automatically update card expiration dates and card validation codes for a fee and save you from badgering customers to update their payment card accounts every three to four years. How much this approach reduces your scope will depend on your organization’s payment channels such as eCommerce, MOTO, or brick and mortar retail.
There are no other ways to minimize PCI scope other than these. For those that are interested, the absolute minimum PCI scope any organization can achieve are the requirements documented in SAQ A (i.e., a merchant with ONLY an eCommerce site using a redirect or iFrame). There is nothing less. Period. Anyone that tells you otherwise does not know what they are talking about.
An important caveat on this discussion. The more payment channels your organization uses, the less scope reduction you get. For example, if your organization operates brick and mortar stores and also has an eCommerce site, you will have to comply with the requirements in both SAQ A AND SAQ P2PE if you follow my advice. So keep that in mind as you evaluate and implement these solutions.
Yet time and again, I encounter organizations spending lots and lots of time, effort and money on all sorts of “magical” PCI compliant solutions sold by “snake oil” salespeople praying on the PCI uninitiated. They promise all sorts of “magic” that will reduce PCI scope or, worst of all, remove your organization from PCI scope. None of them deliver and people are deeply disappointed when they finally contact a QSA (or worse, their bank calls out the solution) and they find out that the money spent was all in vain and did not actually reduce or remove them from scope like they were promised.
Adding insult to injury is the fact that if the merchant had truly understood the solution and the PCI compliance process, it was all documented in the vendor’s contract as to how much scope reduction would actually be delivered (i.e., not a lot).
Stop spending so much time and money on Rube Goldberg solutions. In the end, they are typically costly, complicated and likely do not reduce scope any better than the solutions outlined above.
The bottom line here is, if it sounds too good to be true, it likely is.
PCI Guru 
I’m currently confused by which SAQ a merchant should complete when using an iZettle card reader. iZettle don’t seem to understand PCI themselves though, see here: https://imgur.com/a/ckBRa8m
My first thought would be SAQ B-IP but that states that no other device other than the POS should be involved in the transaction. The Izettle card reader is a PTS approved device but connects to any old phone/tablet. So from my understanding this SAQ isn’t right.
Really not sure what they should be completing except for SAQ D.
Any ideas?
It appears that iZettle is using the Square approach whereby Square is the merchant of record, not the Art Fair vendor you are purchasing from through their iPhone with a Square reader.
I would like clarification on this statement in your blog:
“If you have an eCommerce Web site, use a redirect solution such as PayPal or an iFrame solution from a transaction processor such as those available from Vantiv, Elavon or TrustCommerce with tokenization. Implementing either of these solutions will reduce your scope to the requirements in SAQ A.”
We used to use the iFrame from Trust Commerce and had a page header, page footer and the iFrame url itself served from our (merchant) web server. While all CHD went through the iFrame and never touched our merchant server obviously not ‘All elements’ of the page, as noted in SAQ A, were served from a third party. Hence, why is the iFrame not SAQ A-EP which says ‘Each Element’ originates rom the merchant’s server or the service provider (e.g. Trust Commerce)?
It has been my understanding that it was all elements that dealt with the CHD that must be processed by the third party’s iFrame and NOT the merchant’s server. I have dealt with the TrustCommerce solution for a number of years and it has always been considered to be covered SAQ A.
“Unless your organization is willing to stop accepting payment cards, you are stuck with complying with the PCI DSS.”
Just wanted to mention here that a well known Internet Service Provider here in Oz have deliberately eschewed PCI DSS and are happily paying a higher transaction % as a result. I don’t know the details of the agreement, but presume it has the blessing of the card schemes and the acquirer.
If an organization decides to ignore the PCI standards, then the card brands and banks will potentially enforce fees per transaction as well as quarterly or annual fees.
“Your processor can also likely provide you with a service to automatically update card expiration dates and card validation codes…”
Tokenizing services can store card validation values? PCI DSS indicates that is a big no-no, so we have been just accepting that tokenization = less chargeback protection due to the sale not validating CVV.
The tokenizing services are usually issuers as well. But technically, anyone can store pre-authorization data as long as they get card brand approval.
Excellent summary. One note though, while for mail order, a P2PE/E2EE terminal solution would be a viable option, for MOTO, there is the VoIP element that needs to considered as PCI-SSC has clearly stated that it is in scope. (FAQ 1153).
As such, while some orgs may be able to get their acquirer to accept the VoIP risk temporarily, most orgs in this situation are better of looking at DTMF supression or SecurIVR redirection solutions from PCI compliant Service Providers. This also has the added benefit of being SAQ A eligible if done properly.
I meant call center btw, not MOTO in the 2nd line
You can also outsource the IVR portion as well, but that can be problematic depending on how your own VoIP transfers the call.
First Data owns Clover. Clover has a P2PE listed solution now. I agree though, E2EE is a conversation worth having.
First Data has a LOT of solutions. But their biggest for E2EE is TransArmor.
New QSA here. First, I love and appreciate your column. Thank you for sharing your experience and wisdom!
I have three scenarios that appear to have a scope even further reduced than those you defined, and I’d appreciate your thoughts about them.
1. In 2015 I had a client who used payment solutions and technology from Square to perform in-person credit card transactions. I contacted the PCI DSS Compliance Manager at Square and was told that Square has signed contracts with key banks (e.g. Chase, Wells Fargo) transferring the PCI DSS compliance burden fully from their merchant customers to themselves, and that therefore their customers had ZERO PCI DSS compliance requirements. [In fact I see a new web page at https://squareup.com/guides/pci-compliance, stating these facts (scroll to the bottom).] Square called themselves a “Payment Facilitator”, but I have never seen mention of this term in relation to PCI DSS compliance (VISA published “The Visa Payment Facilitator Model” in 2014, but that document made no mention of PCI DSS requirements or the Facilitator’s right to assume them on behalf of the merchant). Any thoughts?
2. I have a client who accepts card payments through its website (e-commerce channel) with an outsourced payment page. However, my client’s website redirects the consumers’ browsers NOT directly to the third-party payment page, but to their login screen. The consumer has to take additional steps from that point to log in, navigate to the payment page, and effect payment (strange process, I know). My client appears to have no CDE, and also no systems that can directly affect the security of payment card data. Therefore, the only thing that appears to be in scope is an annual verification of the third party payment processor’s PCI DSS compliance. Am I missing something here?
3. One of my clients provides a service to its B2B partners, whereby it takes first-time credit card orders from consumers over the phone (only) and enters them, on the consumers’ behalf, into the applicable partner-hosted payment website. To my knowledge my client has no agreement with its bank requiring PCI DSS compliance, and the payments never hit my client’s bank account (though my client does get a kickback from the corresponding partner for each transaction). No CHD is stored by my client after the transaction, and the calls are not recorded.
I figure that my client falls under its applicable partners’ PCI DSS compliance programs, and that it is up to those partners to define requirements (i.e. specifying my client as a PCI DSS Service Provider) in their contracts accordingly. To my knowledge no such requirements have been established. While I feel that my client has a duty to protect CHD per the applicable PCI DSS requirements, it appears that any enforcement has to come from the partners whose bank accounts receive the transaction revenue (who should be required in turn by their acquiring banks to ensure this). What do you think?
Square is a unique solution in that Square is the merchant of record, not your client, and Square accepts all the risks and does not require their customer to file an SAQ. A lot of this is due to the fact that the major investor in Square is Visa.
Your second example is SAQ A as that is still the least amount of requirements that any merchant can have when transactions are conducted under their merchant identifier.
In your third example, your client is keying the CHD through their computers. I don’t care whose merchant ID is used, that CHD ends up in the systems’ memory and therefore is potentially at risk. They are also a service provider and must therefore follow SAQ D or conduct a ROC if they do more than 300K transactions. No independent entity EVER falls under another entity’s PCI ROC unless they are assessed by that entity.
I understand what you are saying in regards to Square, but are they really so unique? In situations where the ‘merchant of record’ places a kiosk or other payment acceptance apparatus into a third party host store, does the host store fall under PCI scope at all? Or can (does) the merchant of record accept all risk? Perhaps it would behoove the merchant of record to ask/require the host store to help satisfy elements of requirement 9, for example. But is the host store only ‘required’ to do as much as the merchant of record asks them to do?
You kiosk example is not the same. The third party is responsible for the kiosk’s maintenance and updates. Whether or not the host store falls into scope depends on how the kiosk connects to the internet. If it is not on the merchant’s network, then the merchant is not in scope. Even if the kiosk is on the merchant’s network, the merchant is a service provider to the kiosk vendor.
Then, as a service provider – because the kiosk is on their network, they would need to do their own annual assessment and provide an AOC *OR* participate in an on-demand assessment as a part of the merchant’s own assessment? I think this answers my question:
“The specific type of evidence provided by the service provider to their customers will depend on the agreements/contracts in place between those parties. For example, providing the AOC and/or relevant sections of the service provider’s ROC (redacted to protect any confidential information) could help provide all or some of the information.”
I read that to say, while the service provider would do well to be sure they are not the weakest link, they only need to provide the third-party proof that they are following pertinent PCI requirements so far as their agreements/contracts require them to.
Am I correct or way off base here?
You would be correct.
Thank you. I always appreciate reading your blog and hearing your thoughts on this!
There remains potential ambiguity on E2EE (NESA?!) and the use of iFrame. Validated P2PE and simple redirect are always my first choice.
The only magic here is how easily money disappears from an entity trying to buy a non-existent “magic solution”.
I agree, but the Council still allows iFrame.
On the P2PE front though, the big players (i.e., Verifone and First Data) will never P2PE validate, so E2EE will always exist until the brands force the issue, which they never will because of Verifone and First Data. However, E2EE is not that big a deal any way. It’s a 15 minute problem of some additional work and in some cases it’s even quicker because the solution is coming from the acquiring bank.