Policy Library Guide

Policies vs. Procedures vs. Standards vs. Guidelines

Most contractors conflate these terms. The distinction matters during assessment because assessors expect different things from each level of document.

For CMMC purposes, the policy layer is what your SSP references and what most assessors first ask for. Standards and procedures support the policy and are typically referenced from within it. Treat the policy as the authoritative statement of intent; treat procedures as the operational detail that backs it up.

One useful rule of thumb: policy says the organization will do X; procedure describes who does X, when, with what tools. A document that mixes both layers — half intent, half operational steps — is harder to maintain and weaker as evidence.

Document Control Basics

Every policy document, regardless of family, must include the same control metadata. Assessors will look for it on every document they review.

• Document title and identifier: A unique name and (optionally) a tracking number
• Version number: Major.minor format, incremented on substantive change
• Effective date: When this version became binding
• Next review date: When the policy is scheduled for review (typically 12 months from effective date)
• Owner: The role or position responsible for maintaining the document — not a person's name (people change roles)
• Approver: The role or position that approved the version — typically the System Owner or equivalent executive
• Approval signature and date: Wet or digital signature evidencing the approval
• Revision history: Brief log of substantive changes from prior versions

Policies without this metadata, or with metadata that has not been updated in years, fail the basic credibility test. A policy with an "approval date" of three years ago and no revision history communicates that the document is not actively maintained, regardless of what it says.

The 14 Required Policies

NIST SP 800-171 organizes its 110 requirements into 14 families. Most contractors structure their policy library to match — one policy per family, with a 15th overarching information security policy. The breakdown below describes what each policy must contain to support the corresponding 800-171 requirements. Specific structure varies; what matters is that the content exists and is producible on demand.

Additional Documents Beyond the 14 Policies

Several documents are not formally CMMC-required policies but are routinely expected during assessment:

• Information Security Policy (overarching): A short top-level document signed by the senior executive, asserting the organization's commitment to information security and naming the responsible roles. Often serves as the umbrella under which the 14 family policies sit.
• Acceptable Use Policy (AUP): Rules for end users on appropriate use of organizational systems and information. Typically signed by all personnel on hire and periodically reaffirmed.
• Data Classification Policy: The organization's framework for classifying data sensitivity (CUI, FCI, internal, public) and the handling rules for each classification. CMMC does not require a four-tier classification scheme, but a CUI-aware classification policy strengthens the SSP narrative.
• Privacy Policy: Required if the organization handles personally identifiable information beyond the minimum needed for HR purposes.
• Vendor / Third-Party Management Policy: Rules for selecting, contracting with, and overseeing vendors who handle CUI or have access to in-scope systems. See the vendor oversight guide.
• Disaster Recovery / Business Continuity Plan: Not directly mapped to 800-171 Rev 2 (Rev 3 introduces explicit availability requirements), but commonly expected. CMMC Level 3 introduces additional resilience requirements drawn from 800-172.
• System Security Plan (SSP): The master document referenced by everything else; a policy-adjacent artifact rather than a policy itself. See the SSP guide.
• Plan of Action and Milestones (POA&M): The living tracker of open compliance gaps and their remediation plans.

Authoring Principles

• Write for the people who must follow it. A policy that only the ISSO can interpret will not be followed by the user population. Plain language, concrete examples, clear roles.
• Map every policy to specific 800-171 requirements. A policy section should reference the requirement IDs it satisfies (e.g., "implements 3.1.5, 3.1.7, 3.1.8"). Assessors find this enormously helpful and it forces you to confirm coverage.
• Use definite language. "Will" and "must" are policy verbs. "May," "should," and "as appropriate" are not. A policy that uses soft language is hard to enforce and hard to assess against.
• Reference standards and procedures from the policy. The policy says what the organization will do; the standard says the technical specification; the procedure says the steps. Each layer references the next.
• Write what you actually do. A policy that prescribes practices the organization does not actually follow is worse than no policy at all — it creates a gap between the documented and the operational that becomes a finding.
• Keep policies short. Most family policies should fit in 3–6 pages. Long policies are not read; short policies are.
• Approve at the right level. Each family policy should be approved by the System Owner or equivalent executive — not by IT alone. Executive approval signals organizational commitment.

Common Mistakes

• Boilerplate from a template. Downloaded policy templates that describe industry-standard practices not implemented in your environment generate findings — the SSP says you do X (because the policy says you do X) but you don't actually do X. Tailor every policy to your environment.
• Policies that contradict the SSP. The SSP and the policies must align. If the policy says "MFA is required for all remote access" but the SSP implementation statement notes MFA is required for privileged remote access only, one or the other is wrong.
• Stale review dates. Policies with "next review date: 2022" in 2026 communicate that the policy is not actively maintained.
• Unsigned or undated documents. A policy without an approval signature and date is not a policy — it's a draft.
• Referenced policies that don't exist. The SSP cites "the Acceptable Use Policy" and "the Configuration Management Plan" — but no document by those names exists or is producible. Walk through every SSP reference and confirm the cited document exists.
• Policies maintained outside the document control system. Policies stored on individual user laptops, in personal email, or in personal OneDrive folders cannot be controlled. Centralize document storage with version control.
• One-size policies that ignore in-scope/out-of-scope distinctions. If your enclave operates under different rules than the rest of the organization, the policies must reflect that. A single Access Control Policy that doesn't distinguish enclave from non-enclave access creates ambiguity.

Review and Update Cycle

Policies are living documents. Establish and document the review cycle:

• Annual review: Each policy reviewed at least once per year. The review may confirm no changes needed, in which case the version is incremented and a "no substantive change" entry added to the revision history.
• Trigger-based review: Updates triggered by significant changes — new in-scope systems, organizational restructuring, regulatory changes, post-incident lessons learned, audit findings.
• Approval workflow: Updates follow the same approval workflow as initial creation. The System Owner re-approves any substantive changes.
• Communication: Material changes must be communicated to affected personnel. A change to the password policy that no user knows about cannot be enforced.
• Documentation: The revision history is the audit trail. Maintain it diligently; assessors look at it to gauge whether the document is genuinely active.

Authoritative References