PL-10: Baseline Selection

PL-10 is deceptively short: “Select a control baseline for the system.” ¹ In practice, it is the hinge point between intent (“we align to NIST”) and an assessable control program (“these are the exact controls and parameters we committed to implement for this system”). Examiners and assessors rarely fail teams for picking the “wrong” baseline; they fail teams for picking no baseline, picking multiple baselines without clarity, or being unable to show how the baseline decision drove implementation, tailoring, and test scope.

This page translates PL-10 into requirement-level execution steps you can assign to an owner and operationalize in your GRC workflow. The emphasis is on artifacts and traceability: a baseline selection record, system scoping boundaries, tailoring decisions, and a clean link into your System Security Plan (SSP), assessment plan, and continuous monitoring. If you run multiple systems, PL-10 is also how you avoid control drift across environments and acquisitions, because it forces an explicit starting point for each authorization boundary.

Regulatory text

Requirement (PL-10): “Select a control baseline for the system.” ¹

Operator meaning: You must choose a defined set of NIST SP 800-53 controls as the starting point for the system’s security and privacy program, and you must be able to prove which baseline was selected for that specific system. The baseline selection has to be explicit enough that an assessor can (a) understand the control scope, (b) confirm the baseline is the input to tailoring, and (c) trace implemented controls back to that baseline. ²

Plain-English interpretation

• A “baseline” is your default control set for the system.
• PL-10 requires a recorded decision: which baseline applies to this system.
• The baseline is not your final control set. You will tailor it later, but PL-10 is the required starting line. ²

Who it applies to

PL-10 applies whenever you are using NIST SP 800-53 as your control framework for a system, especially in these common contexts:

• Federal information systems that must implement NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is imposed by contract, assessment regime, or authorizing official expectations. ²

Operationally, PL-10 is system-scoped. If you have multiple authorization boundaries (or multiple materially different environments), you should expect to select and document baselines per boundary so scope does not blur during assessment.

What you actually need to do (step-by-step)

Step 1: Assign ownership and define the decision forum

1. Name a control owner for PL-10 (often the System Owner, ISSO, or GRC lead for the system).
2. Define who approves baseline selection (for example: Authorizing Official delegate, security governance committee, or CISO designee).
3. Decide where the record lives (GRC tool record, SSP appendix, or controlled repository).
   This maps directly to the recommended operational control: map PL-10 to an owner, procedure, and recurring artifacts. ¹

Step 2: Lock the system boundary and description first

Baseline selection is only defensible if the system is clearly defined.

1. Confirm the system boundary (what’s in scope, what’s external).
2. Confirm system purpose, major components, and external dependencies.
3. Identify key data types handled and where they flow.
   If the boundary changes later, baseline selection may need re-validation; treat that as a change-management trigger.

Step 3: Choose the baseline and document the rationale

1. Select the baseline your program uses for that system (for example, the baseline your organization uses for the system’s impact/criticality category within your NIST SP 800-53 program).
2. Record rationale in plain language:
   • Why this baseline fits the system’s risk and mission.
   • Any constraints (contractual, hosting model, shared services).
3. Record the selection date and approver and link to the system record.

What auditors look for: a single, unambiguous answer to “What baseline did you select for this system?” plus enough context to show the choice was intentional.

Step 4: Connect baseline selection to tailoring and implementation

PL-10 does not stop at “we picked one.” Your next artifacts must reference the baseline.

1. In your SSP (or equivalent), add:
   • Baseline chosen
   • Tailoring approach (how you decide adds/removals/parameter values)
2. Build or update the control implementation matrix:
   • Baseline control list as the starting set
   • Implementation status per control (implemented/inherited/not applicable)
   • Inheritance statements for shared services
     This is where teams often fail: they pick a baseline, then implement controls ad hoc without tying back to the baseline list.

Step 5: Make it assessable (test scope and evidence cadence)

1. Ensure your assessment plan/test procedures reference the baseline-derived control set.
2. Define recurring evidence expectations for baseline-related governance:
   • Baseline selection record stays current
   • Tailoring decisions are reviewed when the system changes
     Even though PL-10 is a planning control, assessors expect operational evidence that the baseline selection is maintained, not abandoned after initial paperwork. ²

Step 6: Operationalize in your GRC workflow (what “good” looks like)

A practical way to run PL-10 in Daydream (or any GRC system) is to create a single workflow item per system:

• Task: “Baseline selection”
• Fields: baseline name, rationale, approver, approval date, links to SSP section and control matrix
• Evidence: signed decision record + exported baseline control list + tailoring log reference
  This directly implements the recommended control mapping and recurring evidence approach. ¹

Required evidence and artifacts to retain

Keep artifacts that prove baseline selection happened and is connected to the system’s control scope:

1. Baseline Selection Record (template-friendly):
   • System name/identifier
   • Baseline selected
   • Rationale
   • Approver + approval method (signature, ticket approval, meeting minutes)
   • Effective date and review trigger conditions
2. System boundary documentation
   • Architecture diagram or boundary statement
   • Inventory references (components, hosted services)
3. SSP section or appendix stating baseline and how it is tailored
4. Control implementation matrix showing baseline controls as the starting point
5. Tailoring log (adds/removals/parameter choices) linked back to baseline
6. Change management linkage
   • Evidence that major changes prompt baseline re-validation (change tickets, review checklist)

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me the selected baseline for System X and who approved it.”
  Hangup: teams can’t produce approval evidence.
• “Where is the baseline reflected in your SSP and control matrix?”
  Hangup: baseline is mentioned in a policy, not in system documentation.
• “How do you know your assessment scope matches your baseline plus tailoring?”
  Hangup: assessment plan is built from a generic checklist, not the system’s baseline set.
• “What triggers re-evaluating the baseline?”
  Hangup: no linkage to change management, so baseline becomes stale.

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating baseline selection as a one-line SSP statement

Fix: Require a discrete baseline selection record with approver and date, then cross-reference it in the SSP and control matrix.

Mistake 2: Multiple baselines applied to the same system without clarity

Fix: Declare one primary baseline per authorization boundary, then document inherited/shared controls separately in the control matrix.

Mistake 3: No traceability from baseline to testing

Fix: Build the assessment scope from the baseline-derived control list plus tailoring outcomes, and retain the exported list as evidence.

Mistake 4: Baseline chosen before boundary is understood

Fix: Gate baseline selection on a minimum system description package (boundary statement + major components + key data flows).

Risk implications (why PL-10 failures matter)

PL-10 gaps create predictable downstream failures:

• Under-scoped controls: You miss required safeguards because no one agreed on the starting control set.
• Assessment disputes: Security team and assessor argue scope mid-engagement because the baseline is unclear.
• Control drift: Over time, control implementation diverges across environments and acquisitions because there is no baseline anchor.
• Weak defensibility: If an incident occurs, you cannot show a reasoned control selection decision for the affected system.

Practical 30/60/90-day execution plan

First 30 days: Establish the mechanism

• Assign PL-10 owner per system and define approvers.
• Publish a baseline selection template and minimum boundary prerequisites.
• For the highest-risk or most audited system, create the baseline selection record and link it into the SSP and control matrix. ¹

By 60 days: Scale across systems and fix traceability

• Complete baseline selection records for remaining in-scope systems.
• Standardize control matrices so they clearly indicate baseline controls vs. tailored controls vs. inherited controls.
• Align assessment planning to baseline-derived scope so test plans match what you selected.

By 90 days: Operationalize and keep it current

• Add baseline re-validation triggers to change management (major architecture change, hosting shift, new data type, boundary change).
• Schedule governance review checkpoints (for example: during system risk reviews or ATO package updates).
• In Daydream, automate reminders and evidence collection so baseline selection, approvals, and cross-links are exportable for audits. ¹

Frequently Asked Questions

What counts as “selecting” a baseline under PL-10?

A documented, approver-backed decision that names the baseline for a specific system and ties to the system’s control scope (SSP/control matrix). A policy that says “we follow NIST” is not system-level baseline selection. ¹

Do I need a separate baseline for each environment (prod vs. dev)?

If they are within one authorization boundary and share the same control scope, you can use one baseline selection and describe how controls apply across environments. If boundaries differ materially, document baseline selection per boundary to prevent scope confusion.

How do inherited controls affect baseline selection?

You still select a baseline for the system; inheritance changes how controls are implemented and evidenced. Record inherited controls in the control matrix with clear provider references so the baseline control list remains complete.

What artifact do auditors ask for first?

Most ask for the SSP and the control implementation matrix, then trace back to a baseline selection decision and approval. Keep the baseline record easy to export and linked from the SSP.

What triggers re-evaluating the baseline?

Boundary changes, major architecture shifts, new hosting or shared services model, and meaningful changes to the types of data processed. Treat these as governance triggers in your change process, even if the baseline ultimately stays the same.

How can Daydream help with PL-10 without turning it into paperwork?

Use Daydream to assign PL-10 ownership, capture the baseline decision and approval trail, and attach the recurring artifacts (SSP excerpt, control matrix export, tailoring log). That creates a single audit-ready thread per system. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5