Who Must Mark CUI? DoD Contracting Risks Explained
Eric, Paul, and Roz unpack why the DoD—not the contractor—bears the burden of identifying and marking CUI, and why accepting unlabelled data can create serious compliance and False Claims Act exposure.
They also trace how DFARS clauses, NIST SP 800-171, and pre-award CIO variance approval shape the procurement process and set the system boundaries for CDI, CTI, and CUI.
Is this your podcast and want to remove this banner? Click here.
Chapter 1
The Government's Burden of Identification
Eric Marquette
Welcome to the show, everyone! I'm Eric Marquette, here with Paul Netopski and Roz the Rulemaker. Today, we are diving deep into a compliance pain point that keeps defense contractors up at night: the burden of identifying Controlled Unclassified Information, or CUI. And let me start with a reality check for every contractor out there. If a DoD program office hands you a pile of unlabelled data and says "just protect it as CUI while we figure it out," you are stepping into a legal and financial minefield.
Roz the Rulemaker
They absolutely are, Eric. Because under Department of Defense Instruction 5200.48, specifically Sections 5.1 and 5.3, the legal burden to identify and mark CUI at the time of contract award is placed squarely and exclusively on the contracting DoD organization. The government cannot delegate its administrative failure to mark information down to the contractor.
Paul Netopski
Exactly, Roz. And from a cybersecurity assessment perspective, this concept of "implied CUI" is a disaster. If it isn't marked, how does a contractor configure their boundaries or scope their NIST SP 800-171 system? Accepting unlabelled data with some vague, informal understanding that it "might" be CUI creates massive liability. If you treat everything as CUI, your compliance costs go through the roof. If you treat it as public because it's unmarked, and a breach occurs, you are suddenly looking at a False Claims Act violation or immediate contract termination.
Roz the Rulemaker
That False Claims Act angle is no joke, Paul. The administrative rulemaking process is designed to prevent this exact ambiguity. Long before a solicitation is ever released, the program office or requiring activity is legally obligated to define the CUI boundaries. They are supposed to compile a Security Classification Guide, or SCG, or a specific CUI marking guide. It is a structured, procedural requirement that must occur upstream.
Eric Marquette
So if the government is required to do this upstream, why are so many contractors still receiving blank documents with a verbal "hey, just keep this secure" from their contracting officer?
Paul Netopski
Because program offices are often understaffed and undertrained on DoDI 5200.48. They treat security as an afterthought to speed up the procurement cycle. But as an assessor, I tell my clients: do not accept that liability transfer. If the government fails to execute its inherent responsibility under Section 2.8 of DoDI 5230.24 to determine appropriate markings, you have to formally request clarification.
Roz the Rulemaker
And that formal request is your paper trail. If the program office refuses to mark it, and you have documented your inquiries, the administrative record is on your side. The contracting officer is the only one who can legally commit the government, and they have to follow the regulations. They can't just bypass the system because they're in a hurry to meet an award deadline.
Chapter 2
The Regulatory Pipeline: DFARS and Solicitation Clauses
Eric Marquette
Let's look at how this plays out in the actual procurement pipeline. Paul, when a contracting officer is drafting a solicitation, what is the actual regulatory mechanism for inserting these requirements?
Paul Netopski
It all flows down through DFARS Subpart 204.7304. This section outlines the precise rules contracting officers must follow. They are required to use the provision at 252.204-7008, which is the Compliance with Safeguarding Covered Defense Information Controls, in all solicitations, except those solely for commercially available off-the-shelf, or COTS, items. It's an all-or-nothing trigger.
Roz the Rulemaker
And let's look at the wording of 252.204-7008. By submitting an offer, the contractor is making a legal representation that they will implement the security requirements specified by NIST SP 800-171 that are in effect at the time the solicitation is issued. That submission is a binding compliance statement. You are certifying to the United States government that your systems are compliant or that you have an authorized variance.
Paul Netopski
That word "variance" is key. Under 252.204-7008 paragraph (c)(2)(i), if an offeror proposes to vary from any of the NIST SP 800-171 requirements, they must submit a written explanation to the Contracting Officer. This explanation must justify why a requirement isn't applicable, or how an alternative, equally effective security measure compensates for it.
Eric Marquette
Wait, so can a contractor just write up their own alternative security controls and call it a day?
Roz the Rulemaker
Absolutely not. The regulation is highly specific here. That written explanation goes to the Contracting Officer, but it must be adjudicated in writing by the DoD Chief Information Officer, or CIO, prior to contract award. An authorized representative of the DoD CIO has to sign off on that variance. If they accept it, that accepted variance must be legally incorporated into the resulting contract.
Paul Netopski
And that's a massive hurdle. You can't just throw a Plan of Action and Milestones, or POA&M, at the wall and hope it sticks. The DoD CIO's office is looking for equivalent protection. If you say "we don't use multi-factor authentication because we have a strong physical perimeter," they will reject it unless you can prove equivalent logical controls. It's a rigorous, technical evaluation, not a paper-pushing exercise.
Eric Marquette
So the takeaway here is that compliance is a gating item for the award itself. You can't win the contract first and then figure out your NIST 800-171 compliance afterward, unless you have that pre-award CIO adjudication in writing.
Roz the Rulemaker
Exactly. The rule is designed to ensure that the defense industrial base is secure before the first byte of Covered Defense Information, or CDI, is ever transmitted.
Chapter 3
System-Level Realities and the Episode 12 Connection
Eric Marquette
Now, let's connect this back to our highly requested Episode 12, which we originally published on November 12, 2024. In that episode, we spent a lot of time defining the boundary lines between CDI, CTI, and CUI in contractor systems. Paul, how do these contracting mandates we just talked about alter those system-level boundaries?
Paul Netopski
They don't change the boundaries, they enforce them. In Episode 12, we discussed how Covered Defense Information, or CDI, is the broad umbrella that includes both Controlled Technical Information, or CTI, and CUI. The vital link here is DoDI 5230.24, which establishes the distribution statements B through F. Those distribution statements are what actually categorize and restrict the secondary distribution of unclassified technical documents.
Roz the Rulemaker
Yes, and DoDI 5230.24 aligns those technical data controls directly with the newer, executive branch-wide CUI program. If a document has a Distribution Statement B, which limits distribution to U.S. government agencies, or Statement C, which includes contractors, it is automatically CUI. The distribution statement itself is the justification and the marking requirement under 32 CFR Part 2002.
Eric Marquette
So, what happens to legacy data? If a contractor has files from a ten-year-old contract that don't have these modern CUI banner markings, are they exempt from these rules?
Paul Netopski
No, they are not. Under 32 CFR Section 2002.20 and DoDI 5200.48, the lack of an initial CUI marking does not exempt the holder from safeguarding requirements once the information is identified. If you are reusing legacy technical data or deriving new materials from it, and that data fits the definition of CTI or CUI, you must get a determination from the government's CUI authority as to the appropriate markings, or use the guidance in the current contract resources and protect it on your systems in accordance with NIST SP 800-171. Your marking responsibility as a contractor is to follow government determinations, not make your own. So when you mark it, it is supposed to be due to guidance from the government or you derived the information from a source document that was marked as CUI.
Roz the Rulemaker
And that is where contractors get tripped up. They think "well, it didn't say CUI on the original PDF from 2015, so we can just put it on our commercial cloud." But the moment you incorporate that data into a new deliverable, you are generating derivative CUI. You have an administrative obligation to conduct a review and apply the correct markings, including the CUI designation indicator block and the appropriate distribution statement. Also, when taking government information from other contracts and using it on a new contract, permission must be obtained from those other government contracting officers or program offices before the information can be reused on another contract. Data ownership is a key element in these determinations too, and Paul, I think you mentioned this situation to be similar to Schrödinger's cat and the quantum wave theory in quantum mechanics.
Paul Netopski
Yes, I did mention Schrödinger's cat during the 2026 NDIA Cyber event and several times before that! The basis of that callout is that you must look at the information at that point in time to determine its current ownership and state. To continue on the path you were going about the file from 2015, it's about the data itself, not just the sticker on the cover page. As a digital sentinel, you have to protect the integrity of the information. If it has military or space application, and it isn't in the public domain, you must assume it requires safeguarding. The mission-first, security-always mindset means protecting the capability, not just checking a compliance box.
Eric Marquette
That's a powerful way to look at it, Paul. It's about protecting the warfighter by securing the technical data that gives us the edge. That is all the time we have for this quick take. Thanks to Paul Netopski and Roz the Rulemaker for the incredible insights. We'll see you all next time!
