CMMC does not ask for a shelf of binders
A firm that buys a box of policy templates can end up with hundreds of pages nobody has read. NIST SP 800-171 asks for something different: a small set of documents that describe what your firm actually does, and records that show it happened.
In Revision 2, which is the version DoD holds contractors to, NIST did not carry over the stand-alone policy controls from its federal catalog. Appendix E marks items like AC-1, Access Control Policy and Procedures, as NFO, meaning expected to be routinely satisfied by nonfederal organizations without specification. No line of Revision 2 says "write an access control policy." The expectation arrives through two other doors: the requirements that name documents directly and the objectives assessors use.
What the requirements name directly
A handful of Revision 2 requirements call for a document or a record in their own words.
| Requirement | What it calls for |
|---|---|
| 3.12.4 | System security plans, developed, documented and periodically updated, describing system boundaries, environments of operation, how requirements are implemented and relationships with other systems |
| 3.12.2 | Plans of action to correct deficiencies and reduce or eliminate vulnerabilities |
| 3.6.1 and 3.6.2 | An operational incident-handling capability, with incidents tracked, documented and reported |
| 3.4.1 | Baseline configurations and inventories, established and maintained |
| 3.4.3 | Changes to systems tracked, reviewed, approved or disapproved, and logged |
| 3.2.1 | Managers, administrators and users made aware of security risks and of applicable policies, standards and procedures |
The system security plan is the one you cannot do without. The DoD Assessment Methodology says the absence of a plan results in a finding that an assessment could not be completed. The CMMC rule also bars 3.12.4 from ever appearing on a plan of action for conditional status.
What the assessment objectives expect
NIST SP 800-171A is the source of most of what people call the documentation requirement. It describes three assessment methods: examine, interview and test. For each requirement it lists the objects an assessor may examine. Requirement 3.1.1 begins its list with "Access control policy; procedures addressing account management; system security plan."
Those lists open with the words "SELECT FROM," so an assessor chooses what is useful. Taken together they make the expectation clear. An assessor will want to see that your rules are written down, that people know how to carry them out, and that the system behaves accordingly.
The DoD methodology gives one direct example. If a company disallows remote, wireless or mobile access and marks those requirements not applicable, it should also have a policy and procedure in place so those capabilities are not enabled inadvertently, and a point should be assessed if it does not. The written rule is doing real work there.
Policy, procedure and evidence are three different things
Most document problems start with mixing these up. Keep them apart and each one gets shorter.
| Item | Answers | Example |
|---|---|---|
| Policy | What we require, and who is accountable | Every person has a unique account. Access is removed when employment ends. The IT lead owns this. |
| Procedure | Exactly how it is done, step by step | HR opens a ticket on the last working day. The IT lead disables the account, moves the files, records the date. |
| Evidence | Proof it actually happened | The closed ticket and the directory record showing the account disabled. |
Assessors weigh the third column heavily. The CMMC scoring rule requires evidence in final form and says unacceptable evidence includes working papers, drafts and unofficial or unapproved policies. A policy with no approval date is weak evidence even when every word is right.
How short a good policy can be
One or two pages is enough for most policies at a firm of 30 people. NIST does not set a length or a count of documents, so write for the reader who has to follow it. A shop supervisor should be able to read your media handling policy in the time it takes to drink a cup of coffee.
A sound policy page carries a few fixed parts.
- Purpose and scope in two sentences, naming the systems and people covered
- Plain rules written as statements someone could check
- The owner, by role, who answers for it
- The requirement numbers it supports, so the plan can point straight at it
- Approval and review: who approved it, when, and when it is next reviewed
Here is the level of detail that works, for an account management policy: "Each person has one named account. Administrator rights are held in a separate account and granted by the IT lead. Accounts are reviewed each quarter against the employee roster. Access ends on the last working day." Four sentences an employee can understand and an assessor can test.
Procedures can be shorter still. A numbered list of six steps that a new hire could follow beats three pages of narrative. Where your tool vendor already documents the steps, link to them and record only your settings and your decisions.
A starter set for a 30-person firm
This set covers the ground the 14 Revision 2 families need. Combine or split them as suits you, because the goal is coverage and accuracy, and the count of files does not matter.
| Document | Main requirements it serves |
|---|---|
| System security plan | 3.12.4, and a statement of how every other requirement is met |
| Plan of action | 3.12.2 |
| Access and account management | 3.1.1, 3.1.2, 3.5.1, 3.5.2, 3.5.3 |
| CUI handling and acceptable use, including personal devices and remote work | 3.1.18, 3.1.20, 3.8.1, 3.10.6 |
| Configuration and change management | 3.4.1, 3.4.2, 3.4.3 |
| Incident response plan | 3.6.1, 3.6.2, 3.6.3 |
| Awareness and training | 3.2.1, 3.2.2, 3.2.3 |
| Physical security and visitors | 3.10.1, 3.10.3, 3.10.4, 3.10.5 |
| Media handling and disposal | 3.8.1, 3.8.3, 3.8.4, 3.8.5 |
| Risk and security assessment | 3.11.1, 3.12.1, 3.12.3 |
| Personnel actions, for departures and transfers | 3.9.2 |
Put the system security plan at the center and let it point outward. For each requirement, the plan says how it is met and names the policy, the procedure and the tool. A reader should be able to start at any requirement number and reach the proof in two steps. If a document in your set is never cited by the plan, ask whether you need it at all.
Where you use an IT provider, your documents still have to say what your firm does and what the provider does. Keep that division in one place, and reference it from each policy, so an assessor never gets two different answers.
Write what people do, then close the gaps
Start by asking. Sit with the people who handle accounts, drawings and laptops and write down what they actually do. Then compare that with the requirement. Where practice meets the requirement, document it as it is. Where it falls short, change the practice and then write it down.
Interview is one of the three assessment methods, so the people on your floor are part of your evidence. A policy your staff would be surprised to read is a finding waiting to happen. Walk your team through each document once it is approved, keep the attendance record, and include the material in onboarding.
A policy your staff would be surprised to read is a finding waiting to happen.
Keep the documents true over time
The CMMC rule defines "periodically" as a regular interval set by your organization that may not exceed one year, and 3.12.4 requires system security plans to be periodically updated. An annual review is therefore the outer limit for those items. Tie the review to the annual affirmation so the person signing has seen fresh documents.
Some changes should trigger an update right away: a new IT provider, a new cloud service, a new building, a change in who owns a process. Keep one version history per document with who changed what and who approved it. Store the set in one controlled location with read access for staff and edit access for the owners, so nobody works from a copy saved to a desktop three years ago. Artifacts used as evidence must be retained for six years from the CMMC Status Date, so keep superseded versions as well.
Ways document sets fail
- Template text left in place, including another company's name or a vendor's product you do not own
- Aspirational language stating that controls exist when they are still being planned
- Rules nobody follows, such as a ban on USB drives while drives move between the office and the shop every day
- No owner and no approval date, which reads as an unapproved policy
- A system security plan that disagrees with the policies it cites
What Revision 3 will change about this
Revision 3 adds a direct requirement at 03.15.01 to develop, document and disseminate the policies and procedures needed to protect CUI, and to review and update them at a frequency you define. DoD has not adopted Revision 3. Firms that write short, owned, reviewed policies now will already be doing what that requirement asks.
Frequently asked questions
Yes. NIST does not prescribe a document count. One well-organized document can work for a small firm, as long as an assessor can find what each requirement needs and it stays current.
Templates are a reasonable starting point. They become a problem when the text describes tools, roles or practices your firm does not have.
The scoring rule treats unofficial or unapproved policies as unacceptable evidence. A recorded approval by a named person with authority, with a date, is the plain way to show a policy is official.
At least annually for anything the requirements call for periodically, since the rule caps "periodically" at one year, and again whenever your environment or your people change.