CUI compliance does not stop at the research enclave.
Universities handling Controlled Unclassified Information need to protect the systems where CUI is processed, stored, or transmitted. But governance extends further into policies, people, physical spaces, shared services, evidence, ownership, third parties, and the institutional processes that support the research. Understanding those relationships is what turns a secure environment into a defensible CUI program.
What is CUI in university research?
Controlled Unclassified Information, or CUI, is information that the U.S. Government creates or possesses (or that another entity creates or possesses for or on behalf of the Government) that requires safeguarding or dissemination controls under applicable law, regulation, or government-wide policy. It is not classified information. And not every piece of sensitive research data is CUI.
For universities, CUI can arise when the institution participates in federal research, contracting, engineering, technology development, or other activities involving information designated for controlled handling. The federal CUI Registry includes categories directly relevant to research environments, including Controlled Technical Information and Export Controlled Research. Whether information is actually CUI depends on the governing authority and the circumstances under which the university receives or creates it.
The first question, then, is whether this project receives, creates, processes, stores, or transmits information that is actually CUI and what requirements govern it?
SOURCE: National Archives — CUI Registry.
When does NIST SP 800-171 apply to a university?
NIST SP 800-171 provides security requirements for protecting the confidentiality of CUI in nonfederal systems and organizations. The requirements apply to components of nonfederal systems that process, store, or transmit CUI or provide security protection for those components.
That distinction matters. A university does not become subject to NIST SP 800-171 simply because it receives federal research funding. Applicability depends on the information involved and the contractual or other agreement requirements governing the work.
For an affected research project, the practical questions are:
What information is CUI? Determine what the federal sponsor or applicable authority has designated for controlled handling.
Where does it go? Identify the systems, applications, endpoints, storage locations, facilities, and other components that process, store, transmit, or protect the CUI.
Who touches it? Identify faculty, researchers, students, administrators, IT personnel, collaborators, subcontractors, and other authorized users.
What institutional services support it? Determine which centrally or locally managed services help meet the applicable requirements.
Who owns each requirement? Separate responsibilities performed centrally from those performed by the research program, school, lab, project, or external provider.
The boundary will change. Plan for that.
This is where CUI governance becomes particularly difficult in Higher Education. Research institutions are decentralized by design. Central IT may operate identity, networking, endpoint security, security operations, or other shared services. A research computing organization may manage the technical environment. A school or department may own local processes. A principal investigator may own the project. Research administration, export control, legal, HR, procurement, physical security, and information security may each own another part of the operating environment.
The result is not necessarily a lack of controls. The problem is understanding which controls apply to the research environment, which controls it inherits, who owns each one, and what proves that responsibility is being fulfilled.
That issue appeared directly in our work with university teams. In one research scenario, the institution needed to distinguish controls inherited from the broader university from controls it had to implement specifically for the research project. The same discussion extended to owners, evidence, vendors, physical spaces, collaborators, and audit obligations.
As Rob Groome, CTO of USC Viterbi School of Engineering, puts it: “Scope before building.” Define the actual environment first, then determine what the project can inherit and what it must implement itself.
Shared controls change the CUI compliance problem.
Consider identity management. A university may already have institutional controls for:
account provisioning and deprovisioning;
authentication;
privileged access;
access review;
personnel changes; and
identity lifecycle management.
A research project may depend on those institutional capabilities rather than recreating them inside the project. The same pattern can occur with security monitoring, incident response, policies, awareness and training, personnel security, physical security, configuration management, and other capabilities.
The key governance question becomes what this environment can inherit and what it must implement itself. That distinction affects the system boundary, responsibility assignments, assessment preparation, evidence collection, and remediation work.
Evidence has to follow the control.
Knowing that a central service performs a function is not enough during an assessment. The institution needs to be able to show what the control does, who owns it, where it applies, how it is implemented, and what evidence demonstrates that it is operating as expected. That evidence may exist in different places:
policies and procedures;
system configurations;
access records;
tickets;
training records;
technical reports;
logs;
screenshots;
approvals;
risk records; or
documentation maintained by another institutional team.
This is why evidence management becomes difficult in decentralized universities. The research team may depend on a control without owning the evidence for it. The governance model needs to preserve that relationship:
Control → Owner → Scope → Implementation → Evidence → Requirement.
Document as you build.
CUI programs become much harder to defend when you reconstruct documentation after the fact. When the boundary changes, an implementation changes, or responsibility moves between teams, the documentation should change with it.
Groome’s advice is simple: “Document as you build.” The goal is to maintain the connection between what the institution says it does, what it actually does, and the evidence that demonstrates it.
Treat the SSP as proof.
The System Security Plan should tell a consistent story about the environment: where the boundary is, how applicable requirements are implemented, who owns the responsibilities, and what documentation supports the program. As Groome describes it: “The SSP is proof.” That means the SSP, policies, standards, diagrams, ownership records, implementations, and evidence should not tell different versions of the same story.
Requirement → Control → SSP → Policy / Standard → Owner → Implementation → Evidence.
This is the red thread: the ability to trace a requirement through the institution’s documented governance and operating environment to the evidence demonstrating what is actually being done.
NIST SP 800-171 Rev. 3
NIST published Revision 3 of SP 800-171 in May 2024. It superseded Revision 2 as the current NIST publication and aligns the requirements more closely with the NIST SP 800-53 Rev. 5 control structure.
Revision 3 organizes its requirements across 17 families: Access Control; Awareness and Training; Audit and Accountability; Assessment, Authorization and Monitoring; Configuration Management; Identification and Authentication; Incident Response; Maintenance; Media Protection; Physical and Environmental Protection; Planning; Personnel Security; Risk Assessment; System and Services Acquisition; System and Communications Protection; System and Information Integrity; and Supply Chain Risk Management.
NIST SP 800-171A Rev. 3 provides corresponding assessment procedures for evaluating the requirements.
Does that mean every university should move to Revision 3 immediately?
No. NIST SP 800-171 Rev. 3 is the current NIST publication, but the requirement governing a particular university project comes from the applicable contract, agreement, regulation, or other authority.
For example, DFARS 252.204-7012 states that covered contractor information systems are subject to the NIST SP 800-171 version in effect when the solicitation is issued, unless the contracting officer authorizes otherwise.
Universities should therefore identify the specific version required for each applicable project rather than assuming that every existing contract automatically moved when NIST published a new revision.
Where does CMMC fit?
CMMC and NIST SP 800-171 are related, but they are not interchangeable. NIST SP 800-171 establishes security requirements for protecting CUI in applicable nonfederal systems.
CMMC is the Department of Defense framework for assessing contractor compliance with applicable information-security protections. Under the current DFARS CMMC clause, contractors must maintain the CMMC status required by the contract for information systems used to perform the contract that process, store, or transmit FCI or CUI. The clause also addresses annual affirmation and applicable flowdown requirements.
For universities, CMMC becomes relevant when the institution performs applicable DoD work, not simply because it conducts federally funded research.
One university. Different research environments.
A university may have many projects requiring different levels of protection. One project may use a dedicated CUI enclave. Another may inherit university-wide capabilities while maintaining project-specific controls. Another may involve external collaborators. Another may depend on a cloud environment. Another may involve physical laboratories, specialized equipment, graduate students, subcontractors, or vendors.
And most of the university may have no CUI involvement at all. Representing all of that as a single institution-wide compliance status hides the information governance teams actually need. The useful view is:
Applicability | Which projects and information are subject to the requirement? |
Scope | Which systems, people, facilities and services are involved? |
Controls | Which safeguards support the environment? |
Inheritance | Which controls come from shared institutional services? |
Ownership | Who is responsible for implementation and operation? |
Evidence | What demonstrates that the control is working? |
Gaps | What is missing or deficient in this specific environment? |
Risk | What does the deficiency expose the institution or project to? |
Change | What else is affected when a control, service, requirement, or environment changes? |
Stop rebuilding the same control around every project.
This is where a control-based approach changes the operating model. Instead of treating each research project or requirement as an independent compliance program, Cyturus lets the institution establish the controls it actually operates in a Living Control Set. You can then evaluate applicable requirements against that control environment.
If an institutional control already supports part of the requirement, you can preserve the relationship. If a research environment inherits the control, you can represent that relationship. If the project requires something different, the difference remains visible. The goal is to stop recreating work that actually is the same.
See the delta before creating another workstream.
When a new CUI project, contract, or requirement enters the university, the first question should be “What does this require that we do not already have?” With Cyturus, universities can compare applicable requirements against their existing control environment to identify:
Already supported: Controls the institution already operates that can support the new scope.
Inherited: Capabilities provided by central or other shared institutional services.
Project-specific: Controls or implementations that must remain unique to the research environment.
Missing or deficient: Requirements requiring remediation, additional evidence, ownership, or another action.
The result is a clearer view of the delta without losing the context that makes each project different.
A Living Control Set for the university
Cyturus uses the Living Control Set (LCS) as the control system of record for the institution’s actual control environment. Instead of organizing governance exclusively around individual frameworks, the LCS preserves the controls the organization operates and their relationships to:
requirements;
owners;
evidence;
organizational scopes;
risks and threats;
deficiencies;
remediation activities; and
governance history.
For Higher Education, that distinction matters. Central IT can operate a shared control without pretending it owns every research program. A research project can inherit that control without duplicating it. And the institution can still preserve the project-specific evidence and implementation context needed to demonstrate how the requirement is satisfied.
See Control-Based Governance for Higher Education >
From a CUI gap to institutional risk
A control deficiency can affect a research project, contractual obligation, information environment, or other institutional objective. The useful governance record should show those relationships rather than leaving the finding isolated in a compliance checklist.
Cyturus connects control deficiencies to the corresponding governance context so teams can understand: What is deficient → Where it applies → Who owns it → What it affects → What action is underway. This gives leadership, research administration, security, compliance, and project teams a common record while preserving their different responsibilities.
What should universities do first?
Before buying another tool, building another enclave, or creating another assessment spreadsheet, establish the governance model. Start with five questions:
Which projects actually involve CUI? Confirm applicability from the governing contract, agreement, federal sponsor, CUI designation, and relevant authority.
Where is that CUI processed, stored, transmitted, or protected? Define the actual environment rather than assuming the entire university is in scope.
Which existing university controls support that environment? Identify central and distributed services that may already perform applicable functions.
Who owns implementation and evidence? Separate institutional, shared-service, project, and third-party responsibilities.
What is the delta? Identify what must actually change for this project rather than rebuilding every requirement from zero.
That produces a much better starting point for NIST SP 800-171 implementation, assessment preparation, SSP development, and, where applicable, CMMC readiness. There is also an important discipline behind the assessment itself. As Groome puts it: “Don’t talk yourself into a good score.” The objective is not to make the environment look compliant. It is to understand accurately what is implemented, what can be demonstrated, and what still needs work.
By assessment time, the evidence should already be there.
By assessment time, teams should not have to search across repositories, tickets, emails, cloud platforms, and individual folders to reconstruct how a control is implemented. The control, its owner, implementation, evidence, findings, and remediation should already be connected.
“Cyturus enabled our global consulting practice to increase assessment accuracy while streamlining reporting by 90%. This dramatically reduced time spent on compliance tasks and allowed us to focus on delivering exceptional value to our clients.”
— Robert Teague, VP of Services, Redspin
Find out what your next research requirement actually changes.
Bring the requirements affecting the project and the controls your institution already operates. Cyturus can help you determine what is already supported, what you can inherit or reuse, and where the gaps remain.
Explore Higher Education & Research ›
Frequently Asked Questions
What is Controlled Unclassified Information (CUI)?
Controlled Unclassified Information is information the federal government creates or possesses, or that an entity creates or possesses for or on behalf of the government, that requires safeguarding or dissemination controls under applicable law, regulation, or government-wide policy. CUI is not classified information. The National Archives CUI Registry identifies approved CUI categories and the authorities governing them.
Does every university that receives federal research funding have CUI?
No. Federal funding alone does not mean all research information is CUI. CUI status depends on the information, its relationship to the federal government, the applicable authority, and the project's governing requirements. Universities should determine applicability at the project and information level rather than treating all federally sponsored research as CUI.
Does NIST SP 800-171 apply to universities?
It can. NIST SP 800-171 is designed to protect CUI in applicable nonfederal systems and organizations. A university may therefore be required to implement it when an applicable contract or agreement requires protection of CUI in university systems.
What is the current version of NIST SP 800-171?
NIST SP 800-171 Revision 3 is the current NIST publication. NIST published it in May 2024, superseding Revision 2. However, organizations should verify which revision the specific contract or agreement requires.
Is CMMC required for universities?
CMMC can apply to universities performing DoD contracts when the applicable contractual requirements require a CMMC status. It should not be treated as a general requirement for higher education or for all federally sponsored research.
Is a secure CUI enclave enough for NIST SP 800-171 compliance?
Not by itself. NIST SP 800-171 includes requirements spanning technical and nontechnical areas such as access control, personnel security, physical protection, incident response, training, risk assessment, planning, supply-chain risk management, and other functions. The institution needs to understand how those requirements are implemented across the environment and supporting services.
Can a research project inherit controls from central IT?
Potentially. A project may rely on institutional capabilities that support its environment. However, the university still needs to establish the applicable scope, implementation responsibility, and evidence showing how the requirement is satisfied. The exact treatment depends on the environment and governing requirements.
What is an SSP for NIST SP 800-171?
A System Security Plan documents the system boundary, operating environment, how applicable security requirements are implemented, and related information necessary to describe the system's security posture. For a university, developing an SSP often requires coordination across research, IT, security, compliance, and other institutional control owners.
What is the difference between CUI and sensitive university data?
Sensitive university information is not automatically CUI. CUI is a federal information designation grounded in applicable law, regulation, or government-wide policy and the federal CUI program. Universities may protect many other forms of sensitive information under institutional policy or other regulatory obligations without that information being CUI.
How should a university start preparing for NIST SP 800-171?
Start by determining applicability and scope: identify the projects involving CUI, understand where the information flows, identify the systems and services supporting it, determine control ownership and inheritance, gather existing evidence, and then identify the remaining gaps. That avoids treating NIST SP 800-171 as an isolated checklist detached from the university’s existing control environment.
Authoritative Sources
National Institute of Standards and Technology
NIST SP 800-171 Rev. 3 — Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations
NIST SP 800-171A Rev. 3 — Assessing Security Requirements for Controlled Unclassified Information
NIST Protecting CUI Project
National Archives and Records Administration
Controlled Unclassified Information Program
CUI Registry
CUI Policy and Guidance
Department of Defense / Acquisition.gov
DFARS 252.204-7012 — Safeguarding Covered Defense Information and Cyber Incident Reporting
DFARS 252.204-7021 — Contractor Compliance With CMMC Level Requirements
