What Do I Write for Safeguards We Have Not Implemented Yet?

You have a safeguard that is not done yet. Your SSP (System Security Plan) must say so, honestly.

The honest answer is short. Write "not implemented" in the SSP. Describe the current state in plain words. Then create a POA&M entry that says what you will do and by when. POA&M stands for Plan of Action and Milestones. NIST (National Institute of Standards and Technology) expects exactly this. The standard says the SSP describes how requirements are met, or how you plan to meet them. It says the POA&M describes how unimplemented requirements will be met. (NIST SP 800-171 Rev. 2)

What the SSP entry should contain

For each unimplemented practice, write these five items.

1. Status. Say "not implemented" or "planned." Never write "implemented" for something that is not.
2. Current state. Say what exists today. One honest sentence is enough.
3. Gap. Say what is missing, in concrete terms.
4. POA&M reference. Point to the POA&M entry number for this practice.
5. Planned date. Give the date you will finish, and keep it real.

NIST requires the SSP to be updated on a schedule you define. (NIST SP 800-171 Rev. 2, requirement 3.12.4) When the practice is finished, change the status and update the entry.

Worked example: a POA&M entry

Here is a real entry for multifactor authentication. It is only partly done. MFA (multifactor authentication) means two or more different sign-in factors.

• Practice: require MFA for every account that can reach CUI.
• Current state: MFA is on for admin accounts only. Regular user accounts still use passwords alone.
• Planned action: enforce MFA through conditional access policies for all accounts, then spot check sign in logs.
• Owner: the identity team lead.
• Planned completion: eight weeks from the assessment date.
• Milestones:
• Policy written by week two.
• Test group rollout by week four.
• Full rollout by week six.
• Log review by week eight.

Which gaps block a CMMC Level 2 assessment

Not every gap can ride on a POA&M. The CMMC (Cybersecurity Maturity Model Certification) rule sets hard limits.

Six practices can never go on a POA&M. They must be fully met at assessment time. Two concern CUI on external connections and in public information. One is the SSP itself. Three concern physical access: visitor escorts, access logs, and access management. (32 CFR Part 170, section 170.21)

Notice one thing. The SSP itself is on that list. You must have an SSP at assessment time. An SSP that honestly lists gaps is fine. An SSP that does not exist is a failure.

Also blocked: any practice worth more than one point cannot go on a POA&M. Most practices are worth one point. A few are worth three or five. Those heavy ones must be done before the assessment. FIPS stands for Federal Information Processing Standards: the government list of approved encryption. CUI encryption is the one exception. It may go on a POA&M if encryption is in use but not FIPS validated.

The math also matters. Your score divided by the 110 Level 2 requirements must be at least 0.8. That means 88 of 110 points. If you fall below that line, a POA&M does not save you. (32 CFR Part 170, section 170.21)

A POA&M that passes gives you Conditional Level 2 status. You then have 180 days from that date to finish every item. A C3PAO (CMMC Third-Party Assessment Organization) runs a closeout assessment on just those items. Miss the 180 days, and the conditional status expires. (32 CFR Part 170, section 170.21)

How assessors score unmet practices

An assessor reads the SSP and checks each practice against evidence. If a practice is not implemented and has no POA&M, it scores NOT MET. If it is on a valid POA&M, it still scores NOT MET. But the POA&M keeps the assessment alive under the rules above. DoD (Department of Defense) says a Level 2 POA&M can hold up to 22 one-point practices. The six banned practices are excluded from that count. (CMMC final rule, response to comments)

Assessors check three things about your honesty.

• Does the SSP match reality? A practice marked "implemented" with no evidence is a problem.
• Is the POA&M entry specific? "Fix later" is not a plan.
• Are the dates believable? An entry that never moves tells the assessor the plan is theater.

Three mistakes that hurt

1. Marking a practice "implemented" when it is only planned. The assessor will find it. Now they doubt everything else.
2. Writing dates you already know are fake. Pick a date you can hit.
3. Leaving gaps out of the POA&M entirely. An undocumented gap is a surprise. A documented gap is a plan.

Keeping it current

Requirement 3.12.4 says to review and update the SSP on a schedule you define. When a POA&M item is finished, update both documents the same week. An SSP that lags the POA&M confuses the assessor.

Where tooling helps

The safest approach is to let evidence write the SSP for you. PolicyCortex reads live Azure configuration with 33 collectors. It produces SSP, SAR, and POA&M output from the collected evidence. SAR stands for Security Assessment Report. It re-verifies everything after you finish remediation. Strongest in commercial Azure, and AWS is covered. If a practice is not implemented, the output shows it that way. Your SSP then never claims what the evidence cannot prove.

See how it works

Sources

• NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r2.pdf
• NIST SP 800-171A Rev. 2, Assessing CUI Requirements: https://csrc.nist.gov/pubs/sp/800/171/a/final
• 32 CFR Part 170, CMMC Program final rule, section 170.21: https://www.federalregister.gov/documents/2024/10/15/2024-22905/cybersecurity-maturity-model-certification-cmmc-program
• 32 CFR Part 170 on eCFR: https://www.ecfr.gov/current/title-32/subtitle-A/chapter-VI/subchapter-B/part-170