top of page
Timelines Backdrop_edited.png

Auntie Em! Auntie Em! It’s an Acronym!

The yellow brick road to Cybersecurity Maturity Model Certification (CMMC) is paved with one thing. Acronyms.

In order to take your company from “a house dropped on my sister” to the ruby slippers of certification, you will need to become conversant in a series of overlapping terms specific to the Defense Federal Acquisition Regulation Supplement (DFARS), the National Institute of Standards and Technology (NIST), and the National Archives and Records Administration (NARA.) Why, you might ask, has the Department of Defense (DoD) swaddled a civilian-facing standard in a slurry of inconsistent, inaccessible, and highly technical documents? Because the foundation of CMMC’s yellow brick road was laid by flying monkeys.

Just kidding.

In reality, the foundation of CMMC stretches all the way back to the 20th century. Legislation like DoD Instruction 52-30.24, Distribution Statements on Technical Documents, which was originally published in 1987, and the Homeland Security Act of 2002, were instrumental in making CMMC what it is today. These days, documents like DFARS 252.204-7012 and NIST Special Publication 800-171r2 are discussed most often in reference to CMMC. But it is important to understand these documents in their historical context. A series of legislation from different government organizations, under different administrations, at different stages of technological advancement, with different staffs, and with differing sets of priorities underlies the CMMC process as it stands.

As of April 2023, NIST and the DoD are working to standardize, simplify, and fine-tune CMMC requirements. In the meantime, it is important to remember that the CMMC 2.0 model itself is highly nuanced, and therefore it follows that the verbiage used to discuss it is also complex. A concrete discussion of acronyms, definitions, and usage can make this complexity more accessible as the model evolves.


The most common and most crucial sticking point for OSCs is Controlled Unclassified Information, or CUI. CUI is defined in 32 CFR 2002 as, “information the Government creates or possesses, or that an entity creates or possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls,” excluding information that is classified. One of the primary purposes of CMMC is to safeguard CUI systematically across the Defense Industrial Base (DIB). This is particularly so for Level 2 certifications under CMMC 2.0. As discussed in previous blogs, DoD contracting officers were originally given the responsibility to identify CUI in contracts, but this has not been routinely practiced. Therefore, it has become the responsibility of Organizations Seeking Certification (OSCs) to identify CUI in their own systems. So how does the 32 CFR definition help you do this?

To answer that question, it helps to take a look at this DFARS FAQ. It points out that NARA’s CUI Registry delineates CUI into subcategories. This may help OSCs bolster their understanding of the CUI umbrella, which can at first appear to mean ‘anything that isn’t classified, but we don’t want running amok on the internet. Up to you to figure that out.’ According to the FAQ, these subcategories include ‘CUI Basic’ and ‘CUI Specified.' CUI Basic is defined as, “CUI that does not have specific protections set out in a law, regulation, or Government-wide policy.” Meanwhile, CUI Specified is said to recognize:

“...the types of CUI that have required or permitted controls included in their governing authorities. The required/permitted controls referenced for ‘CUI Specified’ are largely dissemination controls – e.g., Distribution B — F for Controlled Technical Information.”

This brings us to another key acronym on the yellow brick road to certification: Controlled Technical Information (CTI).


Controlled Technical Information (CTI), a subcategory of CUI, is defined in DFARS 7012 as, “Information with military or space application that is subject to controls on access, use, reproduction, modification, performance, display, release, disclosure, or dissemination.” Therefore, we can come to understand CTI as a kind of Specified CUI. CTI is always technologically complex or sensitive in such a way that calls for additional safeguards. For example, CTI often takes the form of computer software created for the DoD. More information about —and examples of— CTI can be found in the NARA listing of CUI categories.


CTI brings to mind a similar acronym which may present a point of confusion for OSCs just beginning their dive into CMMC lexicon: Covered Defense Information, or CDI. CDI is defined in DFARS 7012 as,

“...unclassified controlled technical information or other information, as described in the Controlled Unclassified Information (CUI) Registry…that requires safeguarding or dissemination controls pursuant to and consistent with law, regulations, and Governmentwide policies, and is —

(1) Marked or otherwise identified in the contract, task order, or delivery order and provided to the contractor by or on behalf of DoD in support of the performance of the contract; or

(2) Collected, developed, received, transmitted, used, or stored by or on behalf of the contractor in support of the performance of the contract.”

I know what you’re thinking. Hold on. Isn't that paragraph saying CDI is just CUI? And guess what? You’re right. The DoD’s DFARS FAQ discussed briefly above speaks to this. It states:

“The definition of CDI is in line with NARA’s CUI definition. Like CUI, CDI is defined as unclassified information, as described in the CUI Registry, that requires safeguarding or dissemination controls pursuant to and consistent with law, regulations, and Gov’t wide policies. This ensures that even if the CUI Registry changes, CDI will continue to be aligned with the CUI categories and subcategories. Like CUI, adequate security for CDI requires, at a minimum, the implementation of NIST SP 800-171…This statement accounts for any added requirements that may result in CDI that is categorized as CUI specific.”

Flying monkeys. It is important to note that CDI is a term on its way out. Originally defined in DFARS 7012, it makes just a few limited appearances in DFARS 7008 and 7009, outdated discussions of CMMC 1.0, and occasionally community discussions as a synonym for CUI.


The final CMMC acronym I’ll discuss here is Federal Contract Information, or FCI. FCI is defined in the Federal Acquisition Regulation (FAR) 52.204-21, Basic Safeguarding of Covered Contractor Information Systems, as “Information provided by or generated for the Government under contract not intended for public release.”

So is FCI just CUI? Not exactly.

FCI is an umbrella term that includes CUI, CTI, and CDI. However, not all FCI is CUI, in the same way that not all rectangles are squares. All CUI is FCI. All squares are rectangles. A classic example of FCI that is not CUI is banking information, because it’s considered contract data not intended for public release, and yet fails to demand additional safeguards in the way CUI does.


Entering the world of CMMC legislation can be overwhelming, especially for OSC’s with little cyber experience, staff, and/or infrastructure. But just because you aren’t in Kansas anymore doesn’t mean your company won’t find its way. The DoD is expected to streamline the Cybersecurity Maturity Model Certification 2.0 model as soon as Summer 2023. It is hoped that the consolidation, elaboration, and normalization of CMMC language will be a part of this process. In addition, Certified Third Party Assessment Organizations (C3PAO), expert consultants, and free Cyber AB Town Halls are all options for an OSC looking to broaden their understanding of CMMC requirements. Finally, if you have any questions regarding the 2.0 model or its key terms, DCG’s specialists are available to support your organization on its compliance journey at


bottom of page