CUI Handler Field Manual: 9 Questions Answered (2026)

Posted: May 21, 2026 to Compliance.

Controlled Unclassified Information, or CUI, is the single most misunderstood compliance topic in the Department of Defense supply chain. Prime contractors get it wrong. Subcontractors get it wronger. Cloud vendors selling "CMMC-ready" services frequently mark documents incorrectly, store them in the wrong enclave, and route them through email systems that are not authorized for the data type they are handling. The cost of getting it wrong is real: a failed C3PAO assessment, a False Claims Act exposure, contract termination, or in the worst case a Government Accountability Office referral that ripples across an entire vendor portfolio.

Petronella Technology Group, a Cyber AB Registered Provider Organization (RPO #1449) headquartered at 5540 Centerview Dr., Suite 200, Raleigh, NC 27606, has spent the last several years inside the CUI workflows of defense manufacturers, engineering firms, and managed-service providers across the Mid-Atlantic and Southeast. The pattern is consistent. Contractors do not fail because they refuse to follow the rules. They fail because the rules are spread across the National Archives ISOO CUI Registry, 32 CFR Part 2002, DoD Instruction 5200.48, DFARS 252.204-7012, NIST SP 800-171 Revision 2, NIST SP 800-172, and a stack of agency-specific implementing guidance documents that very few engineers have actually read end to end.

This field manual answers the nine questions that show up most often during pre-assessment readiness work. It is written for an IT lead, security officer, or contracts manager who needs to brief leadership before signing a DoD prime agreement, or who just inherited a CMMC Level 2 scope and is trying to figure out where the CUI actually lives in the environment. Every answer below is sourced to the underlying federal document. None of it is opinion. Where Petronella Technology Group has a service offering that maps to a specific control or workflow, that is called out explicitly at the end so it does not muddy the regulatory content.

What Is CUI? Basic vs Specified, Defined Against the NARA Registry

Controlled Unclassified Information is government-created or government-owned information that requires safeguarding or dissemination controls under law, regulation, or government-wide policy, but that is not classified under Executive Order 13526 or the Atomic Energy Act. The authoritative definition lives in Executive Order 13556, signed in November 2010, which created the CUI Program and designated the National Archives and Records Administration as the Executive Agent. NARA's Information Security Oversight Office (ISOO) operates the program day to day and publishes the ISOO CUI Registry.

Before EO 13556, federal agencies used more than 100 different markings for sensitive-but-unclassified information. For Official Use Only (FOUO), Sensitive But Unclassified (SBU), Law Enforcement Sensitive (LES), Limited Distribution (LIMDIS), and dozens of agency-invented variants all coexisted with inconsistent handling rules. The CUI Program replaced that patchwork with a single, government-wide framework. Inside that framework, CUI is divided into two procedural categories. Knowing which category your information falls into is the first decision every handler has to make, because it controls which safeguarding and dissemination rules apply.

CUI Basic

CUI Basic is information for which the law, regulation, or government-wide policy that authorizes its controls does not specify particular safeguarding or dissemination requirements beyond the baseline. The handling rules are the standard CUI rules in 32 CFR Part 2002 and the NIST SP 800-171 controls that DoD contractors implement under DFARS 252.204-7012. If a category is listed in the ISOO CUI Registry and the underlying authority does not call out anything special, it is CUI Basic by default. Examples include most general procurement-sensitive information, most controlled technical information at the unclassified level, and the broad category of administrative information that agencies tag as CUI because of privacy or operational concerns.

CUI Specified

CUI Specified is information for which the authorizing law, regulation, or government-wide policy contains specific handling controls that differ from, or add to, the CUI Basic baseline. Specified categories override the baseline only to the extent the underlying authority requires. If the authority is silent on a particular dimension of handling, the CUI Basic rules still apply for that dimension. Examples include export-controlled technical data under the Export Administration Regulations (EAR) and the International Traffic in Arms Regulations (ITAR), nuclear information under the Atomic Energy Act, certain critical infrastructure information under the Critical Infrastructure Information Act, and certain personally identifiable information categories where Privacy Act provisions create additional restrictions.

The practical rule for handlers: if a document has a Specified category banner marking (the format is CUI//SP-CATEGORY//Limited Dissemination Control), you must read the underlying authority for that category, because Basic-level training is not enough. Petronella Technology Group sees roughly one in five CUI documents in a typical defense manufacturer's environment carry a Specified marking, and most are export-controlled technical data that should never leave a CMMC Level 2 enclave on its way to a foreign person.

Who Is Responsible for Applying CUI Markings?

This is one of the most common questions in pre-assessment readiness work, because contractors are repeatedly told that they have to mark their own documents and they are not sure why. The answer involves two roles that 32 CFR Part 2002 defines carefully: the designating agency and the authorized holder.

The Originating Agency Designates

The originating agency, also called the designating agency, is the federal entity that creates or originates the information and makes the determination that it qualifies as CUI under one or more categories in the ISOO Registry. The designating agency is responsible for the initial marking. When the Department of Defense, the Department of Energy, the Department of Homeland Security, or any other CUI-handling agency creates a document that qualifies as CUI, it is the agency's responsibility under 32 CFR 2002.20 to apply the banner marking, portion markings where required, and the designation indicator that identifies the agency, office, and date.

The Contractor Marks Derivative Documents

Here is where contractor responsibility kicks in. Under DFARS 252.204-7012 and the flow-down provisions of DoD Instruction 5200.48, when a contractor creates a derivative document that contains, paraphrases, summarizes, or otherwise incorporates CUI received from a government source, the contractor is responsible for marking that derivative product with the same or stricter controls. If a defense manufacturer receives a Statement of Work that contains CUI//SP-EXPT export-controlled information and the manufacturer's engineer creates a CAD drawing that incorporates dimensions or specifications from the SOW, the CAD drawing inherits the CUI//SP-EXPT marking. The engineer, not the originating contracting officer, is responsible for applying that marking before the drawing leaves the workstation.

The role responsible for the marking action inside the contractor organization is typically the document author, with a designated CUI program point of contact reviewing for accuracy. Most CMMC Level 2 programs assign the CUI POC role to the security officer or compliance lead, with a backup in contracts. The program point of contact is not a regulatory role defined by NARA, but it is operationally necessary, because without one, marking quality drifts within months.

Authorized Holders

An authorized holder is any person who has a lawful government purpose to access CUI and has been granted access by an authorized source. Contractors performing on a DoD prime or subcontract are authorized holders for the CUI categories explicitly identified in their contract data requirements list (CDRL) and in the System Security Plan (SSP) supporting their DFARS 252.204-7012 compliance. Authorized holders must apply markings to derivative material and must reapply or correct markings on material that is found to be improperly marked. This is a quiet but important rule. A contractor who finds that an inbound SOW from the government carries the wrong marking, or no marking when CUI is clearly present, has an affirmative duty to request clarification from the contracting officer and to apply the correct marking to any internal copies pending that clarification.

Who Is Responsible for Protecting CUI?

The protection responsibility is laid out in Section 4 of Executive Order 13556 and operationalized in 32 CFR Part 2002. The roles break down into four categories, and a CMMC program needs to be able to name the people occupying each one before assessment week.

The Designating Agency

The designating agency retains overall responsibility for the lifecycle of the CUI it creates, including deciding which categories apply, training its own workforce, monitoring compliance with the program inside the agency, and making decommissioning decisions when the information no longer requires controls. The Department of Defense delegates much of this through the Office of the Under Secretary of Defense for Intelligence and Security (OUSD(I&S)) and the DoD CIO.

Authorized Holders

Every authorized holder, including every contractor and subcontractor employee with lawful access, is responsible for safeguarding the CUI in their custody. The 32 CFR 2002.14 safeguarding rules require holders to control CUI in a manner that minimizes the risk of unauthorized disclosure, including physical, technical, and administrative safeguards. For contractors, the technical safeguards are operationalized through NIST SP 800-171, the controls baseline that DFARS 252.204-7012 requires.

Senior Agency Official

Each agency designates a Senior Agency Official (SAO) responsible for implementation of the CUI Program within that agency. The SAO is the accountable executive who signs off on the agency's CUI policy, training program, marking guides, and self-inspection program. Contractors do not have an SAO equivalent under 32 CFR 2002, but most mature CMMC programs designate a senior official, typically the Chief Information Security Officer or equivalent, who plays the analogous role for the contractor organization. This is a best practice during a Level 2 or Level 3 readiness engagement, because it gives the C3PAO an accountable named individual to interview.

The CUI Program Manager

NARA, through its ISOO office, designates a government-wide CUI Program Manager and each agency designates an agency-level CUI Program Manager. Contractor-side equivalents are typically the security officer, compliance lead, or a Registered Practitioner (CMMC-RP) brought in through an RPO engagement. Petronella Technology Group's full team of CMMC-RPs commonly steps into the program-manager-equivalent role during a 90-day readiness sprint, then transitions the role to an internal staffer with documented procedures once the program is operating.

Required System and Network Configuration for CUI

This is the question that drives the largest engineering decisions inside a CMMC environment, because the answer determines what gets carved out of the corporate network, what gets put behind a separate enclave, and which cloud services are usable. The configuration baseline is set by NIST SP 800-171 Revision 2 for CMMC Level 2 and by NIST SP 800-172 enhancements for CMMC Level 3. The level of system and network configuration required for CUI is, in plain English, the level that satisfies the 110 controls of 800-171 across the 14 control families, implemented in a way that is documented in a System Security Plan and verified through assessment procedures consistent with NIST SP 800-171A.

The 14 Control Families

Every CUI handling system must address all 14 families. The families are: Access Control (AC), Awareness and Training (AT), Audit and Accountability (AU), Configuration Management (CM), Identification and Authentication (IA), Incident Response (IR), Maintenance (MA), Media Protection (MP), Personnel Security (PS), Physical Protection (PE), Risk Assessment (RA), Security Assessment (CA), System and Communications Protection (SC), and System and Information Integrity (SI). These are not optional menus. A scoping decision that excludes a family because "we do not do that" is almost always wrong. The right answer is usually "we inherit that control from a service provider" or "we have a compensating control that achieves the same outcome," and both of those answers require explicit documentation.

FIPS-Validated Cryptography

One of the most frequently missed configuration requirements is FIPS 140-2 (now superseded by FIPS 140-3 for new validations) validated cryptography. Control SC.L2-3.13.11 of NIST 800-171 requires the use of FIPS-validated cryptography when used to protect the confidentiality of CUI. This means the cryptographic module, not just the algorithm, must appear on the NIST Cryptographic Module Validation Program list. A configuration that uses AES-256 from a non-validated software library does not meet the control. This single requirement quietly eliminates a long list of consumer-grade VPNs, messaging apps, and storage tools from any CUI-bearing network path.

Multi-Factor Authentication

Control IA.L2-3.5.3 requires multi-factor authentication for local and network access for privileged accounts and for network access for non-privileged accounts. This is one of the most-cited deficiencies in DIBCAC and joint surveillance audits, because it is widely under-implemented for service accounts, jump-host accounts, and emergency-break-glass accounts. A configuration baseline that says "MFA enforced for all human users at the identity provider" is not enough if service accounts can bypass MFA via long-lived API keys.

System and Communications Protection

Control SC.L2-3.13.1 requires that the contractor monitor, control, and protect communications at external boundaries and key internal boundaries. The practical implementation usually involves a CUI enclave, sometimes a Microsoft GCC High tenant, sometimes a private virtualization cluster, sometimes a dedicated AWS GovCloud account, with documented boundary devices and traffic policy. The boundary cannot simply be the corporate firewall because the corporate network is almost always out of scope. A boundary device that allows arbitrary outbound traffic to the public internet from a CUI workstation is a Level 2 assessment finding waiting to happen.

Audit Logging

The Audit and Accountability family requires the creation, protection, and retention of audit records sufficient to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. Logs must be protected against unauthorized modification, must include the specific events called out in AU.L2-3.3.1, and must be retained according to a documented retention schedule. The retention schedule should align with the NARA General Records Schedule when the underlying CUI is being held under federal records retention requirements.

NIST 800-172 Enhancements for CMMC Level 3

CMMC Level 3 layers selected enhanced security requirements from NIST SP 800-172 on top of the 800-171 baseline. These enhancements target advanced persistent threat (APT) defense and include penetration-resistant architecture, damage-limiting operations, and a cyber resilient and survivable system construct. The current DoD-selected subset is roughly 24 enhancements at the time of writing, drawn from across the same 14 families. Configurations supporting Level 3 typically add things like dual authorization for privileged actions, threat-hunting capability, and deception technologies. A Level 3 environment is not a slightly more locked-down Level 2 environment. It is an environment built around the assumption that a determined nation-state actor will get a foothold and the architecture has to detect and contain that foothold before exfiltration of CUI occurs.

Petronella Technology Group's CMMC compliance guide walks through each of the 110 baseline controls plus the Level 3 enhancements with implementation notes specific to small and mid-sized defense suppliers.

The CUI Handling Lifecycle: Receive, Label, Store, Transmit, Destroy

Every CUI program eventually has to answer the lifecycle question. What happens to a CUI artifact from the moment it crosses the boundary into the contractor's environment to the moment it is destroyed or returned? The answer is the same regardless of CMMC level, with only the rigor of the technical controls changing.

Receive

CUI arrives by one of several channels: email through a CUI-authorized mail flow (Microsoft GCC High to GCC High, for example), secure file transfer through a contractor-side CMMC-compliant portal, sneakernet on encrypted media, physical mail with appropriate package markings, or, in the case of derivative material, creation inside the boundary. Every channel must be documented in the SSP. The receiving organization is responsible for verifying that the marking on inbound CUI is correct and for applying the correct marking if the originator has under-marked or omitted markings.

Label

The 32 CFR 2002.20 marking rules require a banner marking at the top of each page or screen and portion markings where the agency requires them. The banner format is CUI for Basic, or CUI//SP-CATEGORY for Specified, optionally followed by Limited Dissemination Control markings such as //NOFORN, //FED ONLY, //DL-PERSONS, or //REL TO. Footer or designation indicators identify the controlling agency, office, and the date the marking was applied. Derivative documents inherit the most restrictive marking present in any source document.

Store

At rest, CUI must be protected by physical, technical, and administrative safeguards consistent with 32 CFR 2002.14. Technical safeguards for digital CUI involve FIPS-validated encryption, access control consistent with the principle of least privilege, and audit logging. Physical safeguards for printed CUI involve locked containers in controlled-access areas, with the level of physical control proportional to the sensitivity (some Specified categories carry additional physical-storage requirements). Administrative safeguards include a written storage policy, role-based access reviews, and a marked-inventory procedure.

Transmit

CUI in transit must be protected by FIPS-validated cryptographic mechanisms. Email between CUI-authorized environments commonly uses S/MIME or a CUI-flagged transport such as the Defense Industrial Base (DIB) collaboration spaces. CUI sent to authorized non-government recipients must go through channels documented in the SSP, and any out-of-band channel requires prior approval. Voice transmission of CUI is permitted only on encrypted channels, which is a frequently-missed nuance for organizations that allow CUI discussions over consumer-grade conferencing platforms.

Destroy

Destruction is a regulated step. Digital CUI must be destroyed in a manner that renders the information unrecoverable, consistent with NIST SP 800-88 Revision 1 (Media Sanitization). For magnetic media, that means cryptographic erase, degaussing, or physical destruction. For solid-state media, cryptographic erase plus physical destruction is the conservative path. Paper CUI must be cross-cut shredded to a particle size specified by the relevant agency, with NSA-approved Class 3 shredders being a common contractor choice. Destruction records are mandatory under the next section's review rule.

CUI Documents Must Be Reviewed Before Destruction

This is one of the head questions in the cluster and one of the most frequently mis-answered. The rule, drawn from 32 CFR 2002.18 read together with NARA General Records Schedule guidance and DoDI 5200.48 Section 4.h, is that CUI documents must be reviewed against the applicable records retention schedule before destruction. The shorthand answer is: CUI documents must be reviewed against the applicable Records Disposition Schedule (also called a Records Retention Schedule or NARA-approved records schedule) before destruction.

The longer answer is that the review confirms three things. First, that the document is not subject to a litigation hold, a Freedom of Information Act (FOIA) request, an Inspector General investigation, a congressional inquiry, or any other legal preservation obligation that would override the routine retention schedule. Second, that the records retention period applicable to the document has elapsed. Different categories of CUI carry different retention periods, ranging from a few years for routine procurement-sensitive material to permanent retention for certain historical or controlled technical information. Third, that the destruction method is authorized for the category in question.

NIST SP 800-171 control MP.L2-3.8.3 (sanitize or destroy system media before disposal) and 800-53 control AC-22 (publicly accessible content) are sometimes cited in this context. AC-22 governs the review of publicly-released information for CUI content, not pre-destruction review per se, so do not let that one creep into your destruction procedure. The cleaner statement is: CUI destruction must follow records management review, NIST SP 800-88 sanitization standards, and the agency-specific destruction-record requirement.

Destruction Records

Destruction events should be logged. The log should capture the document identifier or media identifier, the categories of CUI involved, the destruction method, the date, the personnel involved, and a reference to the records schedule disposition authority. These logs themselves may be CUI depending on what was destroyed and should be retained according to the records schedule that applies to destruction certifications, which is typically several years.

Who Can Decontrol CUI?

Decontrol is the formal act of removing CUI status from information that no longer requires safeguarding or dissemination controls. The 32 CFR 2002.18 rule is direct: decontrol may only be performed by the designating agency, by an Original Classification Authority (OCA) in certain limited cases, or by an authorized agency official acting under delegated authority from the designating agency.

Designating Agency

The designating agency that originally applied the CUI status is the default decontrol authority. The designating agency may decontrol on a case-by-case basis, by category through a published decontrol decision, or by a time-based decontrol schedule built into the original designation. Time-based decontrol is increasingly common for procurement-sensitive information that has a natural expiration tied to award announcement or contract close-out.

Contractors Cannot Unilaterally Decontrol

This is the critical rule for contractors. A contractor, no matter how senior, no matter how confident the program manager is, cannot unilaterally decide that a CUI document has lost its sensitivity and remove the markings. The contractor's options are limited to: (1) requesting decontrol guidance from the contracting officer, (2) continuing to protect the information at its current marking, or (3) transferring it back to the designating agency for disposition. Unilateral decontrol by a contractor is a compliance finding and, depending on the category, may constitute mishandling that triggers DFARS 252.204-7012 paragraph (m) reporting obligations.

Limited Dissemination Control Removal

Some Limited Dissemination Control markings (//NOFORN, //FED ONLY, etc.) may be removable independent of the underlying CUI status. The rule is the same: only the designating agency, or its delegated authority, may remove them. A contractor who believes a Limited Dissemination Control is incorrect should request review through the contracting officer.

The ISOO CUI Registry: What It Actually Is

The ISOO CUI Registry is the single authoritative list of CUI categories and the authorities that govern them. It is published and maintained by the Information Security Oversight Office of the National Archives and Records Administration. The purpose of the registry, drawn from 32 CFR 2002.10, is to provide a government-wide reference that defines every CUI category, identifies the underlying law, regulation, or government-wide policy that authorizes its controls, distinguishes Basic from Specified treatment, and documents the marking conventions and Limited Dissemination Controls that apply.

Why the Registry Matters to Contractors

Contractors should consult the ISOO CUI Registry in three situations. First, when a marking on an inbound document is ambiguous or unfamiliar, the registry will clarify what category is being asserted and what the underlying authority requires. Second, when creating a derivative document, the registry confirms which Specified controls flow through. Third, when training employees, the registry's category definitions and examples are the canonical content. Internal training that contradicts the registry will not survive an assessor's review.

Registry Structure

The registry is organized into organizational index groupings (such as Defense, Critical Infrastructure, Export Control, Financial, Immigration, Intelligence, International Agreements, Law Enforcement, Legal, Natural and Cultural Resources, NATO, Nuclear, Patent, Privacy, Procurement and Acquisition, Proprietary Business Information, Provisional, Statistical, Tax, and Transportation) and within each grouping it lists the specific categories. For each category, the registry shows the authoritative document citation, Basic versus Specified status, and the standard marking format.

The Registry Is Living

NARA updates the registry as new authorities are added, retired, or amended. Contractors with a CUI program should subscribe to the ISOO update notifications and have a defined process for reviewing changes against their internal CUI training, marking guide, and SSP. A registry change that affects a category the contractor handles is a controlled change that should flow into the SSP within a documented review cycle, often quarterly.

CMMC Level 1, Level 2, and Level 3: CUI Implications at Each Level

The Cybersecurity Maturity Model Certification program implements the protections required by DFARS 252.204-7012 and adds graduated assessment rigor. Each level handles CUI differently, and the difference matters enormously for scoping decisions.

CMMC Level 1

Level 1 covers Federal Contract Information (FCI), which is information provided by or generated for the government under contract not intended for public release. Level 1 does not authorize handling of CUI. A contractor at Level 1 may handle FCI but must not receive, store, process, or transmit CUI in its Level 1 environment. The 17 controls at Level 1 are a subset of NIST 800-171 mapped to basic safeguarding requirements from FAR 52.204-21. Annual self-assessment is the verification mechanism at Level 1. If your contract requires Level 1 and you discover that CUI is in fact moving through your environment, you have a scoping problem that needs immediate remediation, because Level 1 is not a permissible CUI baseline.

CMMC Level 2

Level 2 is the CUI baseline. The 110 controls of NIST SP 800-171 Revision 2 are required, with assessment by a Cyber AB-authorized C3PAO for most prioritized contracts (a self-assessment path remains for some non-prioritized acquisitions, but the trend is toward third-party assessment becoming the dominant path). A Level 2 environment is designed to handle CUI Basic and most CUI Specified categories. Specified categories that require additional handling (such as some export control or nuclear categories) may still require additional controls layered on top of the Level 2 baseline.

CMMC Level 3

Level 3 is the advanced persistent threat baseline. It applies to contractors handling CUI that is particularly sensitive or that supports critical national security programs. Level 3 layers selected NIST SP 800-172 enhancements on top of the 800-171 baseline and requires assessment by the Defense Industrial Base Cybersecurity Assessment Center (DIBCAC). Contractors operating at Level 3 typically maintain separate enclaves for the most sensitive workloads, with stricter boundary controls, enhanced threat detection, and architectural design choices oriented around damage limitation. The number of contractors expected to hit Level 3 is small relative to the Level 2 population, but the controls cost is meaningfully higher and the cycle time to ready is longer.

Practical Scoping

The single highest-impact decision in a CMMC program is the boundary decision. What is in scope, what is out of scope, and what role do shared-services providers play? A boundary that is too large drags the entire corporate network into the assessment, with controls cost and assessment cost that scales accordingly. A boundary that is too small risks excluding systems that touch CUI and creates assessment findings. The goal is the smallest boundary that fully encloses every system that creates, processes, stores, or transmits CUI, plus the systems that provide security services to that boundary. The Petronella CMMC compliance flagship and the CMMC services page together describe how the firm approaches boundary scoping for Level 2 and Level 3 environments.

Common CUI Handling Mistakes

The following list reflects patterns Petronella Technology Group sees during readiness engagements. None of these are hypothetical. Each one is a real assessment-finding category.

1. Treating CUI Like a Permissions Problem Instead of a Boundary Problem

Many organizations start their CMMC journey by tightening Active Directory permissions and assuming that solves the CUI problem. It does not. CUI is a boundary problem. Until there is a defined CUI enclave with documented inbound and outbound channels, permission tightening is rearranging the deck chairs. Boundary first, permissions second.

2. Allowing CUI Email to Land in the Corporate Mailbox

Email is the single most common CUI ingress channel and the single most common reason that a corporate Microsoft 365 tenant ends up in scope. Routing CUI email through a Microsoft GCC High tenant, or through a contractor-side CUI mail flow, is one of the highest-leverage scoping moves available. Letting CUI flow into a commercial mailbox and trying to remediate after the fact is far harder than configuring the right ingress in the first place.

3. Using Public AI Endpoints With CUI

Public large language model endpoints (ChatGPT, Claude, Gemini, Copilot, Perplexity, and similar consumer-grade APIs) are out of scope as a CUI-handling channel. Submitting CUI to a public AI endpoint constitutes unauthorized disclosure under 32 CFR 2002, and may also trigger DFARS 252.204-7012 paragraph (m) cyber incident reporting if the contractor learns that CUI has been retained or processed in a manner inconsistent with the controls. The right answer is a private AI environment for CUI workloads, with no public LLM connectivity from the CUI enclave.

4. Skipping Portion Markings on Derivative Documents

Banner markings on the first page are not enough. Where the originating agency uses portion markings, derivative documents must also carry portion markings, and the absence of them is a documented finding pattern in C3PAO assessments.

5. Storing CUI Backups Outside the Boundary

Backup tapes, cloud backup repositories, and disaster recovery sites that hold CUI are themselves in scope. A common mistake is to enclave the primary environment carefully while letting backups replicate to a non-CMMC-compliant cloud target. The backup target needs the same controls as the source, or the boundary needs to be drawn to include both.

6. Treating Subcontractors as Out of Scope

DFARS flow-down means subcontractors who handle CUI carry the same protection obligations as the prime. The prime is responsible for ensuring flow-down is in the subcontract and for monitoring subcontractor compliance. A subcontractor breach is the prime's notification obligation in many cases.

7. Confusing FOUO Legacy Markings With CUI

Documents created before the CUI Program may still carry FOUO, SBU, or other legacy markings. Treat any legacy marking as a flag that the document may now qualify as CUI under one of the current categories. Do not assume FOUO equals CUI Basic by default. Review the content against the registry or request guidance from the contracting officer.

8. Letting Mobile Devices Drift Into the CUI Boundary

Mobile device management is one of the quietest scoping risks. The moment a user reads CUI email on a personal phone, that device becomes a CUI-handling endpoint, and the entire mobile fleet may need to be in scope. The cleaner path is to provision separate corporate-issued mobile devices for CUI users, enrolled in an MDM platform that supports the relevant 800-171 controls (configuration enforcement, encryption at rest, remote wipe, and certificate-based authentication). Bring-your-own-device for CUI is technically possible with a heavily-locked containerization solution but is rarely the right answer for small and mid-sized contractors because the operational overhead exceeds the cost of a dedicated device.

9. Outdated Training Materials

An organization's CUI training program is a controls input under the Awareness and Training family. Training built on FOUO-era assumptions, on pre-DFARS 252.204-7012 (2017) guidance, or on third-party content that has not been refreshed against the current ISOO Registry is a finding waiting to surface during assessor interviews. Refresh training annually, validate it against current authoritative documents, and document each employee's completion. Tie completion records to the personnel security file so that an assessor reviewing access lists can immediately verify that every authorized holder has current training.

10. No Designated CUI Handling Procedures Document

A CUI handling Standard Operating Procedure (SOP) is not optional in a mature Level 2 program. The SOP describes how CUI moves through the contractor's environment in concrete operational terms: which mailboxes receive CUI, which storage repositories hold it, who has access, what the inbound marking-check procedure is, what the destruction process is, and how exceptions are handled. The SSP describes controls; the SOP describes the day-to-day workflow. Assessors will ask to see both.

11. Treating the SSP as a One-Time Document

The System Security Plan is a living document. Every meaningful change to the CUI environment, including new user populations, new applications inside the boundary, new third-party services that touch CUI, new boundary devices, and new categories of CUI being handled, should produce an SSP update. A common finding pattern is an SSP that was last updated 18 months ago while the environment has continued to evolve. Maintain the SSP on a documented review cadence (quarterly at minimum) and make the SSP owner one of the named roles in the contractor CUI program.

Putting the Program Together: A Sequenced 90-Day Approach

For contractors approaching CMMC Level 2 readiness for the first time, the sequencing of work matters as much as the substantive controls. Done in the wrong order, weeks of effort get redone. Done in the right order, the program comes together with a defensible audit trail. The following 90-day sequence is the one Petronella Technology Group uses on most boutique CMMC Level 2 readiness engagements.

Days 1 to 15: Scoping and Boundary Definition

Identify every contract that requires DFARS 252.204-7012 compliance. Pull the contract data requirements lists. Inventory the CUI categories present. Map the data flows of how CUI enters, lives in, and leaves the environment today. Draw the proposed boundary on a network diagram with explicit inbound and outbound channels. This step is the highest-leverage one because boundary errors cascade into every control family downstream.

Days 16 to 45: Control Mapping and Gap Analysis

Walk the 110 controls of NIST SP 800-171 Revision 2 against the current environment using the NIST SP 800-171A assessment procedures. For each control, document the implementation evidence, identify gaps, and assign each gap to a named owner with a target close date. The output is the first draft of the SSP and the first draft of the Plan of Action and Milestones.

Days 46 to 75: Remediation and Documentation

Close gaps in priority order, starting with the controls that materially affect CUI confidentiality (encryption, access control, boundary protection, audit logging). Produce the supporting policies (typically 16 to 20 documents covering each of the relevant control families), the CUI handling SOP, the incident response plan, the configuration management plan, and the personnel security artifacts.

Days 76 to 90: Dry-Run and Submission Prep

Conduct an internal pre-assessment that walks the C3PAO scoring playbook. Identify any residual gaps and either close them or move them onto the POAM with a defensible close date. Compute the DoD Self-Assessment Score and submit it to the Supplier Performance Risk System. Schedule the formal C3PAO assessment for a date that gives the contractor a buffer beyond the contract requirement so unexpected findings can be resolved without contract jeopardy.

This 90-day sequence assumes a contractor of moderate size with reasonable IT maturity. Larger environments, environments with significant legacy debt, and Level 3 environments may need 120 to 180 days. The sequence itself does not change.

8. Letting Mobile Devices Drift Into the CUI Boundary

Mobile device management is one of the quietest scoping risks. The moment a user reads CUI email on a personal phone, that device becomes a CUI-handling endpoint, and the entire mobile fleet may need to be in scope. The cleaner path is to provision separate corporate-issued mobile devices for CUI users, enrolled in an MDM platform that supports the relevant 800-171 controls (configuration enforcement, encryption at rest, remote wipe, and certificate-based authentication). Bring-your-own-device for CUI is technically possible with a heavily-locked containerization solution but is rarely the right answer for small and mid-sized contractors because the operational overhead exceeds the cost of a dedicated device.

9. Outdated Training Materials

An organization's CUI training program is a controls input under the Awareness and Training family. Training built on FOUO-era assumptions, on pre-DFARS 252.204-7012 (2017) guidance, or on third-party content that has not been refreshed against the current ISOO Registry is a finding waiting to surface during assessor interviews. Refresh training annually, validate it against current authoritative documents, and document each employee's completion.

10. No Designated CUI Handling Procedures Document

A CUI handling SOP is not optional in a mature Level 2 program. The SOP describes how CUI moves through the contractor's environment in concrete operational terms: which mailboxes receive CUI, which storage repositories hold it, who has access, what the inbound marking-check procedure is, what the destruction process is, and how exceptions are handled. The SSP describes controls; the SOP describes the day-to-day workflow. Assessors will ask to see both.

Petronella CMMC-RP Services for CUI Programs

Petronella Technology Group operates a Cyber AB Registered Provider Organization (RPO #1449). The entire team holds the Registered Practitioner credential (CMMC-RP). Craig Petronella holds CMMC-RP, the MIT-Certified Blockchain credential, the Digital Forensics Examiner (DFE) credential #604180, CCNA, and CWNE. The firm has been operating in cybersecurity since 2002 and currently serves defense manufacturers, engineering firms, and managed-service providers across the Mid-Atlantic and Southeast from its headquarters at 5540 Centerview Dr., Suite 200, Raleigh, NC 27606.

For CUI programs specifically, Petronella delivers three things that small and mid-sized defense suppliers most often need. First, a 90-day Level 2 readiness sprint that produces a documented boundary, a complete SSP, a Plan of Action and Milestones (POAM) for any gaps, and a pre-assessment dry run conducted as if a C3PAO were in the room. Second, ongoing program operations through ComplianceArmor, the firm's compliance documentation and operations SaaS, which keeps SSPs, policies, and assessment artifacts current as the environment changes. Third, private artificial intelligence infrastructure designed specifically for CUI workloads, so that engineers can use modern AI assistance without ever submitting CUI to a public endpoint.

ComplianceArmor pricing starts From $497/mo and is described in detail on the ComplianceArmor product page. Readiness sprint and ongoing advisory pricing depends on environment scope and is quoted after a free 15-minute boundary-scoping conversation. The DoD Self-Assessment Score that contractors submit to the Supplier Performance Risk System (SPRS) is a useful starting input for that conversation; the firm's SPRS score calculator walks contractors through the math before the first scoping call.

Frequently Asked Questions

What is CUI?

Controlled Unclassified Information (CUI) is government-created or government-owned information that requires safeguarding or dissemination controls under law, regulation, or government-wide policy, but that is not classified under Executive Order 13526. The CUI Program was established by Executive Order 13556 in 2010 and is administered government-wide by the National Archives ISOO, with the full category list published in the ISOO CUI Registry.

What is CUI Basic?

CUI Basic is the default CUI category. It is information for which the authorizing law, regulation, or government-wide policy does not specify particular safeguarding or dissemination requirements beyond the standard CUI baseline established by 32 CFR Part 2002. Handlers apply the baseline rules and, for DoD contractors, the NIST SP 800-171 controls required by DFARS 252.204-7012.

What is CUI Specified?

CUI Specified is CUI for which the authorizing law, regulation, or government-wide policy contains specific handling controls beyond the CUI Basic baseline. The Specified category's underlying authority controls. Common examples include export-controlled technical data under EAR and ITAR, nuclear information under the Atomic Energy Act, and certain critical infrastructure and privacy categories. Banner markings include the //SP-CATEGORY designator (for example, CUI//SP-EXPT for export-controlled).

What level of system and network configuration is required for CUI?

The configuration required for CUI is the level that implements all 110 controls of NIST SP 800-171 Revision 2 across 14 control families, documented in a System Security Plan and assessable under NIST SP 800-171A. For CMMC Level 2, that 800-171 baseline is required. For CMMC Level 3, selected enhanced requirements from NIST SP 800-172 layer on top. FIPS-validated cryptography, multi-factor authentication, boundary protection at external and key internal boundaries, and protected audit logging are among the most-cited specific configuration requirements.

Who can decontrol CUI?

Only the designating agency that originally applied the CUI status, or an authorized agency official acting under delegated authority from the designating agency, may decontrol CUI. Contractors cannot unilaterally decontrol. A contractor who believes information no longer requires CUI status should request guidance from the contracting officer.

CUI documents must be reviewed against what before destruction?

CUI documents must be reviewed against the applicable Records Disposition Schedule (Records Retention Schedule) before destruction. The review confirms that no legal preservation obligation (litigation hold, FOIA request, IG investigation, congressional inquiry) overrides the routine retention period, that the retention period has elapsed, and that the destruction method is authorized for the category. Destruction must also follow NIST SP 800-88 Revision 1 sanitization standards.

Who is responsible for protecting CUI?

Every authorized holder is responsible for protecting CUI in their custody under 32 CFR 2002.14. The designating agency carries overall lifecycle responsibility. Each agency designates a Senior Agency Official accountable for program implementation. Contractor organizations typically designate an internal CUI Program Manager or Registered Practitioner-led role to carry the operational responsibility for marking, storage, transmission, and destruction across the contractor environment.

Who is responsible for applying CUI markings?

The originating agency applies the initial markings to CUI it creates. Contractors and other authorized holders are responsible for applying markings to derivative documents that incorporate CUI, and for re-marking material that is found to be improperly marked. Internally, marking responsibility usually sits with the document author, with a designated CUI program point of contact reviewing for accuracy.

What is the purpose of the ISOO CUI Registry?

The ISOO CUI Registry is the single authoritative government-wide reference that defines every CUI category, identifies the underlying law, regulation, or government-wide policy that authorizes its controls, distinguishes Basic from Specified treatment, and documents marking conventions and Limited Dissemination Controls. Contractors consult it to clarify ambiguous markings on inbound documents, to identify the controls that flow through to derivative material, and to anchor employee training in the canonical category definitions.

Talk to a Registered Practitioner About Your CUI Environment

If you are a defense contractor, engineering firm, or managed-service provider with a CUI handling obligation under DFARS 252.204-7012 and a CMMC Level 1, Level 2, or Level 3 trajectory ahead of you, Petronella Technology Group offers a free 15-minute boundary-scoping conversation with a CMMC-RP. We will not ask you to send us any CUI in advance. We will walk through your contract data requirements, your current environment topology, and where the CUI lives today, and we will tell you honestly whether you are 30 days, 90 days, or longer from a successful assessment. Submit the form on the contact page or call (919) 348-4912 to schedule. Our RPO ID with the Cyber AB is #1449, our address is 5540 Centerview Dr., Suite 200, Raleigh, NC 27606, and our team has been delivering cybersecurity for the regulated economy since 2002.