Self-Assessment Questionnaires

I have received some interesting questions of late regarding various scenarios and how to fill out specific self-assessment questionnaires or SAQs.  The troubling part to these questions is that they are totally misinterpreting how to apply the SAQs to particular businesses.  As a result, I thought it was a good time to discuss the various incarnations of SAQs and how they apply to various businesses.

For those of you unfamiliar with the PCI SAQs, there are five; A, B, C, C-VT and D.  The first four are designed for very specific business scenarios and D is the catch all when none of the previous four seem to fit.  In the QSA trade, SAQ D is referred to as Report On Compliance (ROC) ‘Light’ because any organization that has to fill out SAQ D is essentially going through all 12 PCI DSS requirements, albeit on a reduced scale.  If your business does not fit the criteria for the other four SAQs, then you are expected to use SAQ D.

The first important fact about the SAQs is that they can only be used by merchants classified as Level 2 through 4 or Level 2 service providers.  And the most important fact, while anyone can give you an opinion regarding which SAQ your organization should use, only your acquiring bank can officially determine which SAQ your organization should use.  That said, in the front of every SAQ under a section entitled ‘Completing the Self-Assessment Questionnaire’, the SAQ documents the criteria for using the particular SAQ.  If your organization does not meet all of the criteria, then you cannot use the SAQ.

SAQ A is designed for merchants that have no brick and mortar stores such as those similar to Amazon.com.  In addition, the merchant must be totally outsourcing its processing, storing and transmission of cardholder data to a third party such as Level 3 or IBM and those providers must be PCI compliant.  Finally, the organization cannot be storing cardholder data electronically.  However, the organization can have paper reports and receipts that contain cardholder data, but those documents cannot be received electronically.

For SAQ B, your company needs to go back to the “stone age” of credit card processing.  The organization must be using stand-alone card terminals or manual embossers also known as a “knuckle buster.”  In the case of a stand-alone terminal, the terminal cannot be connected to a network or the Internet.  No cardholder data can be stored electronically.  The organization can have paper reports and receipts that contain cardholder data, but those documents cannot be received electronically.

In SAQ C, we get to versions; the standard SAQ C and SAQ C-VT.  The original SAQ C is for organizations that run integrated point of sale (POS) systems on a network that only connects to the Internet for authorization and does not store cardholder data.  To qualify to use SAQ C, the organization must meet the following criteria.•    The payment application system and the Internet connection are on the same device and/or same local area network (LAN);

  • The payment application/Internet device is not connected to any other systems within the organization’s environment (this can be achieved via network segmentation to isolate payment application system/Internet device from all other systems);
  • The organization’s retail facility is not connected to other retail locations, and any LAN is for a single retail location only;
  • The organization retains only paper reports or paper copies of receipts;
  • The organization does not store cardholder data in electronic format; and
  • The organization’s payment application vendor uses secure techniques to provide remote support to your payment system.

Where most organizations go wrong with the original SAQ C is when they have an integrated POS that connects back to a corporate network.  Remote management is allowed in this environment, but the entity that remotely connects must not have unlimited or uncontrolled access to the POS environment.  We have run into a number of instances, particularly in the fast food and hospitality/hotel industry, where the franchisee’s POS solution fits the SAQ C criteria.  However, upon further investigation, we find that SAQ C cannot be used because the POS environment is connected managed from the franchisee’s corporate office or it is managed or connected to the franchiser’s corporate office.

New for version 2.0 of the PCI DSS is SAQ C-VT.  This was developed to handle virtualized environments.  Virtual can be either full on thin clients such as a Wyse terminal or a PC where only a browser is used to process cardholder data.  However, the same connectivity requirement remains in that the thin client or PC must only connect to an acquirer, processor or third party.  Finally, and the most important aspect for this SAQ, cardholder data can only be entered manually.

So those are the rules surrounding using SAQs.  Hopefully all of you small merchants can now figure out which SAQ to use.  However, remember, please consult with your acquiring bank on which SAQ to use before you pick one.  If your acquiring bank gives you no idea, then use this posting to make your choice.


108 Responses to “Self-Assessment Questionnaires”

  1. December 10, 2020 at 3:38 PM

    Hey, Guru, I am Glad to write again I have been wa a long period of rehabilitation after a Stroke I suffered, but Thanks to GOD I am back and rocking again as a QSA, recently I was reviewing a SAQ B-IP, But and there is an inresting Question about ASV compliance for the merchants in these cases Merchants Elegibles for these type of SAQ mostly rely in acquirer service provider infrastructure to comply with this type of assessment, so ASV must be a responsibility of those service providers right, but what happens if merchants and acquirers are connected through private MPLS connections no, public IP adresses exposed?

    • December 11, 2020 at 10:25 AM

      Glad to hear you survived your health issue.

      If the POI are on a private network with no public interfaces, then conducting an ASV scan is not possible. This is the same for organizations that have no PCI in-scope public assets such as with call centers. AS such, the organization will have to respond that ASV scanning in ‘Not Applicable’ with the explanation that this is because there are no publicly accessible POI and a description of the procedures (i.e., Nmap scans, etc.) that were performed to confirm that fact.

      • December 22, 2020 at 8:27 AM

        But, guru What about the firewalls on the stores managing the connections between the stores and the acquirer? Those must have a public up interface to establish vpn

      • December 25, 2020 at 9:57 AM

        In the case of P2PE/E2EE the traffic is encrypted between the POI and the acquirer so the firewall is out of scope. In the case you mention, yes the firewall would be in scope if the firewall is the VPN endpoint.

  2. 5 H
    August 1, 2018 at 2:23 AM

    I am asking about travel agencies who are using 2 separate ways for card-present payment: POS connected to the acquirer banks and Virtual Payment Terminal provided by Amadeus. They have no PCI DSS compliance obligations required by their acquirer banks but the IATA obliged them to comply with PCI DSS for the following scope: Payment via Virtual Payment Terminal provided by Amadeus. As the compliance scope is limited to the virtual payment terminal, we plan to use the SAQ C-VT. My question is the following: As the virtual payment terminal accessed by an Internet-connected web browser is NOT the only payment processing way through the Card-present (face-to-face) channel, could we still use the SAQ C-VT ? If not, could you please tell me which SAQ should we use for this case?

    • August 1, 2018 at 10:03 AM

      Your choice (provided your acquiring bank approves), would be to do the SAQ C-VT as you suggest as well as a separate SAQ that would meet your POS requirements such as SAQ B-IP or SAQ D.

      It is important to note that ONLY your acquiring bank can approve what SAQs to use and how many they will accept.

      If you acquiring bank only wants one document, then SAQ D is your only choice but you can use C-VT and your POS SAQ for templates as to what requirements need responses and what requirements will be marked as being Not Applicable.

  3. 7 Gabriel
    July 31, 2018 at 2:15 AM

    Please i have two questions.
    1. What SAQ is a payment gateway provider / payment processor suppose to fill? is it SAQ D?.
    2, Are payment gateway providers meant to comply with all 12 requirements of PCI?

    • July 31, 2018 at 7:55 AM

      Service Providers only have one choice in an SAQ and that is SAQ D.

      Payment gateways are required (as is every organization), to comply with hose requirements that are relevant to their environment. For example, if your organization does not store SAD/CHD, then requirement 3 should not be relevant to your assessment.

      • 9 Gabriel
        July 31, 2018 at 8:12 AM

        For payment gateway providers who are to be accessed or be PCi DSS certified for the first time, what merchant level category will they fall into? level 1,2,3 or level 4 merchant. Having in mind that they have not had any transaction volume currently until after passing their certification?

      • August 1, 2018 at 9:59 AM

        Your organization is NOT a merchant, your organization is a Service Provider, so you need to look at the Service Provider Levels for the card brands you will process.

        For Visa and MasterCard there are only TWO levels, over 300K transactions processed and under 300K transactions processed. American Express, Discover and JCB have different Service Provider levels that you will have to research if you will be processing those brands.

        If teh organization has NOT processed any transactions as of yet (I find that hard to believe since how could they be in business), that would place your organization at under 300K and you can do an SAQ D.

      • 11 Gabriel
        August 2, 2018 at 2:02 AM

        I am most grateful for your answers. i appreciate. you are doing a wonderful job.

  4. 12 Adarsh
    June 6, 2018 at 11:46 AM


    My question is that whether a company can file multiple SAQ’s for each of their environment or does it have to be one SAQ for whole company? For example, can the company file one SAQ each for B2C, B2B and MOTO if all those environments are separate.

  5. 14 Robert Chilcoat
    March 27, 2017 at 10:46 AM


    Thank you for the information in the blog and the comments. This has been a helpful read. However I do have a question I am a bit confused on regarding what SAQ to use (C or D) as it pertains to receipt details. If a company is thinking of using a PCI-DSS semi-integrated solution utilizing end to end encryption to enable our kiosk to take payments from customers. In your blog it says:

    “-The company only retains paper reports or paper copies of receipts.”

    However in the SAQ C Before You Begin page goes a little further in the criteria description and adds “and these documents are not received electronically.”

    If the semi-integrated solution the kiosk software company is planning to use returns perforated receipt data along with the approve/decline response and a token, does that mean the SAQ C is not an option because it received the receipt details electronically, and a SAQ D would be required?

    Thank you very much for your guidance.

  6. November 10, 2016 at 2:06 PM

    My Question is not about the forms as much as the testing. I know we are behind the times with a dial up unit but we process very few and usually small amounts $100 or less. I know we are SAQ B but how do meet the training for personnel to be aware of tampering. Do we have to hire someone to train one of us, what do we have to do to meet this requirement.

    • November 16, 2016 at 5:15 AM

      No. You do not need to hire anyone to train your staff. You simply need to make all of your staff aware of the fact that skimmers can potentially be placed on your customer facing point of interaction (POI) aka card terminal. I would recommend taking pictures of a device you know is correct and has not been tampered with. Post those pictures near the device and have someone inspect the device at least once a day. If they believe it has been tampered with, have them not use the device until someone in authority looks at it.

  7. 19 Ash
    August 5, 2016 at 5:13 AM

    Hey mate,

    quick question, there have been some changes to SAQ A with version 3.2. Just wanted to understand their applicability for an iframe set up, where the merchant’s own website is hosted by a third party using an iframe provided by different PSP.

    So the addition of requirement 2 and 8, will this only apply to the web server (and DMZ firewalls) that is hosted by merchant’s hosting provider? or are we talking about the same scoping principals here? e.g. data flowing back and forth from that web server to other backend systems by merchant (not containing any cardholder data).

    Also, in requirement 9 around physical security of SAQ A, the question says “For purposes of Requirement 9, “media” refers to all paper and electronic media containing cardholder data” – contain here refers to systems storing cardholder data” this won’t apply to merchants using iframes who are not receiving any reports or scanning any physical receipts?

    Appreciate your thoughts on it.

    Kind Regards,

    • August 5, 2016 at 7:10 AM

      The new requirements apply only to devices owned and operated by the merchant on the merchant’s network. Those operated by any third parties would be covered by the third parties’ PCI assessments.

      As long as the merchant does not store any CHD on their own computer systems or in their paper files, then those requirements in 9 regarding media storage would not apply.

      • 21 Ash
        August 5, 2016 at 7:21 AM

        Thanks mate, if the service provider’s environment isn’t PCI compliant (as previously no one would have thought the webserver will be in scope) then the merchant will have to make sure that their service provider implement these controls?

        Also, will it be just the web server or are we talking about associated firewalls, and the web applications as well?

        Also, when you say merchant systems, can you please provide an example as unless those web servers are hosted internally by the merchant itself I am struggling to come up with any examples. Are we talking about the admin aspects of iframe or hosted page where merchant can logon and view past transactions?

        Many thanks,

      • August 5, 2016 at 3:57 PM

        Yes, the merchant is responsible to ensure that a non-PCI compliant service provider implements the appropriate controls.

        If the Web server provided by the third party is performing a redirect or using an iFrame for payment processing, then it is technically out of scope for PCI but the controls in SAQ A still have to be addressed. Any other payment processing approach would put the Web server and associated network infrastructure into scope for PCI.

        As you are finding out, scope of outsourcing environments can become tricky. We are talking about any administration or management of pages, applications or services that could impact the security of the payment process/transmission or related payment information (processed, stored or transmitted).

      • 23 Ash
        August 8, 2016 at 7:55 AM

        Thanks mate.

        So in this scenario where the web server performing the redirect is outsourced to a third party are we saying we don’t have to worry about those controls in SAQ A or will that third party still need to apply these controls (as part of their compliance or otherwise)?

        What do you mean when you say any other payment processing approach would put the web server in scope? The only two methods where saq a applies are iframe or redirect or full outsourcing of payment processing otherwise no?

      • August 15, 2016 at 6:44 AM

        SAQ A was changed for v3.2 and now includes some controls regarding user management because a lot of the outsourced environments are configured and managed by the merchant. As a result, the Council has acknowledged that fact and added some requirements in 2 and 8 into SAQ A. Not that they necessarily apply in all instances, but they also want merchants to include them if they are relevant.

        As you correctly point out, SAQ A can only be used by merchants that are fully outsourced, use a redirect or use an iFrame from their Web site. All I was try to do was to clearly define that any other approach to processing payments from a merchant’s Web site places the merchant’s Web site in scope for PCI compliance.

  8. 25 chris pousson
    March 17, 2016 at 1:53 PM

    Hopefully you can help me here. I am writing a web application that is hosted in the Amazon web service cloud for an organization that uses virtual merchant. They will input CC info into my application which will not store anything but will then transmit the data to their virtual merchant account. They want my application to be a transparent pass through that can get batch reports as well as update CC info. I have to administer it remotely. What SAQ class does that sound like to you?

  9. 27 Ron
    March 15, 2016 at 9:55 PM

    We have a cards wipe terminal the encrypts the credit card data, which is the sent to our PCI compliant POS, which then is sent via Internet to Payment processor.
    Every evening the POS receives a report of the days transactions (Name, amount, date, transaction code and last 4 digits of PAN) which it stores it it’s database.

    Given that the data stored is very limited and PCI compliant (it’s not full PAN, security code, magnetic card data and such), do we still have to do a SAQ D ?

    • March 16, 2016 at 7:17 AM

      Is this your only payment channel? Do you have eCommerce, MOTO or other payment channels. That would be why you are doing an SAQ D so that you cover your retail and other payment channels with one SAQ.

  10. 29 Barbara
    February 28, 2016 at 11:57 AM

    there is also SAQ A-EP for e-commerce from which customers are redirected but merchant has admin rights and is able to modify iFrame or 3rd party payment gateway website. It’s almost as difficult and complex as SAQ D.

    • March 1, 2016 at 5:48 AM

      Thank you for pointing this out. This post was written when v2.0 was out and before the addition of SAQ A-EP and B-IP as well as before SAQ D was split into two different versions. I will have to go back and update this post.

  11. July 21, 2015 at 1:52 PM

    Appreciate all your posting and updates. greatly help people like me. Have one question and applies to SAQ B/B-IP and the CDE.
    I’m a bit confused about the “standalone and not connected to other system” statement on the SAQ B or B-IP.
    Initially, the VX570/520 card terminals were connected standalone and via IP and some on dial-up. That makes them to meet either SAQ B (dial-up) or the SAQ B-IP(IP connection). Now, although still having its own connection, some of our business activities decided to connect these card terminals to their POS workstations using the RS232 (ECR), or USB . Connection was done in order for the workstation to receive the card transaction approval and amount. Note that some are dial-up and some are IP connected. The question is, which SAQ to use if connected to POS workstation?

    Appreciate any information.

    • July 21, 2015 at 1:54 PM

      As long as you can prove that only the total dollar amount of the transaction and the approval/decline of the transaction is all that flows over the serial/USB connection, you can still use SAQ B and SAQ B-IP.

  12. 33 Raul Ramos
    July 20, 2015 at 4:48 PM

    Dear PCI Guru,

    All the while, my idea of SAQ A is the use of a fully outsourced credit card processing by a merchant. The merchant has no involvement at all at anytime when a customer pays credit card. I also remind our merchants that they cannot accept payment in person and access the online site and process the payment because not only the computer becomes in scope but the process becomes a virtual terminal (the merchant typing the credit card on behalf of the customer).

    Per PCI DSS, SAQ A refers to Card-not-present (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS validated 3rd party service providers, w/ no electronic storage, processing or transmission of any CHD on the merchant’s systems or premises.

    Could you please clarify on how the merchant should process the credit card payment for a MOTO? Should the merchant access the fully outsourced online site and just process the credit card just like a customer typing their own credit card?

    I hope you can shed light to my question.


    Raul (UBC)

    • July 21, 2015 at 5:10 AM

      To use SAQ A, all mail order/telephone order (MOTO) would be outsourced to a third party operated PCI DSS compliant call center. The merchant cannot be doing anything other than a Web site redirect or iFrame to the eCommerce transaction processor.

  13. 35 Jonatan Pregliasco
    April 24, 2015 at 6:35 AM

    Hello PCI Guru.
    I was doing some research about the brand new SAQ B-IP and I came up with a doubt.
    The PCI documenation states that you can only apply to this SAQ if your PTS devices do not rely on any extra device to perform the payment transaction (tablet, pos, cell phone, etc) and is propperly segregated.
    What if the PinPads that collect the Credit card data is connected to a lan which allows connection t the payment processor BUT the connection does not go directly from where the PinPad is but it first goes through a MPLS connection to a DC and then it gets connected to the payment processor devices (no other server takes the packages at any time but the payment processor and the decription keys are under payment processor responsibility).
    I’m aksing this cause the SAQ clearly says that you can apply to this SAQ B-IP only if your CHD lan is segregated from any other and in some way since the MPLS is a private link, technically the information took from the PinPad would never leave the merchants private network till it is sent to the payment processor.

    I’m actually thinking about this cause some merchants I’m working with would need to complete a SAQ B-IP or a SAQ C.

    What reyour thoughts about this? Thank you so much in advance for sharing your opinion!

    • April 24, 2015 at 7:22 AM

      You have very adequately explained the risks involved with the example configuration. What you need to do now is convince the acquiring bank that the example configuration meets the intent of the SAQ and get their approval to use SAQ B-IP. The the bank formally approves (i.e., you have their approval in writing), then you move ahead with using SAQ B-IP.

    • 38 Joe
      May 4, 2015 at 2:52 PM

      We have standalone VeriFone dialup terminals that is provided by the bank and would like to switch to dsl. Since the dsl is coming from an ISP and basically connecting the terminal to the Internet, I believe it falls under SAQ B-IP. SAQ B-IP talks about firewalls and scanning, do we need to setup a firewall in front of these dsl terminals even if it is not connected to any other network other than the dsl? Do we need to scan the dsl terminals even though we have no control over the software on the device?

      • May 5, 2015 at 5:23 AM

        The DSL modems should be the responsibility of the telephone service provider/carrier, not your organization unless you bought them. If they belong to the carrier, then they are not your responsibility to vulnerability scan them.

        You are implementing an IP network and that network needs to be protected by a firewall and that firewall needs to be vulnerability scanned to ensure it is working properly. Your firewall should be configured such that the point of interaction (POI) aka card terminal, can only talk to the processor and the only inbound traffic can come from the processor as well. The reason is that the POI will get its firmware updates from your processor. With firewall rules set like that, vulnerability scanning of the POI is not going to be worth anything. I would rely on the processor to manage the vulnerabilities.

      • 40 Joe
        May 5, 2015 at 5:09 PM

        So we need to put a firewall in front of the dsl modem? If we have multiple sites, then we have to implement multiple firewalls?

        On a side note, if we are doing SAQ A because we are redirecting payment to a payment processor (yes, I know the fine line between SAQ A and SAQ A-EP with redirects)…Anyways, since SAQ A doesn’t require scans, does that mean the web site could technically remain on a win2003 server past July 2015 since the site doesn’t process credit card information?

      • May 6, 2015 at 5:00 AM

        The firewall would be behind the DSL modem, NOT in front. Some DSL modems have an integrated firewall which also might be a solution. But that typically requires that your organization owns the modem.

        DSL modems are also routers and as such they can have rules that restrict inbound/outbound traffic. If all you will have on the network is the point of interaction (POI), then you could construct a routing rule that only allows the POI to communicate with the IP addresses of your processor and no other IP addresses.

        However, if you will have more than just the POI on the network, then I would highly recommend a firewall than trying to use the router alone. A firewall will give you much more flexibility in protecting the POI as well as other network devices.

  14. 42 randy
    June 4, 2013 at 1:57 PM

    I too want to thank the Guru for excellent information as I try to understand this for our org. We have a vendor which provides an online job posting service for our customers. When the customer is ready to purchase, this system hand over the customer to PayPal Standard for the customer to enter their credit card and then once processed, they land back on the job site and none of the CC information is ever on our vendor’s system. However, our foreign customers do not like the way PayPal process works and we’d like to explore other options. We believe based on our talks with other processors, we should use SAQ A but we’re not sure as to who should sign this given the servers for the job posting site is not on our premises but our vendor’s. Do you have any advice on this? Also, any advice on alternatives to PayPal Standard you can recommend? Thanks.

  15. 43 Dano
    May 14, 2013 at 11:41 PM

    Great article but even after reading all the responses I’m questioning our particular case’s SAQ requirement.
    We only have a website, no phone orders. Our web application talks to a 3rd party provider, however this information is entered (not stored) on our website (SSL) which talks to their API (Zuora).
    So we don’t store, but we do pass that info on (securely).
    I understand your disclaimer about the bank having the final say so just after your general advice on this matter.
    Keep up the great work!

    • May 15, 2013 at 1:31 PM

      Based on your description, I am assuming that your Web site has the code that invokes the card processing frame/window. That puts your Web site in scope for at least transmission and possibly processing depending on your Web application. As a result, I would say you need to be doing an SAQ D.

  16. 45 Barb
    April 23, 2013 at 2:15 AM

    Thanks for your informative website, it’s great to finally find one that is clear!

    I am struggling through filling out a SAQ, and I’m not convinced that I have the correct one. We are a small business, with two physical locations, and a website. We handle credit card details in the follow ways:
    – in store, using stand alone eftpos terminals not connected to the internet, or to any pos systems etc.
    – on our website, which doesn’t store the details, a 3rd party processes the payments for us
    – over the phone, we enter the card details into a virtual terminal using a stand alone computer connected to the internet.

    I’ve informed our bank of the above, and they have told me that SAQ B is the correct form to fill out. However I’m not convinced that it allows for the phone orders. I’m stuck on the first question of Part 2c, the eligibility to complete SAQ B. It mentions in part:

    OR Merchant uses only standalone, dial-out terminals… (it goes on). <– Whilst it is true that our dial out terminals are stand alone, this doesn't allow for our use of the virtual terminal for phone orders??

    What's your take on this – I am going to email the bank yet again to ask…

    For those that have given up on phone orders (I'm about to!) – has anyone considered MOTO transactions? Before we had the virtual terminal, we used to use our stand alone terminal to process phone payments. The reason we moved to a virtual terminal is because the receipt printed by the terminal used to list the full card number and expiry date – we felt this wasn't particularly secure (I don't know if this is still the case). I wonder if moving back to using this function may make the process of PCI compliance easier?

    • April 23, 2013 at 4:43 AM

      I congratulate you on your diligence to do the right thing.

      The issue with the terminal printing the full primary account number (PAN) is most likely a configuration issue. We encounter this all of the time. Why the vendors do not properly configure these terminals for their customers, I do not know.

      If you were still doing your telephone orders over your card terminal and not the virtual terminal, I would agree with using SAQ B. However, as you have found out, SAQ B really doesn’t cover the virtual terminal environment.

      In my opinion, SAQ C-VT is probably the better choice for your virtual terminal situation.

      However, remember, your bank has the official word in this matter and if your bank insists on SAQ B, then fill it out and send it to them as they are the official word in this matter.

      • 47 Barb
        April 23, 2013 at 9:40 PM

        Thanks for your quick reply! wrt the terminal printing the full PAN, I spent years trying to get them to correct it, before finally giving up on it. I will mention it next time we need to get something done with the terminals though, I’d prefer them not to print the full number out!

        My contact at the bank is on holidays, and the replacement person has sent through the SAQ C-VT after I questioned it. I’ve only had a chance to have a glance through it, but two things that stand are the statements “Merchant’s only payment processing is via a virtual terminal accessed by an Internet-Connected web browser” and “This option would never apply to e-commerce merchants”.

        As I said earlier, we also have a bricks and mortar store, and a website, so are also processing payments via terminals and via the internet. The internet payments are handled by a 3rd party (it’s not via a redirect, but newer technology that I don’t understand, our contact at the bank recommended it and said that using it would eliminate our need to be so PCI compliant).

        Anyway, what I’m wondering is, what happens for people running stores that handle payment processing in more than 1 way. Each of the SAQs seems to focus on one payment type only (eg A for web payments, B for terminal payments etc) – what happens when there is a cross over, such as in our situation?

      • April 24, 2013 at 4:21 AM

        You do an SAQ D and only fill out those requirements that fit your operations.

        In your case, use the SAQ C-VT to address your virtual terminal process. Use SAQ B for covering your terminals. Combine those into the SAQ D and fill in any other requirements in SAQ D that are relevant such as those in requirement 12 and 9, but please look at all the requirements to ensure you are not missing something. The remainder of SAQ D for your organization will be marked ‘Not Applicable’.

      • 49 Barb
        April 24, 2013 at 5:51 AM

        Thanks for your quick reply again – I’m off to attempt SAQ D 🙂

      • April 26, 2013 at 3:41 AM

        As a reminder since I neglected to add it in my original reply, any non-relevant requirements in SAQ D should be marked as ‘Not Applicable’ and the reason you believe the requirement is not applicable.

        Good luck.

    • 51 Owen Griffiths
      June 3, 2013 at 7:15 AM

      Hi. We are currently completing SAQ B and are PCI compliant, however we are planning on changing our chip and pin machines to connect via ethernet and communicate with a POS terminal so the total cost is already on the PDQ rather than typing it in manually, rather that the phone line.

      Will this mean we can no longer complete SAQ B?

      • June 3, 2013 at 7:27 AM

        Depends on how your network is configured. If the terminals share the network with the POS, then you will most likely be doing an SAQ C, not SAQ B.

  17. 53 jb
    April 3, 2013 at 8:30 PM

    What about large retail chains that accept credit cards but do not store them? I’m guessing their reporting requirements would be based on transaction volume (either SAQ B or C or ROC, if level 1.) It’s that “storage” that gets me. If they accept over 6mm credit cards but do not store, are they classified as a level 1 and go through the ROC by a QSA? If they are a level 2 but do not store any card data, would they complete a SAQ b or a C?

    • April 4, 2013 at 4:28 AM

      You are forgetting the process and transmit pieces of the equation. The PCI DSS says that any entity that PROCESSES, STORES OR TRANSMITS cardholder data needs to comply.

      We have a number of Level 1 merchants that do not store cardholder data, but they do process and transmit it and they all are required to conduct a PCI assessment and create a Report On Compliance (ROC).

      On the Level 2 front, if you are a Level 2 merchant and accept MasterCard cards, you are required to conduct a full assessment and file your Attestation Of Compliance (AOC) and ROC with MasterCard. That rule went into affect July 1, 2012. See this post for clarification.

  18. March 22, 2013 at 6:43 AM

    Hello PCI Guru, great blog read all posts with interest. My company is a level 3 merchant and in agreement with our acquirer and an information assurance consultancy, we attest to SAQ-C, however I have missgivings.

    All card transactions are ecommerce entered by customers onto websites hosted by an msp or by call centre operators over the phone onto the same web sites. All transactions are over SSL with operator computers segmented on our corporate LAN by ACL’s.

    Our firewall is located on the msp’s platform and managed by them, we connect to this over an MPLS, however we have no sysadmin access. SSL certificates are purchased by us from a CA and keys generated and securely transmitted to the msp for installation onto our dedicated platform onto a load balancer.

    Card data is transmitted from the hosted platform to a third party payment processor who provide us with a token once a transaction has been completed which we can then use for any aftersales enquiries should we need to.

    Refunds and chargebacks are manually processed using a PDQ terminal by our accounts dept which is physically secured in a back room and connected directly to our acquirer. 2 receipts are printed with PAN’s showing last 4 digits only – one goes into storage for 18 months before being shredded and destroyed, the other being sent to the customer via post.

    The websites are developed in house with development procedures incorporating requirement 6 controls on our LAN using a subversion repository, again in a segmented development area. Once code is ready to be launched into a production environment our msp will access our reository and place the latest code into a preproduction environment for live testing before going live for real.

    It is this fact that I think we should actually be completing SAQ-D, your opinion and point of view as ever is most welcomed.

    Kind regards
    Matt P

  19. 56 Robert Diaz
    March 1, 2013 at 9:55 AM

    Appreciate providing PCI information to everyone. Very helpful. I have a question pertaining to SAQs. Our organization has business activities worldwide and they are operating on their own, having each their merchant id, just like a mom & pop operation. Have restaurants, lodging faciilities, golf, bowling etc.. All the credit card transactions goes to only one acquirer. At each location, have activities using SAQ B, C, C-VT and D. Individually, all are Level 4 merchant, can we use just one SAQ D to cover the activities at each location (have 90+ worldwide locations). If so, how will compliance be implemented for each activity. Any info will help make job easier (ISA).

    • March 2, 2013 at 8:19 AM

      You will need to talk to your acquiring bank to get a decision on whether one SAQ D will work.

      That said, I would recommend an approach that does a sampling of your 90+ locations. Not that you need an QSA to do the work, but I would select a sample 30 or so locations worldwide (enough that covers one third of your locations every year) and have them go through the SAQ D as it pertains to their operations. That way you would cover your entire operation every three years. If any location shows up as non-compliant, I would then recommend that the location be assessed the next year to ensure that the issues had been addressed.

  20. January 28, 2013 at 8:19 AM

    My very small business takles orders/requests via the website but processes all payment info manually (for security and ease of bureaucracy or so I’d planned!). Any payments made by CC have the details taken by telephone or fax and I then use my PC browser to access a virtual terminal with Paypoint and this all works very well. I have just had a reminder of overdue compliance and find the process has got a lot more long-winded and basically put N?A whever possible to a whole bunch of irrelevant techie questions like do I chancge the SNMP passwords on all my devices…. It takes me thru to teh ATTEST phase and there’s one question there I am stuck on – ” Merchant accesses the virtual terminal via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment; ” they’re kidding right? a single dedicated PC locked in a sealed vault somewhere with no other connections??? the whole idea of using paypoint is to use any browser anywhere, securely, as needed to process payments safely for all isn;t it???

    • January 28, 2013 at 1:34 PM

      No, that is not what they are saying.

      The PCI SSC wants the computer used to process payments to be logically isolated from any other computers, i.e., on its own network. For example, if you have a small network with three PCs and only one PC is used to access the Paypoint site. That one PC needs to be isolated from the other two PCs. If you are using a Cable/DSL router with a switch on the back, you may be able to logically isolate that one PC from the other PCs by creating a DMZ for the one PC. That one PC cannot be accessible by the other two, it can only go out to the Internet. That will satisfy the requirements.

      If your Cable/DSL router will not logically segregate things, then I would recommend that you purchase one that will do this. There are other ways to accomplish this, but they are fairly complex and would involve a lot of additional equipment.

  21. 60 Sebastian
    August 15, 2012 at 5:21 AM


    We have 3 card machines 2 on broadband and 1 on a phone line. We also have E-commerce all level 4.
    Because we use 1 provider for E-commerce and another for the card machines would you know in your opinion who the SAQ would lie with? your comments much appreciated PCI guru

    • August 16, 2012 at 5:38 AM

      ** Remember, this is only my opinion. You need to confirm this with your service provider and/or acquiring bank. **

      The card terminals would make you eligible to use SAQ A.

      It is the eCommerce that possibly creates a problem. If you have totally outsourced your eCommerce, then you can still use SAQ A. However, if the eCommerce is hosted in-house, then you will likely have to fill out SAQ D.

      That said, remember, this is only my opinion. You need to confirm this with your service provider and/or acquiring bank.

  22. 62 Dan
    June 26, 2012 at 6:08 AM

    Hi There,

    I have an environment with 3 POS Terminals and several internet web pages that collect and process (Not store, I’m told) CC data via an oracle data base (one server) and the POS Application (another server). This is not segmented from the rest of the network. I THINK we need to complete SAQ D, but it may be possible that it’s just SAQ C. Is it the “Storing” of CC data that makes it a “D” or if we merely process the CC Data through our managed apps/servers?

    Thanks Greatly!


    • June 26, 2012 at 6:31 AM

      Remember, only your processor or acquiring bank can actually confirm what SAQ your organization should fill out. So my comments are only my opinion on your situation as you have described it.

      That said, it is how your environment is structured that determines what SAQ to use. Each SAQ has its criteria for use documented in the front section of the SAQ. If your environment does not meet that criteria, then you cannot use that SAQ.

      As you describe your environment, I would say you need to fill out an SAQ D. You have POS terminals AND eCommerce.

      SAQ C is only for the situation where you have POS that is networked and connects only to the Internet for the secure processing of transactions – NO eCommerce.

  23. 64 Enric
    April 24, 2012 at 9:29 AM

    We’re a level 3 merchant that sell goods on-line, as well as (punctually) by phone. With regards to our website, we have found a mechanism to avoid processing any cardholder data (CHD) through our webservers, therefore the CHD just flows between the customer’s browser and our acquirer’s servers. To achieve that, we first store the CHD in our acquirer’s infrastructure, in return we receive a reference ID (“CREF”) and from that moment we just reference this CHD through the CREF value. Because no CHD is processed, transmitted or stored in our infrastructure (network, web and DB servers) we assume we can avoid going through the self-assessment questionnaire for this process (SAQ C-VT I would assume). Is our assumption correct?

    With regards to the phone sales, our operators process order payments receiving the CHD from the customer by phone and entering it into same on-line website described above. In this case I have the following questions:
    1- Should it be enough to assess SAQ A to cover the phone sales?
    2- Is it PCI DSS compliant to ask the customer (by phone) their CVV and 3D Secure PINs to complete the payment transaction?

    Many thanks and congratulations for the blog, it helps a lot!.

    • April 24, 2012 at 12:09 PM

      First, no QSA or anyone other than your processor or acquiring bank can tell you which SAQ you can use. So, regardless of my opinion here, you will need to talk to your processor/acquiring bank to get final approval of which SAQ you can use.

      That said, you have two things going on in regards to processing CHD. You have a e-commerce process and you have phone orders. Your e-commerce is out of scope because it does not process CHD, but you still need to document that fact.

      However, you do not say that you do or do not record your phone orders. If you are recording your phone orders, you need to ensure that the CVV/CVC/CID values are NOT recorded.

      As far as I am aware, 3D Secure PINs should NEVER be requested of any cardholder as they are PINs. All cards have a CVV/CVC/CID value and that should be the only value ever requested.

      Based on your description of your processes, your phone order process is going to drive which SAQ you use. However, until the aforementioned questions are answered, I really have no idea as to which SAQ you would need to use.

      SAQ C or C-VT are the most likely candidates, but there needs to be more detail provided as to how your phone orders are processed and how those phone order PCs/terminals are configured on your network.

  24. April 16, 2012 at 7:24 PM

    I have a company that takes CHD over the telephone and enters the CHD into a Third Party application via an internet connection. The application requires a login ID and password and it is a PCI certified service. The Third Party vendor provides a token back for future reference. Can you tell me if I need to complete SAQ C or SAQ C-VT?

    • April 16, 2012 at 7:56 PM

      Remember, ONLY your company’s acquiring bank or processor can tell you which SAQ to use.

      That said, do the calls get recorded? Is any CHD recorded from those calls? If the answer to either of these questions is ‘YES’, then, in my opinion, you are looking at SAQ D and you need to make sure that the recorded CHD is encrypted.

      Otherwise, if no CHD is recorded, then I would say you could try to get your acquiring bank to agree to SAQ C-VT as long as you meet all of the requirements on page iv of the SAQ C-VT.

  25. 69 celeah
    February 12, 2012 at 12:31 PM

    I own a very small business only e-commerce using Zen Cart on my website (latest version is listed as PA-DSS validated payment application) and have SSL, using Zen Carts Authorize.net AIM payment module (customer enters payment information into Zen Cart [installed on my website, hosted by a webhosting company] which is then transmitted to Authorize.net gateway) what type of SAQ would I be? I have no access to cardholder data. My merchant account says I would be type D because the customer enters the information on my website into Zen Cart – but this seems extreme, as this is how MOST shopping cart software handles checkout processes, most e-commerce follows this type of payment process for a smooth checkout process for the customer. I highly doubt they are all treated as type D. I have talked to other Zen Cart users and they say their merchant accounts treat them as SAQ-A. The main issue seems to be the interpretation of the word “transmission” and “third party” in the case of using Zen Cart on your own website. Can you clarify?

    • February 13, 2012 at 7:14 AM

      The key thing is that ZenCart is running on YOUR server, not a third party’s server. As a result, if your server is compromised, you are the source of the breach, not your processor. Hence your PCI scope is larger than you would like.

      Yes, you are correct that this is how a lot of checkout cart systems work so that a customer gets an “integrated” experience. But from a PCI compliance standpoint, it puts your eCommerce solution in-scope for PCI compliance because it runs on your server. As a merchant, it’s your responsibility to determine what is more important, that “integrated” approach or minimizing PCI scope. I would guess from your question, you would prefer minimizing your scope.

      • 71 celeah
        February 15, 2012 at 12:48 PM

        Thanks for responding!
        If my website was hosted on Bluehost (for example), is that not considered a third party server? I guess that is where I get confused, because the majority of questions on the SAQ-D look like they wouldn’t apply to anything I have control over so much as it would apply to the hosting provider and their network. and questions worded as if I am the one who who wrote the shopping cart software script. It’s not run from my server it is run from their servers. It’s mine in the sense that I pay for the hosting but it’s their servers and their network. I asked Bluehost how they deal with customers asking about SAQ-D network questions and they said they are SAQ-A and SAC-B compliant, and told me to make sure that my merchant account provider understood that I was not storing data. There is very little talk about this on the Zen Cart forums, if everyone was getting treated equally with this it seems like it would be a much bigger thing to discuss on how to fill out the SAQ-D in this common setup.
        So maybe there is a misinterpretation here? If I still technically fall under SAQ-D, I feel like a lot of other merchants in the exact same scenario are getting put under SAQ-A depending on how this is interpreted.

      • February 16, 2012 at 2:20 PM

        This is a common problem with service providers. In one sense, they are a merchant themselves in that most allow their customers to pay with a credit card. However, the services they provide you for your eCommerce site fall under the service provider label and there are only two types of service providers, Level 1 and Level 2. As usual, each card brand has their own criteria for service provider levels, so your hosting company would have to determine their level be reviewing each of the brands requirements.

        Level 1 service providers are required to go through the full Report On Compliance (ROC) assessment process and provide their customers with an Attestation Of Compliance (AOC) that lists all of the services that were assessed by their QSA. So, a service provider may have had their network and network management services assessed but nothing else. So, if you have them manage your servers, you would have to independently assess the PCI compliance of their server management services.

        Level 2 service providers only have to go through the SAQ D process, but still have to provide their AOC in the SAQ D to their customers. Again, if a service was not assessed, then the merchant must assess it. Very few service providers are Level 2.

        Their remark about SAQ A and B do not make sense and are not relevant to your situation.

  26. 73 greystoke
    November 4, 2011 at 2:52 AM

    Great site thanks for the advice, It is being recommended that we can use SAQ B an application vendor, but I have misgivings, we have a property mangement application, which holds ccd, it is hosted in a secure data centre and we have a web interface to it where we can input customer card details, it is not used for payment processing.

    This I assume is considered as Electronic storage of CHD, which I think leads us to using SAQ D. Is there another way to interpret this.

    Many thanks

    • November 5, 2011 at 5:06 PM

      I think you meant that the application holds CVV when you say, “which holds ccd,”. If that is the case, then you application is not compliant with the PCI DSS as CVV, CVC, CID are not allowed to be stored once a transaction has been processed. SAQ B is only meant for merchants that use stand alone terminals or embossers (aka knucklebuster), Based on your description, you do not qualify as you are using an application. That said, SAQ D amy or may not be necessary, but I do not have enough information to provide guidance.

  27. 75 Joanne
    September 1, 2011 at 5:15 AM

    I understand that but surely from a bank they should be supplying top notch trust worthy machines ??

    • September 1, 2011 at 7:26 AM

      It’s not that the terminals cannot be properly secured, it’s that they are not always configured to be secure by the bank or the third party the bank uses to supply them. I know that sounds silly, but we see this time and again out in the field from a variety of suppliers and banks.

  28. 77 Dave
    August 31, 2011 at 6:42 PM

    What SAQ would best apply to this scenario: C-store with a POS system that dials out to process via a third party, no data storage. We import and export sales data and item data via a backoffice PC with an internet connection – single store LAN – through the POS mfr. supplied firewall that doesn’t allow any access except to import and export sales data via the separate POS network. Is that considered enough segregation to fall as an SAQ C?

    • September 1, 2011 at 4:59 AM

      While I can have an opinion, only your acquiring bank can give you a definitive answer as to which SAQ to fill out.

      Based on the information you have provided, I would agree with your SAQ C decision. However, given my experience with these sorts of configurations, I am not comfortable that I have the full picture.

      One key question I have is, does your POS solution also have time keeping, inventory management or accounting solutions as well as POS? If there is some other application(s) running on your POS platform, then you cannot use SAQ C. The other configuration we typically see in these situations is the POS system shares its network with another server that has the time keeping, accounting or other applications. If this is the case, then SAQ C can also not be used.

  29. 79 joanne
    August 31, 2011 at 4:05 PM

    OK I’m having a major issue with all this pci dss and trying to become compliant I’m an saq b and the questions I’m arguing or may be not understanding properly is Requirement’s regarding protect cardholder data 3.2/3.2.1/3.2.2/3.2.3 they are questions asking me does the machine store sensitive data [full track from the magnetic strip/pan number/cvc code] that i rent from a bank . Should it not be up to the bank to answer these questions as i do not own machine.??

    • August 31, 2011 at 6:13 PM

      While I would like to tell you that your bank or its surrogate new what they were doing when they configured your credit card terminal, that may or may not be the case. I cannot tell you how many I have encountered that were not properly configured and were storing cardholder data. I would recommend that you run whatever reports you can to determine that your terminal is not storing cardholder data. You may also want to reference the terminal’s user guide to ensure that it was configured securely.

  30. 81 Joey
    August 10, 2011 at 2:16 AM

    Hi ,

    Great posts and appreciate all your doing to shed light on the PCI DS Standard.
    We use only Paypal for all out transactions online. Each customer checks out and completes the transaction on Paypal.
    i understand we fall under the SAQ A category but do we need to perform an ASV scan of my web facing server. This server is not in scope as it is not involved in the payment process. I am convened we don’t but just wanted a confirmation.

    Appreciate your views.


    • August 12, 2011 at 2:51 PM

      Technically, your Web server is out of scope as long as the PayPal payment is processed nowhere near your server which should be the case in a traditional PayPal implementation.

      However, some outsourced payment processes similar to PayPal can be compromised if the merchant’s Web server is compromised. So you need to know if your payment process is truly segregated from your Web server. If it is not segregated, then you should be scanning your Web assets to ensure they are not a way into your payment processor.

      Then there is just the good Netizen responsibility. Even if your Web servers are not doing any card processing, if you are redirecting or using some API, whatever, you really should be ensuring that you are not a potential breach point that could cause headaches for your other business partners.

  31. 83 M0ss
    June 1, 2011 at 3:14 AM

    Great post, but I have a question for you.
    What do you think about a service provider eligible for a self assessment questionnaire that operates like as a call center merchant? It gets orders by phone (doesn’t store CHD) and simply inserts these information in the merchants’ applications by using a secure web browser. In case of a merchant it can use the SAQ C-VT (that is much lighter than the SAQ D), but what in case of a service provider? It’s seems mandatory to use the SAQ D, but maybe there is a way to complete the SAQ reflecting the SAQ C-VT and motivating a lot of not applicable…

    • June 1, 2011 at 4:01 AM

      It is my understanding that service providers are only allowed to do a ROC or SAQ D. That does not mean that every requirement pertains to your organization, but it does mean that those are the only two reporting forms you are allowed to use.

      • 85 M0ss
        June 24, 2013 at 4:39 AM

        I resume this post asking for an opinion. In such situation some requirements are clearly N.A. (e.g. requirement for the PAN encryption is of course N.A. if no PAN are stored by the entity) due to obvious nature, but what about requirements not so obvious (e.g. requirements 11.4 for the IDS/IPS and 11.1 for the wireless scan)? How the auditor can safely mark the requirement as N.A. on a SAQ D for a service provider as well as the council did for the SAQ C-VT for merchants?

      • June 24, 2013 at 5:44 AM

        11.1 is one of the few requirements that CANNOT be marked as NA. An organization needs to document the procedures used to confirm that unauthorized wireless is not present in their facilities. See these posts for the requirements that cannot be marked as Not Applicable. https://pciguru.wordpress.com/2010/11/03/requirements-that-are-never-%E2%80%98not-applicable%E2%80%99/ https://pciguru.wordpress.com/2011/09/09/more-requirements-that-cannot-be-marked-%E2%80%98not-applicable%E2%80%99/

        When you do mark anything as Not Applicable, you are required to document the procedures you used to determine that the requirement is Not Applicable. Simply stating that a requirement is Not Applicable is not good enough.

        I’m not sure how any organization could mark 11.4 as Not Applicable. While an organization is not storing cardholder data (CHD), you are still likely transmitting it and possibly processing it. Rather than marking requirements as Not Applicable, requirements such as 11.4 and others might better be addressed by Compensating Controls.

  32. May 12, 2011 at 3:24 PM

    I love you, you seem to have the answers! I have been getting headaches over this for over a week now, and it looks like (after reading your other posts) there are more to come.

    We outsourced our web credit card processing onto a secure website (we do not take any card info on our web site), so that is the easy part!

    We also have a “virtual terminal” where we can take phone orders and then process the credit card through our Mac computer over the internet only through a browser to a secure site. We do not store credit card numbers anywhere. This Mac is on a common small office network of five computers.

    Question (is my understanding correct?): Do we have to isolate one Mac from the office network behind a firewall or router to remain under SAQ-C? This seems to be the only thing forcing us into SAQ-D. In other words, if we do isolate it, would we fill out SAQ-C?

    • May 12, 2011 at 10:22 PM

      As with one of the previous comments, you are in a dual position. Your Web site puts you in SAQ A territory because it is a fully outsourced eCommerce solution. Your Mac in the office is an SAQ C-VT situation. However, you are a single organization as far as I can tell. As a result, in my very humble opinion, you will need to fill out an SAQ D because neither an SAQ A nor SAQ C-VT will cover your entire credit card situation.

      That said, not everything in the SAQ D will be relevant. As I stated in another comment, you can use SAQ A to guide you as to what you need to meet in SAQ D for your eCommerce solution. Use SAQ C-VT to guide you through those requirements relevant to your Macintosh. You will also need to fill out all of requirment 12. All the rest of the requirements would be ‘Not Applicable’ and the reson would be that they are not relevant to how your organization processes credit cards.

      Remember, this is just my opinion. You need to get official approval from your acquiring bank. If they are clueless or refuse to tell you what to do, then I guess you’re stuck with my opinion.

      • 89 Trevor
        May 13, 2011 at 2:01 AM

        Hi Debbie – “headache for a week” – we’ve been battling with this for about 12 months!

        You are in exactly our position and I suspect many other small business face the same issue, ie website with outsourced card processing making SAQ-A fit the bill. Then comes the issue of how to take phone orders. We have been advised that if we use a virtual terminal then we would go for SAQ-C and to comply with C we’d either need a stand alone computer on the internet or an isolated PC on our internal network. On a practical level this just doesn’t work . . .

        When a customer phones us to place an order, a member of staff would need to get up from their desk, walk across to the desk in the corner of the office (note to self; upgrade phones to cordless so they can still talk to customer – note to others, are cordless phones secure, or could a hacker tap into our phone calls?); switch on or wake up PC; login to the “special” PC and complete the transaction, logoff and return to desk. Is this the reality of how we are all going to take phone orders?

      • June 2, 2011 at 5:17 PM


        We just decided to cancel our Virtual Terminal and only take online payments. It was just too painful. I can understand all the security with all the credit card hacking going on. But this has become a big headache for a small business, especially when there is scant clear information about it and lots of conflicting information.

      • 91 nrs
        November 16, 2011 at 1:34 PM

        We fall into the same situation SAQ A and SAQ C. We had a meeting with our merchant bank and we provided them with our SAQ submission plan. We plan to complete 1 SAQ for processes that fall into SAQ A and one for processes that fall into SAQ C. Bank is happy with this approach.

      • November 16, 2011 at 8:48 PM

        Some acquiring banks will allow this to happen, but the key is to be up front with your issues and to get your acquiring bank to agree to this approach. Sometimes you will win the argument, and sometimes you will not. However, until you ask, you never know what is possible. Glad to hear it worked out for your organization.

      • 93 nrs
        January 24, 2012 at 12:42 PM

        Here is a situation and hope you can help. We are subject to SAQ C VT as we process credit card data via virtual terminal. However, recently we learned that we have a legacy excel file with credit card data stored on the share drive. We cannot remove the credit card data from excel file as this will require a big manual effort, we need the excel file as it contains other accounting info that is required to be stored for 10 years. That being said, the solution we have come up with is to transfer the excel file to an encrypted ironkey USB drive and remove it from the share drive. So how does that change our SAQ CVT qualification? Do we still qualify to complete SAQ C VT OR because we have an encrypted USB drive with credit card data we need to complete SAQ D? If We have to complete SAQ D- most of the questions will be not applicable to the USB drive… I have an inquiry out to the QSA, however, wanted to know your thoughts.

      • January 24, 2012 at 5:35 PM

        Only your acquiring bank can provide you a definitive answer. I would recommend that if your QSA agrees with your approach, that you and your QSA work together to get your acquiring bank to agree to your approach. As long as you have appropriate controls surrounding the USB drive (key management practices and secure storage of the drive), I would agree with your SAQ C-VT approach.

    • 95 Ns
      June 7, 2011 at 1:35 PM

      Here is a similar scenario. We accept credit cards in a various different ways. Web, call center, fax. etc.. we have now changed our processes to use a 100% outsourced model. Meaning, when clients come to our website and are ready to make the payment, we initiate a web call to our 3rd party and they send us the iframed page, hosted by them. Credit card details are entered into the iframe by the clients and card is processed by the 3rd party. That qualifies us for SAQ A. Now the question is around call center and fax documents that contain credit card data. We first thought about using the dedicated desktop system to process these transactions, however, it’s not practical. So we are thinking about why not act like a client and call the iframe page and enter the card data in behalf of client. Would this be subject to SAQ A? Again, the iframe page is hosted by the 3rd party card processor, all our reps are doing is entering the card data for the clients into the iframe page.

      • June 7, 2011 at 7:43 PM

        You are doing data entry through a virtual terminal, in my humble opinion, that would mean your data entry process would require SAQ C-VT and would then mean that you would need to fill out the SAQ D for all of your processes. But remember, this is just my opinion, only your acquiring bank can officially make this determination.

      • June 9, 2011 at 11:11 AM

        Yes, Ns, I thought about this too. But with my very limited PCI background, I decided it was still a type of virtual terminal; just as the PCI Guru replied to you. I think the bottom line is that if you ever have knowledge/control of an entire credit card number (even if only momentary), then it puts you in the “thick of the mess”.

      • 98 Trevor
        June 10, 2011 at 1:41 AM

        This is an interesting concept that implies that it’s OK for our customers to use our PCI compliant websites to make purchases and payments. Our customers don’t need their ISP connection scanned nor have an isolated computer for the sole use of using our website. However if we, the vendors use the same website to process payments, then in terms of electronic data transfer it is no longer considered secure – does anyone on this planet have an answer to this?

        I’m with another view express on this blog that it’s basically far easier to give up taking phone orders and spend more time trying to run our business. I don’t mind trying to jump through the PCI hoops if only those writing the rules could tell us which hoops we need to jump through. For us phone orders are 99% of our headaches.

      • June 10, 2011 at 2:20 AM

        The statement that “… if we, the vendors use the same website to process payments, then in terms of electronic data transfer it is no longer considered secure…” is not true. The Web site is still considered secure. However, as the merchant that controls the site, you would have significantly higher rights as an “administrator” than your customers when you connect to the site. If your staff are entering transactions and have rights no different than your customers, then they too are also compliant. It’s the ability to act as an administrator and have access to cardholder data in bulk (i.e., more than one card number at a time), that changes the game from a PCI compliance perspective. This access may not necessarily be through your Web site, but may occur through your acquiring bank Web site. This sort of access is provided for the resolution of disputes and for the processing of chargebacks.

  33. 100 Sama
    May 12, 2011 at 4:04 AM

    Thanks for your sharing your experience. Your posts are always of great help. I still have a question.
    Let’s say we are a big commerce, with hundreds of physical shops. All together, we process more than 6 millions transactions, so we are required to do pass the auditory with a QSA. However, the infrastructure in each shop is quite simple, in theory eligible for SAQ C.
    My question is, the QSA will ask me to implement the whole 12 requirements in PCI DSS for each shop? Or am I only require to implement mentioned SAQ C controls in every shop, but be reviewed by a QSA?
    Thanks for your help.

    • May 12, 2011 at 5:54 AM

      You are responsible for complying with all requirements that are relevant for your operation regardless of reporting format.

      For example, you would be responsible for all of the requirements in requirement 12. Every organization is, regardless of what type of operation they have. However, if your organization used off the shelf software and performed no application development, you would only be responsible for those requirements in requirement 6 such as those in 6.1, 6.2, 6.4 and 6.6. 6.3 and 6.5 would not apply because they are related to development of software which your organization does not perform. If your organization does not store cardholder data anywhere, either electronically or physically, then all of requirement 3 would not be applicable for your ROC.

      All of this said, your QSA would still have to confirm that all of these requirements were out of scope for your assessment.

  34. 102 Trevor
    May 12, 2011 at 1:39 AM

    Thanks for the reply, but still confused.

    To clarify we have one business that has an ecommerce website that ticks all the boxes on SAQ-A. We also use a mobile chip&pin machine to process telephone orders which is where all the confusion starts.

    Our bank won’t tell us which SAQ to use as they say they are not qualified to answer. Our ASV/QSA are suggesting SAQ-C but claim they don’t know what scanning is required on the device and they need to know what our bank require. Our bank just keep on saying they are not able to answer and we should ask our ASV/QSA!

    So we are stuck paying a monthly non-compliance fee to our bank – keeps the bank happy and they may have no desire to help us achieve compliance. We are at the stage of looking for another bank because this process is driving us round the bend. We’re already on our second ASV/QSA because the first one was so unhelpful and incompetent.

    If you’re saying a stand alone terminal doesn’t need scanning then why are we stuck between two global organisation who don’t know this?

    • May 12, 2011 at 6:11 AM

      This is one of the problems that I documented in my post. According to the card brands and the PCI SSC, your acquiring bank is the only official entity that can determine which SAQ your organization should file. Your QSA, your ASV, the PCI Guru, etc. can all give you their opinions on what SAQ they think you should fill out and file, but only your acquiring bank can give you the definitive answer. If they will not, then I would do whatever SAQ you feel best fits your operation and start looking for an acquiring bank that knows about the PCI standards (not easy or even possible depending on your location in the world).

      You say you have eCommerce and qualify for SAQ A, so I am assuming that your eCommerce is totally outsourced and you have no cardholder data electronically stored anywhere within your organization. Then you go on to say that you do have a credit card terminal (Verifone, Nurit, etc.) for conducting phone orders. That process now brings in the SAQ B requirements.

      As a result, in my humble opinion (note, this is just my opinion), you should be doing an SAQ D for your entire organization because you only fill out ONE SAQ. I would use SAQ A as a guide for identifying the relevant requirements in SAQ D that pertain to your eCommerce operations. I would use SAQ B as a guide to identify all of the relevant requirements in SAQ D that pertain to your phone order operation. Under SAQ D, you will need to comply with everything in requirement 12 regardless. Any other requirements in SAQ D that do not pertain would be marked as “Not Applicable” and you need to document the reason you believe them to be Not Applicable.

      As to your ASV scanning issue, I am guessing that your ISP/ASP that hosts your eCommerce environment is not doing the required ASV vulnerability scanning of that environment and you are responsible for having it done. If we are talking about the credit card terminal used for phone orders and that terminal is not on the Internet and uses a dialup line, I’m not sure why anyone would be vulnerability scanning for that as it is not required and you should tell your bank that it is not on a public network.

  35. 104 Ns
    May 11, 2011 at 10:59 AM

    This is great information. So if we have 2 different processes and for each process we work with different banks, one process is subject to SAQ C and other process is subject to SAQ D. Do we complete 2 different SAQ or just complete SAD D and give it to both banks? We have talked to banks and they are saying do separate SAQ, just want to hear your thoughts.

    • May 11, 2011 at 9:47 PM

      Unless your processes are done by two different legal entities, you do only one SAQ and submit that one SAQ to each acquiring bank.

      In your example, you would do the SAQ D and submit it to your two banks.

  36. 106 Trevor
    May 7, 2011 at 11:54 AM

    Thanks for the information but there still appears to be a lot of confusion out there. I’ve talked to a number of online business that don’t know anything about PCIDSS, and even last week our Bank’s local business manager gave me a blank look when I mentioned how much we are struggling with PCIDSS.

    A year ago we were faced with SAQ-D but after outsourcing our online payments to a 3rd party we thought we’d be on SAQ-A. All was OK apart from taking telephone orders (<1% of sales). By using a internet based Virtual Terminal we are now looking at SAQ-C.

    We also have a mobile chip&pin machine used at exhibitions that could be used for customer not present telephone orders instead of the VT, however we are unable to establish which SAQ applies to this scenario and what scanning requirements are needed. Our merchant bank won't tell us and say we need to consult with our ASV/QSA. We have, and they are unable to provide accurate scanning results due to the scanning infrastructure. They asked us to ask our bank what scanning they require.

    • May 10, 2011 at 7:53 AM

      You only do ONE SAQ, not a couple, one for each type of transaction. Unless each of your businesses is operating under a different name (aka ‘doing business as’ or ‘dba’), you only ever do one SAQ. That said, it sounds like you need to do an SAQ D for your entire organization given all of the different payment processing styles you use. Again, you need to confirm that with your acquiring bank.

      If your payment terminal is stand-alone and connects directly to the Internet or a dial-up terminal, it does not need to be scanned by an ASV. There is an assumption (right or wrong) that these terminals are secure from you acquiring bank. An ASV would only need to scan your in-scope Internet site(s) and any other devices/systems in your Internet-face cardholder data environment (CDE).

      • 108 QSAsteve
        December 21, 2011 at 9:25 AM

        As a QSA, I certainly agree that the SAQs seem to have been written without much thought as to how real businesses operate. It’s always difficult when asked to advise which SAQ applies.
        Most of the issues here seem to relate to businesses that operate as defined for SAQ A and for SAQ C. Although I accept that if you don’t exactly fit a specific SAQ then you are technically SAQ D, I’d point out that all the requirements of SAQ A are included in SAQ C. So there is no logic at all in saying that if you would be SAQ C if only you weren’t SAQ A as well therefore you must be SAQ D! In this situation, unless your acquirer insists that you are SAQ D, I’d argue for SAQ C. Even much of that will be not applicable in the scenarios described as there is no payment application and no card data storage.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

May 2011

%d bloggers like this: