Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Simplify NIST compliance: How to identify CUI and establish scope

Andrew Hosch VP, Software and Security, Base2 Solutions
Sign saying

The clock is ticking for anyone who holds US government data. That’s because compliance with the security directives surrounding controlled unclassified information (CUI), also known as NIST 800-171, must be reached by December 2017. But instead of working through reams of federal publications, you can take a simplified approach.

By asking four basic questions, any organization can quickly know how much effort will be needed to meet regulations. So avoid plowing through security jargon and acronym-laden alphabet soup and beat the clock.

1. Covered: Is the site covered by the CUI scope?

If the site holds a US federal contract or is a supplier on a US federal contract, then the site likely has CUI.

2. Consolidated: Is the CUI contained and isolated?

When the CUI is located in one application or one set of systems, applying controls is simplified. When the CUI is not consolidated, but instead is spread throughout systems and locations, applying controls can become expensive and burdensome. Though even here, applying controls widely may be less intrusive than trying to consolidate the CUI.

3. Controlled: Is the CUI actually controlled?

The CUI needs to be monitored, audited, and protected. Having the CUI in one set of systems does not guarantee control. Physical location, network, authentication, and infrastructure must all be evaluated to ensure that the CUI is accessed only by those authorized to use it.

4. Composed: Does the site have mature information technology practices?

Unrelated to CUI specifically, many of the security controls center on good IT practices. Are backups run? Are operating system patches applied? Is antivirus installed and functional? These practices cover a majority of the controls.

Working through these four steps will guide progress to getting the site into full and maintainable compliance.

Below, the details of each of the four steps is further explained, with guidance provided to getting through each. Sample high-level designs will explain how different sites may adopt a pattern that meets the federal requirements. Also, general and policy questions will be addressed. 

Step 1: Covered

Does the site have CUI? For some sites, this answer will be absolute. For others, research will be needed. This section happens to focus on aerospace manufacturing and is not meant to be comprehensive to all CUI. For example, federal grand jury data falls under CUI, but that is not generally data an aerospace manufacturing entity will hold.

A full list of what is CUI can be found here and is ever-changing.


We suggest getting started by looking at contracts. Does the site hold or plan to bid on any direct US government contracts? Does the site hold supplier status or plan to have supplier status through a larger entity, such as Boeing, Lockheed Martin, and SpaceX, that holds US government contracts? Answering yes to either means CUI compliance is very likely going to be needed. At a minimum, additional investigation is required.

So contracts exist. Which information needs to be protected?

Labeled information

Some types of information are simple to identify as CUI.

“Export control” includes any information that is subject to export control, such as International Traffic in Arms Regulations (ITAR) and the Export Administration Regulations (EAR)—this would be CUI. (ITAR covers items, commodities, technology, software, or other information whose export could reasonably be expected to adversely affect US national security. EAR generally covers “dual-use” items.)

“Labeled information” includes any nonclassified information that is labeled with legacy or agency-specific designations and is CUI. This pertains to labels such as Unclassified (U), For Official Use Only (U//FOUO), Official Use Only (OUO), Sensitive But Unclassified (SBU).

Some projects, which may not have specifically marked information, still could include CUI.

Defense projects

For defense projects, “covered defense information” can come in several forms. More than one Defense Federal Acquisition Regulation (DFAR) deals with CUI. Generally, for aerospace manufacturing, noncommercial technical details are CUI. This may be called out in the contract, task order, or delivery order.

Technical information includes research and engineering data, engineering drawings, and associated lists, specifications, standards, process sheets, manuals, technical reports, technical orders, catalog-item identifications, datasets, studies and analyses, and computer software executable code and source code.

Here are some specific DFARs that define the application of CUI:

  • 252.204-7012  Safeguarding Covered Defense Information and Cyber Incident Reporting
  • 252.227-7013 Rights in Technical Data—Noncommercial Items
  • 252.239-7010  Cloud Computing Services

These contract clauses denote that sensitive data must be handled appropriately.

CUI also applies to defense projects that include technical information with military or space application subject to controls on the access, use, reproduction, modification, performance, display, release, disclosure, or dissemination.

Non-defense projects

For non-defense federal projects, much depends on the specific contract. The definition is a bit open-ended in “52.204-21 Basic Safeguarding of Covered Contractor Information Systems,” which states:

Federal contract information means information, not intended for public release that is provided by or generated for the Government under a contract to develop or deliver a product or service to the Government, but not including information provided by the Government to the public.

To add some subtlety to the entire CUI program, agencies are required to “decontrol” designated CUI as soon as is practicable. However, the rules state that “decontrolling CUI relieves authorized holders from requirements to handle the information under the CUI Program, but does not constitute authorization for public release.” In other words, even when the data is decontrolled, it must still be protected.


Defining the scope of CUI coverage and deciding how to implement controls depends on the complexity and amount of the CUI needing to be contained. Here are some suggested approaches in increasing levels of conservatism.

By item
If a site has a limited amount of CUI, say only a half-dozen noncommercial items for a legacy project with little activity, bringing only those specific items into scope might make sense.

By project
If a site has a federal project, bringing the entire project into scope may be more expeditious than trying to continually decide if some content is CUI or not and then having to divide and protect some of the project and not the rest. Designating the project as all CUI is the approach taken by many institutions.

By location or zone
If a site has multiple types of CUI, or is primarily dealing with CUI and has multiple people working on multiple covered projects, bringing the entire site or a subset of that location (such as an entire floor or a cloud location or a separate zone) into scope may be better than trying to separate out different practices for each project.

In summary, if a site holds a federal contract or supplies a company on a federal project, the CUI information associated with that project most likely needs to be protected.

Step 2: Consolidated

How widespread is the CUI throughout the site? How difficult will it be to consolidate into an isolated enclave? Accurate answers to these questions will dictate how best to control CUI:

  • If the CUI is limited to a single system, can controls be applied to that system?
  • If the CUI is pervasive through the workflow of the site, do controls need to be applied at a wider level?

Having an inventory of CUI and CUI projects is key to completing this step accurately.

For example, a site might utilize a document management application, but can the document management system, associated file server, and database be isolated from other infrastructure on the network? If so, the CUI controls can be isolated.

Step 3: Controlled

Having CUI consolidated in a small set of systems does not mean the information is actually controlled. Four major technological domains are evaluated to determine whether the CUI is controlled adequately.

Physical controls: The CUI must be physically protected via locks, such as card key access. When at rest, the data and associated backups must be labeled and secured. Generally, an air gap of some kind is associated with physical control.

Network controls: The CUI must be protected at the network layer, including OSI layers two through four. Switches, routers, and firewalls must all work to prevent unauthorized access. For example, having a router isolate a network via VLAN is no good if the underlying switches are misconfigured or unprotected.

Session controls: The CUI must be protected via authentication and authorization mechanisms. Using authentication systems outside of the control of the data owner means unauthorized access to CUI could be granted at any time.

Infrastructure controls: the infrastructure that supports the CUI systems can take many forms, including virtual machines, physical servers, storage area networks, and backup systems. A CUI-holding system may have network and session controls effectively implemented. However, if the backups and underlying systems are outside of the control of the data owner, the CUI can be accessed via “back-door” methods.

In summary, all four areas—physical, network, session, and infrastructure—must be examined and brought under control.

Step 4: Composed

If the site has composed, mature IT practices, a majority of the controls will be met.

Encrypted backups need to be run. Risk assessments must be completed. Change management processes must be in place. Antivirus must be installed. Network scans must be run periodically. Training and policies need to be in place and practiced. Configuration changes to the systems controlling CUI access should have a documented review and approval process. Logs collected should be audited on a regular interval—ideally by a designated third party.

Sites with composed local IT support will have an easier time implementing the controls and maintaining them. Sites with little IT availability or junior IT support will need to contract periodic maintenance once controls are put in place.

The kind of IT support available will greatly dictate both how much a site needs to consolidate its CUI and where controls can be placed: at the system, project, or site level.

Scoping out compliance

By answering only these questions—establishing whether information is covered by NIST 800-171, identifying whether the CUI is consolidated, knowing whether the infrastructure is controlled, and determining whether the support IT and security teams are composed—any organization can quickly understand the scope and amount of effort that will be needed to reach compliance in the next six months.

This is Part 1 in our NIST compliance series. In the next article, we will discuss simple methods to implement compliance quickly.

Jenifer Rees, a principal quality engineering consultant for Base2 Solutions with CCSFP and CSSLP (ISC)², contributed to this post. She is a skilled QA engineer with a focus on pushing quality upstream into all phases of the software development lifecycle.

Image credit: Flickr

Keep learning

Read more articles about: SecurityInformation Security