Rev 3 Is Not the CMMC Baseline. Plan for Both.

A contractor sends me a system security plan rewritten against NIST SP 800-171 Revision 3, with a note that the team wanted to "get ahead of the change." Their assessment is in four months, and the assessor will score them against Revision 2.

That is the expensive mistake in this corner of compliance. Revision 3 is real, it is better in important ways, and it is not the document your CMMC Level 2 assessment measures.

Revision 2 is what you are assessed against. Revision 3 is what you are designing for. Confusing the two costs you an assessment.

Two documents, two jobs

Revision 2 contains 110 security requirements across 14 control families, and it is the basis of the CMMC Level 2 assessment. The DoD assessment methodology that produces your SPRS score is built on those 110 requirements, with a weighted score that runs from minus 203 to 110.

Revision 3 was published in May 2024 (opens in a new tab). It restructures the requirements into 97 items across 17 control families, adds organization-defined parameters throughout, and aligns more closely with the control catalog in NIST SP 800-53. It is a better document. It is also a different document, and the mapping between the two is not one to one.

DoD has been working through how and when to move CMMC onto the newer revision. Until that lands and is codified in the contract clause and the assessment guide, an assessor scoring a Level 2 assessment is working from the 110 requirements.

The practical instruction is not "ignore Rev 3." It is: keep two artifacts. An SSP that maps to the requirements being assessed, and a crosswalk that shows where your implementation satisfies the newer structure.

What Rev 3 actually changes

The change that matters most is the organization-defined parameter.

Revision 2 had some places where the requirement left a value to the organization, but Revision 3 makes the practice systematic. A requirement will say to limit unsuccessful logon attempts to a defined number, or to review audit records at a defined frequency, and the organization has to supply the number and justify it.

That is a documentation burden and an opportunity. The burden is obvious: someone has to choose, write down the choice, and defend it. The opportunity is that a written parameter is testable. "We follow industry best practice" is not a control. "Five attempts, lockout for fifteen minutes, exception process through the service desk" is a control, and an assessor can check whether the system implements it.

The second change is structural. The requirements are organized differently and the language is closer to 800-53, which matters if your program also has to satisfy a federal agency's control catalog. A single implementation can often satisfy both, but only if the mapping is written down.

Why it matters before the baseline moves

Three reasons to do the work now, none of which requires re-baselining your SSP.

The first is that the choices you make today will outlive the revision. A lockout threshold, a log retention period, a vulnerability scan cadence: those are configuration and process decisions. Whether the requirement is numbered 3.1.8 or sits in a restructured family, the decision is the same, and documenting it now means the transition is a mapping exercise rather than a redesign.

The second is that ODP documentation is what an assessor already expects to see, even under Revision 2. The questions are the same: why this number, who approved it, where is it implemented, and how do you know it is still in place. A team that can answer those questions is ready for either revision.

The third is scoping. Revision 3 devotes more attention to how the boundary is defined, and boundary decisions are the ones that are hardest to change late. If the assessment scope is wrong, no amount of control documentation fixes it.

What to do, concretely

Four moves, in order of value.

Keep the SSP anchored to the assessed requirements. Do not rewrite it against a document your assessor is not using. Add the crosswalk beside it.

Write the parameters down in one place. A register with the requirement, the chosen value, the rationale, the owner, and where it is implemented. That register is useful under both revisions and it is the artifact most teams are missing.

Fix the boundary before you fix the language. Decide which systems process, store, or transmit CUI, and write the scope statement. Most findings I have seen are scope findings wearing a control number.

Do not migrate the SSP mid-assessment. If an assessment is scheduled, finish it against the current baseline. A plan that changes the target while the evaluator is looking is a plan that fails on process rather than substance.

The timeline argument, without the panic

The pressure is real. The CMMC program rule was published in October 2024, and the contract clauses that carry it into solicitations are the next step in the sequence. Primes are already flowing the requirements down to subcontractors, and the conversation has moved from conference panels to bid packages.

But the pressure does not justify the wrong document. A team that rewrites its SSP against Revision 3 and then discovers the assessment measures Revision 2 has spent months producing a mapping it cannot submit. A team that keeps the assessed baseline clean and tracks the newer revision separately is ready for both, and it is ready sooner.

The program office's question is not which revision you admire. It is whether the controls are implemented, documented, and evidenced. Revision 3 gives you a better vocabulary for answering that. It does not change the answer.

Standards revise. Assessments lag. The gap between the two is where contractors get hurt, and it is a process problem rather than a technical one.

Write down what you implemented and why. Keep the record of the choice, not just the choice. When the baseline moves, the mapping moves with it, and the evidence you already have keeps its value.

That is a duller project than "getting ahead of Rev 3," and it is the one that survives the assessment.