POA&M Template and What You Can Actually Defer

A Plan of Action and Milestones records what you have not implemented, what you are going to do about it, and when. It is the companion to the System Security Plan, which records what you have.

Most guidance on POA&Ms explains the format. The format is the easy part. What catches organisations out is eligibility — the rules governing what may lawfully sit on one — because a plan containing ineligible items does not buy you the time you think it does.

Start with what you cannot defer

Under 32 CFR 170.21 the general rule is that only one-point requirements may be deferred to a POA&M. That is a much narrower allowance than most people assume, and it means the majority of your gaps have to be closed rather than planned.

There is a single exception. 3.13.11 may sit on a POA&M where encryption is deployed but not FIPS-validated — the partial-credit condition. Not where encryption is absent.

And six requirements can never be deferred, whatever their weight:

3.1.20 · 3.1.22 · 3.12.4 · 3.10.3 · 3.10.4 · 3.10.5

Two of those are worth calling out. 3.12.4 is the System Security Plan — unscored, undeferrable, and its absence voids the assessment entirely. Three of the others are physical protection requirements, which organisations routinely leave until last on the assumption that locks are simpler than logging.

The 88-point threshold

A POA&M is only useful in combination with conditional status, and conditional status requires a score of at least 88 of 110.

Composition matters as much as the total. A score of 92 with a five-point requirement outstanding does not qualify, because that requirement cannot be deferred. A score of 89 with only one-pointers outstanding does. Check eligibility before celebrating a number. See how scoring works.

What each entry needs

Six fields, and the last two are where plans fall apart:

• Requirement — the identifier, e.g. 3.8.8.
• Weakness — what specifically is not implemented, stated at objective level rather than as a restatement of the requirement.
• Point value — and therefore whether it is eligible at all.
• Remediation — the actual action, named. “Implement control” is not a plan.
• Owner — a named role who can be asked about it.
• Completion date — inside the 180 days, and derived from lead times rather than from wishful arithmetic.

The 180-day clock

It starts on award of conditional status and does not pause. That has a practical consequence worth planning around: anything with procurement, vendor onboarding or hardware lead time should be started before the plan is submitted, not after.

A POA&M written on the assumption that six months is a long time tends to meet a twelve-week purchasing cycle in month four.

How a POA&M relates to your SSP

They answer different questions and should not be merged. The System Security Plan describes the environment and how each of the 110 requirements is met in it. The POA&M lists the ones that are not, with a plan.

The failure mode to avoid is an SSP that quietly describes intended rather than implemented controls, with no corresponding POA&M entry. That is not an administrative tidiness issue: it is an inaccurate representation of your security posture, and it is the kind of discrepancy that turns a compliance gap into a False Claims Act question.

If the control is not in place, say so in the POA&M and keep the SSP truthful.

A minimal structure that works

A spreadsheet is fine. What matters is that every row carries the six fields above, that eligibility has been checked before anything is added, and that the owner and date are real. Sort by point value and by completion date, so the items that cannot be deferred are visibly separated from the ones that can.

Review it monthly rather than at day 170. A POA&M that has not been touched since it was written is evidence of a process that is not running, and an assessor will read it that way.