Ask a first-time CMMC candidate what they are missing and the answer is usually technical: multi-factor authentication, logging, encryption. Ask an assessor and you often hear something different. Companies fail to demonstrate requirements because the policy, the procedure, or the evidence is missing, even when the technology is fine.
For CMMC Level 2, which is built on NIST SP 800-171, practices need to be documented, implemented, and demonstrable. This article lists the policies a defense subcontractor should write first, what each should cover, and how to keep them honest. With the CMMC program rule in effect since December 16, 2024, and DFARS contract requirements phasing in since November 10, 2025, many subcontractors are now being asked for proof, not promises.
Policy Versus Procedure
A policy states what the company requires and why. A procedure explains how someone carries it out. Assessors look for both, along with evidence that people follow them. Keep policies short and readable, and let procedures hold the detail.
The Core Policies
1. Access control
Define who may access systems and data that handle Controlled Unclassified Information. Cover account creation, approval, least privilege, review frequency, and removal at termination. State that accounts are unique to individuals and that shared logins are prohibited for in-scope systems.
2. Identification and authentication
Describe password requirements, multi-factor authentication for in-scope access, and how credentials are protected. Include remote and privileged access.
3. Media protection and handling of CUI
Explain how CUI is marked, stored, transported, and destroyed. Cover removable media, printed copies, and how employees return or delete data at the end of a contract.
4. Incident response
State how incidents are reported internally, who leads, how evidence is preserved, and how and when customers or government contacts are notified as your contracts require. Include a contact list and a plan to practice it.
5. Configuration and change management
Describe how systems are built to a secure baseline, how changes are approved and tested, and how unauthorized software is controlled.
6. System and communications protection
Cover network boundaries, encryption of CUI in transit and at rest, remote access methods, and separation of the CUI environment from other networks.
7. Audit and accountability
Define what is logged, how long logs are retained, who reviews them, and what triggers follow-up.
8. Personnel security
Cover screening where appropriate, onboarding and offboarding, acceptable use, and discipline for violations.
9. Physical protection
Describe who may enter areas where CUI is handled, how visitors are managed, and how equipment is protected.
10. Risk assessment and vulnerability management
Explain how risks are identified, how often vulnerabilities are scanned or checked, and how fixes are prioritized and tracked.
11. Security awareness and training
Describe who is trained, how often, and on what topics, including recognizing phishing and handling CUI properly.
12. Maintenance
Cover how equipment is serviced, who may perform remote maintenance, and how those sessions are controlled and logged.
Writing Policies That Survive Scrutiny
- Describe reality. If your policy requires monthly access reviews and you do them yearly, change one or the other. Assessors compare words to practice.
- Name roles, not people. Use titles such as "IT lead" so documents do not become stale every time someone moves.
- Include dates and owners. Each document should show an approval date, a review schedule, and a responsible role.
- Keep language plain. If your shop supervisor cannot understand the CUI handling policy, it will not be followed.
- Link to evidence. For each policy, know where proof lives: tickets, logs, training rosters, screenshots, signed forms.
Avoid Copy-and-Paste Templates
Templates are fine as a starting point, but unedited ones are easy to spot. They mention systems you do not own and processes you do not perform. Tailor every section to your actual environment and delete what does not apply.
Make Policies Part of Daily Work
Policies sitting in a folder do not satisfy anyone. Walk through them with supervisors, add key rules to onboarding, and tie them to ticket and approval workflows. When something changes, such as a new software tool or a new office, update the relevant policy at the same time.
Review Cadence
Review policies at least annually and after significant events, such as a security incident, a new contract with different requirements, or a major system change. Keep prior versions and a short change log.
Getting Help
Writing policies is rarely the hard part. Making them accurate is. Ironfield Cyber can help a defense subcontractor draft concise policies, align them with what your team really does, and organize the evidence an assessor will ask to see.