CMMC Frequently Asked Questions (FAQ)

NOTE: Read the footer of the website as a reminder that is information is for educational use and it is "use at your own risk" content.

This page is meant to serve as a repository for common "questions & answers" pertaining to CMMC & NIST 800-171. This is broken into two different sections: (1) fact-based and (2) opinion-based. You will note that the fact-based answers directly reference authoritative sources. The opinion-based answers are exactly that - opinions, since there is a lack of guidance from the DoD or CMMC-AB to provide an authoritative answer. If you don't like that, we really could care less - we are doing this for people who actually give a shit and want to have the least painful CMMC experience possible.

​Since we don't really have anything else better to do, you can email us your questions that we do not currently post answers to. We might be able find a solution... then again, we might not. Seriously, share your questions with us. Consider it a dare!

Fact-Based Q&A

This section attempts to provide direct authoritative guidance.

​1. What is the assessment criteria for CUI?

NIST SP 800-171A is the authoritative source for assessing CUI.

The US National Archives (NARA) published CUI Notice 2020-04: Assessing Security Requirements for CUI in Non-Federal Information Systems that is authoritative guidance for assessing CUI. In section 6 (assessment guidance), NARA states, "When any entity assesses compliance with the security requirements of NIST SP 800-171, they must use the NIST SP 800-171A procedures to evaluate the effectiveness of the tested controls. NIST SP 800-171A is the primary and authoritative guidance on assessing compliance with NIST SP 800-171."

 

2. Do I need a network diagram and/or Data Flow Diagram (DFD)?

Yes. Go to NIST 800-171A 3.1.3[c]. In order to "control the flow of CUI in accordance with approved authorizations" as required in 3.1.3, the assessment criteria in NIST 800-171A (3.1.3[c]) requires an assessor to determine if "designated sources and destinations (e.g., networks, individuals, and devices) for CUI within the system and between interconnected systems are identified."

It is not feasible to demonstrate the NIST 800-171A assessment criteria without a network diagram and/or a DFD.

 

3. We make COTS widgets. Are we in scope for CMMC?

Per the official CMMC's FAQ page, "Companies that solely produce Commercial-Off-The-Shelf (COTS) products do not require a CMMC certification."

However, this "official DoD guidance" does not mean your customers will not contractually require you to earn a CMMC certification in order for them to still purchase from you, since that purchasing decision is at the discretion of the customer. If you want their money, you have to do what they want. Otherwise, do not sign the contract!

 

4. What is CUI?

NARA is the authoritative source for defining CUI and operates the CUI Registry.

 

5. Is Personally Identifiable Information (PII) considered CUI?

It depends who "owns" the PII:

• If you are storing/transmitting/processing PII of your employees or customers then that is not considered CUI.
• If you are storing/transmitting/processing PII for the government, that "government owned PII" is considered CUI per NARA guidance in the CUI Registry (https://www.archives.gov/cui/registry/category-detail/sensitive-personally-identifiable-info)

 

6. Do I need a Plan of Action & Milestone (POA&M) or "plans of action" for CMMC & NIST SP 800-171?

Yes. You do have to maintain plans of action to be considered compliant with both NIST SP 800-171 and CMMC:

• From a NIST SP 800-171 perspective, control # 3.12.2 addresses the use of a Plan of Action & Milestone (POA&M) by requiring DoD contractors to "Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.". NIST SP 800-171A provides greater detail as to the requirements around POA&Ms:
• 3.12.2[a]: deficiencies and vulnerabilities to be addressed by the plan of action are identified.
• 3.12.2[b]: a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
• 3.12.2[c]: the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.
• From a CMMC perspective, CA.2.159 requires an OSC to do the exact same thing at NIST SP 800-171 #3.12.2. However, in DFARS 252.204-7020, it states, "The CMMC framework does not allow a DoD contractor or subcontractor to achieve compliance status through the use of plans of action."

The issue with POA&Ms and CMMC is that you need to have a completed or blank POA&M at the time you are officially assessed for CMMC compliance, otherwise the OSC will fail due to the "zero tolerance" policy by the DoD PMO for CMMC-related deficiencies. The day after the assessment is complete, all the way through the next assessment, the OSC can fill a POA&M with lots of crazy shit and that is completely ok. It would be nice if that wasn't the case, but the DoD has not provided any clear guidance on remediation requirements associated with NIST SP 800-171 & CMMC control deficiencies.

 

7. What does it mean to be "FIPS validated" for encryption in NIST SP 800-171 3.13.11 & CMMC SC.3.177?

This is a highly-contentious topic due to the wording included in the requirement, "Employ FIPS-validated cryptography when used to protect the confidentiality of CUI." The issue is "FIPS-validated" and that means the technology that you use to encrypt CUI in-transit or at-rest (including backups) has to come from this list of NIST-approved solutions in the Cryptographic Module Validation Program (CMVP). If your hardware/software is not on that list, then it is NOT a viable solution since it is not FIPS-validated. Yeah, that kind of sucks.

 

​8. WTF needs to be in the System Security Plan (SSP)?

This is another highly-contentious topic due to the antiquated nature of NIST SP 800-181 ("gold standard" for SSPs being nearly 16 years old), the semi-official guidance from the DoD in 2018 and the overall lack of any current guidance on SSPs from the DoD or CMMC-AB to provide clarification. DI-MGMT-82247 (see page 9 of 14) (Contractor’s Systems Security Plan and Associated Plans of Action to Implement NIST SP 800-171 on a Contractor’s Internal Unclassified Information System) was published in 2018 and provides DoD guidance on what minimum content needs to be in a SSP (scroll all the way to "Tab 2" on page 8 of the PDF):

1. Reference Documents: The applicable issue of the documents cited herein, including development dates and dates of any applicable amendments, notices and revisions, shall be specified in the contract.
2. Format: Contractor’s format acceptable.

3. Content: The system security plan (or extracts thereof) shall include a description of system boundaries, system environments of operation, how security requirements are implemented or how organizations plan to meet the requirements, and the relationships with or connections to other systems. Any associated plans of action shall include a description how the Contractor will correct deficiencies and reduce or eliminate vulnerabilities in the Contractor’s information system.

3.1. Cover Page: The cover page of the system security plan (or extracts thereof) and any associated plans of action shall identify the following information:
3.1.1. Title of the document (i.e., Systems Security Plan and Associated Plans of Action for [Name of Contractor’s Internal Unclassified Information System])
3.1.2. Company name
3.1.3. Data Universal Numbering Systems (DUNS) Number
3.1.4. Contract number(s) or other type of agreement
3.1.5. Facility Commercial and Government Entity (CAGE) code(s)
3.1.6. System that this System Security Plan and any associated Plans of Action addresses
3.1.7. Date of latest revision
3.1.8. All appropriate distribution and classification statements/markings
3.2. System Identification: The purpose of the system security plan shall be communicated in this section, to include a description of the function/purpose of the Contractor’s internal unclassified information system(s)/network(s) that is(are) addressed in the plan.
3.3. System Environment: A detailed topology narrative and graphic shall be included that clearly depicts the Contractor’s internal unclassified information system boundaries, system interconnections, and key components. This does not require depicting every device, but would include an instance of operating systems in use, virtual and physical servers (e.g., file, print, web, database, application), as well as any networked workstations, firewalls, routers, switches, copiers, printers, lab equipment, etc. If components of other systems that interconnect/interface with this system need to be shown on the diagram, denote the system boundaries by referencing the security plans or names and owners of the other system(s) in the diagram. Include or reference (e.g., to an inventory database or spreadsheet) a complete hardware and software inventory, including make/model/version and maintenance responsibility.
3.4. Security Requirements: Describe how the Contractor addresses/will address security requirements in each of the following NIST SP 800-171 security requirement families (including basic and derived requirements) for protecting covered defense information in the Contractor’s systems and organizations:

3.4.1. Access Control (3.1.1 – 3.1.x)
3.4.2. Awareness and Training (3.2.1 – 3.2.x)
3.4.3. Audit and Accountability (3.3.1 – 3.3.x)
3.4.4. Configuration Management (3.4.1 – 3.4.x)
3.4.5. Identification and Authentication (3.5.1 – 3.5.x)
3.4.6. Incident Response (3.6.1 – 3.6.x)
3.4.7. Maintenance (3.7.1 – 3.7.x)
3.4.8. Media Protection (3.8.1 – 3.8.x)
3.4.9. Personnel Security (3.9.1 – 3.9.x)
3.4.10. Physical Protection (3.10.1 – 3.10.x)
3.4.11. Risk Assessment (3.11.1 – 3.11.x)
3.4.12. Security Assessment (3.12.1 – 3.12.x)
3.4.13. System and Communications Protection (3.13.1 – 3.13.x)
3.4.14. System and Information Integrity (3.14.1 – 3.14.x)

 

​9. Do I need to be FedRAMP certified?

In most cases, no. Make a cup of coffee and read the DoD Procurement FAQ Q116:

Q116: If a company is using an external Cloud Service Provider (CSP) to provide processing and storage of covered defense information, (i.e., DFARS clause 252.204-7012 requires that the CSP meet requirements equivalent of to the FedRAMP Moderate baseline), depending on the service provided (i.e., IaaS, PaaS or SaaS), some of these FedRAMP requirements are allocated to the client. In this case, does the client (the company contracting with the CSP) have to meet FedRAMP “Moderate” requirements that are NOT mapped to the NIST SP 800- 171 requirements per Appendix D of NIST SP 800-171?

A116: No. The CSP has to meet all of the requirements equivalent to the FedRAMP Moderate Baseline, but if some of these (as is typical) are allocated to the client, the client does not need to meet FedRAMP requirements that are unrelated to the NIST SP 800-171 requirements. If the particular FedRAMP requirement (a control from NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations) is not mapped to a NIST SP 800-171 requirement in Appendix D of NIST SP 800-171, it need not be applied by the client. When the FedRAMP control is mapped to a NIST SP 800-171 requirement, only the actual NIST SP 800-171 requirement need be implemented, which may be somewhat different than its mapped NIST 800-53 control. Note that in some circumstance controls that must be implemented by the CSP may require a reciprocal implementation by the client for the CSP’s control to be effective.

 

 

Assumption-Based Q&A

This section attempts to provide an educated guess, since there is a lack of authoritative guidance that leads us to ponder possible answers based on the available information at hand. If you think it isn't cool that you have to read this page instead of getting something directly from the DoD, please take a few minutes to complain to your local member of Congress about the lack of authoritative information (brownie points for both of your Senators & your House of Representatives member)! We made it even easier for you to do just that - go to https://www.usa.gov/elected-officials to file a complaint. Seriously.

​1. If I don't know what CUI is, what do I do?

Ask questions. We know that can be kind of scary at times to reach out to organizations that provides you with money, but that is just the reality of the situation. How the DoD has handled defining CUI is a giant "shit sandwich" and we all have to take a bite. To minimize that unpleasantness, here are a few options:

• If you are a sub, contact your prime's contracting office and ask for clarification. Document the days/times that you reached out seeking clarification for your records. The prime is supposed to have that information specified in a DD Form 254.
• If you are a prime, contact the contracting officer to have the contract specify exactly what CUI is, if it is not clearly specified on the DD Form 254.

If that does not work, an alternative "get out of jail" approach to demonstrating evidence of due diligence is to document your assessment of what CUI is specific to the contract in a Memorandum for Record (MFR) format.

• Document your assumptions of what CUI is, specific to the contract, based on NARA's CUI Registry.
• Provide a copy of the MFR to the applicable contracting officer with a deadline for their response (give them 2-3 weeks or as you feel is appropriate).
• If you do not hear from them by the deadline, document that.
• Scope your CUI environment based on what you described in your MFR.
• Document further requests for clarification, as necessary.

 

2. Is the System Security Plan (SSP) considered CUI?

By itself, a SSP is not considered CUI. However, if the SSP contains "vulnerability related information" then that SSP could potentially be considered CUI, based on NARA's CUI Registry (https://www.archives.gov/cui/registry/category-detail/info-systems-vulnerability-info.html).

 

3. What do plants crave?

Brawndo "The thirst mutilator" has what plants crave.

 

4. Am I a DoD subcontractor?

That is a great question... let's think through the problem:

• If someone who provides you with $$ for a contract is telling you that you are in scope for NIST SP 800-171/CMMC, there is a good chance that you are in the DoD supply chain and that technically makes you a "defense contractor" in the loosest sense of the term.
• If you store/transmit/process CUI, then you are 100% a "defense contractor" and must comply with NIST SP 800-171 & CMMC Level 3 requirements.

 

5. Is CMMC a maturity model that expects us to evolve from Level 1 to 2 & 3?

No. At first glance, the CMMC looks like a traditional maturity model with its 3 levels and increasingly stringent requirements. However, when you take a closer look at what CMMC levels focus on, it is clear that evolving maturity is not the focus of CMMC. CMMC levels are focused on data sensitivity-based business practices and do not involve evolving maturity.

Maturity models have been around for years. One thing that binds them all is the concept of “continuous improvement” where an organization can measure its capabilities against a benchmark and the expectation is for a continued progression from lower to higher levels of maturity. On the contrary, CMMC focuses on current business practices. For example, a landscaping company that has a DoD contract to mow lawns on a military installation could theoretically be a Level 1 OSC since the contract contains FCI. That same landscaping company will be a Level 1 OSC in 3, 5 or 10 years, since its business model will keep it at a Level 1 (e.g., mowing lawns with only FCI-related contracts). There is no “continuous improvement” for most Level 1 OSCs as that example demonstrates.

There is a widely-held misconception that a Level 1 OSC is going to be limited to small “mom and pop” companies, but that is an inaccurate assumption. An organization is designated a Level 1 when it only stores, transmits and/or processes FCI, not CUI. It is possible to have a Fortune 500 organization be a Level 1 OSC with a robust, well-staffed and mature security program. It is equally possible to have a small company with less than a handful of employees be a Level 2 OSC, even though it has no formal IT infrastructure or IT staff - just a completely virtual/remote workforce business model.

Size and maturity considerations have no corresponding influence on CMMC levels - it is all about the data classification.

 

6. Can I outsource CMMC compliance to my Managed Service Provider (MSP)?

No. The reality of the situation is that the OSC is responsible for securing the confidentiality and integrity of regulated data (FCI/CUI) since that is something that cannot be delegated. This legal obligation requires understanding the co-ownership nature of security controls and maintaining a unified picture of compliance efforts so that any deficiencies can be remediated in a timely manner.

In reality, there needs to be an employee of the OSC who has some form of oversight for all NIST SP 800-171 / CMMC compliance operations. A MSP cannot manage all of your cybersecurity needs, since it likely does not know all of your requirements. Both the OSC and its MSP will likely be in scope for NIST SP 800-171 / CMMC compliance, based on how the MSP may have access to CUI and even possibly storing/transmitting/processing CUI if it is also providing hosting and backup services.

 

7. Where do I start?

Pour a cup of coffee (or something stronger) and read the CMMC Kill Chain to get an understanding of where to start. The CMMC Kill Chain is meant to provide a prioritized approach to addressing CMMC, where you can create a CMMC project plan. It is worth a read.

 

8. How often should I change my password?

Changing passwords should be like changing your underwear... no need to change unless you have an Indicator of Compromise (IoC). Per NIST SP 800-63B, Digital Identity Guidelines, in section 5.1.1.2 (Memorized Secret Verifiers):

• Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically); and
• Verifiers SHALL force a change if there is evidence of compromise of the authenticator.

 

9. How Do We Define Reciprocity and Control Inheritance?

This article concisely addresses the concept of reciprocity vs inheritance for CMMC controls.