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.


1947 Responses to “Miscellaneous Questions Page”


  1. 1 Erik
    August 30, 2022 at 3:42 AM

    Hi,

    What’s your understanding of requirement 11.6.1 in the context of SAQ A?

    The requirement applies to the payment page. FAQ1438 clarifies that for an iframe solution, the Merchant website is NOT part of the payment page. In addition, if any part of the payment page is delivered by the Merchant, they are not eligible for SAQ A.

    However, SAQ A has an applicability note stating that 11.6.1 applies to Merchants with iframe solutions. It doesn’t say to what the requirement should be applied to though. By comparison, the SAQ A applicability note for 6.4.3 very clearly states that it applies to the Merchant website.

    My interpretation is that although SAQ A says that 11.6.1 is in the Merchant’s scope, it would always be the responsibility of the PCI DSS certified payment processor providing the payment page. There would be no actions needed by the Merchant.

    I find it very confusing when SAQs twist the applicability of requirements…

    • September 6, 2022 at 9:40 AM

      For v4, SAQ A is being changed to address the MageCart and similar attacks that are going on. Hence why 11.6.1 is there now as they are trying to reduce MageCart style attacks.

  2. 3 Oj Mavd
    August 10, 2022 at 12:24 PM

    Can I do ASV scans as a pcip or do I need to work for an ASV company and be a QSA

  3. 6 Mike
    August 8, 2022 at 10:16 AM

    Hey PCI Guru-

    My company utilizes corporate credit cards (Visa) for employee travel and expenses. CHD is stored within our network for reconciliation purposes. Would this fall into PCI DSS scope, or are corporate cards exempt?
    Thanks in advance for your assistance.

    • August 17, 2022 at 12:49 PM

      While corporate cards are exempt from PCI compliance, I would highly recommend that they be secured according to the PCI standards just for safe keeping.

      I also recommend that corporations have an agreement in place for employees that indicates why the information is stored and what the organization is allowed to do with the stored SAD/CHD.

      • 8 Robert
        September 26, 2022 at 7:16 AM

        Agreed. When a company obtains corporate credit cards, they are doing so under the terms and conditions of the cardholder agreement with the issuing bank, not the merchant agreement with the acquirer. Cardholders are still required to protect the card account number and report when it is stolen or compromised, thus requiring PCI-like controls on the information.

  4. 9 Mike Machado
    August 2, 2022 at 1:23 PM

    Are corporate credit cards in scope/ applicable to PCI DSS? I’ve seen conflicting information online. I found an article from 2009 that it depends on the card brand. Such as AMEX does not consider it in-scope but MasterCard does. We use Amex and Visa… if it is up the brand to determine the scope, is there an official published stance somewhere?

    • August 17, 2022 at 12:52 PM

      News to me that Mastercard considers corporate cards in scope, but that seems to change all of the time.

      That said, I recommend to all my clients that SAD/CHD for corporate cards be secured according to the PCI standards regardless of the card brand rules.

      I also recommend that the organization have an agreement in place with employees that have their SAD/CHD stored documenting why the organization has that data and for what purposes they are allowed to use the data (i.e., travel reservations, meeting reservations, meeting registrations, etc.).

  5. 11 Marc Jones
    July 1, 2022 at 2:19 PM

    Hi there I have a question about AWS lambda vulnerability scanning. Can we use Aqua to meet Req 11.2.1 (Internal Vulnerability scanning) for our entire environment?

    Thanks!

    • July 2, 2022 at 11:22 AM

      I don’t see a problem with using Aqua as long as the reports generated by Aqua regarding Aqua’s analysis of your containers are available to prove your quarterly vulnerability scanning requirements. That may require some sort of scheduled quarterly analysis using Aqua to get that reporting.

  6. 16 Marc Jones
    June 22, 2022 at 11:20 AM

    I apologize for leaving this out, they are a ticketing service platform and payment API processing tokenized cc data and do not have the ability to de-tokenize the the tokens.

    • June 22, 2022 at 11:39 AM

      No problem. I thought it was my misinterpretation of what you wrote. Regardless, if they are only seeing tokenized data and have no way to de-tokenize that data, they are not in scope.

  7. 18 Marc Jones
    June 22, 2022 at 10:23 AM

    Hi Guru – can a Level 1 Service Provider API processing over 300k tokenized credit cards complete a SAQ-D vs a Report of Compliance?

    • June 22, 2022 at 10:28 AM

      That depends on how many Visa, Mastercard or Discover transactions you process. The 300K limit is based on the card brand transaction count, not the aggregate. If any of those counts by brand are over 300K, then you are a Level 1 Service Provider.

      If you are going to claim you are a Level 2, you better make sure you have accurate transaction counts to justify doing an SAQ D versus the ROC.

      All of that said, if you are a service provider registered with Visa or Mastercard, then you MUST do a ROC.

      • 20 Marc Jones
        June 22, 2022 at 10:32 AM

        So the challenge I have here is the service provider does not see the tokenized cc data as cc data –

      • June 22, 2022 at 10:50 AM

        Okay, there is a clarification. If they only see tokenized data, then it is NOT classified as cardholder data and therefore NOT in scope. Meaning they are NOT in scope. I read your original message as they were the tokenizer, not that they were only seeing tokenized data.

  8. 22 Kay
    June 20, 2022 at 1:29 PM

    Can a SIEM be used in lieu of a FIM for satisfying the requirements?

  9. 24 Cindy
    June 16, 2022 at 11:50 AM

    Hi PCI Guru,

    Thanks so much for your site! It has very useful resources and information that I could not find anywhere else. With that being said, I have question regarding requirement 8. In the “overview” narrative for both v3.2.1 and v4.0, there is a statement that says these requirements do not apply to accounts used by consumers (cardholders). Does this mean the entirety of Requirement 8 does not apply to consumers? Not even password complexity requirements? On all systems or mobile apps that are customer facing?

    Thank you in advance for your time and help to clarify this!

    • June 22, 2022 at 10:16 AM

      Sadly, yes, they do not apply. So you need to plan and design your solutions accordingly. If your organization chooses to follow the DSS guidance for consumer credentials, you can do that.

  10. 27 Marc Jones
    May 18, 2022 at 5:02 PM

    Question: Can a service provider change their PCI AOC due date because of a merger or acquisition with another company?

    • May 30, 2022 at 10:47 AM

      That is a discussion with the card brands (if registered on their sites), banks that are involved (if at all) and your customers. I have seen that happen, but not without discussions with all of those parties.

  11. 29 JP
    May 5, 2022 at 6:12 AM

    Hi PCIGuru,

    I have observed full pan in the footers / remits of statements from several card issuers Chase, Wells etc. possessing. Understanding that they need this to process transactions whether internal/third party ( ex: MoneyGram etc.) for physical mailings, but finding it hard to understand how reference IDs/surrogate values are not required. I suspect they would say its the course of business, presents minimal fraud risk, and would be a lift on the backend core processing to correlate that surrogate to PAN, but PCI is clear that full pan needs to be masked/sanitized. Thoughts? Thx

  12. 31 Erik
    April 27, 2022 at 8:10 AM

    I’m curious on your opinion of how the use of EMVCo tokens (and similar tokens) affect PCI DSS scope for a Merchant. PCI FAQ 1326 says that the token and cryptogram are not Account Data (not in scope). However, Mastercard MDES guidance states that storing the Token and Cryptogram is effectively equivalent to storing PAN and PCI DSS should apply.

    Other industry sources I’ve looked at (e.g. Visa) provide no or very vague guidance.

    What’s your take on this?

    Regards,
    -Erik

    • April 28, 2022 at 7:58 AM

      Another area where the Brands and Council are at odds. But in that case, the Brands win. I always advise clients to take the worst case, in this case Mastercard, and follow that guidance. If Mastercard says it is not allowed to be stored, then don’t store it.

  13. 33 Robert
    April 20, 2022 at 4:51 AM

    Since this blog reaches such a large audience, I’m hoping that I can ask a question of the community.

    Has anyone translated the PCI DSS v4.0 Standard into French? I’m hoping someone has already done this work.

  14. 35 Erik
    March 11, 2022 at 2:52 AM

    I’m trying to understand the impact of 8-digit BINs on PAN truncation. From the current version of PCI FAQ#1091, it seems storing the full 8 digit BIN + any other 4 digits is OK for all brands except Amex. Amex still accepts no more than First 6 + Last 4.

    If I understand this correctly, it means that the truncation function needs to determine the card brand for each PAN and then apply different truncation methods (assuming you want to store the whole BIN).

    Is that correct, or did I misunderstand something?

    • March 19, 2022 at 1:23 PM

      Nope. Your analysis appears correct. That said, this is where things will get messy and people will screw up. It will get even worse when multiple groups in the same organization use different truncation rules where it will get really messy and create the compliance issues.

      • March 19, 2022 at 9:09 PM

        Visa has muddied the waters here a bit recently. This Visa FAQ document states you would also need to encrypt, hash, or tokenize anything more than the first 6 and last 4.

        Click to access visa.com-numerics-faq.pdf

        “PCI-DSS allows exposure of the first six and any other four digits in a PAN as the only method
        for protecting data at rest. If a merchant would like to expose the full eight-digit BIN as well as
        the last four digits, they will need to add one or more of the other acceptable methods for data
        protection, such as encryption, hashing or tokenization. Merchants should consult their Qualified
        Security Assessor (QSA) prior to implementation”

        Contradicting FAQ 1091 on the council’s website.

      • 38 Erik
        April 28, 2022 at 12:46 AM

        One thing I think will really mess things up is the difference between truncation and masking. Very few people I meet (even QSAs) understand the difference between truncation and masking. That used to be no big deal, because the rule was the same for both.

        Now we have the new 8 digit BIN rules for truncation, while masking is still 6+4…

      • April 28, 2022 at 8:00 AM

        It’s a problem waiting to happen particularly in organizations with multiple teams and everyone picks their particular version of truncation. What could possibly go wrong? 😉

  15. 40 Deepak
    January 6, 2022 at 9:14 AM

    Hi Guru,

    Kindly can you share or refer a link for PCI-DSS Network Pentesting checklist.

    Thanks,
    Deepak

  16. 42 Clobert
    November 22, 2021 at 12:50 PM

    If an entity is using a SIEM with installed agents that report to a cloud instance of the SIEM, and that SIEM doesn’t have an AoC, and the QSA decides to assess the SIEM ad hoc for the current RoC, how rigorous, or which of the 12 sections would the QSA assess on that SIEM? (not meant to sound like a limerick)

    • November 23, 2021 at 1:38 PM

      All the requirements that apply which, sadly, is most of them.

      Obviously section 10, but also section 1 (it has a network that connects the SIEM), section 2 (it’s some sort of HW/SW either real or virtual), section 3 (the QSA must prove that the SIEM does not store SAD/CHD), section 5, section 6 (vuln mgmt and change mgmt), potentially sections 7 and 8 (depending on how authentication and user management are performed), section 9 regarding the physical security of the hosting DC, section 11 (wifi at the DC and then vuln/pen testing), finally section 12 for the DC’s employees.

  17. 44 Erik
    October 28, 2021 at 7:09 AM

    Hi,

    I’m curious if you have any comments on the recent FBI investigation into Pax Technologies, as reported by Brian Krebs and others. Should merchants who have Pax terminals be worried?

    • October 29, 2021 at 4:33 AM

      From what I have read and in talking to others, the problem is NOT with exposure of SAD/CHD it is that these devices are being used to compromise networks. Also, it seems that the POI in question are wireless, not the wired POI. But time will tell if wired POI are also an issue.

      That said, I have worked with a number of merchants that are using the PAX POI and I was always concerned with the fact that PAX had unfettered access to “monitor” and “update” those POI in a lot of cases even though the processors typically handle that task with Verifone and Ingenico POI. In one case, BoA required me to write a CCW for the PAX access because I brought up the fact that PAX was NOT PCI compliant and could not provide an AOC for their monitoring and updating.

      It will be very interesting to see how this plays out.

  18. 46 Marc Jones
    September 17, 2021 at 8:54 AM

    Would you accept a self-signed AOC where the SAQ-D was dated 3-months prior to the officer’s signature?

    • 47 Marc Jones
      September 17, 2021 at 8:54 AM

      Actually, it’s 4-months, not 3

      • September 17, 2021 at 12:29 PM

        Self-signed SAQs are always a concern, but given how the card brands treat them, they are legal representations by the person signing them that the organization is PCI compliant.

        As with any executive, documents get “lost” in their inbox and they do not get signed in a timely manner. If it is signed, it is a legal representation that the organization is PCI compliant and should be treated accordingly. That said, it is up to the receiving organization as to whether or not they accept that representation. If you are uncomfortable with that time frame, it is within your rights to reach out to the organization with your concerns and talk through those.

  19. 49 shane
    September 7, 2021 at 8:09 AM

    We recently changed vendors/applications for our front desk and now all CC transactions are run through a 3rd party. If the old servers are still on, but are no longer processing CCs (haven’t been for 3 months) are they still in scope for this years audit?

    • September 10, 2021 at 5:48 AM

      If they still have card data on them, yes they are until you properly decommission and wipe them.

      • 51 EDY NGAMKHAO
        September 10, 2021 at 6:27 AM

        HI. Would this also be true for HSM hardware? If MFK and all keys are removed, reset to factory? I recall something regarding the chain of custody upon initial possession of the HW but can not find anything upon retiring the devices and if the HW must be sent back to the MFG or can be recycled.

      • September 12, 2021 at 11:48 AM

        Most HSMs have a factory reset or similar utility that will securely decommision the device which would remove all sensitive information in the HSM. Provided it has that capability, it should not matter whether you recycle it or send it back to the manufacturer. That said though, I would probably lean towards sending the device back to the manufacturer regardless.

  20. 53 Brendan
    August 30, 2021 at 10:58 AM

    I work for a company that sells products. We pay a third party company to handle our credit card transactions (we don’t store numbers, we take them over the phone and put them straight into this vendor’s website). As such, we might need an SAQ C-VT. However, the employees who are taking the numbers work for another third party and so does the building they work in and all the equipment. So company A is a subcontractor of ours and they run the entire call center that takes the numbers. Thus, our direct employees and our direct equipment do not ever touch credit card numbers. My question is whether we need to fill out the SAQ, or company A does, or both?

    • August 30, 2021 at 3:49 PM

      The answer is going to depend on whose merchant identifier (Merchant ID) is being used to conduct the card transactions.

      If it is YOUR company’s merchant ID, then your company needs to fill out an SAQ A because everything is outsourced. However, for requirement 12.8, you will need PCI Attestation of Compliance (AOC) from your two outsourcers.

      If the outsourcers are running the transactions through their merchant IDs and just sending your company a check, you should have their AOCs on file to prove annually that they are compliant but your company does not need to fill anything out.

  21. 55 Erik
    August 16, 2021 at 4:56 AM

    Hi,

    I’ve encountered a strange practice from an Asian processor/acquirer, where half the card PIN code (first 2 digits) is sent as part of authorisation for e-commerce payments.

    They claim the half PIN code is not in scope for PCI DSS. As far as I know, there are no truncation rules for SAD. To make the PIN unreadable, you have to use cryptographic methods.

    Protecting the transmission isn’t a problem, but would the half PIN code “contaminate” systems it passes through with PCI DSS requirements? I’m inclined to say YES.

    How would you approach this?

    • August 16, 2021 at 9:48 AM

      I think you mean the card verification value (CVV) rather than the PIN. The PIN would only work in a card present transaction scenario and you are speaking about an eCommerce transaction.

      CVV is considered sensitive authentication data (SAD) and is required to be protected at all times and cannot be saved once a transaction has been either approved or declined. Splitting the CVV is not going to remove any intermediate systems from scope, so there is no scope reduction in my view.

      Besides, we are talking about a four digit number that can be easily guessed if you have half of it.

      • 57 Erik
        August 17, 2021 at 2:55 AM

        As far as I’ve been able to tell, it is actually the card PIN, not the CVV. I think it may be some kind of wierd effort to get better authentication of e-commerce transactions, without using proper 3DS.

        Thanks for your input! It confirms my view that SAD cannot be made unreadable by truncation.

      • August 18, 2021 at 7:27 AM

        If it is the PIN, how do they compare it to the PIN block? That is how the whole thing works. Without the card and the PIN block, the transaction fails. This sounds like some sort of scheme to obtain people’s PINs, not a security measure.

      • 59 Erik
        August 23, 2021 at 7:24 AM

        As far as I’ve found out, it appears to be a standard practice in Korea to require CVV and half the PIN code for e-commerce authorisations. I have no idea of how they actually use it.

        I’m still trying to verify if it is used for all cards, only for local non-branded cards, or just for cards issued by specific Korean issuers.

        The acquirer has now changed their mind, and say the half PIN is indeed in scope for PCI DSS.

        Strange case indeed…

        Thanks for your input!

      • August 23, 2021 at 12:40 PM

        I have a couple of clients in South Korea and neither uses half the PIN with eCommerce. I have also checked with some colleagues that have clients in SK and none of them have encountered it there either. Granted, all clients are subsidiaries of US-based retailers, so that might have something to do with it. But this is the first time we have ever encountered it.

      • August 25, 2021 at 7:52 AM

        So, I got more clarification from a QSA colleague. They think you are referring to the South Korean MyPIN or iPIN which is a personal identification number of 13 digits and has nothing to do with a payment card PIN. The MyPIN was introduced to reduce online fraud.

      • 62 Erik
        October 29, 2021 at 12:51 AM

        Hi,
        We did double-check several times with the Korean processor and they confirmed that it was indeed half the actual PIN code for the card. I guess it works because they are also Issuer/Acquirer and processor for these cards. The half-PIN was not used for cards from other issuers. The cards are PCI-branded (Mastercard or Visa I think), so they are in scope for PCI DSS.

        Strange case. I guess when you don’t have proper solutions available (like 3D-Security), companies will come up with “home-made” solutions to solve problems.

      • October 29, 2021 at 4:34 AM

        Interesting, but you are probably right. When in a vacuum, nature finds a way to fill it.

  22. 64 Nagu Sittampalam
    June 14, 2021 at 10:37 AM

    Hello PCIGuru

    I have question with regards to taking Credit Card Payments over the phone in the current corvid climate where people are asked to stay in. In a situation where you do not have a phone automated payment system are their any requirements to be compliant taking payment over the phone apart from the obvious once like not to write down Credit card numbers, do not repeat the number back etc..
    Regarding automated payment system are there any exceptions/catering for visually impaired people?

    • July 3, 2021 at 9:07 AM

      I think you have the basics down. Where telephony payments get into trouble is over voice over IP (VoIP) because the Council considers that no different than transmission of CHD/SAD as digital data. There is an Information Supplement on Telephony Security on the PCI SSC Website that you should read concerning VoIP.

    • July 3, 2021 at 9:08 AM

      In regards to visually impaired, I am not aware of any exceptions offered for solutions that cater to them.

  23. 67 Marc Jones
    April 21, 2021 at 8:17 AM

    Can you shed some light on what constitutes a “shared hosting provider” Requirement 2.6?
    For example, if I use AWS to host my web application for looking up credit bureau information, am I considered a shared hosting provider?

    • April 23, 2021 at 9:51 AM

      From the Guidance column of the PCI DSS v3.2.1.

      “This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client’s data and thereby gain access to all other clients’ data. See Appendix A1 for details of requirements.”

      Under this definition, the best example of a shared hosting provider would be one that hosts a single instance of a Web-based eCommerce application that multiple organizations all use. Each organization’s data and users are segregated from one another, but they use the same application instance.

  24. 69 Deep Haria
    April 18, 2021 at 7:39 PM

    If the merchant is using Non-VoIP based PRI (Primary Rate Interface) to transmit and collect CHD, would this bring the telephony infrastructure (SBC, PBX, etc.) in scope for PCI? or Can they be NA as it is not VoIP based.

    • April 23, 2021 at 9:44 AM

      No. You cannot mark them as “NA” because they do process and transmit CHD/SAD. You must acknowledge the risk (msall as it is) and what you do to mitigate or remove those risks.

  25. 71 johnswk
    March 29, 2021 at 10:22 PM

    My organisation uses gmail using SSO to access their customer care call management software. The call management software is cloud hosted and they are PCI compliant. My question is whether using free gmail accounts to access the call management software prevents us from becoming PCI DSS compliant?

    • March 31, 2021 at 4:07 PM

      I think what you mean is that your personnel access your hosted Call Management solution using their GSuite SSO. If that is true, GMail (or any of the other GSuite apps) has nothing to do with anything other than the SSO solution grants access to all applications covered by the SSO solution.

  26. 73 Andrew Madejczyk
    March 29, 2021 at 12:10 PM

    PCIGuru

    quick question.

    Is there any value to having a QSA assist with completing a SAQ-D over just paying for the ROC? The cost difference not being much different. What I am asking is, do you see a benefit of doing one over the other?

    • March 31, 2021 at 4:15 PM

      IMCHO, an SAQ D is more like a auditing an education class versus actually attending the class to get a grade (i.e., ROC). Both however result in an Attestation Of Compliance (AOC) which is what you turn over to a customer if you are a service provider.

      The only difference would be with your acquiring bank who would likely prefer to see a ROC vs. an SAQ D, even when a QSA does an SAQ D. Sadly though, I know of firms that do not do much, if any, examination of evidence and just check the boxes, sign the AOC and move on. Which is why banks prefer the ROC over the SAQ.

  27. March 24, 2021 at 1:36 PM

    Regarding Bearer Tokens:
    One of my programmers recently asked me if there are any PCI DSS requirements regarding bearer tokens. Specifically, he is asking how often does PCI DSS recommends they be changed (rotated). I am unfamiliar with Bearer Tokens and have not been able to find any direct PCI DSS requirements that would influence the bearer tokens. I did find the RFC (https://tools.ietf.org/html/rfc6750), which has some recommendations regarding the rotation, but would like an expert’s opinion on how Bearer Tokens should be managed and secured in an environment that is within the scope of PCI DSS.

    • March 25, 2021 at 6:37 AM

      There is no guidance on this topic currently and I do not recall it being discussed in any of the v4 drafts, so I would expect no explicit guidance coming from the PCI DSS in the future. The Council may create an Information Supplement to discuss the topic, but that also is something for the future.

      That said, section 5 of the RFC has a great discussion on threats and mitigations to protecting the bearer tokens and I would use that as your reference.

      My guess would be you would want to rotate the token however often it makes sense based on the information being protected. General business information could have the token rotated annually or semi-annually. Payroll information might want a token rotated monthly.

  28. 77 Lloyd
    March 18, 2021 at 6:31 AM

    Hi

    Thanks for the excellent site. Really useful.

    I have a question regarding devices from iZettle (and this probably refers to others such as Square).

    I understand that in this case, iZettle is the merchant, and therefore responsible for PCI DSS compliance. If I want to use these devices on a corporate LAN, where do I stand? Do I need to implement a segregated network, and complete a SAQ? Or do I just take iZettle’s statement at face value, and do nothing special?

    • March 19, 2021 at 4:01 PM

      Good questions.

      Unfortunately, we need more information to get you answers. I went out to the Zettle Web site and could not find any information on their POS solution. I assume it is end-to-end encrypted, but without explicit proof of that, I cannot say if you need to segment your network.

      Technically, Zettle is your acquiring bank, so they would be the ones requiring your organization to file an SAQ with them. If they are not requesting one, then you do not have to do one. That said though, I would recommend doing an SAQ B-IP for this solution just to make sure that you have all of those requirements covered.

      One other thing you need to do is to have an incident response plan in case the POS solution is tampered with or hacked. You will also need to have a procedure in place to examine the POS periodically to ensure that it has not been tampered with.

  29. 79 Pat
    March 5, 2021 at 5:14 PM

    Hi Guru,

    Our organization’s PCI program is maturing, and we are now expanding our requests for AoC’s beyond just those service providers who use our MIDs on our behalf. We’re now asking for AoCs from vendors who use their own MIDs, but may pose a risk to our “brand”.

    For example, an outsourced foodservice vendor with their own MID, POS system, employees, and network connectivity, but operating on our premises, and handling credit card data of our customers and employees.
    Because of the risk to our customers, employees, and our organization’s “brand” from a breach, we are requesting their AoC. In response to our request for an AoC, if a vendor asks “what does PCI AoC stand for?”, we believe we may have identified a credit card data risk that needs to be addressed.

    Q1: What are your thoughts on this?

    We asked the vendor whose name appears on the onsite vending machines (which accept credit card payments) for their AoC. They informed us that the vendor we contracted with for vending machine services actually subcontracted to them, and they in turn subcontracted to a third vendor. While we think we need an AoC from the party with whom we initially contracted, they would not be reasonably able to attest to what the 3rd subcontractor is doing.

    Q2: Can we accept an AoC from this “3rd vendor / 2nd subcontractor”?

    Q3: If this were an actual PCI-defined service provider, could we accept an AoC from a party we don’t directly contract with, or does that necessarily have to be attested to by the service provider we contracted with?

    –I really hope that made sense!

    And thanks, guru!

    Pat

    • March 6, 2021 at 8:21 AM

      To your Q1, good luck with that. The vendor is technically correct in that it is whatever subcontractor that is responsible. That said, the vendor should have that AOC as part of their due diligence.

      As to Q2, that is up to you. There is nothing in the PCI DSS that says otherwise.

      For Q3, if you talk to your legal counsel, your organization has contracted through the legal process with the entity that is responsible. It is not direct, but all parties are legally bound, so technically there is accountability for compliance.

  30. 81 Frank
    February 16, 2021 at 7:53 AM

    Hello guru

    I have a question about searching credit card information on the Deepweb/Darkweb.
    I enter my credit card number in the system of a service provider and he regularly searches for this number in the darknet, in various forums.
    Do service providers who offer such services and store the credit card number in their systems have to be PCI-DSS certified and if so is a SAQ sufficient ?

    thank you
    Frank

    • February 17, 2021 at 1:03 PM

      They should be PCI compliant, but I am guessing you are pointing out a gap in PCI compliance that flies under the radar.

      That said, an SAQ is fine as long as they do not handle more than 300K PANs. More than that and they should perform a Report On Compliance (ROC).

  31. 83 FRK
    January 7, 2021 at 5:44 AM

    Hi Guru,

    How can one provide evidence to the PCI auditor for requirement 4.1.c if the environment resides in AWS VPC and using wireshark is not possible?

    4.1.c Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.

    Thanks

    • January 18, 2021 at 3:43 PM

      In this case you would have to rely on the configuration of the HTTPS and TLS certificate or whatever else is being used to encrypt the connection. You then say that you observed that HTTPS appeared in the browser or that you observed that the connection was encrypted.

      Serverless, virtual networks, etc. create a number of issues that are not easily addressed in the current PCI DSS because it was written before such technologies exist. Not that they cannot be addressed, you just much be creative in getting your evidence.

  32. 85 Lloyd
    December 3, 2020 at 4:41 AM

    Hi

    I have a scenario where we have outsourced our online event ticketing to a compliant service provider. They handle all payment functions, using one of our merchant ids. My question is this. Where do we stand if we allow a member of the public to access the booking website to make their booking and pay for their tickets at one of our physical locations, using our PC, network etc.? I can’t decide if this will bring our network into scope or not.

    • December 8, 2020 at 5:39 PM

      If the payment is occurring on a device and network you own, yes, it will be in scope. That said, if you use a payment terminal (aka POI) that is a P2PE or E2EE device and you use tokenization, then only the POI is in scope.

  33. 87 Paul
    November 16, 2020 at 9:56 AM

    Hello,

    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. https://www.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf

      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.

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

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

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

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

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

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

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

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

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

  39. 106 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?

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

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

      Thank you 👍

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

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

    Cheers,
    Joe

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

  43. 118 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 Authorize.net (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 pay.gov. 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/payer.do?orderType=” 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 ticketmaster.com)? 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.

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


Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Connecting to %s




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

September 2022
M T W T F S S
 1234
567891011
12131415161718
19202122232425
2627282930  


%d bloggers like this: