With the advent of SAQ A and A-EP, there seems to be confusion as to what meets what for each SAQ. I thought I covered this rather well in my post titled ‘Of Redirects And Reposts’. But apparently that was not clear enough.
For outsourced eCommerce solutions, the criteria from SAQ A states it can be used if and only if:
“The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).”
For some service providers it appears that there seems to be a lot of misunderstandings as to what constitutes “originates directly from a third party”. A lot of processors believe that if their customers’ Web sites are not storing cardholder data (CHD) or sensitive authentication data (SAD) then they are out of scope regardless of the method used to process a customer’s payment. What they seem to forget is that applications that process and/or transmit CHD/SAD are in-scope for PCI compliance just as those that store CHD/SAD.
For SAQ A and A-EP, the Council took their lead from Visa Europe as to what is meant by “originates directly”. Visa Europe’s Processing eCommerce Payments guide has a great matrix that explains the difference between SAQ A and A-EP by payment processing type and merchant level.
With redirects and iFrames, the merchant’s Web server never comes into contact with the CHD or SAD because the customer is communicating directly with the transaction processor’s server. PayPal is a prime example of a redirect and meets the criteria of SAQ A. With a direct post, JavaScript, XML or any other techniques, the merchant’s eCommerce server is at least processing and/or transmitting the CHD/SAD to the processor’s servers. That is because there is some form of code/executable/script/etc. that is running on the merchant’s eCommerce server thus placing it directly in-scope.
Where things seem to get confusing is with processors that offer multiple methods of completing payments. Unfortunately, it also appears to be just as confusing to the processors’ sales personnel as well. We have encountered numerous instances where the processor’s sales people believe all of their solutions make the merchant out of scope when only the redirect/iFrame solution they have provides such a scope reduction. All of their other solutions place the merchant directly in-scope.
The bottom line is that it is extremely important to get the transaction processor to explain how a payment is processed to determine whether your server is or is not out of scope. Even if the sales person says the solution is an iFrame or a redirect, make sure to quiz them enough to ensure that they truly are delivering you an iFrame or redirect solution.
But a word to the wise. Security professionals will question a merchant’s decision to not worry about the security of their eCommerce Web server because there still is a risk even with the redirect or iFrame approaches. That risk is that the code/executable/script/etc. that invokes the redirect or iFrame on the merchant’s server gets tampered with or changed and now invokes a Web site that is not the transaction processor’s Web site. As a result, a merchant’s customers’ CHD/SAD could be sent to Timbuktu and no one would be the wiser until goods/services are not provided due to non-payment.
As a result, security conscious merchants will, at a minimum, ensure their eCommerce servers are properly security hardened, patched current and will monitor the code/executable/script/etc. for changes. Should a change be detected, the server would then be brought offline and fixed to ensure that transactions are properly processed.
Hopefully this provides everyone with clarity on how to use these SAQs peroperly.
One additional thing I would like to point out. If you look at the Level 1 merchant line of the Visa Europe matrix, it shows ROC subscripted with either an ‘A’ or an ‘A-EP’. I point this out because if you meet the criteria of either of the SAQs but are a Level 1 merchant, you can mark all of the ROC requirements not in the respective SAQ as ‘Not Applicable’ and only provide testing evidence for those requirements in the relevant SAQ.
PCI Guru 
Good reading.
I have one question, if the web application service store the last 4 digits of the credit card, would it still be a SAQ A-EP or SAQ D?
Last four of the PAN is NOT considered cardholder data (CHD) by the PCI DSS.
However, that has nothing to do with SAQ type. SAQ type is determined by HOW CHD is processed by the application and whether or not that application comes into contact with CHD in clear text.
Thanks.
That make sense.
I have been reading and researching about when it would be a SAQ A-EP or SAQ D. But I’m not sure yet when one or the other applies.
If the web application comes into contact with the CHD as the user type it manually in the web application form. then this data is sent to let say paypal to process the payment. The web form is coded internal and is not such a iframe (in these cases a SAQ A could be enough). would it be a A-EP or D?.
For the SAQs, is segmentation logic handled similar as in service providers?. I mean, as a merchant you can have the web application, database, and some other servers in the back end. all of those that interact with the web app form would be part of the scope?
Thanks
SAQ A-EP only applies when the merchant is exclusively eCommerce based and is using a payment processing method other than iFrame or redirect.
SAQ D is the catch all and is used when a merchant has more than one payment channel such as eCommerce and traditional brick and mortar. Even then, you can assess the eCommerce using the SAQ A/A-EP as a template, assess the brick and mortar under SAQ B-IP and then combine the two into one SAQ D and mark any requirements not covered as Not Applicable.
Hi PCIGuru,
Thanks for the wonderful blog, and for responding to so many unique scenarios.
I’ve spent a few hours scouring your site and the comments, but can’t quite find the answer to our scenario, so apologies if I’ve missed it.
I work for a software company, let’s call us “Vendor”.
We build web based applications for “Customer A” and “Customer B”.
Those web based applications are hosted by “Hosting Company”.
We have developed some web based applications for our customers that take credit card payments. These applications are obviously hosted by “Hosting Company”.
“Customer A’s” payments work via the “URL redirect” method, so I put them in category SAQ-A
“Customer B’s” payments work via the “Direct Post” method, i.e. our web page accepts the credit card details and passes them through to the bank – we don’t store any CC details. I put them in category SAQ-A-EP.
Do you agree with the above assessments?
Now, if “Hosting Company” are hosting “Customer A’s” system, would they be in category SAQ-A? Or, because they are providing a service that facilitates the payment, are they a “service provider” (SAQ-D)?
Similar question for Customer B.
Where do we fit as the “Vendor”? I’m guessing we’re out of the picture from a PCI-DSS perspective? We have no access to the production environment, that is all done by the Hosting Company.
Thanks in advance.
I agree with your analysis of the SAQs.
Your hosting company is a service provider. Since they likely do not know the transaction volume of your customers, they would assess under SAQ D regardless of what the customers are doing.
As the vendor of the application, are your applications bespoke/unique to each customer or the same with minor changes? If there are only minor changes, the I would argue that the application is not unique and therefore should be PA-DSS assessed and validated. If the application is bespoke, then it would not need PA-DSS assessing. That said, regardless of the PA-DSS, as the vendor, your organization should be also assessed to SAQ D to provide assurance that your development practices comply with the PCI DSS. Not that every requirement would be involved, but network security and configuration is maintained, application development is controlled and segregation of duties are maintained. There could be other requirements involved, but I would ahve to know much more about your organization.
Hi, good reading.
I have one question, when does an ecommerce or shopping cart is considered to be PCI PA-DSS? Instead of just an SAQ A. (If using iFrame).
I ask as we are thinking on implementing a shopping cart/catalog that uses iFrame with Stripe. Some people internally say the web portal initiate the payment process and that we should require PA-DSS to the shopping cart software company. The shopping cart is a third party software and they sell this software to different companies and can be customized, they don’t process, transmit or store CHD, just receive the token for future recurrent payments.
Thx
If the shopping cart is not a part of the transaction process (that should be Stripe) and does not process, store or transmit cardholder data (CHD) then the shopping cart does not need to be PA-DSS validated. The PCI SSC wrote a great guide on this topic titled ‘Which Applications Are Eligible For PA-DSS Validation’ that can be obtained at the Council’s Document Library under the PA-DSS category (https://www.pcisecuritystandards.org/document_library).
HI All, We are looking to reduce our scope. Our vendor said that they will be deploying client side tokeninzation. I am not sure what that means in terms of SAQ. I suspect our scope would go from SAQ D to SAQ A-EP. But I don’t know enough about this to be sure.
I would have to know a lot more about your environment before giving an opinion on SAQ. But tokenization typically is the returning of a token to a payment application for storage in a file/database after a transaction is approved versus returning the PAN.
Thanks. I am familiar with the term “tokenization”, but not “client side tokenization”. It appears to imply that the card is tokenized at the client end when they type and submit it, similar to (but not in technology) a P2PE transaction, but instead for e-commerce. The vendor alleges that no PAN would ever go to our servers, but that would mean that the payment fields can not be hosted by our checkout page.
Some merchant providers, like Braintree, do have this technology.
https://developers.braintreepayments.com/guides/credit-cards/client-side/javascript/v2
Have you or anyone you know heard of “client side tokenization”?
It is much more common in traditional retail when the PAN is tokenized at the swipe/dip of the card in the POI. But I have heard of more and more eCommerce solutions providing something similar with their solutions.
Hi, very good article. I have a quick question. We are currently using checklist A. Our setup is our 3rd party processor delivers the payment page to the customer’s browser via iframe and all processing, transmitting and storage is between the customer’s browser and the 3rd party processor and it never touches our network. My question is: We also display an iframe from that 3rd party within our accounting department in case a customer calls us with a card number update or expiration update (no payment processing… just card updates). Our accountants (from our network) enter that update on the iframe from the 3rd party. Does this exclude us from using checklist A now?
As a merchant, you have an additional payment channel which is that you have phone payments. SAQ A is only for merchants that have totally outsourced everything and you no longer qualify for that distinction.
The accounting PCs are now in-scope because they are used for data entry of payment information. The risk is that a keyboard logger or memory scraper ends up on those systems. I would say that an SAQ C is more appropriate but you will need to confirm that with your acquiring bank.
Is the table (above) from the Visa Europe can be implemented or use as reference in North America?
That table is the basis for the Council’s information supplement on the subject.
In the article, you say: “With a direct post, JavaScript, XML or any other techniques, the merchant’s eCommerce server is at least processing and/or transmitting the CHD/SAD to the processor’s servers. That is because there is some form of code/executable/script/etc. that is running on the merchant’s eCommerce server thus placing it directly in-scope.”
This is not how direct post works. In a direct post JavaScript transaction, the payment processor hosts a chunk of JavaScript in their CDN that is referenced by the merchant’s website. When the merchant’s website loads in the customer’s browser, the JavaScript is downloaded directly from the payment processor to the customer’s browser. The JavaScript executes in the customer’s browser — renders the payment form, collects the CHD, and ships it to the payment processor — all in the customer’s browser without ever touching the merchant’s server. The payment processor then calls back to a JavaScript handler function served by the merchant server (but still executed in the customer’s browser) with the response and a token.
I agree that this still feels like SAQ A-EP because the merchant’s server controls the link to the service provider’s JavaScript, but I want to make sure people aren’t getting the wrong idea about how the dataflow works.
Ref:
https://developer.authorize.net/api/howitworks/dpm/
https://stripe.com/docs/stripe.js
Just as an interesting discussion point, Stripe is working on an update that will stick their whole solution into an iFrame as a method to get their customers back to SAQ A. I’m not sure that I feel that’s a better solution than what they’re doing now — something the merchant controls still has to point to a URL to populate that iFrame — but that’s a discussion for another day.
https://support.stripe.com/questions/what-about-pci-dss-3-0
I agree with your analysis. JavaScript at the service provider is different from JavaScript running on the merchant’s Web site. I was just repeating the matrix from the Visa Europe document. The key is when the code/executable/script/etc. runs on the merchant’s server, it is at a minimum processing and transmitting cardholder data (CHD) and that Web server is in-scope.
Where things get sticky and argued over is when the JavaScript comes from the merchant’s server, executes on the customer’s browser and communicates directly with the service provider. In the opinion of Visa and the Council (and mine as well), if such a JavaScript comes from the merchant’s server, then the merchant has a responsibility to secure/monitor the JavaScript so that it is not corrupted and customer payment information not only goes to the service provider, but is collected surreptitiously and sent to who knows where.
I’d like to avoid the phrase “runs on the … server” because it makes it sound like the JavaScript which handles CHD is executing/interpreted on the server (merchant or service provider) that it is hosted on, which is not the case. So far as the server hosting the JavaScript is concerned, the JavaScript code is just text that is sent to a browser, not an executable/script to be executed/interpreted.
I agree that it’s messier when the JavaScript is hosted on the merchant’s server, but I think fundamental responsibility and the CHD flow are the same.
In this scenario, the merchant website includes the JavaScript that knows how to render the payment form and connect to the payment processor. The merchant server sends this JavaScript to the customer’s browser where it is executed. The customer’s browser is still doing all of the collection and transmission of CHD directly to the payment processor without any CHD every touching the merchant’s server.
While the merchant’s server is not storing, processing, or transmitting CHD, what makes it messy is that the merchant’s server _is_ storing and transmitting JavaScript code that when executed in the customer’s browser will process and transmit CHD. Since the customer’s browser doesn’t have any way to validate what the JavaScript is supposed to be doing, this puts the onus back on the merchant to make sure that chunk of JavaScript isn’t evil.
My concern is around the differentiation between using an iFrame and using JavaScript / Direct Post. I’ll try to explain by walking through the scenarios:
iFrame:
The HTML hosted by the merchant server holds a reference that looks like:
iframe src=”https://www.paymentprocessor.com/iframe_generator/merchant_id/”
If the merchant’s server is compromised, the attacker can change the reference to be their own server which presents altered payment iFrame content which submits the CHD first to an evil server and then to the payment processor
Attack surface: Merchant Server
Skills required: Modify HTML, Create a web app to generate evil iFrame content including some new JaveScript to skim the CHD before submission, Create a web app to accept CHD from added JavaScript
Impact: CHD is skimmed and transaciton UX looks the same
Direct Post without JavaScript:
The HTML hosted by the merchant server holds a reference that looks like:
form action=”https://www.paymentprocessor.com/payment_gateway.asp” method=”post”
If the merchant’s server is compromised, the attacker can add some JavaScript to intercept the form post and send the CHD to their evil server before posting to the payment processor.
Attack surface: Merchant Server
Skills required: Modify HTML, Add JavaScript (to intercept the form submission), Create a web app to accept CHD from added JavaScript
Impact: CHD is skimmed and transaciton UX looks the same
Direct Post with JavaScript hosted by the payment processor:
The HTML hosted by the merchant has a reference that looks like this:
script type=”text/javascript” src=”https://www.paymentprocessor.com/js/payment_app.js”
If the merchant’s server is compromised, the attacker can change the reference to point to their own JavaScript which does whatever they want, including skimming the CHD and sending it off to another evil server before sending the transaction to the payment processor.
Attack surface: Merchant Server
Skills required: Modify HTML, Modify JavaScript, Create a web app to accept CHD from JavaScript
Impact: CHD is skimmed and transaciton UX looks the same
Direct Post with JavaScript hosted by the merchant:
Being the scenario under dispute, we’d expect this to look different, but it doesn’t.
Just like in the previous cases, if the merchant server is compromised, the attacker can alter the JavaScript to send the CHD to their evil server in addition to the payment processor.
Attack surface: Merchant Server
Skills required: Modify JavaScript, Create a web app to accept CHD from JavaScript
Impact: CHD is skimmed and transaciton UX looks the same
Given that the attack surface and impact is the same in all four scenarios and all four attacks can be carried out by breaking into the merchant server, modifying some HTML and JavaScript, and propping up an evil web app to accept the skimmed CHD, why is an iFrame considerd to be more secure? Don’t get me wrong, I’m not necessarily arguing that Direct Post and JavaScript should be SAQ A, but that if Direct Post and JavaScript are SAQ A-EP then iFrame should be as well. Not saying that the Council agrees with me, just looking at the attacks and outcomes and I don’t see much of a difference.
Most of the arguments for iFrames that I’m finding out there boil down to “The Council is aware that a MITM attack against a redirect or iFrame is viable, but in the payment brands’ experience these are detected before significant volumes of cardholder data are lost.” My hope is that this is true because most payment processors who implement iFrame solutions are doing some sort of sanity checking — “I received a post from $IP including $magic_token. Did I recently serve a payment form to $IP and is $magic_token what I’m expecting from them?” — as opposed to because the card brands havent figured out yet how to detect well-architected MITM attacks against iFrame solutions.
IMO, it’s a question of implementation. How is the iFrame implemented and the data sent to its endpoint validated? How does the Direct Post endpoint validate that the HTML form or JavaScript that sent data to it wasn’t tampered with? It all comes down to hard implementation details that are not guaranteed by any given technology. I would love for someone to prove me wrong and provide a technological reason (not “because the payment brands have detected less fraud on iFrame solutions”) why iFrames are more secure.
Your analysis of your examples are absolutely dead on.
This is why a lot of us in the security business do not like SAQ A allowing redirects and iFrames. It’s why smart merchants that use redirects and iFrames are using SAQ A-EP as their template, not SAQ A. It is why good QSAs tell their clients to only use SAQ A if their eCommerce is truly and totally outsourced with no redirect/iFrame.
In my very humble opinion, what drove the Council to allow SAQ A to be used with redirects and iFrames were the hosting providers. They whined and lobbied for that decision because they had sold (some would say lied to) their customer bases on the fact that they had minimized their PCI scope by using their redirect/iFrame solutions. If that had not been the case, then those hosting providers would have had to eat crow and admit their mistake and possibly lost their hosting businesses. So this was all about protecting unscrupulous hosting providers, not securing eCommerce and protecting merchants’ customers’ cardholder data (CHD).
You are correct in your analysis that all four techniques have similar vulnerability to attack given weak controls on the merchant’s server that can be exploited. The only difference seems to be that those merchants who choose a Javascript-based solution are obligated to validate and report PCI compliance; those that choose iframe/redirect are not so obligated. In all cases, the merchant has a requirement to its clients to exercise due diligence and protect the information on the web server. All merchants who use any of these methods should be compelled to ensure controls commensurate with those outlined in SAQ-A-EP are in-place and are functioning. For merchants who utilize iframe/redirect they most probably will not exercise good risk management and carry out corporate due diligence, because they are not obligated to do so as part of their annual PCI DSS assessment.
Where does this http://en.wikipedia.org/wiki/Cross-origin_resource_sharing fall in the chart?
I’m not positive. But the Wikipedia page you pointed me to speaks about XML all over, so that is the column I would look to for guidance.
Hello,
I have a doubt about the inclusion of the web server in scope whenever a redirection or an iframe to the payment gateway is used in a call center environment. If the web page used to select a product is used in a call center environment, it is usual that an event is triggered (and received in the record system) when the payment has to be performed and at this moment, the record of the conversation is stopped in order to not record the payment data.
In this case, I believe that you have to control the code including the redirection of the payment gateway and the code including the event triggered to stop the record of the phone call. So, do you think that controlling these parts of the code and patching the web server is enough? Should the secure development methodology be audited?
Call centers are unique not only because how they work, but also how they interact with cardholder (CHD) and sensitive authentication data (SAD).
Call centers typically use voice over IP (VoIP) which creates its own unique PCI compliance issues outside of call recordings. Then there are the call recordings. The PCI SSC has issued an FAQ on how those need to be secured or dealt with if CHD/SAD is not recorded.
But then you have how the call center operators interact with their client applications to handle orders and payments. Some are Web sites but some are also virtual desktop. While the Web site solutions are typically hosted by the client, the virtual desktop solutions may or may not be hosted by the client, which means the QSA must ensure they truly understand how the virtual desktop solutions work.
As to developing such Web-based solutions, I would recommend that you follow the PA-DSS guidelines for developing secure applications if that application is going to process, store or transmit CHD/SAD. If you are redirecting or using an iFrame solution, then you want to make sure that the code/script/executable/etc. that invokes the redirect/iFrame is secure and only changes when you expect it to change.
Secure coding techniques and training is a must for any developers as you no longer have any guarantees of where or how an application will be implemented.
But secure coding techniques are not included in SAQ A because the redirection to the payment gateway is performed. So, if an application included in the requirements of SAQ A is used by a call center operator, is it the same case where a customer uses a SAQ A application? (I mean in relation with the application requirements, not the call center and operators and desktop machines requirements)
If you are relying on the PCI standards to be your complete security guidance, then you are looking at the wrong documents. Frameworks such as the PCI standards, ISO 27K, HIPAA, etc. are merely baselines for basic security, not guides for proper and complete security (however, always remember that security is NOT perfect). There is no detailed road map because every organization is different, has a different architecture, has different applications, has different risks, has different threats, etc. The PCI SSC, QSAs and security professionals have always stated that to be secure, organizations must go beyond the published standards.
Just because something is not explicitly called out in any standard, does not mean it is not something you need to do.
How far and where you need to go beyond depends on the results of your risk assessment. The threats to a merchant are different from the threats to a manufacturer, different from the threats to a financial institution. The threats also differ based on industry such as the threats to a defense contractor versus a health care firm or a law firm. And finally, size does matter when it comes to security. However, large firms typically have stepped up their security measures. As a result, the attackers are moving downstream to small and mid-sized organizations that do not have as robust a security program either to gather their data or to use them to gain access to the larger organizations.
A risk assessment is what will provide your road map for your organization.
Most call centers use CTI solutions to manage recording.
A CTI application are usually configured to work over one or more different forms, and it is able to detect the fields where the recording server must to stop the record. I think that in this scenario, it is possible to use a SAQ A and you should add the configuration and protection of these agents to the requirements for the personal desktops, in conjunction with the antivirus and personal firewall.
In the cases where is the own web application who notifies to the recording server that must to stop/resume the recording with an API (CTI server), it is possible only when you have control over the payment form, so the web-application does not qualify for SAQ A requirements.
Apart from that, call centers typically report SAQ C or SAQ C-VT.
In my experience, Computer-Telephony Integration (CTI) is very hit or miss in call centers. My experience with about a dozen outsourced call centers, none of them invested in CTI with their call recording systems because they are constantly moving from client to client and CTI cannot be quickly reconfigured for the new client. Where I have encountered CTI solutions is with call centers that use their own technology and have integrated the call recording system with their applications.
Whether you can use SAQ A, C or C-VT for the situations you describe is up to the acquiring bank to determine and endorse. QSAs and others can build a business case for reporting PCI compliance using a particular SAQ. But the ultimate decision as to whether or not you can use a particular SAQ is the acquiring bank’s.
Most of the call centers I deal with conduct a full Report On Compliance (ROC) because they want to be listed on the Visa and MasterCard service provider lists for marketing purposes.
The Man in the Middle (MITM) attack you describe in your third to last paragraph has a more insidious, and likely, bent. The Silent MITM attack is where the iframe or redirect code is hijacked to add an additional iframe wrapper that allows the transaction to process as normal and silently copies the transaction data to the Bad Guys’ server. This attack would cause much less disruption and therefore could take much longer to even notice. Also, if the silent wrapper is programmed to execute from the end user’s machine, then the CHD wouldn’t touch the merchant’s environment and would have no hope of being caught by exit firewalls or traffic monitors.
That sort of silent attack is a big reason why production code should be reviewed and compared against canonical code even when nothing appears to be wrong.
Agreed on the code reviews even when something is supposedly not wrong.
What I describe is not a true man-in-the-middle (MITM) attack when the code/script/executable/etc. is changed on the server.
However, as you point out, there are many ways that a redirect/iFrame could be successfully manipulated to end up with customers going to the wrong payment site.
Good day,
I find I am more confused that ever before.
My understanding of the redirect page was that because of the web site compromise risk and ensuing card data illicit capture, redirect eCommerce merchants (or their outsourcers, for that matter) had to comply to the SAQ A-EP subset.
Your referenced article even mentions it rather clearly to me: “… An e-Commerce solution using the redirect approach is in scope for PCI compliance…”
So here are two scenarios I am dealing with on a daily basis, and any light shedding on your part will be bliss
Merchant A
Purchased and hosts a software kit, that incorporate shopping cart functionalities and those redirect the customer browser to our hosted payment page. No card data is ever sent, either by the customer or us, to the merchant.
My assessment, thus far: Merchant falls under A-EP and we are PSP (RoC L1)
Main risk scenario is the shopping cart web site being compromised and card data sent to Timbuktu, affecting Merchant A
Merchant B
Hosts an informational web site which redirects the customer browser to a hosted shopping cart service. This provider’s solution is very similar to the merchant A solution, only they provide this service to many merchant B’s.
Customer browser completes selection and is redirected to our hosted payment page. In essence, the customer browser was redirected twice and in neither of those cases, is card data returned. Only transaction result.
My assessment, thus far: Merchant falls under A, Provider is RoC A-EP and we are PSP (RoC L1)
Main risk scenario is the shopping cart web site being compromised and card data sent to Timbuktu, thus affecting many merchant B’s
First, service providers can only do either a Report On Compliance (ROC) or an SAQ D as defined by the card brands.
The first matrix in the Visa Europe PDF is very, very poorly worded as is the written guidance from the PCI SSC. Based on Visa’s and the Council’s public comments (particularly those at the 2014 Community Meeting), the second matrix that I published with the post accurately reflects the position that the Council has backed.
As a result, in both of your examples, the merchants would do an SAQ A.
Ok, got it for the merchants
But how would you bring about (rationale behind) PCI applicability to a service provider that only provides shopping cart services, and handles no card data whatsoever ?
That has been the bane of my existence, recently…
(Much appreciated is your time spent here, btw)
You end up with an SAQ D that only responds to the requirements listed in SAQ A and marks the rest of the requirements in SAQ D as ‘Not Applicable’ with the reason being that the service provider redirects the payment process to a third party service provider.
OK, so I have been trying to determine scope for one my service providers and whether I have to require an SOC from them or not.
We, the merchant, have contracted with a service provider that only provides shopping cart services (Similar to Louis above) and they are redirecting the payment process to a third party service provider via an iframe. The Service provider is based out of Europe and does not currently have nor have they ever had a SOC. They do not want to have to be “PCI Compliant” and have bulked at the mention of PCI.
Also, we are going to be required to do an SAQ D since we have other places that we store PAD/SAD in the CDE and therefore are not eligible to do an SAQ A or SAQ A-EP.
First, let us clear up the service provider issues you describe. Your service provider is contracting with a third party to provide payment services. They are still YOUR service provider and are indirectly providing your organization with payment services. If they are truly out of scope, then they should convey you the payment service provider’s AOC for their payment service(s) along with a letter signed by an officer of the shopping cart service provider describing why they themselves are out of scope.
By SOC, I am assuming you mean an SSAE 16 SOC 1 Type II report from your service provider. I would assume since this third party is providing shopping cart services to your organization that they are material to your organization’s financial statements. If true, then your organization will need a SOC 1 report from that service provider. However, a SOC 1 is a report used by your accountants to prove they can rely on the service provider’s financial numbers that are included in your organization’s financial reports. If you want something for your PCI and other security needs, you will have to work with the service provider’s SOC reporting provider to develop testing that will meet your needs under the SSAE 16 SOC 2 framework. Since the service provider is based in Europe, you may also have the additional issue of reconciling the ISAE 3402 SOC 2 standard to SSAE 16 SOC 2 since the likelihood is that the auditor will be European-based.
FYI Storage of SAD is not allowed after a transaction is complete, so I hope that your statement in that regard is a typo. However, being you are from an airline, you are potentially referring to storage of SAD similar to what hotels do. That said, I would highly recommend that you avoid storing SAD and look at tokenization solutions that will get the SAD storage out of your systems.
Not sure what you meant by PAD other than you mean cardholder data (CHD).
If I have a service provider that fits into the SAQ-A scenario, but whose transaction volume is too large to allow an SAQ-D, is it fair game for the ROC to essentially follow SAQ-A? Or does good security engineering come into play here and lead me to add more requirements around protection of the web site that performs the redirect/iFrame?
To be clear for all other readers, I am assuming from your question that your service provider is conducting more than 300K transactions per year per the Visa/MasterCard/Discover definition. If true, such a service provider MUST perform a ROC assessment. A Service Provider SAQ D is not an option.
That said, you can use the SAQ A as a template for relevant ROC requirements based on the Service Provider’s use of a redirect/iFrame BUT … You need the approval of the bank(s) involved with your service provider as to whether or not they approve of such an approach prior to taking such an approach. Until you have their formal, documented approval, all you have is opinions as they are the only ones that can provide a definitive decision.