It’s this time of the year: PCI audits. Web apps mature, payment methods evolve, and so does PCI DSS.
There was a time, when I used this document by Visa to explain the implications of different payment workflow integrations; among them
- iFrame based forms, that get loaded from a Service Provider entirely
- iFrame based redirects, which open a site that gets loaded from a Service Provider entirely
- and last but not least DirectPost
Many QSAs would put this into a SAQ A-EP, simply because it’s possible and it means business.
Reality meets PCI DSS
The encrypted data (from the CSE process) usually gets sent to the Acquirer / Payment Service Provider via an API, that is hosted by the Merchant.
These API calls submit the encrypted credit card data. In theory it is also true, that encrypted data can be in scope of PCI DSS, and that it’s possible that an entity is not eligible for an SAQ A (ROC), simply because of that.
But it’s also possible to do an SAQ A (ROC).
It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.
What does that mean?
This means that you can seek out a accredited professional to review your Payment Service Provider and your integration in order to determine your eligibility for an SAQ A or SAQ A-EP (ROC). Most ISAs / QSAs are well aware, that Merchants in general do not want to do an SAQ A-EP.
- ensure that there is a valid SSL certificate in place
- assess the hosts within the Merchant’s (small) CDE and search for credit-cards
- confirm that the CSE is PCI compliant (PSP has to account for that)
- collect the AoCs from the SPs, colocation sites and Acquirers
Do Payment Service Providers lie about PCI eligibility criteria?
Payment Service Providers and Acquirers can lie. They are not responsible for the compliance of a Merchant entity. They can request an appropriate compliance level from the Merchants they are in business with. Usually it’s not in their interest to enforce PCI DSS.
For the QSA / ISA it is important to know, that the PCI SSC has a QA program. The SAQs or ROCs can get selected for a review. For the respective Merchant it is important to know, that the PCI SSC might flag a report. This can lead to a suspension of the Merchant’s eligibility to process credit cards.
It is in the interest of the Merchant to support the assessor, and to review the evidence sheet. - And to ensure that the evidence sheet contains the relevant policies and procedures, including areas such as the ERP (where the Acquirer reports might go to), Customer Support portals, CRMs, Ticket Systems, PBXs and so on.
A Service Provider does not determine the eligibility criteria for Merchant entities, and does not determine whether they have to do an SAQ A or A-EP. Especially if the Merchant gets breached, they will insist that they only issued basic recommendations, that were not specifically for the breached entity.
So unless the entity went through a QSA / ISA assessment, there is a higher residual compliance risk.
Minding these details is the job of the assessor. The decision is with the assessor, but the reasoning should be sane. Solely relying on a 4 years old document from Visa is not appropriate for a yearly assessment in 2018.
26.02.2018 - published
27.02.2018 - clarifications added