Protecting CUI is the easy half. Knowing everywhere it goes is the hard one.
Defense and aerospace suppliers usually already own the security products an assessor expects to see. What they usually cannot yet do is name every system, mailbox, share and subcontractor that holds Controlled Unclassified Information (CUI), and show that each one is protected. That inventory is where the work starts.
The challenge isn't simply protecting CUI. It's knowing everywhere your CUI goes.
What CUI may look like here.
Examples of information that may constitute CUI when appropriately designated or contractually identified include:
- Technical drawings
- Engineering specifications
- Controlled Technical Information (CTI)
- Test results
- Engineering change information
- Technical manuals
- Program documentation
- Export-controlled information
- Supplier and subcontractor technical information
The path a file takes.
- Prime Contractor
- Program Manager
- SharePoint/Teams
- Engineering Workstation
- Subcontractor
- Deliverable
Where it goes wrong.
CUI is distributed, and nobody holds the map
CUI tends to become distributed across engineering, program management, Microsoft 365, endpoints, email, SharePoint and Teams, and subcontractors. Each group knows its own corner. No one document says where all of it is, so the first honest answer to "where is your CUI" is usually a list that grows every time someone asks a different department.
Security products are mistaken for demonstrated compliance
The issue is often not whether security products exist. It is whether the organization knows everywhere CUI exists and can demonstrate that the applicable systems and processes are properly protected. A firewall, multifactor authentication and endpoint detection are inputs. The assessment asks for the evidence that each control is implemented on each in-scope system, and that evidence is rarely collected until someone asks for it.
The subcontractor boundary is assumed, not defined
Technical information flows down to suppliers because the program requires it. What is seldom written down is which suppliers receive CUI, through what channel, and under what flow-down obligation. The prime will ask. Without a defined list, the answer becomes an audit of email history under time pressure.
Program and engineering tools live outside the security team’s view
Product lifecycle tools, engineering file servers, simulation environments and program-management workspaces are usually chosen by the teams that use them. They hold some of the most sensitive technical data in the company and are often the last systems anyone thinks to put inside the assessed boundary.
"We already have IT and cybersecurity."
Having firewalls, multifactor authentication (MFA), endpoint detection and response (EDR) and other security products does not by itself establish CMMC compliance. Those tools are necessary. They are not the thing being assessed. The organization must be able to demonstrate that its CUI environment satisfies the applicable requirements and produce evidence supporting that implementation, control by control, system by system.
In practice this is the difference between an IT department that can say "we have MFA" and a compliance program that can say "here is the list of every system in scope, here is the policy that requires MFA on each, here is the configuration export that proves it, and here is who reviewed it last quarter." The security team you already have is where the evidence will come from. What is usually missing is the scoping, the documentation and the collection discipline that turn its work into something an assessor can accept.
An environment that holds.
- 01
- A written CUI inventory and flow map — One maintained record of where CUI enters, is stored, is processed and leaves, covering program management, engineering, Microsoft 365, endpoints and every subcontractor channel. It is the document the rest of the program is scoped against, and it is updated when a new program or supplier is added, not rediscovered before each assessment.
- 02
- A defined boundary that includes the engineering tools — The assessed boundary is drawn deliberately to include the file shares, lifecycle tools and workstations that actually hold technical data, and to keep out what does not need to be in. Systems inside are managed, monitored and covered by the System Security Plan (SSP); systems outside have a documented reason for being there.
- 03
- Controlled channels to suppliers — A defined list of subcontractors that receive CUI, a defined method for getting it to them, and a record of the flow-down obligation each one has accepted. Ad hoc email attachments to a supplier are replaced by a channel someone owns.
- 04
- Evidence collected as a routine, not a project — Each control has a named owner, an expected artifact and a collection cadence, so that the evidence for the current period already exists when the Certified Third-Party Assessment Organization (C3PAO) asks for it. Open items are carried on a Plan of Action and Milestones (POA&M) with dates, not in someone’s memory.
The order we do it in.
- 01
Discover CUI
- 02
Define Scope
- 03
Identify Gaps
- 04
Design Controls
- 05
Implement
- 06
Collect Evidence
- 07
Prepare for Assessment
- 08
Maintain Compliance
This is the CMMCg Method applied to your environment. Read the Method →
Open these first.
The working documents from the CMMCg Resource Library that fit this kind of organization, in the order to use them.
CUI Identification Worksheet
Worksheet to list the information your organization receives, creates, processes or transmits that may constitute CUI, with origin, access, storage and marking.
Open →CUI Flow Mapping Template
Template to trace each CUI type from receipt through processing, storage, transmission, sharing and disposition, and mark where it leaves your boundary.
Open →CMMC Scoping Worksheet
Worksheet to sort people, systems, endpoints, networks, cloud services, facilities and providers into CMMC asset categories, and defend every exclusion.
Open →CMMC Level 2 Readiness Checklist
High-level readiness review across all 14 NIST SP 800-171 Rev 2 requirement families that CMMC Level 2 assesses, 3 to 5 review prompts per family.
Open →CMMC Evidence Collection Tracker
Evidence register for each practice: expected evidence, source, artifact owner, interview owner, technical validation, collection and validation status, gaps.
Open →
Further along than that? The path continues with the Evidence Collection Tracker, the Gap & POA&M Tracker (a POA&M is a Plan of Action and Milestones) and the Assessment Preparation Checklist.
Does this look like your environment?
The readiness call starts from where your information actually goes, not from a template. An engineer runs it.
- Your CUI boundary sketched on the call
- The requirements costing you the most points, named
- A written summary afterward, yours to keep
NDA signed before anything technical. No cost, no obligation.