Is It CUI? A Decision Path for Engineering Data

Quick answer: scope follows data, and a lot of data people protect was never CUI. Getting this wrong is more expensive than any control, because misclassified data drags assets into scope that never belonged there. It is also the area where the most confidently wrong advice circulates.

Why does this decide your scope?

Because 32 CFR 170.19 defines the assessment scope as the set of assets that will be assessed, and asset categorisation turns on what the asset does with CUI. An asset that processes, stores, or transmits CUI is a CUI Asset and gets assessed against all Level 2 requirements.

So if a drawing was never CUI, the Mac that opens it was never a CUI Asset on account of that drawing. Every hour spent hardening it to that standard was spent for a reason that does not exist.

The reverse error is worse, and it is why this needs care rather than enthusiasm.

What does the CTI definition actually exclude?

Something specific and narrow. The CUI Registry entry for Controlled Technical Information ends with this sentence: "The term does not include information that is lawfully publicly available without restrictions."

So a MIL-SPEC that anyone can download was never Controlled Technical Information. It is not that the information was decontrolled. It never met the definition.

Three limits on that, all of which matter more than the exclusion itself:

• The document does not stop being CUI. A drawing marked CUI//SP-CTI stays CUI even if some elements on it are public. The exclusion applies to information, not to paper.
• Compilation is protected. Which specs apply where, at what tolerance, in what configuration, is exactly what CTI exists to cover. The parts can be public and the arrangement still controlled.
• "Lawfully publicly available without restrictions" is a burden you carry. Some specs are on public repositories. Others are export-controlled or distribution-restricted. That is a per-document finding.

Note also that the Registry lists a single authority for CTI, 48 CFR 252.204-7012. DoDI 5230.24 is referenced inside the description as the source of distribution statements B through F, but it is not listed as an authority. Getting that right marks you as someone who read the source.

What if the document has no category marking?

That is the normal case, and any workflow that depends on reading the category will break on it.

32 CFR 2002.20 makes category and subcategory markings mandatory only for CUI Specified. For CUI Basic it says the programme "does not require agencies to use category or subcategory markings," though an agency may mandate them by policy.

DoD went further. DoDI 5200.48 provides that DoD markings include "CUI" in the banner and footer, with no required distinction between Basic and Specified during implementation. So you will routinely receive documents banner-marked only CUI, with nothing to categorise from.

When that happens the answer is to ask, not to infer. The originator knows what authority made it CUI. You are guessing.

Can you strip CUI status from data you send onward?

No, and this is the most consequential correction in this article.

Advice circulates in these communities suggesting that a contractor can apply decontrol options to reduce what flows to a subcontractor. That is not available to you.

32 CFR 2002.18 places decontrol with the designating agency. An authorized holder "may request that the designating agency decontrol" information. The section adds that "unauthorized disclosure of CUI does not constitute decontrol," and that decontrol itself "does not constitute authorization for public release."

Two things you can lawfully do. Ask the designating agency to decontrol. Or determine that specific content never met the definition in the first place, which is categorisation rather than decontrol and is the subject of the sections above.

Extracting content from a government-marked document and asserting it is now uncontrolled is not one of them.

What should you do with engineering files on Macs?

Three things, in order.

First, get the marking question answered upstream. A contract that specifies which CUI categories apply is worth more to your scope than any tool.

Second, keep the boundary where the files are, not where you wish they were. Engineering data has a habit of living on the workstations that create it, which makes those Macs CUI Assets. Pretending otherwise in the SSP is the gap an assessor finds. See Mac asset classification for CMMC.

Third, be realistic about labelling tooling on macOS. Sensitivity-labelling coverage for engineering and CAD formats is limited on any platform, and the client that provides generic protection for unsupported file types is documented for Windows. Verify what is actually available on macOS for your stack before you design a control around it.

For the handling side once classification is settled, see CUI on Macs.

Sources

• NARA CUI Registry, Controlled Technical Information category entry
• 32 CFR 2002.18, 2002.20; DoDI 5200.48
• 32 CFR 170.19

Verified against primary sources on August 1, 2026. CUI categorisation carries legal consequences and this article is general information, not legal advice. Confirm category questions with the designating agency or your counsel.