September 28, 2026

How to Organize 800-171 Evidence So an Assessor Can Follow It

An assessor grades your proof, not just your security. Messy evidence slows the review and invites doubt. Follow these steps in order to build a library an assessor can trace.

Step 1: List every requirement

Use the 110 requirements of NIST SP 800-171 Revision 2 (32 CFR Part 170). These form the basis for CMMC Level 2. Build a simple index with one row per requirement: number, short name, and the files that prove it.

Empty rows are your to-do list. Fill them before the assessor arrives, not during the visit.

What does a good index row look like?

One row might list requirement 3.1.2 with the short name "access enforcement". It points to two files: the access policy PDF and the August audit log CSV.

Each file name starts with 3.1.2 and ends with a date. The row tells the assessor exactly where to look.

Step 2: Build one folder per family

The 14 families make natural top-level folders. Name each with its number and plain title, for example "3.3 Audit and Accountability". Numbers keep the order stable.

Inside each family folder, add one subfolder per requirement, for example "3.3.2". Every practice gets its own home. Keep the structure two levels deep so no file hides.

Step 3: Name files so they explain themselves

Start each file name with the requirement number. Add a short plain description. End with the date.

Good: 3.3.2_audit-log-sample_2026-09-15.csv. Bad: doc1_final.pdf. The assessor should understand the file before opening it.

Avoid vague words like "final" or "updated". Dates are clearer than version words.

Step 4: Map each item to Examine, Interview, or Test

This is the step most teams skip. NIST SP 800-171A lists potential assessment methods and objects for every requirement (assessment procedures). Use that list as your packing checklist.

For each requirement folder, include:

Examine items: the policy, the plan, the settings export, the logs.
Interview items: the name and role of the person who owns the control.
Test items: the record of your own live check, with the date.

For example, requirement 3.1.2 (access enforcement) may call for examining the access control policy and audit logs. It may also call for interviewing administrators and testing the enforcement mechanisms (SP 800-171A). Your folder should hold one item for each method.

When one file supports several requirements, list it in each relevant index row. Do not copy the file into five folders.

How do you file Interview and Test evidence?

Interview evidence is a name, a role, and a topic. Record who owns each control and what the assessor should ask them. Keep it to one line per requirement in the index.

Test evidence is a dated record of your own check. Note what you tested, what you expected, and what happened. If you fixed something, record the fix and the retest date.

These two methods are where teams fall short. Documents are easy to file; people and live tests take planning. Start them early.

Step 5: Keep evidence fresh

Old evidence raises questions. Pick a rhythm and stick to it: for example, review access lists each quarter and export logs each month.

Record the collection date in the file name or the index. Fresh dates show the assessor that security is a habit, not a last-week scramble. PolicyCortex re-checks Azure controls after fixes, so the folders reflect the latest state without manual exports.

Step 6: Avoid the common mistakes

The biggest mistake is a pile of files with no index. If the assessor cannot trace a file to a requirement, it does not count.

The second mistake is evidence that proves nothing. A policy no one follows is weak proof. Pair every policy with proof that you follow it.

The third mistake is waiting until the week before. Rushed evidence looks rushed. Steady collection across the year is calmer and stronger.

Sources

Next step

A clean evidence library makes assessment week routine instead of stressful. See how PolicyCortex keeps your Azure evidence fresh without the manual work.