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.

1861 Responses to “Miscellaneous Questions Page”

  1. 1 Paul
    November 16, 2020 at 9:56 AM


    Question regarding segmentation and category 2/security impacting systems. Can you tell me, how is segmentation looked at from this perspective? More specifically, do these Cat 2 systems need to be in their own network segments and will the firewall rules that isolate them from the rest of the corporate network (not the CDE) also be in-scope for the firewall reviews? If for example a domain controller could connect both to the CDE and other non-CDE environments, would the assets in the non-CDE environment then be pulled into testing scope?

    Is there any guidance the council has put forth that speaks to this specific use case?

    • November 17, 2020 at 12:29 PM

      Easiest question first. See the Information Supplement ‘Guidance for PCI DSS Scoping and Segmentation’ for reference.

      As to your first question, you need firewalls to segment CDE, Connected To and not in scope network segments from one another. That does not necessarily mean separate firewalls (best approach), but separate network adapters on a single firewall with the appropriate rules. Connected To (Cat 2) systems are always in scope because they connect to systems that are directly in scope. Connected To systems are allowed to communicate to the CDE as well as out of scope systems but you must ensure that the out of scope systems cannot effect the security of Connected To systems that could then effect the security of the CDE.

  2. 3 gabbyndu
    October 23, 2020 at 4:24 AM

    How can organisations with their PCI-DSS assets in amazon cloud for example comply with requirement 1.1.7 that talks about firewall and router review every six months? knowing that they don’t have control over the firewall and routers

    • October 25, 2020 at 12:09 PM

      Pardon? This is a shared responsibility if you read the AWS responsibility matrix. AWS merely provides the capability, but your organization is responsible for establishing the firewall rules and network routes.

  3. 5 rlm
    October 22, 2020 at 12:21 PM

    Made an error in my last post..:

    Text contained in the major card brand program guides is somewhat confusing when it comes to deciphering franchisor/franchisee/TPSP PCI DSS accountability (think RACI model). American Express provides the clearest directive, as AMEX states that [remove all] “covered parties” are accountable for all entities associated with the entities’ Merchant Account.”

    • October 25, 2020 at 12:16 PM

      In most franchise arrangements, it is the franchisee that is on the hook for PCI DSS compliance. Where that can get messy though is with for example fast food where the franchisor may have connectivity into the franchisee’s systems for account, HR, inventory, ordering, monitoring, etc. In those cases, the Franchisor needs to be providing an AOC to the franchisee for those services they provide that could impact the security of CHD/SAD.

      A prime example of this arrangement is Exxon/Mobil Speedpass. That program is managed/maintained by Exxon/Mobile on behalf of their participating franchisees. Exxon/Mobil originally stored the CHD information and all transactions flow through them thus making Exxon/Mobil a service provider to their franchisees. It is my understanding now that Exxon/Mobil only stored tokens which gets the CHD out of their systems but they are still a service provider to their franchisees.

  4. 7 Stassi Hausen
    October 21, 2020 at 12:19 PM

    Do you happen to know if there are any limitations around reporting entities for ASV scans vs. SAQ’s? For example, if an entity reported via multiple SAQ’s, can they all rely on the same ASV scan providing that the appropriate hosts are included in the ASV scan or do they need to be separated to align with the SAQ’s?

    • October 22, 2020 at 11:22 AM

      I would have to ask why there are multiple SAQs with only one set of ASV scans. I would assume that the ASV is scanning everything used by the organization but for whatever reason there is an SAQ for each business unit for example. When that happens, you need to call out what infrastructure belongs to what BU for their individual SAQ.

      • 9 Robert
        October 25, 2020 at 4:13 AM

        I work for an acquiring bank and can confirm that there is no limitation in the Card Brand rules that prevents an entity from reporting their compliance using multiple SAQs and a single all-encompassing ASV. The primary reason an entity will attempt to report using multiple short-form SAQs is to align their acceptance channels in their CDE to the chosen SAQs. So long as the ASV scan tests all external IPs, it shouldn’t be a problem for the acquirer and Card Brands to accept. As PCIguru points out, you have to call out the infrastructure that belongs to the particular acceptance channel / SAQ.

        As an acquirer, we encourage merchants to aggregate multiple SAQs into one SAQ-D. They can validate using multiple SAQs if desired, but only one document should be submitted. This is easier for us, but moreover it ensures that the merchant has only one published compliance date in Section 3 of the AOC. Those merchants who report using multiple SAQs don’t always publish the same date on all SAQs making it more difficult for the acquirer to report compliance to the Card Brands.

  5. 10 Pete
    October 20, 2020 at 8:47 PM

    I’ve chased leads for over a year now, and have found statements supporting every side of the argument. I understand it can be complex, but the basic question should have a definitive answer available somewhere without all the circle talk.

    Scenario: I have a small office that takes card-present payments and is equipped with PCI-DSS approved P2PE hardware. The office is compliant and follows the P2PE requirements to a T.

    Twist: This office has begun taking phone payments over a VOIP system and entering the CHD on the P2PE keypads on behalf of the user.

    Question: Did this office’s SAQ qualification just change from a SAQ-P2PE to a SAQ-D by beginning to take phone payments over a VOIP system?

    Bonus Points: Does a possibility exist that would enable the office practices to proceed while still qualifying for P2PE? (Segmentation?)

    • October 22, 2020 at 11:29 AM

      Yes, your scope now includes the VoIP solution because people speak CHD/SAD over the phone. As a result, you are never going to be just P2PE once you added in VoIP.

      As to SAQ, yes you are probably going to have to use SAQ D to cover VoIP although a good portion will likely be marked as Not Applicable.

      One option is to outsource your VoIP and do end-to-end encryption (E2EE) between handsets and the call manager and other VoIP servers. That leave only handsets in scope which is not a heavy lift.

      Where organizations run into trouble is when they have softphones in use because softphones drag the workstations they run on into scope regardless of whether they discuss CHD/SAD via phone because they are directly connected to the CDE.

      You need to read the Information Supplement on Telephony from the PCI SSC Web site.

      • 12 Pete
        October 23, 2020 at 8:11 AM

        Thanks a bunch for your insight.
        After about 3 years on this project I still learn new things every day.

        Our VOIP implementation is already a hosted setup although, we are exploring DTMF masking in order to potentially de-scope the phone payments back out of the equation and get back to the P2PE qualification we desired. Hopefully DTMF masking can help us accomplish this.

        I have read the supplement you referenced, as well as every other resource I can possibly find regarding this subject. The answers are just not as clear as I would like. Your site has been one of the best resources of “plain talk” information I have found. Thanks a ton for that.

        In regards to your statement regarding “a good portion will likely be marked as Not Applicable”, I have one other hypothetical question to ask, as this too has produced conflicting information.

        Scenaro: If a company uses a flat network, but has two distinctively differing payment channels/processes, one meeting P2PE qualifications (branch office) and the other qualifying for SAQ-A (call center), I understand the proper way to accomplish this is by utilizing a SAQ-D to fulfill both channels.

        Question: If utilizing the SAQ-D form, can the company complete ONLY the requirements that are required either on the SAQ-A or the SAQ-P2PE form and mark EVERY OTHER requirement on the SAQ-D form as N/A, with the explanaition that it doesn’t apply to the SAQ-A and SAQ-P2PE qualifications, also fully explaining the intent and reasoning in the Executive Summary on the SAQ-D form.

        Thanks again for your insight. Your information provided at this site is awesome.

      • October 25, 2020 at 12:07 PM

        Whether or not DTMF masking reduces scope is dependent upon where it occurs. If it is before it hits the VoIP system, then it will reduce scope. If it occurs after (the most common implementation), the CHD is still going through the VoIP system and therefore it is not out of scope. It doesn’t matter that operators cannot hear the DTMF, its the fact that the call is still going through the VoIP call manager which is transmitting it to the DTMF masking solution.

        The short answer to your question is Yes. However, given my previous clarification, you may want to reconsider whether SAQ A is realistic for your call center.

  6. 14 Robert
    October 13, 2020 at 1:43 PM

    I have a question about MFA factors. Would a Kerberos token returned from a SAML call constitute a “Something you have” factor?

    • October 17, 2020 at 3:14 PM

      The Kerberos token is obtained by the user providing credentials. If the user’s credentials are compromised, anyone with those credentials can generate the Kerberos token so it is not MFA. The purpose of MFA is to not rely only on user credentials. You are relying on independent factors that cannot be derived from the other factors.

      • 16 Robert
        October 18, 2020 at 10:17 AM

        Thanks for those thoughts and I do agree with the position you’ve stated. The Kerberos token is obtained from a completely separate authentication environment from where the service is provided, and the user credentials which are associated with the service are validated in another separate authentication environment. So, the attacker would have to successfully compromise two disparate authentication environments to succeed with that attack. That situation does seem to fulfil the property of independence.

      • October 19, 2020 at 6:59 AM

        But is not the Kerberos token created as part of the authentication process using the user’s credentials to start the process? I would agree with you if the user must authenticate to LDAP for an example and then use different credentials to authenticate to Kerberos.

        However, in all of the Kerberos implementations I have seen, it is the user’s single set of credentials that authenticate as well as generate a Kerberos token behind the scenes. That is not MFA as defined by the PCI DSS nor NIST. You need two independent factors used to qualify as two factor authentication. Hence the something you know and something you have or something you are. One factor cannot generate the second or third factors.

      • 18 Robert
        October 20, 2020 at 7:09 PM

        The entity is trying to access a TPSP portal. The entity has implemented the following process. The entity has their auth system, a federated login based around AD. The TPSP has their own independant auth system, in no way related to the entity’s AD. An end user must have credentials on both systems and both access provisioning processes are separate. Having any one set of credentials does not guarantee portal access.

        The entity’s AD and federated login both need to be compromised to falsify a Kerberos token. The same assailant needs to compromise the TPSP’s AD to falsify the portal access. Both the entity’s token and the TPSP’s credentials are presented to the TPSP to get access. If access fails, it’s not possible to determine whether the token was bad or the TPSP credentials were bad.

      • October 22, 2020 at 11:31 AM

        I see two logons with different credentials. By definition that is NOT two factor authentication. See NIST SP800-63B for more information.

  7. 20 Rpm
    September 16, 2020 at 8:37 PM

    Hello Pciguru,

    What is the short term solution to resolve application hosted in PCF to connect directly with applications hosted in pci zone?

  8. 22 Deepa
    August 20, 2020 at 12:15 AM

    Hi PCI Guru, thanks for your support.
    I have a question on SAQ A.
    While SAQ A doesn’t not mandate customers using iframe on their website to have requirement 5 ( Antivirus ) and FIM solution and tea 10- logging , is it fine to go ahead with compliance without these basic important security requirements.
    The ecommerce guideline from PCI do recommend these in addition to SAQ A controls, but are these mandatory.
    Can we go ahead with certification without AV, FIM and logging for a website using iframe and eligible for a SAQ A.
    Thank you.

    • August 21, 2020 at 2:06 PM

      Remember, the Coucil always reminds people that the Information Supplements do NOT replace any requirements in the PCI DSS. They are written only to provide additional information on ways to approach compliance issues encountered when dealing with the PCI DSS.

      That said, I always explain to my clients that just because you are PCI compliant, does not mean you are secure. When that SAQ A compliant Web site gets compromised, it will NOT be the acquiring bank that is on the legal hook for that mistake. It will be you Ms. Client that is legally on the hook, so please act accordingly.

    • August 21, 2020 at 2:07 PM

      If it is NOT in SAQ A then to be PCI compliant, it is not needed.

    • 25 Deepa
      August 21, 2020 at 4:45 PM

      Thank you 👍

  9. 26 Deepa
    August 19, 2020 at 7:30 PM

    Hello Pci guru, thanks for all your insights.
    I have a question on call centers.
    If the call centers uses third party pci compliant call center soution that integrates with your calling soultion and makes uses of DTMF tones ( eg solutions from Secure co, semafone etc ) and thus call center agents do no see or hear card numbers or SAD, is the call center still is scope of pcidss.
    If yes what controls are to be validated in the call center. Thanks.

    • August 21, 2020 at 2:01 PM

      The problem with DTMF solutions is it all depends on how they are implemented. While call center operators cannot hear the tones, the call may still be processing through your Call Manager or telephone system which means it is still in scope. This is why you really need to follow the call flow to make sure that when DTMF is used, that VoIP flow is not still within your telephone system.

  10. 29 Joe H
    August 12, 2020 at 4:07 PM

    Hi PCIguru,

    Thank you for your work in maintaining this website. It has truly been informative and helpful.

    I have a query with regards to an organisation that has remediated their environment, and now meet the criteria for an SAQ-A and SAQ P2PE, BUT…. they believe they have CHD stored within legacy backup tapes in the form of email, files (e.g. Excel), etc. It is not a trivial task to restore all backups, search for CHD and securely delete them, as the backup of the environment is spanned across multiple tapes per backup run. Additionally, some legacy backup tapes exist but the system to restore them have been replaced with newer technology. The tapes are kept offsite in a secure facility and will eventually be disposed of in a few years time, when the data retention requirements have been exceeded.

    So, is there a way to ring fence these backup tapes, so that it does not contravene the SAQ requirement of legacy CHD Storage in the environment, and ultimately be assessed with an SAQ-A and SAQ P2PE.


    • August 13, 2020 at 7:40 AM

      Thank you for your question Joe.

      This is not as unusual a problem as you think. A lot of organizations get caught in this dilemma as they dig ever deeper into their processes and procedures. It’s a lot like cleaning an attic. I am assuming by your “remediation” comment that they have cleaned up their act going forward and are now dealing with their sins from the past.

      First thing they need to do is to determine secure methods of dealing with this situation. If there are tapes that cannot ever be used, those should be securely destroyed as soon as possible.
      I am assuming that the remaining tapes are not encrypted so they must be accurately tracked and secured. Assuming those tapes are in a facility like Iron Mountain, that physical security should be sufficient. Then you will need to make sure that any request for these tapes being brought back is approved by at least two people, one being an executive (i.e., CFO, CIO). If brought back, the tape must be secured when not in use such as being stored in a safe or locking secure cabinet and any access to use the tapes are logged. Once done with their use, they should immediately be securely returned to the offsite storage facility.

      Once you have those procedures documented and in place, the organization needs to talk to their acquiring bank about this situation and determine how the bank wishes to deal with it. The organization will explain their approach and get the bank’s approval to continue or will implement any changes.

      You will also want to discuss how the bank wishes you to report the fact that there is storage of CHD until it is purged with the last tape that contains CHD. That will be a $64K question. I have had banks say to report it on an SAQ D (most of which is NA) to just notate that it exists in the company’s file and the date the condition will no longer exist. I cannot give you any guidance as to how the bank will approach that situation.

      Good luck!

  11. 32 Jane L
    July 19, 2020 at 2:28 PM

    First, I thank you for your site and for your ask the PCI Dream Team web casts – they are a great resource! I would love to hear your thoughts on how much of SAQ A applies when the “redirect” is to a hosted form such as those offered by merchant payment gateways NelNet (QuikPay) and (Simple Checkout). Both of these large payment processors offer customized forms that are “linked” to via a custom URL. The merchant sets up a custom form on the payment gateway, then includes a custom URL on their web site that redirects the customer to the payment gateway/custom form to make the purchase. The US Treasury has something similar they offer on The URLs are also sometimes included on a printed form, or sent to the customer in an email. These custom forms are typically used for single purchases, like a electronic bill, vs. filling a shopping cart with items then making a payment. These methods fall under SAQ A, but is it SAQ A as a fully hosted eCommerce solution (where only SAQ A requirements under 9 and 12 would apply to the merchant), or SAQ A (where requirements under 2, 6,and 8) also would apply to the merchant)? For example, many universities use QuikPay (a simple google search on “commerce_manager/” will return many examples) and may have hundreds of such links on their Web sites (which may be hosted by many different internal and 3rd party organizations). These merchants are under the impression they have no PCI responsibilities under SAQ A other than 9 (if applicable) and 12, but SAQ A specifically states it applies “to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.” Does this type of redirect (a link to a 3rd party payment processor) meet the definition of “redirect” in SAQ A? How is this any different than just redirecting the user to another eCommerce site altogether (e.g., to In one of your responses to a comment on you “of redirects and reposts-updated” article, you stated “Just because a Web site sends a user to another Web site and that Web site is an eCommerce site, does not mean that the original Web site needs to be PCI compliant. That would mean that the entire Internet would need to be PCI compliant and we all know that will never happen.” I would appreciate any thought you might have.

    • July 20, 2020 at 9:08 AM

      “but is it SAQ A as a fully hosted eCommerce solution (where only SAQ A requirements under 9 and 12 would apply to the merchant), or SAQ A (where requirements under 2, 6,and 8) also would apply to the merchant)?”

      I would refer you to the SAQ A criteria documented on page iii. I would also refer you to the PCI SSC FAQs with a search for ‘SAQ A’. All of this information can answer your question.

      “These merchants are under the impression they have no PCI responsibilities under SAQ A other than 9 (if applicable) and 12, but SAQ A specifically states it applies “to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.” Does this type of redirect (a link to a 3rd party payment processor) meet the definition of “redirect” in SAQ A?”

      It all depends on how the redirect or iFrame are implemented. Again, some of the aforementioned FAQs on SAQ A address your question.

      Your merchants my be correct about their scope regarding SAQ A but this is all contingent on how the data does or does not flow through their Web site. That said, as I have pointed out many times, while an organization complies with SAQ A, that does not ensure they are secure. Should a bad actor change the redirect or iFrame invocation, that error will be on the merchant, NOT the service provider or their bank. So people need to look beyond just being compliant because that does NOT remove or mitigate their risks.

  12. 34 Wayne G
    June 22, 2020 at 4:20 PM

    Hey PCIGuru, first of thank you for this amazing page and thread. The info from your answers here are very helpful.
    We have a web application that we are adding credit card payment functionality to with a partner who handles the full CC transaction. We don’t store or process anything but use Checkout.js to tokenize the transaction with our payment partner. We are under SAQ-A-EP.

    I have a couple of questions regarding inactivity timeout (specifically 8.1.8) “If a session has been idle for more than 15 minutes, are users required to re-authenticate to re-activate the terminal or session”
    Given the industry and the way our application is used we are trying to come with a different solution. One idea is rather then log the user out of the system completely after 15min, would be to make them authenticate again when accessing the CC payment/management area then log them out of that portion of the application that deals with CC payments after 15min of inactivity. Would that be acceptable or is there an easier method like a cookie timeout?
    Second question, I’m a bit baffled that many SAAS admin consoles I use on a daily basis such as Office 365 and Atlassian don’t seem to log you out after 15min of inactivity, it made me question my interpretation and I was wondering how they get away with that?

    • June 23, 2020 at 8:20 AM

      Requirement 8.1.8 applies to people you control such as employees, contractors, third parties, etc. that have access to systems and devices in the CDE. Not consumers that are shopping on your site.

      That said, if someone was paying for something and got side tracked and did not complete payment, I would like to think you or your processor would step in and deactivate the consumer’s session after 15 minutes or less.

  13. 37 BJ
    June 17, 2020 at 12:05 PM

    Any advice for someone looking to start a career in PCI compliance? There don’t seem to be a lot of resources and no certifications.

    • June 17, 2020 at 1:07 PM

      You need an auditing (e.g., CISA, CPA) and a information security (e.g., CISSP, CISM) certification in order to get into the PCI game. The first certification offered by the PCI SSC is the PCIP. Once you meet the requirements for being a QSA or an ISA, you can then apply for that one. All of this is documented in the QSA and ISA guides on the PCI SSC Web site.

      • 39 Erik
        July 1, 2020 at 7:14 AM

        If you are working for a QSA company, you can become an Associate QSA (AQSA), without having the required certifications (although some security experience is needed). You will be able to work together with experienced QSAs on PCI DSS assessments.

        You can then get the required certifications as you gain more experience and eventually upgrade to full QSA status.

        I think that’s a good way to start.

  14. 41 Deepa
    June 16, 2020 at 5:32 AM

    Hi PCI Guru,
    For any pentest findings that cannot be addressed or if it takes more than 3 months to address the finding, can we mark requirement 11.3 to retest the exploitable vulnerabilities as compliant and go ahead as compliant considering there is a plan to address the finding and retest is done for other findings.

    Also, can the high and medium findings be updated in the risk register as an accepted risk if there are no vendor support or outdated applications that has no compensating controls.
    Or is it mandate to address all high and medium exploitable vulnerabilities before calling it compliant.
    Thanks for your support.

    • June 16, 2020 at 7:54 AM

      Any pen testing issue discovered and cannot be remediated by patching or updating software MUST BE mitigated by other controls such as additional logging and additional monitoring. You will also have to document this all in a compensating control worksheet (CCW).

      You can NEVER, EVER mark anything as ‘In Place’ if it is NOT in place. If you have a plan to address the situation, great, BUT, you must mitigate the issue while that plan is executed. That will result in you creating a CCW.

      High risks can never just be “accepted” by management regardless of the situation. Use of outdated applications that have vulnerabilities depends on a number of factors. The first factor is if your bank or the card brands will accept you operating with such a situation. The second factor will be how well you can mitigate the risks presented by the outdated application. I have seen situations where this can be accomplished, however it makes managing the application nearly impossible and and very expensive because it is not easy.

      If you read 6.2.b, it requires that all applicable vendor patches be applied within an appropriate time frame such as 90 days. So the idea that you never need to address low and medium vulnerabilities is false. While the Council gives you wiggle room here, you still MUST mitigate any vulnerability that remains unpatched until it is patched. So just because you have time, does not mean your work is done.

  15. 44 Marc Jones
    June 15, 2020 at 9:27 AM

    Hi Guru – on the PCI website, it lists our current version of a PA-DSS application as being acceptable for pre-existing deployments only and the version expired 10/29/2019. The next version is for new deployments and expires 10/19/2022.

    Are we compliant if we keep using the expired version? The reason I ask is because the PCI website also states it does not require a revalidation of an expired version – ???? Clear as mud to me.

    Thanks for all you do.

    • June 15, 2020 at 10:09 AM

      Yep, clear as mud alright. From a PCI perspective, you can technically be PCI compliant using an expired PA-DSS application as there is no rule against that. You might have to write a few compensating controls though for lack of patching or any risks that old application presents.

      However, if you accept Visa or MasterCard payment cards though, using a PA-DSS validated application with an expired validation date is not allowed per their rules. Go out to and scroll down to the Payment Applications section and read the Security Mandates document from 2007.

  16. 46 Deepak
    June 10, 2020 at 5:17 PM

    Hi PCI Guru, if the application is hosted in AWS and admin access to application is managed by enterprise AD in a local data center, to what extent should the pci controls be enforced on enterprise AD.
    Is it required to be behind a firewall and firewall review done in addition to hardening, logging, patching, MFA for administration of AD, Antivirus, physical security of data center and supporting info security policies for AD.
    Is it a overkill to mandate all this for only the Active directory that’s not in AWS but local data center n hence increasing the scope. Thanks.

    • June 11, 2020 at 2:25 PM

      Based on what you are saying, AD can effect the security of the CDE so it is in-scope for compliance. That is PCI Scoping 101. That is true for any directory services that controls access to the CDE.

      The CDE will have it’s own firewall, so that can be used for segmentation of AD from the CDE. That said, best practice is to ensure that your directory services are isolated away from the rest of your network so that you can monitor them as control who has access to administer them.

      Seriously, AD runs on Windows. Granted, you must actually turn things off when putting up a domain controller to mess up its security, but I have seen it done.

      All of your AD servers are ALWAYS in scope when it is used to manage access regardless of where it is located. You may think it is “overkill” but AD is critical to controlling your CDE.

      • 48 Deepak
        June 11, 2020 at 4:05 PM

        Thank you PCI Guru, having said that should the firewall isolating the the AD in the datacenter be reviewed every 6 months as well in addition to to firewall of CDE in AWS.Thanks.

      • June 13, 2020 at 5:49 AM

        Since AD is in scope for the PCI assessment, the firewall is also in scope and therefore its rule set must be reviewed every six months.

  17. 50 Dale
    June 9, 2020 at 3:48 PM

    Hi, is expired credit card information in pci scope? Thanks

  18. 53 Deepak
    June 4, 2020 at 1:40 AM

    Hi, Has anyone worked with Pivotal cloud foundry ( PCF)
    It’s a SAAS that’s bought by our company and currently deployed on Cloud ( AWS ) and there are 100 plus application managed by the our cloud infrastructure team in the PCF currently.
    My team has developed an application and hosted it in PCF managed by our cloud infrastructure team.
    Is there a way they can get PCI compliant.
    There is one possibility to make the cloud infrastructure team as an internal service provider and get a SAQ D signed as a shared hosting provider.
    But if they are not compliant, how do we handle this.
    Its an SAQ A- EP thats applicable to us.Thanks.

  19. 57 Nicole S
    May 27, 2020 at 7:17 AM

    Are there any requirements on what has to be said/disclosed to a customer before accepting a credit card payment over the phone using third party ton encryption? (Like NACHA has for one time debit of a bank account).

  20. 59 Sebastian Nielsen
    May 27, 2020 at 5:57 AM

    About password security, requirement 8.1.6 and 8.1.7.

    Can a corporation, implement a cooldown of 5 minutes to each incorrect authentication (even on first invalid try), to fullfill this requirement?

    Since if a cooldown of 5 minutes is implemented, the total lockdown time, would be 30 minutes (6 attempts * 5 = 30) – which means the time a person cracking passwords have to wait per password, is the same.
    Is this then be considered a compensating control, or does such a solution directly fulfill the requirement?

    Same with solutions that lockout for 15 minutes after 3 invalid retries (which also sum up to 30 for 6 retries)


    Also “Access attempt”, what is that? Is this all attempts to access a resource, or is it permissible to filter out totally invalid attempts (like authentication attempts with a invalid CAPTCHA response, or authentication attempts that lack a correct device password/pre-shared key – where the device password/key is used to filter out totally invalid authentication attempts by invalid devices)?

    Ergo, if a user attempts to authenticate 6 times with a invalid CAPTCHA response, must a lockout occur then – even if a valid password would never have been accepted due to the invalid CAPTCHA response, or is it permissible to ignore such “invalid” authentication attempts (ergo, not count them towards the lockout limit)?


    Also 8.1.8 – what does this mean in effective? Is it enough to invalidate a session on the server in for example a web app (which means that if a user has sensitive information loaded on screen, it will still be visible on screen after session timeout – but if the user tries to do anything or refresh the page, user will be considered logged out) OR does this requirement mean that the web app must contain tecnology like javascript, that forcefully blanks the screen and navigates the user away from the page once the session timeout is reached?

    • June 10, 2020 at 10:39 AM

      The bottom line is that if you are not meeting the requirement exactly, then you need to write up a compensating control worksheet that explains how your approach till meets the intent and rigor of the requirement.

      An access attempt is an attempt to logon to a device regardless of the logon mechanism. So in your example, if a CAPTCHA is being used and they mess it up six times, yes, you must lock them out.

      While 8.1.8 does not specify it, it is assumed that being forced to log out would clear anything on the display and would toss the user back to a logon page.

      • 61 Sebastian Nielsen
        June 10, 2020 at 3:02 PM

        So basically, OpenVPN’s solution with a “Static key” to filter out for example port scans and bots cracking passwords, are prohibited then? Since with a invalid “Static key”, you can’t even decrypt the packet and see which user account the access attempt was on.

        The whole idea of a pre-authentication step or for example captcha logins and such is just to filter out invalid packets in such a way so accounts are not locked out for automated port scans and vulnerability scans and such things that happen automatically on the internet (ergo packets randomly aimed at random IPs like with “root/root” as username/password attempt), but only for real authentication attempts made by someone that is really attempting to get in.

        The basics behind a pre-authentication step, is not to give any extra security, but just act as a “first fence” that anyone attempting to break in, must break before any alarms/lockouts and such are triggered, to avoid nuisance alarms and nuisance lockouts.

      • June 11, 2020 at 2:41 PM

        I have no idea as to what OpenVPN’s static key has to do with any of this discussion. It is the key used to start the encryption of the VPN and not an authentication credential. This is no different from how TLS works with HTTPS.

        A port scan should NEVER, EVER cause an account lockout. Period, full stop! If it did, then someone really screwed up the authentication process.

        Bots or vulnerability scanners attempting to log into a system should ALWAYS lock an account. Otherwise they can brute force it which is the whole point of the controls for locking accounts for the number of attempts and length of time. I know you are going to point out that this will result in a denial of service, but that is the whole point of why such attacks are a problem. But if you do not take that approach you have no way to protect your system from compromise.

        I’m not exactly sure how you are using CAPTCHA for “pre-authentication” but it sounds like it’s a pointless exercise. Typically CAPTCHA is used in conjunction with user identifier to prove a human is logging on and not a machine and then a password is requested.

  21. 63 Muhammad Imran
    May 14, 2020 at 2:48 PM

    Our current application provider is a PCI level 1 service provider. The PIN PADs are not connected with the PC at all and we have a dedicated IP/DSL modem network for them.

    But now we are planning to integrate the PIN PAD with the SaaS application so that a transaction ID can be shared (no PAN data will be exchanged with the application running on the PC. This integration will be via a USB connection between PIN PAD and PC. PIN PAD ethernet connection to the payment processor will still stay the same (completed isolated network).

    Considering this situation, do you think the PC which is connected with PIN PAD via USB will come under the PCI scope. Even though no PAN data is exchanged on the USB link.

    Our application provider says, as per their PCI certification, a PC connected via USB will not be considered under the scope.

    I need your valuable input on this.

    • May 14, 2020 at 3:27 PM

      Connecting the PIN pad (aka POI) to the PC should not bring the PC into scope based on your description.

      However, you will need to document that fact with a test that shows the information exchanged with the PC and POI. That is fairly easy to do using Wireshark on a test PC along with USBPcap installed (assuming you are on Windows) to capture that traffic. Once you have the solution installed in your test environment, install Wireshark with USBPcap and run transactions and capture the USB traffic to prove that only dollar amounts, approval/decline and other non-CHD/SAD information is not in that data flow.

      If you are using Linux, you just need to configure libpcap to capture the USB traffic for Wireshark.

      Whenever you do an application update/upgrade, you should rerun this USB capture test to ensure that CHD/SAD does not accidentally start flowing. It should not flow to the PC, but I have seen instances where vendors mess up and it does flow.

  22. 65 Steven
    April 24, 2020 at 11:33 AM

    Hi Guru

    Appreciate all your effort in keeping this site up!

    Just a quick question here on failed ASV scan. We’ve told our client that they MUST have 4 quarterly passed ASV to consider PCI compliant.However, they pointed out FAQ 1152 from PCISSC – Can an entity be PCI DSS compliant if they have performed quarterly scans, but do not have four “passing” scans?”

    It essentially states that entities that have failed scans MAY be considered to be compliant if the 4 criteria listed in the FAQ were met. While we may not agree to this, I would like to have your opinion as this FAQ is from PCISSC.

    a) Can entities with lets say 2 quarters failed and 2 quarters passed (example) can still be considered PCI-DSS compliant if they fulfill the requirements stated in this FAQ (those in bullet points)?

    b) And if there is a really “risk-based” approach to accepting failed ASVs, who should be assessing this risk? It seems to imply its the QSA (not the ASV), because it would essentially be assessing the risk of “Accepting failed scan reports” in a compliant certification program. The ASV therefore would have already issued out these non compliant reports (and they cannot backdate them obviously), so its up to the QSA to decide? Seems like extra work for the QSA here and a sort of backdoor way for entities to pass with failed ASV scans!

    These entities are not requesting to pass, they just want to know if the QSA should be even considering a risk based approach? My opinion is that the QSA should just fail whoever that doesnt have all 4 quarter clean ASV scans and not think further, but this FAQ obviously suggests otherwise….

    Any thoughts on this?

    • April 24, 2020 at 2:21 PM

      The short answer is that if they have followed the FAQ and meet those four criteria then I would say that they have to be considered “compliant”.

      As you will recall, the ROC template has in the external scanning table in 5.1 that allows the QSA to document all of the ASV scans that were performed including rescans to obtain passing scans. So until you have passing scans from the ASV you do not have passing scans.

      That said, it is the fourth bullet that can catch QSAs, What they are implying there is that if the entity mitigates the risk, they can get a “passing” scan. Mitigation is also covered in the ASV Program Guide.

      • 67 Steven
        April 26, 2020 at 10:54 AM

        Thanks Guru, I would agree to that last point, where in the ASV program guide, it provides for a possibility to get Passing Scans through compensating controls etc. However, that needs to occur during the quarter of the scan itself before the release of the quarter report, I believe, since ASV scans are timebound. The problem occurs here (and I am sure you have been asked this before) – is that the entity already have, let’s say, 3 non compliant scans and now, working on their 4th quarter. The ASV will not be re-issuing previous quarters reports to be ‘compliant’ even if the 4th quarter is considered to be compliant. In fact, the ASV probably doesn’t have to be in the picture anymore, do they, since they have already issued the previous reports and there is certainly no way to change those past reports to be ‘compliant’ again.

        From the FAQ, it does sound that the QSA (not the ASV) should at the very least consider the 4 criteria before signing off the report for non-compliance, correct? At least that provides some sort of recourse (albeit very remote chance) for the entity to be able to be recertified even with failed ASV scans. But is this even part of the QSA’s scope of work to work out with their client to at least put options on the table on how the entity can possibly get recertified, given these non-compliant reports?

        Really appreciate all the input you have given!

      • April 29, 2020 at 2:22 PM

        In the end, I would write up a Compensating Control Worksheet to list off controls that mitigate the vulnerabilities that are causing the fail.

        I agree that if they are going to rely on the ASV to deal with the issue, they need to do that within 30 to 45 days of getting the scan so that the ASV can regrade the report.

  23. 69 Adam
    March 19, 2020 at 6:17 AM

    Hi, just found this extremely useful blog. Thanks for all you do.

    A question came up today in light of COVID-19: if we operate under the guidelines of SAQ C-VT (unrecorded phone calls and a network isolated computer entering details into a virtual terminal in a web browser), is there any compliant way of doing this while working remotely?

    Ordinarily, the network isolation requires the operative to be physically present at the PC running the virtual terminal. In the coming weeks, this may of course not be possible…!

  24. 72 Craig Gillespie
    March 2, 2020 at 2:50 PM

    Dear Mr. Guru,

    Thank you again for taking the time to work on this blog and answer our questions.

    My question today is about P2PE PIMs and movement of POI devices. As we are not a small organization, we do have multiple sites. But we also have a few specific receiving areas where we would receive (and send) deliveries from Fedex, USPS, and UPS. So we would have all of our POI devices arrive at one location and get checked into our asset management system. (of course all of the validations would take place at this point….). And they would be securely stored until they were needed. So my question comes to the requirements of “shippment” to the alternate sites. The PIMs I have seen all specify tamper evident packaging, and trackable shipments.

    Do you believe it would be an issue to use tamper evident packaging and then send it through interoffice mail? There isn’t any tracking number or tracking capability. I feel like the numbers on the packaging as well as a list of contents of each POI sent independently (e-mail) so the receiving location can validate everything, should be good enough.

    Or do I need to ship them between facilities via a trackable solution (Fedex, USPS, UPS….)?

    Thanks again,

    • March 3, 2020 at 1:30 PM

      As far as I am aware, once your organization is in receipt of the P2PE POI it is up to your organization to have policies, standards and procedures in place to ensure their security.

      The question comes down to the security of inter-office mail in your organization. If you feel it can be trusted with the POI then I would have no reason to believe you cannot use it. However, if they are notorious for loosing items, then that is probably not the way to ship them to your other facilities.

      Based on your proposal for sending an email separate from the POI, I think that is sufficient as long as the first question can be answered satisfactorily. I would add though that I would want a signature and name of the employee at the remote facility that received the POI so that you have that just in case something goes awry.

  25. 74 Jackson Smith
    February 26, 2020 at 5:42 PM

    How can Offline Card processing tools such as:
    be complaint?

    They claim by separating the card data you are safe.

    The CVV has to be saved somewhere, assuming it is sent in an email which generally results in getting save to a backup.

    Common sense will tell you that just because it’s in two separate locations does not mean you are not in possession of the full card information.

    • July 8, 2020 at 8:18 AM

      This is a scheme that was used back in the early days of eCommerce. What the solution does is store the first and last four of the PAN in a database and sends the middle 7-8 digits via email. The merchant then does a DB lookup and pairs the first/last four with the middle digits and then manually enters that PAN into their payment terminal. It is secure and is PCI compliant, but does not really do much for PCI scope reduction.

      What WooCommerce misses is that all of this occurs in their plugin on the merchant’s server meaning that the server is still in scope for SAQ A-EP. Add in that the payment might be keyed into a Web site and that brings any PCs or devices used to access that Web site into scope as well. So while it is better than nothing from a security standpoint, it does not do much for the merchant’s PCI compliance efforts.

  26. 76 gmanpmp
    February 17, 2020 at 8:11 AM

    We are a software service provider with a thin-client, non-browser-based PA-DSS application that runs in our clients’ locations. One of our clients would like to have us add support for SSO, likely SAML 2.0 so that their backoffice employees do not have to sign in to our application once they have already logged into the client’s system. These employees, with the correct admin permissions, can view individual PANs in support of chargeback investigations.

    In reviewing 8.2.x, I am not seeing how we can support this as we would be handing over credential creation and authentication to our client. Could this be allowed if the responsibility matrix and contracts put the responsibility on them? We are Level 1, they are level 3 and do an SAQ. Would we need to have our QSA review their practices so they meet our requirements as a Level 1 or should we require that they have a QSA/RoC assessment? Frankly, we would prefer not to do this, but this is not the first client to bring it up and we cannot find any clear opinions on this topic. There are several on using SSO for in-house, but little on external SSO.

    Thanks for reviewing this and all that you do for the community.

    • February 17, 2020 at 11:59 AM

      QSAs are encountering this situation more and more with SaaS and other outsourced applications.

      At the end of the day, it is up to your organization to mandate MFA if it is required regardless of how your user authenticates because you cannot always be certain if MFA was invoked when the actual user authenticated (some protocols can provide that, some cannot or will not). I advise my service providers to obviously use something free such as Google or Microsoft Authenticator as there is less push back to use a free service as opposed to Duo, YubiKey or RSA SecurID. But how you support MFA is up to your business to decide.

  27. 78 Paul Smith
    February 11, 2020 at 2:32 PM

    Hi PCIGuru
    I have questions about network segmentation.

    We have users that enter card data into an application that we host in our isolated datacenter. The connection is TLS encrypted. The server itself just passes the CC authorization to our processor and we just get back the token. We don’t store details on the server or PC’s.

    Most users are internal and are forced to a VLAN with our NAC. I have created ACL rules on the switch that isolates the VLAN.
    Does the ACL on the switch count as a segmented network?
    Or does that force the switch and all VLAN’s on it into scope?

    Also, we have some users who work from home and VPN in. We deny split tunneling on the VPN client so the home network is not accessible.
    Can I also set up a VLAN for the VPN users with ACL rules?
    Will the users home network then come into scope or be considered an “out of our control” network?


    • February 13, 2020 at 5:02 PM

      ACLs do NOT count as segmentation. Only firewalls count as you need the rule AND monitoring of the traffic for abuse.

      The switch and any other network infrastructure with that VLAN or connectivity to the VLAN are in scope.

      Restricting the split tunneling will keep the home network out of scope. However, you still need a firewall not just ACLs.

      • 80 Paul Smith
        February 14, 2020 at 2:29 AM

        Thanks for the reply. I am still trying to wrap my head around the details.It all seems very complex.

        So every site where we have users who enter CC info will require a dedicated firewall and switch for those users?

        Since the requirements need a firewall, how restrictive do the inbound ACLs to the CC users network need to be?

        i.e. – What happens with infrastructure systems that need to connect to those systems to interrogate them? Like our asset management, patching, EPP, EDR servers? Do they become in scope?

        I thought I saw somewhere that the firewall and switch would need to have their own dedicated VLANS for management. From your statement above, that puts the switch that the management ports are connected to in scope as well?

        I see this becoming an endless cascade of systems becoming in scope.

      • February 14, 2020 at 5:42 PM

        Not a dedicated firewall, just A firewall interface so that you not only control the traffic but you also have packet inspection and flow monitoring.

        I have a full set of posts under my Post Series References under Network Segmentation. I think those three posts will clarify what a QSA would look for.

        You need to read the Scoping and Network Segmentation information supplement – . But the short answer is those systems you discuss that you thought were out of scope are definitely in scope as “Connected To” systems.

        Having a separate management VLAN is nice but is not required. It just makes things easier to monitor and control. But yes, that also puts all of that infrastructure in scope as well. Which at the end of the day, most organization’s infrastructure is in scope because in scope VLANs traverse a lot of devices for a lot of reasons. That said, all of this can be sampled so it is not like all your switches, routers, firewalls, etc. will be reviewed unless you have terrible configuration standards or no standards at all.

  28. 82 mike
    January 27, 2020 at 8:54 AM

    Quick Question

    Does a system need to be in a logical DMZ if we are using a reverse proxy that is already in the DMZ and requires authentication? What is the spirit of the requirement? For example, is the requirement designed to restrict a compromised webserver from becoming a pivot point on the internet network, or is it to reduce the attack surface of the webserver itself?

    If we have a firewall or F5 device prompting for authentication before you can access the internal system from the Internet, does that meet the requirement?

    • February 7, 2020 at 5:16 PM

      You need to specify the requirements you are asking me to answer.

      • 84 Mike
        February 15, 2020 at 2:46 PM

        I am referring to requirement 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

        If the system is on the internal network and publicly accessible only through an F5 reverse proxy that lives in the DMZ. Does that meet the requirement or does the internal system need to move to the DMZ,.

      • February 16, 2020 at 2:45 PM

        I understand what you are saying but these systems still connect to the systems in the DMZ and could affect their security and the compromise of cardholder data (CHD). That reverse proxy is only working on their internet access, not access to the DMZ as you explain it. Please read the Information Supplement I recommended as it explains exactly what the Council is telling QSAs is in scope.

  29. 86 Robert
    January 16, 2020 at 10:47 AM

    For Req. 3.4.1, the requirement begins with “If disk encryption is used (rather than file- or column-level database encryption), …”. Does Oracle TDE and Microsoft SQL TDE constitute file-level database encryption? Or is it disk-level encryption? I’m talking whole database encryption using TDE and not column-level encryption using TDE.

    • January 16, 2020 at 2:18 PM

      TDE is file level or field/column level encryption. It is NOT whole disk or full disk encryption. Whole disk encryption (WDE) or Full Disk Encryption (FDE) is like BitLocker or VeraCrypt. WDE/FDE encrypt an entire disk or partition irrespective of files/folders/directories. WDE/FDE is only in force when a disk is NOT running.

  30. 88 Lloyd
    January 16, 2020 at 6:56 AM

    We have an ecommerce site, run by a third party, that uses a redirect method. From the eligibility criteria, this put us in scope for SAQ A.

    My question is around 12.10.1(a). Whose incident response plan should I be reviewing? Ours, as the merchant, the company’s running the site, or the payment service provider’s? As we are using redirect, and the card data never hits the third party’s systems, are they relevant for this point?

    • January 16, 2020 at 8:12 AM

      Your organization needs to have an incident response plan that coordinates with your third party’s incident response plan. This all assumes that the third party is PCI compliant and you have their Attestation Of Compliance (AOC) to prove that fact.

  31. 90 rlmx
    December 30, 2019 at 9:04 AM

    For requirement 1.2, I have heard several people suggest that personal firewalls on each end user end point (laptop, desktop pc) in the “cde” will suffice to meet the requirement. This doesn’t seem like a logical approach. It seems counter intuitive. Am I missing something?

    • December 31, 2019 at 11:38 AM

      It doesn’t seem right because it is NOT correct/accurate. In theory, it can work, but as I always point out, in theory, theory always works.

      The cardholder data environment (CDE) must be segmented from all other networks to reduce scope. A host-based firewall does not accomplish that logical network segmentation from a CDE standpoint. While a host-based firewall can do that from a point-to-point communication standpoint for a particular service, it becomes ever more onerous from an all services standpoint as services get missed and rules are not strict enough on every host-based firewall required. As a result, a system that is inside the CDE can be potentially compromised off of the common network if it is not segmented by a physical firewall. Then there is the penetration test that tests segmentation which a host-based firewall will likely not pass because some services will be available.

      The bottom line is that I have yet to see a host-based firewall approach segment the CDE and successfully pass a penetration test to prove out segmentation. This is why you see implementations of firewalls and jump servers used to gain access to the CDE to restrict and control access to the CDE therefore minimizing the ability to get data out of the CDE.

  32. 92 rlmx
    December 18, 2019 at 1:12 PM

    Square, Inc. does make devices that appear on the Approved PTS Devices list. And Square claims on their website, “Square takes care of PCI compliance for your business.” So the device is compliant. But Time Out, the PCI DSS covers PEOPLE, PROCESSES, and technologies. So if I hire a felon that was busted last week for stealing payment card info, and the felon has zero knowledge of a companies processes, according to Square, I’m all good if using a Square, Inc solution. Does that really all add up?

    • December 19, 2019 at 3:16 PM

      Nope! In your example, if the felon skims cards, Square is NOT going to help you with that regardless of their understanding of processes.

      Just so you know. Square serves as the merchant of record for all of its customers so Square is on the hook for any PCI related processing issues/breaches. But that does NOT indemnify the people that use the Square solution from their own fraud and misuse of cards.

  33. 94 Tony Autin
    October 18, 2019 at 12:46 PM

    Hi PCIGuru!

    I had a colleague that suggest I posted a situation I’m dealing with here. I figured I’ll give it a shot.

    My company is a service provider that offers a ecommerce store to our clients, this store allows them to configure the site such that they can resell their products and services on it. This ecommerce site does redirects to payment gateway hosted payment pages like cybersource, touchnet, cashnet, paypal, etc. We offer this solution as an on premise service for the customer, where they manage the server where the solution is hosted, and in the cloud where we manage the environment where the solution is hosted.

    I’ve worked with a QSA in the past, that told us that our scope was limited to the server that does the redirect, and with my reading of PCI-DSS, that was my interpretation as well. Thus, we have been completing SAQ-D SP with the scope only covering our infrastructure.

    We recently had a customer challenge the scope, in a situation where they host our application where the server performs the redirect, and felt that our application was also in scope. I pointed them to your article on redirects (, as well as information from our QSA. Their point being, that you could adjust the redirect URLs within our application, to change which payment gateway the customer would interact with. We do this because we integrate with many different hosted payment pages from payment gateways, and it allows the client to even change which payment gateway they will work with.

    While I agree that the URL configuration within the application should be considered within security and risk for the client, I wasn’t sure that spreading the scope was appropriate? I reengaged with my QSA company, who provided me with a different QSA, and they agreed with the client.

    Since then, I’ve started reassessing our SAQ-D SP to include scope for our application, and I have a message out to another QSA company for a second opinion.

    I’m okay with being wrong, as I have been before! I just want to make sure I’m doing the “right thing” by considering our application in scope for PCI.

    Thanks ahead of time!

    • October 21, 2019 at 4:13 PM

      So, a few comments.

      The easiest first is that I agree with you that ability for your organization to change the URL for the redirect puts that “service” into PCI scope because you are entering your customers’ cardholder data environment (CDE). So whatever infrastructure at your end is used to effect that URL change is also part of your SP assessment because you are going into your customers’ CDE to make that change and you are definitely effecting their processing of payments during that effort.

      If you want to change that scope to take your organization out, you would need to allow a customer to make the change to one of the many payment processors you support. IMVHO, that would be a great enhancement to get into your application.

  34. 96 Kelsang Kalden
    October 11, 2019 at 2:08 PM

    How long does a nonprofit religious organization need to keep merchant receipts?

    • October 21, 2019 at 4:20 PM

      This is not really a PCI question and I would recommend that you talk to your bank as to what they think you should do. That said, it depends on the card brand but most merchants can safely get rid of receipts within 90 to 120 days. That is based on a 90 day dispute period for most card brands remembering that the dispute could be filed to the bank/brand on day 91.

  35. 98 Chris
    October 4, 2019 at 8:31 AM

    Hi PCI Guru, can you confirm if i can use a PDQ device to take payments over the phone i.e card not present transactions.
    For some reason I have an inkling that you can’t but I’m unable to locate it directly in the PCI DSS guidance or any FAQ’s

    • October 5, 2019 at 2:39 PM

      What type of process data quickly (PDQ) are you talking about? I am assuming you are talking about a card terminal or point of interaction (POI) in the vernacular of PCI. But I need to confirm that fact before I can answer correctly.

      • 100 Chris
        October 9, 2019 at 3:36 PM

        Hi PCIGuru,
        Yes I’m referring to a physical PED which would connect either via a separate phone line or 3G connection.

      • 101 Chris
        October 11, 2019 at 3:06 AM

        Hi PCIGuru,
        I’m referring to a card terminal (PED) which would connect via a separate phone line or 3G

      • October 22, 2019 at 2:45 PM

        If the point of interaction (POI) has a keypad, then yes you can use it. But if you are expecting to use it to reduce scope, that will depend on if the POI is using a P2PE/E2EE solution between the POI and the processor.

  36. 103 Patrick Morris
    September 3, 2019 at 2:09 PM

    Long time listener, first time caller. I could use a second opinion if you get the time and/or inclination. We use SAQ A at my company, since all card processing and storage is handled by third parties. However, there are the relatively new patching requirements in SAQ A which seem to apply to “system components.” Given our lack of a CDE, I’m reading that as any machine on the production network that is used to communicate with the payment processor.

    • September 6, 2019 at 11:15 AM

      That was how it was explained to the QSAs when the changes were introduced. If something has the ability to “influence” the payment process, then it needs to be considered.

  37. August 23, 2019 at 6:01 PM

    Hi PCI Guru,
    My question is re a mobile app in scope for PCI. An exploitable vulnerability is showing from the Pen test for mobile manifest reference external storage – the code allows authenticated users to download (or export) a *.pdf, thru the mobile app, without any further validation required. The SP is stating they will accept the risk. Can the QSA mark them in place for 11.3.3 without documenting an in place compensating control?

    • August 24, 2019 at 11:04 AM

      Good question for your QSA as they are the one that has to make that determination. I would get the Service Provider’s risk acceptance of the vulnrability in writing though so the QSA has that to reference and keep in their work papers.

  38. 107 DN
    August 1, 2019 at 8:05 AM

    Hi There,

    We are going through an RFP and have asked our bidders to provide proof of recent annual PCI DSS compliance to Service Provider Level 2. We have received a number of responses, but the one that struck us the most was a link to the Visa Service Provider page showing that they are on the Visa list. I am not inclined to accept this as meeting the requirement, but I want to confirm if my initial response is correct. If they are on the list, is there anything in the report that we should look at or consider?


    • August 1, 2019 at 9:09 AM

      First and foremost, any service provider providing PCI compliant services must have done an PCI assessment. That will either result in a Service Provider Report On Compliance (ROC) or a Service Provider SAQ D as well as the mandatory Attestation Of Compliance (AOC) from either. So, your requirement of Service Provider Level 2 is a given and moot. You should only ask if they have a current PCI Service Provider assessment, provide their current AOC and leave it at that.

      If they are on the Visa or MasterCard Global Service Provider lists, they must have submitted a fully compliant ROC to the card brand to appear on that list (regardless of their service provider level). From at least Visa’s site, you would know what services were assessed as well as when they were assessed and when they need to be reassessed. Those global lists should be your initial source of service providers that can provide you services, but provide nothing more than that. However, just because a service provider is not on those lists does not mean they have not PCI assessed, just that they are not willing to pay the brands the big dollars required to be listed.

      That said, any RFP due diligence process should always obtain the vendor’s Attestation Of Compliance (AOC) to confirm that all of the services being proposed for your organization have been assessed (the brand sites do not always best represent what services were actually assessed). The AOC will also document what your organization’s responsibilities will be using the service provider’s services so that you can evaluate how much work will be required on your end.

  39. July 24, 2019 at 4:15 PM

    If a point of sale software is using EMV hardware with end-to-end encryption to an external payment host, would the requirement of strong, regularly changed passwords be required for access to the POS, since no card information can be gleaned through it? The merchant account information is stored (encrypted, of course) in the POS database, but PCI is mostly concerned with the ability to retrieve PAN and SAD instead of the merchant configuration, right?


    • July 26, 2019 at 7:59 AM

      Your description implies that the POS workstation is “connected to” the POS database which has encrypted PAN. Connected to systems are still in scope for PCI compliance, so the POS workstation would have to meet all of the relevant PCI requirements.

      Another item that would have to be clarified is how the end-to-end encryption (E2EE) is implemented. I have encountered too many E2EE solutions where the last 6″ between the POS workstation and the point of interaction (POI) are NOT encrypted and the workstation is the actual endpoint. I am assuming that the POI is the E2EE endpoint.

      The only caveat to all of this is if the encryption keys for the data are held and managed by an outside third party AND the encrypted data cannot be decrypted by the POS application or any merchant employees. If that is the case, then the POS workstation and the POS database are out of scope and then only the POI are in scope.

      • July 26, 2019 at 9:08 AM

        The card info is encrypted on the POI and not decrypted until it reaches the external payment processing host, so neither the POS nor computers can be aware of PAN. The POS has no knowledge of the encryption keys.

        I was just asking if the merchant account info — the credentials used to process cards on the external payment processing host — is considered sensitive information if no PAN can be obtained using it.


      • July 27, 2019 at 6:43 PM

        Those areas of clarification were needed in order to answer your question. At the POS, the credentials do not matter. However, the credentials that log into the processor’s or bank’s systems must comply with the PCI DSS requirements in section 8.

  40. 113 Gabriel
    July 18, 2019 at 7:01 AM

    Hey Guru! I got stucked with an existencial question regarding PAN transmitted over public networks. Am I mistaken by stating that once you encrypted the channel by using secure and appoved methods (such us TLS 1.2) you do not need to encrypt the CHD transferred within such channel?
    I always recommend to encrypt the information as well as the channel since it provides a proper layer of security regarding the Data by itself but is such thing mandated by any requirement?
    I found requirement 4.1 to be a bit ambiguos cause is says “Secure transmission of cardholder data requires using trusted keys/certificates, a secure protocol for transport, and proper encryption strength to encrypt cardholder data” which would confirm that Data must be encrypted as well but inmediatelly below it says “Connection requests from systems that do not support the required encryption strength, and that would result in an insecure connection, should not be accepted” which explicitly references to connections (channel) and not data.

    What id your opinion on such thing?

    Thanks in advance for your always helpful advice!

    • July 18, 2019 at 7:27 AM

      Unfortunately, you are correct. As stupid as it sounds, that is exactly the interpretation. As long as something is encrypted, it is considered protected whether that is the communications channel, the data, or both. Obviously the best practice is to encrypt the data and then also encrypt the communication channel. However, the DSS only requires one or the other.

  41. 115 Bryan Carter
    July 9, 2019 at 3:45 PM

    Thanks for your willingness to help us all with PCI!

    I am an ISA for a retail company (company A) and have been doing their PCI AOCs for several years. Many years ago, they purchased a competing company (company B), but have always maintained segregation between the two (separate networks, separate names, separate employees, etc). Each company has continued to file their own PCI SAQs, and the scopes have never combined.

    It is now the desire of the Company A to eliminate the Active Directory of the Company B, and host those user accounts in the AD of company A.

    What are the ramifications to each of the companies if they share the same AD? Does Company A then become a service provider to Company B? Can Company B just accept Company A’s AOC when it does it’s own SAQ? What would have to be done in AD to keep them separated in scope?


    • July 10, 2019 at 8:57 AM

      How you handle the single AD environment is up to your company to deal with because it is all within the same company. So the idea of one division being a service provider to another is not the way the PCI SSC defines a service provider. Technically, company A & B are all one big “family” under a holding company of some sort, so how you report and treat things are an internal matter as long as your acquiring bank(s) agree which I assume they have since you did not mention them being involved.

      I have had clients assess common infrastructure services such as AD, DNS, NTP, DHCP, etc. and then give that assessment evidence and write ups to fill out the individual ROCs/SAQs as you complete your assessments currently.

      I have also had clients do a Service Provider ROC of common services and then issue an AOC for those services for their other divisions to do their individual PCI reporting.

      Whatever makes sense for your organization should be workable as long as nothing gets missed. That is where things go sideways is when one group thought the other group was covering a given area and it turned out no one was covering the area. I have seen that happen way to many times. This is particularly true where there are shared responsibilities. For example, if your individual companies manage their own user base in that shared AD environment then the user management needs to be assessed individually and not as a shared responsibility unless is is centrally managed.

  42. 118 FredR
    July 9, 2019 at 10:03 AM

    Hi PCI Guru, what happens when a POI device’s certification has expired? Does it mean it is no longer compliant or usable? We have some models that expire next year. thanks in advance for your guidance.

    • July 9, 2019 at 12:42 PM

      Once a point of interaction (POI) certification expires it is supposed to be replaced by a POI that is certified as compliant. Hence the whole point of a certification expiration date.

  43. 120 Mark Stevenson
    July 5, 2019 at 12:02 PM

    Hi PCIGuru, In PCI 3.2.1 a question regarding VDI devices in CAT 2 directly processing payments. Should the VDI be in CAT 1 behind the PCI firewall or does it make them CAT1 ? what is the implication of VDI’s in CAT 2 directly showing and processing payments in applications directly to the CDE?

    • July 7, 2019 at 8:16 AM

      If a virtual desktop (VDI) is processing card payments, then it is part of the cardholder data environment (CDE) or Category 1. There is no other way to look at such a VDI because it is directly processing payments. Any device that connects to that CDE VDI is a shared services or Category 2 device. As a result, the VDI needs to be considered a CDE and be firewalled accordingly.

      Showing CHD through a VDI is a real discussion. Most VDI use rasterized display, so there are arguments about whether the display puts the Cat 2 device into scope. IMVHO, the organization needs to determine the risk and be willing to accept that risk of VDI display.

      That said, if a workstation is used to connect to a VDI and then is used to directly process payments such as keying PAN though the workstation keyboard or using VoIP softphone to hear PAN, the workstation AND the VDI are part of the CDE and need to be treated accordingly.

  44. June 24, 2019 at 7:16 AM

    Dear PCI Guru

    Regarding control 8.1.5

    a) Are accounts used by vendors to access, support, or maintain system components via remote access enabled only during the time period needed and disabled when not in use?

    (b) Are vendor remote access accounts monitored when in use?

    We have a supplier who has monitors running to monitor databases which sends alerts to them if it detects any issues. The suppliers would like to remotely login and fix them as they find them. Currently all our suppliers accounts are disabled and only enabled when it is needed. In this case it is OK during businesss hours but during out of hours there will be nobody around to enable the accounts. They are saying can you make a exception for them otherwise they cannot meet SLA etc.. What do people normally do with this situation with regards to PCI? Can we meet the requirements with exceptions?

    • June 28, 2019 at 2:33 PM

      I have a lot of clients with third parties that monitor SANs, firewalls, routers, etc. However, when it comes to fixing issues, there must be a ticket generated and then access granted. If that means waking someone up at 2AM to get that access, then that is what needs to happen. You can try to meet things with compensating controls, but at the end of the day, you will find that even more complicated and messy than just doing what you should be doing whether the people are outside or inside your organization.

  45. 124 Dan
    June 18, 2019 at 11:28 PM

    Hey PCIGuru,

    I’m interested to hear your opinion on pay now email links such as squares invoice solution? We have a department sending these links on mass to customers. Do you see any PCI onus on these people for sending email links telling people to enter their card details on a website?

    • June 19, 2019 at 5:58 AM

      Other than the threat that these emails become so SOP and the “bad guys” begin spoofing them? It just means to me that organizations need to step up their security awareness programs so companies do not lose too much money.

  46. 126 S
    June 14, 2019 at 2:33 AM

    How often are level 2 merchants required to complete an attestation of compliance for self-assessment questionnaire?

  47. 128 Marc Jones
    June 13, 2019 at 8:08 PM

    If a payment application is PA-DSS compliant does that mean it is complying with FACTA regulations?

  48. June 13, 2019 at 2:31 AM

    I have a question about Pan Key Entry (PKE) in store. My understanding is that it is frowned upon as it leaves the Merchant exposed regarding chargebacks i.e. the liability shifts to the merchant and also encourages fraudulent behavior. However a potential client told me that they would not allow PKE for PCI reasons. Does PCI regulations restrict typical PKE?

  49. 132 Syed Naqvi
    June 12, 2019 at 7:59 AM

    Dear PCI Guru,
    If any organization only processing banking (deposits, withdrawals and balance enquirers) transactions would we need to be PCI compliant?

    • June 17, 2019 at 12:55 PM

      Where banks come into scope is if they are a card issuer or an acquirer of card transactions. In the US, UK and EU that is most banks. However, in other countries that is not the case, so it depends on your location and banking laws.

  50. 134 Luigi Figueroa
    May 31, 2019 at 3:38 PM

    Hi PCI Guru,
    I am going over a vendor’s AOC (done by a 3rd party QSA) and this vendor states that they sell card data capture devices which, they argue, not a POS but a Mobile POS. They go on stating that PCI doesn’t have this option segregated so the auditor they used had no way of clarifying it in the scope.
    Wouldn’t that still be considered in scope and would have to still be assessed?

    Thanks for your help!

  51. 136 jmroehrich
    May 22, 2019 at 9:08 AM

    What SAQ would a merchant use that only manually enters credit card numbers into a website for processing? I see SAQ C mentions payment application connected to the Internet but I’m not clear what this includes. Does this just refer to a POS system and not apply to manually keying into a website account? This merchant would not qualify for C-VT due to them using their computers for other purposes besides credit card entry.

    • May 22, 2019 at 3:12 PM

      First and foremost, this is only my opinion. The only entity that can provide a decision is an organization’s acquiring bank.

      That said, SAQ C was developed for the fast food or similar industries where they have a POS system on a network that sends transactions to a processor. So I would say that is not relevant to your situation described.

      In order to use C-VT, the workstation can only be used for the purpose of data entry of SAD/CHD and nothing else. That said, I have found that most banks point organizations to C-VT even when those workstations are used for other activities within the organization as long as they are firewalled (host-based or network-based) and monitored.

      Again, you need to get a written decision from the acquiring bank for an official ruling.

  52. May 14, 2019 at 10:27 AM

    Hi, if I set-up a card reader that supports chip and pin, contactless cards and Google Pay/Apple Pay, does a staff member need to be present when it’s used by a customer ?

    • May 21, 2019 at 5:15 AM

      They should be, but it is not mandatory as far as I am aware. That said, an unattended point of interaction (POI) should be looked at periodically during operation to ensure that it has not been tampered with since it is not always attended.

  53. May 1, 2019 at 6:56 AM

    I’ve been dealing with PCI DSS with a level 1 merchant for many years. I’ve recently switched to a level 2/3 merchant (depending on payment brand criteria), and am confused about the validation process

    Basically, we have multiple merchant accounts with several different processors.
    We are processing (and have merchant id’s with) Bluefin, Clover, and a couple others.

    I was filling out a “Rapid Comply” with Clover and when asked questions regarding which SAQ – I selected the SAQ that pertained to the entire environment. However, Clover has informed me that I only need the SAQ relevant for that merchant ID.

    So, with Clover, I need to file an SAQ C-VT while may environment really should be an SAQ Merchant-D.

    Does that sound accurate? If so, I see that as a potential risk as I could technically be compliant with one processor, and not compliant (or secure) with another processor.

    This is really disappointing and I feel like the jump from Level 1 to Level 2 and below is a joke.

    • May 1, 2019 at 4:50 PM

      This is the problem with these “automated” solutions. Merchant levels are set by the number of transactions processed by card brand across all merchant identifiers (MID). At least that is the rule but it is not always enforced as it should. Technically, if you are a Level 2 merchant, MasterCard’s Security program (SDP) requires that you conduct a ROC with either a QSA or an ISA. Check out their Merchant Web site page for that guidance.

      • May 2, 2019 at 5:48 AM

        Thanks for the reply.

        So, Merchant Level is determined by combined # of transactions across all MID’s (and payment channels). Does that mean when completing an SAQ through one of the automated solutions – I do it in the context of that specific solution or my entire environment regardless of who issued the MID.

        I ask because that’s what I did. I was completed an SAQ Merchant D through an automated solution with Clover and Trustwave. However, I was told by support at Trustwave that I only needed the SAQ P2PE because the Clover was a P2PE device. I explained to him that I processed cards outside of the Clover device, but he was insisted that it didn’t apply.

        Question and Options :

        1. Would I be taking the correct action by completing a single SAQ (Merchant D) as an ISA, and submitting to all required processors/merchant banks instead of completing an SAQ per processor/merchant bank in the context of their specific solution,

        2. Complete an SAQ through 6 different automated solutions in the context of that specific solution. Which doesn’t seem correct to me as PCI covers the entire environment – not just a single solutions

      • May 8, 2019 at 9:19 AM

        To answer your point #2. This is the problem with those automated SAQ filing solutions. They only deal with the solution that you are filing for, in your case your Clover implementation. Any other payment channel is assumed to be separate filing. It is not correct from what the PCI SSC teaches, but the banks and card brands let these providers of these solutions get away with it under, I am sure, the rationale that some sort of filing is better than nothing.

        As to your point #1. You could take that approach, but your acquiring bank might force you back to the automated filing solution. That said, you do NOT have to be an ISA to fill out and file an SAQ.

  54. 144 Marc Jones
    April 25, 2019 at 10:30 AM

    Can you weigh in on this as a valid Compensating Contol for 2.3 and 11.2.1 – we have web app that does not store cc (only hashed version). W have a new cloud provider and we’re failing internal scans because we’re using RDP over VPN w/2FA to support our Windows Servers (2.3 CC). Even though we have High findings, our management response is we are willing to downgrade this internal risk to medium because we believe this is contained and we are categorizing based on our risk strategy and not the CVE. We enable 3389 for internal use only, not external. We’re goung to fix this within the next quarter but we need our AOC now and are going to run it by our QSA for approval. Thanks

    • April 26, 2019 at 11:54 AM

      Your statement “Even though we have High findings …” seems to imply that the RDP issue is not the only scanning results issue you have.

      That said, I’m not sure why you did not implement RDP with only high encryption connections allowed which is the only way it should be implemented. Next, I’m confused if you are using a VPN connect why RDP is even exposed to the scan.

      I think you might have enough controls available to develop a compensating control worksheet for getting through your current assessment. But I’d need a LOT more specifics on those controls before I could completely weigh in on if they were adequate.

  55. April 5, 2019 at 9:02 AM

    PCI Guru –

    Here’s a situation that I would appreciate your comments on –

    Customer has an exchange server in the environment. Customer is using a shared-services model for services for in-scope and out-of-scope systems (authentication, mail, av, etc). No CHD or SAD in Exchange. Exchange is considered in-scope as systems that store, process or transmit CHD access exchange. Systems out-of-scope access exchange as well for mail. Systems accessing exchange (in-scope and out-of-scope) are locked down to necessary ports/protocols. Would you consider this compliant or does it have problems. I’m getting various opinions on this.

    Thanks in advance,


    • April 17, 2019 at 6:34 AM

      Exchange would be considered a Category 2 (shared services) system in that it is connected to systems in the CDE, but is not in the CDE. As to whether or not the situation is compliant is anyone’s guess and would be a huge discussion here as it requires an examination of firewall configurations, network diagrams, server configurations, etc. Not a simple activity.

  56. 148 Geiger Lee
    March 29, 2019 at 2:03 PM

    8.3.2 “Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network.”

    How does this apply to a merchant who needs third party support by a payment application vendor or external IT help that uses a WebEx remote control support model? Does the fact that the merchant has to allow access to the requester provide a compensating control in place of a MFA solution?

    • April 6, 2019 at 11:46 AM

      Any person or entity that accesses your network remotely needs to use multi-factor authentication (MFA). You can attempt to try to write a compensating control worksheet (CCW) for this situation, but in my very humble experience trying to do this for a few clients, it is easier to implement MFA.

  57. 150 Dan
    March 28, 2019 at 11:31 PM

    Hey PCI Guru,

    I’m reading the telephone guidance and all about demarcation points. We are trying to determine the scope for our call centers and we’ve come to a sticky situation. The guidance states that your telecommunications provider is generally considered out of scope and that your scope begins when it is your equipment, problem is that we are the telecommunications provider. The whole network from caller to contact center is probably us, where is the demarcation point?

    • April 6, 2019 at 11:44 AM

      Typically the point of demarcation is where you transition from equipment under your organization’s direct control to control by some other organization.

      Where this gets messy is when the teleco is providing telephony services (i.e., VoIP, voice messaging, instant messaging, telepresence, etc.) as well as the connectivity services (i.e., wire and call switching). The connectivity services would be out of scope, but the telephony services would be in scope for PCI compliance.

      • 152 Dan
        April 7, 2019 at 5:40 PM

        But all of the equipment is under our direct control, including the cell tower the customer hits when they make the call.

      • April 17, 2019 at 6:32 AM

        It’s infrastructure, not information processing. No different than SS7, channel banks, SIP routers or similar gear that only provides connectivity to the voice or wide area network.

  58. 154 Erik
    March 21, 2019 at 2:32 AM

    Hi PCI Guru,

    How would you interpret Requirement 6.3 (software development processes) when it comes to 3rd party developed applications? The guidance states that 6.3 applies to “software developed internally as well as bespoke or custom software developed by a third party”.

    I have a customer that uses an application that is developed by a 3rd party and sold to perhaps a few dozen customers. The application is not PA-DSS validated (not eligible due to not doing authorization or settlement).

    The customer is claiming that 6.3 does not apply, because it’s not a “bespoke” or “custom” application.

    In my opinion, the intent of the requirement is to ensure that software designed to process cardholder data is developed securely. “Shrink-wrapping” a product, does not make it secure. Therefore, 6.3 still applies.

    What do you think?

  59. February 28, 2019 at 4:41 AM

    Hello PCIGuru

    Wondered if you can advise with regards to a situation we have. The business has gone and bought a solution without considering compliance issues. The suppliers have proposed a solution which we are investigating the impact on our PCI compliance. There propose solutions is to host a number of application/database servers, Domain Controllers in their cloud data centre but all these servers need to be member of our on-premise Active Directory. Our immediate reaction when we saw this proposal was it is big security issue because servers in our domain including DCs are in a data centre which we have no control of. What impact a setup like this have on our PCI compliance? Would the cloud data centre be in scope for our PCI compliance?

    • March 3, 2019 at 12:42 PM

      I am assuming that none of the application/DB servers going into this hosted setting are in scope for PCI compliance. However, your AD solution is in scope for PCI and the AD servers in the hosted solution will therefore also be in scope. If the third party running the hosted solution does not assess for PCI compliance, then your organization will have to assess the hosted solution for PCI compliance.

      • March 4, 2019 at 2:22 AM

        Hello PCIGuru
        Thank you for your response. The application/DB are not themselves linked to PCI but in our case our whole network is in scope for PCI. Number of years back we had a QA consultant to assess how we can reduce our scope for PCI and the recommendation was that we should segregate the PCI application from the reset of the network. We looked at a high-level view of what is involved in doing this and the management of it afterwards. Considering that our whole network is in scope for PSN and there are lot of similarity in requirement between the two and the amount of integration between the various business within the council and the pain it can cause separating things out and maintaining it we decided to keep the whole network in scope. Does this change anything in this case?

      • March 9, 2019 at 7:31 AM

        Not really when your scope is basically everything.

  60. February 27, 2019 at 9:00 AM

    Our business have gone and purchased a system which we are trying to fit in to our environment. The initial solution they are proposing is they’ll host a number of servers with the application in their data centre but these servers need to be in our AD domain and some of the servers are going to be DCs. When we heard this immediate response was that it is a security no no because we have no control of these servers in their data centre. This is extending our corportae network in to their data centre. For our PCI compliance would their data centre be in scope as well.?

  61. 162 Wafiy
    February 15, 2019 at 12:03 AM

    Hi Guru

    Happy New Year and hope all is well.

    A quick question: Messaging technologies like Signal has gotten a fair bit of traction these days thanks to Kevin Mitnick’s Art of Invisibility book. This has also brought up the query from clients, now that Signal or Whatsapp has adopted end to end encryption , can they be used now as a PCI channel and address requirement 4.2. Because there are two issues here: transmission + storage.

    Firstly transmission. Whatsapp now utilises private/publick key where the public key is transferred to receive via whatsapp server, and private key in device of user. The public key encrypts the senders message on the phone even before it reaches the centralised server. The server is only used to transmit the encrypted message. The message can only be unlocked by the private key of the receiver. No third part, including WhatsApp can intercept and read the message.

    So far it seems to address the issue of transmission encryption.

    The storage is a problem here admittedly. But if we limit the storage – meaning whatsapp messages and senders/receivers are limited to company phones that do not do anything else, and are isolated, and cannot be removed, and are located in single secure locations. And these phones are also encrypted (somehow) – wouldn’t these in theory address the issues of requirement 4.2? (discounting the massive headache to secure data at rest – let’s assume we somehow can do this).


    • February 16, 2019 at 10:49 AM

      The problem is that just because you have Signal does NOT imply the person you are messaging has Signal as well. As a result, you cannot guarantee that using Signal is secure.

      As to WhatsApp. Seriously? Given all of the press they have gotten lately for their lack of security and other privacy issues, you’d even consider this as an option?

      The bottom line is that IM is a terrible solution for sharing anything regardless of what security they claim to have implemented. I don’t even recommend it when it is only used internally. It’s just a really, really bad practice.

      • 164 Wafiy
        February 17, 2019 at 2:54 AM

        Hi Guru

        Thank you for the response. While, trust me, I am 100% keen on NOT having us explore this option, its still an obligation for us to look into this, as to whether instant messaging technologies can comply. Previously the biggest argument was encryption was only from sender to server and on servers like WhatsApp, they had copies of our messages, rendering PCI impossible.

        Now, because WhatsApp has championed their E2E encryption, unfortunately we need to look into it, from an unfiltered lense (yes, we don’t trust Facebook) – so if its ANY instant messaging system, employing end to end encryption (they utilise private-public key, and WhatsApp has zero access to messages), and despite the recent alarms of them having a backdoor (they don’t, it’s purely hacking of the device itself, not the encryption technology) – would they comply to 4.2?

        Its a case where, at the point of PCI being written, Instant messaging was never secured so we never had a query like this. Now, however, if a solution is able to comply to PCI (at least for 4.2), shouldnt we be obligated to go deeper into understanding it? Just an opinion, would like to know your thoughts.

      • February 17, 2019 at 9:26 AM

        WhatsApp will provide your organization with a compliant PCI Attestation Of Compliance (AOC), correct? I think the “NO!” answer to that question will give you your answer. This is the same problem we run into with other services such as Microsoft Office 365 and Google Applications. The vendor will not provide an AOC and will not let you independently assess them. And if you think their SOC 2 report will do the trick, think again. I spent a week going through the SOC 2 for O365 and could only get to around 23% coverage of the PCI DSS requirements. Not enough in my very humble opinion to rely upon for saying O365 is PCI compliant.

      • 166 Wafiy
        February 17, 2019 at 7:30 PM

        Hi Guru

        Thanks for the response. Yes, I doubt they will provide any sort of compliance on their end. Even if they did send us a SOC2 report, I dont think that will provide any safe harbor for PCI in any case. Thanks for the discussion, it was good one.

  62. 167 Erik
    February 13, 2019 at 4:25 AM


    Do you consider a DMZ to be a CDE? For example, a DMZ for a web server that processes incoming transactions, with appropriate segmentation from the main “internal” CDE.

    By the general definition, a DMZ is obviously a CDE, as it does process CHD. On the other hand, the DMZ is allowed to do things the CDE can’t (e.g. direct connectivity to the Internet). In addition there are some requirements (e.g. 1.3) that distinguish between the DMZ and the “internal cardholder network segment”.

    For example, would you apply Requirement 1.2.1 (restrict in- and outbound connections to the CDE) to the DMZ?

    (I couldn’t find any guidance or FAQ from PCI SSC on this subject…)

    • February 16, 2019 at 10:58 AM

      There are externally facing DMZs (i.e., the internet facing Web site) and there are internally facing DMZs. Some DMZs have both exposures (again, your internet facing Web site) and some internal DMZs only have internally facing connections (i.e., any CDE). However, the networking restriction rules apply to ALL DMZs regardless of external or internal connectivity.

  63. 170 betsycastelleno
    February 11, 2019 at 8:22 PM

    I just started as an ISA.
    Turns out the previous ISA didn’t renew the contract for our ASV scans and they were never run in 2018.
    We are coming up on our annual RoC next month, so we will only have a scan from this month (first quarter 2019), but not the previous 3 quarters.
    Are we dead in the water?
    If not, how can we pass a RoC with only 1 quarter of clean scans and not 4.
    Thank you sooo much.

    • February 16, 2019 at 11:00 AM

      Welcome to PCI surprises.

      You are going to need to have a Compensating Control Worksheet (CCW) for your external ASV scans. Your problem will be to come up with controls that go “above and beyond” the controls ASV scans provide. One that I have used in the past is that the organization does their own monthly vulnerability scans in addition to the ASV scans. Not a perfect situation, but at least you can show that scanning is done, it’s just not an “official” scan.

  64. 172 Dan
    February 11, 2019 at 3:01 PM

    Hi PCI Guru,

    A question on SAQ B-IP and 11.2.2 (external scans). Question being: Why? Our PTS devices are not external facing. Does the council want us to test all of the firewalls at each store?

    • February 16, 2019 at 11:02 AM

      If your POI are not externally facing, a couple of questions.

      1. How do the POI communicate to your gateway/processor?

      2. How are you able to use SAQ B-IP?

      • 174 Dan
        February 17, 2019 at 4:26 AM

        Thanks for the reply.
        1. Behind a firewall, making an outbound connection. No NAT/PAT rules to the device.
        2. No storage of card data, PTS device.

      • February 17, 2019 at 9:22 AM

        You MUST prove with the external scans that what you are saying is correct against point #1. As to point #2, that is expected from a PTS devices, however, those PTS devices can still have vulnerabilities.

  65. 176 Jane Laroussi
    February 11, 2019 at 11:21 AM

    What are your thoughts on using Office 365 (e.g., OneDrive or SharePoint Online) for storing QSA work papers? Section 4.4.2 of the QSA Qualification Requirements document includes this statement regarding protecting confidential and sensitive information “Systems storing customer data do not reside on Internet accessible systems.” Since these hosting platforms are Internet accessible (with authentication), I’m thinking O365 would not be an option. Many of our actual customers have moved to this platform already.



    • February 16, 2019 at 11:04 AM

      If the OneDrive instance is a corporate instance, the files/folders are encrypted and only your company’s personnel can access via MFA and credentials, then it should be fine.

      I am not a proponent of SharePoint for storage of sensitive information. I know that there is encryption available, but it is too dependent upon Active Directory and I have never seen a SharePoint site able to survive the scrutiny of a good penetration test.

      • 178 Jane Laroussi
        March 5, 2019 at 6:35 PM

        Thanks. I am inclined to keep work papers on premise vs. in the cloud as I have the same concerns. Having another opinion from someone with your credentials will help support my position.

  66. January 8, 2019 at 2:41 PM

    Hi – is it true there is a 90-day window in which to complete an annual RoC?

    Meaning if we signed our AoC/RoC on Jan. 1, 2018, our 2019 has to be done by March 30, 2019.

    If that is correct, do I need to get permission, or advise our bank/acquirer that we will be late? Or just get it to them within that 90-day window.

    Thanx!!! Kathy

    • January 9, 2019 at 7:47 AM

      You have two issues here.

      First, let’s tackle the time limit question. There is a time limit but it is based on the age of evidence, not the actual time it takes to write the ROC itself. The PCI SSC wants QSAs to use timely evidence in developing the ROC. Most QSAs gather evidence two to four weeks before the start of onsite fieldwork. After fieldwork, there usually is a period of time where remediation and/or additional evidence needs to be gathered. The general rule of thumb a lot of QSAs use for the age of evidence is that it should be no older than 120 days (i.e., four months). If it gets older than that, new evidence needs to be gathered and used for the ROC. Not that all evidence needs to be replaced, just evidence that is older than 120 days.

      Now to your question about your bank. Yes, you need to talk to your acquiring bank(s) any time you will not be filing your ROC on your expected renewal date and why that is occurring. If you are only going to be two to four weeks late, most banks do not require anything else. However, if you need more than a month, most banks are understanding of this situation and have processes in place to address it by giving you 90 day filing extension without too many issues. More than a 90 day extension usually requires your QSA to be involved as well as your own organization. Your QSA may be required to write a letter expressing that the ROC is in process as well as documenting any issues that have resulted in the filing delay. In any case, the bank(s) will likely schedule regular meetings to check on your progress.

  67. January 2, 2019 at 2:48 PM

    Hi Guru – trying to figure out which SAQ we need to do. We gave a mobile app (both Apple and Android), which is available on App Store/Google Play.

    It is used for the buying and selling of specialized industrial parts.

    We do about 50,000 transactions per year.

    We are using the Spreedly API.

    So when the user wants to make a payment, Spreedly window comes up. They enter the CHD in the Spreedly window and press enter to make the transaction. We don’t store any cardholder data.

    All we get back is a token.

    Based on the, which SAQ do we do?


    • January 3, 2019 at 5:30 PM

      First and foremost, only your acquiring bank can provide you a definitive answer as to which SAQ you should be using based on your payment processing.

      But your answer is in following the payment data. You say that your organization gets back a token at the end but you give very little about how the payment is actually processed, how the Spreedly API is invoked, by whom and what if any of your infrastructure is involved in these processes. These answers will be needed by your bank to determine which SAQ to use.

      To assist your bank, I would highly recommend creating a data flow diagram of how the transaction process works. That diagram should indicate where, if anywhere, the sensitive authentication data (SAD) or cardholder data (CHD) is processed/transmitted in clear text. I am assuming that your transaction processor or bank is the actual storage point of any SAD/CHD.

      Best of luck.

  68. 183 John
    December 26, 2018 at 11:18 PM

    Mr Guru, I’m seeing more and more queries and complaints from small vendors who are now failing their external automated scans because these third parties aren’t detecting any hosts/ports/services active anywhere on their IP address. These are tiny offices with a cable modem/router and nothing exposed to the internet, and maybe have nothing but a terminal transmitting card data, but since the scan vendors don’t get any kind of response on any port they are insisting that vendor is actively blocking traffic to thwart the scans — just because the router is doing what it’s supposed to do! Any advice?

    Related — what about an office with only a dynamic IP for internet? How can they comply with scanning requirements?

    • December 29, 2018 at 2:15 PM

      First off, in my VERY humble opinion, these merchants should NOT be conducting ASV scans because they have no externally facing assets other than their cable modem or router. And if that cable modem/router is NOT theirs, then it is the common carrier’s problem to ensure the security of that device, NOT the merchant.

      That said, if they still want to scan, these merchants should be explaining the fact that they have only their cable modem/router as externally facing and the ASVs should be reporting their findings accordingly (i.e., NO vulnerabilities found). If the ASV refuses to do that, then they need to find a new ASV that understands the program.

  69. 185 Kenny
    December 26, 2018 at 2:16 PM

    In reading a historical post you have on the site regarding encrypted CHD being in scope, I have a follow up question related to the CDE scope impact when encrypted CHD has been proven to not be in scope. If you are encrypting at POI and meet all requirements for the encrypted CHD being out of scope, does that mean that none of the infrastructure is in scope of the CDE except for the EMV card reader? Technically, you may be transmitting the encrypted CHD over your internal network on it’s way out to the payment processor. Would anything on the internal network that the encrypted CHD travels over be pulled into the CDE?

    Thanks, Kenny

    (copied from prior post)
    “It is possible that encrypted data may potentially be out of scope for a particular entity if, and only if, it is validated (for example, by a QSA or ISA) that the entity in possession of the encrypted data does not have access to the cleartext cardholder data or the encryption process, nor do they have the ability to decrypt the encrypted data.”

    • December 29, 2018 at 2:20 PM

      That is the whole point of point-to-point encryption (P2PE) and end-to-end encryption (E2EE) solutions – to take everything but the endpoints out of scope. The only difference between the two is that a PCI P2PE validated solution grants the merchant immediate scope reduction and E2EE (e.g., TransArmor or VeriShield) requires the acquiring bank’s approval for P2PE scope reduction.

      Just to be clear, EMV does NOT imply P2PE or E2EE. P2PE/E2EE solutions were available with the mag stripe. They only came in vogue with EMV because merchants were replacing their POI for EMV so they might as well add P2PE/E2EE capability.

  70. 187 Wafiy
    December 19, 2018 at 9:45 AM

    Merry Christmas to the Guru

    I’ve been logger heads with my QSA for some time and I just want to bounce it off. According to her, we are using Citrix Sharefile and it does encryption of data at rest. She insist on having us document the entire key management of this sharefile, especially focusing on the location of all the keys that are stored in folders and directories and for us to have FIM on it. Firstly, while I agree some encryption technologies do have keystores located in the server folder/directories, we have other Counter off the shelf encryption solutions as well. Does QSA require every encryption solution to have this information of where keys are stored etc? What if like TDE, keys are stored in the tablespace header? How do we monitor it? I just think this is going a bit too far, but I might be mistaken. Do we need all COTs software to identify keystore locations, and for us to monitor all these keystore locations for changes and access?

    • December 19, 2018 at 3:36 PM

      So, let me counter with my own questions. If you don’t have the information that you are complaining about knowing, how do you know that your solutions’ key management is secure? Let alone the encryption is secure if someone takes that encrypted blob of data? If you cannot answer those questions, then I think you have your answer as to why your QSA is asking. Because you have no idea what risks your encryption solution presents to the data it is supposedly protecting.

      • 189 Wafiy
        January 2, 2019 at 12:11 AM

        Point noted. It was just that for this solution, we were presented with the AoC of the vendor which covered key management and in this instance, the key management was done by the vendor, through Azure Key Vault, not by us. So technically even if we had access to the data, we don’t really manage the keys. But I will get clarity on this, thank you for your point.

      • January 2, 2019 at 11:04 AM

        If you have an AOC from the vendor and the table in section 2g of the AOC clearly states that the vendor is managing the keys (i.e., there are no ‘Not Applicable’ or ‘Non Compliant’ answers for requirements in 3.5 and 3.6 or it is flagged that your organization is responsible), then I would take that as your proof for you and your QSA. If your QSA still balks, then you need to get your bank involved to break the deadlock.

  71. 191 Nagu
    December 14, 2018 at 1:58 AM

    PCI compliance and Wifi network
    We are looking at a few new Wifi solution and onwe of them is from Cisco. Below link gives detail

    In our case the each Access Points will be broadcasting various wifi networks Corporate, Guest, public etc.. but all this trafic will be routed through the corportae network. The Access points have a firewall built in with which we can block guest and public users from connecting to corporate ip but the guest and public traffic needs to be routed through the corporate network to the firewall to get out to the internet. Is this adequate separation for PCI compliance?

    • December 14, 2018 at 6:46 AM

      You need to have separate, secured VLANs for the non-Corporate traffic. That means ACLs and firewalls that do NOT allow the non-Corporate traffic to go anywhere other than out to the internet.

  72. 193 annette
    December 4, 2018 at 12:15 PM

    Happy Holidays – apologies for two posts. I pressed enter before the first sentence was correct. I’m seeing products that use a WiFi hotspot page for credit card payments. Any suggestions on how to reduce scope? These are not PCI Council Approved P2PE products. I also see some vendors offering cellular services products and i know control 4.1 speaks to the encryption and open public networks. How would the QSA test for a cellular services card payment beyond the encryption level. ? Thanks

    • December 6, 2018 at 9:18 AM

      AA lot of these Wi-Fi and cellular solutions are using TLS or IPSec for encrypting their connections back to the gateway or processor. Your only way to confirm this is to ask these providers for their PCI Service Provider Attestation Of Compliance (AOC) for their payment service(s). No AOC then you should move on to a different service provider.

  73. 195 AAbbas
    November 11, 2018 at 8:03 PM

    My question is regarding a merchant environment, they are using wildcard certificates and using keypass to store the details. The cryptographic requirement 3.5 doesn’t talk about certificates and cert management. Any clarity on this area?

    • November 13, 2018 at 8:05 AM

      I am assuming you are talking about certificates that are used for secure data transmission not encrypting data at rest. The requirements in section 3 are all about data encryption, not data transmission. Data transmission requirements are discussed and tested in section 4.

      That said, wildcards are acceptable as long as they are not too “wild”. I am assuming you are talking about a wildcard such as ‘*.domainname.TLD’ or more restrictive. KeePass to keep information about the certificates is acceptable as long as there are appropriate restrictions regarding who has access and appropriate password strength. I would want to see a separate KeePass vault for this information not have it stored in an enterprise vault.

  74. 197 betsyosterheim
    November 6, 2018 at 9:29 AM

    I need help with understanding section 9.5 – physically secure all media.

    I always thought this was about cardholder data on removable media, like floppy, backup tapes, CD-ROM, optical etc. That is what ‘media’ means to me. But I am not a ISA or QSA.

    Our QSA is telling us ‘media’ is any and all electronic media where cardholder data is stored.

    So he wants our inventory to include every hard drive where CHD is, including every drive, array, SAN, etc.

    That inventory will be massive in this case, and so hard to track.

    Can you clarify? My guess is that the letter of the DSS is closer to his interpretation, while the spirit of the DSS is closer to my interpretation.

    Please send any advice and official references that you can.

    Thank you so much!

    • November 7, 2018 at 7:38 AM

      Just to clarify, it also includes physical media such as receipts, forms from a “knuckle-buster”, reports, etc. So it is NOT just electronic storage.

      I think your QSA is going a bit overboard. Yes, I would want to know what SAN/NAS, server or workstation has stored CHD, but keeping track of every physical drive is insane as you point out. That said, if a drive from one of those devices needs to be replaced, I would want to record that fact by drive serial number, date replaced, and if it was securely wiped (in the case of drives that are NOT already encrypted) or a notation that a drive was encrypted and not wiped.

      If you QSA does not agree to that, then you need to have a discussion with your bank and the QSA to get this issue mediated.

  75. 199 Chris Larson
    November 5, 2018 at 5:15 PM

    Can you clarify if Stripe is PCI compliant?
    I’d like to help a client with a SAQ-A, but can not make sense if Stripe is PCI compliant.
    I requested their AoC a few times, but ended up in a black hole.
    They have a lot of info about PCI DSS on their web site, but the actual AoC is no where to be found.

  76. 201 Michael
    November 2, 2018 at 8:22 AM

    I’m trying to understand the relationship is between the various SAQs and the PCI DSS checklist v3.2.

    For example, if I am a level 4 merchant, who does not store any CHD electronically, and am required to fill out an SAQ-A, what is my responsibility to be in compliance with the rest of the 12 Requirements?

    • November 2, 2018 at 11:41 AM

      SAQs are a subset of the full PCI DSS based on the type of payment channels your organization processes such as eCommerce, stand alone card terminal, integrated POS and the like. Each SAQ has a ‘Before You Begin’ section that documents the criteria for that SAQ. If you cannot meet that criteria exactly, then you cannot use that SAQ. For example, SAQ A is only for merchants that have outsourced eCommerce and no other payment channels.

      Please read the criteria for all the SAQs and then determine which fits your merchant environment. You may find that you need to follow more than one SAQ based on how many payment channels your organization has in place.

  77. 203 Chris Larson
    October 9, 2018 at 12:55 PM

    For SAQ signing, does the merchant have to sign first, and then the QSA?

    Or does order not matter?

  78. 205 Chris Larson
    October 9, 2018 at 7:53 AM

    For a SAQ-D, when using AWS (or any other PCI compliant hosting provider), for section 9, do you answer ‘yes’, ‘N/A’ or ‘not tested’?

    Since it is in place via AWS, I’d think it is ‘yes’, but not 100% sure.

    • October 9, 2018 at 9:29 AM

      ‘Not Applicable’ or ‘NA’ if the requirement is entirely met by AWS. You will also need to describe in the Comment WHY it is not applicable. In this case, I would suggest, “Not Applicable. Reviewed the AWS AOC and Compliance Matrix and verified that AWS is entirely responsible for compliance with this requirement.” But be very careful here as there could be situations where your organization AND AWS are responsible for some requirements in section 9.

  79. 207 Wafiy
    September 28, 2018 at 5:16 AM

    PCIGuru, quick question. We are trying to get our insurance company to go through SAQ D-Merchant and we have a question on the agents. Our agents (freelance or agencies) handle policy forms, Mobile POS and even send emails sometimes of documents containing credit card information of clients. I believe they are in scope for PCI, but from the insurance company perspective, as long as we have a contract clearly stating their security obligations (REquirement 12.8), it should be sufficient. We should then worry about the point of entry of these policy forms and emails (which we will be removing and using secure FTP) into our environment. We shouldnt be having to concern with these agents, or their environments, or their PCs, Laptops under our PCI-scope correct?

    • October 9, 2018 at 9:38 AM

      Any document or electronic transmission that contains cardholder data (CHD) or sensitive authentication data (SAD) is in scope for PCI compliance. So removing those from your environment using SFTP/FTPS is the way to meet compliance.

      In the case of your agents/agencies, you need to be requiring them to provide you with their own annual PCI Attestation Of Compliance (AOC) stating that they are PCI compliant. Contractual obligations are fine for meeting requirement 12.8.2, but does not comply with 12.8.4 which requires acknowledgement of third parties’ PCI compliance. You may want discuss this with your acquiring bank and see if you could possibly drop the 12.8.4 AOC requirement and just rely on the contractual requirement as long as it explicitly calls out PCI compliance.

      As to laptops and any other devices your company owns but are used by the agents/agencies, those need to be assessed as part of your company’s PCI compliant effort.

  80. 210 Chris Larson
    September 26, 2018 at 2:27 PM

    Any thoughts on a payment app vendor who late in getting a fix to upgrade their usage of TLS?

    So we are still using 1.0, and hope to be fully migrated to 1.2 by end of January 2019.

    Can a Compensating Control be made for the use of TLS 1.0? Or will it be rejected by acquirers?

    • September 26, 2018 at 3:10 PM

      The Council stated earlier this year in a QSA call that a compensating control worksheet (CCW) would have to be used for those instances when TLS 1.0 still needed to be used.

      That said, could the CCW be rejected by the acquiring bank? That is always the risk with a CCW.

      • 212 Chris Larson
        September 26, 2018 at 4:17 PM


        i have found about 95% of the time, the acquiring banks will go along with a CCW if it is well-written, has real answers, includes a plan to fix the gap. As long as you are reasonable, they will be reasonable. If you are reasonable, they will ok the CCW as if they don’t, it will get fixed and a different bank will be making the money. So they have many incentives.

        of course, I have seen CCW that look like they were written by 5th graders, and were quickly rejected by the bank.

      • September 26, 2018 at 4:42 PM

        But I have also seen well written CCWs get rejected as well. It is rare, but it can occur. If an acquiring bank does not agree with the risk being accepted, they will reject a CCW.

        There are also the very, very occasional bank that will not accept a ROC/SAQ with any CCWs. They are very rare, but I have also encountered them. They are unwilling to deal with any CCWs.

  81. 214 Anonymous
    September 19, 2018 at 9:41 AM


    Can you please suggest what PCI DSS controls will be applicable for a business process where in ‘ a global service desk needs to respond to phone calls from colleagues who have forgotton their user level account password.
    Hope to hear soon from you.
    Kind Regards

    • September 23, 2018 at 8:01 AM

      I think you are asking abut what is acceptable under PCI DSS to validate an end user’s identity as required in 8.2.2. In the US, last four numbers of the social security number is acceptable. I have also seen companies ask for the last four characters of the person’s driver’s license number. What you want to use is something that a social engineer would not readily come up with via LinkedIn, Twitter or Facebook.

  82. 216 Chris Larson
    September 17, 2018 at 3:58 PM

    For Card Recon scans, do you need to scan every device that contains CHD? Or can you do it as per the sampling criteria?

    • September 20, 2018 at 10:14 AM

      If you read the PCI DSS on page 10, second paragraph states, “At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in the PCI DSS scope. All types of systems and locations should be considered as part of the scoping process, including backup/recovery sites and fail-over systems.” The next paragraph explains in further detail. Basically, it is up to the assessee to validate that CHD/SAD is only contained in the CDE and no where else.

  83. 218 Chris Larson
    September 17, 2018 at 11:01 AM

    Want to do initial SAQ D, but only has 1 quarter of scans

    SAQ D requires 4 quarters of clean scans.
    But if a merchant is going thru a SAQ D for the first time and have only recent scans, what should they do?
    Do they have to wait 3 more quarters to submit? Or is there alternatives?

    • September 17, 2018 at 12:10 PM

      No. First time filers can submit one, two or three ASV scans if they only have that few. In the Report On Compliance, a QSA/ISA can specify that it is the organization’s first assessment. However, I do not notice the same in the SAQ so you will have to note that in the Comments entry for those requirements.

  84. August 23, 2018 at 4:32 AM


    What does safe harbor status mean?

    • August 23, 2018 at 6:24 AM

      In regards to PCI and PCI compliance, nothing.

      • August 23, 2018 at 8:18 AM

        OK what I was told was we have not met all the requirements so currently we are in a safe harbor state but you are saying not relevant to PCI?

      • August 23, 2018 at 8:57 AM

        The concept of “safe harbor” was related to the old EU data privacy law and had nothing to do with PCI.

        If you are not PCI compliant, you are not PCI compliant. There is no “safe harbor” where because you assessed there is some sort of “credit” given for at least making a try. Your organization is not PCI compliant and can face fines and penalties as a result from the card brands and your acquiring bank.

  85. 225 Eddy
    August 22, 2018 at 5:27 AM


    New to this forum. I have a question regarding PIN security from a product development as I have seen this done by other processors / issuers.

    We store our PIN blocks and Keys in accordance to PCI DSS guidance, but I have been asked a few times by other product development teams if they can provide a feature to customers in circumstances where they have forgotten their PIN. In essence what they would like is a feature that upon credential verification, the system could display the PIN, as opposed to force them to reissue a new card.
    Obviously this would mean that the PIN would travel encrypted and through TLS but at the end of the road, it would be displayed in the clear on the website. It could be displayed as an image as opposed to clear text if that helps.

    • August 23, 2018 at 6:27 AM

      Rather than displaying a PIN, it should be handled similar to a password reset. Banks have been allowing people to change their PINs for years on ATM cards via IVR solutions. That would be the approach I would recommend.

  86. July 27, 2018 at 8:00 AM

    I’ve got a payment LAN segmented from the office LAN using a single firewall, and two external IP addresses. The firewall ensures all PCI CDE traffic uses public IP 1, while all office traffic uses public IP 2. I also host a few servers (email, web) on the office LAN, which are only accessible from public IP 2.

    Does this reduce the scope of external ASV scans to just the public IP I’ve associated with the PCI LAN? Or do I still have to scan both IPs?

    What happens when vulnerabilities are found on the office public IP? Am I then non-compliant?

    • July 27, 2018 at 3:56 PM

      Assuming your ASV has deemed that your network segmentation is correct between the two public IP addresses, your ASV scan should only be against your public IP address on the CDE network segment.

  87. 229 Mike
    July 18, 2018 at 9:15 AM

    Does PCI come into scope if the CHD stored is not used in payment processing? Such as a law firm that stores subpoenas that contain CHD.

  88. 232 Rob
    July 14, 2018 at 8:39 PM

    Dear PCI Guru,

    I know that organizations need a PCI Security Policy and many vendors such as Trustwave or Coalfire have a template you can use. Do we also need procedures for the security policy on a separate document or is the security policy enough? What would the procedures look like? Do they really need to be step by step if needed? That does not seem reasonable since methods change over time.

    Thanks in advance,


    • July 15, 2018 at 1:03 PM

      I prefer policies, standards and procedures as separate documents because policies and standards should rarely change. But procedures usually change as practices, software and new controls are introduced making them easier to revise because policies are required to be reviewed whenever they change.

  89. 234 Aaron
    July 13, 2018 at 8:44 AM

    Tokenization and Merchant Level

    So here’s a scenario I was wondering if there is any precedent or ruling on (Or if it’s just self evident to everybody else that it’s not a thing, ha):
    Let’s say you’re a Level 1 Merchant, and you do 6 million Visa transactions a year. However, 80% of those are Merchant Initiated Transactions via multiuse tokens (supplied by a fully compliant provider). The rest are all from a managed retail POS device.

    Now, here’s a bit I’ve had a question about. We know at this point that Tokens are not Card Holder Data via the PCI definition. How does this relate to the definition of what constitutes to contributing to a Transaction level?

    IE: Are tokenized transactions in this scenario considered to be the same as a standard credit card transaction, or can these transactions by their nature actually lower a merchants transaction level and their by their Merchant Level?


    • July 14, 2018 at 8:26 AM

      Good question for Visa to get you an official answer.

      It is my understanding that transactions are transactions, regardless of the format of the cardholder data, i.e., token or PAN. The reason I say that is if there was a difference, you would think the card brand merchant levels posted on their Web sites would call that fact out.

      But furthermore, solutions like Shift4 tokenize at the swipe and those transactions still count towards the merchant level for a merchant even though they are tokenized.

      • 236 Aaron L Schatzer
        July 16, 2018 at 11:33 AM


        This does lead me to a really basic question:
        What defines a “Transaction” for the purposes of PCI?

        I actually can’t find a single definition of what constitutes a transaction. (And I say this as somebody that s actually written an ISO 8583 implementation way back when, haha).

        I would assume a transaction for the scope of PCI for a merchant would be Point A (Card holder data) to Point B(Processor). A tokenized transaction in theory would be a request from Point A to Point B (Assuming this train of thought).

        Where I’m going with this is really more of a side curiosity about programs like Visa’s TIP. No where in it’s definition does it take tokenization into it’s requirements for eligibility based on volume, even though a tokenized transaction (ie: Merchant Initialized via a stored token) assumes much less risk than either of it’s eligibility criteria (PINnChip/Contactless or a p2pe solution).

        But anyhow! Thanks again! You’re site is great source of information! time to talk to the acquirer and Visa!

      • July 16, 2018 at 5:34 PM

        A transaction occurs whenever a payment card is used to pay for goods or services.

  90. July 11, 2018 at 7:22 AM

    Hi – i was wondering if there was any additional advice regarding which SAQ to complete regarding external JS implementations on payment pages (even those with Embedded iFrames) given the recent Ticketmaster breach. These implementations seem very popular -across all sites: chatbots, analytics, session recording etc.. For example do you need to remove all external JS on any payment page that contains an embedded iFrame in order to meet SAQ A. Otherwise you are at least required to complete SAQ- EP.

    • July 12, 2018 at 6:17 AM

      I always have people reference this post ( and the chart in that post. If JavaScript is used, then A-EP applies.

      That said, anyone that thinks that SAQ A is even remotely a good idea for ensuring the security of a Web site is greatly mistaken. In the end, if that Web site is shown to be the cause of a breach because the link to invoke the payment page was compromised, it will NOT be the transaction processor or the merchant’s bank that will take the heat. It will be the merchant and their lack of securing their Web site that will be held responsible. So following A-EP might be a better way to go for everyone operating a Web site.

  91. June 25, 2018 at 6:10 PM

    This question regards SAQ B. We use handheld PoS devices approved by our acquirer for continued use. In SAQ B, there are some requirements that speak about how the device handles CHD, such as:


    The device is a black box to us. It is approved by our acquirer (just for clarity, our acquirer is an enormous bank who issues our merchant ID’s, and has the power to taketh them away. I just want to assert that I’m using the term acquirer accurately).

    So in citing evidence of compliance for those requirements, as pertains to the PoS device, do we just say the device is approved? Or do we have to get explicit evidence from the device’s manufacturer?

    I realize that if we are doing things in our environment that do not take place on the PTS devices, we would have to address those activities directly and separately.

    • June 26, 2018 at 5:51 AM

      When you use the term “handheld” is the point of interaction (POI) connected via a telephone line, USB cable, network cable or wireless? If it’s a telephone line, then you are using the correct SAQ (SAQ B). All the others require you use SAQ B-IP.

      Since the SAQ goes to your bank and your bank issued you the POI terminals, then you should not have to do anything more other than fill out the SAQ and send it to them.

      That said, I would check to make sure that the POI are properly configured to be secure. I cannot tell you how many I find that are not properly configured and are storing cardholder data (CHD). I would contact your bank’s customer support, ask them to explain how to properly configure the POI and then make sure that all your POI are securely configured so that they are not storing CHD.

      • June 26, 2018 at 10:35 AM

        Thanks so much. A few facts I did not supply at first:

        The devices are cellular.

        The devices are not supplied by our acquirer, but the acquirer has said they are OK to use. I wanted to check with the acquirer precisely because the devices are not supplied by them.

        They come from a separate company who specializes in providing such devices for our industry.

        Also, there is yet another company who is the payments processor, between the devices and the acquirer.

        So the devices are not configurable by us, they are not provided by the acquirer, and they are approved by the acquirer. Do we just say Yes to those 3.2 and 3.3 questions?


      • June 26, 2018 at 2:50 PM

        Your transaction processor would have the information you need to ensure that the POI are encrypting at the swipe/dip as they would have to be managing the encryption keys.

  92. 244 Mark
    June 25, 2018 at 2:25 AM

    A question has some up about the level of fines for service providers. Particularly, in the situation where a service provider has been compliant for a number of years but loses subsequently loses compliance, for example by missing a vulnerability scan. What level of fines (if any) can they service provider expect?

    • June 25, 2018 at 5:04 AM

      If you are a Service Provider but do not process transactions such as with a managed security services provider (MSSP), I am not sure how or even if the card brands can assess a fine against your organization because there is no contractual arrangement between your organization and the brands.

      If you are a Service Provider that does process transactions such as with a transaction processor, then you have a contractual arrangement between your organization and one or more of the card brands. In this instance, the brands would fine you just as they would fine a merchant.

      In regards to your example of missing a vulnerability scan, you would write a compensating control worksheet for missing that scan and move on. Something that simple would not typically result in a fine unless it is a regular occurrence.

  93. 247 Ben
    June 22, 2018 at 12:25 PM

    A few questions regarding the upcoming TLS deadline:

    If a company hosts several websites, and only accepts payments on one of them, can early TLS remain enabled for the sites that are not payment related (out of scope)?

    If the payment page has a fully-outsourced solution (iframe or payment fields hosted directly by the payment processor), is the website even in-scope for disabling early TLS to begin with?

    What happens if TLS remains enabled for a week past the deadline?


    • June 23, 2018 at 5:35 AM

      Your question makes me ponder your motives? The iFrame will use TLS v1.2, so you cannot be concerned about your customers’ devices being able to support TLS v1.2. So why can’t your sites also support TLS v1.2? Read this post ( and then explain your question again, if you even have a question.

      • 249 Ben
        June 25, 2018 at 12:48 PM

        It was discovered that there are some devices used by a large amount users that don’t function with TLS v1.2. The manufacturer is scrambling to come up with a fix but they won’t have it ready by 6/30. These devices aren’t even capable of being used to submit payment information, and the information that is exchanged with them is not confidential in nature, so it’s not an issue of security being in question.

        If it could be made so these devices connect to a separate website dedicated to them, that allows use of TLS 1.0, and then have TLS 1.0 disabled for everything else, would that achieve compliance?

        Is that even necessary at all if the payment website uses the iframe method to reduce scope, and TLS 1.0 would only remain enabled for a week or two past the deadline anyway, when the manufacturer has the fix ready?

      • June 26, 2018 at 5:53 AM

        The separate Web site for TLS v1.0 needs to be logically or physical segregated from your payment site. Other than that, your plan is sound.

  94. 251 Kim
    June 13, 2018 at 3:38 PM

    We take payments via virtual terminal provided by our application processor. It’s a traveling setup of approximately 5 laptops with network connection via cellular hotspot. We travel on-site for specific events to process payments. Is there anything needed to secure/isolate the cellular wifi connection between the hotspot and the associated laptops from a PCI standpoint?

    Also the team currently uses the old-style usb card swipes to populate the card data into the payment browser page. I’m assuming this elevates us from a SAQ C-VT to a SAQ C. If the application processor supports encrypted mag readers does that take the PC’s and wireless completely out of scope?

    Thanks in advance!

    • June 14, 2018 at 3:37 PM

      I would hope that the Web page is encrypted from the PC to the Website over TLS to secure the cellular and Wi-Fi connections. However, because of the USB card terminals (point of interaction or POI), those place the PCs in scope for PCI compliance.

      I am assuming that when you refer to the “encrypted mag reader” solution it is NOT point-to-point encryption (P2PE) validated solution listed on the PCI SSC Web site.

      If you go to an end-to-end encryption (E2EE) solution with an encrypted POI, that would take everything BUT the POI out of scope. You could then ask your bank for approval for scope reduction to the requirements in SAQ P2PE.

      • 253 Kim
        June 14, 2018 at 3:54 PM

        Thank you for the rapid response. Yes, the website is SSL. You are correct that the “encrypted mag reader” would NOT be a P2PE validated solution. I’d be looking to go to E2EE to take the PCs out of scope. One additional question, if we go E2EE is there any impact if these are connected on our corporate wifi network as opposed to the cellular hotspot? I will have two machines in the CDE on the corporate network not currently segregated.

      • June 18, 2018 at 6:40 AM

        A proper E2EE solution should make any network out of scope for PCI as long as the transaction processor is the only entity with the encryption keys.

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

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

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

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

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

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

      • 267 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!

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

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

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

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

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

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

  103. 280 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).

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

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

    • 286 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:

      Click to access PCI-DSS-v3_2-SAQ-C_VT-rev1_1.pdf

      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.

  105. 288 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?

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

  107. 293 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!

  108. 295 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?


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  126. 342 Alan
    September 7, 2017 at 8:52 AM

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

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

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

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

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

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

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

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

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

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

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

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

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

  137. 370 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  159. 426 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,

  160. January 19, 2017 at 12:05 PM

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

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

  162. 432 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?

  163. 434 Marc Jones
    December 21, 2016 at 2:06 PM

    Can you recommend a free iptables audit tool?

  164. 436 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      • 475 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!

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

  190. 515 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!

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

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

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

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

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

  196. 527 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).

  197. 529 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?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      • 565 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!

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

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

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

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

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

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

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

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

  216. 584 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?


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