DISCLAIMER: The following is my opinion on the self-assessment questionnaire (SAQ) process and cannot be relied upon. Only your acquiring bank can definitively tell any merchant which SAQ they should provide to their acquiring bank.
Based on the comments I got back on the first SAQ post, I thought I ought to gather that information together into one location and share my thoughts on what the PCI SSC is thinking. The problem that small and midsized businesses (SMB) are running into is that no one SAQ meets their needs because they have multiple methods of conducting credit card transactions, from face-to-face to telephone to eCommerce. And that is the problem. Since there are multiple ways to conduct a transaction, no single SAQ will cover all of these transaction methods. And since an organization is only supposed to fill out and submit one SAQ to their acquiring bank, the question becomes, which SAQ should the organization use?
Let us face it; SAQ D is just not the SAQ any organization wants to fill out. Organizations are trying to avoid SAQ D like the plague because it is “ROC-lite.” But unfortunately, if your business model does not fit within the strict criteria set forth with any of the other SAQs; your only option is to fill out SAQ D. And that, my friends, is the rub.
But that does not mean that everything in SAQ D applies to your organization. However, before everyone starts marking the majority of requirements in SAQ D “Not Applicable,” let me point out that the requirements in 9 and 12 will always apply to any organization filling out SAQ D regardless of how many ways organizations conduct their credit card transactions.
So how does an organization keep their sanity and fill out SAQ D? In my very humble opinion, you use the other SAQs that apply to your individual transaction types to guide you in filling out SAQ D. For example, your organization has an entirely outsourced eCommerce site (SAQ A), but you also have data entry of phone and mail orders over a PC using the eCommerce site (SAQ C-VT) and you have a portable card terminal that you conduct transactions at seminars (SAQ B). Use the three SAQs (A, B and C-VT) as templates for filling out SAQ D. That does not mean that there will be some other requirements in SAQ D that an organization might need to address. However, the majority of SAQ D will be filled out and then an organization can review their SAQ D to ensure that everything that is relevant is covered.
My work with SMBs has given me an appreciation for why organizations want to avoid SAQ D. SAQ D is not a simple task and takes a lot of time and effort to prepare, both of which SMBs do not necessarily have in abundance. However, if your organization intends to accept credit cards for payment for goods or services, then through your Merchant Agreement with your acquiring bank, you are contractually bound to abide by all relevant PCI standards. So, either you stop accepting credit cards for payment, or you own up to the fact that the PCI standards are just another requirement of doing business in our electronic age.
I wish I had a better answer, but there is not one.
PCI Guru 
I absolutely agree with your comment #26 22 June 2011 (I often come back to this thread when thinking through which SAQ to apply). The problem though is if those are the only controls applied, then how do you answer all the other requirements in SAQ C-VT? To be honest SAQ C-VT seems a huge overkill for the situation of small volumes of care data being input by an employee at a workstation straight into a PSP hosted web page over https.
You have to mark any requirements as “Not Applicable” and then explain your rationale (i.e., WHY) for marking them as such. It’s not as easy as you think constructing a good rationale as you also may have to explain what efforts you went through to prove a requirement is not applicable.
There are company which act has service providers and also merchant. In such cases
1. Does the company have to do PCI DSS assessment for both as a service provider and merchant separately?
2. OR can they cover both the scope in a single AOC as a service provider? If yes then how can we mention in AOC of service provider? Would a status update letter from the QSA stating that both the infrastructure are covered in scope of AOC for service provider will suffice (In cases when VISA tracks the company individually as service providers and as a merchant)?
Also please share the relevant documentation from PCI if any?
Q1 – Yes, they will do a service provider SAQ D or ROC and then whatever SAQ/ROC as a merchant and separate AOCs for each assessment.
Q2 – Such organizations can combine the compliance assessment fieldwork such as documentation, interviews and observations where it makes sense, but such scope overlap is not going to likely be significant in my experience.
I am not aware of any FAQs on the PCI SSC Web site that covers this situation.
Do courier company need to comply with PCI DSS compliance if they are delivering Welcome Kit (contains credit/debit cards) containing cardholder data? (Note : where these cards are not activated)
No. But you should educate your couriers on protecting those kits.
Should credit/debit/forex card distribution vendors must be PCI DSS compliant as they have physical access to cardholder data in the welcome kit (Note : where these cards are not activated)? Will PCI DSS be applicable to vendors as they are storing physical cards in their environment?
Typically the distributor is also the issuer so they would need to meet the PCI Card Issuer standards. PCI DSS compliance would not be necessary if complying with the Issuer compliance.
If a merchant is having CNP and CP (Fully outsourced) engagements with the bank where the merchant is not storing CHD, so can they fill SAQ A and SAQ B IP respectively or they have fill SAQ D Merchant?
Also will Payment brand accept this 2 SAQ’s or not?
The Council has recommended either doing one SAQ D or multiple relevant SAQs. But it is up to your acquiring bank to tell an organization what they will accept.
Can you please share the relevant documentation from PCI if any?
See FAQ #1082 at https://www.pcisecuritystandards.org/faqs for the discussion.
Our company supplies software to customers and our staff provide support remotely from their office PC to customer site server. The customer software display full credit card numbers one at a time even the staff do no need to see the credit card number.
If our company go for PCI compliance, does the above exposure is considered in our scope?
Your staff have access to processed, stored or transmitted cardholder data and possibly more. So, yes, they are in scope and so are all of your related policies, standards and procedures.
Good Morning PCI Guru,
I’m an IT auditor and one of the questions I have for organizations is if they completed their SAQ. Often it’s “no” and they know it. If I had an organization that told me they completed their SAQ over the phone with their bank, would this be plausible? I can call the bank to see if it’s their process, but I was wondering if you’ve heard of a mid-size organization completing their SAQ over the phone? And if they had no evidence that they completed their SAQ, does that make them “out-of-compliance”?
Many Thanks,
Dan
It’s rare, but I have heard of instances where the bank does the SAQ over the phone. When I have heard of this it was with merchants that have a card terminal from the bank on either dial up or the Internet. Most mid-level merchants would not necessarily be set up this way, so I would be doubtful about what is going on.
More common are the SAQs that are done via a Web site hosted by a QSAC such as Trustwave or Security Metrics.
In the case of the Internet SAQs, the merchant gets a confirmation of the fact that they did the SAQ. I’m not sure how that would work over the phone if they didn’t get anything back from the bank. Technically, the merchant needs to sign the Attestation Of Compliance (AOC) that is embedded as part of the SAQ.
One thing that I find confusing about SAQ-C is the requirements as they apply to e-commerce. At least two of them seem very ambiguous in this setting. For example:
“Your company store is not connected to other store locations, and any LAN is for a single store only”
If you have your own equipment located at a collocation facility, and your office is across town (where you occasionally use a virtual terminal to process stray charges) do you have 1 store location or 2? Or 0 since e-commerce is inherently non-physical.
For that matter how can a LAN be for more than a single store? Isn’t that the definition of LAN (Local Area Network)?
Also
“Your company’s payment application vendor uses secure techniques to provide remote support to your payment system”
Does this preclude a custom website, written in house, from qualifying as SAQ-C? There is a presumption of a third party vendor included in this statement.
I would welcome any insights into the issues these questions raise.
SAQ C was designed to be used by organizations such as fast food franchisees that have a networked POS solution (workstations and servers) in their retail locations but the POS network does not connect to anything other than their credit card service provider for the processing of card transactions.
Where this usually runs into trouble is that the franchisee has more than one location and they connect all of these locations across a wide-area network (WAN) back to a corporate office for accounting and inventory management. Or, worse yet, the franchisee’s systems are networked, managed and monitored by the franchiser. In all of these instances, SAQ C cannot be used.
The reference to “stores” in SAQ C is not in regard to e-Commerce but to physical retail locations. If an organization has e-Commerce as well, then it cannot use SAQ C and will likely have to use SAQ D.
Thank you for the response. As far as Virtual Terminal, since we cannot use the corporate PC (because it’s connected to corporate email, employee can go to google, yahoo, etc..) the only option we have is setting up a dedicated desktop that employee can use and it can only go to our 3rd party card processor website. The issue is we are a global organization and setting up these types of dedicated machines all over the globe is not practical. So what are the other options we have? Any help is much appreciated.
I have clients using Citrix for just such a solution, You could also use Windows Terminal Services if it is compatible. You just need to make sure that the connectivity to these is over a secure connection. We see too many implementations where they use SSL v2 or DES encryption to connect to these services.
So i think the way this would work is, we would setup one citrix server in our data center, we give only the authorized user ( who will need to process credit card using virtual terminal) access to the citrix server. So now the citrix server is in-scope for PCI and also the desktops that will have access to the citrix server. So how does that help limit the scope? We still need to manage the desktops globally that have access and also the citrix server for PCI compliancy.
The “desktop”, so to speak, that is in scope is the virtual one on the Citrix server. Desktops that access the Citrix server are not in scope because they do not come directly into contact with the cardholder data. You need to make sure that all of the desktops are properly secured, but the Citrix desktop is the important one.
Thank you. The only caveat….there would be no way to ensure that the end user went through Citrix to process the payment vs straight to the website. Is there anything systematically we can do instated of just trusting the user? I am just thinking out loud, we use the DLP product to monitor emails. If we know in advance the desktops that will be processing credit card data via virtual terminal, we can deploy DLP agent on the desktop to restrict user from going out to the card processor website directly or we even put proxy (no DLP required) to restrict desktop from going out to the processor website. Any thoughts on that? I guess there will always be risk of trusting the user. We can’t get rid of all the risk; however, we can eliminate or transfer the high / moderate risks.
You should be able to block the Web site for everywhere BUT the Citrix box through your firewall.
I would still want your DLP solution monitoring everyone including Citrix.
You are correct, it all comes down to the honesty of the user.
Hi, great site! I just have a question about the Citrix terminal solution. We have PCs connecting via web browser to an outsourced payment processor. The user inputs the card details into the browser, which has an encrypted connection all of the way through to the processor. We don’t own or have access to the encryption keys, therefore the card details should only ever appear in memory until that transaction is complete.
Our QSA insisted that we install firewalls and IPS onto these desktops to segment them from the network and reduce the scope. This was also to protect against possible compromise of the desktop system.
How is the use of CITRIX different to, and able to reduce the scope and risk of compromise of CC data in this scenario?
Thank you for the compliment and I am glad you like the site.
You do want to segregate any in-scope cardholder data environment (CDE) from any other non-CDE environment. While physical firewalls can do that job, you can also use ACLs and VLANs to get it done as well. The key is the ability to monitor the CDE so that any anomalies can be identified and investigated.
Thanks again.
So, if the users PCs are using either the Citrix solution, or third party web portal, would you suggest that segmentation of the users PCs would still be necessary?
Thanks
If the users of these PCs are only doing data entry of PANs and do not have access to bulk PANs from the Citrix or third-party systems, you should make sure that these systems are properly hardened, have current, active anti-virus, personal firewalls, are patched current and are monitored, but I would not segment them away from other systems. The key thing is to ensure that these PCs do not come into contact with any malware, keyboard loggers, etc. which would create a compromise.
We have a call center with close to 300 reps, they could receive credit card data via email, phone, fax or post mail… in either case they logon to the 3rd party card processing site to process the transactions using their normal corporate desktops. This desktop has access to email and some other applications. As far as credit card data received via email, email is out there for 1 day at max and then deleted once the card is processes. How do we tackle this situation? I believe as we are taking credit card data via email, we are subject to SAQD. Let say we eliminate email option (very hard to do), would this qualify us for SAQ C / VT SAQ C? Let say we eliminate the email option, looking at your comments about using citirx server so that the scope is only limited to citirx server and not the desktop connecting to the citrix server, would this be even possible when you have 300+ reps who need access to other application to do their jobs?
Thank you in advance for your help on this.
PCI-G,
You have some good points, but I question the way the tone of the article spins the SAQ’s in this sense: The SAQ’s are not a merchant’s Security Policy. Nor are the SAQ’s the requirements a Merchant must contractually abide by. Yet it seems like many merchants and commentators/QSA’s treat the SAQ like they are.
A heads up to all Merchants: The SAQ does NOT outline and define the totality of your responsibilities for PCI compliance.
“According to payment brand rules, all merchants and service providers are required to comply with the PCI DSS in its entirety.” – pci_dss_saq_instr_guide_v2.0 Page 12
So, all merchants have to
PCI DSS Req 12.1: Establish, publish, maintain, and disseminate a security policy that accomplishes the following:
PCI DSS Req 12.1.1: Addresses all PCI DSS requirements.
It is very odd that SAQ-A does not reference 12.1 and 12.1.1, SAQ-B skips 12.1.1 and only SAQ-C has the sentence: “Additionally, you must still comply with all applicable PCI DSS requirements in order to be PCI DSS compliant.” (PCI DSS SAQ C, v2.0 page iv). By putting that sentence only in SAQ-C and none of the others, that almost infers that the merchant only has to comply with the PCI DSS requirements listed on the SAQ they are filling out.
In fact, you could fill out SAQ-A and B with a pristine line of Yes’s, and still be non-compliant per the “PCI DSS Requirements and Security Assessment Procedures, Version 2.0” if you don’t have a Security Policy covers every point of the requirements.
Sorry, I’ll get off my soapbox now.
So, it seems that the most efficient procedure, since you have to have a Security Policy anyways, is to make the Policy first. Put the N/A’s where appropriate for your process with a single sentence explaining each N/A. Then Flesh out the Policy with all the required “authorized list of xxxxx” and sub plans and configs and diagrams etc. (Yes, just a couple of sentences to pass over the most painful part of PCI, but the subject here SAQ’s so…)
If that is all done, then the SAQ’s are easy:
– Take the SAQ that looks to be one level higher than what you think you need and fill in all the N/A’s from your Policy first. Just mark N/A in the Special column, don’t start filling on Appendix D yet. If the N/A’s get you to the level of the ‘lesser’ SAQ, switch to that one, if not, continue with the SAQ you are filling in.
– Finish filling in the N/A’s by copy/pasting the explanatory sentence from your Policy onto Appendix D. Note: only fill out Appendix-D for N/A’s that the SAQ asked you about.
– For the non-N/A questions, go to the pertinent section of your policy, check to make sure it is in order: the policy reflects what you are actually doing and you have any needed proof (your docs, vendor supplied docs, service provider supplied docs, etc.). Then answer the SAQ question as appropriate.
One way to figure out exactly which SAQ you should be filling out, make your bank tell you. They are making money off you, make them help you.
Fackler
Every once in a while I have to calm down and comfort myself with this one heartwarming thought.
“At least I don’t have to deal with FISMA.”
Remember, the purpose of the SAQ is provide basic requirements for cardholder data security based on the criteria for that particular SAQ. SAQs are really focused on very small to small organizations with a single method of accepting credit card payments, not any organizations with multiple card acceptance methods. That is why a number of small and most midsized merchants end up having to fill out SAQ D since they have multiple methods of conducting payments.
In order to keep the process simple and straight forward for these small merchants and to facilitate their compliance, all of the minutia that is contained in the Security Assessment Procedures, aka ROC, is not provided in an SAQ. A merchant that meets the criteria and is filling out SAQ A does not need a whole lot of requirements other than to ensure that any paper-based materials containing cardholder data are kept secure and that they have basic policies, standards and procedures in place to ensure that employees keep cardholder data secure and private. The ROC requirements and other PCI DSS documentation can be used for reference if clarification is needed, but it is the requirements in the particular SAQ that an organization needs to respond.
A lot of acquiring banks are so clueless to what SAQ to direct their merchants to use, that I think your comments regarding SAQs are the result of that mis-information and not the SAQ itself. And that was the point of my disclaimer and some of my remarks in my first post regarding acquiring banks. They have skin in the PCI compliance game and most have yet to get into the game. As a result, we have the mess we have with merchants that fill out SAQs.
There is a consensus with the card brands, PCI SSC, QSAs and other payment professionals that a lot of merchants using SAQs are just checking the ‘YES’ boxes and submitting that to their acquiring bank. In fact, a number of QSACs operate Web sites that allow merchants to fill out SAQs online and those applications only allow for ‘YES’ answers. That is why MasterCard is requiring their Level 2 merchants after June 30, 2011 to either have the merchants assessment staff certified as ISAs or have the Level 2 merchants engage a QSA. Too many Level 2 merchants were just doing the check boxes to comply when there was no real assessment work performed.
And to correct you, SAQs are not based on levels of complexity, number of transactions processed or any criteria other than payment acceptance methods. If a merchant does not exactly fit the criteria of SAQ A, B, C or C-VT – OR – has multiple payment methods, then their only option is SAQ D.
Love this post. Here is another issue, we have 2 processes. Process 1 – 100% outsourced for eCommerce and Process 2 – Virtual terminal for call center reps. So if the mercahnt is only allowed to complete 1 SAQ, we have to go with the most stringent SAQ – SAQ C VT. However, if we use that to assess 100% outsourced process, lot of the questions will be N/A. But since we can only submit 1 SAQ, and all SAQ C VT questions are subject to Process 2, we can’t just submit 1 SAQ with N/A for lot of the questions. So in that case, we now need to submit 2 SAQs, SAQ A for 100% outsourced model and SAQ C VT for virtual terminal process. I have reached out to our merchant bank to see what guidance we get back.
SAQ C-VT covers all of the requirements from SAQ A (totally outsourced eCommerce), so, in my very humble opinion, you only fill out SAQ C-VT to cover both payment processes. However, you need your acquiring bank to approve this approach.
The problem with SAQs comes from merchants that have more than two or three payment methods and there is no other SAQ other than D they can use to report all of their payment methods on a single SAQ.