A Little Clarity: Not Applicable vs. Not Tested within the PCI DSS

May 8, 2018

Contributors: David Mundhenk CISSP, PCI QSA, PCIP and Ben Rothke CISSP, PCI QSA

If you’re a baseball fan in the AL East, you know there is no ambiguity out there – you either love the Boston Red Sox, or you’re obsessed with the New York Yankees. But within the PCI DSS, there’s an area we have found that causes a lot of head-scratching amongst PCI Qualified Security Assessors (QSA) when attempting to complete an SAQ or RoC. What is the difference between: Not Applicable and Not Tested.

In a PCI DSS Report on Compliance (RoC) or SAQ D, each requirement must be answered with one of the following 5 possible choices:

• In place
• In place with compensating control worksheet
• Not in place
• Non-applicable (N/A)
• Not tested

While the first three are intuitive, it is not so clear what exactly the difference between the last two are. Our friend Jeff Hall wrote about this quandary in his PCI Guru blog in 2016, and we are going to expand on that here. As an aside, Jeff’s blog is an invaluable resource for all things PCI.

At the beginning of the RoC, the council attempts to clarify the matter in the appropriately titled section What is the difference between Not Applicable and Not Tested? But in speaking with many other Qualified Security Assessors (QSA), that explanation is actually more confusing that clarifying.

For example, if an entity does not have any wireless capabilities, then Not Applicable would be the appropriate selection for the respective requirements. This conclusion comes after the QSA confirms that there are no wireless technologies used in their CDE, or any wireless that connects to the CDE, via QSA testing.

What this therefore means is that the QSA can render a ‘Not Applicable’ ruling only after they have tested that it is indeed N/A. It is a prime example of the proverbial trust but verify.

So, what exactly does not tested really mean? The PCI council notes that if a specific requirement is completely excluded from review without any consideration as to whether it could apply, the QSA should check the not tested box.

So, the real difference between Not Tested and Not Applicable is that no testing at all is performed when you select the appropriately named “not tested” box. While with not applicable, there is limited testing to show that the control really is not applicable. So is this a difference in semantics?  Actually no. Only N/A is considered by the PCI SSC to be an affirmative response. So if Not Tested is not an affirmative response, and if a RoC section 4.13 has a disclosure summary for Not Tested responses; then what is a QSA to make of that?

As detailed in the November 2016 Assessor Newsletter, the intent in introducing Not Tested was to achieve a better level of transparency as to the level of compliance and this clarification supports that intent.

In addition, there are sections within the Executive Summary of the PCI DSS Requirements and Security Assessment Procedures reporting document where the QSA must explicitly declare anything that was excluded from the assessment.

 Another approach to take is to make the control as being in place, but with a supporting statement, that details the fact that the QSA has validated the contract, due diligence and/or compliance status of the 3^rd-party.

Ultimately, it is important to understand that if RoC section 4.13 has anything in the disclosure summary for Not Tested responses; or a SAQ has anything marked Not Tested; then it is by definition a non-compliant environment.

If you are confused, you are not alone. But take this to heart; from a PCI perspective, not tested is just a fancy way of saying not compliant.

---

Webinar: Ask Us Your Toughest Questions [Part 4]

Adhering to the PCI DSS 3.2 requirements can be daunting for businesses. Join Herjavec Group's David Mundhenk and three highly-experienced PCI QSAs for an interactive Q&A webinar for all your PCI-related questions. No PCI question is out of bounds.

Date: June 15, 2018 | 12:00 PM EST

Register for the PCI DSS 3.2 webinar on June 15, 2018, and join the PCI Dream Team as they answer all of your toughest PCI questions.

Speakers

• Ben Rothke, Principal Security Consultant at Nettitude
• David Mundhenk, Senior Security Consultant at Herjavec Group
• Jeff Hall, Principal Security Consultant at Optiv Security
• Arthur Cooper "Coop", Security Consultant at NuArx

To register for the webinar, click here.