CMMC Update by Glenda R. Snodgrass for The Net Effect
[ View this email in your web browser ] [ Visit our archives ] [ Sign Up for this Newsletter ]

December 7, 2022

I don't think N/A means what you think it means

In a recent group study session for my Certified CMMC Professional exam (I passed!), there was a lively discussion on the use of N/A in response to whether a control or practice has been MET or NOT MET. There seems to be a bit of confusion about this outside the assessors' world, so I thought I'd tackle that today.

In the context of NIST 800-171, CMMC and DoD Self Assessments, "N/A" or "Not Applicable" has a very narrow definition. For example, 3.1.16 ("Authorize wireless access prior to allowing such connections") could be answered N/A if you do not have any devices in your CMMC scope with wireless capabilities. Hmmm, that's a bit more narrow than you thought, eh? So if you have devices with wireless capabilities that you don't use, you need to have a policy stating that you don't enable wireless access, and procedures defining how you disable it, how you monitor that it has been disabled, etc. (Hint: those need to be actual written documents, not just internal knowledge.)

Do you really want to answer N/A at all?

Most of the assessors I have spoken with seem to agree that they would rather not see N/A in an SSP. They would much rather see the control marked MET, with written policies and procedures outlining how the control is being met (in this case, by preventing wireless access in the CMMC environment).

Isolated systems and the N/A option

It is a common practice, especially in small organizations, to use isolated systems (a standalone computer, or a small network of computers that aren't connected to any other systems, including the Internet) to create an enclave to protect CUI.

(As an aside, even seemingly isolated systems are rarely truly isolated -- Don't you have to get data into that system? Don't you create data in that system that is useless unless you get it out somehow? "Sneakernet" -- walking data between systems using thumb drives or CDs -- means a system isn't truly isolated.)

I have seen SSPs that mistakenly use N/A to answer a control that cannot be met because of this isolation (e.g., patching software). This is a problem! Why?

The DFARS 7012 clause states in part:

The Contractor shall submit requests to vary from NIST SP 800-171 in writing to the Contracting Officer, for consideration by the DoD CIO. The Contractor need not implement any security requirement adjudicated by an authorized representative of the DoD CIO to be nonapplicable or to have an alternative, but equally effective, security measure that may be implemented in its place.

So, if you think you cannot implement one or more of the controls of NIST 800-171, you have to request permission in writing for the variance. If it is approved, you should keep this written permission to show your CMMC Assessor that this variance is allowed.

In this scenario, once you have written permission from the DoD CIO to use an "alternative, but equally effective" security measure, you would then mark this control as MET (not N/A) and explain the security measure that was approved by the DoD CIO.

In conclusion: you really shouldn't answer any control with N/A. Every control should be MET by some means or other.

Need help? You know where to find me!

Remember, you can read past editions of this newsletter on our website, along with tons more information under the CMMC and Resources tabs. Feel free to share this update!

Glenda R. Snodgrass Sincerely,

Glenda R. Snodgrass, CCP
The Net Effect, LLC
251-433-0196 x107

If you enjoy these updates, you might also enjoy my weekly newsletter "Cyber Security News & Tips" -- sign up now!

TNE. Cybersecurity. Possible.

Speak with an Expert


The Net Effect, L.L.C.
Post Office Box 885
Mobile, Alabama 36601-0885 (US)
phone: (251) 433-0196
fax: (251) 433-5371
email: sales at theneteffect dot com
Secure Payment Center

The Net Effect, LLC

Copyright 1996-2024 The Net Effect, L.L.C. All rights reserved. Read our privacy policy