NIST SP 800-171A Rev. 3 (assessing CUI security requirements), explained

NIST SP 800-171A Revision 3, "Assessing Security Requirements for Controlled Unclassified Information," is the companion assessment-procedures document to SP 800-171 that tells an assessor how to determine whether the security requirements a nonfederal organization implemented to protect Controlled Unclassified Information (CUI) are actually satisfied. Per its own abstract, the publication "provides organizations with assessment procedures and a methodology that can be used to conduct assessments of the security requirements in NIST Special Publication 800-171," with procedures that "are flexible and can be customized to the needs of organizations and assessors," supporting independent third-party assessments as well as government-sponsored ones. Authored by Ron Ross and Victoria Pillitteri, Revision 3 was published in May 2024, superseding the original edition of June 2018.

Built on SP 800-53A's methodology

Section 2.2 is explicit that the assessment procedures in this publication's Section 3 "have been derived from the assessment procedures in SP 800-53A" — each of the 17 SP 800-171 requirement families is assessed using methods and object categories lifted directly from SP 800-53A's model, and each procedure's References line names the specific SP 800-53A control(s) it traces back to (for example, the account-management procedure in the publication cites AC-02, AC-02(03), AC-02(05), AC-02(13)). Appendix C confirms the same lineage for the overall assessment process: the four-phase approach "is based on the methodology in SP 800-53A." Where SP 800-53A assesses the federal SP 800-53 control catalog, SP 800-171A narrows that same machinery to the 17-family, CUI-specific requirement set in SP 800-171.

Examine, interview, test — and what gets assessed

Section 2.1 defines the three assessment methods:

• Examine — "the process of reviewing, studying, inspecting, or analyzing assessment objects."
• Interview — "the process of holding discussions with individuals or groups about assessment objects."
• Test — "the process of exercising assessment objects (i.e., activities, mechanisms) under specified conditions to compare actual with expected behavior."

Assessment objects fall into four categories: specifications (documented artifacts — plans, policies, procedures, requirements, design documentation), mechanisms (the hardware, software and firmware safeguards implemented in a system), activities (protection-related actions involving people, such as conducting a system backup or exercising an incident response plan), and individuals (the people applying those specifications, mechanisms or activities). Each assessment method carries depth and coverage attributes that set "the rigor, scope, and level of effort for the assessment as well as the degree of assurance that the security requirements have been satisfied" — for the full basic/focused/comprehensive definitions of those attributes, the publication points readers to SP 800-53A, Appendix C, rather than redefining them.

Determination statements, ODPs and the numbering scheme

An assessment procedure's objective is expressed as one or more determination statements — alphanumeric identifiers that always begin with "A" to mark them as part of an assessment procedure, followed by the SP 800-171 requirement identifier being assessed. The publication's own worked example, 03.01.06 Least Privilege – Privileged Accounts, shows determination statement A.03.01.06.a asking whether "privileged accounts on the system are restricted to <A.03.01.06.ODP[01]: personnel or roles>."

Two notation details matter for reading the catalog correctly:

• Organization-defined parameters (ODPs) are values — a time period, a frequency, a list of roles — that the implementing organization must fill in before a requirement is complete; these appear as ODP[nn] in square brackets. Rev. 3's change log (Appendix E) lists ODPs as a new addition versus the 2018 original, which had no such mechanism.
• Square-bracketed sequence numbers (e.g., A.03.01.01.f[01] through [05]) mark where a procedure has decomposed one SP 800-171 requirement into several more granular, individually assessable determination statements.

The four-step assessment process

Appendix C lays out the process in four phases, each summarized in its own table (Tables 2–5):

1. Preparing for assessments — establishing the objective and scope, notifying organizational officials, selecting assessors (considering assessor independence), and providing artifacts (policies, procedures, system documentation, prior assessment results) to the assessment team.
2. Developing assessment plans — selecting and tailoring the specific assessment methods and objects from the Section 3 catalog needed to obtain sufficient evidence for the organization's required assurance level.
3. Conducting assessments — executing the plan and gathering evidence through examine/interview/test activities.
4. Analyzing, documenting and reporting assessment results — compiling findings into a report that supports the organization's compliance determination and risk response decisions.

The publication frames the resulting evidence as part of an assurance case — "a body of evidence organized into an argument demonstrating" compliance with SP 800-171's security requirements — and notes this evidence can come from multiple sources, including prior independent third-party product assessments, not solely from a single system-level assessment event.

Findings: satisfied vs. other than satisfied

Applying an assessment procedure produces a finding of either:

• Satisfied — the assessment objective was fully met, a fully acceptable result; or
• Other than satisfied — either a potential anomaly that the organization needs to address, or a case where the assessor could not obtain sufficient information to make the determination called for.

The publication is explicit that the broad list of potential assessment methods and objects for a given procedure "does not necessarily reflect and should not be directly associated with actual compliance or noncompliance" on its own — organizations select whichever specific methods and objects are sufficient to obtain the evidence they need, rather than treating the full list as mandatory artifacts.

SP 800-171's 17 families, assessed

Table 1 organizes the assessment procedures into the same 17 requirement families as SP 800-171 Rev. 3 itself: Access Control, Awareness and Training, Audit and Accountability, Configuration Management, Identification and Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Planning, Risk Assessment, Security Assessment and Monitoring, System and Communications Protection, System and Information Integrity, System and Services Acquisition, and Supply Chain Risk Management — see our SP 800-171 / CMMC 2.0 guide for the underlying 130-requirement catalog these procedures assess.

A workable starting point

1. Read the References line on every procedure before tailoring it. It names the exact SP 800-53A source control(s), which is the fastest way to find deeper assessment-method guidance SP 800-171A itself doesn't repeat.
2. Resolve every ODP before building the assessment plan. A determination statement with an unresolved ODP (an undefined time period, an unspecified role list) can't be meaningfully examined, interviewed against, or tested.
3. Don't treat the full assessment-object list as a checklist. The publication explicitly disclaims that the complete set of potential objects for a procedure represents a required evidence list — select what's sufficient for the assurance level needed.
4. Separate "satisfied" from "no evidence yet." An "other than satisfied" finding can mean either a genuine gap or simply that the assessor couldn't get the evidence — the four-step process keeps that distinction visible through to the final report.
5. Remember this assesses SP 800-171 Rev. 3, not the CMMC-referenced Rev. 2 baseline. If the assessment is for a CMMC Level 2 determination, confirm which NIST SP 800-171 revision the contract actually requires before applying these Rev. 3-aligned procedures — see our SP 800-171 / CMMC 2.0 guide for that distinction.

SoftWSP's firmware and device security assessments produce the kind of examine/test-based evidence — control-by-control, traceable to a determination statement — that a CUI-handling system or component under SP 800-171A-style assessment needs: see Device & Firmware Security.

This guide summarises NIST SP 800-171A Revision 3 (May 2024) and the related SP 800-171/SP 800-53A publication pages; it is not a substitute for the full text and does not constitute compliance or legal advice.