PL-10: Baseline Selection

Quick-reference card

What this control requires

PL-10 requires your organization to select a predefined control baseline that matches the risk profile of each information system. That baseline becomes the starting point for every security and privacy control you’ll implement, tailor, and eventually defend during an audit.

In practice, baseline selection isn’t a one-time checkbox. It’s a decision that cascades through your entire risk management strategy, because the baseline you choose determines which of the hundreds of controls in NIST SP 800-53 apply to your environment by default. Specifically, when you select a Low, Moderate, or High baseline from Special Publication (SP) 800-53B, you’re accepting a curated set of controls that the National Institute of Standards and Technology (NIST) has assembled to address the most common threats at that impact level.

The result is a scoping decision that directly shapes your compliance workload, your evidence collection requirements, and the depth of your security architecture. Organizations subject to the Federal Information Security Modernization Act (FISMA) don’t have discretion over whether to select a baseline, only over which one fits their system’s categorization.

Why it matters

Most organizations treat baseline selection as an administrative formality, but the choice carries real operational weight within the NIST SP 800-53 framework. Selecting the wrong baseline creates either a false sense of coverage or an unnecessary compliance burden that drains resources from higher-priority risks. A system categorized at a Moderate impact level that operates under a Low baseline will have gaps in access control, audit logging, and incident response that directly affect its ability to withstand common attack patterns.

In practice, this means that a misaligned baseline doesn’t just produce audit findings. It leaves controls unimplemented that were specifically designed to counter the threats your system faces, based on the sensitivity of the information it processes, stores, and transmits.

Where this breaks down is in organizations that haven’t completed a rigorous security categorization under Federal Information Processing Standards (FIPS) 199 before selecting their baseline. Without a clear understanding of potential adverse impact on operations, assets, individuals, and other organizations, baseline selection becomes a guess rather than a risk-informed decision. The result is compliance documentation that doesn’t reflect actual risk exposure.

Take national security systems as a specific case. These systems follow a separate baseline framework under Committee on National Security Systems Instruction (CNSSI) 1253, which maps controls to confidentiality, integrity, and availability impact levels independently. Applying the wrong framework compounds the baseline selection problem with jurisdictional non-compliance.

How to implement

For your organization

The most common failure mode isn’t selecting the wrong baseline. It’s selecting a baseline without completing the prerequisite categorization work, then discovering during an audit that your control set doesn’t match your system’s actual impact level.

Start with security categorization, not baseline selection. Your baseline choice should flow directly from a completed FIPS 199 categorization that evaluates the confidentiality, integrity, and availability impact levels for the information types your system handles. Specifically, when you analyze the potential adverse impact of loss or compromise across your operations, assets, individuals, and other organizations, you produce the inputs that make baseline selection a defensible decision rather than an assumption.

Map your categorization to SP 800-53B baselines. NIST publishes three baseline tiers that correspond to Low, Moderate, and High impact categorizations. Each tier includes a progressively larger and more rigorous set of controls. A Low baseline covers foundational security hygiene. The Moderate baseline adds controls for systems where a breach could cause serious adverse effects. The High baseline addresses systems where compromise could cause severe or catastrophic harm. You don’t mix and match across tiers. You select one baseline per system, then tailor from there under PL-11.

Document the rationale, not just the choice. Auditors don’t just want to see which baseline you selected. They want evidence that the selection was informed by your system categorization decision, a stakeholder needs analysis, and a review of applicable mandates including laws, executive orders, directives, regulations, and organizational policies. Your system security plan should trace the baseline selection back to these inputs explicitly.

Account for privacy baselines separately. SP 800-53B includes a privacy baseline that operates independently of the Low/Moderate/High security tiers. If your system processes personally identifiable information (PII), you’ll need to evaluate the privacy baseline alongside your security baseline, not as a replacement for it.

Revisit when system boundaries change. Baseline selection isn’t static. When you add new information types, connect to new external systems, or change the operational context of a system, you should reassess whether the current categorization and baseline still apply. Organizations that treat baseline selection as a one-time event accumulate drift between their documented controls and their actual risk posture. Continuous monitoring can help you track whether your control implementation stays aligned with your selected baseline over time.

Evidence examples

Demonstrating PL-10 compliance requires artifacts that show how you arrived at your baseline selection, not just which baseline you chose.

Cross-framework mapping

Related controls

• PL-02 — System Security and Privacy Plans: the system security plan documents the selected baseline and serves as the primary artifact where the baseline decision is recorded and maintained
• PL-11 — Baseline Tailoring: once a baseline is selected under PL-10, PL-11 governs how you adjust that baseline by adding, removing, or modifying controls to fit your specific risk context
• RA-02 — Security Categorization: the FIPS 199 categorization performed under RA-02 produces the impact levels that directly determine which baseline tier applies to your system
• RA-03 — Risk Assessment: risk assessment results inform whether the selected baseline adequately addresses identified threats or whether additional controls beyond the baseline are warranted
• SA-08 — Security and Privacy Engineering Principles: engineering principles guide how baseline controls are implemented within the system architecture, ensuring that selected controls are technically feasible and effective

Frequently asked questions

What is NIST SP 800-53 PL-10

PL-10 requires organizations to select a control baseline for each information system. A control baseline is a predefined set of security and privacy controls published in SP 800-53B, assembled to address threats at a specific impact level. The selection must be grounded in a completed security categorization decision that evaluates the information types the system processes, stores, and transmits, along with the potential adverse impact of their loss or compromise. It isn’t a discretionary recommendation. For organizations subject to FISMA, baseline selection is a mandatory step in the Risk Management Framework (RMF).

What happens if PL-10 is not implemented

Without a selected baseline, your organization has no structured starting point for determining which controls apply to a given system. The consequence is that control selection becomes ad hoc, driven by individual judgment rather than a risk-informed categorization decision. During a FISMA audit or an assessment under NIST’s RMF, the absence of a documented baseline selection means assessors can’t verify that your control set matches your system’s impact level. In practice, this leads to findings against your system security plan, because there’s no traceable link between your security categorization, your stakeholder needs analysis, and the controls you’ve implemented.

How do you audit PL-10

Auditing PL-10 centers on one assessment objective: confirming that a control baseline for the system has been selected. But the evidence required to satisfy that objective goes deeper than pointing to a baseline label. Assessors will look for a documented security categorization decision, the information types stored, transmitted, and processed by the system, a stakeholder needs analysis that shows mission and business requirements were considered, and the system security plan where the baseline designation is recorded. They’ll also verify that the selected baseline aligns with applicable mandates, including federal or organization-approved baselines or overlays. If your organization has changed the system’s boundaries, data flows, or interconnections since the original selection, assessors will want evidence that the baseline was reassessed.

How do you choose the right NIST 800-53 baseline

Choosing the right baseline starts with completing your FIPS 199 security categorization, which assigns Low, Moderate, or High impact levels for confidentiality, integrity, and availability based on the information types your system handles. The highest impact level across those three dimensions determines your overall system categorization, and that categorization maps directly to one of the three baseline tiers in SP 800-53B. A Moderate categorization, for example, means you select the Moderate baseline. Your stakeholder needs analysis should validate that the categorization reflects current mission requirements and regulatory mandates, not assumptions carried over from a prior assessment. After selection, PL-11 governs how you tailor the baseline to your environment.