Secani
Secani
  • Partners
Sign inTake the tour

Summarize with AI

Open in ChatGPTOpen in ClaudeOpen in PerplexityOpen in MistralOpen in Grok
SIBB Startups
Berlin
Co-funded by the European Union
for Startupsby
Secani

Jonathan Bezdek

Wörther Straße 9

10435 Berlin


hello@secani.com

Product

  • Secani Agent
  • Roadmap
  • Documentation
  • OSCAL
  • NIS2 applicability check
  • NIS2 implementation check
  • Frameworks

Legal

  • Privacy Policy
  • Terms
  • Cookie settings
  • Legal Notice
  • humans.txt
  • lawyers.txt
  • security.txt

Company

  • Company
  • Contact
  • Blog
  • Brand

Support

  • Help
  1. Home›
  2. Frameworks›
  3. NIST 800-171

NIST 800-171.

CUI protection in nonfederal systems: distinguish requirements, contractual revision and assessment clearly.

  • NIST SP 800-171 Rev. 3 · NIST SP 800-171A Rev. 3
  • ·By Jonathan Bezdek
  • ·As of: 10/22/2026
  • ·Reading time: 8 min.

Short answer.

NIST 800-171 describes security requirements for protecting Controlled Unclassified Information, or CUI, in systems outside the US federal government. Agencies use the publication in contracts and agreements. Revision 3 has been published since May 2024; the agreed version, confirmed data scope and required assessment remain decisive for an engagement.

Understanding NIST SP 800-171 Revision 3.

NIST SP 800-171 is a US publication for protecting certain government-regulated information in nonfederal environments. Revision 3, section 1.1, describes its connection to contracts and agreements. This creates no general duty for every German company or universal NIST certificate. The starting point is a specific relationship with a US federal agency or corresponding prime contractor.

CUI stands for Controlled Unclassified Information and, according to the responsible US authority NARA, means information subject to safeguarding or dissemination conditions regulated by law or government-wide policy. CUI is neither a classified information designation nor a catch-all for internally confidential company data. The information type concerned and its basis must be clarified; a self-assigned label does not replace this clarification.

The current publication version and agreed assessment engagement are different details. NIST's publication page lists Revision 3 of May 2024 as the successor to Revision 2. Publication does not, however, automatically move an existing contract onto a different basis. The responsible authority should confirm which revision, supplementary requirements and assessment procedures are actually agreed.

Who CUI protection is relevant to.

Within the described scope, NIST 800-171 concerns systems processing, storing or transmitting CUI and components protecting those systems. Section 1.1 therefore requires robust system boundaries. A company label, European location or broad industry classification does not answer the scope question. Equally, a single data room should not be treated as the full scope without examining its connections.

Practical preparation connects the engagement, information flow and responsibilities. Record which information comes from whom, where it is used and which internal or external services are involved. Unresolved classifications belong with the responsible agency contact or prime contractor. The current NIST CUI FAQ explicitly directs such compliance questions to them; NIST does not decide whether an individual contract has been fulfilled.

Small organisations also need a specific agreement rather than an assumed size exemption. NIST's Revision 3 FAQ describes application by the responsible agency. The Small Business Primer SP 1318 helps smaller companies get started but replaces neither the standard nor examination of actual service scope. A manageable organisation can keep processes simple but must address agreed requirements traceably.

NIST 800-171 requirements at a glance.

The following six work areas group the CUI protection task editorially; they are not a new division of NIST families. Revision 3 and the Small Business Primer SP 1318 connect organisational decisions with technical controls. Individual requirements are not reproduced here.

  • Clarify scope and responsibility.

    Protection starts with confirmed information and a described system boundary. Planning, responsibilities and relationships with supporting services belong together. Alongside technical ownership, name the person who clarifies contractual questions and changes with the customer; this keeps implementation focused on the correct subject.

  • Connect people, identities and access.

    Authorised people need appropriate access and an understanding of their tasks. Revision 3's family overview includes access control, identification, awareness and personnel security. Operational implementation should consider joining, task changes, privileged activity and leaving together, rather than treating a technical login mechanism alone as a complete solution.

  • Operate systems under control.

    Configuration, maintenance and integrity support traceable operation of the defined environment. The general implementation perspective in Primer SP 1318 helps connect these topics with specific owners. Changes should be considered in terms of their impacts on CUI and existing evidence; a one-time stocktake does not keep scope current permanently.

  • Protect data and its environment.

    CUI protection encompasses more than data on a server. Communications, media, the physical environment and protective components involved must be considered in the context of their respective families. The practical question is where information actually becomes accessible and which transitions between people, systems and providers must be secured and documented.

  • Organise incidents, risks and assessment.

    Safeguards need feedback from monitoring, risk assessment and incident handling. Current NIST publications distinguish a requirement from its assessment: a documented implementation statement is a starting point, not yet an assessment result. Define who evaluates identified problems, tracks measures and feeds changed information back into the system description.

  • Define procurement and parameters traceably.

    External services and organisation-defined parameters belong in confirmed implementation. The Revision 3 FAQ explains that agencies may prescribe parameter values, provide selection aids or permit their determination. Values not prescribed must be completed; invented or indiscriminately copied values without examining responsibility do not create a robust requirements basis.

Organise CUI protection as an ongoing task.

  1. Confirm the engagement.

    Record the authoritative contract or agreement, responsible authority, required evidence and people able to resolve open interpretation questions with binding effect.

  2. Define the information flow.

    Describe confirmed CUI, participating people and systems, and connections to protective components and external services in a verifiable system representation.

  3. Record the revision and parameters.

    Confirm the applicable edition and origin and ownership of parameter values before translating requirements into operational tasks.

  4. Operate implementation with clear ownership.

    Assign specific processes, technical settings and owners to agreed requirements, and keep scope changes traceable.

  5. Examine evidence selectively.

    Plan suitable examinations, interviews and tests for the confirmed engagement, and document results, limitations and outstanding measures.

  6. Track changes.

    Assess new services, data flows and contract changes with the owners, and update the system description, controls and assessment documents accordingly.

Understand assessment and evidence separately.

NIST SP 800-171A provides security requirement assessment procedures. Section 1.1 names the System Security Plan, or SSP, as the assessment scope basis; section 2.1 distinguishes examination, interview and testing. An assessment plan should define which statements are examined with which evidence. Not every example document listed is automatically required for every engagement.

Assessment should support a traceable statement about actual implementation within agreed scope. Assessment Primer SP 1352 of September 2026 provides an additional introduction. A percentage alone, without a revision, system boundary and substantiated results, is of little help in this context. The applicable framework must clarify what form the customer accepts and when reassessment is needed.

CMMC is a separate programme, rather than another name for NIST 800-171. NIST's CUI FAQ describes its connection to NIST requirements and assessment methods while distinguishing NIST from CMMC certification. A required programme status or DoD assessment therefore does not arise simply from working through a Revision 3 catalogue. No general validity period for all evidence follows from this either.

Read more on the blog.

  • CMMC Phase II: a time-specific status articleThe July 2026 publication explains the programme status and contractual questions at that time; current requirements need separate confirmation.

Understanding other frameworks.

NIST SP 800-53 is the broader security and privacy control catalogue, while NIST SP 800-171 is tailored to the described CUI context. NIST CSF supports shared understanding of desired cybersecurity outcomes. ISO 27001 organises an information security management system; its certificate does not replace separately required CUI or contractual evidence.

  • NIST SP 800-53Understand the broader control catalogue and contextual selection.
  • NIST CSFDescribe cyber risks and desired outcomes together.
  • ISO 27001Understand management system and certification scope separately.

In Secani.

Secani provides an editorial work catalogue for NIST SP 800-171 Revision 3. Profile fields distinguish confirmed CUI scope, contract revision, agency or contractual requirement, parameter responsibility and external providers. This allows the underlying classification to be recorded alongside the work. The catalogue is a working aid with professional review pending; it issues neither CMMC status, a DoD score nor an official compliance decision.

Next step.

Start with a specific engagement and confirmed information flow. Record which CUI is affected, which systems touch it and who can confirm the applicable contractual revision. Only then can you meaningfully decide what work and evidence are needed next. The described sequence is practical guidance, rather than an additional government-prescribed order.

Request a demo

Sources.

  • NIST SP 800-171 Rev. 3: publication and scope
  • NIST SP 800-171 Rev. 3: sections 1 and 2 and family overview
  • NARA: Controlled Unclassified Information
  • NIST: FAQ on Revision 3 and organisation-defined parameters
  • NIST SP 1318: Small Business Primer
  • NIST SP 800-171A Rev. 3: sections 1.1 and 2.1
  • NIST SP 1352: Assessment Small Business Primer
  • NIST: CUI FAQ on contractual questions and CMMC

Frequently asked questions.

No. CUI is an information category regulated by law or government policy; an internal confidentiality label alone is insufficient. Clarify the information concerned and its basis with the responsible authority.

No. The current NIST publication and contractually required version must be confirmed separately. The specific agreed framework is decisive for implementation and assessment.

No. Security requirements, assessment procedures and CMMC programme status have different functions. According to its own FAQ, NIST is not responsible for CMMC certification.

No. The specific agreement, relevant information and affected system scope are decisive. Company location alone establishes neither an obligation nor an exception.

CUI protection with a clear scope.

Use Secani to organise work status, responsibility and the underlying contract revision.

Request a demo

This page provides general guidance. Applicable agency requirements, the agreed revision and the specific contract remain authoritative.