Baseline Selection

Baseline Selection (NIST SP 800-53 Rev. 5 PL-10) requires you to formally choose the correct security control baseline for your system, then use that baseline as the starting point for tailoring, implementation, and assessment. In FedRAMP Moderate contexts, this decision must be explicit, documented, and traceable to the system’s purpose and impact so assessors can validate your control set. ¹

Key takeaways:

• You must make an affirmative, documented choice of control baseline for the system, not an implicit or assumed one. ¹
• The baseline decision becomes the anchor for your SSP scope, tailoring decisions, and assessment evidence package.
• Auditors look for consistency: baseline choice ↔ system characterization ↔ implemented controls ↔ assessment scope.

Baseline selection sounds simple until you have to defend it in an assessment. PL-10 is a requirement to pick the control baseline for a system, but operationally it functions like a “scope lock” for your entire compliance program: it determines which controls you must implement, what you can tailor, what your assessor will test, and what your authorizing official expects to see.

For a Compliance Officer, CCO, or GRC lead supporting a FedRAMP Moderate authorization effort, baseline selection is one of the earliest decisions that can create downstream rework if it’s wrong or undocumented. You need two things: (1) a clear decision record stating what baseline you selected for the system, and (2) clean traceability into the SSP and supporting artifacts so a reviewer can reconcile your baseline choice with how you built and assessed the system.

This page explains PL-10 in plain English, who it applies to, how to implement it step-by-step, what evidence to retain, and where teams commonly stumble during exams and assessments. ¹

Regulatory text

Requirement: “Select a control baseline for the system.” ¹

What the operator must do:
You must explicitly choose the starting set of security and privacy controls that applies to your system (the “baseline”), then treat that choice as a governed compliance decision. In practice, that means:

• The baseline is named (for example, aligned to your FedRAMP target).
• The baseline selection is recorded and approved.
• The baseline selection is reflected consistently in the SSP/control implementation statements and assessment scope. ¹

Plain-English interpretation

Baseline selection is your declared answer to: “Which control set are we building and getting assessed against for this system?” PL-10 does not ask you to implement every possible control. It requires you to pick the baseline that applies, then use it as the foundation for tailoring and implementation.

A good baseline selection decision is:

• Explicit (someone can point to a document and see the selection),
• Justified (it aligns to system purpose and impact),
• Actionable (it directly drives SSP content, control ownership, and assessment scope),
• Stable but governable (changes trigger formal change control and document updates). ¹

Who it applies to (entity and operational context)

PL-10 applies to organizations operating or authorizing systems under NIST SP 800-53 control frameworks, including:

• Cloud Service Providers (CSPs) pursuing or maintaining FedRAMP Moderate authorization for a cloud service offering.
• Federal Agencies sponsoring, authorizing, or integrating systems that must align to NIST SP 800-53 control baselines. ¹

Operationally, baseline selection matters most when:

• You are standing up a new system boundary and writing the SSP.
• You are changing the system in a way that could change impact, data types, or boundary (which can force a baseline re-evaluation).
• You are preparing for an independent assessment and want clean testability and scope alignment.

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

1) Name the system and boundary you are selecting a baseline for

Write down the system name, system purpose, and boundary statement in the same place you record the baseline. If the boundary is unclear, your baseline decision will be hard to defend because reviewers won’t know what “the system” means.

Operator tip: baseline selection fails in practice when teams pick a baseline for “the product” instead of the defined authorization boundary.

2) Identify the governing compliance target for the system

For FedRAMP Moderate efforts, the operational expectation is that your baseline aligns to that target authorization level. Your job is not to debate the existence of baselines; it is to show you selected the one you are claiming you meet and will be assessed against. ¹

3) Record the baseline selection decision in a controlled artifact

Create a short “Baseline Selection Record” (one page is fine) that includes:

• Selected baseline (name it exactly as your program uses it)
• System identifier and boundary reference
• Decision owner (role) and approver (role)
• Date and change history pointer
• Rationale statement tied to system context (data sensitivity, mission criticality, integration context)

Keep it simple, but make it auditable.

4) Translate the baseline into your working control set

Baseline selection is not complete until it is operationalized. Convert the baseline into:

• A control inventory/control applicability list for the system
• Control ownership assignments (system owner, control owner, shared services owner)
• Implementation planning tasks for controls not yet implemented

If you run a shared responsibility model (common for CSPs), explicitly mark which controls are inherited, shared, or fully implemented by your team.

5) Tailor only after the baseline is selected, and keep tailoring traceable

PL-10 is about choosing the baseline. Tailoring is separate work, but auditors will connect the dots. If you tailor (for example, mark controls not applicable or apply overlays), you need a traceable rationale and governance trail that starts from the baseline selection decision. ¹

6) Make the SSP and assessment scope match the baseline selection

Consistency is what gets assessed:

• The SSP control list must match the baseline plus approved tailoring.
• Control implementation statements must be present for applicable controls.
• Your assessment plan and evidence collection must track the same control universe.

7) Put baseline re-evaluation into change management

Baseline selection is not “set and forget.” Add a checkpoint to your change process so material changes prompt the question: does this change affect the system characterization enough to revisit the baseline?

A practical trigger list:

• Boundary changes (new components inside the boundary, major outsourcing, new hosting model)
• New data types or new use cases that change sensitivity
• Major architectural shifts (identity plane changes, logging plane changes)

Required evidence and artifacts to retain

Auditors and assessors typically want to see a clean chain from decision → implementation → assessment. Retain:

1. Baseline Selection Record

• Decision, approver, date, rationale, system boundary reference

2. System boundary documentation

• Boundary diagram and boundary narrative that the baseline decision references

3. SSP/control matrix

• Control list that aligns to selected baseline and any approved tailoring ¹

4. Tailoring/exception documentation (if any)

• Rationale, approvals, and where it is reflected in SSP language

5. Assessment scope alignment

• Evidence that your assessment plan/control testing scope matches the baseline-derived control set

6. Change management artifacts

• Tickets/records showing baseline review checkpoints for material system changes

Common exam/audit questions and hangups

Expect questions like:

• “Where is the baseline selection documented, and who approved it?”
• “Show me how the SSP control set ties back to the selected baseline.”
• “What controls are inherited, and where is the inheritance documented?”
• “If a control is marked not applicable, where is the tailoring justification and approval?”
• “How do you ensure system changes don’t invalidate the baseline selection?” ¹

Hangups that slow reviews:

• Baseline stated in one place (SSP intro) but control list reflects a different set.
• Teams can’t explain why the system boundary chosen is the one being assessed.
• Tailoring decisions exist in email or chat but not in governed artifacts.

Frequent implementation mistakes and how to avoid them

Mistake 1: Treating baseline selection as implied

Symptom: SSP says “FedRAMP Moderate” casually, but there is no formal baseline selection decision record.
Fix: Create a Baseline Selection Record and make it a required artifact for any new authorization boundary.

Mistake 2: Selecting a baseline before the boundary is stable

Symptom: Controls and evidence shift repeatedly because the “system” keeps changing.
Fix: Freeze a boundary for authorization purposes, then select the baseline for that defined boundary.

Mistake 3: Inheritance is hand-waved

Symptom: “We inherit this from the cloud” without mapping it to the system’s baseline control set.
Fix: For each inherited/shared control, record the provider, the artifact that supports inheritance, and the system owner’s responsibility.

Mistake 4: Tailoring without governance

Symptom: Controls marked N/A with weak rationales or no approval trail.
Fix: Treat tailoring like a formal exception workflow: rationale, approver, and SSP update.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for PL-10, so this page does not cite specific actions.

Operational risk is still straightforward: baseline selection is a gating input to authorization and continuous monitoring. If your baseline choice is unclear or inconsistent, you create assessment delays, scope disputes, and remediation churn. In a regulated environment, that translates to missed authorization timelines, control gaps that go untested, and fragile audit defensibility. ¹

Practical execution plan (30/60/90)

You asked for a plan you can run. Treat the day markers as phases; compress or expand based on your program cadence.

First 30 days (Immediate)

• Draft the system boundary statement and boundary diagram for the authorization scope.
• Create and approve the Baseline Selection Record for the system. ¹
• Generate the baseline-derived control inventory and assign control owners.
• Stand up a single source of truth (GRC workspace) for baseline, SSP mappings, and tailoring decisions.

Where Daydream fits naturally: Daydream can act as the controlled workspace where the baseline decision, control ownership, and SSP mappings live together, reducing “which spreadsheet is right” failures during assessment.

By 60 days (Near-term)

• Complete first-pass SSP alignment to the selected baseline (control applicability + implementation statements).
• Document inheritance and shared responsibility boundaries for baseline controls.
• Formalize tailoring workflow and approvals, and reflect outcomes in SSP/control matrix.
• Run an internal “scope consistency” review: baseline record ↔ SSP control list ↔ evidence plan.

By 90 days (Operationalize)

• Integrate baseline review into change management (architecture reviews, release gates, major tickets).
• Build an assessor-ready evidence index keyed to the baseline control set.
• Run a mock assessment or readiness review focused on baseline consistency failures: mismatched control sets, missing rationale, unclear boundary.
• Establish ongoing maintenance: update Baseline Selection Record when system characterization materially changes. ¹

Frequently Asked Questions

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

A documented decision that identifies the control baseline for the specific system boundary, with an approver and a rationale that matches the system context. The selection must be reflected in the SSP control set. ¹

Where should we document baseline selection so auditors accept it?

Put it in a controlled Baseline Selection Record and cross-reference it in the SSP. Auditors want traceability and version control more than narrative volume.

Can we change the baseline later?

Yes, but treat it like a governed change. Update the Baseline Selection Record, assess impact to SSP scope and evidence, and run change control so the assessment target stays clear.

How does baseline selection relate to tailoring?

Baseline selection chooses the starting control set; tailoring documents justified deviations (such as not applicable determinations). Tailoring should reference the baseline-derived control list so reviewers can see what changed and why. ¹

Our system inherits many controls from third parties. Does that affect baseline selection?

Inheritance affects implementation responsibility, not whether you must select a baseline. You still select the baseline for the system, then document which baseline controls are inherited/shared and what evidence supports that.

What is the fastest way to fail a baseline selection review?

Having the baseline declared in one place while your SSP/control list and assessment scope reflect a different control universe. Consistency across artifacts is the core review lens.

Footnotes

1. NIST Special Publication 800-53 Revision 5