The 20 Policies CMMC Level 2 Requires (& How to Write Them)

The short answer

CMMC Level 2 sits on the 14 control families of NIST SP 800-171, and each family needs a documented policy — which, with a couple of overarching documents, lands most small shops at roughly 20 policies. A policy states what you require and who owns it; a separate procedure states how it's done. Write them to what your business actually does, map each to its control family, and the paperwork stops being the thing that fails you.

Nobody fails a CMMC assessment because their firewall wasn't fast enough. They fail because the documentation didn't hold up — a policy that described a company they aren't, a procedure filed where a policy should be, a control with nothing on paper behind it. The 110 controls get the attention, but the writing is where small contractors quietly lose.

Here's the part that should make you feel better: the policy layer is the most learnable, most templatable part of the whole standard. The 14 families are fixed and public. The structure of a good policy never changes. Once you understand what a policy has to actually say — and how it differs from the procedure sitting next to it — you can write all 20 yourself and have them stand up.

I've written these for shops from six seats to sixty. Below is what each control family needs, what a policy must contain to pass, the practical list a small contractor works from, and the failures I see over and over. No fluff, because your assessor won't reward fluff either.

On this page

Why every control family needs a policy
Policy vs. procedure — the distinction that trips people
What a policy must actually say
The practical list: 20 policies for a small shop
Why wording beats length
The failures I see most
FAQ

Why every control family needs a policy

NIST SP 800-171 organizes its 110 controls into 14 families — Access Control, Awareness & Training, Audit & Accountability, Configuration Management, Identification & Authentication, Incident Response, Maintenance, Media Protection, Personnel Security, Physical Protection, Risk Assessment, Security Assessment, System & Communications Protection, and System & Information Integrity. Each family is a coherent chunk of your security posture, and an assessor works through them one at a time.

A documented policy for each family is how you prove the requirement isn't just something one admin happens to do — it's a standing organizational rule with an owner behind it. When your System Security Plan says "we enforce least privilege," the assessor's next move is to ask where is that written down as a requirement, and who owns it? The policy is the answer. Without it, the control is a claim with no backing.

That's the mental model: the policy is the commitment, the procedure is the execution, and your evidence is the proof it happened. Miss the commitment layer for a family and every control under it starts on shaky ground.

The frame that helps Think of it as three columns per control family: the policy (what we require and who's accountable), the procedure (how we carry it out), and the evidence (logs, screenshots, records that show it ran). An assessor reads left to right. A gap in the first column undermines everything to its right.

Policy vs. procedure — the distinction that trips people

This is the single most common mix-up, and it's worth slowing down on. A policy is a statement of intent and authority. It says what the organization requires, why, and who is responsible for making it stick. It's short, stable, and rarely changes. A procedure is the how-to: the specific steps, tools, and settings that carry the policy out. It changes whenever your tools or workflow change.

Put concretely, in the Access Control family:

Policy: "All access to systems that store, process, or transmit CUI is granted on a least-privilege basis. The IT lead approves and reviews access quarterly. Accounts for departed personnel are disabled within one business day."
Procedure: "To provision a new user: create the account in the identity provider, assign the CUI-enclave group, enforce the YubiKey MFA prompt, log the approval in the access register, and file the ticket number."

See the difference? The policy is the rule and the accountability. The procedure is the keystrokes. Assessors expect both, and the classic failure is writing a detailed procedure, labeling it "policy," and leaving no actual policy statement anywhere. When that happens, the control has no organizational commitment behind it — just an undocumented habit.

Don't merge them into one blob Keep policy and procedure as separate documents, even if they live in the same binder. Merging them means every time a tool changes you're editing your "policy," which signals to an assessor that your policies aren't stable governance documents. Stable policy on top, living procedure underneath.

What a policy must actually say

Strip away the templates and a policy that passes always contains the same handful of elements. If yours has these, it works. If it's missing one, that's usually the finding.

Scope — what and who it covers.Name the systems and people it applies to. For a small shop running a CUI enclave, scope the policy to the enclave and the users who touch controlled data — not the whole company. Scope creep in the policy is scope creep in your assessment.
The requirement — the rule itself, plainly stated.What must happen, in language you actually follow. "MFA is required for all CUI-enclave access" — not "MFA may be considered where appropriate." Weasel words fail because they're unenforceable.
Ownership — who is accountable.Name the role (not the person) responsible for enforcing and maintaining the policy. An assessor will ask who owns it. "The IT lead" is an answer; silence is a finding.
Review cadence — how often it's revisited.State that the policy is reviewed at a set interval and after significant changes, and record the last review date. A policy nobody has looked at in three years reads as abandoned.
Control mapping — which family and controls it satisfies.Reference the control family and the specific 800-171 controls the policy backs. This is what lets the assessor connect your policy to their checklist without guessing.

Five elements. Scope, requirement, ownership, review, mapping. A policy that nails those in two clean pages beats a bloated one that buries them — which is exactly the point of the next section.

The practical list: 20 policies for a small shop

There's no single federal document that says "write these exact 20." What exists is the requirement for documented policy across all 14 families. In practice, small contractors write one policy per family and add a few overarching governance documents, which is how the number lands near 20. Here's the working set I build from.

#	Policy	Family	What it commits you to
01	Access Control Policy	AC	Least privilege, account management, remote and CUI access rules.
02	Awareness & Training Policy	AT	Security awareness and role-based training for everyone touching CUI.
03	Audit & Accountability Policy	AU	What gets logged, how logs are protected, who reviews them.
04	Configuration Management Policy	CM	Baselines, change control, and locking down system settings.
05	Identification & Authentication Policy	IA	Unique IDs, MFA, and password/credential requirements.
06	Incident Response Policy	IR	Detecting, reporting, and handling security incidents.
07	Maintenance Policy	MA	Controlled system maintenance and handling of maintenance tools.
08	Media Protection Policy	MP	Marking, storing, transporting, and sanitizing media that holds CUI.
09	Personnel Security Policy	PS	Screening, and protecting CUI during transfers and terminations.
10	Physical Protection Policy	PE	Physical access to CUI systems, facilities, and devices.
11	Risk Assessment Policy	RA	Assessing risk and running vulnerability scanning.
12	Security Assessment Policy	CA	Assessing controls, the SSP, and managing the POA&M.
13	System & Communications Protection Policy	SC	Boundary protection, segmentation, and encryption of CUI.
14	System & Information Integrity Policy	SI	Flaw remediation, malware protection, and monitoring.
15	Information Security Program Policy	—	The overarching document that ties the program together.
16	CUI Handling & Marking Policy	—	How controlled data is identified, marked, and handled day to day.
17	Acceptable Use Policy	—	What users may and may not do on systems that touch CUI.
18	Mobile Device & Remote Work Policy	—	Protecting CUI on the road, at home, and on mobile endpoints.
19	Data Backup & Recovery Policy	—	Encrypted, versioned, recoverable backups and restore testing.
20	Vendor & Supply Chain Policy	—	Flowing requirements down to subcontractors and service providers.

The first 14 map cleanly to the families. The last six are the overarching and cross-cutting documents that most assessors expect to see and that keep the family policies from having to repeat themselves. Your exact set may shift a little based on how your contract and your assessor scope things — but this is a set that covers the ground without inventing paperwork you don't need.

Scope note Every one of these should be written to your assessment boundary, not your whole company. If you've scoped CUI into an enclave, the policies govern the enclave. Read the CUI enclave method for why that boundary decision drives everything, including how much policy you have to enforce.

Why wording beats length

Assessors don't weigh your policies. A twenty-page Access Control policy full of borrowed boilerplate is not "more compliant" than a tight two-pager — it's usually less, because the longer it is, the more likely it describes something you don't actually do. And the fastest way to fail is a policy that contradicts your evidence.

Here's the trap with copy-pasted policies: they're written for a generic, larger organization. They'll say things like "the Security Operations Center reviews alerts 24/7" when you're a nine-person shop with no SOC. The moment an assessor reads that and then asks to see your SOC, you've got a documented commitment you can't meet — which is worse than not claiming it at all. Every sentence in a policy is a promise you're agreeing to be graded against.

So the discipline is: write what's true, name who's accountable, keep it enforceable, and cut everything you can't stand behind. Short and honest sails through. Long and aspirational gets picked apart.

The test for every line Read each sentence and ask: "If the assessor asks me to prove this, can I?" If yes, keep it. If no, either build the capability or cut the sentence. A policy is not a wish list — it's a set of claims you're volunteering to be audited on.

The failures I see most

Same handful, over and over. Avoid these and you're ahead of most small shops walking into an assessment:

Procedure masquerading as policy. A detailed how-to labeled "policy," with no actual requirement statement or owner. The most common one.
Boilerplate that describes someone else's company. References to teams, tools, and facilities you don't have. Instant credibility loss when cross-checked.
No named owner. "Someone handles this" doesn't survive the question "who?" Name the role.
Policies that don't match the SSP. Your System Security Plan says one thing, the policy says another. Contradictions read as "nobody maintains this."
Stale documents. No review date, no revision history, last touched years ago. Reads as abandoned governance.
Missing a family entirely. Fourteen families, and one has no policy. That's a straightforward gap the assessor will flag every time.

None of these are hard to fix. They're just easy to miss when you're writing twenty documents under deadline pressure — which is exactly why starting from a mapped, editable set beats a blank page.

Skip the blank page

All 20 policies, editable, mapped to every control family.

Writing twenty policies from scratch is the slow, error-prone half of CMMC. The CMMC Level 2 DIY Compliance Kit gives you all 20 as editable documents — each with the scope, requirement, ownership, review, and control mapping already structured — plus a System Security Plan, a POA&M template, and a per-control SPRS scorer. Tailor them to your shop instead of building them from nothing.

$2,995

one-time · lifetime updates · a fraction of a consultant's retainer

Get the Compliance Kit → Check my SPRS score free →

Audit-ready preparation for a fraction of consultant fees — not a substitute for your C3PAO assessment. Not legal advice.

Before you write a word, get a baseline: the free SPRS score estimator shows where you stand against the 110 controls in about two minutes, so you know which families need the most attention. And if the price of getting all this done is what's on your mind, the honest breakdown of CMMC cost for a small business lays out every line item — including where the documentation work is the biggest share of a consultant's bill.

Frequently asked questions

How many policies does CMMC Level 2 require?

CMMC Level 2 is built on the 14 control families of NIST SP 800-171, and each family needs a documented policy. In practice most small contractors write one policy per family plus a couple of overarching documents, which lands at right around 20 policies. There is no single federal list that says "these exact 20," but a policy per control family is what assessors expect to see referenced in your System Security Plan.

What is the difference between a policy and a procedure in CMMC?

A policy states what your organization requires and who is responsible — the rule and the authority behind it. A procedure describes how that rule gets carried out, step by step. Assessors want both: a policy that commits you to a control and a procedure that shows the control actually runs. Writing a procedure and calling it a policy is one of the most common documentation failures.

Do CMMC policies need to be long to pass?

No. Length is not what an assessor grades. A policy passes when it clearly states the requirement, names who is accountable, references the control family it satisfies, and matches what your organization actually does. A tight two-page policy that is true beats a twenty-page policy full of language you do not follow. Accuracy and enforceability matter far more than word count.

Can a small contractor write CMMC policies without a consultant?

Yes. Policies are the most template-friendly part of CMMC because the control families are fixed and public. A small shop can start from proven, editable policies mapped to each family, then tailor them to how the business really operates. What you cannot skip is the tailoring — copy-paste policies that describe a company you are not will fail the moment an assessor cross-checks them against your evidence.

When do these CMMC Level 2 policies need to be in place?

Now, if you are chasing contracts that will require Level 2. November 10, 2026 begins Phase 2, when Level 2 third-party (C3PAO) certification becomes a required condition of award on applicable DoD contracts, and self-assessment and affirmation language is already appearing in solicitations. Your policies underpin your System Security Plan, so they need to exist and be accurate before any assessment, not written the week before.

Do my policies have to cite a specific NIST 800-171 revision?

Your policies should map to the 14 control families and the 110 controls of NIST 800-171, and they should reference whichever revision your contract and your assessment scope call for. Confirm the exact revision against your contract requirements and your C3PAO rather than assuming — the control families and the count of 110 are the stable anchor, and the policies should reference the specific version you are being assessed against.