Welcome to CMMC Unlocked. I’m Eric Marquette, and today’s a bit of a follow-up from the NDIA New England Cyber Event on April twenty-ninth, twenty twenty-six at Gillette Stadium. If you went there, or even if you didn't, this conversation is meant to get you grounded in one topic that trips up a lot of organizations: CUI. [calm] It does, and for good reason. People tend to treat CUI as only a cybersecurity issue. It isn’t. It’s a business operations issue, because it affects how work moves through the company. It’s a contract issue, because the obligation usually comes from the government’s requirements. And it’s a cybersecurity issue, because once the information qualifies, you have to protect it appropriately. While we talk about the information type as CUI, we should focus on the definition of Covered Defense Information, CDI, which provides additional context as to how to identify the CUI information that an organization will be developing on behalf of the federal government under a contract. CDI is defined under DFARS 252.204-7012. The federal government has the responsibility to communicate the information types the contractor will be generating on the governments behalf that requires safeguarding and dissemination controls under a law, regulation or government wide policy. It is not up to the contractor to do all of this research and make their own determination as to if information is CUI. Only a designating agency can approve the designation of a specific item of information as CUI, and this is not your business. As we discuss the information type CUI here today, we are trying to look at it through the lenses of a defense contractor and where the government, or a higher level contractor, A.K.A. Prime contractor, is communicating to us that information is "determined" to be CUI for the particular contract. Yeah, that’s what I like about this conversation. It’s not just, you know, lock down the file and move on. There’s a bigger chain behind it. Exactly. Before you can protect it, you need to know what it is, why it is controlled, and whether the contract actually requires that treatment. So the practical goal today is pretty simple: help people spot CUI, understand what obligations they may actually have, and avoid some of the more common mistakes. Because I think a lot of teams either over-mark things, under-protect things, or honestly just get buried in conflicting documents. That’s a fair summary. And if we can help people ask better questions before contract execution, that alone will reduce a lot of operational pain later. Alright, let’s start with the foundation. In plain language, what is CUI? In plain language and very abbreviated, CUI is information generated by or possessed by the federal government, or generated for the federal government, where a law, regulation, or government-wide policy says that information requires protection from public release using safeguarding and/or dissemination controls. There are two main categories of CUI, CUI Basic and CUI Specified. CUI is defined in the 32 Code of Federal Regulations, Part 2002. So there are really two gates there. There are. First, it has to be generated by or for the government. Second, there has to be an actual authority requiring protection. If those conditions are not met, the information should not just be labeled CUI because someone feels safer doing that. That feels like a big one. Just because a document seems sensitive doesn’t automatically make it CUI. Correct. Sensitivity by itself is not the standard. The underlying authority matters. And markings matter as well. If the government creates the information, it should identify the applicable CUI category and mark it appropriately using approved markings. And when we say markings, we’re not talking about just slapping CUI in big letters at the top, right? No. Proper marking includes more than that. NARA and the Department of Defense have specific requirements. You’re looking at the designation indicator block, the category, whether it is basic or specified, any distribution statement or limited dissemination control, and the government office that designated it as CUI along with a point of contact. It also needs to be marked in the header and footer. So this is structured, not casual. Which also means if the structure isn’t there, that’s maybe a sign to pause and ask questions. Yes. Not to ignore it, but to validate it. So how does a contractor know when information is truly CUI? Where do they actually look? Start with the contract artifacts. The government typically identifies deliverables through CDRLs, and those use the DD one four two three. In those forms, especially blocks nine and sixteen, the government should state the CUI category and how the deliverable should be marked. The related Data Item Descriptor, or DID, may also define the required format. So if I’m responding to an RFP, I should be looking at the deliverables table, the CDRLs, the DIDs, and not just the statement of work. Exactly. Also review the clause set, things like DFARS clauses, and if the contract has classified elements, the DD two five four. The DD two five four may reference the Security Classification Guide, and that can be an important indicator. If the guide says certain information is unclassified but controlled, then information you derive from that source may need to be marked as CUI. Let me throw in one that gets people tangled up: export control. Folks hear ITAR or EAR and think, well, that must be CUI. [measured] Not always. ITAR and EAR are export control regimes. ITAR is under the Department of State. EAR is under the Department of Commerce. Information can be export controlled without being CUI. It becomes CUI when, for example, technical data is being delivered to the government under a contract and the CDRL says it must carry a CUI category, such as CUI double slash SP-CTI, with a specific distribution statement. So the same underlying material might stay just ITAR in one context, and become ITAR plus CUI in another, depending on the deliverable. That’s right. The contract context matters. The same goes for OPSEC or Critical Program Information. Those may require protection, but you need to see how the government identifies and categorizes them in the applicable documents. Okay, let’s get into the messy part. What should contractors do when the RFP, purchase order, or contract language is unclear, incomplete, or just inconsistent with itself? The honest answer is: it depends. I’m not a contract attorney, so I’d be careful there, but the practical approach is consistent. Review what was actually awarded, what obligations were accepted, and what flow-downs apply. If your organization committed to comply in the proposal and the awarded contract carries that forward, then that obligation matters. And if something changes after award? Protect the information appropriately while you raise the issue. If there is a change from the RFP to the awarded contract, or a modification during execution, communicate early with the contracting officer or, in the subcontractor context, with the prime. Document the question, document your rationale, and seek clarification rather than making unsupported assumptions. That feels especially important for smaller companies. Sometimes they get a PO from a prime and assume, well, I guess we’re a subcontractor now and all these terms just apply automatically. Not necessarily. A vendor providing goods or services is not automatically a subcontractor under the FAR definitions. The purchase order and inserted terms and conditions matter. Review them. Negotiate them where needed. Establish order of precedence if possible. And if you think information is marked incorrectly, or not marked when it should be, do your due diligence. Meaning talk to the sender first? Yes. Start with the person who sent it. The designation indicator should point to a government office and point of contact. If it lists a contractor name instead, that’s a warning sign. If you still cannot resolve it, elevate through the contracting officer and legal counsel as appropriate. And it’s smart to define a resolution process with the prime or collaborator before work begins. Before we wrap, give me a few closing lessons listeners carried out of the NDIA event, and frankly any day they are working with CUI. First, identify requirements before execution. Review the statement of work, DD two five four, OPSEC plan, Program Protection Plan, CDRLs, the DD one four two three, and the Security Classification Guide if one exists. Second, manage change carefully. Contract modifications, purchase order terms, and updated instructions can all shift your obligations. Third, treat contract compliance, data handling, and cybersecurity as one integrated discipline. If those teams operate separately, gaps appear. I like that a lot. CUI can sound abstract until it hits an engineering file, a proposal response, a user manual, or a supplier relationship. Then it becomes very operational, very quickly. It does. And if organizations build the habit of identifying the authority, validating the marking, and clarifying the requirement early, they put themselves in a much better position for day-to-day execution and for broader CMMC readiness. That’s a strong place to leave it. Think about CUI as part of how your business runs, not just as a label on a document. Paul, thanks for making a complicated topic feel usable. [warmly] Thanks, Eric. Glad to be here. And thanks to all of you for listening to CMMC Unlocked. We’ll keep this going in future conversations. Until next time, take care. Goodbye, everyone.
Audio Coursesby Jellypod