By Ned Butler, Lead Certified CMMC Assessor (CCA), Redspin
Two new requirements in NIST SP 800-171 Rev. 3 are likely to catch organizations flat-footed: 03.04.11 Information Location, and 03.12.05 Information Exchange.
These aren’t simply reorganized versions of controls you already satisfy under Rev. 2. They ask for something most organizations have never formally built: a documented, current, defensible account of where their CUI actually is, and everywhere it’s gone.
This article walks through what each requirement demands, why they’re really two parts of the same problem, and what a working CUI Register looks like once it’s built.
I can already hear the objection: “We have a System Security Plan. It describes our environment. Isn’t that the same thing?”
It isn’t. And the gap between the two is exactly what these requirements are designed to close.
Table of Contents
- The Gap These Requirements Are Closing
- 03.04.11 Information Location: Know Where It Sits
- 03.12.05 Information Exchange: Know Where It Travels
- Why These Two Belong Together
- Building the CUI Register
- Where to Start
- Frequently Asked Questions
- How Redspin Can Help
The Gap These Requirements Are Closing
Ask most organizations handling CUI where it lives, and you’ll get a fast, confident answer: the file share, the ERP system, maybe a project drive.
Ask them to prove it – identify every system, every subcontractor, every place that data has been copied or forwarded or exported – and the confidence tends to evaporate.
In most cases, this isn’t a technology failure. An organization can have solid access controls, working encryption, and a competent IT team, and still have no single, current record of which systems, which people, and which outside parties touch its CUI.
The gap is ownership.
Nobody’s job is to answer “where does this go next?” So as systems change and the supply chain shifts underneath them, nobody tracks the answer.
A 2026 industry workshop on defense supply chain risk found the same pattern in every functional group in the room. Operations, IT, finance, and sales each separately flagged CUI moving to sub-tier suppliers with no formal record of where it ended up.1
That’s not an isolated data point. It matches what assessors and consultants have been describing across the Defense Industrial Base for years.
Rev. 3 turns that informal observation into a requirement with teeth.
“We generally know where our CUI is” no longer clears the bar.
Organizations have to document it, keep the documentation current, and be ready to walk an assessor or even their own leadership through exactly where the boundaries of their CUI environment sit.
03.04.11 Information Location: Know Where It Sits
The requirement text doesn’t leave much room for interpretation:
- Identify and document the location of CUI and the system components on which the information is processed and stored.
- Document changes to the system or system component location where CUI is processed and stored.
The discussion language explains why this matters: understanding exactly which system components process and store CUI, and who has access to it, makes it possible to apply the right flow controls, access controls, and information management in the first place.²
Scoping decisions, enclave design, access restrictions, all of it depends on knowing where the data actually sits.
Get the map wrong, and every control decision built on top of it is wrong too.
A well-prepared organization can walk an assessor through a specific, current inventory: this file server, this SaaS tenant, this subcontractor’s dev environment. Each is tied to a review cadence and updated the moment a system changes.
A poorly prepared one has an SSP describing the environment in general terms, never tested against where CUI actually flows on a Tuesday afternoon.
The places CUI usually goes missing aren’t exotic:
- Email attachments.
- Shared drives that predate the CUI program
- Cloud storage a project team spun up without telling security
- Subcontractor systems nobody scoped in because the relationship was about parts and delivery, not data.
Assessors evaluating this requirement are going to look for a documented, current inventory tied to specific system components, not a narrative paragraph, and not a diagram that hasn’t been touched since the SSP was written.3
03.12.05, Information Exchange: Know Where It Travels
Knowing where CUI sits is only half the picture.
03.12.05 covers the other half: what happens when CUI moves between systems, including outside the organization.
Approve and manage the exchange of CUI between the system and other systems using [interconnection security agreements; information exchange security agreements; memoranda of understanding or agreement; service-level agreements, or other types of agreements]… Review and update the exchange agreements [organization-defined frequency].
The requirement covers exchanges both internal and external to the organization. The type of agreement should match the relationship and the level of access involved.4
In practice, that could mean:
- A dedicated interconnection security agreement
- A memorandum of understanding
- A cloud provider’s service-level agreement
- Contract language that spells out how CUI moves and who’s responsible for protecting it at each end.
A generic NDA doesn’t cut it. Neither does a boilerplate flow-down clause buried three pages into a subcontract. The agreement has to actually describe how the exchange is controlled.
Organizations most often skip this step with outside parties – subcontractors, cloud vendors, portals – rather than internal transfers. That’s mostly because internal transfers stay inside one security domain that already has some baseline policy.
External exchanges cross a trust boundary, which is precisely where formal agreements start to matter.
It’s also where self-attestation has quietly stood in for verification. A prime takes a subcontractor’s word that CUI is handled correctly, but there is no document spelling out how the exchange itself is governed.
That 2026 workshop flagged this exact failure mode: CUI moving through a channel nobody had actually authorized or written down.1
Under Rev. 3, that’s not a gray area anymore. It’s a documented control gap.
Why These Two Belong Together
Location tracking without exchange tracking tells you half the story. The reverse does too.
You can build an airtight internal inventory of where CUI sits and still have no idea it’s leaking out through an exchange with a subcontractor nobody’s managing. Just as easily, you can have clean interconnection agreements on paper with no real visibility into where the CUI those agreements govern actually lives day to day.
The failure mode to watch for is the half-measure: solid technical controls on your own systems, but no mechanism to track what’s leaving them, where it’s headed, or under what agreement.
Or the mirror image: tidy legal agreements that don’t correspond to anything in your actual technical environment.
Location answers: “what do we have and where is it.”
Exchange answers: “where does it go and under what terms.”
You need both, connected to each other, to actually understand your CUI footprint. One without the other is a map with half the roads missing.
Building the Register
The most direct way to satisfy both requirements (and to operate with actual confidence instead of just clearing an assessment) is a living CUI Register, built before CUI starts flowing rather than reconstructed after a finding.
A working register isn’t a static spreadsheet built once for an assessment and then forgotten.
At minimum, for every instance of CUI, it documents:
- What it is, and where it was received from
- Which systems and physical locations store or process it
- Who the data custodian is
- Who currently has possession of it
- What external systems or entities it’s been shared or disseminated with, mapped directly to the agreements 03.12.05 requires
Who should own the CUI Register?
Ownership matters as much as content. A register that lives solely with IT tends to miss the business relationships that create new exchanges: new subcontracts, new program requirements, a cloud service a project team spun up on its own.
A register that lives solely with compliance tends to miss the technical reality underneath it.
The model that holds up gives compliance or GRC ownership of the register itself, with IT and program or operations teams as required contributors whenever a system, a supplier relationship, or a data flow changes.
How often should the CUI Register be updated?
Update triggers should be event-driven, not just calendar-driven.
A new subcontract, a new system, a new cloud service, an offboarded supplier, or a discovered exchange nobody documented should all trigger an update, on top of a baseline periodic review.
Tooling matters too.
A spreadsheet can work for a very small, single-site environment. But it breaks down quickly once multiple systems, business units, or supply chain tiers get involved.
Past that point, a GRC platform or dedicated register tool that ties locations to exchange agreements, and flags when either goes stale, can earn its cost quickly.
Where to Start
If you’re standing up a register this quarter, this is the order that works:
- Inventory every system, component, and physical location that touches CUI today – not the SSP version, the real one.
- List every external party CUI has touched in the last 12 months, agreement or no agreement.
- Assign a data custodian to each CUI instance and a single owner for the register itself.
- Pull existing exchange agreements and flag every gap where none exists.
- Set your event-driven update triggers before you close the project, not after the first gap surfaces.
Rev. 3 didn’t add 03.04.11 and 03.12.05 as bureaucratic overhead. It added them because assessors and practitioners kept running into organizations that genuinely couldn’t answer where their own CUI was, or where it had gone, even when asked directly.1,3
A living CUI Register, built before data starts flowing, addresses both requirements at once. And it’s one of the few pieces of this transition that can pay for itself immediately.
An organization that can actually answer “where does your CUI go” has already solved a problem most of its peers are still carrying.
Frequently Asked Questions
What is a CUI Register?: A CUI Register is a living record of where an organization’s Controlled Unclassified Information is stored, processed, and shared. It connects the CUI an organization handles to the systems, physical locations, people, and outside parties that interact with it.
Does NIST SP 800-171 Rev. 3 specifically require a “CUI Register”?: Not by that name. Requirements 03.04.11 and 03.12.05 require organizations to document where CUI is processed and stored, track changes to those locations, and manage exchanges of CUI between systems. A CUI Register is one practical way to bring that information together and keep it current.
Isn’t our System Security Plan enough? Not necessarily. An SSP describes your system and security environment, but these requirements call for specific, current information about where CUI is processed and stored and how it is exchanged. The question isn’t just whether your documentation describes the environment. It’s whether you can show where CUI actually sits and where it goes.
What should be included in a CUI Register? At minimum, the register should document what the CUI is, where it came from, which systems and physical locations process or store it, its data custodian, who currently has possession of it, and any external systems or entities it has been shared with. Those external exchanges should also connect back to the agreements used to govern them.
Who should own the CUI Register? Compliance or GRC can own the register itself, but maintaining it should be a cross-functional responsibility. IT, program teams, operations, and other relevant stakeholders need to contribute when systems, supplier relationships, or data flows change.
How often should a CUI Register be updated? Don’t rely only on an annual or quarterly review. Updates should also be triggered by events such as adding a new system or cloud service, entering a new subcontract, offboarding a supplier, changing a data flow, or discovering an undocumented exchange.
How Redspin Can Help
Knowing where your CUI is supposed to be is one thing. Being able to show where it actually lives, who touches it, and where it travels is another.
Redspin helps federal contractors understand their real CUI footprint, evaluate existing data flows and environments, identify gaps, and prepare for evolving NIST SP 800-171 requirements.
Whether you’re working through the transition to Rev. 3, revisiting the scope of your CUI environment, or trying to build a process you can actually maintain, our team can help you turn what’s on paper into something that reflects how your organization operates day to day.
Do You Know Where Your CUI Actually Goes?
Your CUI environment may extend beyond the systems listed in your SSP. If CUI is moving through people, platforms, suppliers, and systems you aren’t actively tracking, it’s time to map the real environment.
Redspin can help you find the gaps, understand
Footnotes
1. Winning at What Cost? Supply Chain Risk, CMMC, and the Decisions That Define Defense Readiness. CS5 West 2026 Supply Chain Risk Mapping Workshop white paper, “Supply Chain Management: Getting Real About Supply Chain Risk.”
4. National Institute of Standards and Technology, NIST Special Publication 800-171 Revision 3, §03.12.05 Information Exchange (May 2024).
