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.
PCI Guru 
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.
Well said.
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?
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/