Trackr.Live The landing site for Trackr Services
§ Trackr.Live

PM — Program Management

Program Management is the control family that does not behave like a control family. Every other family in NIST SP 800-53 gets allocated to a system baseline by impact level: FIPS 199 sets the categorization, SP 800-53B turns that into a Low, Moderate, or High starting set, and the controls land in a specific system’s SSP. PM does none of that. The PM controls are organization-wide, deployed once at the enterprise tier, and they apply regardless of whether the system in front of you is Low or High. In 800-53B they sit outside the Low/Moderate/High baseline tables entirely. You will not find PM-9 in the Moderate baseline because PM-9 was never a per-system control to begin with.

Schematic of an organizational tier sitting above several system boundaries, a single set of program controls feeding down into each system as inherited common controls.

That single fact reorders everything about how this family gets implemented, assessed, and (mostly) ignored. PM is owned by the program office, the CISO or Senior Agency Information Security Officer, the Senior Agency Official for Privacy on the privacy half, the risk executive function on the risk half. Not the system team. An ISSO standing up a new system inherits the PM controls as common controls from the org; they do not write a PM-9 risk management strategy for their box, because the strategy is an enterprise artifact that already exists (or is supposed to). The 800-37 language for this is the common control provider, and PM is the canonical case: assessed once at the organizational level, inherited by every system underneath it.

What’s in the family, and what Rev 5 did to it

PM spans PM-1 through PM-32 in Rev 5, and unlike AC there are almost no withdrawals to trip over. The catch is the opposite problem. Rev 5 nearly doubled the family from the Rev 4 set, bolting on an entire privacy program block and several risk-and-supply-chain strategy controls that did not exist before. If your documentation still describes PM as ending around PM-11, you are reading a Rev 4 artifact, and the rename traps in that range are nasty.

The security-program core carried over from Rev 4, mostly with new names:

  • PM-1, Information Security Program Plan. The org-level program plan. Rev 5 carved the privacy program out of it into the new PM-18, so PM-1 is now narrower than the Rev 4 version that tried to cover both.
  • PM-2, Information Security Program Leadership Role. This is the CISO/SISO role. Rev 4 called it “Senior Information Security Officer”; an SSP or policy still using that title is quoting the old catalog.
  • PM-3, Information Security and Privacy Resources. The budget line. Rev 5 added privacy and tied it to the funding that actually backs the POA&M remediation nobody scheduled money for.
  • PM-4, Plan of Action and Milestones Process. The org-level POA&M process, which is a different animal from the per-system POA&M (that’s CA-5). More on this collision below, because it causes real assessment confusion.
  • PM-5, System Inventory. Renamed from “Information System Inventory.” The org-wide inventory of systems, which is not the same artifact as the CM-8 component inventory inside any one system.
  • PM-6, PM-7, PM-8 cover measures of performance, enterprise architecture (ties to SA-8), and the critical infrastructure plan.

Then the two controls people most often miscite:

  • PM-9 is Risk Management Strategy, the same title it carried in Rev 4. This is the Tier 1 strategy that feeds RA-3 system risk assessments and underwrites the 800-37 Prepare step.
  • PM-11 is Mission and Business Process Definition, the same control it was in Rev 4 (Rev 4 spelled it “Mission/Business Process Definition”). The continuous-monitoring control people sometimes expect here was never PM-11: in Rev 4 the continuous-monitoring control was CA-7, and Rev 5 added the org-level continuous monitoring strategy as the brand-new PM-31. So PM-11 is mission and business processes, full stop.

The Rev 5 additions are where the family grew teeth. The privacy program block runs PM-18 through PM-27: PM-18 Privacy Program Plan (the privacy companion to PM-1), PM-19 Privacy Program Leadership Role (the SAOP), then dissemination, accounting of disclosures, PII quality management, the PM-23 data governance body, the PM-24 data integrity board, PII minimization in testing, complaint management, and privacy reporting. PM-17 protects controlled unclassified information on external systems. PM-28 is Risk Framing and PM-29 is Risk Management Program Leadership Roles, the risk executive function. PM-30 is the org Supply Chain Risk Management Strategy, the thing the per-system SR family implements downward. PM-31 is the org continuous monitoring strategy per SP 800-137. PM-32 is Purposing. PM-12 insider threat, PM-13 workforce, PM-14 testing/training/monitoring, PM-15 groups and associations, and PM-16 threat awareness round out the security side.

How PM maps onto the RMF process

Because PM is the org tier, it lines up most cleanly with Prepare, the step 800-37 Rev 2 added precisely to capture organization-level groundwork. Risk framing is PM-28. Risk strategy is PM-9. Mission and business process definition is PM-11. Enterprise architecture is PM-7. Those Prepare tasks are not abstractions floating above the catalog; they have control IDs, and the control IDs live in PM. Then PM-30 feeds the Select-and-implement work of the SR family on each system, and PM-31 feeds Monitor and the per-system CA-7 continuous monitoring. A system team doing ongoing authorization is, whether they frame it this way or not, executing against an org PM-31 strategy that either exists and is usable or exists as a binder.

Deeper: why PM is a common-control family, not a system one.
800-37 splits control responsibility three ways. System-specific controls are implemented and owned inside one boundary. Hybrid controls are part org, part system (the org provides a baseline config, the system tailors it). Common controls are provided once by a common control provider and inherited by everyone downstream. PM is almost entirely the third kind. That is why it has no Low/Moderate/High allocation in 800-53B: a baseline tells a system which controls to implement, and a system implements none of PM. The risk is structural. Common controls get assessed once, against the provider, and then every system underneath cites the inheritance without re-testing it. So the assurance for an entire family rests on a single org-tier assessment that is easy to wave through, because the assessor in front of a system has a system to grade and assumes the program office handled the program. When the program office assumes the systems exercise what it wrote, the control is owned by no one and reported green by everyone.

Control Tier it lives at What an assessor actually checks
PM-2 Org A named, current CISO/SISO with the authority and the appointment letter, not a vacant box on an org chart.
PM-4 Org One org-level POA&M process exists and is followed; sampled per-system POA&Ms (CA-5) actually feed it.
PM-5 Org The system inventory reconciles against the actual list of authorized boundaries and against CM-8 component counts.
PM-9 Org The risk strategy is referenced by real RA-3 assessments, not just shelved. Does any system cite it?
PM-18/PM-19 Org A real Privacy Program Plan and a named SAOP, distinct from the security program and the CISO.
PM-30 Org The SCRM strategy that SR-1 and the per-system SR controls claim to inherit actually says something.
PM-31 Org The ISCM strategy per 800-137 that makes ongoing authorization defensible, or doesn’t.

Treat “tier” as the whole point of that table. None of these has a “first live at Moderate” answer, because none of them is baseline-allocated. They are on, org-wide, or they are a finding.

Where it goes brittle

The PM-4 / CA-5 POA&M collision. This one confuses assessors and authors alike. PM-4 is the organizational POA&M process: how POA&Ms are created, prioritized, funded, and reported up. CA-5 is the actual POA&M for a given system. They are different controls at different tiers, and PM-4 is assessed once at the org/common-control-provider level and inherited by every system. The failure mode is a system team writing PM-4 language into their SSP as if they owned it, or an org that has a tidy PM-4 process document and a stack of per-system CA-5 POA&Ms that the process never actually touches. The document describes a workflow; the workflow isn’t running. An assessor who pulls three system POA&Ms and traces them up into the org process will find the seam.

PM-5 inventory drift. The system inventory is supposed to enumerate authorized systems. In practice it drifts from the ATO boundary list and from the CM-8 component inventory underneath each system, because three different teams maintain three different spreadsheets and none of them is the source of truth. New systems get stood up and authorized without making it onto the PM-5 list for a quarter. Reconcile PM-5 against the actual ATO register and against CM-8 counts; the gaps are where shadow systems live.

Strategy controls as shelfware. Here is where I’ll plant a flag, and it is contestable: PM is the least-assessed and most rubber-stamped family in the catalog, precisely because no single system owns it. Every system claims clean inheritance of PM-9, PM-30, PM-31. The org nods. And because the controls are common, no individual assessment digs into them, so they rot at the org tier while every SSP underneath reports green. A risk management strategy that no RA-3 assessment ever references is a binder, not a strategy. An ISCM strategy that doesn’t actually drive what gets monitored on which cadence is a PM-31 finding that never gets written because the system assessor assumes the org handled it and the org assumes the systems exercise it. The way you catch shelfware is to test it bottom-up: pick a real RA-3 risk assessment and ask which PM-9 strategy framed it. If the answer is a blank look, the control is decorative.

Leadership roles with no real owner. PM-2 and PM-19 look like paperwork (name a CISO, name a SAOP) but they are load-bearing for the whole common-control model. If the leadership role is vacant or nominal, the common controls underneath it have no actual owner, and “inherited from the org program” becomes inheritance from nobody. That is the quiet way an entire family of common controls goes unowned while every system reports it as satisfied.

Artifacts

PM evidence lives at the org tier: the program plans (PM-1, PM-18), the risk strategy and framing documents (PM-9, PM-28), the org POA&M process (PM-4), the system inventory (PM-5), the SCRM strategy (PM-30), and the ISCM strategy (PM-31). These get assessed against the organization, recorded as common-control implementations, and inherited downward. The fastest way to fail a PM assessment is to treat these as a documentation exercise that exists to be cited rather than used. The catalog text is short on PM. The org either runs these programs or it has paper that says it does, and an assessor who tests them bottom-up from a real system can tell the difference inside an afternoon.

Sources

Adjacent material on this site