By PCIGuru

If you have a PCI question that is not related to anything I have posted, you are welcome to post them here.  I will do the best I can to respond to your questions.  If other readers wish to weigh in on questions posted here, their comments are also welcome.

To those of you that have issues with this page and it’s load time, blame WordPress. This is a “free” blog and to fix this issue would require a ‘Business’ subscription that would cost $300/year (2018) to access the necessary plugins to reorganize the comments to multiple pages. To afford that, I would have to charge a subscription fee to anyone reading the blog.

Remember though, I am a QSA and consultant.  So I am not going to “give away the store” as I am in the business of selling my expertise.


1602 Responses to “Miscellaneous Questions Page”

  1. 1 R
    May 15, 2018 at 9:34 AM

    Hi everyone! I’m looking for help deciding what to do with our mainframe sessions and the coming SSL/early TLS deadline. My mainframe team tells me the mainframe is limited by the emulator and can’t run without using SSL (which is encrypting a type of telnet session; another thing mainframe can’t run without). Mainframe is in scope as it runs an application the call center uses to enter credit cards and ultimately stores credit cards prior to auth/settlement (batch), then transmits to banks, and for customers who elect to have their cards saved. Is anyone else in this boat, and what are you doing to comply? Particularly for requirements 2.2.3 and 2.3 of SAQ D, do these apply directly to mainframe systems? Do mainframe systems that can’t run on anything other than SSL get a pass/CCW? Thanks!

    • May 21, 2018 at 6:43 AM

      You will need to create compensating control worksheets (CCW) for those requirements that your mainframe cannot meet. A lot of my clients with mainframes have moved to SSH to secure their TN3270/TN5250.

      After June 30, the only way to comply will be with a CCW for any of the SSL/early TLS requirements.

  2. 3 Adam
    May 4, 2018 at 12:58 PM

    Love the site. I have a question about scope. I am new to the organization as the ISA and am questioning prior scoping decisions where our customer facing website was left out of scope.
    We host both our customer facing website which redirects to our payment gateway when they want to pay a bill, authentication takes place once on the customer facing website. The customers browser calls a javascript (provided by our payment processor, we dont have the keys but the script is stored on our gateway) the credit card data is encrypted and sent to the payment processor then we get a token back and store on the gateway and used for reoccurring payments.
    Would the customer facing website be in scope in addition to the payment gateway?

    • May 8, 2018 at 6:26 AM

      Your customers’ Websites are in scope as far as SAQ A makes them which is not much.

      That said, I would highly recommend that your customers’ sites be vulnerability scanned to ensure that they are secure and patched. The reason is that if someone changes your JavaScript code using one of your customer sites, your customer will be on the hook as well as your organization. Security is all about the weakest link and the last thing you want is one of your customers being your weakest link.

      • 5 Adam
        May 8, 2018 at 8:41 AM

        Oh sorry maybe my explanation was unclear. When I said “customer website” i meant ours, we are the merchant. Our CMS system is where the customer manages their account, selects services, etc. When the customer pays their bill and they click pay they go to the payment gateway. Both of these we own and host. The javascript that runs in their browser then sends the encrypted data back through our gateway before going to the payment processor.
        Due to these architectural decisions I think this doesn’t allow us to do even a SAQ A-EP but instead have to do a SAQ D.
        The scoping error that I believe was made was not including the CMS system in scope as a Cat 2 or connected device since it redirects the customer to the payment gateway which would mean that its connected to the payment gateway which is a Cat1 CDE device.

      • May 9, 2018 at 6:08 AM

        Based on your description, you sound like SAQ A-EP would be acceptable. But that is only my opinion. Only your processor or acquiring bank can give you an official ruling.

  3. 7 Fred
    April 24, 2018 at 1:26 PM

    Greetings. With regards to 12.3.9 Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use.
    We are having trouble in assessing what is “after use”. For an external consultant who is working on a 6 month contract who require access daily, is it end of day or account is disabled at the end of 6 months?
    Thank you in advance for providing any clarity and assistance.

    • April 25, 2018 at 6:24 AM

      Does the consultant have access to the cardholder data environment (CDE) or just your general network? If it’s just the general network, then 12.3.9 does not apply. If they are in the CDE, then you need to follow 12.3.9. However that should not be hard because you now need to required multi-factor authentication (MFA) into the CDE as well as for remote access. What a lot of organizations do is require CDE access be enabled via a one-time use password along with MFA. When they leave the CDE, they are locked out automatically until they request access again.

  4. 9 Anne
    April 3, 2018 at 11:02 AM

    For control 8.1.6 and 8.2.4 – compensating controls i have considered are logging, monitoring, and alerting for follow up. Do you have any suggestions based on discussions with QSA’s? Thank you for consideration and help.

    • April 7, 2018 at 6:18 AM

      In my experience, where 8.1.6 runs into trouble with a CCW is when you test the compensating controls and you find that the people monitoring them do not respond in a timely manner to the alerts generated and lock out the account. I have sat and watched screen after screen of alerts from SIEMs roll by while people try and triage what is most important and miss other critical alerts. That to me basically says that any CCW relying on monitoring is not going to pass.

      In regards to 8.2.4, the biggest issue with monitoring is getting a rule to track all user identifiers and when their last password change message was generated so that you can notify users to change their passwords. From what I’ve seen, it can be done, but is so labor intensive that it would be a whole lot easier and cheaper to implement a directory system that automatically monitors for such conditions.

  5. 11 GBF
    March 23, 2018 at 7:09 AM

    Our company assists clients with purchasing items online – typically they are on the phone line while we make the online purchases on their behalf but not always.

    We occasionally come across sites with the Verified by Visa or MasterCard SecureCode – in these cases we ask the client for the requested info (eg letters from password or text code) to proceed with the purchase and we enter the information at the time. How does this fit with PCIDSS – this type of information doesn’t appear to be covered as SAD?
    We do store their card numbers for their convenience (we are PCI compliant for that) but the VbV seems a grey area as to what can be stored. Have you come across this before?
    Thanks, and thanks also for such a useful site – a really big help is making things easier to understand!

    • March 23, 2018 at 4:26 PM

      Good question and unfortunately one you will have to ask Visa and MasterCard about because of the fact that it is not covered by the PCI DSS. If you do get answers back, I would love to know what they told you.

      • 13 GBF
        March 25, 2018 at 8:52 AM

        Thanks – I’m feeling it should be treated as SAD… I can’t imagine Visa or Mastercard being very impressed and probably would potentially leave the customer in a tricky position too unfortunately. Appreciate the response, thanks for your help!

    • 14 Chandramani
      March 26, 2018 at 1:22 PM

      What is the definition of Issuer and acquirer?

      • March 29, 2018 at 4:00 PM

        From the PCI DSS Glossary

        Acquirer – Also referred to as “merchant bank,” “acquiring bank,” or “acquiring financial institution”. Entity, typically a financial institution, that processes payment card transactions for merchants and is defined by a payment brand as an acquirer. Acquirers are subject to payment brand rules and procedures regarding merchant compliance.

        Issuer – Entity that issues payment cards or performs, facilitates, or supports issuing services including but not limited to issuing banks and issuing processors. Also referred to as “issuing bank” or “issuing financial institution.”

  6. 16 TB
    March 22, 2018 at 9:24 AM

    Thanks for your efforts in this area, very educating!

    I think you have said the nirvana of card transaction security is implemeting an encrypting device at point of swipe that initiates transactions only the processor can decrypt. As such any merchant PC, network, or server that moves the encrypted data is out of scope.

    Such an encrypting device encrypts both dips and swipes right? Is there a difference in terms of security between an encrypted transaction created by a dip vs a swipe?

    • March 23, 2018 at 4:17 PM

      Yes, card terminals with both EMV and magnetic stripe capability that encrypt at the terminal should do both EMV and swipes. That said, it is always best to confirm that with the terminal manufacturer or the processor providing you the terminal.

      There should be no difference between the encryption of the EMV or swipe data.

  7. 18 Erik
    March 22, 2018 at 8:58 AM

    Do you have any experience with PCI DSS compliance for hotels using Oracle Hospitality Opera? This seems to be one of the most common hotel booking system in the world, but it’s difficult to find any information on PCI DSS compliance for it. There is a PA-DSS validation for Opera, but that doesn’t cover their Oracle back-end systems storing cardholder data…

    • March 23, 2018 at 4:15 PM

      Look at the ‘Other Dependencies’ at the bottom of the listing just before the new listing, you will see that the Oracle RDBMS version that it was PA-DSS validated.

      • 20 Erik
        April 9, 2018 at 6:10 AM

        Oracle acts as a Service Provider, providing the back-end systems that store cardholder data. I’m having difficulties finding if that service is PCI DSS validated.

        In general, the Opera application seems shaky in terms of security, relying on a Java Applet which prevents use of modern browsers or operating systems…

      • April 11, 2018 at 5:35 AM

        Opera is a PA-DSS validated application, but that does not mean it is implemented by Oracle to be PA-DSS compliant and secure.

        I am assuming from your question, you went out to the Visa and MasterCard Global Registry of Service Providers and did not find Oracle Opera listed. Remember, those lists are all a marketing ploy and have no real meaning other than that they paid money to Visa/MasterCard to be listed on those lists.

        What you need is the Attestation Of Compliance (AOC) from Oracle for the Opera hosting service. Your Oracle account representative should be able to get a copy. When you get it, make sure it lists Opera hosting as a service that was assessed. I have had companies send my an AOC and then discovered that the services I needed assessed were nowhere to be found.

  8. 22 IT GUY
    March 19, 2018 at 10:08 AM


    At the minute, our development department needs to be kept out of scope of PCI. They are located in another office and are on a network over the MPLS that is not classed as in scope. They use a RDP session to a server that is in scope, but not CDE. While in terms of networking the development VLAN is classified as trusted, because they are on another domain that is not trusted with the PCI domain, they have been classified as out of scope for PCI DSS. (They do not handle credit card data)

    As they require access to systems in scope and CDE. We have put in restrictions whereby, their PCI domain accounts are disabled at all times, they then need to request access which details the following:

    Date & Time of Access
    Reason for Access
    Which Systems they need access to.

    With these details, their accounts are enabled by admins in the PCI domain and then the developers can access to servers requested. (2FA is currently being put in place for this) Account automatically disabled and every access requested is logged into a help desk system for reporting.

    I have been told by a new security officer, there is no time requirements mentioned in PCI DSS for allowing access to a CDE\In Scope servers from users on another active direction domain that is not in scope of PCI. It is perfectly fine to allow continued access from another domain.

    I would like to know if you deem this an acceptable solution for user control\restricted access and a method of keeping the development department out of scope?

    I acceptable this is not a normal case, there is far too much internal politics taking place where PCI is just brushed aside to please some big wigs. (even the QSA is internal now, I dont trust half the stuff he says either)

    As always, Thanks!

    • March 21, 2018 at 11:00 AM

      There is no time requirement specified, but you are required to monitor their activities within the CDE and disable their access when they are complete.

      While I know the developers probably do not like having to request access all of the time, a lot of authentication solutions only can provide the solution you currently have in place. As such, I like your original approach as that is more in line with what the PCI DSS was trying to accomplish.

      • 24 IT GUY
        March 22, 2018 at 7:53 AM

        Hi Again,

        1st of all, thanks for the reply, 2nd, apologies about the grammar mistakes in there! Having serious issues with my new mobile device!

        If there are no time requirements for access, then I am concerned the following requests would be made.

        “I need access for 365 Days a year, 24 hours a day to do my job”

        Which we have seen in the past. When development was in the same office on the same domain, access was not a problem as they was apart of previous assessments. Now they are located else where on another domain and a network not managed by the PCI business entity, the route above was taken.

      • March 23, 2018 at 4:20 PM

        That gets covered by the fact that developers are NOT allowed to have unfettered access to production environments under requirement 6.4.2 that requires separation of duties. The Guidance column clarifies what the requirement means.

  9. 26 R
    March 16, 2018 at 1:06 PM

    Happy Friday! I’m on the fence about anti-virus today…

    I read over and over in your comments how PCs should be hardened with anti-virus, Bit9 or similar, FIM, up-to-date patches, etc. I also noticed you’ve said anti-virus catches only about 30-40% of malware. What’s your take on the scenario where all of the above mentioned (AV, Bit9, some degree of FIM, up-to-date critical & high rated patches) are in place, but we seem a bit lax on the “AV actively running (req 5.3)” front?

    Specifically, PCs that become noncompliant with AV (due to unintended result of updates/patching or any other glitch) are purposefully NOT blocked from the network in the name of operational efficiency. The requirements from the “note” section of 5.3 (legitimate technical need, case-by-case authorization, blocking web browsing) are not implemented. If a large number of PCs becomes noncompliant, a team will prioritize fixing the widespread problem. If a small number of PCs are noncompliant, it seems they’re more or less fixed as there’s time to do so; not a priority.

    I appreciate your take on this issue. I can’t tell if anti-virus is a non-negotiable requirement and the current practice is noncompliant (and more importantly a measurable security risk), or if I’m over-analyzing and small instances of anti-virus noncompliance are unavoidable and the other defense in depth tactics compensate. Thanks!

    • March 16, 2018 at 1:50 PM

      If the PCs in question are in-scope for PCI compliance, then your QSA should not care whether it is one or a thousand that have a compliance issue, they better get fixed as soon as possible as you are not complying with the requirements.

      That said, you could attempt to write a compensating control worksheet (CCW) for the requirements you cannot comply. However I think you would find that exercise harder to do than just fixing the problem(s).

  10. 28 Jeff
    March 16, 2018 at 7:14 AM

    We want to take telephone payments over the phone to a virtual terminal provided by our payment gateway.
    However PCI-DSS states the following:
    “Merchant accesses the PCI DSS-compliant virtual terminal solution via a computer that is isolated in a single location and is not connected to other locations or systems within the merchant environment;”
    The machines we want to take payments on are general customer service machines, which communicate with our other internal systems over the internal network, share files, as well as other tasks such as emails.
    For example even taking a payment, we would also want to update a separate system to add their quote to get the amount, confirm we have the money and take their order etc.
    Does this sentence means that we have to have a machine just for credit card orders that is isolated completely using firewall rules or vlans, or can we carry on with what we have, and just isolate the customer service machines from the rest of our internal network?

    • March 22, 2018 at 6:23 AM

      The short answer is, ‘Yes’, that is exactly what it means. What you want to do is to get those PCs out of scope.

      The way you do that is to use an end-to-end encrypted (E2EE) card terminal such as an IDTECH M100 or MagTech DynaMag (there are others, but these are the most commonly used).

      This approach is not without its changes and costs. It will likely require programming changes to the Web application(s) to work properly. You will also need to discuss it with your transaction processor as they will be the ones encrypting these keypads. Such an approach will allow you to rollout keypads to anyone that needs it but keep their PC out of scope.

      In the end though, you may find out that this approach cannot be implemented for any sort of reasons. As a result, you will need to treat those PCs as Category 1 devices and then control them accordingly.

      • 30 Craig
        May 15, 2018 at 2:41 PM


        Thank you for taking the time to address these issues. I have just started with PCI this year and have a couple of follow up questions for this response.

        We use the IDTECH M100 and M130 to encrypt data on entry. However, I can’t find them as approved PTS devices on the PCI security standards website. What effect does that have on your answer (if any)? Also, because they are not listed and the solution we are using is not a P2PE validated solution, what kind of guidance should we expect from our acquirer about PCI scoping?

        Thanks in advance.

      • May 21, 2018 at 6:40 AM

        None, as I have a number of clients that use the IDTECH M100/M130 POIs in use. It all comes down to a discussion with the transaction processor as well as some Wireshark network and USB captures to prove that the encryption starts and is maintained through the PC the POI are connected.

        The processor should require that the end-to-end encryption (E2EE) solution to be assessed and the evidence presented to them that E2EE is implemented correctly. See this post ( which discusses that E2EE assessment process.

    • 32 danuksw
      March 22, 2018 at 7:24 AM

      In a similar environment, I have been thinking of various solutions to lessen our scope and, as PCIGuru suggests, card terminals is one way, The other way, that has been sanctioned by our QSA, is to have (for example) tablets that can access the virtual terminal that are isolated on their own segment of the network. Initially, I was told that only one device could exist but after reading page 4 of:

      which says:

      ‘Your company accesses the PCI DSS – compliant virtual payment terminal solution via a computer that is isolated in a single location, and is not connected to other locations or systems within your environment (this can be achieved via a firewall or network segmentation to isolate the computer from other systems) 1’

      and the footnote ‘1’ says:

      ‘1 This criteria is not intended to prohibit more than one of the permitted system type (that is, a virtual payment terminal accessed by an Internet – connected web browser ) being on the same network zone, as long as the permitted systems are isolated from other types of system s (e.g. by implementing network segmentation). Additionally, this criteria is not intended to prevent the defined system type from being able to transmit transaction information to a third party for processing, such as an acquirer or payment processor, over a network. ‘

      I went back to our QSA and they said we can qualify for SAQ-VT if the Virtual Terminal device(s) are indeed on their own network segment. It might be easier/cheaper for you to do it this way?

      • March 23, 2018 at 4:25 PM

        Except for the fact that the tablet (or any device for that matter) that connects to the virtual terminal is in scope for PCI if it is used to enter cardholder data (CHD) or sensitive authentication data (SAD). That is because under the scoping guidance, it is a Category 1 device and needs to be part of the cardholder data environment (CDE). That is why your QSA is okay with it, but should have told you that it is part of the CDE. But worse, that tablet is likely collecting every PAN that is keyed into it thanks to the built-in keyboard logger that all iOS/Android/Windows mobile devices have in the OS.

  11. 34 Ash
    March 5, 2018 at 4:42 PM

    Hi PCI Guru, hope you are well. A quick one, if a merchant is using a P2PE solution, do they have to maintain a list of service providers, and do those service provider need to be PCI compliant? and also, do a P2PE solution provider need to become pci compliant as a service provider as well?

    • March 14, 2018 at 1:06 PM

      Check out SAQ P2PE for your answer. If the requirement is in there to maintain a list of Service Providers, then you need to maintain a list.

  12. 36 Dave
    February 22, 2018 at 3:38 PM

    Some ASV’s state that using a touch tone phone to dial a 1-800 number and punch in CC info is an SAQ-A under MOTO and another has it as an SAQ-B because it has a face-to-face aspect. There are no other forms of processing at this merchant. Idea’s which SAQ is correct for the merchant to complete and be compliant?

    • February 24, 2018 at 8:49 AM

      It depends on whether it is the merchant’s IVR system that processes the payment. If it is the merchant owns and operates the IVR, then you have to look at it and determine how it works as to what SAQ is appropriate.

      In my experience though, the vast majority of those IVR solutions are owned and operated by third parties and therefore do not effect the merchant’s SAQ choice.

      • February 24, 2018 at 8:52 AM

        That said though, if a merchant has multiple payment processes, they are likely going to end up overall with an SAQ D if their bank does not allow them to file multiple SAQs for each payment process.

  13. 39 Gina
    February 20, 2018 at 8:45 AM

    Hi PCI Guru and anyone else who’s had this situation–

    Has anyone had a federal customer tell them it’s illegal to keep federal credit card information on file after the payment is processed?

    I know such a law would supersede PCI requirements, but of multiple federal customers for some time, this is the first time we’re hearing such and only from one particular customer. Thanks for any insight!

    • February 20, 2018 at 4:35 PM

      That is a new one for me as well. However, if it is an agency that has a reason for secrecy of spending patterns, I could see their rationale for the request.

  14. 41 DN
    December 11, 2017 at 11:40 AM

    Hi There,

    I have an interesting scenario, that I am looking for a different take on… My company provides services to other companies and as part of that we offer the company’s an API to connect and interact with us. Part of the API is the passing of credit card information from them to us to pay for services.

    We have always maintained that our PCI responsibility starts with at our web service. It has come to my attention that we integrate with a number of procurement engines (Ariba and ivalua). The standard communication between the services is cXML. The integration with the platforms is done by us, but at the request of our customers. My question is this: Who is responsible for PCI security between the customer and us over the procurement platform? My take is the procurement platform itself, but do they know they are processing transactions? What will that mean for our other customers using our API? Do we need them to be PCI compliant, as the majority use their internal purchasing cards?


    • December 11, 2017 at 2:19 PM

      Your organization’s responsibility starts with securely transmitting the data from the third parties (usually using TLS but could also be IPSec).

  15. 43 Scott
    December 4, 2017 at 9:49 AM

    Hi PCI Guru,

    First off, thank you for this site! It has been invaluable to me so far!

    I wanted to ask, in terms of the PCI requirements, is the use of IP tables for network segregation instead of seperate VLANS considered “okay”? I have very little understanding of iptables yet I’m being asked this very question and can’t find any answers on the internet that even make sense.

    Thanks! 🙂

    • December 8, 2017 at 9:08 AM

      IPTables is PART of the equation, but not the complete solution for adequate segmentation under PCI. You also need to be able to restrict by port/service as well as be able to monitor the traffic (i.e., stateful packet inspection) as it flows.

  16. 45 Yolanda
    November 29, 2017 at 8:57 AM

    Greetings, PCI Guru.

    First, thank you for the many valuable insights provided on this blog. Very, very helpful. My question relates to payment kiosks. I’m trying to determine which SAQ is most applicable. Customers can use the kiosks to make utility payments on their own during peak and off hours. The machines are located in the lobby, as well as outside the building, and are completely owned and maintained by a third party. The utility company simply provides an internet connection to each machine and that is the extent of their involvement with the machines. Customers can use these same machines to make payments to other utility companies. In your opinion, what security obligations does the utility company where the machines are located have for PCI compliance for these machines and which SAQ would be most applicable? I thank you in advance for your response.

    • November 30, 2017 at 11:08 AM

      The question comes down to whether or not these kiosks are on your network or a physically separate network maintained by a third party. If they are on a physically separate network, then the PCI compliance is on the third parties involved. If on your network, then there is a LOT more information needed to determine the SAQ.

      • 47 Yolanda
        March 9, 2018 at 2:54 PM

        Much belated thank you for the response. Had to table this topic for awhile in favor of more pressing matters. The internet connection provided is physically separated from the corporate network (separate internet connection, separate hardware firewall). We are including the network diagram, photos of the physical equipment and connections, and firewall rules in the documentation to demonstrate that. Furthermore, the kiosk provider’s compliant AOC specifically includes the payment kiosks and the management of those kiosks in the scope of the assessed CDE. By contract, the only services the utility company is required to provide in support of the kiosks is an internet connection and power for each machine. Someone suggested that we obtain more information from the vendor regarding what P2PE device they use in the machine and how they manage physical inspections over the card readers so that we can complete a P2PE SAQ. Seems to me these requirements would already be addressed in the provider’s report since they specifically included the kiosks in their CDE scope and did not carve that out as the responsibility of the client. Someone else suggested that we document all this in a SAQ D where most of the responses would be N/A. Given the information provided, what are your thoughts on where this information should be documented to show that we’ve done our due diligence regarding PCI compliance for these kiosks?

        I greatly appreciate your feedback. Thank you.

      • March 14, 2018 at 1:23 PM

        If you have an AOC from the vendor and it is NOT on your network, you are have done your part as the kiosk is not involved in your PCI compliance effort beyond your vendor management requirements in 12.

  17. November 24, 2017 at 8:15 AM

    In one of the posts I noted that,

    ———-“If a PA-DSS compliant/ validated Application is implemented on an Operating System other than an Operating System tested during the PA-DSS Validation, such implementation is NOT PA-DSS Compliant.”———

    Question 1:
    Is this true. If so, where does it exactly denoted under the PA-DSS requirements or any other place/ material in

    In a nutshell, what should i refer to validate above statement?

    My requirement is to have an evidence from PCISSC to justify the above statement.

    Question 2:

    Should the Application be implemented ONLY on an Operating System tested during the PA-DSS Validation process?

    If so, where does it exactly denoted under the PA-DSS requirements or any other place/ material in


  18. November 16, 2017 at 6:33 PM

    We are undergoing a dmz redesign and upcoming projects require us to externalize some services. There has been some discussion about requirement 1.3.x and what is actually required.

    As an example, if we utilize a firewall and directly to an F5 device using APM. Then NAT from the F5 to the internal system, does that meet the intent of the requirement?

    What specific controls would need to be in place for this to be compliant? — or do we absolutely need a computer system in the dmz?

    • November 17, 2017 at 2:46 PM

      It should be PCI compliant, but it will depend on how you define the rule(s) in the firewall and F5.

  19. 53 Niks
    November 8, 2017 at 7:28 AM

    Hello PCI Guru,

    Thanks for this lovely resource and your help.

    We are looking to build on taking recurring payments from our customers without asking for CVV2 again and again. Now since PCI DSS does not allow us to store CVV2 in our environment then what can be the way around to implement recurring payments without violating PCI DSS.

    Thanks in advance.

    • November 11, 2017 at 4:32 PM

      Work with your transaction processor or acquiring bank. They can provide you with a solution for recurring payments.

  20. 55 RLM
    November 6, 2017 at 12:54 PM

    Could you please provide an example of a list that should be generated/managed for req. 1.1.6 “Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.”

    Possibly a spreadsheet template exists somewhere? Have searched high and low.

    • November 11, 2017 at 4:34 PM

      Think about what you’re asking. I cannot do everything for you and this is something you should be able to create in a spreadsheet.

  21. 57 Gabriel
    October 31, 2017 at 9:41 AM

    Based on requirement 12.8.3 on vendor due diligence. who is to conduct due diligence? is it audit, internal control or risk management

    • November 11, 2017 at 4:40 PM

      Whomever in your organization that is best equipped to conduct it. I have some clients whose legal group collects the necessary information and then it is reviewed by the appropriate groups that can assess it.

  22. 59 Mrgray
    October 26, 2017 at 5:12 PM

    Mr. Guru. Question about the upcoming Two-factor requirement for non-console administrative access:
    Is there any guidance for applications hosted on servers that are used for managing devices in the CDE?
    For example, Endpoint management solutions. We can implement two factor for RDP and SSH into those servers, but the applications themselves, which are usually accessed via a web portal or a locally installed console (on the administrator’s workstation), do those applications need two factor as well? Don’t get me wrong, I would love to implement it if they had the option, just checking if it was required.
    Some solutions that come to mind are V-Center, Solarwinds, Landesk, MOM, WSUS, Sophos, Trendmicro, Symantec, Bit9, etc.


    • October 27, 2017 at 5:39 AM

      Any administrative console used by a human administrator that can affect the security of systems inside the CDE are required to have multi-factor authentication (MFA). So all of those examples you list will need MFA for administrators to connect to them. But then most organizations have implemented MFA on all of their administrator consoles regardless of PCI or not.

      • 61 Mrgray
        October 27, 2017 at 10:13 AM

        Thank you for responding! What about MMC snap-ins, for example, Active Directory users and computers?

      • October 27, 2017 at 1:12 PM

        If they are not administrators but normal users, then they would not need to MFA.

  23. 63 Mrgray
    October 26, 2017 at 4:48 PM

    Hello Guru!
    Riddle me this:
    1. I am a Segmented iPad and I am managed with MDM.
    2. I have a certified PCI P2PE solution.
    3. I also have Access to an SAQ A e-commerce site via Safari.
    4. I only have access to the POS application, P2PE response, the MDM and the e-commerce site.
    5. My users use the P2PE reader for POS transactions
    6. My users manually key in CHD into e-commerce site on clue #3, using my iPad’s own virtual keyboard.

    What SAQ does my owner need to file?
    SAQ C-VT?
    SAQ C?
    SAQ P2PE?
    SAQ D?

    • October 29, 2017 at 8:59 AM

      Until you got to #6, I would have told you to merge SAQs P2PE and A. But you had to screw it all up with manual data entry into that iPad which will remember everything entered. I would say you now need to do SAQ D as well as explain how you secure the clear text SAD in those iPads.

  24. 65 Bianca
    October 22, 2017 at 5:21 AM


    I have a question regarding a consumer-facing mobile application in which our users can purchase tickets using their credit cards. The application accepts cardholder data as input in our native Android/iOS form. This data is encrypted using the latest TLS and it is transmitted to a third-party payment gateway using an HTTP post method. The application does not store any cardholder data and it also doesn’t send this data to our servers (Amazon – which are already PCI DSS compliant), even though there is a communication channel between them. For which SAQ do we qualify? Are our servers or anything else within the PCI DSS scope?

    Thank you!

    • October 22, 2017 at 5:10 PM

      If you are developing the mobile application, then you need to be following and complying with all of the requirements in section 6 of the PCI DSS for the development of that application as well as the related Web sites that drive it. That said, I would have to know a LOT more about your environment to give you an opinion. If you have outsourced development, then either you will assess the third party developer or they assess themselves as a service provider and provide your organization with a service provider AOC. But the only entity that can definitively answer your question about what SAQ to use is your acquiring bank. I can provide an opinion if I have a LOT more information about your organization and architecture (i.e., a paid consulting gig), but only your acquiring bank can provide you an actual answer.

  25. 67 RT
    October 20, 2017 at 10:13 AM

    PCI Guru, great site!

    We are looking to reduce scope to from SAQ-D to SAQ-P2PE by switching to a fully P2PE provider on our face to face transactions. The standard indicates it will not work for e-commerce. We do have a website that does not touch our network at all (it is provided and managed by one of the well known card transaction companies and all transaction go from them to the Card provider).

    Because that site is not managed by us and does not connect any credit card data to our network, would we still be eligible for SAQ-P2PE?

    • October 22, 2017 at 5:03 PM

      While your brick and mortar will be covered by the requirements in SAQ-P2PE, your eCommerce site needs to meet the requirements in SAQ A. Talk to your bank and confirm that they agree. If all of the requirements in SAQ A are covered in SAQ-P2PE (something you will have to check), then I would also ask your bank if you can just use SAQ-P2PE. If they do not agree, then you will use SAQ D but only map the requirements in SAQ-P2PE and SAQ A into SAQ D and mark all the other requirements outside of those two as Not Applicable.

  26. 69 Ken
    October 13, 2017 at 10:28 AM

    I am looking to get some advice or opinions on whether our PC’s are part of the CDE scope. We currently use a Magtek card reader to swipe the card. The card reader is connected to the PC via USB and the PC uses an EPX Vpost terminal. The PAN is encrypted at the time of swipe and the PC never sees the PAN in clear text. Would you consider the PC to be in the CDE scope? Thanks Ken

    • October 13, 2017 at 4:16 PM

      If the MagTek Point Of Interaction (POI) encrypts at the swipe/dip and the PC cannot decrypt that data stream, then the PC is out of scope for PCI compliance. A QSA/ISA or someone from your organization should prove that is the case by gathering evidence and packet captures that proves that fact. Then that evidence needs to be presented to your acquiring bank for them to make the final determination that those PCs are out of scope.

      • 71 Ken
        October 16, 2017 at 2:03 PM

        Thanks for the response. Is it always the case that the PC is excluded from CDE scope where the PAN is encrypted at swipe or dip AND the merchant doesn’t have access to the decryption keys? Or is VPost serving some purpose here along with the encryption with keeping the PC out of scope? I assumed VPost isn’t helping it with scope reduction since it states that as long as the device encrypts the PAN and the device cannot read the PAN in clear text and the merchant does not have access to the decryption keys.

      • October 22, 2017 at 4:49 PM

        It has to be proven that the PC cannot decrypt the POI’s data stream. So it is not always the case. But 90%+ of the time these days it is the case that the PC is deemed out of scope.

  27. 73 Faithless
    October 2, 2017 at 3:51 AM


    We are currently looking to reduce our CDE scope to nothing but taking advantage of SAQ-A and redirect payments. At the same time, the business wants to change our data centre from a self hosted solution to a service provided by our Corporate owners. (We operate as a standalone entity due to PCI)

    If we have fulfilled the SAQ-A requirements, what do we need to request from our Corporate data centre as apart of any future assessments. Even without handling credit card data, I am assuming they would still need to apply to some sort of requirements as a service provider of PCI Scoped infrastructure?

    As always, thanks for your input and help! you are like the only person I can seek independent advice from!

    • October 2, 2017 at 7:29 AM

      IMVHO, everyone involved, including your business unit and the Corporate DC will need to comply with the requirements in SAQ A. But this is a question that only your acquiring bank can provide you the definitive answer.

      • 75 Faithless
        October 2, 2017 at 7:42 AM

        Ok, so from a QSA’s point of view you would say, for Example RackSpace or AWS would need to be SAQ-A accredited for us to use them in this solution.

        But the acquiring bank would have the final say if they needed to be or not? Strange one that, I would have thought all service providers would have to provide some accreditation to host PCI DSS services.

        Thanks again. (I am dealing with the exact issues in your latest blog post) 🙂

      • October 3, 2017 at 7:54 AM

        No, a cloud provider needs to do, at a minimum, a Service Provider SAQ D and assess all relevant requirements to all of the services they provide their customers that need to be PCI compliant. It is not as simple as just SAQ A or any other SAQ. There could be services such as MSSP that bring their firewalls and network infrastructure into scope. Definitely their virtualization infrastructure is in scope. So it is not as simple as just SAQ A.

  28. 77 Bel
    September 28, 2017 at 9:43 AM

    My company is implementing a PLCC (private label credit card). I understand that it will not be in scope for PCI, however does the PLCC data need to be encrypted?

    • September 28, 2017 at 1:12 PM

      I have a lot of clients that have private label cards. At the end of the day, why would you want to treat them any different from branded cards? It’s much simpler (and safer) to just treat them all the same. At the end of the day, the PLCCs are just like money no different than a credit card, so secure them as well. That is what the majority of my clients with PLCCs do.

      • 79 Bel
        October 3, 2017 at 2:45 PM

        Yes, thank you. That’s exactly what I have conveyed to management.

  29. 80 JAM
    September 26, 2017 at 3:08 PM

    We have the “secure pause” feature that agents activate when accepting payments to eliminate the PAN information from being recorded in the call recordings. This has helped reduce our PCI scope but what if our compliance reviews find cases of human error and PAN data is recorded. Does this one or two incidents cause the call recordings to be in-scope again? How should one off incidents be handled to keep call recordings out of the PCI scope?

    • September 27, 2017 at 4:13 AM

      Accidents will happen even with fully automated solutions. When found, the sensitive information should be redacted from the recording and the redacted recording replace the original recording.

  30. September 18, 2017 at 11:56 AM

    Hi PCI Guru – a quick question on ASV scans. We have a retailer who has multiple branch sites connecting back to HQ for card processing. Most of these branches set up VPN tunnels site to site, so these IPs are in scope for ASV. They have handful very small branches that utilises normal broadband (with dynamic IP addresses) or even satellite and connect via SSL VPN to do manual updates.

    Due to their small setup, they do not get any fixed IPs (like home users). How do these branches do their ASV scans (obviously they will change IPs daily – or even more frequently everytime their router reboots or turns off at the end of the day or whenever)? These dynamic IPs are only used for outbound access and not for any services in the branch itself…

    • September 19, 2017 at 4:46 AM

      Dynamic IPs do not always change, but they CAN change which is the problem. You need to test them while you know their IP addresses which as you have found can be tricky and time consuming. It just takes patience but you will get them scanned.

      • September 20, 2017 at 4:05 AM

        Thanks PCIGuru – yes it just seems a little strange that PCI requests us to tests these dynamic IPs. In fact, some QSAs we spoke to told us there is no need, as long these are outbound; while some tells us that we need to purchase static IP addresses, else the scope keeps changing. We didnt find anything clear on this on the ASV guide.

      • September 21, 2017 at 5:55 PM

        Somehow, you have to prove that the ports are only open outbound though and that nothing will penetrate the firewall. What I have done is test inside a store lab environment and then compared the configuration of the firewall in the lab to the firewalls in the field. If they are equivalent, then it is likely they would all respond the same as the lab one. But this only works when the equipment is all the same.

  31. 86 Jon
    September 11, 2017 at 12:39 PM

    I wanted your opinion on the following FAQ item, which I pulled from a QSA site:

    Q: Is antivirus and anti-malware eliminated from requirements with P2PE?

    A: For eligible merchants deploying a PCI-listed P2PE solution, the remaining controls can be found in the SAQ P2PE. The controls do not include antivirus or patching of the POS or other systems that may otherwise be in scope.

    Thoughts? In particular, with regards to POS terminals. Cheers,

    • September 18, 2017 at 10:22 AM

      They are correct that the SAQ P2PE does not cover anything in section 5 of the PCI DSS. The rationale being that the POI (SRED certified) is encrypting the data at the swipe/dip/entry, so nothing else can gain access to that data until it is decrypted somewhere further down the road from the POS. As a result, what would infecting the POS accomplish if it cannot get to the data? Now if the P2PE solution endpoint is a server on the merchant’s network instead of a third party, then you need to ave AV there and anything it connects, but still not on the POS.

  32. 88 Alan
    September 7, 2017 at 8:52 AM

    what’s your opinion on bars and restaurants holding credit cards for a Tab?

    • September 8, 2017 at 2:54 PM

      PCI does not cover those situations. You should obviously protect those cards, but if a customer physically hands you their card, that was their decision.

  33. September 4, 2017 at 2:28 AM

    we’re working in a project to provide Self Services Payments in Motorways. As you probably know Motorways are working in off-line mode and it’s not required the PIN in anycase. They’re a specific case below PCI normative.
    So, our question is about what are the requirements for card readers (mag strike, EMV chip and CTLS/NFC) in motorways?

    Many thanks

    • September 5, 2017 at 6:15 AM

      As far as I am aware, motorways are not treated any different from any other merchant, off-line or on-line. So the card terminals have to be PCI PTS validated, EMV capable, acceptable to the card brands and able to securely store the payment data until it is sent to the processor(s).

      • September 6, 2017 at 2:13 AM

        many thanks, I believe that Mastercard and Visa have some exceptions for Tollways, i.e.:

        CVM Requirements for Maestro Cards
        MasterCard permits Maestro No CVM card acceptance at Europe transit vending
        machines, parking, garages and tollways. To facilitate acceptance in these
        environments, ‘No CVM’ may be included as the final entry in the CVM list of
        Maestro chip cards issued in the Europe Region.

        Terminal Certification:

        R MS CT RA112.13 For Maestro transactions below or equal
        to the applicable limit, the terminal kernel
        must have been EMVCo Level 2 approved
        based on a configuration with No CVM as
        the only CVM.

        R MS CT
        RA113.13 The terminal must have successfully
        completed MasterCard chip certification
        for Maestro Vending, Parking and Tollway
        No CVM transactions.

      • September 8, 2017 at 2:57 PM

        Everything you cite is for Maestro which is a MasterCard product that is exclusive to Europe. Not sure Visa has the same rules.

        All I know is that in the US, I have never encountered any rules specific to tollways and card payments.

  34. 94 Dan
    September 2, 2017 at 4:42 PM

    Hey PCI Guru, is it acceptable to store first 6 or 8 in the clear and mask or even tokenize remaining 7-10 of PAN?

    • September 5, 2017 at 6:18 AM

      No. The first 6 and last 4 of the PAN are the only PCI DSS acceptable digits a merchant is allowed to store. That does change with PANs longer than 16 digits, but if you are using PANs with 15 to 16 digits, only the first 6 and last 4 may be stored.

  35. 96 gilagolf
    August 25, 2017 at 4:43 AM


    We are doing our merchant SAQ now and we have a very simple setup, just a few Electronic Data Capture (EDC) credit card terminals issued by our bank, maintain and managed by our bank (Verifone Vx520) and we accept cards through this terminal. This terminal utilises SIM cards and uses the 3g/4g network to connect to the bank (as opposed to dialup which is rare these days)

    However, we are now not sure whether to do SAQ B or SAQ B-IP. Our acquirer is supposed to advice us, but they tell us to just be compliant and when asked, they even suggested us to do SAQ D if we are not sure. We think it is SAQ B, since we have no idea of the 3g/4g network used, but we find no reference to this, only “standalone dialout terminals”. SAQ B-IP could be possible as well, since these 4g/3g communication would be considered “IP devices”? But queries like ASV scans – how can we perform on these since we have no clue what IP addresses they are using since they are directly connecting out via 3g/4g simcard that doesnt belong to us.

    Thanks and keep up the good work

    • August 25, 2017 at 4:52 AM

      While you are on a cellular network, in my experience, most banks tell people to follow SAQ B because these terminals work similar to a dialup terminal, just over a cellular network.

  36. 98 Michael Q
    August 21, 2017 at 5:08 PM

    Hi PCI Guru, I’m looking for some insight into a scoping question in regard to external networks where data may be shared through something like an integration (web services, etc). In terms of passing card data to a 3rd party, regardless of whether my CHD environment is compliant, what is my organization’s responsibility in knowing whether an external network is compliant or not? This is assuming all proper segmentation and encryption items are in place to facilitate the exchange of data. But once that data is in an environment that is out of our control, would that not be considered out of scope in regard to our compliance?

    • August 25, 2017 at 4:59 AM

      It is out of scope as far as your organization’s compliance, but your organization is responsible for ensuring that all other third parties are also following PCI requirements and are secure. That could be done by assessing them yourself as part of your assessment or getting an AOC from them.

  37. 100 Kevin
    August 20, 2017 at 2:54 PM

    First, Thank your for your work and willingness to discuss and guide the community!

    I had a question, if a SaaS company uses Stripe or Braintree or similar technology on their site to collect fees and payments, and my company has a contract with the SaaS company to manage events like classes, concerts etc (including collecting registration fees for us), Aren’t they a Service Provider and therefor required to provide us with a SAQ D?

    The SaaS company maintains that they are only required to provide a SAQ A because of the redirect technology. I agree with that if we wrote and hosted the site ourselves , but it’s their status as a Service Provider that makes me think that they need a SAQ D or a SAQ A – SP. Is that accurate?

    • August 25, 2017 at 5:03 AM

      As a service provider, they are only obligated to provide you with their service provider AOC, not their ROC or SAQ.

      That said, to clarify things. The service provider could have followed the requirements in SAQ A because of how they have implemented the payment process. But they must follow the service provider SAQ D or the ROC in their assessment process that results in their service provider AOC. It’s just that the SAQ/ROC will have a LOT of ‘Not Applicable’ responses to most of the requirements because they are following SAQ A requirements when they fill their assessment out.

  38. 102 Bryan Carter
    August 16, 2017 at 1:48 PM

    PCI Guru,

    I have a question regarding the protection of CHD in a troubleshooting event.

    We have several “brand name” computers that are acting as gateways in a retail store environment. Each store has a gateway machine that collects and transmits CHD from the registers. These machines are obviously in scope, and all requirements for PCI are met. The gateway does store CHD for a limited time before being forwarded to the processing system.

    Several of these machines from various stores are having performance issues related to their performance using SSD drives, and the “brand name” vendor has been contacted for support. We have now got to a point where they are requesting us to send one of the machines “as is” from the production environment so they can test it. There offer is to send a new one, have us copy the image to it and put it back in production. Then we are to send them the original without any alteration.

    What would our options be that would allow us to continue to protect the CHD in this scenario?

    Your thoughts are most appreciated!

    • August 18, 2017 at 5:37 AM

      Ah, what to do when you need to debug. But with the twist of the vendor being involved. It all depends on the protections of the CHD now in place. I am assuming that the CHD is encrypted somehow on this gateway whether by TLS, AES, 3DES or some other method, so the data should be protected. That being the case, you should remind the vendor that there is CHD on the device and it needs to be protected. I would also make sure it is shipped with some sort of tracking capability and signature required on delivery.

  39. August 10, 2017 at 7:42 AM

    Hello PCIGuru
    I have seen the document on PCI Security standard website on password guidance. Wonder if there are any changes coming to aliagn with what is in the below link or any comments on the below link.

    Best Regards

    • August 11, 2017 at 6:20 AM

      Not sure, but it will be interesting to see if any changes result from that new guidance.

    • 106 Erik
      August 23, 2017 at 4:54 AM

      The guidance seems to be in line with (or based on) the draft for the new NIST guidelines (SP 800-63-3).
      In general, I think the new guidelines are good, with a focus on experience from research of actual security breaches. It will be something of a revolution to introduce it though, as it contradicts a lot of previous best practices and standards.

      I’m guessing that PCI will eventually have to introduce changes to adapt.

      • August 25, 2017 at 4:53 AM

        No doubt. These new NIST standards will be something to see being rolled out.

  40. 108 Niks
    August 3, 2017 at 2:26 AM

    Hey PCI Guru,

    Thanks for this awesome PCI resource.

    I have really small query and would like your guidance for the same.

    I would like to know if I should include my unassigned public IPs in ASV scans. The IPs are not assigned to any systems/server and does not host any service as of now.

    Also, if I do include the IPs in the scan I would like to know whether the scan result will be Pass or Inconclusive.

    Please provide your valuable comments.

    • August 11, 2017 at 6:24 AM

      If your ASV charges by the IP, then I would not incur the cost. If they do not charge by the IP, then I would include them.

      That said, I would periodically run Nmap against the IPs using Quick Scan just to see if any of those IPs turn up with devices.

  41. 110 LeftCoast
    July 25, 2017 at 9:09 AM

    Hello PCI Guru,

    I am a level 1 merchant that just finished installing a non-certified, E2EE to the bank, EMV, semi-integrated solution purchased from my merchant bank. The bank says I qualify for the TIPs program from VISA and the corresponding programs from the various card brands. There isn’t a lot of clear direction for Level 1s on what I have to do moving forward other than maintain PCI compliance. When I bring it up with my current assessor, they claim I still need to do an on-site assessment (I think they need the $$$) but my bank’s compliance officer says no and I don’t even need to do external scans too (I will keep doing them for my own sanity).

    Ultimately, I want to maintain a high level of security but I don’t want to punch myself in the face trying to do it if I don’t have too.

    So, I guess my question is, have you worked with level 1 merchants in the TIPs program and what do they need to do for PCI moving forward?

    Thanks for the time!

    • July 29, 2017 at 7:56 AM

      The TIPs program is a Visa program and has nothing to do with PCI. So while Visa can say whatever they want about benefits of their program, it has been my experience that you still must conduct a PCI ROC assessment for the other card brands.

      Assuming you only have a retail payment channel, the good news is that with a letter or email from you acquiring bank explicitly giving you P2PE scope reduction for their E2EE solution, you can follow the requirements in SAQ P2PE when you do your ROC.

  42. 112 ABC
    July 9, 2017 at 7:53 PM

    Hi PCI Guru,

    I was wondering how you would apply PCI requirements 7,8 and 10 to AWS account id/ root id? Shouldnt it be treated as consumer accounts and therefore be outside the purview of an organisation? Please advise.

    • July 23, 2017 at 8:01 AM

      Not exactly sure what you are referring. If you are referring to the accounts used by Amazon themselves, that is what their service provider Attestation Of Compliance (AOC) is providing. If you are referring to the AWS accounts that your organization sets up, those are all on your organization to manage, secure and maintain and therefore are covered by 7 and 8. As to monitoring those accounts, there are ways to do that to comply with the requirements in 10. So I’m not sure what exactly your issue with all of this regards.

      • 114 ABC
        July 24, 2017 at 11:00 PM

        Thanks for your response PCI Guru.

        Apologies for not being very clear here. I am referring to the root user account(I think this is the id against which AWS bills its customers??); please refer to This is different from AWS IAM accounts, as you have rightly pointed out, which are to be created and managed by AWS customers. There are some controls from requirement 7 (which focus more on which user needs to have root user access –
        I believe this cannot be determined by AWS), requirement 8 (which focus on management of accounts, e.g. changing account credentials in the event of termination of employment of the staff with root user access) , which I think would apply to the root user account. I would appreciate if you share your experience on how such accounts are dealt with in other organisations complying with PCI DSS.

      • July 29, 2017 at 7:59 AM

        The AWS “root” account should be treated similarly to a console account of a firewall or router. It should only be used in emergencies when no other way in will work. The password should be kept in a secure place and require management approval to obtain and use. Normal administration should be done through individual administrator accounts using the IAM features and MFA.

  43. 116 Barry
    June 19, 2017 at 6:45 AM

    Hi PCI Guru, are you operating in the UK? We are a small scale (SAQ D) service provider which simply transmits tokenised data from a web portal that receives PAN data in an https web page which tokenises it immediately via a payment gateway. Can you tell me where we can get hold of some template service provider agreements that we could use as part of our relationship with our customers?

    • June 27, 2017 at 4:49 AM

      Sorry, but I am based in the US. Your best bet is to make friends with a barrister and get language from them.

  44. 118 chandramani
    June 18, 2017 at 12:55 AM

    Q1. Do application on ATM have to be PA-DSS ?
    Q2. What is difference between SAQ’s and Level 1-4 ?

    • June 22, 2017 at 11:54 AM

      Technically, ATM applications should be PA-DSS validated, but I am not sure why that is not being enforced. Possibly because of the other regulations they must meet.

      As to merchant levels, those are defined by the card brands. So you need to visit their sites to get that answer.

      SAQs can only be used by Level 3 and 4 merchants. MasterCard requires Level 2 merchants to essentially perform a Report On Compliance (ROC) but go to their site for the actual rules. It’s a footnote, so you’ll be looking for fine print.

  45. 120 JazzintheCity
    June 15, 2017 at 7:01 AM

    Hi PCI Guru!

    I have a question for you on CD/CI. I have a client that uses a marketing vendor who makes their code available on their hosted portal for us to copy and drop into our environment (its straight javascript on all webpages, including payment). It is designed to tailor specific offerings based on a customer’s purchase and browsing history. The deal with this vendor is that my client asks for changes and then the company updates the code where we then copy and drop it into their environment. The “rationale” was that the marketing teams make changes to their promotions and try to tailor experiences for the customers on a regular basis and do not have time to wait for the normal scrum/sprint process (2wk iteration). Changes to code could be multiple times per day.

    The problem we are running into (“one” of the problems – no pun intended hehe) is that the vendors refuse to be PCI compliant as their products are not designed or contracted to be PCI compliant, even if used in a CDE. I did research the contracts and they negotiated several years ago without any security clauses in them. I’ve tried to see if the Vendor could work with us and give us audit logs or if we could reduce the number of areas the client uses this code but that is not working. I was thinking that as a mitigating process maybe we could scan the code after it is in production via our normal code review processes and then have marketing go back to them and fix or pull any malicious or bad code as a potential mitigating process.

    What are your thoughts on this? Have you seen other solutions for this type or area or for environments with higher volume continuous delivery/continuous integration at other clients?

    Any thoughts are greatly appreciated!

    Thank you in advance for your thoughts!!

    • June 22, 2017 at 12:01 PM

      If the vendor of the code refuses to conduct their own PCI assessment, then it is incumbent upon the merchant/service provider using their code to include that vendor as part of their own assessment. At a minimum, that will mean covering their hiring practices, security awareness training, information security policies/standards/procedures, development practices and the security on their systems used for development.

  46. 122 DN
    June 12, 2017 at 8:59 AM

    Hi PCI Guru,

    Quick question in regards to prepaid cards. My company sells prepaid cards and activates them for use. Is this process in scope of PCI?

    The cards are not activated by our merchant acquirer, but by another company.


    • June 12, 2017 at 1:38 PM

      If your company never stores or comes into contact with the PAN, then it should be out of scope. Where you do risk some scope is if the activation process occurs on your company’s PC or other device.

  47. 124 jackblaze11
    May 30, 2017 at 11:54 AM

    Had few queries on POS terminals and their PCI DSS/ PA DSS Applicability
    1. Does PTS approved point of interaction contains payment application residing on it? Also do they have to be PA DSS Compliant?
    2. There are payment application which are PA DSS compliant. Along with this application there are some customization done as per client and is included as an module. Will this customized module need to be PA DSS? OR can this module be covered in client’s PCI DSS certification?

    • June 4, 2017 at 9:48 AM

      Answer to #1. The PTS covers the hardware and firmware in the POI. No, the firmware/software in the POI does not have to be PA-DSS validated as that is what the PTS is for.

      For #2. Any customizations to a PA-DSS validated application that are bespoke to a specific customer do NOT require PA-DSS validation. They are the same as if the customer developed the application in house and therefore must be assessed as part of the customer’s PCI assessment.

  48. 126 Robert
    May 17, 2017 at 10:02 AM

    Hello, I was wondering if you could shed some light on the subject of the handling, securing and treatment of vulnerability report data results. I have searched for a while and haven’t found much on the subject. As you know a vulnerability report can and generally does contain some pretty sensitive information, so does the SSC provide any guidance and do QSAs look to see how organizations control this information? Is developing a policy that outlines who has/gets it and why (justification) along with a tracking mechanism that shows they have been educated on the sensitive nature of the PCI-related data they’re dealing with? Any recommendations? Thank you.

    • May 17, 2017 at 1:27 PM

      The PCI DSS says nothing about how you secure any sensitive information other than SAD/CHD.

      Most organizations cover this topic as part of their data classification standard.

  49. 128 Erik
    May 8, 2017 at 7:38 AM

    I’m having a hot discussion with my QSA colleagues about which facilities are in scope for physical access controls (Requirement 9).
    Example: A company has a customer support center where personnel are using an application that can access cardholder data, e.g. to handle chargebacks and disputes. The application is hosted in the CDE. The local workstations in the operations center do not store cardholder data, but can display it on the screen. The personnel can only perform operative tasks (no administrative access). They use multi-factor remote access (to the CDE) before they can access the application.
    Would the operations center be in scope for physical access controls (video surveilance, visitor management, restricted access to network jacks, etc)?

    • May 9, 2017 at 7:12 AM

      It depends on the organization and their security policies, standards and procedures.

      One risk is that someone installs a keyboard logger or memory scraper on one or more of these systems. Another risk is that someone tampers with a switch and begins sniffing network traffic. If the physical security controls are not sufficient to manage those risks, then I would say they should be enhanced.

  50. 130 Peter
    April 6, 2017 at 3:18 PM

    On SAQ A v3.2, if you successfully satisfy 9.1.1 and 9.1.2, is it possible that 9.1 could not be satisfied? If so, why does it have its own answer section, instead of being a heading whose response boxes are absent?


    • April 7, 2017 at 6:40 AM

      The SAQ A v3.2 I am looking at starts at 9.5, not 9.1, so I’m not sure what you are looking at or what your question is referring.

      • 132 Peter
        April 7, 2017 at 9:49 AM

        I meant to say SAQ *C* v3.2. Sorry to waste your time like that.

      • April 7, 2017 at 3:42 PM

        Everyone makes a mistake every now and then.

        I would think in order to have a ‘Not In Place’ in 9.1, that would require one or more ‘Not In Place’ marks in one or more of the requirements in 9.1.1 or 9.1.2. I suppose there could a rare instance where someone feels that while 9.1.1 and 9.1.2 are fine, there is some other issue that makes the facility controls inadequate such as say there is no guard at a visitor door during business hours and employees are expected to provide that function.

  51. 134 s crow
    April 5, 2017 at 2:51 AM

    Hi, i was wondering if you could give us some insight into the release date of V 3.3 of the PCI DSS. As it has moved to an annual update and it was released in April of last year, i was expecting to have read some chatter somewhere on the internet but i cant find anything!
    Appreciate any information you can share.

    • April 6, 2017 at 12:51 PM

      The Council has given up on a fixed schedule for new DSS releases so your guess is as good as mine.

  52. 136 aluminex
    March 29, 2017 at 10:20 AM

    This question is in reference to service providers / payment gateways. The PCI requirements around password complexity, expiration, and audit logging are pretty clear. However, our current payment gateway does not enforce any of these requirements. For instance, we are working on a manual process to enforce password changes after 90 days. As a payment gateway, aren’t they required to have these controls in place for customers.

    • June 12, 2017 at 1:49 PM

      Yes, the gateway is also required to meet the PCI requirements. Why they do not is a mystery to me.

  53. 138 LuckoIrish
    March 15, 2017 at 8:20 AM

    Hi Guru,

    Got a question related to one of my clients that I wanted to run by you and get your thoughts.

    If a company had a dedicated connection to a TPSP (tunnel terminates on TPSP hardware) and the TPSP had unrestricted access to the company network and applications in the CDE, are there any potential options to implement MFA without requiring all the TPSP users to use VPN tokens as one of the factors?

    TIA for your help & insight!

    • March 15, 2017 at 9:14 AM

      Under the new guidance for MFA from the Council, not that I am aware. They are a third party and need to use MFA to access the CDE. That said, once we pass January 31, 2018, even your own administrators with access to the CDE will have to use MFA, so you might as well invest in an MFA solution for your CDE.

      • 140 LuckoIrish
        March 15, 2017 at 9:40 AM

        That is kind of what I figured – my only other crazy thought was, would a VDI solution work or would they still MFA to the VDI?

        Thanks again for your help on this!

      • March 15, 2017 at 1:28 PM

        Anyone with direct access to the CDE needs to use MFA. As a result, using a VDI solution would be easiest if the MFA was implemented for accessing the VDI.

  54. 142 Charles
    March 8, 2017 at 2:02 PM

    Do the terms “review” and “assessment” have different meanings within the context of scoping of what is required to evaluate and what should be or recommended to evaluate?

    • March 8, 2017 at 3:30 PM

      A review usually means that you want to confirm your scope and identify and potential gaps in compliance before you go through the assessment. The assessment is when you are officially doing your SAQ or ROC.

  55. 144 Sarah
    March 8, 2017 at 11:37 AM

    Hello, I’m having some issues with third party service provider agreements. Specifically, our POS company does not feel that they qualify as a TPSP. They are not involved in the processing, storage, or transmission of CHD but they do continue to update/support the POS system. I’ve read the PCI SSC Third-Party Security Assurance document and I think it points to POS companies/QIR’s as being service providers that require written agreements.

    Our POS company claims they have never been asked to sign a third party service provider agreement and they refused to even discuss it. Am I totally wrong in my interpretation of TPSP’s?

    • March 8, 2017 at 3:37 PM

      No, you are not wrong. Just because the rest their customers don’t know any better is not your problem. They are providing you a service on an in-store device (assuming it’s in-scope). You need a contract AND an AOC from them as a service provider for all of those services.

  56. 146 Jeff
    March 8, 2017 at 8:33 AM

    Forgive me for what might be a stupid question. My knowledge of PCI compliance requirements is growing but by no means am I an expert in this area, hence I’m turning to those who are for a simple question:

    Is it “normal” for a 3rd party processor who leases a company POS terminals to issue the Merchant ID’s for the company leasing (using) the POS terminals for transaction processing?

    My understanding was that the acquirer (banking institution) was the one that issued a company their Merchant ID’s, and not 3rd party processors. Can someone clear this up for me if I should be concerned?

    Much thanks!

    • March 8, 2017 at 3:33 PM

      Some processors and gateways will act as an intermediary between your bank and your organization and issue your merchant ID if you do not have one. I would want to confirm that they are working through the bank you intended.

  57. 148 b
    March 7, 2017 at 12:18 PM

    First of all, thank you very much for creating this blog – it is very informative!

    I would like to ask about work-from-home Call Center Representatives. My company is considering a work-from-home CSR model wherein CSRs would take customers’ credit cards over the phone, and enter them into a payment processor page. We currently have on premise processes doing this (PCI Certified), with many technology controls in place (not limited to firewalls, disabled call recordings, encryption, etc…) as well as facility controls (not limited to clean desk policies, well-identified work areas for card processing with signage, background checks on CSRs, etc…).

    The question I have is not about the technology (I believe this has a solution), but the ‘facility’ itself. Since clean desk policies and signage (and similar controls to defend scope) are not feasible in a home environment, is there any solution that would allow a work-from-home CSR to take customer credit cards over the phone (by voice, without IVR)?

    Have you seen any precedence for this type of model working while maintaining PCI Compliance? (ie – how do pizza chains and banks do this… or do they?)

    Many thanks,


    • March 7, 2017 at 2:53 PM

      The home CSR has been around for a while. In the end, it all comes down to your organization’s willingness to accept the risks that you cannot completely control. I have some clients that do occasional visits to check that policies are being followed. I have other clients that use built in video cameras when the CSR is online to do spot checks. It really is up to your organization to determine how they want to handle things and what is appropriate. The key thing though is to make sure that everyone is aware of your monitoring techniques and rationale for that monitoring.

  58. 150 Seth
    March 2, 2017 at 4:03 PM


    I have a question in regards to required penetration testing. I have gotten multiple answers if workstations that are in the CDE need to be pentested. Some say, for workstations, pentests don’t apply (only vulnerability scanning is required) others say that they require a full pentest just like any server or network device in scope. Which is right?

    thank you,


    • March 4, 2017 at 9:54 AM

      If it is in the cardholder data environment (CDE), it must be penetration tested.

      • 152 aluminex
        March 29, 2017 at 10:23 AM

        Does this include networks, systems, and applications? For instance, payment applications and any other applications that contain, or transmit CHD? Also, how does this affect third parties (SaaS) that provide this as a service provider? Would validation of their PCI Compliance be adequate?

      • June 12, 2017 at 1:48 PM

        Yes, penetration testing must include any devices that process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD) or has a connection to a system that does (i.e., all category 1 and 2 devices/systems/applications). If the SaaS provider has provided you an Attestation Of Compliance (AOC) for the SaaS application, then that is sufficient. If not, then you must pen test the SaaS solution as part of your own assessment.

  59. 154 Kevin
    February 24, 2017 at 9:40 AM

    Hi PCI Guru,

    I greatly appreciate your guidance, and I am a long-time subscriber to your newsletter and questions page. My question today is in regards to a mobile application and PCI Scope. If a company develops a customer-facing mobile application that they would download to their Apple or Android mobile device through their respective App Store, how does that affect the scope of the company’s servers for PCI if the app can accept cardholder data? The company is currently fully outsourced payment-wise and is using the SAQ A requirements. The app would only transmit the cardholder data to a 3rd party tokenization gateway. It would never store it or transmit it back to the company. The app would have to communicate with company servers for ordering and log-ins.

    My understanding is that the application would be in full scope for PCI SAQ D requirements, but would this bring the company into needing to comply with the full SAQ D requirements? I have been having a very difficult time finding good information on PCI scope and customer device mobile apps.

    Thanks in advance for your help,

    • February 26, 2017 at 2:14 PM

      Welcome to the club. The Council is not tackling mobile applications because they do not want to regulate people’s wallets. That said, I would highly recommend that you develop your mobile app using the PA-DSS for guidance on how to keep SAD/CHD secure.

      In regards to your organization’s scope, the only thing you are really adding is the development requirements in section 6 based on what you are describing.

  60. 156 Justin
    February 22, 2017 at 12:14 PM

    Hi PCI Guru,

    First, thanks for doing this! My question is this, my company has the standard credit card authorization form that clients/customers send in. Most clients/customers these days do not have a fax machine handy as they are small mom and pop stores. I have a PCI certified efax provider and I was wondering if I could setup a forwarding e-mail address that automatically forwards and deletes the incoming e-mail. Here is the process:

    Client E-mails>E-mail Server Forwards to PCI eFax Vendor and Deletes E-mail>eFax Vendor sends form to printer

    My email provider should not be storing it since it is being deleted so in my mind I want it to work but it seems wrong. I wanted to get your thoughts on it if possible.


    • February 26, 2017 at 2:18 PM

      Your solution will put your email system in scope because no matter how good you think you are deleting messages, they will exist somewhere. In addition, no matter how diligent you think you will be on training, there will be some of those forms that get forwarded by people that just forget that they are not supposed to do anything other than print them out.

      A better solution would be to have your eFax provider send them to a secured printer and then have people have to logon to the printer to physically print them out for processing.

  61. February 3, 2017 at 6:26 AM

    Hello again Guru, apologies if this is the wrong topic to post this enquiry (regarding scoping) but thought the topics listed under scoping are more your topic posts than discussion posts. Anyway, i would like to query scenario 5 in the Open PCI Scoping Toolkit. I have a similar set up with a category 1a workstation and further workstations that are not used for processing CHD which may be segmented or not from each other. This is because the 1a work stations use a web application to process CHD, this application is hosted in a data centre provided by our ISP who provides an internet break out connection for general internet usage. The application in question is accessed via a URL just like customers who use our ecommerce websites (on the same platform). A firewall detects when 1a workstations are accessing the CDE application based on the URL and rather than sending them out on the internet to come back in to the application it routes the workstation directly onto the application. However there is nothing stopping any other workstation from accessing the URL via a web browser either. The application is accessed over an MPLS and uses TLS as standard, the application requires a log in with username and password, so even users who use the application for other purposes cannot access the CHD collection page (job role based access) but I cannot get my head around the fact that regardless of this the application is accessible to all internal staff who have internet access (we do not limit access via IP as we hot desk and repurpose desktops quite a bit). So my understanding would be that the desktops used to process CHD will be 1a while desktops segmented on our network that do not process CHD would be category 2b correct or would they also be 1a because they have the potential to connect? but not sure about any unsegmented desktops that are not used for CHD but can access the application, the operator would have to be using a user account that had access to the payment page and would have to have obtained CHD from somewhere else as we do not store CHD, you can only enter it into the application like a customer at home could using a shopping website. Would such workstations be 1a or 2b or other category?/ Thanks again for your insight.

    • February 11, 2017 at 10:02 AM

      If I understand your configuration correctly, you are using TLS to secure your Web site that accepts payments. Therefore the TLS connection is what “segments” your 1A workstation and would segment any other workstation regardless of internal or external access.

      Your risk to all workstations is that someone installs a keyboard logger or memory scraper to a workstation and obtains the CHD in that way. As long as you minimize that risk (AV alone in my opinion is NOT sufficient), you should be compliant.

  62. January 26, 2017 at 10:45 AM

    As a follow up to your comment “Also I have seen instances where manual data entry is through the thin client’s keyboard, not the POI which also brings the thin client into scope.”.

    In those instances where manual data entry of CHD is through a at-home/remote agent’s thin client’s keyboard, does this then bring the workstation, running the thin client, into scope for PCI requirement 11 (e.g., vulnerability scans, pen tests, etc.)?

    In addition, does this then bring the above workstation into scope for the credit card ccompany’s PCI requiremnts for an ASV vulnerability scan?

    Charlie K

    • January 28, 2017 at 8:46 AM

      It depends on how that remote workstation is configured. Remember the Microsoft hack a number of years ago when the XP code base was released? That was through a remote contract worker’s home PC being used to access the Microsoft network. That is the risk. Now, how you implement controls and reduce that risk for your remote environment is up to you. This is why a lot of my clients supply their own workstation and firewall for remote access so that they control rules and hardening. But as to ASV scans and other controls, that will depend on how you have implemented your remote access.

      • 162 Nick
        February 8, 2017 at 11:46 PM

        Hi there. Long time reader, first time poster. We have a client that has a website taking payments. They have implemented an iframe (scope reduction not security improvement). Obviously SAQ A if it is done properly. The question comes in that they use a non-compliant Third Party Service Provider to conduct maintenance of the environment hosted in AWS. They also use a non-compliant Third Party Service Provider to conduct development of the website.

        My question is, do these Third Party Service Providers have any requirements in SAQ A. In my view, the maintenance company has no requirements as they have no access to the web config. The development company has no requirements as the payments are via an iframe.

        I would think the development company has some requirements as the iframe code could be altered to go to an evil iframe and nobody would know until the client is not being paid, however, there is nothing in SAQ A to state this.

        What are your thoughts? From a security perspective, proper patching management, FIM, logging etc, but from a PCI perspective, there are actually no requirements?

      • February 11, 2017 at 9:58 AM

        Any third party that has access to the merchant’s cardholder data environment (CDE) is in scope for PCI compliance. So your customer should be assessing their third parties as part of their own assessment if those third parties have not done their own assessments.

  63. 164 Javi
    January 24, 2017 at 9:32 AM

    I heard that for non-profit organizations, trustees or members of the audit committee can directly be held liable for the non-compliance of the organization. Is this true, and if so can you direct me to where I can find the information? I tried google searches, but it does nothing turn up. I thought I check with you before I close this question.

    • January 25, 2017 at 5:55 AM

      It would depend on the laws in which the non-profit is incorporated. That said, in most states, officers of any corporation can be held accountable for mismanagement. You need to consult with your legal counsel for advice on this matter.

    • 166 maxmgc
      February 14, 2017 at 6:25 AM

      Nick raised an interesting topic and I’d like to add to it and probe a couple of principles: the iframe approach allows the merchant to use SAQ A and takes the merchant’s web server out of scope. And when you look at the SAQ A questions there aren’t any requirements that deal with web development (in contrast to A-EP). And regarding 12.8.5, no requirements would be managed by the web developer but I feel that 12.8.2 would be relevant as the web developer could impact the security of cardholder data. Do you agree?

      If this was an on-site assessment of the merchant then would you use SAQ A as a guide to the ROC questions that would be applicable? That would mean that the (non-compliant) web developer’s processes would not be in scope for assessment. With the merchant’s web server out of scope the web developer does not have access to the CDE.

      Thinking again of the SAQ A vs A-EP debate, and compliance vs security, I expect that some merchants and their QSAs might want to go the extra step and use SAQ A-EP as a guide to the ROC questions that would be applicable, even though the iframe approach allows them to “do less”. If this was the approach, how would you handle push back from a web developer who expected their processes to be out of scope?


      • February 14, 2017 at 4:31 PM

        I agree with your assessment, but the Council and the card brands feel that it is an acceptable risk.

        We recommend that even in the iFrame and redirect scenarios that merchants at least monitor the object that invokes the iFrame/redirect for any changes and that any unapproved/unexpected changes stop their eCommerce until they determine it is safe. Full on compliance with all of A-EP is nice, but not required in all cases.

  64. 168 Scott
    January 24, 2017 at 7:47 AM

    I’ve been searching for an answer to this question. According to PCI DSS Requirement 10.5.3, it asks that you send logs to a centralized secure Internal Log server. Would we need to enable multi-factor auth into the internal Log server for audit reviews if the Log server is secured and segregated? Especially if we have firewalls only allowing pushes into the log server but no traffic is allow outside the Log server back the other way. Basically locking it down so you can get into any part of CDE from that Log server.

    Thanks for any help or Guidance on this

    • January 25, 2017 at 5:58 AM

      If the log server has access into and from the CDE, I would prefer it have MFA to access it. But in order to accurately answer such a question, I would have to conduct a review of network diagrams, firewall rules and other documentation before I could give you a definitive answer.

      • 170 Scott
        January 25, 2017 at 7:30 AM

        Thanks for your reply. if this helps the CDE pushes logs out to the Centralized Log Server (CLS). The CLS cannot access the CDE through FW rules, it is one way only traffic.

        Thanks again

      • January 28, 2017 at 8:51 AM

        Under the Council’s latest discussions on scope, your CLS would only have to be securely hardened to protect it from attacks where administrator credentials could be stolen as that would be the risk presented to that device.

  65. 172 Kevin
    January 23, 2017 at 11:28 AM

    Hello PCI Guru,

    I appreciate this website as an excellent resource for PCI news and answers. My question today is related to PCI and mobile applications. Is there a way to configure a mobile app to be able to accept credit card data for submission to a tokenization service provider while keeping the mobile app eligible for a SAQ A without having to use an iFrame?

    Thank you in advance for sharing your knowledge and expertise,

    • January 25, 2017 at 5:59 AM

      Not that I am aware. Only an iFrame keeps the Web site as SAQ A assessible.

  66. January 19, 2017 at 12:05 PM

    Hi PCIGuru,
    Can I use and process Virtual Credit Card in a non PCI environement ?

    • January 19, 2017 at 3:26 PM


  67. January 19, 2017 at 10:36 AM

    I have just come across the horrible Chrome autofill functionality. I was observing operators in our call centre taking orders and cards were being suggested for autofill. Panick!!!! well maybe not literally but needless to say the only solution was to stop all users using Chrome when working with our internal web application that processes orders. and to erase all cache and browser histories and to use a secure erasure tool to make sure it was all gone. I dare say we could set the advanced autofill settings to stop Chrome storing card details or we could try fooling Chrome by naming the card field to something Chrome wouldn’t recognise as a field for auto filling. Are there currently any solutions you know of for continuing to use chrome or is it a case of stop using it until Google sees fit to rectify the situation?

    • January 25, 2017 at 6:04 AM

      Chrome is insidious for more than just auto-fill. Most call centers do not use Chrome because it collects and sends usage and metadata information back to Google. As a result, if you are going to use a browser other than IE, use Firefox or Opera.

  68. 178 Tage Rasmussen
    January 7, 2017 at 7:49 AM

    Thanks for a very interesting and informative blog.

    I have a question regarding scoping and PCL compliance requirements for a specific scenario that I would like your view on as I do not think it is quite clear what the requirements are.

    Scenario :

    A Level 2-4 Merchant has a E-commerce solution using either a URL redirect or iFrame for the payment page to a PCI compliant PSP. The solution is hosted 100 % at a MSP.

    The MSP handles less than 300.000 transactions and is therefore a Level 2 service provider.

    In this scenario the PSP of course need to be full PCI compliant as they handle the CDE and the Merchant need to comply with SAQ-A.

    But what about the MSP that hosts the e-commerce solution in this scenario ?

    In PCI terms the MSP is a servcice provider and therefore need to adhere to “SAQ-D for service providers” but what is the PCI scope and are most controls not considered N/A as this environment does not have access to the CDE environment at the PSP ?

    Using the PCI scoping toolkit one could argue that the webserver hosting the redirect URL or iFrame to the payment page at the PSP is a category 2b system, but then again all internet connected systems has access to this payment page.

    The risk in this scenario is primarilly that the web server is compromized and the payment redirect URL/Iframe modified. But does this mean that all components of the e-commerce solution and the system used to mangage this are in scope for PCI DSS ?

    • February 18, 2017 at 3:45 PM

      Your customer in this scenario needs to comply with the requirements in SAQ A. I would argue that puts your organization as the MSP out of scope as you do not process, store or transmit cardholder data (CHD) or sensitive authentication data (SAD). However, I could see a bank arguing that you should also comply with the requirements in SAQ A. So you would then have an SAQ D that is full of a lot of Not Applicable responses.

      That said, if you know you have one customer that needs PCI compliance are they really the only one?

  69. 180 Marc Jones
    December 21, 2016 at 2:06 PM

    Can you recommend a free iptables audit tool?

    • December 22, 2016 at 8:27 AM

      I am not aware of any open source iptables audit tools.

  70. 182 Bruce LeBel
    December 21, 2016 at 1:17 PM

    I am posting a new question: Does PCI Scope allow a single device to change its state between Category 1 and 2 (reference PCI Scoping Toolkit) when the network it is connected to dynamically changes? E.g. A client machine uses an internal control to invoke the tokenization process at the proper time. This function first switches the web server connection from the routine business application server to a separate (by definition in-scope) firewalled and secure Payment Card Comm Server (“PCCS”), which is a Category 1 device. When the client is connected to the PCCS a hosted page from the CDE is used for tokenization of a new card. Following tokenization there are no other interactions between the client and the CDE. The client automatically disconnects from the PCCS and reconnects to the routine business application web server. It is never logged in at the same time to both the PCCS and the routine business application web server. If these were two different client machines with continuous connections to the respective web servers then one would be Category 1 (connected to the PCCS) and the other (connected to the routine business application server) would be Category 2 (possibly Category 3, out of scope). Given that this client machine is a single device that connects discretely between the two different web servers, does PCI scope allow this device to change its state (i.e. downgrade its Category) when it is connected uniquely to the routine business application web server vs the PCCS web server? (Note: We’re also seeking a QSA and I’m appreciative of your blog and site. How do I contact you?) Thanks for your help!

    • December 21, 2016 at 1:28 PM

      If a device ever processes, stores or transmits sensitive authentication data (SAD) and/or cardholder data (CHD) it is a Category 1 device regardless of other circumstances.

      If you think about it, how would you achieve Category 1 compliance and then back it off and then put it back into place dynamically?

  71. 184 James Glaves
    December 13, 2016 at 10:33 AM

    Hi PCI Guru, and everyone. Is anyone aware of any official guidance in regards to third-party cleaning/facilities staff accessing a physical cardholder area (such as a call centre). How should these be treated – as visitors, signing in, wearing an ID card and “escorted” throughout? Or should they be considered as contractors needing background screening, completion of security awareness training, etc? It’s a bit of a grey area for me – they don’t really fit into either category.

    As others have said – this is a fantastic resource. Thanks for putting in so much time to sharing your experiences and knowledge.

    James Glaves

    • December 13, 2016 at 12:58 PM

      I have some clients that provide supervision of such personnel when they are working. I have other clients that make sure such people have been vetted and background checked by their provider prior to being allowed into facilities. It all depends on the risk of coming across SAD/CHD during their work. In a call center, I would argue that since nothing is written down, the only risk would be any forms from mail orders, but those should be in locked shred bins at the end of the day. It is up to your organization to determine the best approach to ensure such contractors are not putting SAD/CHD at risk.

  72. 186 Bruce
    December 7, 2016 at 6:21 PM

    Thank you for your informative blog and for sharing your insights and opinions on this complex topic.

    My two questions:
    If a business’s website shopping cart opens a payment page that is a “hosted page” from their authorization provider, e.g. Chase Paymentech, for entry of the sensitive cardholder data, is the business’s web server still “in scope”, requiring a PCI DSS Audit even though there is never any sensitive cardholder data stored on, transmitted through or otherwise touching that web server?

    if the answer to the above is No, then if the same web server of that business performs the (tokenized) settlement transaction with their authorization provider (which is the cardholder data environment), does that fact of establishing the secure connection with the authorization provider for the settlement transaction place the web server “in scope”, requiring a PCI DSS Audit?

    Thank you for your opinion and insights on this “scope” question

    • December 8, 2016 at 6:40 AM

      If your Website uses a redirect or an iFrame (I’m assuming you are using a redirect), then your Web site is not required to be ASV scanned but it still is part of the transaction processing process and needs to be assessed against SAQ A’s requirements. See this post on SAQ A versus SAQ A-EP –

      Your second comment is somewhat problematic in that the server is both a shopping cart AND it does settlement. That may violate requirement 2.2.1 regarding a server providing more than one primary function depending on how the application is implemented. There is no CHD being processed as it is tokenized so that process would not be in scope. That said though, I would be concerned about security of the other information that could be involved and stored on or connected to that server.

  73. 188 DB
    December 1, 2016 at 3:35 PM

    Hi, Thank you for your blog – it is an awesome resource.

    So I have difficulty getting a clear answer to this because the requirements themselves seem to overlap and contradict themselves.

    I’ve heard two things that I would like a “definitive” answer on:

    1. If a merchant has a scan that they failed in the quarter and are about to remediate in the next quarter there seems to be a gray area there. i.e. they can use a solid business justification coupled with a strong vuln management process and change management process showing they are compliant “in spirit” and then pass the scan there.

    My initial thought was that this was wrong and that you absolutely need to have four passing scans within a year or else you were non compliant and thus this would put you immediately into arbitration with the acquirers/card brands etc

    Then I talked to another QSA who said that
    2. No, in fact you need all of what you said, but since 3.2 you only need to show you did 4 scans 90 days apart and have at least one passing scan during the year *and* have all the other stuff in place – solid vuln management process, review meetings, tickets etc etc

    What is the *actual* truth if a merchant is unable to get a scan passed within a quarter?

    • December 2, 2016 at 6:52 AM

      What? You MUST be able to produce four passing quarterly scans. However, it is how you get there that matters.

      First, this is why most organizations scan monthly rather than quarterly. They do their own scanning both externally and internally. That way they are able to stay on top of things and not have a huge surprise at the quarter. This is particularly important in Windows environments where 95%+ of all vulnerabilities patched carry a CVSS score of 4.0+ (i.e., they fail your scan).

      Even with that approach, there are situations where you will not always be able to patch due to compatibility issues or vendor issues. ON the vendor side, this is particularly true with solutions such as IBM’s Websphere and Oracle’s eCommerce solutions. IN both those instances, IBM and Oracle not only provide updates to their own application suite, but also the underlying operating systems. As a result, it is possible that OS patches are not included due to compatibility issues or timing of the release. The approach you need to take in both of these situations is to mitigate any remaining vulnerabilities while you wait for a patch that will work with the application.

      It is that mitigation effort that confuses a lot of QSAs as well as clients. But this is an essential part of any vulnerability management program. You are acknowledging the issue and developing ways to mitigate it and not just sweeping it under the rug.

      • 190 Gina Rogers
        January 27, 2017 at 10:08 AM

        I’m the ISA for my company, and as I’m sure you’ve experienced before, my IT team wants to do absolutely the minimum necessary for PCI. I’m currently receiving push-back on my advice that we need four passing quarterly scans that occurred AFTER our prior PCI submission date. We submitted our SAQ for the prior period on June 23, 2016. My team would like to use the last passing scan from that submission period (scan date of June 22, 2016) to count toward the current period. I am almost certain this is not allowed but I wanted to confirm this. Is there any way the fourth scan for the prior period can be used as the first scan for the current period using a compensating control?

        Thank you in advance for your input.

      • January 28, 2017 at 8:37 AM

        I would agree with you, but sometimes timing does not fall right when an assessment is being conducted. Therefore, sometimes we end up with the Q4 scan from the last assessment as the Q1 scan in the current assessment because of timing. I try to avoid it, but sometimes it cannot be avoided.

  74. 192 Alan Swan
    December 1, 2016 at 9:31 AM

    I have a question about an internal vulnerability scans. I have an issue with a high level vulnerability detection result. This is caused by an expired “SSL Certification Result”. This is a certificate connected to the Dell OpenManage Server Administration set-up/update. The update from 8.3 to 8.4 seems to have installed with an expired certificate. Anyway, my question is, as this is simply an internal scan and the certificate, although expired, isn’t customer facing. Would it really require the installation of a new certificate until I resolve the issues with the OpenManage or roll it back to 8.3? I understand the scan is simply looking at the certificate as it has expired.

    • December 2, 2016 at 6:59 AM

      Mitigate the risk and move on. You will likely have to have a compensating control worksheet (CCW) if this is a scan result that you will not remediate before your PCI assessment is due.

  75. 194 Erik
    December 1, 2016 at 6:38 AM

    Not Tested (revisited)

    Me an my fellow QSAs are debating how to deal with the AoC for assessments where some requirements are Not Tested.

    For example, PCI SCC informs us in an FAQ that we can base the scope of an assessment, and create a RoC, based SAQ A for redirected e-commerce solutions. In such cases, we are instructed to use Not Tested for requirements not included in SAQ A.

    Now, in the AoC (Part 3) we have to check either “Compliant” (full compliance with PCI DSS) or “Non-Compliant”.

    Somewhat contradictory, PCI SSC informs us in another FAQ that if there are Not Tested responses we are not allowed to state that the entity is fully compliant with all requirements. So, does this mean that we have to check the “Non-Compliant” checkbox in the AoC? In that case, the whole Not Tested concept is completely useless!

    What’s your opinion of this?

    • December 1, 2016 at 7:34 AM

      Your not the only one questioning the Council on this as they just discussed this in their latest Assessor Newsletter email. However, based on what they are saying in the December 2016 newsletter, organizations are Non-Compliant. I don’t agree with that but that is how the Council wants things answered.

      • 196 Erik
        December 1, 2016 at 8:00 AM

        I haven’t seen the latest newsletter (it’s not published on the QSA portal yet…).

        We’ve used Not Tested for some Merchant assessments and checked the “Compliant” checkbox in the AoC. The acquirers we’ve dealt with have accepted this approach without objections. It’s a great way to reduce unnecessary complexity for an assessment and the report, making PCI DSS validation easier and cheaper for the assessed entities.

        If you have to check Non-Compliant, then Not Tested is a useless concept that cannot be used in any assessment. No Merchant or Service Provider would ever accept that we present them with a Non-Compliant AoC even though they’ve implemented all relevant requirements.

      • December 2, 2016 at 6:59 AM

        No kidding it is a useless concept. The Council really needs to fix this situation.

  76. 198 LJ_180
    November 30, 2016 at 5:24 AM

    Even having read a lot of literature, I am still not 100% which SAQ I should be using and/or I should be using different SAQ’s for different payment channels.

    My organisation doesn’t sell services as such, but does have methods for customers to pay fees. We have standalone terminals where customers can come in and pay. We allow for customer not present payments over the phone, using the same standalone terminals. Finally, we have a page on our website that redirects to a payment service provider.

    I am thinking that we need to complete SAQ A-EP for the website payments and, also, SAQ B for the other channels. Is this correct?

    Thanks in advance.

    • December 1, 2016 at 7:38 AM

      First, only your acquiring bank can give you the final answer to your SAQ question. So everyone else, including the PCI Guru, will only be providing their opinion on the matter.

      If the point or interaction (POI), aka card terminals, are dial up, then you would follow SAQ B. Otherwise, if the POI are on your network, then you would use SAQ B-IP.

      If your Web site truly is a redirect, then you would follow SAQ A.

  77. 200 Shay
    November 28, 2016 at 7:05 AM

    Hi PCI Guru

    Firstly, your blog is a fantastic resource. Thanks for sharing your expertise with everyone.

    I have a question about transaction counts and Service Provider levels.

    Bit of background. We have a cloud-based SaaS solution, which we host on Amazon Web Services and provide web development or other technical services for our customers, all whom use IFRAMEs for accepting payments. Each customer uses their own Payment Processor Service (e.g. SagePay) with their own merchant account / identifiers. We’ve designed our solution so cardholder data or sensitive authentication data does not touch our web servers.

    Individually, each customer is classified as a Level 3/4 Merchant and annually attest PCI compliance using an SAQ A. As a Service Provider, we attest PCI compliance via self-assessment, and provide our customers with a compliance package to demonstrate this.

    However, now our customer transaction counts, combined, is over 300k; my question is do we *need* to perform an an onsite assessment in order to attest compliance for our solution going forward? Or can we continue to perform our own assessments internally? Are these transaction counts on our customers / payment service provider in this scenario, as long as our solution does not ‘store, process, and/or transmit cardholder data’?

    Thanks in advance.


    • November 29, 2016 at 6:21 AM

      Thank you for your nice comments about my blog. I appreciate it.

      First, I am assuming that your organizations ensures that ALL of your customers are using iFrame payment solutions because your organization manages/develops every site. As a result, your organization is also responsible for meeting the requirements listed in SAQ A although, as a service provider, your organization needs to report its PCI compliance on the service provider SAQ D.

      Technically, your Web sites do NOT conduct the transactions because of the aforementioned use of iFrames. Therefore none of the transactions conducted are processed through any of your servers which is why I am sure you took the iFrame approach in the first place. As a result, your organization’s transaction count is technically zero and, as long as the rules stay the same, will always be zero. Therefore, you can continue to conduct your own self-assessment as long as your customers are willing to allow it.

      The only reason I can see that you might want to consider conducting a ROC would be to get your organization listed on the Visa and/or MasterCard Global Registry of Service Providers. Your sales/marketing folks would likely drive that move in an effort to boost merchants using your hosting services.

      • 202 Shay
        December 8, 2016 at 5:39 AM

        Thanks so much for your clear and considered response. Greatly appreciated!

  78. November 18, 2016 at 10:39 AM


    I have a use case I was hoping to get some advice on. We have a call center that takes card information, but because of our use of P2PE devices and tokenization, we have been able to keep CHD off of our endpoints.

    However, due to how orders are processed, gifts, etc… there are scenarios where 5 orders or more of different types may be submitted. Those orders can be within the same system, or several different systems. Basically, we end up asking customers 5 different times for their credit card information.

    The business is wanting our reps to write down the card number and shred after the call ends. I am looking for options to meet that need without writing down numbers.

    • November 20, 2016 at 4:09 PM

      Sorry to be a downer, but how about fixing your messed up order entry system? Seriously!

      Writing PANs down is a stupid idea and goes against not only the PCI DSS but most call center policies and procedures.

  79. November 17, 2016 at 11:19 AM

    Hi, following the reply number 21. I’m very interested on how PCI-DSS is affecting an eCommerce solution running in Kiosk, but where cardholder data is not keyed but readed using basic emv level 1 devices (not PCI-PTS, not PINPAD).
    For clarification; a mag reader in the kiosk gets the cardholder data from the card and sent it to a webservice of an eCommerce PCI gateway.

    many thanks!

    • November 20, 2016 at 4:21 PM

      It depends on whether or not the kiosk reader is using a P2PE or E2EE solution that takes the PC in the kiosk out of scope.

      • November 21, 2016 at 6:30 AM

        Hi, none, the kiosk reader is not using a P2PE or E2EE solution. It’s only an EMV level 2 reader. The point is that the transactions are processed as eCommerce (CNP) not as a card present ones.

      • November 21, 2016 at 7:38 AM

        What? Why bother to have a point of interaction (POI) aka card reader if you are doing card not present? Convenient for the customer because they do not have to key their information. But silly as a merchant because you are not getting the benefit of doing card present transactions.

        That said, your kiosk is in scope because it is processing and transmitting cardholder data (CHD). Since you did not implement P2PE or E2EE with the reader, then the kiosk is likely handling the CHD in some way.

    • 209 John
      January 24, 2017 at 1:32 PM

      So if you use a P2PE IP terminal then the switch that it connects to is not in scope? No firewall or acl is required?

      • January 25, 2017 at 5:54 AM

        You need to have a firewall to protect the P2PE terminal, but the data stream generated by that terminal is encrypted and only the endpoint it communicates with can decrypt that stream, so all devices inbetween the P2PE device and the decrypting endpoint are out of scope.

      • 211 John
        January 25, 2017 at 11:45 AM

        Ok. If you need a firewall, how come the P2PE SAQ doesn’t have a firewall section?

      • January 28, 2017 at 8:49 AM

        Good question. We are having a similar argument over SAQ A not requiring vulnerability scanning but yet banks required it when a redirect or iFrame is used on a merchant’s Web site.

        That said, you are still required to protect the point of interaction (POI) from the Internet sot hat hackers do not have unlimited access to it to attempt hacking it.

  80. 213 wafiy
    November 15, 2016 at 4:43 AM

    Hi PCI guru.

    regarding PCI req 2.2.1 : enable one primary function per server. I do know that the “Primary function per server is based on the security level” so my question if i have a server that act ac AV, patch and jump server. will it violates the requirement as it does not having storage or processing of card data and the connection if through and specific port only.

    • November 16, 2016 at 5:11 AM

      It’s not the anti-virus (AV) and patching functions that would make me nervous. It is the fact that it is also a “jump box” or out of band (OOB) box providing the gateway into your cardholder data environment (CDE). The reason is that a jump box typically is going to have a LOT of human use ports open in to/out of the CDE. That makes that device a huge attack point and you want to have only the jump box function on that device to truly minimize the risk. As a result, I would recommend setting up a separate jump box.

  81. 215 Dave
    November 8, 2016 at 3:48 PM

    In relation to the the use of SSL/early TLS, I have a question. Does the discontinuation of this type of communication by June 2018 apply to systems that only internally communication on a private network (i.e. not across public networks / Internet)? We have a few internal VMware (version 5.5) systems that communicate via TLS 1.1. In order to enforce only TLS 1.2, we’d have to upgrade to VM version 6.0 and that could be problematic.

    • November 16, 2016 at 5:19 AM

      Welcome to the club. I have a LOT of clients in the same boat.

      Yes. ALL SSL and early TLS are verboten – external and internal use. That said, TLS 1.1 can be configured securely according to NIST SP800-52. However, I am not sure if VMware ESX(i) would support that configuration.

      • 217 Jonatan
        November 16, 2016 at 5:32 AM

        Hi there! I’d like to raise my hand here and as a 2nd question. Since PCI does not require the usage of encrypted channels for CHD transimissions within non public networks, the usage of SSL or early TLS is not mandatory and even though its vulnerable it still better than plain text transmissions. I know an internal vuln scan wound find this but it would aso find a plain text transmissions… so my question is how would you consider this? It’s like “I’m not required to place a door here by I’ve still placed it anyway, it’s unlocked, yes, but whether its there and unlocked and it is not even there, I’m still in compliance to what the regulations says which is u don’t need to put a door”

        I just came up with this question while reading your reply and I’d like to get your opinnion since I consider you have lot of experiencia on several kinds of markets and infrastructure.

        At last, I was wondering for a while now, what’s your opinnion about this SSL and Early TLS requirements applicability to scenarios like AV web administration, Nagios web administration. They are nor used for transmission of CHD but they provide secure access to systems that actually provides security functions to CHDE. Even though the migration of SSL or early tLS within those platforms may require the migration of the tool itself, I tend to belive that SSL and early TLS within web administration interfaces is as critical as for CHD transfer cause if someone compromised such communications can lower the security level of the CHDE by modifying the systems that’s actually provigin security functions.

        Thanks a lot again in advance! I hope you have a nice day!

      • November 16, 2016 at 6:26 AM

        Ah, nice try. SSL and early TLS cannot be used either internally or externally, period. I understand your argument, but if you think about the SSL exploit POODLE, it is actually much, much easier to pull off internally than it is externally. That is why I would be more afraid of inside risks than outside risks.

        Your second example appears to be the old “connected to, connected to” argument and where do you draw the line. The Council has told organizations to draw that line based on your risk assessment. The bottom line is that if those systems/devices that are not directly connected are believed to still have influence on compromising the cardholder data environment (CDE), then they should be in-scope for assessment.

      • 219 Jonatan
        November 16, 2016 at 6:40 AM

        This is why I ask ur opinnion 🙂
        Yep, I’m aware about the explotability of POODLE and how easy would it be to exploit it from the internal network. I’m just playing the devil here by saying something that a customer might say. I’m thinking here that if I tell him to replace SSL or eTLS to TLS 1.2 they might end up telling me something like “ok, i will just remove the SSL/eTLS channel and work in plain text since this is an internal network and PCI does not require to encrypt transmission within the internal network”.
        I just feel like I’m lowering the security level if I put them in that kind of situation. I feel like when something is not mandatory required, I rather see something weak as an extra tweak on security than seeing nothing.
        I know PCI has a lot of situations like this. I’m not trying to challenge PCI regarding internal data transmissions but i do think this kind of situation should be taking into consideration, right? Thanks a lot for your comments! As i sais, they are really valuable due to ur knowledge and experience!

      • November 20, 2016 at 4:24 PM

        They would be well within their rights to just drop SSL/TLS and go back to clear text since it is an internal network. It is a tough thing to push on internal networks. If you are asking the question, then you know your client well and that they are not interested in security. They just want to punch that PCI compliant box and move on. If they really are that silly, I would let them do it and move on. I would also find a new security conscience client to replace them and then cut them loose.

      • 221 Jonatan
        November 21, 2016 at 6:11 AM

        Thanks a lot again for your feedback!!! As I said, it’s always great to get the opinion of someone with your knowledge and experience!

        Have a nice week!

    • 222 ITGuy2
      April 10, 2018 at 1:26 PM

      Internal connections on port 80 (http) would be allowed with additional security features per requirement 2.2.3? Would it be a case of implementing the security features required would be more work than using the compliant SSL version?

      • April 11, 2018 at 5:30 AM

        I have a lot of clients that are stuck with routers, switches, blade chassis, etc. that do NOT support TLS for their Web management interfaces. In order to get to them, the administrator has to use a “jump box” to connect to the network that does have access to those interfaces and then they can use HTTPS over SSLv3 to gain access. In that case they need to document this in a CCW for using SSLv3.

  82. 224 Rich
    November 3, 2016 at 9:21 AM

    Would control 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server be applied to Wireless access points? Some AP’s provide WiFi and do rouge asset detection. Would this make sense?

    • November 4, 2016 at 3:29 PM

      Requirement 2.2.1 is for servers only, i.e., running Linux, Windows, UNIX, etc. It does not apply to appliances such as firewalls with IDS or layer 3 switches, etc. or even your wireless access points that are also acting as wireless sensors for rogue devices.

  83. October 31, 2016 at 2:30 AM

    Hi PCI Guru,

    Thank you so much for your knowledge and help!

    My company has 2 sites. Each site has a virtual desktop (a portal to be used for sales) issued by the vendor for card-present situations. Also at every site there’s a PCI-compliant POS which uses cellular connection (wholly outsourced). The credit card information does not get captured at all. Credit caress will only be inserted for using the chip. Which SAQ should we use and which overarching controls you think would apply to us? Thank you

    • November 8, 2016 at 3:36 PM

      Good question, but I have no idea because you have not supplied enough information for me to give a decent answer.

      That said, you cannot rely on my opinion to determine what SAQ you should use. What SAQ to use can only be determined by your acquiring bank. If the bank cannot give you an answer, then I suggest you find a new acquiring bank.

      That said, the first thing the bank will want to know is how many transactions you process both card present and card not present by card brand. Once you have that, then you can determine your merchant level. Next you need to determine if the card present transactions are encrypted at the swipe/dip or by the POS. How that happens will determine what SAQ you will use to report your compliance. Again, the only official decision on what SAQ to use can be given by your acquiring bank. Anyone else is just giving you their opinion.

  84. October 26, 2016 at 7:14 AM

    This miscellaneous questions page is a great resource but it is VERY big and takes quite a while to load (even with good bandwidth). Since the page has so much content, a “Find on this page” search is pretty much always needed but the lengthy download time means waiting what seems forever 🙂 to get started.

    Would you be able to break the page up, say by year, so the load would be faster?


    • October 28, 2016 at 3:19 PM

      You are not the first one to complain about the Miscellaneous Questions page. I just need to set aside some time to break it up. Thanks.

  85. 230 Patrick
    October 20, 2016 at 1:38 AM

    Hi, I’ve got a question regarding PCI compliance and MS Active Directory. I’ve been asked to look at merging Active Directories between 2 companies. 1 of these companies is PCI compliant and one not. To start things off I’d like to create a domain trusts between the 2 companies, what’s the minimum I need to do to setup this trust without impacting the PCI compliance of the company?


    • October 23, 2016 at 7:11 AM

      Unless you are granting access to people from one domain to the other and they will have access to cardholder data (CHD) or the cardholder data environment (CDE), then I would not worry about things just yet. Once you start opening up the PCI compliant company’s network and CDE to the other, then you will start to have an impact.

      • 232 Patrick
        November 1, 2016 at 2:48 AM

        Brilliant, this was the answer I was hoping for. 🙂

  86. 233 ITProSec
    October 18, 2016 at 10:17 AM

    Are there any restrictions in the PCI DSS regarding storing, processing and or transmitting card data internationally (say, backups going offshore, or databases being housed offshore), as well as human operations (overseas customer service reps with access to CC data or taking verbal orders via CC)? I’ve search the PCI DSS document and online and thus far have come up short.

    • October 18, 2016 at 12:15 PM

      Other than protecting the data, the PCI DSS does not restrict the data in this regard. However, there could be legal or regulatory requirements that may get in the way.

  87. 235 Pete
    October 6, 2016 at 4:58 AM

    Hi – The company I work for has a retail chain of a few hundred stores. However they cannot stock every item we sell. Apart from the traditional chip and pin POS solution (we are in Europe) at our tills. We are also thinking on introducing a chrome book like device connected to a segmented (by firewall) public wifi we provide for our customers. This device would allow a customer to only browse our website and carry out a Card not present transaction via our SAQ A ecommerce compliant website (iFrame/Tokenised). For clarity the chrome book like device is standalone and only connected into the public wifi. In many ways it is a cybercafe with only one site to access.

    How does PCI apply to this scenario and indeed are there any card scheme rules that could also apply around CNP transactions in retail stores

    • October 6, 2016 at 3:10 PM

      PCI really does not apply in this situation. But common sense security measures do apply because, in the event of a breach, I would not want to be around your organization as an IT person responsible for these devices.

      I have a lot of organizations that have done just what you are considering. A very few have retained them, others bailed on them when it became obvious to management that they were not worth the effort required to keep them secure and available. Remember, it this age of smartphones, almost everyone has a computer in their pocket, so the need to provide a computer is not as necessary as it once was. Most of my clients have determined it is cheaper and better to develop a more usable mobile application or Web site to accomplish the same goal.

      As a point of clarification, I am assuming that this computer is on your public customer Wi-Fi (you said it was segmented, but I think you meant from your other networks). I would expect transactions will be conducted using HTTPS (required by PCI) which would also be considered segmentation.

      Your first consideration you need to acknowledge is that this device is your organization’s responsibility. As such, your organization is responsible for it’s security (physical and logical). After all, it will be your organization that is held responsible if it is found that any of these devices were responsible for a data breach. Your organization will need to ensure it is patched current, has anti-virus, has file integrity monitoring, log collection/monitoring and other controls to ensure that it remains logically secure for your customers’ use. The reason for these controls is that in the event of a compromise, you can take the affected units out of service as soon as possible. You will also want to have these systems under video surveillance to ensure they are not tampered with or stolen. I would also recommend that you put them in some sort of enclosure to ensure that anyone cannot walk up and insert/attach USB or other devices to these systems. Another option is to take a hot glue gun and fill the unused external ports with the glue.

      Some of these issues are relatively minor to accomplish but some like patching and logging can be difficult, particularly when on a public network.

      • 237 Pete
        October 7, 2016 at 3:38 AM

        Thanks. Agree with all the security points and we would use a supplier to provide a physically secure and lock the solution down.

        Just for my clarification even though it is our device in stores, PCI compliance only applies from an E-commerce perspective and does not change the stores separate F2F compliance submission?
        Is there any clarification or guidance notes from the payments council on this? It does seem a grey area?
        Are there any card brand rules that could impact on this?

        Very much appreciate any advice – we have reviewed a variety of implementations in various retail stores

      • October 8, 2016 at 5:31 AM

        There is no guidance in this area because the Council sees these PCs and kiosks as extensions to the PCI DSS not covering consumers’ home PCs and smartphones. All I can point you to is the legal risks presented should such a device become compromised and your customers’ card data are breached as a result of your negligence in maintaining and securing these systems.

  88. 239 Luigi Figueroa
    September 29, 2016 at 11:45 AM

    Is there a way to show companies, certificate-wise, that since there is no credit card data at all if the company is asking for PCI compliance? Reason I am asking is a company wants to do business with us and is asking for PCI compliance when in our environment, there is no credit card data at all.

    Thanks for your help!

    • September 29, 2016 at 5:38 PM

      The way I have dealt with this in the past is to hire an independent third party to conduct an engagement looking for sensitive information such as cardholder data (CHD) or personally identifiable information (PII) and then issue a report discussing the methodology used and that they did not find any such information.

  89. September 29, 2016 at 2:52 AM

    Dear PCI Guru,

    I am currently working on all assessments for our various brands. I have completed 1 SAQ already (SAQ B) for one brand wiht QSA approval. I have a query for a call centre I am looking at SAQ C-VT for. They currently use a PCI compliant payment portal to process all card payments taken over the telephone. They have automatic Pause and resume when entering the card number into the portal so they never record the card number. My question is around Network segmentation and Server hardening(req 1.2-1.4). Is this really applicable if they are entering the cards into the Hosted Payment page which is compliant and they do not enter the card numbers anywhere else? The Card data is also not stored anywhere as it is a token that is used if a refund to the customers card. We have secure firewalls around our network as a whole but this particular call centre is across them all and not segmented off. Is this absolutely required for SAQ C-VT? As it brings the PC’s into scope that the users are entering the card data (even if it is straight into a PCI-DSS accredited 3rd party payment page)

    • September 29, 2016 at 5:43 PM

      Remember, your call center operators are entering the cardholder data (CHD) through their PCs which means a keyboard logger or memory scraper could access that CHD even if using a PCI compliance, secured Web site. Anti-virus only addresses this situation, at best, 40% of the time. So those PCs should have something a bit more to ensure that such malware cannot end up on those systems such as critical file monitoring or white/black listing of applications. Then you want to have their event log or syslog data collected for analysis and alerting.

  90. September 27, 2016 at 3:18 AM

    Hi, we are just about there. thx for your help.

    We would like to use a virtual terminal which would be an Air-Gapped machine on a mobile internet connection or VLAN’d off on our network to new outbound iP solely for this use. Would this be compliant?



    • September 29, 2016 at 5:52 PM

      Stop trying to get your organization out of scope because you never, ever will as long as you are considered a merchant by the card brands. The best you can do is to limit yourself to the requirements in SAQ A and it sounds to me like that is impossible for you to accomplish. Get over it and please move on.

      • October 3, 2016 at 5:09 AM


        Not trying to avoid compliance, all our other systems have been changed to comply. We need one PC to access a virtual terminal as we need to process certain payments in this manner. We are thinking of having a dedicated PC with its own internet connection and security to limit access and vulnerabilities. Any help appreciated.


      • October 3, 2016 at 7:06 AM

        If you feel the need to do that, that is up to you and your company. I would just make sure that all your PCs are properly security hardened, have anti-virus, and are always patched current. Most organizations already do this. But if your organization is not one of those that maintains their PCs religiously, then your approach might be the best way to go. The one additional control I would suggest is to install something like Bit9, Tripwire or similar to make sure that no new software can be installed on the PCs used to do data entry.

        The risk is that a memory scraper or keyboard logger gets installed on your PCs that do the data entry or cardholder data (CHD). As long as you do everything you can to minimize that risk, you should be fine.

  91. September 22, 2016 at 8:13 AM

    I don’t really have a PCI DSS question but last assessment the QSA asked why my client’s (I’m not a QSA but a security consulting) vulnerability management program was solely focused on the CDE. I took that as a nudge to expand the program. The CISO agreed but she left this summer for a position elsewhere ( doubled here salary). IT pushed back but I finally convinced interim management (yes the organisation is still searching for a CISO) to expand the program. The security analyst added 250 additional servers, ran the vulnerability scan and found all the servers with high to critical vulnerabilities. 20% have critical vulnerabilities that are 6 months old. These are scope category level 3 systems but … I so want them fixed.


    • September 26, 2016 at 10:14 AM

      If the cardholder data environment (CDE) you describe included all of the “connected to” systems, then your client was following the PCI DSS to the letter of the law. However, where this goes awry is if those “connected to” systems are also on the same network segment or can be accessed by other network segments. This is typically true of Active Directory, DNS, DHCP, NTP and other common services. As a result, if an organization does not have a complete vulnerability management process for everything on their networks, those “connected to” systems can become a conduit to compromising the CDE from systems out of scope.

  92. 249 Suresh Kumar
    September 21, 2016 at 10:12 AM

    My client has a Mainframe card data environment. Backups are in unencrypted tapes but the client contends that Dara in the tapes is in non-readable format (i.e. Only read by Mainframe) and does not physically leave the data Centre. Is this on for PCI compliance? Thx

    • September 29, 2016 at 5:57 PM

      Dara? Not familiar with Dara and what that has to do with magnetic tape and readability of those tapes. Dara might be a potential control, but I would have to know a lot more about it. That said though, most mainframe backup utilities do not lend themselves to being security controls.

      PCI does not care if the cardholder data (CHD) never leaves a data center, it is still in scope for compliance. The fact that it is unencrypted just makes compliance all that much more difficult.

  93. 251 MikeAL
    September 19, 2016 at 6:54 PM

    I read a lot about how scope can be reduced by tokenization, P2PE, or PA-DSS, but I have not been able to find any specifics on the exact PCI DSS requirements that can be avoided by any of these methods.

    • September 19, 2016 at 7:06 PM

      Tokenization scope reduction depends on when the tokenization occurs. Tokenization typically occurs at the completion of the transaction, so as long as your process doesn’t store the PAN before the token is created, then tokenization keeps the PAN from being stored. There are some tokenization solutions that create the token at the swipe/dip of the card, so those can take your network and POS solution out of scope just as P2PE/E2EE can as long as the sensitive authentication data (SAD) is not also transmitted.

      P2PE or E2EE can also take your network and POS solution out of scope by encrypting the SAD at the point of interaction (POI) if the solution is managed by your trasnaction gateway or processor. However, P2PE/E2EE does not automatically mean you get tokenization even though a lot of transaction gateways/processors bundle it with P2PE/E2EE. So your application may still be storing the PAN even though you implement P2PE/E2EE.

      PA-DSS dos not reduce scope so much as it proves that the application was independently validated for securely processing, storing and/or transmitting SAD or CHD. A QSA/ISA still has to confirm that any PA-DSS was implemented according to its Implementation Guide (IG). Once that is proven, then the application can be considered secure and you can avoid the requirements in 6.3 and 6.5.

      • 253 MikeAL
        September 21, 2016 at 2:15 PM

        Lets assume an effective tokenization solution in which there is absolutely no CHD or SAD saved anywhere in a merchant’s network or premises. Are there any scenarios under which such a merchant can go from SAQ D, to either SAQ A or SAQ C?

      • September 26, 2016 at 10:15 AM

        Yes, if they meet the criteria of those SAQs.

  94. 255 Brad
    September 19, 2016 at 4:31 PM

    We are looking to implement an ecommerce site that utilizes integration with Zuora’s CORS REST APIs ( My question is what SAQ classification would this put my company? The number of annual CC transactions would be less than 20,000. Also as best I can tell unlike direct APIs, this process would send CHD directly back to Zuora not through our website.

    • September 19, 2016 at 7:11 PM

      While I can provide you my opinion on this, this is a question you need to ask your acquiring bank as only they can give you the official answer. That said, based on the vendor’s documentation, I would say you have reason to request using SAQ A as long as eCommerce is you only payment method.

  95. 257 CJ
    September 18, 2016 at 10:44 PM

    We are an organization with 3 small sites (geographically separated) with point to point connections between them. We struggle to figure out the following:

    1. The main site hosts cardholder data. The other two do not. However, the workstations from these two sites connect to the main site as they connect to the server that hosts the cardholder data. My first question is if we need to complete the SAQ for each site or just for the main site? At the end of the day we need all 3 sites to be compliant.

    2. We understand that workstations at those 2 sites are in scope, however, we struggle to understand if we just need to properly harden them, or if we need to go through each PCI requirement. The connection between the workstations and the server that hosts the cardholder data is encrypted.

    3. a. We understand that one of the requirements is a proper risk assessment. Since this is our first time going through the PCI, when do we need to conduct the risk assessment? Is it right after we define our scope and have up to date inventory of all devices or at some other point?

    b.Should we complete the SAQ before or after the risk assessment?

    We are using the PCI Scoping toolkit to help us with our segmentation.

    4. We will be using SAQ v3.2. Do we need to justify and document new requirements that are mandated by v3.2 only that we cannot implement at this time, but would definitely implement by 2018?

    Thank you so much for your help.


    • September 30, 2016 at 5:30 AM

      As you have already determined, the answer to your questions lie in your scope.

      To answer your first question, unless the three sites belong to three separate legal entities with different merchant identifiers, you will fill out one SAQ for your entire organization. That said, it might be easier to assess each site separately based on their business processes and then combine the results, but that will depend on your own judgement.

      To your second question, the workstations need to be hardened to prevent being a point of compromise that can then allow the compromise of the cardholder data (CHD) that you store. It’s great that connectivity to the CHD is encrypted, but that does not protect the workstations being used to compromise your server that stores CHD.

      A risk assessment needs to be performed BEFORE you conduct your assessment. The reason is that you need the risk assessment to justify your rationale for the security measures (or lack thereof) you have implemented to protect the CHD you store, why or why not you have network segmentation, justify your server/workstation hardening standards, why you monitor what you monitor, etc. As you conduct your assessment, you will likely adjust your risk assessment as you discover new risks and/or realize that ratings of risks were wrong.

      At this late point in the game, you should use v3.2 of whatever you follow for your assessment. V3.2 goes into effect at the end of October 2016, so unless you think you can finish by then, you’ll need to use v3.2. Any requirements that do not go into effect until some later date are only suggestions. However you need to meet those future dates in order to be judged compliant.

      • 259 Jon
        September 30, 2016 at 5:42 AM

        Hi! I thought OCI 3.1 was gonna be acceptable till the end of September and all assesments completed from October and on should be PCI 3.2. Under October section, It says “at this time all assessments will need to use version 3.2”


      • September 30, 2016 at 5:53 AM

        The official, final version of PCI DSS v3.2 was released as I recall on April 28, 2016 with the retirement of v3.1 announced as 6 months following the release date of v3.2. If I do my math right, that would put v3.1 being retired on October 28, 2016.

  96. 261 Luigi Figueroa
    September 15, 2016 at 4:29 PM

    Hi PCI Guru,
    I have a scenario for you. Company A is asking for PCI Compliance from Company B. The scope is that Company A is just sending orders to Company to ship products for them. No credit card data is being sent or handled to Company B. Is Company B still need to produce an AOC? If so, would a SAQ D for Service Providers suffice even if there is no credit card data is being handled from Company B? Thanks for your help!

    • September 29, 2016 at 5:59 PM

      If Company B never receives or handles cardholder data (CHD) then there is no need for Company B to be or even prove they are PCI compliant.

  97. 263 Sean Giroux
    September 14, 2016 at 9:45 AM

    In regards to Processing Credit Cards over Wifi… Other requirements aside… With the new 802.11ac standard, do our WIPs (Airtight or Aerohive) need to be 802.11ac compatible or can we get by with 802.11n for PCI 3.1 and PCI 3.2 compliance?

    • September 29, 2016 at 6:05 PM

      If you are relying on your wireless intrusion protection (WIP) units to protect your Wi-Fi and that includes 802.11ac, then yes, your WIPs do have to be able to monitor that 802.11ac network. That said, 802.11ac is just faster 802.11a (i.e., it uses the same 5GHz channels as 802.11a), so I would check with your vendor to see if your WIPs already have the capability.

  98. 265 Scott
    September 13, 2016 at 2:03 PM

    I was wondering if anyone is using kerberos for SSO with a 2FA solution into their CDE for PCI DSS compliance. Also what does PCI DSS say about SSO once 2FA has occured through Raduis Server.

    Thanks for any suggestion or comments

    • September 29, 2016 at 6:10 PM

      Kerberos is only an authentication and communications security solution, so it’s marginally better than regular authentication. Add in two factor authentication (2FA) and you have a secure remote access solution as well (or an administrator access solution internally to comply with v3.2). PCI DSS does not specifically or explicitly deal with single sign on (SSO), but the requirements in section 8 would all be applicable to SSO as they would to non-SSO environments.

  99. September 7, 2016 at 2:17 PM

    PCI Guru… We met about 2-3 weeks ago when you came in to consult with us… as I start to move forward I have a couple of questions. 1st, regarding Internal\External Vulnerability Scans, should either be credentialed or not, is it required, Section 6 does not say one way or the other, furthermore how do I scan those systems if they’re separated from the rest of the network? Do I schedule time when those systems are not processing to allow inbound scanning? 2nd Question… regarding AV, if the Internal PCI space should be separate from non-PCI networks, to include the Internet, how do I keep the software updated and current?

    • September 10, 2016 at 6:35 AM

      Credentialed vulnerability scanning is not a requirement. External ASV scans will/should never be credentialed. However, internal vulnerability scanning typically is done credentialed to minimize false positive results. Using credentials allows most scanners to make a better determination on vulnerabilities.

      Logical and physical network segmentation can create issues when trying to vulnerability scan. In some cases you may have to temporarily open up all ports for the scanner to let it through. In other cases you may have to move the scanner to physically connect it to a particular network segment. Some clients have defined special VLANs for their scanners so that they can accomplish scanning. As to scheduling, that is up to your organization to determine. Some organizations do not restrict scanning to a particular time, others have outage concerns and only allow scanning during off or non-prime processing hours.

      Network segmentation is all in the paranoia of the implementer and organization. Some people and organizations can go overboard on segmentation to the detriment of properly managing and monitoring devices. You need to balance risk with properly managing devices. If you configure your network to only allow the AV, SIEM, AD, WSUS and other necessary services and servers to talk within your PCI zone, that is all is required by the PCI DSS. Where a lot of organizations go wrong though is that they do not restrict those services to only those servers that provide those services.

  100. 269 Sandun
    September 7, 2016 at 1:46 AM

    Noted that the Payment Applications listed in have operating systems that the application was tested on. For example, “PaymentX version 3.2” application system is PA-DSS certified and tested on Solaris (Tested platform/ operating system). If the Vendor implement the same “PaymentX version 3.2” application on any other platform/ OS other than ‘Solaris’, will the same application (Same application and same version) be still compliant with PA-DSS?

    Note: Vendor may have other versions of the payment application tested and certified on other platforms/ OS. Example: PaymentX version 3.1 is also PA-DSS certified and tested on AIX (platform/ OS) but not on Solaris.

    In a nutshell, do we need to consider Payment Application version and the platform or other dependencies which the application was tested on at the time of PA-DSS certification and should we implement the application with the same ‘dependencies’. If ‘dependencies are changed at the time of implementation, will the implemented application be NON-complaint with PA-DSS?

    • September 7, 2016 at 6:48 AM

      Yes, the PA-DSS validation (it is NOT a certification) is OS specific and version specific. So if the application has been validated on Solaris v10 and Red Hat v5.5, but not any other UNIX variants, then only the Solaris v10 and Red Hat v5.5 OSes have been validated for that application.

  101. 271 Ray
    September 2, 2016 at 11:21 AM

    We give away free samples on our site. How can we prevent the PCI scan from generating a ton a free sample requests so that we are not allowing them. Our initial idea was to make note of the PCI scan IP address ranges and not let those sample requests go all the way through the pipeline. Not an ideal situation since that address range changes.

    • September 6, 2016 at 6:08 AM

      How would a PCI vulnerability scan generate sample requests? I think what you are arguing is that a PCI application vulnerability scan could generate sample requests. However, I would argue that such a scan would also not generate such a request unless you are telling the application scanner to fill out the sample request form. Even then, it would only generate a request to one address, not thousands.

  102. 273 Dayne
    August 25, 2016 at 2:10 PM

    I have a database for my point of sale system that currently stores encrypted credit card data (Not full PAN, and moving to tokens). We are in the process of putting an internal firewall up to segment of the back end of the POS system through an ACL. If the POS terminals are not in this segment does that mean that my whole network still needs to be PCI compliant. I know the terminals themselves are subjected to PCI compliance but is the back office computer that is on the same network subject to PCI compliance because it is on the same network? Just having a hard time figuring out my scope? Second if I am a level 2 merchant and doing a SAQ D do I still need a qsa to sign off on my network segmentation to reduce my scope?

    • August 30, 2016 at 7:39 AM

      First, the easy question. If you are a Level 2 merchant and you accept MasterCard credit cards, you are required to do either: (1) a self assessment questionnaire (SAQ) conducted by a PCI SSC certified Internal Security Assessor (ISA), OR (2) a Report On Compliance (ROC) conducted by a PCI SSC certified Qualified Security Assessor (QSA). See Note 4 on this Web page at MasterCard’s Web site for more information.

      As to minimizing scope through the use of network segmentation. If the POS comes into contact with full PAN, then it is also part of your scope and needs to be logically or physically segmented from the rest of your network. It is not just the storage of PAN (encrypted or clear text), it is also the act of processing and/or transmitting sensitive authentication data (SAD) or cardholder data (CHD) that is also in scope.

      BTW I’m not sure what you meant by having encrypted card data but not full PAN. I’m assuming you meant that the POS solution encrypts the full PAN but also stores a truncated version (most likely the last four digits).

  103. 275 AL
    August 25, 2016 at 12:23 PM

    Question about SAQC applicability. We have a business using an SaaS solution. This SaaS offers a hosted payment page to process credit card transactions thru. Transactions can be key entered byt he business by pulling up the SaaS solution online. Thre is not any software installed the business computers.

    The SaaS has validated PCIDSS compliance as a Service Provider however there is a Magtek card reader attached to the business computer where face to face transactions are processed thru the SaaS. The SaaS is not validated as a payment application as they do not meet PADSS requirements. SAQC appears to want to confirm a validated payment application is used, but the SaaS is not validated to PADSS only PCIDSS. Could this apply to an SAQC scope?

    • August 30, 2016 at 7:41 AM

      What you need to do is to get from the SaaS vendor, the PA-DSS validation information of the payment page provider.

  104. 277 MS
    August 25, 2016 at 5:52 AM

    Hi PCI Guru ,

    I have a question on nested iframe solution used in mobile app. Company X has a PCI compliant mobile app solutions for its customers , this solution has processor iframe on payment page where customers enter credit card information. They are changing processors . New processor iframe is not compatible on mobile phone , but can work on a web server hosted in a Data Center inside company X. New Proposed solution is , adding another layer of iframe on mobile app payment page , this iframe will point to processor iframe hosted on a file server.
    Is this nested iframe solution supported by SAQ A ?

    • August 25, 2016 at 8:32 AM

      Good question. The only answer I can provide is that I would have to look at the server and see if any SAD/CHD ended up in memory on that server. I am betting there is, but you would have to conduct the necessary analysis to prove it one way or another.

  105. August 23, 2016 at 12:17 PM

    The Quest for SAQ A……
    Ok, I will try to be brief. 1 legal entity. A few hundred MIDs. Most thought to be considered a SAQ A for their use of API’s that land the customer on a 3rd Party Processor page to enter CHD. However, these MIDs also do MOTO and some reconciliation (no CHD on the back-outs, but yes on the MOTO). Those doing MOTO use a Citrix client that uses Citrix as a ‘jump point’ to the payment processor thereby allowing only 1 IP addy for the Processor to allow (Citrix is behind FW) from the company. Does this still qualify as a SAQ A? ……now let me spice this up a bit. The FW that sits in front of Citrix also acts as a VPN concentrator for a number of connections to POS environments, which may be for other MIDs. …..but wait, there’s more. The FW also sits in front of a server cluster that handles student ID card payments (not CC data, but like a personal account tied to an ID card) …

    • August 25, 2016 at 8:27 AM

      In order to use SAQ A, everything MUST be outsourced including MOTO and your other payment channels.

      The student ID process is similar to a private label payment card, so PCI does not apply. That said though, I would secure it and process it as though it were in PCI scope just to be safe.

  106. 281 FDanforth
    August 22, 2016 at 4:29 PM

    Hi PCI Guru,

    thanks as always for your excellent guidance. Here’s my question:

    We just entered into a new contractual relationship. The company is PCI compliant (they provide online fundraising SaaS), and they connect directly with our PCI compliant gateway (BrainTree), so no data is flowing onto my networks.

    However, they are storing every single payment card in BrainTree’s vault, even when there are no recurring charges happening. We don’t need this data, we get charged for the storage, and it interferes with other business processes for true recurring payments.

    From my perspective, this is unnecessary storage. Is there anything directly applicable in the PCI DSS or PA-DSS that explicitly prohibits this unnecessary storage? Or other leverage you might suggest to strengthen our case for why they need to stop this behavior?

    Thanks much,

    • August 25, 2016 at 8:49 AM

      It may be unnecessary to your business model, but this is how the processor (BrainTree) works. As long as you have a compliant AOC from BrainTree for the services they provide you, it’s their problem, not yours.

  107. August 12, 2016 at 9:21 AM

    PCI Soup

    This is a question that has many legs to it…I think.
    The first part deals with the relationship of Merchant ID’s (MIDs) versus the organization at large – that is, let’s say you have an institution of higher learning with a typical extended campus and literally a few hundred MIDs. The SAQ levels vary; let’s say most fit into the SAQ A with some B and maybe a few A-EP and one D variety. Are these MIDs all treated as separate companies? Do they ultimately tie back to the parent organization? If so, what effect does that have on all the other MIDs and their SAQ obligations?
    The second part deals with shared infrastructure. What effect does having a few hundred MIDs that at various points share infrastructure – whether it is web servers, networks, segregated Citrix gateway (used to segment a processor access gateway), etc. – yet, fill out and submit separate SAQ’s?
    Lastly, as you have noted in another post, what effect does a 3rd party (bookstore, cafe etc.) using the same – typically open, infrastructure have on all this?

    As I said. PCI Soup.


    • August 13, 2016 at 3:19 PM

      Organizations with multiple merchant identifiers (MID) but only one legal entity such as with higher education should be aggregating all of those MIDs together to determine their merchant level. However, it is up to your processor(s)/bank(s) to provide you guidance in this area just as they would provide you for which self-assessment questionnaires (SAQ) your organization should be using.

      The problem long ago was that MIDs that were with different processors/banks would not get aggregated. Some of the more unscrupulous merchants played a game to avoid doing a Report On Compliance (ROC) by having lots of MIDs with different processors/banks. However, most processors/banks got wise about this scam and now share transaction counts with one another for organizations so that it is tougher to get away with staying at an SAQ when the organization should be doing a ROC.

      The number of MIDs involved has nothing to do with the assessment of infrastructure other than from a scoping perspective.

      Finally, third parties using another organization’s infrastructure can put that infrastructure in scope depending on whether or not the third parties’ transactions are encrypted and the infrastructure can be shown that it cannot decrypt the data streams.

      • August 15, 2016 at 8:06 AM

        So – if I read you correctly, determining your SAQ level (apart from Merchant Level) should be driven by the legal entity versus the individual MID. (Understanding that acquiring banks can advise as they will.) Therefore, if you have 300 MIDs under 1 legal entity, you should have 1 SAQ…..correct?

      • August 16, 2016 at 7:14 AM

        You are correct.

        That said, for assessment purposes, it may be easier to do multiple assessments even though you are one legal entity. Whatever the plan, an organization needs to consult with their acquiring bank(s) and/or processor(s) to get approval for whatever approach they chose to take.

  108. 287 Bryan Carter
    August 8, 2016 at 2:51 PM

    We had a retail customer request that we not print their signature on the credit card transaction receipt. I have dealt a lot with all of the other CHD, but I have seen little discussion about the storage of signatures electronically or physically. Obviously if it is printed on a receipt and given to a customer it is their discretion as to what to do with it. I suspect the real concern is that we are storing it electronically as an image. I have advised that we eliminate that piece of data from the system because I feel it will simply cause more headaches, and provide minimal value. I would like your thoughts on best practice surrounding the signatures. Thanks!

    • August 13, 2016 at 3:45 PM

      While not part of PCI, as a security professional, I have a LOT of reservations about merchants that print my signature on receipts. I think it is a very bad practice from a personally identifiable identification (PII) perspective even if given back to the customer. There is just too much risk there that the receipt is thrown out or recycled and not securely shredded by the customer.

      That said, most states and countries with privacy laws consider signatures as PII, so you should be encrypting it and protecting it. I have a few clients that store the signature for transaction validation purposes for a period of 90 to 120 days when they securely erase it. In those cases, all of them have encrypted it because it is PII.

  109. August 8, 2016 at 9:35 AM


    We receive paper forms with cardholder data for supporters to make donations. Can we:
    – use a virtual terminal on the gateway providers web portal from one of our PC’s to enter CC data?
    – use an ipad (for example) with a 3g/4g connection – ideally banned from the wifi network as an alternate method?

    Would either of these methods comply with PCI? the paper forms are stored securely and then destroyed appropriately.



    • August 13, 2016 at 3:55 PM

      Never, ever, ever use tablets or smartphones (Windows, iOS, Android, etc.) for manual data entry of sensitive authentication data (SAD) or cardholder data (CHD). The data manually entered will be stored by those devices from one month to six months or more depending on the device’s amount of memory and how much it is used. This is why the Council said years ago that such devices would never be PTS certified.

      I am assuming by your question that you are trying to get your organization out of scope. Forget it. The mere fact that you deal with SAD/CHD puts you in some amount of scope. So get rid of that idea right now.

      The minimum amount of scope is to use either a virtual terminal or a PC. However, whatever solution you use, that device is still in scope because the keyboard is being used and the SAD/CHD flows through the keyboard and device to the VDI or directly to the gateway. So it could be memory scraped or keyboard logged off of the input device. Not that you need to go overboard segmenting those devices away, the HTTPS does that. But you do need to manage the risk of the memory scraping or keyboard logging which can be accomplished with anti-virus and application whitelisting/blacklisting, file integrity monitoring or similar approaches.

      • 291 Scott Buchanan
        August 26, 2016 at 3:21 PM

        “The data manually entered will be stored by those devices from one month to six months or more depending on the device’s amount of memory and how much it is used.”

        While the compliance part of your answer is beyond my scope of expertise, this statement here is nonsense. Unless the payment application has functionality specifically written to store payment information on the device, the data is no more likely to be stored on a mobile device than on a PC.

      • August 30, 2016 at 7:29 AM

        Unfortunately, not true. Thanks to the way the operating systems for mobile devices are written, they store all manually entered data they come into contact whether that is the songs you play, what you searched for on the Internet and every manually entered credit card number. This is how iOS, Android, Windows and other mobile operating systems “learn” your likes and dislikes.

      • 293 Scott Buchanan
        August 30, 2016 at 8:04 AM

        I challenge you to provide a a citation for that claim (i.e., that mobile operating systems store “all manually entered data they come into contact” with). As a software engineer who works on mobile platforms, I can say with absolute certainty it’s not true. Some data may be stored, if the device is configured to allow it and if the application is built to allow it, but to say all (or even most) data is stored is vastly overstated.

        Just consider the ramifications if it were: mobile devices wouldn’t be allowed in any regulated environment, from health care (due to HIPAA) to corporations (due to internal data retention policies). Yet standard COTS mobile devices are used in all of these. Furthermore, if what you’re saying is true, then you have to be suggesting that every single e-commerce vendor with a mobile storefront/apps is flagrantly violating PCI rules: from Amazon to eBay to Walmart to Apple to Google, given that a customer manually enters their credit card information on all of these. That’s simply not believable.

      • September 6, 2016 at 9:27 AM

        Here are the two I’ve most seen referenced.

        But any forensic examiner worth their salt will tell you the same information, CarrierIQ or not. Smartphones and tablets are the most wonderful devices on the face of the Earth from the information the surreptitiously record all in the name of “improving the user experience”. Even Windows 10 has gotten into the act and is why a lot of companies demanded Microsoft remove that capability from the Enterprise version which they did. However, other Windows 10 version still record as does Windows 8 which is why a lot of corporations avoided it like the plague.

      • September 16, 2016 at 10:31 AM

        quick question on this. I have a client’s environment where MOTO transactions (CHD) are entered into a payment processor portal. For the purpose of locking down to a single IP, a Citrix ‘gateway’ is used. So – workstation with Citrix client. Citrix farm is behind FW on 1918 net that act as proxy out to payment processor portal. Oh, and the workstation has a real world IP addy with direct internet access. 2 questions. A. Is the workstation with the Citrix Client in scope? B. Is the Citrix farm required to be scanned/pen tested?


      • September 19, 2016 at 7:17 PM

        Yes, the workstation with the Citrix client is in-scope because its keyboard and memory still process/transmit the PAN. The risk is that a keyboard logger or memory scraper compromise those systems. As long as you minimize that risk, they should be able to coexist with other workstations on the same network segment. Solutions to minimize that risk are application white/black listing, critical file monitoring, etc. Since these systems have direct Internet access, you probably also want to control what these users can access on the Internet through a proxy or similar solution. However, you will also need to support your decisions on a risk assessment of your environment and those workstations. You will also what to periodically vulnerability scan and penetration test a sample of workstations (assuming they are all the same) just to ensure that they do not become more risky.

        Yes, your Citrix is in-scope as well and needs to be vulnerability scanned and penetration tested.

      • 297 Mike
        January 17, 2017 at 5:06 PM

        To emphasize what Scott Buchanan says, this is indeed not true. The two links provided by PCIGuru to support this claim are not exactly accurate. They refer to a specific software vulnerabilities discovered (still valid?) that have nothing to do with the overall mobile device OS architecture. Of course there are mistakes, bugs, vulnerabilities and so on but mobile device OS as with any software but the OS still designed with security in mind. If the OS are secure enough it is a matter of opinion, today they are trusted by all kind of security sensitive tasks so it is definitely not the common industry perception. Take the link referring to the database used for auto completion. This would be a problem using a naive implementation on an app by prompting the user to enter data with the default keyboard rather than a more secure keyboard implementation. Sure, the device OS could provide more security features out of the box but that doesn’t mean that mobile apps developed from security companies have the same design flaws.
        You can protect sensitive better with a mobile device than from a card in your wallet from an individual user’s perspective. Simply adding fingerprint verification makes stealing your phone compared to stealing your wallet that step harder. That been said, for a financial institution it is different, they care about risks involving mass theft of sensitive data due to some malware. The key point? Users will use mobile devices since it can secure their data and they typically don’t care if it adds risks in a more global level. Some companies, thus, will offer mobile solutions. Other companies will have to compete as apart from loss of fraud there is simpler risks of loss of business.

  110. 298 Ben
    August 5, 2016 at 6:14 PM

    If you are a merchant that has entirely outsourced your payment processing, but several employees have company credit cards, and the finance department stores the PANs for those cards in their financial software, does that make you subject to SAQ D since you are technically storing cardholder data?

    • August 13, 2016 at 4:03 PM

      No. Corporate credit cards are not part of a merchant’s PCI scope.

      That said, you should have an agreement between your employees and your organization that indicates that they are allowing you to store that information and use it only for approved purchases and that you, as their employer, agree to protect that information.

  111. 300 Tonny
    August 4, 2016 at 7:01 AM

    I have a question about 8.3.1 of PCI 3.2. Our company provides web applications for our client. The client could use the application to process Credit transaction for their user, and manage their user. My question is if the client’s administrator of the application must have used two-factor authentication (2FA) to obtain that application.

    • August 5, 2016 at 7:21 AM

      Yes, everyone needs to have two factor authentication if they are remotely accessing the application.

      • 302 Tonny
        August 5, 2016 at 9:16 AM

        Actually the administrator login to the application by web, juts like a normal user. Any difference?

      • August 5, 2016 at 3:52 PM

        Anyone with administrator privileges should have been using two factor for remote access from the get go. Its the normal business user that interacts with the application on behalf of their employer who has contracted with the service provider that is now being added. The idea is to minimize the risk presented should those users be phished and compromised.

  112. 304 Ryan S McLeod
    August 2, 2016 at 1:19 PM

    I’m curious what your take is on Credit Card Convince Checks. We image our checks and then send them to the bank. Would we have to report that we have check images with credit numbers on them? We don’t store anything with our merchant accounts and they are completely separate from this process.

    • August 3, 2016 at 3:41 PM

      The short answer is yes, those checks are in scope for PCI compliance because a primary account number (PAN) is a PAN as far as the card brands are concerned. It also sounds like you are a service provider running a lock box operation, so it’s an SAQ D although most of it will be marked Not Applicable (NA).

      You will not only need to securely store the physical paper, but also securely destroy them as well. Given they are checks, I would already assume you are doing that. However, the check images will also have to be encrypted wherever you are electronically storing those. You will also have to limit access to those checks and log whenever someone accesses those checks.

      • 306 Ryan
        August 4, 2016 at 1:35 PM

        Thanks you for your response on this. We are not a service provider providing a lock box. We are a merchant that accepts checks as a method of payment for goods and services. If we accept these checks that have credit card numbers on them we are in scope for PCI? If we didn’t have a merchant account how could this possibly be enforced?

      • August 5, 2016 at 7:16 AM

        If you do not accept payment cards for payment, why would someone write you a check and put their payment card primary account number (PAN) on it? Or have you instructed your sales people to get a PAN on any checks like some merchants do? Regardless, if a check has a PAN on it, it is now in scope for PCI and must be protected as such. Your organization may not have a merchant agreement, but if your organization becomes the source of a breach, it will still be held legally liable for the loss of that information.

  113. 308 Tim
    July 25, 2016 at 9:16 AM

    Thanks for your time answering these questions! I’ve now found that my PDQ device is covered by P2PE-HW and I don’t need to complete a SAQ B-IP. Could have saved myself quite a bit of time and money! On the flip side, I’ve a well documented system and controls in place.

  114. 309 Jon
    July 21, 2016 at 5:18 AM

    Hey there! I was wondering. In terms of VPN certificates, would you consider Internal CAs as valid for PCI Compliance or do you always ask for external CA? Thanks as usual for your really useful and experienced advice!

    • July 21, 2016 at 5:31 AM

      If you truly operate your own internal certificate of authority (CA), then that is acceptable. What is not acceptable is a self-signed certificate that generates an error because it was not issued by a CA. That creates a bad habit of people skipping by the error and potentially ending up somewhere they should not be and then compromising your operation.

      • 311 Jon
        July 21, 2016 at 5:37 AM

        Yes, indeed. And also, self signed certificate will show up in Vuln Scans which will also make req11 to be failed.
        Thanks a lot again for your thoughts sir! Let me tell you this resource you have here is amazing. I also use your Misc page as a continuos trainning since I receive all the updates from here and I try to answer them based on my knowledge and then validate it against your response. So this is kinda a conitnuos PCI course for me and I bet for lot of people who follows your blog.

        Have a nice day and thnaks again!

  115. 312 Bill
    July 20, 2016 at 7:51 AM

    Your advice is great! Very helpful! Another question around segmentation. I’m struggling with the idea of segmenting workstations that would be used to go out to a payment gateway’s website, and enter in payment information received say by regular postal mail or even over the phone. My initial thought is that these workstations are in scope, but do they need to be in a segmented CDE. The issue is that then this would mean that all other servers and applications within my environment that these users need to access that have nothing to do with taking payments or CHD would also be in scope. Is that correct? I understand that the risk are primarily around malware and keyloggers so antivirus is important, but does this really put all those other system in scope if all they are doing is entering information into a website?

    Thanks again for your advise!

    • July 26, 2016 at 8:01 AM

      A lot of my clients doing mail order/telephone order (MOTO) are moving to using secure card terminals such as those from MagTek, IDTech, Verifone and Ingenico. These are paired with some sort of P2PE/E2EE solution and therefore take everything else out of scope except the terminal. Returned to your systems is a token. Best way to reduce your scope to the absolute minimum. Talk to your transaction gateway or processor about what they can make work.

  116. July 20, 2016 at 4:59 AM


    Can you advise – are CAF cards within the remit of pci compliance? they are not credit cards, just cards people can use to donate to charities. They don’t have an end date and have the same number format as credit cards – 16 digits.



    • July 26, 2016 at 8:05 AM

      If a payment card does not carry the logo of a card brand (such as Visa, MasterCard, American Express, Discover or JCB), then it is a private label card and is not covered by PCI. However, that said, you would be foolish to not treat them any different because they do have a cash value to the customer and should therefore be treated with the same respect and security as a branded card.

  117. 316 Masa
    July 19, 2016 at 8:02 PM

    Hi PCI Guru

    We are outsourcing company planning to start a call center operation business. Agents will be handling credit card info of customer over the phone but CD will not be stored into our system.

    Since the project is starting out small, we are planning to have our call center agents placed in our current office where other employees (accountant, hr, etc) not associated with the call center operations.

    Can call center agents and these non associated employees share a room but still be PCI compliant?

    Thank you for your advice in advance!

    • July 26, 2016 at 8:11 AM

      Yes, the call center agents and others can share the same room. However I would highly recommend that everyone in the organization be trained to understand that the call center comes into contact with sensitive information that, if overheard, must be kept confidential and not communicated to anyone, internal or external to the organization.

      You also will need to segment your call center systems from the rest of your organization. I am assuming the agents will use HTTPS Web sites for data entry, so implementing a local firewall on their workstations will be sufficient to segment them, but your domain controllers and other shared systems will come into scope for PCI albeit somewhat reduced depending on the risks they present to the workstations. I would also recommend that any transactions your call center processes be done under your customers’ merchant identifiers and not your own. That way you will avoid being both a merchant and a service provider for your call center operation.

  118. 318 Masa
    July 19, 2016 at 7:49 PM

    Hi PCI Gru

    We are outsourcing company and theres a plan to start a call center business that will take a credit card payment over the phone.
    Since we are starting small with this project, we are planning our call center agents to be placed in our current office with other employees not associated with this call center project at all.
    I wasn’t sure if it is ok for our credit card processing agents to share a room with other (accountant, hr, etc) employee not associated with call center operations to be PCI compliant.

    • July 19, 2016 at 8:03 PM

      As long as all personnel in the room understand that they could overhear or see sensitive authentication data (SAD) and/or cardholder data (CHD), they understand the sensitivity of that data and that it must remain protected/secret, there is no reason they cannot be in the same room.

      • 320 Masa
        July 20, 2016 at 12:57 PM

        Thank you for the answer. I have one more question. Since we will be classified as a service provider, is annual onsite review by QSA required? According to this website ( ) it seems so.

      • July 20, 2016 at 4:41 PM

        That depends on whose merchant identifier is used for the transactions. If the merchant IDs are your customers, then I would argue you are only providing people and equipment to take calls and the transaction counts are on your customers. If they are your merchant IDs, then that will depend on when you exceed 300K annual transactions. The other consideration though is if you want your company listed on the Visa or MasterCard service provider registries. If you do, then you will have to get a QSA and conduct an assessment that creates a Report On Compliance (ROC). Otherwise if your annual transaction count is less than 300K, then you can do a service provider SAQ D.

  119. July 19, 2016 at 8:08 AM


    Thanks for your advice up till now. I have another question. We are in the process of implementing a PCI compliant phone solution whereby the supporter would enter their CC details using their own telephone keypad for that section of the phone call – these would appear as asterisks on the agents screen. We have a large proportion of older supporters who are not comfortable using this process and would prefer the agent to enter the CC details for them. So the supporter would read the details out and the agent would enter them using their phone keypad. We have tested this out and the process works fine from our perspective. The agents are not writing any details down, the conversations are not recorded. I was wondering if the process we are proposing would be pci compliant?

    • July 19, 2016 at 8:23 AM

      There are a lot of other factors here than just telephony. Are we talking traditional PBX or VoIP (if VoIP, this opens a whole host of other questions/issues)? Is the IVR system in-house or outsourced? How is the IVR connected to the application? How does the card data get transmitted from the IVR or application to the processor? What, if anything, is returned from the processor? That is just the start.

      • July 20, 2016 at 5:04 AM


        the IVR system is outsourced – we open a web browser that links us to PCIPAL. We simply dial a number that securely connects us and the supporter. The supporter would then enter their CC details and we would hear the dtmf tones. the return is either success or fail and is displayed on the screen.



      • July 26, 2016 at 8:03 AM

        The fact that your operators can hear the DTMF is problematic because of the potential to record them for later playback and thus get the SAD/CHD. Most IVR systems I deal with do not let the operator hear those tones. I am betting that your outsourcer can shut those off and I would recommend that they take that action.

  120. July 19, 2016 at 5:44 AM

    Fedex recently lost a package of 300 paper credit card slips, pre-authorisation, including CVV, being shipped from our sales office to our processing office… We have no evidence that any card fraud has happened, and we have already contacted the individuals and offered support. What is my obligation to notify card brands or PSP’s ?

    • July 19, 2016 at 8:13 AM

      Under your merchant agreements with the card brands, you should have notified the brands immediately upon the loss. Notifying the payment service providers (PSP) would have done nothing and they should direct you to the brands. The brands control the compromised card processes.

  121. 328 Fouad
    July 9, 2016 at 12:24 PM

    Hi PCI Guru,

    We are a small company moving towards a medium size company, i have been given the responsibility a couple of years ago to bring our firm into compliance with PCI DSS.

    So far we have been audited by external potential clients who wish to do business with us, the audits were to provide assurance to them and their customers that their data will be secure on our end, the other day i asked myself if we (As in the company i work for) should start auditing the potential clients in return.

    So my question is; if we are PCI compliant, would we (for any reason relating to PCI or other compliance frameworks) need to audit any potential companies who wish to do business with us ? maybe if we experience a security breach as a result of the new company we can hold them accountable ? or is there no need for this ?

    Thanks in advance,
    An avid follower and subscriber!

    • July 13, 2016 at 5:36 AM

      From a PCI perspective, only third party service providers that; (1) process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD) , or (2) have access to systems that process, store or transmit SAD/CHD need to be assessed for PCI compliance. Assuming an organization processes, stores or transmits SAD/CHD, examples of each would be for (1) transaction gateways/processors and for (2) managed security services providers (MSSP) and log aggregation and analysis service providers. If a third party does not have access to SAD/CHD or does not process, store or transmit SAD/CHD, then they do not have to be assessed for PCI compliance.

      For any third party service provider that needs to be assessed for PCI compliance, they have two choices. The first and most common is that the service provider conducts their own PCI assessment of all services in-scope and provides the resulting Service Provider Attestation Of Compliance to their customers. The second and most intrusive is what you have been doing which is to have each customers’ QSA/ISA come through your organization and conduct their own assessment of the in-scope services your organization provides to their organization.

  122. 330 Luigi Figueroa
    June 29, 2016 at 3:29 PM

    Hi PCI Guru,
    Is there some kind of dialogue that can be used to tell customers that we are not going to store their credit card information? Before, we would store customers credit card info for the sake of convenience, but now that we are trying to narrow our scope, we don’t want to store any kind of credit card data. What is the best way to put it gently for customers?


    • July 2, 2016 at 7:45 AM

      How about “We do not store your payment card information”?

  123. 332 Greg Crowe
    June 29, 2016 at 7:20 AM

    Wondering if you could provide your 2 cents on shared anti-DDoS platforms. a lot of companies offer them and are very apprehensive about giving information on how they work. Companies like CloudFlare say they are a level 1 service provider for their products but i don’t understand how they can provide a compliant solution. My understanding is that it works by decrypting traffic that passes through it to analyse its validity and then re-encrypting it, forwarding it on to its final destination. If this shared platform is decrypting CHD for not one but multiple unique clients it surely cant meet compliance as the potential disaster is huge (in terms of a breach) and risk unacceptable?
    would really appreciate getting your thoughts on this.

    • July 2, 2016 at 7:53 AM

      This is where everyone’s differing levels of paranoia and risk acceptance come into play.

      You are right. The DDoS solution in question essentially proxies TLS connections by acting as an endpoint and a starting point. As a result, there is a risk that the DDoS solution is compromised and that the attacker gains access to the datastreams and collects cardholder data (CHD). That said, these solutions are not necessarily exclusively processing CHD datastreams. So the attacker would have to collect a LOT of packets and then sift through those terabytes to find the ones that contain CHD. Not that this sort of attack is not impossible, but what is the likelihood? In my experience, I would say that likelihood is fairly low. However, if successful, the rewards could be well worth the effort.

      And that is where every organization has to make a decision as to if they are willing to take that risk.

  124. 334 Kevin
    June 28, 2016 at 8:09 AM

    We have a call center that contains shred bins that are serviced by a third-party. In the call center, agents take orders by phone and enter cardholder data into a secure web page. There is also physical cardholder data for mail orders there. Because of that, I consider our call center to be a sensitive area for PCI purposes, and I require that our representative from the third party shredding company be escorted when he services the shred bins located in the call center (per PCI DSS 9.4.1). He thinks that because his company is fully certified that he should be able to have direct access to our call center with his vendor badge, but I have it currently set up that he has to knock to be let in. Do you I have it right?

    • June 28, 2016 at 10:42 AM

      I have clients that allow the third party vendor unescorted access and I have customers that escort them. Whatever you are comfortable with is up to you but escorting the vendor is not required by the PCI DSS.

    • 336 Sebastian Nielsen
      July 25, 2016 at 8:37 PM

      If you still want to go for the escort route, which in fact is a secure and good thing to do:

      I see a risk here: Theres a risk a unauthorized person could enter the facility by escort by pretending to be the vendor, and possible have a counterfeit badge. I would suggest you instead configure your access control system to generate a “secure knock” when the vendor scans his badge. Depending on which access control system is done, it can be done in multiple ways. If your door controller is supporting multiple door output, you can connect a “ding-dong” with a distict sound ouput, to the second door relay of the door controller. Then you add the vendor badge to only have access to the “second door” in the access control software.
      Another way if your access controller isn’t supporting multiple door outputs, if you don’t use the “duress function” of the access control system, is that you put his badge on “duress list”, configure the badge to not have access at all, and then wire the duress relay to a “ding-dong” with a distinct sound.
      Some access control system can pull a custom relay if a specific card is scanned, then you can use that function.

      The result is when your third-party vendor scans his badge, it will generate a distinct sound so you immediately know that its the vendor while the door still wont open. This increases security as you can ignore knocks from people if they don’t have a pre-booked appointment, while you still can let in the vendor at any time.

      This gives double security as the vendor is both physically and electronically verified as genuine.

  125. 337 Leland
    June 23, 2016 at 10:46 AM


    We are looking at section 8 in PCI 3.0, we are wondering how to address sections such as lockout duration, change password every 90 days, and submit a new password each time up to the last 4. Are these required on the servers our web app runs on and also the web application users sign into? For example I don’t remember having to change my password on Amazon every 90 days? Our web application accepts payment but only stores PII, it merely transmits the data to a vendor for processing and we store a token.

    Thanks for your help!

    • June 24, 2016 at 8:43 AM

      Not for customers. These are required for anyone that manages that environment such as administrators and internal/external personnel that manage content/sales on the Web site.

  126. June 23, 2016 at 4:56 AM


    Thanks for all the advice up till now – its been really useful in guiding us.

    I have another question… We are receiving calls from a Security Metrics that would like to scan our networks quarterly. But, our web donations are dealt with via Braintree . Our phone donations are in the process of being outsourced with PCIPAL and Cybersource who are both compliant. Both these mean we can self certify the SAQ. I cannot see any reason why we would need to sign another contract for scanning our networks – surely we could simply refer Security Metrics to our providers?



    • June 23, 2016 at 5:02 AM

      As long as your Web site uses a redirect or iFrame to get to Braintree, then it does not need quarterly scanning. However, I believe some Braintree solutions put code on the merchant’s Web server which is why Security Metrics called because Braintree told them to call because you have a solution that requires scanning. You should contact Braintree to determine if your solution needs scanning.

  127. 341 Erik
    June 22, 2016 at 1:35 AM

    In the RoC Reporting Template for PCI DSS 3.2. There is a new section (1.5) where you state the overall compliance for each of the main requirements using checkboxes. You can check Compliant, Non Compliant or Not Applicable.

    Now, what do you do if a requirement is Not Tested?

    • June 22, 2016 at 10:29 AM

      Good question for the Council as I have no idea.

      • 343 Erik
        June 23, 2016 at 5:06 AM

        Yeah, we will put the question to the Council.

        It looks like the section was rushed because unlike all other sections of the RoC, there is no guidance whatsoever. I think it’s a bug. The rightmost column should probably be Not Tested rather than Not Applicable.

      • June 23, 2016 at 5:08 AM

        Or it needs another column added.

      • 345 Jon
        June 23, 2016 at 5:31 AM

        Point for QSA.
        QSA 15 – AQM 0
        QSA Serve =)

  128. 346 CJ
    June 17, 2016 at 8:07 AM

    Our organization is in process of determining if our PCI DSS scope is correct. We have done lots of research and read the Open PCI DSS Scoping Toolkit document. However, we still struggle to fully understand it.

    We have the CDE servers segregated on its own VLAN behind the internal firewalls. Only the CDE environment is behind these firewalls. We understand that all 12 requirements apply to this segment (1a devices).

    Q1. We have devices outside our PCI segment that provide services to PCI segment. This includes Active Directory, SIEM, and Anti-Virus. To us it seems these devices belong to “2a” category and are in scope. The toolkit states that all applicable PCI controls are required for Category 1 and 2a systems. Does that mean that we have to move all these devices behind the firewall into the CDE environment? Or can we leave it as is, and protect these servers with all applicable PCI controls (also introduce the hardening standards) and then document all required ports that are required to be opened on the firewall in order for these servers to provide required services to our CDE environment?

    Q2. One of our larger departments functions in a call center fashion. They take card data via phone and then enter it to software that is installed on their PC. This software connects to the server in CDE environment. Nothing is stored locally on the PC. Everything is submitted and stored on this one server in CDE environment. The connection between the PC and the server is encrypted. Additionally, after the data has been entered, if the center representative went back in to check the card number, they would be able to see only the last 4 digits for verification purposes. Our question is about these PCs (we understand they are in scope), but do we need to move them inside the CDE environment where the server is located or leave them where they are at, and apply all applicable PCI controls and host based hardening controls (FIM, SIEM, anti-virus, patching, access controls, monitoring, etc). There is only 1 port required for the PC (software on the PC) to communicate with the server within the CDE segment. That is the only port we allow through the firewall and we have it documented.

    Thank you so for your help.

    • June 17, 2016 at 7:05 PM

      A1: You should get a copy of the Open PCI Scoping Toolkit ( and focus on “Connected To” systems, aka Category 2 systems. But the bottom line is that any systems that connect to systems in your cardholder data environment (CDE) are in-scope for PCI compliance. The question is how much in scope. Domain Controllers are typically much more of a threat/risk than a workstation that connects through HTTPS and a Web application.

      A2: The risk of your workstations is that they get a keyboard logger or a memory scraper installed. While they do not need to be inside the CDE, they do need to be appropriately security hardened and need something to address the aforementioned risks with a white listing solution, critical file monitoring or similar solution that minimizes those risks.

      • 348 CJ
        June 19, 2016 at 9:48 PM

        Thank you so much PCIGuru. Greatly appreciated. Just one follow up question…how about the other systems (out of scope systemss) that share the same domain controller and SIEM as systems in CDE?…(devices out of scope do not have direct access to CDE)

      • June 20, 2016 at 12:28 PM

        Other systems that might share those Category 2 systems should still be out of scope. However, that is all up to your willingness to accept the risk of those systems sharing those services. The bottom line in my opinion is, if your basic level of security is good enough at managing risk, then out of scope systems sharing services with AD, DNS, SIEM, etc. should be minimal risk. The key is that it is not easy for someone to compromise an out of scope system and then leverage that system to gain access to in scope systems.

      • 350 Erik
        June 22, 2016 at 8:27 AM

        If your Active Directory is outside the CDE and controls access to and inside the CDE, then your segmentation is probably incomplete. The segmentation should be strong enough that if your non-CDE systems are hacked, the security of the CDE should not be affected.

        Access controls and access management for the CDE should be completely separated from access controls and access management for your non-CDE systems.

      • June 22, 2016 at 10:36 AM

        This is where paranoia and security get messy. What is the point of implementing separate AD systems? Manually trying to keep them in synch is going to create more problems than it solves. Bizarre one way trusts also create more problems than they solve. At some point you need to be will to accept the risks of having a single directory solution. If not, then you need to accept the mess of having separate directories and that mess.

      • 352 Erik
        June 23, 2016 at 5:27 AM

        If hacking the non-CDE systems (and AD) can give you access to the CDE, then the segmentation is probably not sufficient. AFAIK, that’s what happened in some of the high-profile breaches in recent years.

        Many of my PCI customers keep a separate access control system for their CDE. Typically, only a very small group of people need access to it. This makes it easier for the customer to manage and makes the PCI DSS assessment much easier.

        Using the same access control system for CDE and non-CDE networks would be possible, but it would probably be much more difficult and expensive to build and maintain, and it would be significantly more work to verify the segmentation controls during the assessment.

      • June 24, 2016 at 8:50 AM

        Which is why in v3.2 the Council added two-factor authentication for anyone directly accessing the CDE. At the end of the day, it all comes down to how much risk is your organization willing to accept. There are risks with a common directory system and there are risks with separate directory systems. That said, properly implemented and managed, a common directory system can be secure and still provide a common directory platform.

      • 354 Brian
        July 21, 2016 at 4:12 PM

        Regarding Q2/A2: According to the scoping toolkit, the PC is a Category 1a system (a.k.a. CDE), because they process cardholder data (effectively SAQ C type environment). Any systems directly connected to them are Category 1b, and also part of the CDE. So they all need the requirements applied (hardening, logging, scans, fim, etc…).

      • July 26, 2016 at 7:54 AM

        Depends on the segmentation that is in place. Some of those connected systems may be of the 2a or 2b variety if segmentation is in place.

    • 356 CJ
      June 27, 2016 at 9:32 PM

      Thank you PCI Guru. This helps me a lot. Greatly appreciated!

  129. June 15, 2016 at 10:04 AM

    Our customers have been getting notices from their processors about the QIR requirement from Visa that is effective on Jan 31st, 2017. So I have 2 questions on that. First, we are not integrators or resellers as we are the software vendor so if our staff does install on -site do they need to be QIR certified? Second, QIR is for individuals installing PA-DSS validated payment applications, and our newest version is a P2Pe certified application. With the applicaiton out of scope, QIR certification does not make sense.


    • June 15, 2016 at 3:10 PM

      I am with you. The page on the Council’s Web site clearly states that the Qualified Integrators and Resellers (QIR) certification is for implementation of PA-DSS validated applications by third parties, not the implementation of P2PE solutions.

  130. 359 Mitch Bucannon
    June 8, 2016 at 2:14 PM

    I have a manage a small medical clinic and we using navicure and PayLeap usb card swippers. Our network is provided by a larger medical organization and is shared across different locations. They also provide Including our PCs. They said the PCs connected to the readers will only be used for swiping. Does my network provider need to be involved or informed? Is this a C-VT SAQ type, or something else?

    • June 8, 2016 at 3:50 PM

      If the PayLeap terminals are connected to PCs over USB, then the cardholder data (CHD) and/or sensitive authorization data (SAD) is likely flowing through the PC to an application or network. So you need to know more about those terminals and how the data moves from them to your transaction processor.

      That said, you are definitely not an SAQ C-VT because you have card terminals or point of interaction (POI). YOu need to more about how your applications work with the terminals to know what SAQ to use.

  131. 361 Brady
    June 2, 2016 at 6:03 PM

    PCI Guru: I floated this idea by Mozilla –

    I have no idea what will come of it but it seemed like a way to reduce the influence a merchant site has over where the customer’s browser renders a payment provider iFrame from.

  132. 362 Gretchen
    June 2, 2016 at 11:21 AM

    I am a one-man shop and only process cards through a virtual terminal. I am not an IT person and have no idea what they are talking about with half of this stuff. What, for instance, is a demilitarized zone? If I only run cards when hooked up through an LAN and am not using wifi, and I’m not storing any cardholder information anywhere on the system, do I need to worry about all of these IT configurations? Because, if I do, offering credit card payments to my clients is quickly going to be not worth the time and expense because I’m going to have to hire an IT person to figure all this out.

    • June 2, 2016 at 11:41 AM

      You should be entering cardholder data (CHD) through a browser over HTTPS. The HTTPS session using TLS v1.2+ is what segments your workstations from the rest of your network devices and computers. Then it all comes down to keeping your workstations current on patches and have anti-virus on them.

      Your other option is to go to physical card terminals such as those from Verifone or Ingenico over dialup or your network. Your acquiring bank can set you up with terminals that will encrypt the CHD when it is entered into the terminal. Again, putting the rest of your network out of scope as well as taking all of your workstations out of scope as well.

      • 364 Bill
        July 12, 2016 at 10:45 AM

        Hoping you can help clarify, so a computing is being used to access a website over HTTPS TLS1.2 to enter CHD, the computer itself is in scope, but the computer does not need to be firewalled off from other computers or devices on the network? The TLS connection providing the segmentation isn’t clear to me.


      • July 13, 2016 at 5:26 AM

        The TLS connection segments the computer from the network when the cardholder data (CHD) is transmitted. However, TLS does not segment that computer from the rest of the other computers on that network segment. That is where the firewall comes into play. That firewall can be software-based on the PC or a hardware firewall on the network.

      • 366 Bill
        July 22, 2016 at 1:00 PM

        So, if the only CHD a workstation handles is what’s being entered into a secure website accessed over TLS, does it need to be segmented via a firewall to keep all other workstations on that same network out of scope? If yes, I assume then that no matter what, any other system (Domain controller, print server, etc) that the workstation needs to be able to talk to would also be in scope?


      • July 26, 2016 at 7:53 AM

        You can use the Windows Firewall as the firewall for the workstation. That and the TLS session will protect the CHD. Any supporting systems such as domain controller, AV central system, printers, etc. would all be in scope, but would only be assessed for PCI requirements that made sense based on the risks they present to the workstations. For example, domain controllers present a huge risk and would be assessed for all relevant requirements, but a printer might be considered a very low risk and could be assessed with just vulnerability scans.

  133. 368 Chin
    June 1, 2016 at 8:36 PM

    Hi PCI Guru:

    I read your post and I think you did a very great job! I have a question on requirement 8.2.2. What if the company is a small company and everyone know each other. What is your recommendation or suggestions to meet this requirement? Further do you have any good reference or link to test data?? Thanks!

    • June 6, 2016 at 9:47 AM

      You still need to do something to comply with 8.2.2 other than stating, “we are small and know each other.” The reason is that you may not always be small. Even if you put the last four characters of a person’s social security number, last four characters of a driver’s license number, etc. in your user’s help desk record. That would satisfy 8.2.2.

  134. 370 Christopher Kennedy
    May 24, 2016 at 5:20 AM

    When you log onto a an open, unsecured guest network like starbucks, and lets say you busy something online and enter CHD, how can Starbucks maintain PCI compliance if they are providing an unsecured access point to potentially allow individuals make credit card payments over their network. If they segment their CDE and isolate the guest wireless from their CDE, is that sufficient?

    • May 24, 2016 at 5:51 AM

      That wireless network is not on Starbuck’s network, it is a separate network owned and operated by AT&T. A lot of retailer’s open wireless is operated by third party carriers and never connect to the merchant’s network.

      That said, it is acceptable for a merchant to have a separate, secured VLAN for customer wireless that never comes into contact with the merchant’s CDE. You would have to monitor that network to ensure that it is not in contact, but it would be acceptable.

      • 372 Sebastian Nielsen
        July 25, 2016 at 9:18 PM

        I can clarify OP’s question:

        What he asked, is like this:
        If I, as a customer, go on Starbucks Wifi, and then navigate to a unsecured shopping site (that are not affliated with Starbucks), that are accepting credit card data without SSL, and this then results in CHD being transmitted over the unsecured Starbucks Guest Wifi from customer –> the unsecured shopping site, without encryption, and Starbucks’s out-of-scope network now, because of a customer and a non-compliant merchant site, did transmit cardholder data, what are the Starbucks PCI Compliance problems then.

        I would say none, because Starbucks PCI compliance is not affected because that transmission of cardholder data was not because a problem on Starbucks end, but a problem on the unsecured merchant’s problem, and Starbucks does not have any obligation to prevent this.

        Another comparision:
        Merchant A operates a CDE, and a isolated, separate guest Wifi, intended for customers. The guest Wifi is out of scope (Category 3).
        Merchant B, that is a neighbour to Merchant A, have on their own, without asking Merchant A, connected their wireless payment terminals to Merchant A’s guest Wifi.
        Even if Merchant A’s out of scope network transmits (unencrypted) cardholder data belongning to Merchant B, its not Merchant A’s problem, and thus does not bring Merchant A guest wifi into scope. Merchant B however, is going to lose their aquirer agreement pretty quick.

        A third comparision:
        A merchant uses Dropbox to store cardholder data, even tough dropbox’s storage servers are classified as out of scope on Dropbox’s end. Dropbox is not going to have any PCI compliance problems, even if they are affected by PCI DSS for accepting payments to increase storage space, but the merchant have big problems.

      • July 26, 2016 at 7:48 AM

        In the case of Starbucks and most merchants offering free Wi-Fi, those networks are not connected to the merchant in any way. In the case of Starbucks, Hard Rock Cafe and many others, AT&T or another carrier provides Wi-Fi independent of the merchants’ internal network. So it does not affect the merchant’s PCI compliance whatsoever.

        However, if the guest Wi-Fi is provided over the merchant’s infrastructure, it needs to be logically or physically separate from the rest of the merchant’s network(s) to be judged out of scope for PCI.

        Where we do run into problems is where a corporation provides cafeteria, coffee, parking, dry cleaning and other services that are operated by various third parties. Those third parties use their own POS solutions on the corporation’s network or private Wi-Fi and are not necessarily separated from the general corporate network. What we typically recommend, at a minimum, is that the corporation create a vendor VLAN that is separate from their corporate network and that the VLAN be encrypted. There are other solutions that can be implemented, but those can increase costs substantially and may result in the corporation being judged a service provider.

      • 374 Sebastian Nielsen
        July 26, 2016 at 8:47 PM

        Thats another thing if the merchants are related to each other via some sort of agreement.
        And the OP was just asking a general question about Guest Wifi’s in general. We know that Starbucks wifi are operated by a third party, now, lets assume its a general Guest Wifi operated by the merchant itself.

        What the OP was asking was basically this (reworded the question heavily):
        I think you are still not understanding the original OP’s question.


        Merchant A does have a CDE, and a logically separated Guest Wifi, everything is separate and firewalled in multiple layers so the Guest Wifi and CDE is completely isolated from each other.

        No traffic ever can travel between these. Everything so far is good, and the Guest Wifi is out of scope.

        Lets assume that the Guest Wifi even have a separate WAN connection, so the CDE and Guest Wifi is really really separate from each other.


        Next door, there is a competitior, Merchant B. Merchant A and Merchant B is not related to each other in any way, and they don’t provide any services to each other in any way. They are completely foregin to each other, and are competitors.

        Now, Merchant B, don’t care about PCI DSS, and then Merchant B connects their CDE equipment (terminals etc) to Merchant A’s out-of-scope and unencrypted Guest Wifi, just because this Wifi happens to have the strongest signal, and then Merchant B configures their CDE to transmit cardholder data completely unencrypted, just because Merchant B don’t care a shit about security.

        Whats happening now, is that Merchant A’s out-of-scope Guest Wifi, is transmitting unencrypted cardholder data belongning to Merchant B, over the air, everything without any agreement or permission from Merchant A.

        Its clear that Merchant B is violating the PCI DSS on basically every point that can be found.

        What the OP is asking now, is:
        Does the action of Merchant B, cause Merchant A’s Guest Wifi to be bringed into scope from Merchant A’s point of view.
        Eg, will Merchant B’s PCI DSS violation, affect Merchant A in any way?

        And here, I would simply say no, as Merchant A cannot execise any form of control over Merchant B.

      • July 29, 2016 at 9:46 AM

        If Guest Wi-Fi is truly segmented, the merchant is not responsible for anyone that uses it foolishly for transmitting sensitive information such as SAD/CHD.

  135. 376 Bill
    May 20, 2016 at 10:40 AM

    Hello, would like your opinion about charged off/closed credit card accounts. If a debt purchasing company buys a portfolio of charged of credit card accounts, are those PANs still in scope of PCI?

    • May 20, 2016 at 1:06 PM

      Sorry, but the Council and the card brands will all tell you that PANs are PANs and need to be protected. Even PANs of closed accounts and those on “Hot Sheets” are still in scope. The reason is that those closed and Hot PANs can be put back active at a moment’s notice by the brands.

      The only PANs that have ever been officially designated out of scope are test PANs issued to payment application software developers, processors and merchants. Those have been officially assigned as test accounts and can never be used to make payments.

      • 378 Bill
        May 20, 2016 at 2:35 PM

        Thank you very much for the input. I’m curious on your thoughts about FAQ# 1038 regarding closed/inactive accounts. If the debt purchaser could get the seller to contractually attest that the PANs of the accounts being sold could never be reactivated, would that take them out of scope for the purchaser? Or is it not even possible for the seller to guarantee that?

        Thanks again for your insight!

      • May 20, 2016 at 2:48 PM

        Only the card brand that controls the PAN can provide such a statement and, I can tell you from experience with other organizations that tried the same tactic, that will never happen.

  136. 380 Chase
    May 18, 2016 at 1:14 PM

    In a PCI DSS 3.1 context, what is meant by ‘remote access’? Is this non-cde to cde? Access over public networks? Or access from a network not within the scope of the PCI assessment (even if it’s owned or managed by the assessed entity?) Or other?

    • May 19, 2016 at 6:26 AM

      “Remote Access” in requirement 8.3 in the v3.1 context is in reference to any user (employee, contractor, service provider, etc.) that is not on the organization’s internal network and is attempting to access the organization’s cardholder data environment (CDE).

      So for example, an employee is on a VPN connection from their home to perform some support task. In order to gain access to the CDE, that employee must have used two-factor authentication (2FA) to obtain that CDE access. 2FA could have occurred at the time of their VPN authentication or as part of their access to the CDE.

      This is the change that is coming with v3.2 (best practice until July 1, 2018). Under the v3.2 of the PCI DSS, requirement 8.3 will require organizations to implement 2FA at the entry to the CDE so that any user (internal or remote) will have to use 2FA to gain access to the CDE.

      • 382 Scott
        August 16, 2016 at 7:49 AM

        Hello, Isn’t this all in regards to Remote Access VPN? What about an Internal LAN (not DMZ) authenticated and authorized user (someone sitting at their office desk) having access through Site-to-Site VPN encrypted tunnel thru a Gateway to an segregated offsite CDE . Would this require 2FA or not, I am assuming that since the CDE is already segregated and has FW, AD, ACL, etc.. protecting it from unauthorized users, it should be treated as local access, correct?

        Here are two good articles on this subject. first a great explanation from CISCO on the definition of VPN and the two types: Remote access VPN vs Site-to-Site VPN gateways. the second article is from Secureworks on the same topic but from a PCI DSS perspective. – (see When is Two-Factor Authentication Required)

      • August 18, 2016 at 9:11 AM

        With v3.2 of the DSS, anyone with administrative privileges such as system administrators or DBAs, are required to access (local or remote) the cardholder data environment (CDE) using multi-factor authentication. I have also heard from some acquiring banks and processors that they also include users that have access to bulk cardholder data in this group of requiring multi-factor authentication to access the CDE. The reason for the change to the DSS is to reduce the ability of Target and Home Depot style breaches where administrators were socially engineered and their credentials used to access the CDE. With multi-factor required at all times to access the CDE, the attacker would also have to compromise the multi-factor solution in addition to having the administrator’s credentials.

  137. 384 Joyce
    May 12, 2016 at 8:22 PM

    Hi there – we are having a debate and our organization has not be asked to be PCI compliant by third parties as we store only PAN but that is it. Are we still required to be PCI compliant? If yes where does it state if we are not a merchant or service provider we need to be compliant?

    • May 13, 2016 at 5:06 AM

      Page 7 of the PCI DSS, second sentence states, “PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.” I would say that your organization would be included in “all other entities that store”.

  138. 386 Owen
    May 12, 2016 at 4:43 AM


    Just a quick question about penetration test reports….

    I’ve been asked to look at a penetration report to let management know whether the work that was conducted is thorough and adequate and that the action plan is complete.

    When i looked at it, the scope of the report covered everything i’d expect to see for example “password complexity/security” but because nothing was found to be wrong with the passwords, there is nothing written in the report about it as the report only lists problems…so now i can only draw two conclusions:

    1. There isn’t anything wrong with the passwords e.g. no defaults etc. although i have no evidence this is true.
    2. They didn’t do the work!

    I find reporting only on the negative strange as it never includes a “work done” section so nobody can see exactly what was examined or what methods were used.

    Is this a normal way to report and if so, how can you place reliance on it besides company reputation?



    • May 12, 2016 at 6:09 AM

      This is the way a penetration testing report is typically written. Only the issues found are reported. So if it is not documented in the findings, then you can assume it was tested and no issues were found.

  139. 388 Dan
    May 11, 2016 at 7:41 PM

    Great site! I am considering getting an ISA certification. I know QSAs are required to have liability insurance but do you recommend ISAs obtain liability insurance as well? Could an ISA be held personally liable, whether they perform a self-assessment or assist a QSA in their assessment, in the event the ISA’s organization’s CHD were breached?

    • May 12, 2016 at 6:11 AM

      As an employee you would be covered under your employer’s business liability insurance policy regardless of your role in the PCI assessment process.

  140. 390 Alm
    May 9, 2016 at 4:56 AM

    Hi thanks for the great resource.

    We fully outsource all cardholder operations to our processor and are in the process of completing the SAQ-A 3.2 document. We are a bit confused because the doc requests us to comply with Requirements 2, 8, 9 – but the way the questions are worded suggests that the scope of these requirements applies ONLY to the cardholder data environment, which wouldn’t apply to us. For example it says “Are all users assigned a unique ID before allowing them to access system components or cardholder data?”

    As I mentioned, we fully outsource everything and don’t see any card data. Should the answers to the questions be all marked as N/A ?

    • May 11, 2016 at 8:05 AM

      While you may fully outsource your environment, you are saying that none of your employees have any role in managing and maintaining that outsourced environment? Even if you are using PayPal, some of your employees will have access to the PayPal system for handling disputes and chargebacks. It is those accounts to outsourced applications that SAQ A applies.

      • 392 Alm
        May 11, 2016 at 10:52 AM


        I agree with you BUT the outsourced card company tells us that the PAN information is NOT visible to any user of the chargeback or any other platform. Therefore, the employee is not exposed to Cardholder data…

      • May 12, 2016 at 6:13 AM

        If the full PAN is not available to the user of the application, then from your organization’s perspective, the application is not in scope.

      • 394 Bob P
        May 12, 2016 at 9:10 AM

        Hi Guru, do you not think these new requirements apply to the web server that is performing the redirect to the third party payment site? When I first read the changes, I assumed it was to further protect the web server redirect versus protecting the data stored on third party payment sites.

      • May 12, 2016 at 10:43 AM

        It applies to all PCI in-scope systems be they the Web server doing the redirect or for the merchant’s systems that access the third party applications that process payments.

  141. 396 Ryan S.
    May 6, 2016 at 1:55 PM

    I have been struggling with the concept of redirection and was wondering if you could provide some clarity. If I place a hyperlink on my public website to a 3rd party eCommerce site that collects user information and in turn redirects the user to a 3rd party payment site to enter and process the credit card transaction, is my public web server in scope as a redirection server? I guess it boils down to the question, “is a hyperlink a redirect?” The public website only provides general information and a link for customers to pay a fee.

    • May 8, 2016 at 8:47 AM

      A hyperlink to a payment page is a valid redirect. According to the PCI SCC, that means that your public Web site is out of scope.

      HOWEVER … While that is the PCI compliance side of the equation, it is not the information security answer. The risk is that if that hyperlink gets modified and starts sending your customers to a malicious payment page, who is at fault? The answer of course is your organization. So I tell my clients taking the redirect approach that they still need to vulnerability scan at least quarterly and penetration test at least annually. They also need to monitor the hyperlink so that if it ever changes, they get an alert of that change. They also need to collect log data from that server to monitor it as well.

  142. 398 Ash
    May 5, 2016 at 5:01 PM

    Hey mate,

    Quick question about requirement 11.5 and 11.5.1 – FIM!!

    If an organisation has their entire network in scope e.g. agent terminals, servers etc. etc. and they are not storing any card-holder data, do they still need FIM on all their end-points and in scope servers? to monitor critical OS files etc.

    Also, if not FIM what alternate automated / manual controls may suffice or is FIM mandatory?

    Appreciate your help.


    • May 8, 2016 at 8:57 AM

      You may not be storing cardholder data (CHD) but you are obviously processing and transmitting it if your network is in scope. So your systems have CHD in their memory and it traverses your network. File integrity monitoring (FIM) or similar solutions are used to minimize or stop unapproved changes to files or adding files to systems that are malicious but not stopped by anti-virus solutions. However you choose to implement such a capability, you need to generate alerts so that you can stop the malicious files before they do too much damage.

      • May 10, 2016 at 12:00 PM

        Hi PCIGuru

        We have an Android and Apple application which registers members into our loyalty system. Part of the process is to register their card information in order to track their transactions. This is done via a Spreedly solution. We are looking at utilising a USSD application (under scope at present) to do the same. We however need to find a solution to transmit their card pans via the USSD application to Spreedly in a PCI compliant manner. The company which will be handling the database is not PCI compliant, so we are looking for a solution to this. Any suggestions?

      • May 10, 2016 at 5:13 PM

        The problem you are going to have is the Windows/Android/iOS issue of keyboard logging. Any manual data entry into such mobile devices is going to be recorded by that device and stored in memory for a length of time until overwritten. As far as I am aware, there is no way for a developer to disable this feature on those mobile devices. Payment solutions such as those from Verifone, Square and the like avoid this by encrypting the cardholder data (CHD) at the swipe/dip of the card. However, even these solutions warn users that manual data entry of CHD will be recorded by their mobile device. This is why the PCI SSC has consistently stated that mobile devices will never be considered PCI compliant.

  143. May 5, 2016 at 8:55 AM

    Hi PCI Guru

    We are using company A (who have informed us that they are PCI compliant) to scan paper forms containing supporter details as well as CC numbers. They scan the forms and hide the middle 8 digits for us to then attach them to supporter records on our CRM. They then send back all the hardcopy forms with the full CC details still on the forms leaving us to manually remove them appropriately before placing into storage.

    Can you tell me if PCI compliance covers returning physical forms back to us? Should the CC number be redacted by Company A before returning (by post) to us for archiving?



    • May 8, 2016 at 9:05 AM

      First, you need to get Company A’s PCI Attestation Of Compliance (AOC) to have absolute proof that they are PCI compliant. Having a third party tell you they are PCI compliant is not good enough.

      Paper forms are also in scope for PCI compliance. But redaction of sensitive authentication data (SAD) and cardholder data (CHD) from forms is not as simple as you may think. In order to securely redact SAD/CHD from forms, you must take a black Sharpie marker and black out the PAN to the first six and/or last four digits. Then you need to take a photocopy of the original form, retain the photocopy and securely destroy the original. If you do not do the photocopy, the redaction of the PAN can still be read by holding the original form up to a bright light.

      Whether you get the third party to do the secure redaction of the PAN your you do it is up to your organization to determine.

  144. 404 Jon
    May 2, 2016 at 10:25 AM

    Hello PCI Guru. I’d like to get your update regarding 2 entirely different things:

    1) What if an HSM which was certified in the past as an PCI Certified device is being used after the EOL was reached? It is not obviously certified and is also failling the requirement 6 of having systems constantly updated as vendor releases. How would be an acceptable solution for you in terms of migration plan ans PCI compliance?

    2) How do you manage companies that are not able to fulfill the quarterly pass scan from an ASV? I mean, somebody who don’t hae the 4 required scans but at the time of the certification, the last scan is OK.

    Thanks a lot for your opinnion on this!

    Have a nice day!

    • May 3, 2016 at 8:42 AM

      The Council has come back and said that out dated an unsupported software, hardware and appliances are acceptable but will required compensating controls to meet the PCI requirements. So that is how to deal with the HSM situation. That said, you can encounter situations such as with Windows 2000 Server where the compensating controls just cannot be put in place to address all of the issues with Windows 2000 Server.

      You would have to come up with compensating controls for the three quarterly scans that failed.

  145. 406 Bob P
    April 29, 2016 at 12:15 PM

    Hi Guru, I want to understand your opinion on network segmentation and SAQ A environments. Does the web server executing the redirect to a third party site – like Cybersource, payPal – have to be segmented/isolated? I know there are still risks so having controls that exceed SAQ A are recommended, but i am interested in the network segmentation approach for validation.

    thank you.

    • May 3, 2016 at 8:45 AM

      That would be an excellent idea, but it is not required with SAQ A. Even if you are in an SAQ A situation, in my very humble opinion, you should follow SAQ A-EP’s guidance to ensure security.

  146. 408 Greg Crowe
    April 29, 2016 at 8:54 AM

    HI PCI Guru, i am currently restructuring our PCI service provider support network and wondered if you could help me clarify something?
    We use McAfee AV and have agents on 20 servers and 100 workstations that send and receive information to the central McAfee ePolicy Orchestrator. This central server is not located on the PCI network, it is situated in a datacentre on its own network behind a firewall on a hardened server and it only sends and receives https traffic from the PCI network. Is the ePolicy Orchestrator in scope and does having it located outside of the network but my compliance in jeopardy?
    Any advice would be greatly appreciated!

    • April 29, 2016 at 9:52 AM

      Yes, your McAfee ePolicy server is in-scope for PCI because it connects to systems that are in your cardholder data environment (CDE). That said, do not despair. It is NOT the end of the world. It all comes down to how you are managing the risk of that McAfee server in regards to the CDE systems. You have a firewall that separates your McAfee system from the CDE systems. It sounds like the rules on the firewall sufficiently restrict traffic in/from the CDE. The question would be how/what you monitor on that firewall to ensure that the McAfee system does not contaminate any systems in the CDE should it become compromised.

      If that risk is unacceptable to your organization, then you will likely want to implement a separate ePolicy server inside your CDE.

  147. 410 David Grow
    April 26, 2016 at 7:52 AM

    I have a general question. I’m not sure if you have addressed this before. In the executive summary section of the ROC it asks for critical hardware and software. This seems to be an ambiguous request as what is deemed critical might differ from one person to the next. What is your opinion on what should be included?

    Thanks for any insight.


    • April 28, 2016 at 3:00 PM

      If the hardware and/or software was deemed in scope for assessing it, then it belongs in those lists.

      • 412 David Grow
        April 29, 2016 at 11:52 AM

        Isn’t that in essence the system inventory in 2.4?

  148. 413 Derek
    April 21, 2016 at 11:44 AM

    Hi PCI Guru, thanks for the updates on this website, as I can tell from the many comments you’re offering a great service to many.

    A comment around DUKPTs was made to me around PCI, and I haven’t been able to find a definitive answer and hoping you might have it.

    The comment was that although a lot of terminals can support multiple DUKPT keys for PIN encryption that PCI limits all terminals to use only one – do you know if this statement is indeed true?

    • April 25, 2016 at 8:33 AM

      Working on a DUKPT post as you are not the only one with questions. That said, multiple keys per merchant is a function of the transaction processor. So you will have to ask your processor if they support multiple keys. It is not a restriction of the protocol that I am aware.

      • 415 Derek
        April 26, 2016 at 11:16 AM

        Thanks for quick reply.

        If the merchant has multiple transaction processors, do you know if PCI limits to requiring only 1 DUKPT? or could we have a different DUKPT key for each processor loaded in a device?

      • April 28, 2016 at 2:54 PM

        You would have to have a different key for each processor and each processor would have to inject those devices before their use.

  149. 417 Bill LaFleur
    April 15, 2016 at 11:16 AM

    We are having a bit of an internal debate and I’m hoping you can help us decide either way. We have a service provider that is refusing to go through the effort of an assessment. So under 12.8 we feel it is necessary for us to invoke the audit clause of the contract and perform the assessment ourselves. The question that’s come up is are we allowed as ISA’s to go onsite and assess the service provider or must we pay for and bring in a QSA to perform the assessment? Some feel that technically as an ISA you can only assess your own company and therefore the Council would prevent one from looking at another company, even a service provider that has your data. What are your thoughts?

    • April 15, 2016 at 11:57 AM

      If you feel your ISAs have the skills necessary to assess the service provider, I would argue that you can do that assessment. Where I have seen QSAs used is when the service provider is using technology that the ISAs do not possess such as mainframe or UNIX for example. The Council does not required that a QSA assess third parties. The only requirement for using a QSA is if the service provider is looking to register with Visa or MasterCard on their Global Service Provider lists.

    • 419 PeCulIar DoSSier
      May 5, 2016 at 12:18 AM

      Are the requirements laid out in PCI DSS 3.1, control level requirements or policy level requirements?

      • May 8, 2016 at 9:06 AM

        Both. But it depends on the requirement and testing of the requirement.

  150. 421 JHP
    April 13, 2016 at 2:28 PM

    Hello, I am fairly new to the Payment Card Industry but I had a question in regards to PTS approved devices on the website. How come some devices are listed as SRED CTLS while some devices are listed as SRED NonContactless? How would Contactless be handled in order for a Payment Terminal to become SRED Compliant? I believe there was a change from PCI PTS v3 to PCI PTS v4 but I am unable to track down reason.

    • April 15, 2016 at 12:02 PM

      My guess is that the difference is that the device manufacturer did not submit the contactless feature of device for PTS certification. I will contact my PTS expert to confirm that though.

    • April 16, 2016 at 7:25 AM

      Here is the “official” answer from Andrew Jamieson at UL that does PTS certifications.

      “Regarding your question, the answer is a bit complicated. SRED was introduced in PTS v3 but there was a ‘grandfather’ period for SRED on v2 devices for some time (about 1 year from memory). The specific requirements for contactless physical security were not enforced immediately and so there was a (very) small window when some devices were approved to SRED without the assessment of the contactless _physical_ security. Such devices may not be listed as having contactless SRED features.

      Additionally, the listing of the ‘functions provided’ was not something done until some way through v3, when a changenwas made to the webaite listings, and although the person in PCI responsible for sorting the listings out has done a stellar job going through all the old reports to figure out what does what there is the chance that some devices listed prior to this time may be listed incorrectly.

      Finally, and quite simply, not all devices provide contactless options, or (for reasons unknown) they may disable the contactless in their PCI approved firmware during submission. One of the most important changes in v4 of PTS (IMHO) is the Security Policy which helps to sort out a lot of these issues and make much clearer to the merchant / acquirer what exactly the sort device does and what was assessed.”

  151. 424 luc
    April 6, 2016 at 10:50 AM

    Thank you so much for having a very informative website. I’ve read through most of the questions others have posted, and your replies, but just wanted to double check.

    If our workstation which has a P2PE usb device for credit card swiping, where it sends the encrypted data directly to our processor (in other words, the workstation does not have access to the data) and our company does not have access to decrypt the keys, then would both our workstations and network be out of scope?

    In addition, would it be out of scope in that there is no need to monitor the logs daily, integrity of the systems, requirement of a penetration test?

    Thank you in advance for your help.

    • April 7, 2016 at 6:05 AM

      First, are you absolutely sure that your solution is point-to-point encryption (P2PE) validated? I cannot tell you how many times we talk to clients/prospects that tell us they have a P2PE solution only to determine that it is an end-to-end encryption (E2EE) solution. Do not feel bad as a lot of vendors’ sales people pawn off these wonderful P2PE white papers that confuse people into thinking the solution has been P2PE validated when in fact it has not been through the process. The bottom line is, if you cannot find your solution on the PCI SSC Web site (, then it has not been P2PE validated. Not that it is the end of the world, it just means that you have some additional work to validate that your E2EE solution is acceptable and reduces scope.

      Assuming that you do have a P2PE validated solution. You need to prove that you implemented it exactly as documented in the solution’s Implementation Guide (IG). Assuming that you did the implementation properly, then only the point of interaction (POI), i.e., card terminal, is in scope. Everything else will be out of scope and the only requirements your organization needs to comply with are documented in SAQ P2PE-HW.

      If you review SAQ P2PE-HW, you will see that there are no requirements for vulnerability scanning or penetration testing of the POI.

      NOTE: All of this of course assumes that you have no other payment channels that would increase your scope outside of those requirements.

      • 426 luc
        April 7, 2016 at 10:44 AM

        Thank you very much for the reply, Actually it seems that one of our dept is using Shift4’s solution, which isn’t a validated P2PE. Shift4 isn’t on PCI SSC list, and they actually have some info on their list as why they are not, but I’ll have to look into that further. unfortunately, that dept already signed the contract with the company. On the bright side, we have another dept that will be using BlueFin’s solution, which is on the validated list.

        Thank you very much for clarifying the scoping information, and for the info on the SAQ. as you’ve said, it really reduces a lot of scope, and also, i’m hoping it reduces the risk as well.

        Cheers PCI Guru!

      • April 7, 2016 at 12:19 PM

        Full disclosure. Shift4 is a former client of my company and I have worked with them for a number of years. So I know quite a bit about their company as well as their solutions. In addition to the fact that I and others at my employer have implemented their E2EE solution.

        There is nothing at all wrong with the Shift4 solution as it is just as secure, if not more so, than some of those validated P2PE solutions. This is the reason why P2PE is a somewhat questionable and what I believe to be useless standard. There are plenty of E2EE solutions from major vendors such as Verifone, First Data and others that could be P2PE validated but are not because the vendors do not see the value provided to their customers for such an assessment. In the opinion of most QSAs, there is only slightly more additional work required with an E2EE solution to get the same scope reduction that you get with a P2PE validated solution.

  152. April 6, 2016 at 9:14 AM

    how to use workstations, compliantly …

    we host a page, that send cards to a PSP to be tokenised. That’s all good … We also have staff call our customers, then use our workstations to enter cards (on behalf of the customer) onto this same site. Less good.

    How can i minimise my scope in these areas, even remove the workstations and telephony all together (or at least keep them segregated from the broader network), when they depend on common systems like Active Directory, AV, patching, etc ?

    • April 7, 2016 at 6:08 AM

      Your only way to totally minimize your scope is to outsource your manual call center work to a third party call center. Otherwise, those workstations and the connected systems are all in scope.

  153. 430 Kevin
    March 31, 2016 at 10:02 PM

    I have question about “1.3.5 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.”

    For e-commerce the solution is pretty clear. What about a sales person that uses their PC to research potential clients and take payments? The test criteria imply a route/firewall is doing the limiting authorizing, but could a A/V product with anti-phishing capability fill this role?

    • April 1, 2016 at 10:32 AM

      Only if the anti-virus solution provides a personal firewall capability as with Symantec, Trend Micro and the like. Anti-virus, anti-malware, anti-phishing solutions alone do not meet the requirements in 1.3.5.

  154. March 28, 2016 at 8:36 AM

    What is credit card “service code” under CHD? Not the CVC under SAD. Thanks.

    • March 28, 2016 at 9:26 AM

      Per the definition in the PCI Glossary, service code is defined as:

      “Three-digit or four-digit value in the magnetic-stripe that follows the expiration date of the payment card on the track data. It is used for various things such as defining service attributes, differentiating between international and national interchange, or identifying usage restrictions.”

      This value is NOT the CVV/CVC/CID. It is an entirely different value used by the card brands, processors and banks. See for the layout of the various track data that can be on a magnetic stripe. Also remember that EMV has its own rules but also stores the same track data for consistency with the magnetic stripe.

  155. 434 PeCulIar-DoSSier
    March 28, 2016 at 1:01 AM

    How are the big banks doing w.r.t PCI Compliance?

    • March 28, 2016 at 7:42 AM

      Huh? Sorry, couldn’t resist. Most banks are in denial regarding PCI compliance. I wish I had a dollar for every one of the banks I have dealt with that said PCI was for merchants only. Then you go through the PCI DSS and point out that it says:

      “PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Below is a high-level overview of the 12 PCI DSS requirements.”

      That said, banks (at least those in the US) are the least problem of the card brands for breaching of data. That is because the banks are under the scrutiny of the FDIC, OCC, NCUA and other regulatory agencies. All of these agencies focus heavily on the security of all financial data, not just cardholder data. As a result, the banks are much more rigorous in their security efforts than merchants and other service providers.

      However, the card brands have come around and are looking at PCI compliance within banks more and more. As a result, we are seeing more and more financial institutions requesting PCI gap assessments to determine their level of compliance.

      • 436 PeCulIar DoSSier
        March 30, 2016 at 5:06 AM

        Any Big Banks that are PCI DSS Certified?

      • March 30, 2016 at 5:12 AM

        No one is ever PCI DSS “certified” because the assessment process is not an audit. Anyone assessing themselves to the PCI DSS is judged “compliant” or “non-compliant”.

        I know of a number of regional banks that are PCI DSS compliant for their ATM networks, transaction processing and their card production operations. I also know that a lot of banks are going through PCI DSS compliance analyses to determine gaps and how to remediate those issues. Whether or not all of the banks in-scope operations have been assessed I have not seen or been privy to those efforts.

      • 438 PeCulIar DoSSier
        March 30, 2016 at 5:09 AM

        Are any of the BIG Banks PCI DSS Certified?

      • 439 PeCulIar DoSSier
        March 30, 2016 at 8:38 AM

        I think the biggest challenge for a PCI DSS Compliance exercise is scoping. If you have to start with say identifying all credit card data flows, this As-Is assessment itself could go on for ages. Also the organization’s card processing/storing/transmitting environment could be in a constant state of flux. So you are actually trying to get a hold on a “Moving Target”. How do you plan an “Identify all credit card data” exercise especially with a Big Bank?

      • March 30, 2016 at 11:49 AM

        You do the best you can knowing that issues will come out of the woodwork. I cannot tell you the number of times in very large organizations where towards the end of an assessment they acquire something or a new operation is found where cardholder data (CHD) is involved. All you can do is to draw a line and save the new stuff for the next assessment. Otherwise you will truly never finish.

  156. 441 Kevin Hinterberg
    March 21, 2016 at 1:25 PM

    Hi PCI Guru,

    Does PCI Requirement 8.2.4 “Change user passwords/passphrases at least once every 90 days.” apply to service accounts? I apologize if this is a stupid question, but I haven’t found any good information online. I would think it does since service accounts can pose a large security risk, but the requirement specifically says the word “user”. Your help is greatly appreciated, and I have been reading your site for a long time.

    • March 25, 2016 at 7:27 AM

      As long as those service accounts cannot be used by someone to logon, then they do not have to change unless the organization feels that those accounts might have been compromised.