06
May
11

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.

About these ads

67 Responses to “Self-Assessment Questionnaires”


  1. 1 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.

  2. 2 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.

  3. 4 Barb
    April 23, 2013 at 2:15 AM

    Hi,
    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.

      • 6 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’.

      • 8 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.

    • 10 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.

  4. 12 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.

  5. 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

  6. 15 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.

  7. 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.

  8. 19 Sebastian
    August 15, 2012 at 5:21 AM

    Hi,

    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.

  9. 21 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!

    Dan

    • 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.

  10. 23 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.

  11. 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.

      • April 16, 2012 at 10:45 PM

        Thank you for such a quick response. Calls are not recorded. I appreciate your help.

  12. 28 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.

      • 30 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.

  13. 32 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.

  14. 34 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.

  15. 36 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.

  16. 38 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.

  17. 40 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.

    Joey

    • 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.

  18. 42 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.

      • 44 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. http://pciguru.wordpress.com/2010/11/03/requirements-that-are-never-%E2%80%98not-applicable%E2%80%99/ http://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.

  19. 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.

      • 48 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

        Trevor,

        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.

      • 50 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.

      • 52 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.

    • 54 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”.

      • 57 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.

  20. 59 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.

  21. 61 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.

  22. 63 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.

  23. 65 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).

      • 67 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 )

Google+ photo

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

Connecting to %s


Announcements

FishNet Security is looking for experienced QSAs for their PCI practice. If you are an experienced QSA and are looking for a change, go to the Web site (http://www.fishnetsecurity.com/company/careers), search for 'PCI' and apply.

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

May 2011
M T W T F S S
« Apr   Jun »
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,018 other followers


Follow

Get every new post delivered to your Inbox.

Join 1,018 other followers

%d bloggers like this: