Finding CUI in Your Environment

Almost every scoping failure starts the same way: a company assumes it knows where CUI lives, draws a boundary around that assumption, and discovers during assessment that the drawings have been sitting in a shared mailbox for three years.

CUI rarely arrives announcing itself. It comes in through four doors — email attachments from a prime, downloads from a customer portal, physical media, and engineering file transfers — and then it spreads, because someone forwards it, saves a local copy, or prints it for the shop floor.

The scoping decision that follows is the single largest cost driver in this entire process. Draw the boundary too wide and you are hardening your whole network. Draw it too narrow and you have systems handling CUI outside your controls, which is worse than not having started.

The four doors

1. Email. The most common and the hardest to contain. A single attachment from a prime puts your mail platform in scope unless you have a deliberate process for moving it elsewhere.
2. Customer portals. Downloads from a prime’s supplier portal or a government system. Scope depends on whether anything is retained locally.
3. Physical media. USB drives and discs, still common in engineering and manufacturing. Easy to miss because they leave no network trace.
4. Engineering file transfers. CAD exchanges, PDM and PLM syncing, FTP from a customer. Often automated and therefore invisible.

Where it comes to rest

Entry is the easy half. The expensive half is where it settles afterwards:

• Mailboxes and their archives, including former employees’
• File shares, especially a general-purpose one everyone can reach
• ERP and MRP systems that hold drawings against part numbers
• Local drives on engineering workstations
• Backups, which inherit the scope of whatever they captured
• Printed material on the shop floor and in inspection
• Personal devices, if anyone has ever checked mail on a phone

Drawing a boundary you can defend

A boundary is defensible when you can explain, system by system, why each thing is inside or outside — and when the explanation survives someone asking “what about the backups?”

Three tests are worth applying to every system:

• Does CUI process on it?
• Does CUI rest on it, including transiently?
• Does CUI transit through it?

Anything answering yes is in scope. Anything providing security services to those systems — identity, logging, backup, endpoint protection — is in scope too, even if CUI never touches it directly.

The enclave approach

Rather than hardening everything, most contractors end up isolating CUI into a defined enclave: a separate tenant or virtual desktop environment where all CUI work happens, with deliberate, controlled routes in and out.

The trade is real. An enclave concentrates the 110 requirements onto a small footprint, which is cheaper and easier to evidence. But it changes how people work, and if the enclave is inconvenient, staff will route around it — which puts you back where you started, only now with a false sense of a clean boundary.

A practical way to run the trace

Scoping fails when it is done as a desk exercise. What works is following the information, in this order.

1. Start at the contract. Which awards carry DFARS 252.204-7012? Those are the ones that bring CUI. See FCI vs CUI for the clause test.
2. Ask who receives it. Not who should — who does. Usually two or three named people in sales, engineering or programme management.
3. Search their mailboxes. By attachment type, by sender domain, by the marking text itself. This is where the unwelcome discoveries happen.
4. Follow each copy. Where was it saved, who was it forwarded to, was it attached to an ERP record, was it printed.
5. Check the backups. Backups inherit the scope of whatever they captured, and they are the most commonly forgotten system in a boundary diagram.
6. Check what leaves. Files sent to sub-tier suppliers, to a plating shop, to a calibration house. Flow-down applies going out as well as coming in.

Security protection assets

One category of system routinely gets missed because CUI never touches it: anything that provides security services to the in-scope systems. Identity providers, logging and SIEM, backup infrastructure, endpoint protection consoles, patch management.

These are in scope even though no drawing ever passes through them, because compromising them compromises the systems that do hold CUI. If your identity provider sits outside the boundary you have drawn, the boundary is not real.

The enclave trade-off, honestly

An enclave concentrates the 110 requirements onto a small footprint. That is cheaper to implement, far cheaper to evidence, and easier to keep accurate over time. It is the right answer for most small and mid-sized contractors.

The cost is friction. Engineers work in two places, files move through a controlled gate, and some familiar conveniences stop working. If the enclave is inconvenient enough, people route around it — and a bypassed enclave is worse than no enclave, because you now have CUI outside a boundary you believe is complete.

The question to ask before committing is not whether an enclave is technically possible. It is whether the people who handle CUI daily can do their jobs inside it without inventing workarounds.

Documenting it

Whatever you decide becomes the system description in your System Security Plan, along with a data flow showing how CUI enters, moves and leaves. Assessors read that description first and test everything else against it, so a vague boundary produces findings across the whole assessment rather than in one place.

If you would rather not do this cold, scoping is the first thing we do in a readiness assessment, before any scoring. And if you are still deciding whether you hold CUI at all, start with CUI categories.