What Level of System and Network Configuration Is Required for CUI?

Last reviewed: July 23, 2026

Editorial note: This guide uses current NIST, NARA, CMMC, and DFARS sources. Contract and agency requirements may differ.

Quick Answer: Systems that process, store, or transmit CUI require no less than a Moderate Confidentiality Impact Level. Federal systems generally use FIPS 199, FIPS 200, and NIST SP 800-53. Non-federal systems generally use NIST SP 800-171 when required through a contract or agreement.

Controlled Unclassified Information requires more than basic antivirus software. Organizations must protect every system that handles or safeguards CUI.

These systems may include:

• Computers and laptops
• Servers and applications
• Email and collaboration tools
• Cloud platforms
• Network equipment
• Security and backup services

The word “Moderate” does not describe system speed or performance. It does not refer to processor power, storage, or bandwidth.

Instead, it describes the possible impact of unauthorized disclosure. A breach could seriously affect government operations, organizations, or individuals.

CUI Basic requires no less than Moderate Confidentiality protection. CUI Specified may require added controls under its governing authority.

The exact framework depends on several factors:

• Who owns or operates the system
• Which CUI category applies
• What the contract requires
• Which government agency controls the information
• Whether CMMC or DFARS clauses apply

This guide explains the required security level. It also covers systems, networks, cloud services, scope, and documentation.

What Is Controlled Unclassified Information?

Controlled Unclassified Information, or CUI, is unclassified government information that needs safeguarding or dissemination controls.

Those controls must come from a law, federal regulation, or government-wide policy. The CUI Program creates a standard approach for handling this information.

CUI is not classified information. It does not carry Secret or Top Secret classifications.

However, unauthorized disclosure can still cause serious harm. It may expose sensitive operations, technical data, personal records, or infrastructure details.

Government agencies may create, receive, process, and share CUI. Contractors, universities, laboratories, and service providers may also handle it.

Common CUI categories may include:

• Certain privacy and health records
• Export-controlled technical information
• Law-enforcement information
• Critical infrastructure information
• Certain procurement information
• Defense-related technical information

Not every private or sensitive document qualifies as CUI.

For example, a technical drawing does not become CUI simply because a company considers it confidential. The information must connect to an approved CUI category or authority.

The official CUI Registry lists recognized categories, authorities, markings, and controls. Agency personnel and contractors should also review agency-specific policies.

CUI Basic and CUI Specified

CUI falls into two main groups.

CUI Basic uses the standard safeguards defined by the CUI Program. These standards apply unless the CUI Registry identifies added requirements.

CUI Specified follows controls from a specific law, regulation, or government-wide policy.

CUI Specified may carry stricter rules for:

• Access
• Sharing
• Storage
• Marking
• Transmission
• Destruction

These groups do not represent two classification levels. They describe which handling requirements apply.

When an authority remains silent on one control, CUI Basic safeguards may apply to that area.

How to Identify CUI Correctly

Organizations should not label information as CUI through guesswork.

Check these sources first:

• The government contract
• Agency instructions
• The CUI Registry
• Applicable laws or regulations
• Approved document markings

Markings help users recognize handling requirements. However, a marking alone does not create CUI.

The information must fall under an approved category and authority.

Staff should also receive practical training. They must know how to recognize, store, share, and dispose of CUI.

Incorrect identification creates two risks.

Under-protection can expose sensitive information. Over-classification can expand scope and increase compliance costs.

Which Security Standard Applies to Your System?

Not every CUI environment follows the same security framework.

The correct standard depends on the system type, contract, agency, and CUI category.

Environment	Starting Framework	Important Qualification
Federal agency system	FIPS 199, FIPS 200, and NIST SP 800-53	The agency selects applicable controls
Non-federal CUI system	NIST SP 800-171	A contract or agreement should establish the requirement
DoD contractor	CMMC and applicable DFARS clauses	The contract identifies the required CMMC status
External DoD cloud service	FedRAMP Moderate equivalent may apply	Check DFARS and the exact service offering
CUI Specified environment	Governing law or policy	Added safeguards may apply

Federal Information Systems

Federal agencies categorize systems through FIPS 199.

CUI Basic requires no less than a Moderate Confidentiality Impact Level. Agencies then apply suitable controls from FIPS 200 and NIST SP 800-53.

Those controls may cover:

• Identity and access
• System configuration
• Communications
• Monitoring
• Incident response
• Physical security
• Risk management

Agencies can tailor controls through approved risk decisions. They may also apply stronger internal protections.

Non-Federal Systems

Non-federal organizations often receive CUI while supporting government work.

Examples include:

• Government contractors
• Research organizations
• Universities
• Manufacturers
• Professional service providers

NIST SP 800-171 defines security requirements for CUI within non-federal systems. It applies to components that process, store, or transmit CUI. It also covers components that protect those systems.

The contract or agreement should establish the applicable obligation.

Organizations should not assume that every government project contains CUI.

DoD Contractors

DoD contractors may face CMMC and DFARS requirements.

CMMC Level 2 uses the 110 security requirements from NIST SP 800-171 Revision 2. Current CMMC rules state that these requirements are identical.

However, not every DoD contract requires the same assessment type.

The contracting officer and contract terms determine:

• The required CMMC level
• Whether self-assessment applies
• Whether certification applies
• Which systems enter scope
• When the required status must exist

A Simple Framework Decision Process

Use this process before building the environment:

1. Identify the system owner.
2. Confirm the CUI category.
3. Review the contract clauses.
4. Identify the required NIST revision.
5. Check CMMC and DFARS duties.
6. Define the security boundary.
7. Confirm cloud and provider rules.

Do not select a framework from a blog or checklist alone. The governing contract and official requirements control the final decision.

Key System Configuration Requirements for CUI

A secure network cannot protect weak endpoints.

Every in-scope system needs controlled settings and clear ownership. This includes devices that handle CUI and tools that protect them.

NIST SP 800-171 covers control families such as access, authentication, configuration, monitoring, incident response, media protection, and system integrity.

The exact implementation depends on the applicable revision and contract.

Access Control and Authentication

Core goal: Allow only approved users and devices to access CUI.

Each user should receive an individual account. Shared accounts weaken accountability and complicate investigations.

Apply least-privilege access. Users should receive only the permissions needed for their roles.

For example, an employee may read project records. Only administrators should change security settings.

Strong access practices include:

• Unique user accounts
• Role-based permissions
• Regular access reviews
• Session locks and timeouts
• Fast removal of inactive accounts
• Separate administrator accounts
• Controls for failed login attempts

Multi-factor authentication adds another identity check.

It may use:

• A security key
• An authentication application
• A smart card
• A biometric factor

MFA requirements depend on the applicable framework. Privileged and remote access commonly receive stronger controls.

Each person should control their own authentication factor. Teams should not share one MFA device.

Administrators should also separate normal and privileged work. They should use elevated access only when required.

Secure Configuration, Software, and Patching

Core goal: Build each system from an approved security baseline.

A baseline defines permitted software, settings, ports, and services. It helps teams configure similar systems consistently.

A secure baseline may cover:

• Approved operating systems
• Disabled guest accounts
• Removed default passwords
• Restricted administrator rights
• Approved applications
• Secure browser settings
• Disabled unnecessary services
• Blocked unused ports

Teams should document their chosen baseline. They should review it after major system changes.

Unused software increases the attack surface. Remove applications and services that serve no business purpose.

Unsupported software also creates risk. Vendors may stop releasing security fixes.

Maintain an asset-based patching process. Prioritize critical weaknesses and internet-facing systems.

A practical patching process should track:

• Affected assets
• Vulnerability severity
• Available updates
• Testing results
• Installation status
• Failed updates
• Approved exceptions

Emergency changes may need faster action. Teams should still document and review them afterward.

Endpoint, Media, and Data Protection

Core goal: Protect CUI against malware, theft, and unauthorized copying.

Endpoint security tools can detect harmful files and suspicious behavior. These tools should receive current detection updates.

They may inspect:

• Email attachments
• Downloaded files
• Removable media
• Running processes
• Network activity

Antivirus alone cannot protect CUI. It must work with access controls, patching, monitoring, and training.

Removable media also needs strict control.

Organizations may limit USB drives to approved devices. They can block unknown media through endpoint policies.

Approved media may require:

• Encryption
• Clear ownership
• Usage approval
• Inventory records
• Secure storage
• Proper disposal

Personal storage devices should not enter a CUI environment without approval.

Encryption can protect CUI after device theft or unauthorized access.

Organizations may encrypt:

• Laptops
• Servers
• Databases
• Backups
• Removable media

However, encryption does not replace access control. A stolen authorized account may still expose encrypted data.

Protect keys and certificates carefully. Weak key management can defeat strong encryption.

Monitoring, Change Control, and Recovery

Core goal: Detect events, control changes, and restore operations.

Audit logs can record:

• Successful sign-ins
• Failed login attempts
• Account changes
• File access
• Administrator actions
• Security alerts
• Configuration changes

Protect logs against unauthorized deletion or alteration. Retain them for the required period.

Collecting logs provides little value without review. Assign clear staff responsibility for alert investigation.

Change control protects approved configurations.

Important changes should receive:

• Review
• Approval
• Testing
• Documentation
• Post-change checks

Configuration monitoring can also detect unexpected changes.

Backups support recovery from ransomware, hardware failure, and human error.

Protect backups through:

• Restricted access
• Suitable encryption
• Separate credentials
• Secure storage
• Restoration testing

A backup only helps when recovery works. Test restoration on a planned schedule.

Maintain an accurate asset inventory as well.

The inventory should include:

• Devices
• Software
• Applications
• Cloud services
• Security tools
• Network components
• Backup systems

Each asset should have an owner and business purpose.

Unknown assets create hidden gaps. Update the inventory after important changes.

Key Network Configuration Requirements for CUI

A secure network controls every path that can carry CUI.

This includes internal traffic, cloud connections, remote access, wireless networks, and external providers.

Network Boundary, Firewalls, and Segmentation

Core goal: Define where the CUI environment starts and ends.

The boundary may include:

• Managed endpoints
• Servers
• Applications
• Cloud services
• Firewalls
• Identity systems
• Monitoring platforms
• Backup services

Map where CUI enters, moves, remains stored, and leaves.

Document this information within the System Security Plan. Maintain a matching network and data-flow diagram.

A simple CUI flow may look like this:

Government Source
       |
       v
Approved Secure Email
       |
       v
Managed CUI Device
       |
       v
Approved CUI Cloud
       |
       v
Protected Backup

Firewalls should control traffic at important boundaries.

Allow only required traffic. Block unnecessary services and connection types.

Document the business purpose, source, destination, protocol, owner, and review date for important firewall rules.

Review rules regularly. Remove expired or temporary access.

Segmentation can separate the CUI environment from normal business systems.

Possible methods include:

• Internal firewalls
• Separate network zones
• Access control lists
• Dedicated cloud segments
• Secure virtual environments

A separate VLAN alone does not create an effective enclave.

Teams must also control:

• User identities
• Endpoint access
• Applications
• Data transfers
• Security services
• Administrative paths

External, Remote, and Wireless Access

Every external connection creates another access path.

Identify and approve connections involving:

• Vendors
• Partners
• Cloud platforms
• Remote offices
• Support providers
• Managed security services

Document why each connection exists. Record which systems and data it can reach.

Remote access should use managed and approved methods.

Typical controls include:

• MFA
• Encrypted connections
• Approved devices
• Session limits
• Activity logging
• Restricted administrator access

Do not allow CUI downloads onto personal devices unless the approved environment supports that use.

Public and shared computers should not access CUI systems.

Wireless networks also need strong authentication and encryption. Separate guest wireless access from the CUI environment.

Users working away from the office should follow approved remote access procedures.

Secure Communications and Allowed Services

Protect CUI while it travels across networks.

Possible transmission methods include:

• Secure web sessions
• Approved email systems
• Encrypted file-sharing tools
• Protected remote connections
• Secure application links
• Encrypted site-to-site connections

Disable weak or outdated protocols.

Allow only required network ports and services. Regularly review firewalls, routers, switches, servers, and cloud security groups.

Encryption must protect the complete transmission path. A secure connection cannot protect an unsafe destination.

Manage certificates and encryption keys carefully. Expired certificates can break services or weaken trust.

Network Monitoring and Security Testing

Network monitoring can reveal:

• Suspicious connections
• Repeated login failures
• Malware traffic
• Unusual data transfers
• Unauthorized scans
• Unexpected cloud activity

Useful monitoring sources include:

• Firewall logs
• VPN activity
• Authentication events
• DNS records
• Cloud access logs
• Endpoint alerts
• Intrusion detection tools

Define who reviews alerts. Set clear response priorities.

Intrusion detection tools can identify suspicious traffic. Prevention tools may block selected threats automatically.

Tune detection rules carefully. Poor settings can produce excessive false alerts.

Security checks should also test the network regularly.

These checks may include:

• Vulnerability scans
• Firewall reviews
• Port scans
• Wireless reviews
• Access tests
• Diagram reviews
• Monitoring tests

Document findings and remediation work.

Control Data Leaving the Network

Organizations must control how users share CUI.

Approved channels may include secure email or authorized file-sharing services.

Restrict unapproved methods, such as:

• Personal email
• Consumer cloud storage
• Public file-sharing links
• Personal messaging tools
• Unapproved printing
• Unauthorized removable media

Data loss prevention tools may detect some restricted transfers. However, they cannot replace training and access controls.

Employees must know where they may store and share CUI.

Public websites and internet-facing systems should remain separated from CUI environments. Any required connection should receive strict control and monitoring.

Does the Entire Company Network Need CUI Compliance?

No. The entire company network does not always enter the compliance scope.

Scope depends on how each asset interacts with CUI.

Systems that process, store, or transmit CUI remain in scope. Systems that protect those assets may also enter scope.

Organizations can reduce scope through proper separation. However, the separation must work technically.

A policy or label alone cannot place an asset outside scope.

CMMC Level 2 Asset Categories

Current CMMC rules define several Level 2 asset categories.

Asset Category	Description	Example
CUI Assets	Process, store, or transmit CUI	Managed laptop or CUI server
Security Protection Assets	Protect the CUI environment	Firewall or monitoring platform
Contractor Risk Managed Assets	Can handle CUI but should not	General business workstation
Specialized Assets	Can handle CUI but cannot use all normal controls	OT, IoT, GFE, or test equipment
Out-of-Scope Assets	Cannot handle CUI or protect CUI assets	Properly isolated office device

Relevant asset categories should appear within the required SSP, inventory, and network diagram.

CUI Assets

CUI Assets directly process, store, or transmit CUI.

Examples include:

• Laptops opening controlled files
• Servers storing CUI
• Approved email platforms
• Cloud services hosting CUI
• Applications processing controlled data
• Printers producing CUI
• Backups containing CUI

These assets receive assessment against applicable Level 2 requirements.

Security Protection Assets

Security Protection Assets safeguard the CUI environment.

Examples may include:

• Firewalls
• Identity platforms
• Vulnerability scanners
• Endpoint management systems
• Log collection tools
• Monitoring platforms

These assets may not hold main CUI files. However, their failure could weaken the environment.

They receive assessment against requirements linked to their security function.

Contractor Risk Managed Assets

These assets can handle CUI but should not receive it.

Examples may include standard office or marketing laptops.

Policies, procedures, and technical controls must support that decision.

Possible controls include:

• Blocking CUI downloads
• Restricting application access
• Preventing unapproved transfers
• Limiting network paths
• Training users

Assessors may review the documented treatment. They may also conduct limited checks when concerns arise.

Specialized Assets

Some systems can handle CUI but cannot use all standard controls.

Examples include:

• Internet of Things devices
• Industrial control systems
• Operational technology
• Government-furnished equipment
• Test equipment
• Restricted information systems

Identify these assets and manage them through documented risk-based controls.

Do not ignore them because standard security software cannot run on them.

Out-of-Scope Assets

An asset may remain outside scope when it cannot:

• Process CUI
• Store CUI
• Transmit CUI
• Protect CUI assets

It should also remain physically or logically separated from in-scope systems.

The organization should be able to defend that decision.

A device does not become out of scope through a spreadsheet label. Its technical settings and connections must support the claim.

Example of a Limited CUI Environment

Consider a company with 100 employees.

Only ten employees support a CUI contract. They use managed laptops and an approved cloud environment.

The company blocks access from all other devices.

Asset	Likely Treatment
Ten managed CUI laptops	In-scope CUI Assets
Approved CUI cloud	In-scope service
Firewall protecting the enclave	Security Protection Asset
Monitoring platform	Security Protection Asset
General marketing laptops	Potentially outside the CUI scope
Personal devices	Blocked from CUI access

This model can reduce scope and assessment costs.

However, weak segmentation may bring more systems into scope.

Trace the full CUI lifecycle:

• Where does CUI enter?
• Who can access it?
• Which systems process it?
• Where is it stored?
• How does it leave?
• Which tools protect it?
• Which providers support it?
• Which backups contain copies?

The answers should match all compliance records.

CUI Requirements for Cloud Services

Organizations can use cloud services for CUI. However, the exact offering must meet contract requirements.

A provider’s brand name does not prove compliance. Large providers often sell several service tiers with different boundaries.

Check the Contract Before Using Cloud Services

The contract may define:

• Required security controls
• Approved data locations
• Incident reporting duties
• FedRAMP requirements
• CMMC expectations
• Provider responsibilities

DoD contractors should check whether DFARS 252.204-7012 applies.

When it applies, an external cloud provider handling covered defense information must meet security requirements equivalent to the FedRAMP Moderate baseline. The provider must also support related incident and forensic duties.

Current CMMC scoping rules also require a cloud service processing CUI to meet the applicable DFARS FedRAMP requirements.

These requirements do not automatically apply to every civilian CUI contract. Always review the governing terms.

Verify the Exact Service Offering

Before selecting a provider, verify:

• Exact product name
• Authorization or equivalency status
• Included service boundary
• Approved regions
• Available security features
• Connected applications
• Customer responsibilities
• Incident support
• Contract compatibility

Do not rely only on sales language.

One product may hold authorization while another product does not.

Understand Shared Responsibility

Cloud providers secure part of the environment. Customers still manage many controls.

The provider may protect data centers and core infrastructure.

The customer may remain responsible for:

• User access
• MFA
• Sharing settings
• Connected devices
• Data classification
• Logging
• Account removal
• Application configuration

CMMC rules require organizations to document provider relationships. The SSP and customer responsibility matrix should explain each party’s duties.

A compliant provider cannot correct weak customer settings.

Configure Cloud Services Securely

Use individual accounts and role-based access.

Disable public sharing unless a clear authorization permits it.

Control:

• Guest accounts
• External links
• File downloads
• Email forwarding
• Third-party applications
• Cross-organization sharing

Protect CUI during storage and transmission.

Enable logs for:

• Sign-ins
• Failed logins
• File access
• Downloads
• Sharing changes
• Administrator actions
• Data deletion
• Security setting changes

Cloud backups may also contain CUI. Include them within the security boundary.

Connected laptops, identity systems, and monitoring tools may enter scope too.

A secure cloud cannot protect CUI downloaded onto an unmanaged device.

Plan for Cyber Incidents

DoD contractors covered by DFARS 252.204-7012 must rapidly report qualifying incidents. The clause defines rapid reporting as within 72 hours.

It also requires affected system images and relevant monitoring data to remain protected for at least 90 days after reporting.

The incident plan should define:

• Who detects the incident
• Who reports it
• How evidence remains protected
• How providers support investigations
• Who communicates with the agency
• How affected services recover

Test these duties before a real incident occurs.

NIST SP 800-171 Revision 2 vs. Revision 3

NIST published SP 800-171 Revision 3 on May 14, 2024. It is the current final NIST publication for protecting CUI in non-federal systems.

NIST also published SP 800-171A Revision 3 for assessments.

However, publication status does not automatically change every contract.

Question	Revision 2	Revision 3
NIST status	Superseded publication	Current final publication
Structure	Earlier requirement structure	Updated and reorganized controls
Assessment guide	SP 800-171A Revision 2	SP 800-171A Revision 3
CMMC Level 2 use	Current CMMC model uses 110 Rev. 2 requirements	Not automatically substituted into CMMC
Required action	Follow when named by contract or program	Follow when adopted by the governing requirement

Current CMMC Level 2 requirements remain based on NIST SP 800-171 Revision 2.

An organization preparing for CMMC should not replace Revision 2 with Revision 3 without official direction.

However, teams should still study Revision 3.

Early preparation may help them:

• Compare existing controls
• Find future gaps
• Update policies
• Improve evidence
• Review system boundaries
• Track contract changes

Do not select a revision based only on publication date.

Use the revision named within the contract, regulation, solicitation, or assessment program.

Documents Needed for CUI Compliance

Working controls matter. Documentation proves how those controls work.

The exact records depend on the contract and assessment type.

Most CUI environments need the following document groups.

System Security Plan

The System Security Plan, or SSP, describes the CUI environment.

It should explain:

• The security boundary
• CUI data flows
• Applicable requirements
• Implemented controls
• Connected providers
• Security responsibilities
• Current gaps
• Planned improvements

The SSP should match the real environment.

Update it after major changes involving systems, providers, or contracts.

Asset Inventory

The inventory should list systems that handle or protect CUI.

Useful fields include:

• Asset name
• Asset type
• Owner
• Location
• Operating system
• Business purpose
• CUI role
• Scope category
• Support status

Update records when teams add or retire assets.

Network and Data-Flow Diagrams

A network diagram shows technical connections.

A data-flow diagram shows how CUI moves.

These diagrams should identify:

• Endpoints
• Servers
• Firewalls
• Cloud services
• Remote connections
• Security tools
• Backup systems
• External providers
• Entry and exit points

Keep diagrams accurate and easy to understand.

Policies and Procedures

Policies define required behavior.

Procedures explain how employees complete each task.

Important topics may include:

• Access control
• Account management
• CUI handling
• Remote access
• Removable media
• Monitoring
• Incident response
• Patching
• Change control
• Physical protection
• Training

Avoid generic templates that do not match daily work.

Assessment Evidence

Assessors need proof that controls operate.

Control Area	Useful Evidence
Access control	Account lists and approval records
MFA	Authentication settings
Patching	Scan and remediation reports
Logging	Alerts and review records
Backups	Restoration test results
Network security	Firewall rules and diagrams
Encryption	Device or service configuration
Change control	Approved change records

Store evidence in an organized and protected location.

Risk, Incident, and Remediation Records

Maintain records for:

• Risk assessments
• Vulnerability scans
• Corrective actions
• Incident response
• Recovery tests
• Approved POA&Ms

A POA&M tracks unresolved gaps. It does not automatically prove compliance.

Some CMMC requirements cannot remain open on a POA&M. Follow the applicable assessment rules.

Supporting records may also include:

• Training completion
• Access approvals
• Provider agreements
• Customer responsibility matrices
• Change records
• Policy reviews

Good documents cannot replace working security.

However, weak records make effective security difficult to prove.

Final CUI System and Network Checklist

Use this checklist before handling CUI:

1. Identify the correct CUI category.
2. Confirm the governing contract requirements.
3. Identify the required NIST revision.
4. Check CMMC and DFARS duties.
5. Define the complete CUI boundary.
6. Inventory every in-scope asset.
7. Restrict access to approved users.
8. Apply MFA where required.
9. Use secure system baselines.
10. Segment and monitor the network.
11. Protect CUI during storage and transmission.
12. Verify cloud and provider requirements.
13. Maintain an accurate SSP and diagrams.
14. Collect evidence for each control.
15. Test incident response and recovery.

This checklist supports internal review. It does not replace a formal assessment, contract review, or qualified compliance advice.

Conclusion

So, what level of system and network configuration is required for CUI?

CUI Basic requires no less than a Moderate Confidentiality Impact Level.

Federal systems generally use FIPS 199, FIPS 200, and NIST SP 800-53. Non-federal systems generally use NIST SP 800-171 when required through a contract or agreement.

DoD contractors may also face CMMC and DFARS requirements.

The correct controls depend on the contract, CUI category, and system environment.

Before handling CUI, confirm the governing requirements. Then define the security boundary and identify every in-scope asset.

A focused and well-documented environment can reduce risk. It can also support assessments and government contract readiness.