Handling CUI in federal proposals without spilling it

Controlled Unclassified Information shows up in federal proposals in ways small contractors are routinely unprepared for, and the consequences of mishandling it run from disqualification through actual federal liability. The hard part is not the rule itself. The hard part is that CUI lives inside ordinary-looking documents and travels into ordinary-looking workflows, and unless your shop has a deliberate process for spotting it, it gets handled the way the rest of the proposal is handled.

This is a workflow note, not legal advice. If you have a specific CUI question, talk to your contracts attorney.

What CUI is, in two sentences

CUI is unclassified information the government has decided requires safeguarding or dissemination controls. It is defined under 32 CFR Part 2002 and the implementing DFARS clauses, and it covers a wide range of categories from procurement-sensitive information to export-controlled technical data to personally identifiable information.

If a document is marked CUI, it is CUI. If it is unmarked but falls into a CUI category, it is still CUI. The marking is a notice. The legal control attaches to the content.

Where CUI shows up in a proposal workflow

Six places, in our experience.

Attachments referenced in the solicitation. Sometimes the government posts an attachment with a CUI banner you can only see after you click through a SAM.gov disclaimer or a DoD SAFE link. The fact that you had to authenticate to read it is the signal.

Bidder library documents. A government-furnished bidder library can contain CUI. The cover sheet usually says so. Read the cover sheet.

Past performance from your prior contracts. If a prior contract delivered CUI, your performance narrative cannot quote the CUI content. It can describe the work at a level that does not disclose. This is the place small contractors most often slip.

Technical data you cite in your technical approach. Export-controlled technical information under ITAR or EAR is CUI. If your technical volume references specific performance parameters from a controlled source, you have a CUI document.

Customer references and points of contact. PII for government employees is CUI when it is non-public. Phone numbers and emails that are not on a public agency directory require handling care.

The proposal itself, in some cases. Some agencies treat bid and proposal information as CUI Specified once it has been submitted. Your internal copies, your version history, and your back-and-forth team correspondence inherit that classification.

What "handling" actually means

Handling has three components.

Storage. CUI must be stored in a system that meets the safeguarding requirements applicable to your contract. For DoD, this is most commonly the NIST SP 800-171 baseline, soon to be enforced through CMMC. For civilian, FAR 52.204-21 sets the floor. Your shared Google Drive folder almost certainly does not meet either standard.

Transmission. CUI emailed in the clear is mishandled CUI. Encryption in transit is required. Most teams meet this with FIPS-validated email encryption or a controlled file-transfer system. A password-protected PDF attachment to a Gmail thread is not compliant.

Access. Only people with a lawful government purpose may access CUI. For a proposal team, that usually means people on the bid team and your subcontracting partners under teaming agreements that include the appropriate flow-down clauses.

The shred-time decision

When you build the RFP shred, scan the solicitation and every attachment for CUI markings. If anything is marked, the shred is the place to decide three things.

1. Which team members get access.
2. Which storage system holds the marked documents.
3. Whether your AI tooling can touch the content at all.

The third question matters more than most teams realize. Most general-purpose large language model services are not authorized to process CUI. Pasting a marked PWS into a public chatbot is a CUI spill, full stop. This is why we built PursuitWorks to refuse to send restricted material to the AI provider and to fall back to deterministic processing instead. The product invariant comes from the fact that we have watched contractors discover this rule by violating it.

The downstream invariant

Once you have a reviewed RFP shred, the raw solicitation text should not need to travel any further into your workflow. The shred captures the substance. The deterministic compliance matrix and the structured requirement list contain what the writers need. Downstream stages should read from the shred and from approved internal sources, not from the marked source document.

This is not a security theater rule. It is how you constrain the blast radius of a CUI mishap. The fewer surfaces that touch the raw marked content, the fewer ways the content can leak.

A short checklist

Before any solicitation hits your active proposal workflow, answer five questions in writing.

• Is anything in the solicitation or its attachments marked CUI?
• If yes, what CUI category and what safeguarding standard applies?
• Does our storage and transmission setup meet the standard?
• Which team members have authorized access, and is that documented?
• What is in our AI pipeline, and is it authorized for CUI?

If you cannot answer all five, the proposal is not ready to start. Find the answers, then start.

Why this matters

Mishandling CUI does not usually announce itself at the time. It announces itself months later, in a contracting officer letter or a debrief that flags the issue. By then the proposal is decided, the contract is awarded elsewhere, and your record has a note on it that follows the company for years.

The protection is not heroic. It is procedural. The teams that get it right are the teams that decided once, in writing, how they would handle CUI when it showed up, and then followed that procedure every time.