CUI Basic vs CUI Specified

CUI Basic uses the uniform Part 2002 controls and the moderate baseline, while CUI Specified adds category-specific handling rules. This page explains what that means for your contract and your NIST SP 800-171 scope.

On this page

CUI Basic vs CUI Specified: which one your contract really carries

CUI Basic has no authority-specific handling controls, so it falls under the uniform controls of 32 CFR Part 2002 and the CUI Registry. CUI Specified has handling controls written into its authorizing law, regulation or Governmentwide policy, those controls may be more stringent or simply different, and the category must appear in the marking. When a contract or prime's flow-down mentions CUI, the first task is to find out which of the two the information is, because that answer decides whether the marking, and possibly the safeguarding, goes beyond the baseline. Part 2002 fills any gap in a CUI Specified authority with Basic controls, so the Specified category adds requirements rather than replacing the general ones.

NIST SP 800-171 reaches both categories through the agency. Under 32 CFR 2002.14(h)(2), federal agencies use SP 800-171 when setting requirements for CUI on nonfederal systems, unless the category's authority prescribes other safeguards or an agreement sets protection above the moderate level. The category therefore changes two things for your team: the mandatory category or subcategory markings for CUI Specified, and the chance that a specific authority requires safeguards that go past what your SP 800-171 implementation already covers. Ask the contracting officer or prime which category applies to each data set and which authority, if any, the contract cites. Check the CUI Registry entry for that category before you accept the flow-down as written.

The organization owns its controls and is responsible for showing how they meet the requirements. A team can prepare the system security plan, the marking procedures and the evidence for any extra safeguards, but an independent assessor issues any assessment result, and the agency or prime decides the contractual consequences. Record the category of each CUI holding in your data inventory, since the answer drives the marking workflow, the access rules and the assessment scope. If the agency has not specified a required safeguard for a Specified category, ask in writing rather than assuming the Basic baseline applies.

How the two categories differ in marking, safeguarding and dissemination

Marking is the first place the two categories look different on paper. Under 32 CFR 2002.20, every item of CUI carries a banner marking built from up to three elements, and the control marking is the one element that is always required. Category or subcategory markings are a second element. For CUI Specified they are mandatory, because the authority behind the information has its own handling rules that the marking has to signal. For CUI Basic, the category marking is optional at the portion level, so a document can be correctly marked with only the CUI control marking and any limited dissemination markings.

  • Control marking for all CUI: The word CONTROLLED or the acronym CUI must appear in the banner of every CUI item, whether Basic or Specified.
  • Category markings for CUI Specified: The category or subcategory must be shown in the banner, using the form the CUI Registry defines.
  • Optional category portion markings for CUI Basic: Portion marks use the acronym CUI, and category portion markings are not required for Basic information.
  • Limited dissemination markings: Any dissemination control appears in the banner in addition to the other elements.
  • Portion marking: Agencies are permitted and encouraged to portion mark, so mixed documents need per-paragraph review.

Confirm with the contracting officer or the agency's CUI program office which marking forms they expect on deliverables, and check the CUI Registry before you assume a category is Basic.

Why the moderate baseline shapes the NIST SP 800-171 scope

CUI Basic is categorized at no less than the moderate confidentiality impact level, and that floor is the reason NIST SP 800-171 exists in its current form. Under 32 CFR 2002.14(g), an agency may raise CUI Basic above moderate only inside the agency or through agreements with non-executive branch entities. For a contractor, that means the confidentiality baseline behind a CUI Basic contract is set by the agency and is not negotiated downward. The protections you owe are therefore expected to track the moderate level, whatever the contract's paperwork looks like.

NIST built SP 800-171 Rev. 3 by tailoring the controls in the SP 800-53B moderate baseline, removing controls that are primarily the federal government's responsibility or that do not directly protect CUI confidentiality. That is why the requirements read as they do and why Rev. 3 added the Planning, System and Services Acquisition, and Supply Chain Risk Management families to stay consistent with that baseline. Rev. 3 contains 97 requirements. The version used for DoD contracts under CMMC Level 2 is Rev. 2, with 110 requirements, and the two numbering schemes do not map one to one. Confirm with the contracting officer which revision the contract names and whether a Class Deviation or a clause update applies to it.

Ask the contracting officer two questions before scoping: which revision of SP 800-171 the contract cites, and whether any agency-specific requirements, organization-defined parameter values or additional safeguards from the CUI category's authority apply. Under 32 CFR 2002.14(h)(2), safeguards can go beyond the standard only where the authority prescribes them or an agreement sets protection above moderate. Record the answers in the system security plan so the scope you assess against matches what the contract requires.

When an agency can require more than NIST SP 800-171

NIST SP 800-171 is the default baseline for CUI on nonfederal systems, but it is not always the ceiling. Five situations can add requirements, and each one is decided by the authority behind the CUI, the agreement, or the contract, not by the contractor. The contractor's job is to find which of these applies before scoping its system.

Category authority prescribes other safeguards

Some CUI categories rest on a law, regulation or Governmentwide policy that sets its own safeguards, and 32 CFR 2002.14(h)(2) lets those prescribed safeguards override NIST SP 800-171. Check the CUI Registry entry for the category or subcategory named in the contract. If the registry lists specific handling controls, the contractor must follow them alongside, or instead of, the 800-171 requirements. Ask the contracting officer to identify the authority in writing.

Agreement sets protection above moderate

Under 32 CFR 2002.14(h)(2), an agreement can set CUI protection above the moderate level. This usually appears in a data use agreement, a memorandum of understanding or a contract clause that names stronger controls than the moderate baseline. Read the agreement's safeguarding section and compare it with the system security plan. Any stronger control written there becomes part of what the contractor must prove during assessment, so confirm scope with the agency before building the enclave.

Limited dissemination controls restrict recipients

A limited dissemination control can restrict who may receive CUI, which affects user access lists, foreign person access and sharing with subcontractors. These controls may only be used when they are approved by the CUI Executive Agent and published in the CUI Registry, and only to further a lawful Government purpose. Check the banner marking for any dissemination control and confirm which personnel, nationalities or organizations are authorized before granting access.

Organization-defined parameter values from the agency

SP 800-171 Rev. 3 leaves some values to the organization, and NIST does not assign them. If the agency does not specify these values, the nonfederal organization must assign them to complete the requirement. Agencies may instead publish values or contract-specific requirements that are stricter. Ask the contracting officer whether parameter values, such as review frequencies or retention periods, are fixed in the contract, and record the answer in the system security plan.

DFARS and export rules layer on top

Some contracts add obligations beyond SP 800-171 through clauses such as DFARS 252.204-7012, which carries its own incident reporting, cloud and flow-down duties, or through ITAR and EAR rules for export-controlled technical data. These rules are separate from the CUI category and often apply to the same system. Review the contract's clause list and any export classification, then confirm with the contracting officer and the organization's export compliance lead which requirements apply to the systems in scope.

Limited dissemination controls and who may receive CUI

An agency can narrow who may receive a piece of CUI only through limited dissemination controls approved by the CUI Executive Agent and published in the CUI Registry, and only when the restriction furthers a lawful Government purpose or a law, regulation or policy requires it. For a contractor, that means any dissemination limit should trace to a registry entry named in the contract or the marking, not to a verbal instruction or a habit inside the agency. Before you change who can open a file, confirm each limited dissemination control against the registry and the contract itself rather than assuming what it means from its name.

Dissemination limits flow down with the information. If a prime contractor passes CUI to a subcontractor, the subcontractor must be authorized to receive that specific control, and the prime should not widen access beyond what the marking and contract allow. Build a short check into your subcontract process: identify which controls appear in the banner or portion markings, confirm each one with the contracting officer or the registry, and record the result in the flow-down package. Expect that some subcontractors will not be cleared for every control, and plan for the handling changes that follows.

Personnel access follows the same logic inside your own organization. Limit access to CUI to employees and agents who have a lawful need and are authorized for the relevant control, and keep the access list current as roles change. Your access control and personnel security procedures should be able to show who holds access to each marked category, when that access was granted and why. Ask the agency or prime to identify any control that restricts foreign or third-party access, and confirm with them how cloud services and offshore support staff are treated before any data moves.

How to classify CUI in a contract step by step

This sequence turns a contract's CUI instructions into a written classification record that shows which categories are Basic or Specified, which markings apply, and which security requirements the system must meet.

  1. Collect every CUI reference in the contract

    The contracts or security office lead reads the statement of work, the DD Form 254 or equivalent security instructions, and any attachments that name information to be protected. They list each CUI category or subcategory the contract identifies, along with the document or clause where it appears. Done means a single inventory exists with one row per category and a source citation for each row. Information the contract does not mention stays out of the inventory until the contracting officer confirms it is CUI.

  2. Look up each category in the CUI Registry

    For each row in the inventory, the compliance lead checks the CUI Registry entry for the category or subcategory and its authority. The registry shows whether the governing law, regulation or Governmentwide policy sets specific handling or dissemination controls. A category with such controls is CUI Specified, and a category without them is CUI Basic. Record the registry entry, the authority cited and the classification, so an assessor can trace the decision back to its source.

  3. Identify the specific controls for CUI Specified categories

    For each category marked Specified, the compliance lead reads the authority's handling or dissemination requirements and notes where they differ from the baseline. Some may be stricter, and others may simply be different. Each difference goes into the record with the affected handling step, such as storage, transmission or destruction. Done means every Specified category has a list of its own requirements, and the team knows which CUI Basic controls still apply to any aspect the authority does not address.

  4. Record markings and limited dissemination controls

    The security or records lead notes the banner marking elements the contract requires: the CONTROLLED or CUI control marking, any category or subcategory markings, and any limited dissemination control markings. Category markings are mandatory for CUI Specified, so a missing category marking on a Specified item is a finding to resolve before the record is final. If the contract places extra limits on dissemination, the team confirms each limit is a control approved and published in the CUI Registry, then records it with the agency or contracting officer who imposed it.

  5. Confirm the NIST SP 800-171 version and ODP values

    The contracts lead confirms which revision of NIST SP 800-171 the contract or clause names and asks the agency to state the organization-defined parameter values it expects. Rev. 3 assigns no ODP values itself, and if the agency does not specify them, the nonfederal organization must assign them to complete the requirement. Done means the record states the revision, lists each ODP value with its source, and notes any open question for the contracting officer in writing.

  6. Determine which systems hold the classified CUI

    The system owner maps each classified category to the systems, enclaves, media and service providers that store, process or transmit it. This map shows which systems fall within the requirements of the contract and which do not. Done means each system has a named owner and a list of the CUI categories it handles, so the boundary in the next step rests on a verified inventory.

  7. Document results in the SSP scope

    The compliance lead writes the classification record and transfers its results into the scope section of the system security plan. The scope names each CUI category, its Basic or Specified status, the markings and dissemination controls, the NIST SP 800-171 revision, the ODP values and the systems in boundary. The record is signed by the contracts and security owners, and it is reviewed again whenever the contract is modified or the CUI Registry changes. Any assessor will test the SSP against this record.

Mistakes that change scope or cost after the contract is signed

Most scope creep on CUI work starts before any system is built, when the team assumes how information is classified. The four mistakes below share a root cause: the classification of each CUI item was never written down and checked against the registry and the contract. A written classification review before work starts keeps the handling controls, and the cost of meeting them, tied to a documented decision.

Treating every item as Basic

Teams often label all contract information as CUI Basic because it is the default form. An item's authorizing law, regulation or Governmentwide policy may set specific handling or dissemination controls, which makes it CUI Specified. Check each category against the CUI Registry and record the authority cited for every item. Ask the agency to confirm the category in writing when the registry entry is unclear.

Missing Specified category markings

Mandatory category or subcategory markings apply to CUI Specified material, and omitting them is a handling error that follows the document into every copy, extract and derivative. Review the banner and portion markings on each Specified item before it moves into a shared repository or a subcontractor's hands. Add a marking check to the review record so the scope of corrections is known before work begins.

Assuming Rev. 3 covers authority controls

NIST SP 800-171 sets the baseline safeguards for CUI on nonfederal systems, but a CUI Specified authority can prescribe safeguards beyond that baseline. Those authority-specific controls are not covered by the 97 Rev. 3 requirements and must be identified separately. Ask the contracting agency which authority-specific controls apply and whether they change the system security plan, the scope of the enclave or the assessment effort.

Dissemination limits not flowed down

Limited dissemination controls restrict who may receive CUI, and agencies may impose them only through approved controls in the CUI Registry. A prime that passes Specified material to a subcontractor without carrying those limits forward has exposed the information outside its permitted audience. Put the applicable dissemination controls into each subcontract and into the classification review, and confirm each recipient is authorized before transfer.

Questions contractors ask about CUI Basic and CUI Specified

Does CUI Specified require a different NIST SP 800-171 assessment?

No. The assessment is still run against the same NIST SP 800-171 requirements, whether the information is CUI Basic or CUI Specified. The difference is that the authority behind a CUI Specified category can add handling or dissemination controls that go beyond those requirements, and those additional controls must be confirmed before scoping. Ask the contracting officer or the agency's CUI program office to identify the authority, check the CUI Registry for the specific controls it contains, and record each one in the system security plan so the assessor can test it. CUI Basic controls fill any aspect the authority does not cover, so the baseline is not replaced, only extended where the authority requires it.

Who decides whether information is CUI Basic or CUI Specified?

The federal agency decides, usually through its designated CUI official or the contracting officer who issues the contract. The category follows from the law, regulation or Governmentwide policy that authorizes the information, and the CUI Registry shows which authorities contain specific handling controls. A contractor does not choose the category on its own, and a contractor that believes information is marked incorrectly should raise the question with the contracting officer in writing. Where the contract is silent, ask for the category and the authority before you build controls around the data.

Can DeployOpen classify our data as CUI Basic or CUI Specified?

DeployOpen cannot make that determination, and the agency that issues the contract owns it. DeployOpen can help you prepare the material the agency will need: an inventory of where the information is created, stored and transmitted, a data flow map, the marking and handling procedures your staff will follow, and the technical settings in the systems that hold the data. That record makes the agency's decision faster to reach and easier to verify. DeployOpen does not issue classification decisions, attestations or assessment reports, and an independent assessor is needed for any formal assessment.

How long does it take to confirm the CUI category for a contract?

The time depends on how complex the contract is and how quickly the agency responds, so no fixed duration applies. Contracts that name a single authority and mark the information clearly are usually quicker to confirm than contracts that draw on several authorities or leave the marking to the prime contractor. Ask the contracting officer for a written statement of the category and authority for each information type, and confirm during scoping how many information types and authorities the contract involves. Build that confirmation step into the project plan so that system design does not start on an unconfirmed assumption.

Does a CUI Specified category change the cost of a CUI enclave?

It can, because the authority may add marking, access, monitoring or dissemination work on top of the standard NIST SP 800-171 effort. Cost drivers include how many categories and limited dissemination controls apply, whether the added controls need new access restrictions or logging, whether marking must be applied to documents and media, and how much staff training and documentation the changes require. A quote should list each added control, the system or process it touches, and whether the work is one-time configuration or recurring operation. Ask for the added items to be separated from the baseline so you can see what the category itself adds.

What should we ask for in writing before scoping a CUI Specified contract?

Ask for the category and authority for each information type, the specific handling or dissemination controls the authority requires, and any limited dissemination control markings that apply. Also ask whether the agency has required protection above the moderate confidentiality level, since that changes the baseline. Request the names of any personnel, facility or system conditions attached to the category, and confirm who the agency contact is for questions after award. With those answers in hand, the system security plan can state each additional control and who is responsible for it, which is what an independent assessor will check.

How DeployOpen helps you map CUI categories to controls

DeployOpen works on the infrastructure side of CUI Basic and CUI Specified: it helps you decide which handling controls each category of information needs, then builds and documents the systems that enforce them. Engagements are fixed-scope, and the organization that holds the contract remains responsible for its controls.

How we scope

  • We inventory the CUI categories and systems you handle, and record which ones carry category markings that call for specific handling controls.
  • The written scope lists which systems, enclaves and workflows are in scope, and which controls each one must satisfy.
  • We confirm with you which agency or contract authority sets any additional requirements, so the scope reflects what your contract actually requires.

How we build

  • We configure marking, access and dissemination controls in your environment so category and limited dissemination requirements are enforced by the system.
  • We map each handling control to the matching SP 800-171 requirement and document where an organization-defined parameter needs a value from the agency.
  • We test the configured controls against the examine, interview and test methods in SP 800-171A before anyone signs off on them.

How we hand over

  • You receive the system security plan, control mapping, configuration records and test results for each CUI category in scope.
  • Operating procedures explain who may apply, change or remove each category marking, and how staff handle mismarked or unmarked material.
  • Your team receives a walkthrough of the evidence so it can answer assessor questions. An independent assessor, not DeployOpen, decides the outcome.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer, so controls stay aligned when a contract or agency requirement changes.
  • We can revisit the category mapping when the CUI Registry, agency agreements or the applicable SP 800-171 revision changes.
  • Any change to scope is agreed in writing before work starts, with its own deliverables and timeline.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.