What an Assessor Is Actually Prompted to Ask For

Quick answer: the assessment objectives are binding, the document lists are not. NIST SP 800-171A frames every requirement as a set of determination statements. The artifact lists underneath them are a menu an assessor selects from. Knowing which is which changes how you should organise your Mac evidence.

What is actually normative in an assessment?

The objectives. The CMMC Assessment Guide Level 2 states that assessment objectives are based on NIST SP 800-171A and that "the criteria are authoritative and provide a basis for the assessment of a requirement."

Each objective is printed as a determination statement under the heading "Determine if:". NIST SP 800-171A puts it plainly: "each assessment objective includes a determination statement related to the CUI security requirement that is the subject of the assessment."

The scoring consequence is unforgiving. One NOT MET objective fails the entire requirement. There is no partial pass at the objective level, and an objective assessed as not applicable is treated the same as met.

Are the Examine lists a required document checklist?

No, and NIST says so directly. The section is headed "POTENTIAL ASSESSMENT METHODS AND OBJECTS," and every entry is written as "Examine: [SELECT FROM: ...]".

The explicit disclaimer lives in 800-171A rather than in the CMMC guide, which is worth knowing if you ever need to cite it. Its cautionary note states that "the entire list of potential assessment objects should not be viewed as required artifacts needed to determine compliance to the requirements." Organisations have flexibility to determine which methods and objects are sufficient.

The CMMC Assessment Guide carries the same flexibility paragraph with assessors substituted in: certified assessors "are not expected to employ all assessment methods and objects contained within the assessment procedures."

So nobody is required to hand over a specific named document. If somebody tells you the guide mandates a policy per family, they are reading a menu as a checklist.

Why do the lists still shape good documentation?

Because they show you what an assessor is prompted with first, and prompts drive behaviour even when they are optional.

Look at how the entries open. For AC.L2-3.1.1 the list begins "Access control policy; procedures addressing account management." For AC.L2-3.1.2 it begins "Access control policy; procedures addressing access enforcement."

One honest caveat, because this gets overstated in marketing. We verified this pattern on three of the 110 requirements, and one of those three breaks the second half of it. AC.L2-3.1.3 opens "Access control policy; information flow control policies" rather than naming procedures. The family-policy anchor is reliable. The "procedures addressing" phrasing is not universal.

The defensible conclusion is narrow and still useful. Organising documentation so that a family-named policy exists and is easy to produce matches the first thing an assessor is prompted to look for. That is a risk-management argument, not a compliance requirement, and it should be sold as one.

What makes evidence unacceptable?

Being unfinished. 32 CFR 170.24 defines a requirement as MET when "all applicable objectives for the security requirement are satisfied based on evidence," and adds that "all evidence must be in final form and not draft."

It goes further and names what does not count. "Unacceptable forms of evidence include but are not limited to working papers, drafts, and unofficial or unapproved policies."

That single sentence is why a signed four-document set beats an unapproved thirty-document set. Volume is not the variable. Approval status is. Anyone shipping you a large template library without an approval workflow has handed you thirty things to sign, not thirty things you can use.

How much discretion does an assessor have?

Considerable, and the guide says so: "assessors exercise judgment in determining when sufficient and adequate evidence has been presented to make an assessment finding."

The same section notes that different objectives can be met in different ways, through documentation, system configuration, network configuration or training, so a variety of techniques may be used.

For a Mac fleet that cuts both ways. A configuration profile is legitimate evidence and you should lead with it where it fits. But discretion means variation between assessors is real, and the way to survive variation is to make the first thing they ask for easy to produce. For what that looks like in narrative form, see the Mac-based SSP narrative, and for the tooling boundary see what mSCP gives you and what it does not.

Sources

• NIST SP 800-171A, section 2.1 and the Chapter Three cautionary note
• CMMC Assessment Guide Level 2, v2.13, assessment criteria and methodology
• 32 CFR 170.24(b)

Verified against primary sources on August 1, 2026. The Examine-list pattern was checked on 3 of 110 requirements and is reported with that limit stated. This is not legal advice.