CMMC Level 2 Policy Pack for Small Contractors (14 policies, plain-language templates that match NIST 800-171)

If you’re a small contractor, you don’t lose bids because you can’t do the work. You lose them because you can’t prove you protect CUI.

That’s why CMMC Level 2 policies matter. A policy pack gives you a clear, written “this is how we operate” baseline. Still, templates only help when they match your real systems, your real people, and your real evidence.

In this post, I’ll break down a practical 14-policy pack (written in plain language), show how it lines up to NIST SP 800-171 families, and explain what you should collect as proof before an assessor ever shows up.

Why a 14-policy pack is the fastest way to get organized (and stay that way)

When I walk into a small shop, I usually see the same problem: good technical intentions, scattered documentation. Someone turned on MFA, somebody else bought antivirus, and a third person “meant to” write it down. Assessors don’t grade intentions. They grade what’s documented, implemented, and evidenced.

A solid policy pack helps you in three ways:

First, it forces clear decisions. Who approves access? What counts as CUI? Where is the system boundary? Those answers drive everything else.

Second, it keeps your System Security Plan honest. Policies should match the way you actually run IT, not the way you wish you did.

Third, it makes evidence collection easier because every policy implies artifacts (logs, tickets, screenshots, training records).

For current assessment expectations and the way Level 2 practices get evaluated, I keep the official guides bookmarked, starting with the CMMC Level 2 Assessment Guide and the CMMC Level 2 Scoping Guide. They’re plain about one thing: scoping and objective evidence drive outcomes.

A template can start your program, but it can’t finish it. Your day-to-day actions have to match the words on paper.

The 14 CMMC Level 2 policies and how they map to NIST SP 800-171 families

Here’s the structure I use for a CMMC Level 2 Policy Pack for small contractors. Each policy is written so a non-security manager can read it, approve it, and follow it.

This table shows the primary NIST SP 800-171 family alignment, plus example control references (examples only, not a promise of 1:1 coverage).

Policy template (plain language)	Primary NIST SP 800-171 family	Example control refs (examples)
Access Control Policy	AC	3.1.1, 3.1.2, 3.1.5
Security Awareness and Training Policy	AT	3.2.1, 3.2.2
Audit Logging and Accountability Policy	AU	3.3.1, 3.3.2, 3.3.6
Configuration Management and Change Control Policy	CM	3.4.1, 3.4.2, 3.4.5
Identification and Authentication (MFA, passwords) Policy	IA	3.5.1, 3.5.3
Incident Response Policy	IR	3.6.1, 3.6.2, 3.6.3
Maintenance and Remote Support Policy	MA	3.7.1, 3.7.2
Media Protection and CUI Handling Policy	MP	3.8.1, 3.8.3, 3.8.7
Physical Security Policy	PE	3.10.1, 3.10.3
Personnel Security (onboarding, offboarding) Policy	PS	3.9.1, 3.9.2
Risk Assessment Policy	RA	3.11.1, 3.11.2
Security Assessment and POA&M Governance Policy	CA	3.12.1, 3.12.2
System and Communications Protection Policy	SC	3.13.1, 3.13.8, 3.13.11
System and Information Integrity (malware, patching) Policy	SI	3.14.1, 3.14.2, 3.14.6

A quick 2026 reality check: many orgs hear “Rev. 3” and panic. In practice, I’m still seeing most CMMC Level 2 work anchored to Rev. 2’s 110 controls, with Rev. 3 planning happening in parallel. If you want a straightforward explanation of why that’s the case right now, this February 2026 summary is helpful: Why NIST 800-171 Rev. 3 is not yet the standard for CMMC.

Tailoring notes that keep your policies clean, credible, and assessable

Templates fail when they pretend every company looks the same. Small contractors need Tailored Technology Services, not a 60-page policy that no one reads.

I tailor each policy using three anchors:

Roles and approvals. Name roles, not people (Owner, Program Manager, IT Admin, HR, MSP). Then document who approves access, who reviews logs, and who owns incident response.

Scope and system boundary. Keep your CUI boundary tight. If CUI lives in one enclave, don’t write policies that drag your whole business into Level 2. The DoD scoping guide helps here, but your network diagrams and data flow matter more.

Cloud and MSP reality. Many small teams run Microsoft 365 and outsourced IT. That’s fine, but your policies must say how you control it. If you do an Office 365 Migration, document tenant settings, Conditional Access, and admin roles. If an MSP runs patches, say how you verify results. This is where Secure Cloud Architecture and Cloud Management stop being buzzwords and start being audit requirements.

My work is usually split between Small Business IT and compliance-heavy environments. One day I’m tightening Endpoint Security and Device Hardening on laptops. The next day I’m reviewing Cloud Infrastructure choices, Data Center Technology constraints, and Infrastructure Optimization plans for a small engineering firm. Even in unrelated lines of work like Restaurant POS Support and Kitchen Technology Solutions, the same theme shows up: if you can’t control identities, updates, and logging, you can’t defend the business.

That’s also why I treat policy writing as part of Technology Consulting, not paperwork. The right policies support Digital Transformation without turning every change into a fire drill. They also help me act as a true Business Technology Partner, not just “the IT person.”

Evidence artifacts to collect for each policy (what assessors want to see)

Policies are the promise. Evidence is the receipt. If you want Managed IT for Small Business that stands up in an assessment, build a simple evidence folder structure now, then add to it weekly.

Here are practical artifacts I collect per policy. Keep them dated, and tie them back to your SSP statements.

Policy	Practical evidence artifacts (examples)
Access Control	Access request tickets, group membership exports, least-privilege review notes
Awareness and Training	Training roster, phishing results, signed acknowledgements, new-hire training records
Audit Logging	SIEM or log platform screenshots, retention settings, sample audit log entries
Configuration Management	Baseline configs, change tickets, approved standard images, exceptions list
Identification and Authentication	MFA enforcement screenshots, password policy settings, admin role assignments
Incident Response	IR plan, tabletop notes, incident tickets, 72-hour reporting workflow proof
Maintenance and Remote Support	Remote tool inventory, session logs, approvals for vendor access
Media Protection	USB control settings, encryption proof, media sanitization records
Physical Security	Badge logs, visitor logs, camera policy, server room access list
Personnel Security	Background check attestation (as applicable), offboarding checklist, account disablement proof
Risk Assessment	Risk register, vulnerability scan summaries, remediation tracking
Security Assessment and POA&M	Self-assessment results, POA&M with dates, management sign-off
System and Communications Protection	Network diagrams, firewall rules review notes, segmentation proof
System and Information Integrity	Patch reports, EDR alerts, malware scan logs, vulnerability management tickets

How I pass an assessment with templates (without “template theater”)

I treat templates like a set of rails. They keep you moving straight, but you still have to drive.

1. Confirm what Level 2 you need. Some contracts accept self-assessment and affirmation, others require a third-party assessment. The rule language and requirements for affirmation live in 32 CFR 170.16.
2. Lock the boundary. I document where CUI is created, stored, and transmitted, then I design controls only for that boundary.
3. Make policies match tools. If you say “logs are reviewed weekly,” schedule it and keep proof.
4. Write the SSP in parallel. Policies explain intent, the SSP explains implementation.
5. Run a mock evidence pull. If you can’t produce artifacts in one hour, fix your process now.
6. Align contract representations. For contractual language tied to CMMC status, I reference the clause text in DFARS 252.204-7021, and I keep DFARS 252.204-7012 incident reporting expectations built into my incident workflow.

If you want a single guiding principle, it’s this: Business Continuity & Security comes from routine, repeated actions, not from a binder on a shelf.

Conclusion

A CMMC Level 2 Policy Pack only works when it’s plain, scoped, and lived every week. The 14 policies above give small contractors a clean structure that tracks the NIST SP 800-171 families, without burying the team in legal-sounding text. If you want help turning templates into real operations, I’ll happily map your boundary, tune your controls, and build an evidence rhythm that holds up under pressure, while still supporting Innovative IT Solutions that keep the business moving.