NIST SP 800-171A is the assessor's procedural document for evaluating NIST 800-171 compliance. It is the source for the three methods and for the specific assessment objectives the assessor evaluates for each practice.
The three methods
| Method | NIST 800-171A definition (paraphrased) | What it produces |
|---|---|---|
| Examine | The process of reviewing, inspecting, observing, studying, or analyzing one or more assessment objects (specifications, mechanisms, or activities). | A documentary determination that the control exists, is configured correctly, and has produced expected outputs. |
| Interview | The process of holding discussions with individuals or groups within an organization to facilitate understanding, achieve clarification, or obtain evidence. | A behavioral determination that the people responsible for the control know how it works and how to operate it. |
| Test | The process of exercising one or more assessment objects (activities or mechanisms) under specified conditions to compare actual with expected behavior. | An operational determination that the control actually works when exercised. |
How methods combine per practice
For each practice, NIST 800-171A lists assessment objectives (sub-items the assessor must determine) and a 'Potential Assessment Methods and Objects' section specifying which combination of Examine, Interview, and Test the assessor may use. The combination varies by practice and by assessment objective; the authoritative mapping is in NIST 800-171A itself. Below are illustrative examples of how multiple methods often combine on common practices, not the canonical mapping for these specific practices, which always lives in NIST 800-171A:
- An access-control practice may pair an Examine of account lists with an Interview of administrators and a Test that attempts access with deactivated credentials.
- An MFA practice typically pairs an Examine of conditional access configuration with a Test demonstrating an MFA challenge live.
- A risk-assessment practice typically pairs an Examine of the risk assessment report with an Interview of the risk assessment team.
- A malicious-code-update practice typically pairs an Examine of EDR configuration and update logs with a Test confirming that updates have applied.
Assessor discretion: the “adequate and sufficient” bar
NIST SP 800-171A's “Potential Assessment Methods and Objects” lists are, by their own naming, potential. The assessor exercises discretion within those potential methods to determine what is needed to reach a defensible determination of MET. Two governing concepts:
- Adequate evidence. The evidence supports the specific assessment objective being evaluated. Evidence that is tangentially related, or that supports a different objective than the one being assessed, does not count.
- Sufficient evidence. There is enough evidence to support the determination. A single screenshot of one user’s MFA enrollment does not show that MFA is enforced for all privileged accounts; the assessor needs broader evidence.
In practice, the assessor will:
- Apply more than one method when one alone is not defensible. If a screenshot shows the configuration is set, the assessor may still Test by exercising the control live and Interview the operator to confirm they understand and follow the procedure.
- Ask for additional evidence beyond what was initially presented if the first artifact raises questions or does not fully cover the assessment objective.
- Probe deeper when initial evidence and operating reality diverge. For example, when the documented procedure differs from what the system actually does, or when an interview subject answers in a way that does not match the documentation.
- Use sampling on practices where universe-level evidence is not practical, such as account reviews, training records, log reviews. The assessor selects the sample; you do not.
- Reach an objective determination. Not a checklist pass or fail, but a judgment that the assessment objective is MET based on the totality of evidence reviewed.
What this means for the OSA:
- Do not assume the minimum evidence will be enough. Be ready to produce additional artifacts and live demonstrations when asked.
- Have the operating staff available to interview, even when the practice “looks complete on paper.”
- Maintain access to the full record (complete account list, complete training roster, complete audit log) so sampling questions can be answered without delay.
- Treat assessor questions as part of the assessment process, not interruptions to it. Follow-up questions are how the assessor builds the adequate-and-sufficient case for MET.
What you produce for each method
- For Examine. Current documents and records: SSP entries, policy and procedure references, audit log excerpts with reviewer signatures, configuration screenshots showing setting name and value, system-identifying header visible.
- For Interview. The right people, briefed on the practices that map to their role, available during the assessment week. Per the APREP master guide: the CISO, IT administrator, an end user, HR, and facilities, each able to answer for their domain.
- For Test. The live system, accessible and operational during the assessment. Demonstrations from a live system are stronger than screenshots and the assessor will often request them.
Common failures
- Unable to give a live demonstration. If NIST 800-171A specifies Test for an objective, you need to demonstrate the control on the live system. Not being able to log in, missing credentials, the demo account disabled, or "the person who knows how to do that is not here" all result in NOT MET when a Test is required. Walk through every Test-method objective during pre-assessment prep and confirm someone is available to actually exercise the control during the assessment.
- Briefing the wrong interview subject. If the practice maps to a specific role, the person who shows up for the interview should be the actual operator, not a manager who paraphrases.
- Not documenting assessment objectives that ask for a definition or identification. Many objectives require the OSA to define or identify something specific (authorized users, types of mobile devices, sanitization methods, the events to be logged, and so on). Each of those definitions and identifications has to appear in the documentation at the assessment-objective level. Documentation that only supports Examine of the practice is not sufficient when the objective is asking the OSA to identify or define. A general SSP description of the practice does not stand in for the specific objective-level content the assessor is reading 800-171A for.