Key takeaways
- 32 CFR 170.4 defines a temporary deficiency as a fixable gap with a known fix available or in process.
- An enduring exception is a gap where full compliance is not feasible, and it must be described in the system security plan.
- Under 32 CFR 170.24, properly documented temporary deficiencies and enduring exceptions are assessed as MET.
- An operational plan of action under NIST SP 800-171 requirement 3.12.2 is separate from an assessment POA&M and its 180-day clock.
- Permanent alternatives to a NIST SP 800-171 requirement need DoD CIO adjudication under DFARS 252.204-7012.
If your firm does design, engineering or construction work for DoD, some security controls will break after you put them in place. A patch knocks a FIPS module out of validation, or a survey instrument cannot run modern authentication. How you record that gap, as a temporary deficiency or a CMMC enduring exception, decides whether it costs you points on your SPRS score.
What is the difference between a temporary deficiency and an enduring exception?
A temporary deficiency is a gap you can fix and are already fixing. An enduring exception is a gap you cannot fix. CMMC uses these two categories, both defined in 32 CFR 170.4, in place of the word deviation, and each has its own paperwork.
A temporary deficiency is "a condition where remediation of a discovered deficiency is feasible, and a known fix is available or is in process." The rule says it arises after implementation, not during a rollout that is still in progress, and that there is no standard duration. Its own example is FIPS-validated cryptography that needs a patch, where the patched version is no longer the validated version.
An enduring exception is "a special circumstance or system where remediation and full compliance with CMMC security requirements is not feasible." The rule lists systems that must replicate fielded configurations, medical devices, test equipment, operational technology and IoT devices, and notes that specialized assets and government furnished equipment may qualify.
For an architecture, engineering or construction firm on defense work, that distinction matters. A server patch that breaks a FIPS module next week is a temporary deficiency. A legacy plotter controller or survey instrument that cannot run modern authentication may be an enduring exception. A requirement you never implemented is neither: it is simply NOT MET.
How does an assessor score a documented deviation?
A properly documented deviation is scored MET. Under 32 CFR 170.24(b)(1), enduring exceptions "when described, along with any mitigations, in the system security plan shall be assessed as MET." Temporary deficiencies that are appropriately addressed in operational plans of action, with deficiency reviews and progress toward correction, are also assessed as MET.
The documentation is what earns the score. The same section says a MET finding needs final evidence, and lists drafts, working papers and unapproved policies as unacceptable. A deviation that lives only in a technician's head, a ticket comment or an unsigned spreadsheet gives the assessor nothing to accept. The DoD CMMC Assessment Guide, Level 2 applies the same treatment.
This applies to the Level 2 self-assessments that remain in effect today. The Department of War suspended CMMC Phase 2 in July 2026, so C3PAO certification is not being required in solicitations, but self-assessments, SPRS scores and annual affirmations continue. Our summary of what still applies during the suspension covers the details.
Is an operational plan of action the same as a POA&M?
No. An operational plan of action is an ongoing internal record you keep under NIST SP 800-171 requirement 3.12.2. A POA&M is tied to a specific assessment and lists NOT MET requirements that must be closed within 180 days. Mixing them up is one of the easier ways to lose points.
Requirement 3.12.2 in NIST SP 800-171 Rev. 2 asks contractors to develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities. Section 170.4 calls the result the operational plan of action and lets the organization choose its format: a document, spreadsheet or database. It sets no remediation timeline.
The assessment POA&M is stricter. Under 32 CFR 170.21, only 1-point requirements, plus encryption that is in place but not FIPS-validated, can go on it, the score must be at least 88 of 110, and a closeout assessment must confirm the fixes within 180 days. Our article on conditional status and the 180-day clock walks through those limits. A temporary deficiency logged correctly in the operational plan of action never needs to reach the POA&M at all.
What should each deviation record include?
Each record should let an assessor see what broke, why, what protects CUI in the meantime, and when it will be fixed. The rule leaves the format to you, so consistency matters more than the tool. A workable entry includes:
- The affected NIST SP 800-171 requirement number and the assets involved.
- Whether it is a temporary deficiency or an enduring exception, and the reason for that call.
- The date it was discovered and who discovered it.
- Interim mitigations, such as network isolation, extra monitoring or restricted user access.
- For a temporary deficiency, the known fix, an owner, target milestones and the date of each review.
- For an enduring exception, the matching description in the system security plan.
- Approval by a named person with authority to accept the risk, and the closure date and evidence when it ends.
Reviews are part of the standard. Section 170.24 expects the operational plan of action to show deficiency reviews and progress toward correction, so a record created in March and untouched by October invites questions.
When does a deviation need a system security plan update?
An enduring exception always does, because section 170.4 requires it to be documented in the system security plan. A temporary deficiency normally stays in the operational plan of action, unless the fix changes how you meet the requirement. Then the plan itself needs updating.
Requirement 3.12.4 asks contractors to develop, document and periodically update a system security plan that describes the system boundary, environment and how each requirement is implemented. If a deviation moves a device off the CUI network, adds a jump host or swaps an authentication method, the plan should say so. Our guide to writing a system security plan an assessor can follow covers structure.
Some changes are not yours to approve. Under DFARS 252.204-7012(b)(2)(ii)(B), requests to vary from NIST SP 800-171 go in writing to the contracting officer for consideration by the DoD CIO. The clause lets a contractor set a requirement aside only once an authorized DoD CIO representative has adjudicated it nonapplicable or accepted an alternative, but equally effective, security measure in its place. A permanent substitute you designed yourself is not an approved variance.
What should you do this quarter?
A short review now puts your deviation records in shape before the next self-assessment or annual affirmation:
- Pull every open exception, risk acceptance and "temporary" workaround from tickets, email and spreadsheets into one operational plan of action.
- Sort each item: temporary deficiency, enduring exception, or a requirement that was never implemented and belongs on a remediation plan.
- Add interim mitigations and a named owner to every entry that lacks them.
- Write each enduring exception into the system security plan, with its mitigations.
- Set a recurring review, monthly or quarterly, and record the date and outcome each time.
- List any permanent alternative controls and decide whether a DFARS 7012 variance request is needed.
- Confirm the SPRS score and the senior official's annual affirmation still reflect what the records show.
How s90 helps
s90 keeps deviation records as part of a client's risk register, so each temporary deficiency and enduring exception has an owner, mitigations, review dates and closure evidence in one place. Our Technology Posture Report shows where those items stand, and we update the system security plan when a change affects it. If you want help sorting your current exceptions before your next self-assessment, we are happy to talk.


