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

PL — Planning

Planning is the family that holds the rest of the catalog together, and almost nobody reads it that way. PL is where the System Security and Privacy Plan lives. That plan, PL-2, is the document every other RMF artifact points back to: the SAR assesses against it, the POA&M tracks deltas from it, the ATO package is built around it, and the assessor’s first move is to open it and start comparing the prose to the system. PL also carries the two controls that decide which controls you even have. PL-10 picks your baseline and PL-11 tailors it. So PL is small in control count and large in consequence, and the common mistake is treating it as administrative paperwork instead of the spine it actually is.

A system security plan rendered as a central document with reference lines radiating out to an assessment report, a POA&M, an architecture diagram, and a selected control baseline.

One thing to clear up before anything else, because the Rev 4 confusion is everywhere: PL is not contingency planning. Contingency planning is the CP family. If you find a page or an old SSP citing “PL-3, Contingency Plans” as a live control, that is wrong twice over. PL-3 was withdrawn well before Rev 5 (its content folded into PL-2 back in Rev 3), and contingency planning never lived in PL to begin with. Security categorization isn’t PL either; that’s RA-2 driving off FIPS 199. PL owns the plan that describes the system and the mechanics of selecting controls for it. Keep that boundary clean or the whole family reads as mush.

Where PL sits in the RMF

The RMF is the SP 800-37 process: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. PL touches more of that loop than most families. PL-10 and PL-11 are literally the Select step in control form: PL-10 selects the SP 800-53B baseline that matches your impact level, PL-11 documents the tailoring applied to it. PL-2 is the running artifact for Implement, where every selected control gets a narrative describing how it works on this system, and it’s graded at Assess. Then it rides into Monitor, because the SSP is supposed to be a living document and the plan that drifts from the system is the one an assessor finds the holes in.

So “we’re doing PL for the RMF” usually means two different jobs wearing one family code. One is governance plumbing (policy, rules of behavior, architecture documentation). The other is the selection-and-tailoring machinery that produces the control set itself. PL-10 and PL-11 are the more consequential half and the half most pages skip.

What’s live in Rev 5, and what got withdrawn

PL spans PL-1 through PL-11, but that range is not a clean list. Several numbers in it were withdrawn back in Rev 3 and Rev 4, so they never appeared as live controls in the Rev 5 catalog at all.

  • PL-1, Policy and Procedures. The family -1. Org-level planning policy plus the procedures that implement it. Baseline-allocated at Low, Moderate, and High, and the first thing pulled in an assessment because everything else inherits its existence from here.
  • PL-2, System Security and Privacy Plans. This is the SSP. The spine. Rev 5 merged the old separate privacy plan into it, which is why the title now reads “and Privacy.” It absorbed withdrawn PL-3 (the old plan-update control). Baseline-allocated across Low/Moderate/High. More below, because this one carries the family.
  • PL-4, Rules of Behavior. What users agree to before they get access. PL-4(1) adds restrictions on social media and external-site posting. Ties straight to AC-8 (the system-use notification banner), to the AT family (the training that teaches the rules), and to PS (the personnel agreements that make them enforceable). Baseline-allocated at Low and up.
  • PL-7, Concept of Operations. The ConOps: how the system is meant to be used and secured across its lifecycle. Not selected in the standard Low/Moderate/High baselines; if your program carries it, an overlay or the AO asked for it.
  • PL-8, Security and Privacy Architectures. The documented architecture: where controls sit, how enclaves divide, what the data flows look like. Ties to SA-8 (security engineering principles), SA-17 (developer architecture), and the SC family it’s supposed to describe. Baseline-allocated at Moderate and High.
  • PL-9, Central Management. An org-level construct for managing controls centrally as common controls. Not in the standard baselines; a common-control-provider concept more than a per-system one.
  • PL-10, Baseline Selection. Pick the SP 800-53B baseline (Low, Moderate, or High) that matches the categorization. Baseline-allocated everywhere because every system has to do it.
  • PL-11, Baseline Tailoring. The documented add, remove, and adjust against the selected baseline, with rationale the AO will accept. Also baseline-allocated across the board.

And the ones that are gone, stated plainly so nobody resurrects them. None of these is a Rev 5 casualty; all three were already withdrawn in the Rev 3 and Rev 4 catalogs, so Rev 5 simply never carried them. PL-3 (Security Plan Update), withdrawn into PL-2 back in Rev 3. PL-5 (Privacy Impact Assessment), withdrawn in Rev 4; in Rev 5 the privacy-risk assessment work it covered lives under RA-8, which is the functional successor, plus the broader privacy program. PL-6 (Security-Related Activity Planning), withdrawn in Rev 4 into PM-9, not into PL-2. An SSP citing any of those three by number is quoting a pre-Rev-5 catalog someone forgot to retire.

PL-2 is the SSP

Worth saying again because it’s the whole point of the family: PL-2 is the system security and privacy plan. Not a plan to make a plan. The artifact. When the SAR says “the narrative claims X but the system does Y,” the narrative it’s reading is PL-2 content. When the POA&M lists a deficiency, that’s a gap between PL-2 and reality. The ATO letter authorizes the system as described in PL-2. Every cross-reference in the package resolves here.

Which means the dominant failure mode is the same one that sinks AC implementations: an SSP that restates the catalog instead of describing the system. If your PL-2 narrative for, say, AC-2 reads like the 800-53 control text with the system name find-replaced in, it’s too generic to pass. The assessor has read the catalog. They want to know what this system does. I’ll plant a flag here: the SSP that paraphrases the control catalog back at the assessor is the single most common reason control implementations come back Other Than Satisfied, and it’s worse in PL than anywhere because PL-2 is the document where that habit shows up everywhere at once.

Control Typical first live at What an assessor actually checks
PL-1 Low Planning policy exists, is current, has an owner and a review date. The procedures actually map to how planning happens.
PL-2 Low The SSP describes this system in specifics, not catalog paraphrase. Control narratives match the as-built environment, and the diagrams aren’t stale.
PL-4 Low Signed rules of behavior on file for current users, dated, and tied to the AC-8 banner language and AT training records.
PL-8 Moderate The architecture document matches the deployed system: enclaves, boundaries, data flows. Compared against the actual network and the SA-17 developer artifacts.
PL-10 Low The selected baseline matches the FIPS 199 categorization. Low system on a Low baseline, no quiet downgrade.
PL-11 Low Every tailoring decision has a documented rationale. N/A claims are defensible (no wireless, so AC-18 out), not convenience removals.

Treat “first live at” as directional. Overlays move things, and PL-7 and PL-9 sit outside the standard baselines entirely, so they show up only when CNSSI 1253, a FedRAMP overlay, or the AO drags them in.

Selection and tailoring: PL-10 and PL-11

This is the part most PL writeups never reach. The baselines don’t live in 800-53 anymore; Rev 5 moved them to SP 800-53B. FIPS 199 sets categorization, FIPS 200 sets the minimum-security floor, and 800-53B turns the impact level into a starting control set. PL-10 selects that baseline. PL-11 documents how you tailored it, with reasons.

Deeper: baseline selection and tailoring are not the same act, and conflating them gets caught.
PL-10 is selection: the categorization is Moderate, so the Moderate baseline applies. Mechanical, defensible, not really negotiable. PL-11 is tailoring: the documented act of adding, removing, or adjusting controls and enhancements against that baseline. Removing a control because it genuinely doesn’t apply (no wireless segment, so AC-18 is N/A) is clean tailoring. Removing one because it’s noisy or inconvenient is not, and the assessor can’t tell a deliberate decision from a forgotten control unless PL-11 shows the math. Overlays push the other direction entirely: FedRAMP Moderate pulls in enhancements above the bare 800-53B Moderate set, and a national-security system under CNSSI 1253 may carry a different selection for the same impact level. The chain has to be legible in the plan, categorization to baseline to overlay to final control set, or every N/A in the SSP looks like a gap instead of a decision.

PL-10/PL-11 lean on the RA categorization to even start, and they produce the control set every other family’s PL-2 narratives describe. Get the categorization wrong, PL-10 selects the wrong baseline, and everything downstream inherits the error.

Where the family goes brittle

PL-8 architecture-as-documented versus as-built. The PL failure I’d flag hardest. The architecture document is accurate the day it’s drawn and decays from there. A new load balancer goes in, a subnet gets re-segmented, a service moves to a managed offering, and the PL-8 diagram still shows the topology from the last authorization. An assessor walking the actual network against the doc finds the gap, and the gap is worse than no diagram, because a wrong diagram affirmatively claims the system is something it isn’t. The diagram is only worth keeping if you re-baseline it when the environment changes, and most programs have no trigger that forces that.

PL-7 ConOps as shelfware. Honest opinion: on most systems the Concept of Operations gets written once for the initial package and never opened again. It’s not in the standard baselines, so it exists only when an overlay or AO demands it, and when it does it’s frequently a generic document that doesn’t describe operational reality. If you’re required to carry PL-7, the useful version describes how the system is actually run and defended, not a template with the name pasted in.

PL-4 rules nobody re-signs. Rules of behavior get signed at onboarding, then the role changes, the rules get updated, and the signed copy on file describes a different set of obligations than the current ones. AT-2 training says one thing, the PL-4 form says another, the AC-8 banner says a third. Assessors sample current users and look for a signed, dated, current ROB. Mismatches across PL-4, AT, and AC-8 are an easy finding, since all three are supposed to say the same thing.

PL-2 stale because the system moved. The plan describes the system at last authorization; the system changed under continuous monitoring; nobody updated the narrative. That’s why the assessor reads PL-2 against the running system instead of taking it at face value, and why a plan that’s clearly current beats one that’s clearly a year old even when both are technically complete.

Artifacts

PL produces the document the rest of the framework orbits. The SSP (PL-2) carries the control narratives and the system description. The SAR is the assessor’s verdict on whether those narratives hold. The POA&M captures the deltas. The PL-11 tailoring record lets the AO distinguish a deliberate control decision from an omission, and the PL-8 architecture lets an assessor check the narrative against the shape of the actual system. If the plan describes a system that no longer exists, none of the downstream artifacts can be trusted, because they all assess against the plan.

Sources

Adjacent material on this site