NIST 800-171 Templates: Complete Rev 2 Document Set Guide

NIST 800-171 templates are easy to find and easy to get wrong, because the first
decision is not which documents you need — it is which revision they cite. Get that wrong and you
produce a polished document set that an assessor cannot accept.

Which revision your NIST 800-171 templates must cite

There are two live answers to that question at the same time, which is why the topic is so
confused.

At NIST, Revision 2 is gone. NIST’s own publication page records SP 800-171
Rev. 2 as withdrawn on 14 May 2024, superseded by SP 800-171 Rev. 3. If you are following the
standard on its own terms, Rev 3 is the current publication.

In the regulation, Revision 2 is the requirement. The CMMC Model rule at
32 CFR 170.14 states that the model incorporates the security requirements from
NIST SP 800-171 R2, incorporated by reference, and that the CMMC domains map to the
requirement families defined in R2. That is the current regulatory text.

So for a defence contractor, documentation written to Rev 2 is not out of date. It is the version
the obligation actually points at. Templates that have been “helpfully updated” to Rev 3 are the ones
that create a problem.

NIST 800-171 templates: Revision 2 and Revision 3 side by side

How to tell Rev 2 content from Rev 3 without reading it

The numbering format settles it on sight. Rev 2 writes requirements as 3.1.1 across
fourteen families. Rev 3 writes them as 03.01.01 and introduces three families the
earlier revision did not have. If a document contains organization-defined parameters — bracketed
values you are expected to set yourself — it is Rev 3 content.

This check matters more than it sounds. The common failure is not a wholesale switch but a
mismatch: Rev 2 requirement text sitting under a Rev 3 label, or a cover page claiming one revision
while the body numbers the other. Both look authoritative and neither survives an assessment.

The NIST 800-171 templates a CUI programme actually needs

A usable set is not one document per requirement. It divides into five groups.

• Scoping documents. A CUI definition and identification guide, a scoping and
  boundary guide, and a data flow inventory. These decide how much of your estate is in scope, which is
  the single largest cost driver in the programme.
• The two assessment artefacts. A System Security Plan and a Plan of Action and
  Milestones.
• Family policies. One per requirement family — access control, awareness and
  training, audit and accountability, configuration management, identification and authentication,
  incident response, maintenance, media protection, personnel security, physical protection, risk
  assessment, security assessment, system and communications protection, and system and information
  integrity.
• Assessment templates. SP 800-171A gives the assessment procedures; a plan and a
  report template turn those into something you can run and hand over.
• Registers. Asset, CUI data, risk, vendor and subcontractor flowdown, exceptions,
  training. These produce the evidence that the policies claim exists.

The two documents an assessor asks for first

Everything else supports these two.

The System Security Plan describes the system boundary and states how each
requirement is met. Its weakness is almost always the boundary: a plan that describes an idealised
network rather than the one you run will fail on the first walkthrough. Write the boundary before you
write anything else, and make the CUI data flow inventory agree with it.

The Plan of Action and Milestones records what is not yet met, with an owner and a
date. Contractors routinely treat a POA&M as an admission of failure and try to submit an empty
one. That reads as a programme that has not looked, and a POA&M with honest dates is a stronger
position than a clean sheet nobody believes.

What NIST 800-171 templates cannot do for you

NIST 800-171 templates give you structure, defensible wording and a complete list of what to produce. They
cannot make the scoping decision, because only you know where CUI actually goes. They cannot
implement multifactor authentication or FIPS-validated cryptography. And they cannot generate the
evidence — the access reviews, the log retention, the training records — that turns a written control
into an assessed one.

Budget accordingly. In most programmes the documentation is finished in weeks and the technical
remediation runs for months, which is the reverse of what the template shopping implies.

Scoping decides how many NIST 800-171 templates you have to maintain

The requirements apply to the systems that process, store or transmit CUI. That sentence is the
whole cost model, because the number of in-scope systems drives the number of policies, registers and
evidence streams you will maintain for years.

Two approaches dominate. The enterprise approach treats the whole environment as
in scope: simpler to describe, far more expensive to evidence, and it drags every workstation and
every SaaS application into the assessment. The enclave approach puts CUI into a
defined segment with controlled entry and exit, so the requirements apply to a much smaller estate.

An enclave costs more to design and much less to run, and it makes the System Security Plan
tractable. The mistake to avoid is declaring an enclave you do not actually enforce — if CUI reaches
email, shared drives or laptops outside the boundary, the real scope is the whole estate no matter
what the plan says. Write the data flow inventory honestly first, then decide.

Flowdown, and the requirement most contractors miss

If you pass CUI to a subcontractor, the obligation travels with it. That means contract clauses,
a record of which suppliers hold CUI, and some assurance that they meet the same requirements.

This is the gap that surfaces late, because it lives with procurement rather than IT and nobody
owns it until an assessor asks. A vendor and subcontractor flowdown register is a small document that
prevents a large problem: it forces the question of who actually holds your CUI, which is often a
longer list than anyone expects.

A sensible order to work through them

Having the documents is not the same as knowing where to start. The order that wastes least effort
runs: identify CUI, draw the boundary, then write the System Security Plan against that boundary.
Only then work through the family policies, because a policy written before the boundary is settled
gets rewritten once the scope changes.

Run the assessment last, using the SP 800-171A procedures, and let it populate the POA&M rather
than trying to guess your gaps in advance. Teams that reverse this — policies first, scope later —
generally produce a complete-looking set of NIST 800-171 templates that describes a system they do not
operate.

Frequently asked questions

Should my NIST 800-171 templates use Rev 2 or Rev 3?
Rev 2 if you are in scope for CMMC or a DFARS clause pointing at it, because 32 CFR 170 incorporates
R2 by reference. Rev 3 if you are following NIST’s current publication outside that regime.

Is Rev 2 withdrawn?
At NIST, yes — withdrawn 14 May 2024 and superseded by Rev 3. That does not change what the CMMC rule
requires, which is why both statements are true at once.

What is the difference between 800-171 and 800-171A?
800-171 states the security requirements. 800-171A gives the assessment procedures used to determine
whether each one is satisfied.

Do I need a separate policy for every family?
Not strictly, but it is the structure assessors expect and it makes the mapping obvious. Fourteen
focused policies are easier to maintain than one document that tries to cover everything.

Can I submit an empty POA&M?
You can, but only if every requirement is genuinely met and evidenced. An empty POA&M on an
immature programme invites scrutiny rather than avoiding it.

Where this leaves you

Settle the revision first, and settle it from the rule rather than from whichever version is
newest. For CMMC work that means Rev 2, with its 3.1.1 numbering and fourteen families,
even though NIST has withdrawn it — an obligation frozen at an older edition makes the older edition
correct.

Then build the set in order: scope, then the System Security Plan, then the family policies, then
the registers that prove them. NIST 800-171 templates shorten the writing. The scoping decision and
the evidence are still yours.

References

• NIST SP 800-171 Rev. 2 — the publication page recording its withdrawal and superseding revision.
• NIST SP 800-171 Rev. 3 — the current NIST publication.
• 32 CFR 170.14, CMMC Model — the regulation incorporating SP 800-171 R2 by reference.

More on CUI and DoD compliance

• NIST 800-171 templates — you are here
• NIST SP 800-171 explained
• CMMC vs NIST 800-171
• CMMC compliance
• NIST risk assessment template

The document set is covered by the NIST SP 800-171 Toolkit, or start with the free ISO templates.