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.

1932 Responses to “Miscellaneous Questions Page”

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

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

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

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

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

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

  5. 14 Dale
    June 9, 2020 at 3:48 PM

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

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

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

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

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

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

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

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

  11. 33 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…!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  34. 90 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?

  35. 92 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?

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

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

  38. 98 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!

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

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

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

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

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

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

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

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

  46. 118 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?

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

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

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

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

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

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

Leave a Reply

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

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

Twitter picture

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

Facebook photo

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

Connecting to %s

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

June 2022

%d bloggers like this: