12
Oct
18

The Requirement 3.2.1 – 3.2.3 Not Applicable Debate

When v3.2 of the ROC Reporting Template came out the QSA/ISA community noticed that requirements 3.2.1 – 3.2.3 could no longer be marked as ‘Not Applicable’.

The rationale the Council gave when they explained why they disallowed ‘Not Applicable’ for these requirements is that they wanted QSAs/ISAs to have to explain what procedures they had followed to confirm that organizations were not storing sensitive authentication data (SAD) in the form of track data, card verification values or PIN blocks.

The push back from QSAs and ISAs was to ask how that was relevant when an organization’s card processing could not come into contact with such information as when P2PE had been implemented?

The Council has long stated that for Level 1 merchants that have, for example, implemented a P2PE solution, they should follow the requirements in SAQ-P2PE to fill out their ROC and mark any requirements not in the SAQ-P2PE as “Not Applicable.  The merchant uses a P2PE validated solution and the requirement is not relevant.”

This Council guidance resulted in the question at the 2016 Community Meeting Assessor Session, “How do you do that for requirements 3.2.1 – 3.2.3 when they cannot be marked ‘Not Applicable’ and do not appear in SAQ-P2PE?”  “Good question.  We will have to get back to you.”, the Council told attendees.

Well, here we are two years and a new version later and these requirements still cannot be marked as ‘Not Applicable’.  A number of people texted me at this year’s Assessor Session to bring this issue up again, but I was tired of arguing and just let it go.

The more I have thought about it, the more I regret not bringing this issue up because it needs to be addressed.

So, if someone attending the Assessor Session at the European or APAC Community Meeting would like to bring this question up, I would appreciate it as would a lot of the QSA/ISA community.


4 Responses to “The Requirement 3.2.1 – 3.2.3 Not Applicable Debate”


  1. 1 Erik
    October 26, 2018 at 1:39 AM

    I would also be very happy if we could get rid of this nonsense of not being able to set certain requirements to N/A. There are requirements in other standards (e.g. PA-DSS) that suffer from the same problem. If a requirement is N/A, it should be marked as N/A!

    The QSA still needs to provide a justification, evidence and a description of the methods used to verify that the requirement is N/A. The description in the RoC (or RoV) for these requirements should be pretty much exactly the same, regardless if it is marked as N/A or forced to “In Place” (even though it is N/A).

    I use SAQ-based scopes for most of my onsite assessments (as described in FAQ 1331). It’s very frustrating not to be able to set these requirements as N/A, even though the instructions from PCI in FAQ 1331 is that they should be set to N/A.

  2. 3 Peter Bourke
    October 14, 2018 at 3:09 PM

    A good question thanks Guru. Another related issue if I may, there are many merchants who use P2PE on premise and also have an ecommerce presence for online sales. The way I read the scoping rules for which SAQ to complete, these merchants fall in to SAQ D scope. This then leads to unnecessary requirements being tested on premise, along the lines of what you have raised. Has anyone previously raised this issue?

    • October 14, 2018 at 5:58 PM

      According to the Council, they could do SAQ A for their eCommerce solution and SAQ P2PE for their brick and mortar. However, the merchant would need approval from their acquiring bank to do two SAQs. If the bank does not approve, then they would have to do an SAQ D and use the two SAQs as a guide as to what requirements are relevant. See my post from seven years ago which is still relevant. https://pciguru.wordpress.com/2011/06/12/my-opinion-on-saqs/


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 )

Google photo

You are commenting using your Google 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


Announcements

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

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

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

Calendar

October 2018
M T W T F S S
1234567
891011121314
15161718192021
22232425262728
293031  

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

Join 2,422 other followers


%d bloggers like this: