PL-10 Baseline selection: requirements and evidence

What PL-10 baseline selection asks for and why it is hard to get right

PL-10 requires the organization to select a control baseline for the system. The NIST discussion describes baselines as predefined sets of controls that serve as a starting point for protection, and it says the choice is driven by stakeholder needs and applicable mandates. For federal systems, the baselines themselves are defined in SP 800-53B, which allocates PL-10 to the low, moderate and high security control baselines. It is not part of the privacy control baseline, so a system selected only for privacy purposes does not carry this requirement in the same way.

For a system owner or compliance lead, the hard part is rarely choosing a level. Impact categorization, which is covered under the risk management process, usually points to a level, and the baseline then follows from that result. The harder question is whether the chosen baseline reflects the system's actual mandates, data types, stakeholder commitments and operating environment. An assessor will ask why the system sits at that baseline and not another, and the answer has to be traceable to documented decisions. Confirm with your authorizing official and your categorization records which mandates were considered, who approved the selection, and when it was last reviewed.

The selection also sets up the work that follows. PL-11 then adjusts the chosen baseline through tailoring, so a weak justification at PL-10 tends to produce weak tailoring decisions later. Record the baseline, the rationale, the stakeholders consulted and the mandates applied in the system security and privacy plan, which PL-2 requires, so assessors can examine the selection alongside its plan. The SP 800-53A procedure for PL-10 focuses on examining the plan development, review and update procedures and interviewing the personnel who carry out risk management, so those people should be able to explain the decision without referring to a spreadsheet.

Which systems and mandates decide the baseline choice

PL-10 asks the organization to pick a starting baseline, and that choice follows from a handful of facts about the system and the rules that govern it. The cards below cover the inputs that most often change the selection, so the baseline can be justified to an assessor before PL-11 tailoring begins.

System impact level

The impact level assigned during security categorization is the first input that narrows the choice. SP 800-53B ties the low, moderate and high baselines to impact levels, so a system categorized at one level cannot simply adopt a baseline for another without a documented reason. Check that the categorization record is current and approved, because a later reclassification changes the baseline that PL-10 must name. Ask who signed the categorization and whether it reflects the system as it operates today.

Personally identifiable information in scope

The types of PII the system stores, processes or transmits affect the baseline decision and the privacy controls that accompany it. SP 800-53B applies a separate privacy baseline regardless of impact level, and PL-10 itself is not part of that privacy baseline. Inventory the data elements, their sources and their uses, then confirm which privacy controls apply alongside the security baseline. Records of this inventory are the evidence an assessor will ask for first.

Mandates that apply to the system

Federal law, agency policy and contract terms determine which baseline is required and which deviations are allowed. FISMA and OMB Circular A-130 are listed among the related laws and regulations for SP 800-53, but a contract or agency directive may name a specific baseline or add overlays. List each mandate in writing, note the baseline it requires, and flag any conflict between them. Where the mandates disagree, the stricter requirement usually governs, and the decision should be recorded in the system security plan.

Stakeholder needs and system boundary

NIST notes that baseline selection is driven by stakeholder needs as well as mandates, so mission owners, system owners and operators should agree on what the system must protect. The boundary also matters: a system that shares components, hosting or identity services with other systems may inherit controls or need its own. Confirm the boundary with the people who run the system before choosing a baseline, because a selection made against the wrong boundary has to be redone.

External services and inherited controls

Cloud platforms, managed services and shared enterprise tools can supply some controls the system would otherwise need to implement itself. Those inherited controls change the working scope even when the baseline stays the same. Identify which services are in the boundary, which controls the provider documents, and which remain the organization's responsibility. Request the provider's control documentation and confirm how it maps to the chosen baseline, since an unexplained inheritance claim is a common assessment finding.

Authorizing official's decision

The authorizing official accepts the risk of operating the system and therefore has to accept the baseline in the system security and privacy plan. That approval is a governance step, not a technical one, and it should record the baseline, the mandates behind it and any known gaps. Confirm who holds the authorizing official role, when they last reviewed the plan, and whether they have delegated any part of the decision. An assessor will look for that signed approval before accepting the PL-10 selection as complete.

How SP 800-53B baselines map to system impact

SP 800-53B sorts security controls into three baselines, low, moderate and high, and each one is matched to the impact level of the system. The impact level comes from the security categorization of the information and services the system handles, so the first decision is a categorization, not a control choice. PL-10 Baseline selection belongs to these three security baselines only. It is not part of the privacy baseline, which applies regardless of impact level and is a separate set of controls. A system that holds personally identifiable information still needs a security baseline chosen under PL-10, and the privacy baseline is added alongside it where privacy requirements apply.

The release 5.2.0 counts matter when you size the work. Counting base controls and enhancements together, the OSCAL profiles in SP 800-53B Release 5.2.0 select 149 items for the low baseline, 287 for moderate and 370 for high. The privacy baseline selects 96 items. Ask your assessor or GRC lead which release version your authorization package cites, because the counts are tied to a specific release and a system documented against an older release may need its baseline mapping re-checked. The SP 800-53B Release 5.2.0 update made no baseline changes, so these counts still describe the current baselines, but confirm this against the release notes before you write them into a plan.

Once a baseline is selected, PL-11 Baseline tailoring adjusts it. Tailoring can remove controls that do not apply, add controls where the risk requires them, assign parameter values and identify common controls the system inherits. The baseline is the starting point, not the final control set, so record the chosen baseline and its impact basis in the system security and privacy plan now, and keep the justification for each later tailoring decision traceable to that record. The NIST CPRT catalog entry for PL-10 is the reference to check against when you write that justification.

How an assessor tests PL-10

This table breaks down the SP 800-53A procedure for PL-10 by assessment element, showing the single determination statement, the examine and interview methods, and the objects an assessor uses. Read it as a checklist of what to have ready before an assessment begins, with the common findings that usually come from gaps in the baseline record.

Element	What the assessor does	Evidence requested or common findings
Determination statement	Decides whether the organization selected a control baseline for the system, using the single PL-10 determination statement in SP 800-53A	Evidence: a documented baseline selection that names the impact level and the baseline chosen. Finding: the system has no recorded baseline at all
Examine: plan development and implementation	Reviews the procedures that govern how the system security and privacy plan is developed and implemented, including where baseline selection is recorded	Evidence: the procedure, plus a plan showing the selected baseline. Finding: the baseline is named in a plan but no procedure says how it was chosen
Examine: plan reviews and updates	Checks whether the procedures for reviewing and updating the plan cover the baseline, so a changed impact level or new mandate leads to a revised selection	Evidence: review records and change history for the plan. Finding: the baseline was never revisited after the system's scope or data changed
Interview: risk management personnel	Asks the people responsible for risk management activities how the baseline was chosen and who approved it	Evidence: named owners, the rationale they can explain, and the stakeholders consulted. Finding: staff cannot explain why the baseline fits the system
Impact and mandate basis	Tests whether the selection reflects the system's impact level and the applicable mandates, which SP 800-53B ties to the low, moderate and high baselines	Evidence: a categorization record and a list of mandates. Finding: the baseline was copied from another system without checking its impact level
Link to PL-11 tailoring	Confirms that the selected baseline is the starting point that tailoring then adjusts, not a substitute for it	Evidence: tailoring decisions traced back to the chosen baseline. Finding: tailoring records do not reference any baseline
Scope of the assessment	Limits testing to the baseline chosen for the system under assessment, and confirms that the privacy baseline is not the reference point for PL-10	Evidence: the system boundary and categorization in the plan. Finding: the assessment covers a different system than the one the baseline describes

How to select and document a baseline in six steps

This sequence turns a vague sense of what the system needs into a documented, approved baseline that PL-11 tailoring and the system security and privacy plan can build on. Each step ends with a record that an assessor can examine.

Confirm the system boundary
Define exactly which components, data flows, users and interconnections make up the system before choosing any controls. The system owner leads this work with the security and privacy teams, and the output is a boundary description with an inventory of in-scope components and external connections. You know the step is done when the system owner and security lead sign the boundary and no component is left unassigned. A boundary that shifts later forces the baseline to be reselected, so settle it first.
Categorize the system by impact
Assess the potential impact on confidentiality, integrity and availability if the system is compromised, and record a low, moderate or high impact level for each objective. The security lead and information owners do this together, using the organization's categorization method. The output is a signed categorization record that states the overall impact level and the reasoning behind each rating. The step is complete when every information type in the boundary has a documented rating.
Identify the mandates that apply
List the laws, regulations, contracts and internal policies that govern the system, such as FISMA for federal agencies or the Privacy Act for systems holding personal information. Legal or compliance staff confirm each mandate and note any that require specific controls or a privacy baseline. The output is a mandate register linked to the system. You know this step is complete when counsel or the compliance lead has reviewed the register and no contractual or statutory requirement is missing.
Select the SP 800-53B baseline
Use the categorization and mandate register to choose the matching baseline in SP 800-53B: low, moderate or high for security, and the privacy baseline where personal information is processed. Note that PL-10 itself is allocated to the security baselines and not the privacy baseline. The output is the selected baseline and the list of controls it contains. The step is complete when the chosen baseline matches the impact level and every mandate that requires privacy controls is reflected in the selection.
Record the rationale and stakeholder input
Write down why the baseline was chosen, which stakeholders were consulted (system owner, mission or business leads, privacy office, procurement and the risk function) and what concerns they raised. The security lead drafts the record and each consulted stakeholder confirms their input is accurately captured. The output is a rationale memo that an assessor or authorizing official can read without interviewing the team. The step is complete when each stakeholder concern has a recorded disposition.
Obtain authorizing official approval
Submit the categorization, baseline selection, rationale and mandate register to the authorizing official for approval. The authorizing official accepts the risk of the selected baseline, and the signed approval becomes part of the authorization package. The output is a dated, signed approval record. The step is complete only when the authorizing official's decision is on file, because a baseline the authorizing official has not approved is not an approved basis for tailoring.
Link the baseline to the plan and PL-11 record
Reference the approved baseline in the system security and privacy plan under PL-2, so the plan states which baseline applies and why. Then open the PL-11 tailoring record, which starts from this baseline and documents each addition, removal, parameter value and common control decision. The output is a cross-reference between the baseline record, the plan and the tailoring record. You know it is done when an assessor can trace a control from the plan to the baseline and to its tailoring entry without gaps.

Evidence that shows a baseline was selected and kept current

An assessor testing PL-10 looks for a traceable chain: why the system landed on a particular baseline, who approved that decision, and whether the record still matches the system today. The six artifacts below form that chain, and each needs a named owner and a review cadence so it stays accurate between assessments.

Signed baseline selection record

This is the decision record itself: the system name, the chosen baseline (low, moderate or high under SP 800-53B), the privacy baseline where it applies, and the reasons the selection fits stakeholder needs and applicable mandates. Keep it in version control so every change to the baseline leaves a dated diff. Check that the signer is the person with authority to accept the risk of that baseline, and that the record names the release of SP 800-53B used.

Impact categorization rationale

The baseline follows from the system's impact level, so the categorization worksheet is the evidence that connects the system to its baseline. It should show the information types, the confidentiality, integrity and availability impact ratings, and the reasoning behind the high-water mark. Review it whenever the data set, user population or mission changes, because a higher impact rating can move the system to a stronger baseline without any change to the platform itself.

SSP section naming the baseline

The system security and privacy plan should state the selected baseline in its system description and carry the control list that results from it. An assessor compares the SSP against the baseline record, so any mismatch between the two is a finding in its own right. Check that PL-2 review dates in the SSP fall after the most recent baseline change, and that the plan points to PL-11 tailoring decisions rather than silently applying the raw baseline.

Approval records

Approval evidence shows that the authorizing official or designated approver accepted the baseline before the system relied on it. Keep the signed approval, the date, the scope it covers and any conditions attached to it. Where the platform is reused across several systems, record each approval separately so a change to one system's baseline does not look like a change to all of them.

Review and update history

A baseline that was correct at selection can drift as the system grows, as SP 800-53 releases change control content, or as new mandates apply. Maintain a change log that records each review, the reviewer, the trigger (scheduled review, system change, new release) and the outcome. Between audits, set a recurring review date in the ticketing system and assign an owner, so the history shows continuous attention rather than a single signature years old.

Stakeholder input records

PL-10 ties selection to stakeholder needs, so keep the records of who was consulted, what they said and how their input shaped the decision. Typical sources include mission owners, privacy officers, system owners and the agency or customer that imposes the mandate. Capture disagreements and how they were resolved. Ask stakeholders to confirm the baseline at each review, because their needs change even when the technical system does not.

What selecting a baseline costs in money and effort

This table lists the cost components of choosing a control baseline under PL-10, who is paid or who spends time on each, and whether the cost is one-time or recurs. Read it as a checklist for a written quote, since NIST does not publish cost or duration figures for baseline selection. The main takeaway is that most of the effort sits in internal analyst and risk owner time, and that the recurring share grows with every significant system change.

Cost component	Who carries it	One-time or recurring	What drives it
Internal analyst and risk owner time	Organization's own staff	One-time at initial selection, then recurring	Number of system components, data types, and stakeholders who must agree on impact levels
Authorizing official review	Authorizing official and their staff	One-time per authorization, recurring at re-authorization	How well the rationale for the chosen baseline is documented before review begins
External consulting for categorization and rationale	Organization pays a consultant or implementation partner under a written scope	Usually one-time, with optional follow-on support	Whether internal staff have prior SP 800-53B experience and how many systems are in scope
Tooling for documentation and tracking	Organization, through licenses or self-hosted deployment and staff time to run it	Recurring license or hosting costs where applicable, plus setup once	Whether baseline decisions are tracked in a system that feeds the security plan and assessment records
Recurring review after system changes	Organization's own staff, with the authorizing official for significant changes	Recurring for the life of the system	Frequency of system changes, new data categories, and changes to mandates that apply
Rework from an incorrect or undocumented baseline	Organization, and any consultant it engaged	One-time per correction, but often costly	Missing impact analysis or a baseline chosen before stakeholder needs were recorded

Who selects the baseline, who prepares evidence, who tests it

Your organization owns the baseline decision. PL-10 asks the organization to select a control baseline for the system, and the choice has to reflect stakeholder needs and the mandates that apply to the system. The people who make that call are usually the system owner, the information system security officer, the privacy function and the authorizing official, who accepts the risk of running the system on the chosen baseline. Your team also signs off on the impact level that drives the choice between the low, moderate and high baselines in SP 800-53B.

Decision ownership: Name the person who approves the selected baseline and records the approval date.
Mandate mapping: Confirm which laws, contracts and agency requirements apply, since these drive the baseline choice.
Stakeholder input: Record what business, mission and privacy stakeholders asked for and how it affected the decision.
Approval record: Keep the signed selection in the system security and privacy plan so assessors can trace it.
Re-decision triggers: Define when a change in data, users or connections requires the baseline to be reviewed.

Before accepting any proposal, check that the decision record names your own staff as owners and that no partner has signed it on your behalf.

Where baseline selections fail assessment

Assessors test PL-10 by reading the documents that record how the baseline was chosen and whether that choice still fits the system. The gaps below are the ones that most often surface when an examiner asks why a baseline was picked and who approved it. Each card names the gap and the check to run before the assessment starts.

No documented selection rationale

A baseline name written into the system security plan with no reasoning behind it gives an assessor nothing to test. PL-10 expects the selection to follow stakeholder needs and applicable mandates, so the record should show which mandates applied, who was consulted and why the chosen baseline fit. Check that the rationale names the mandates and the decision makers, and that it was approved before the system went live.

Impact level and baseline do not match

A system categorized as moderate impact but assessed against the low baseline leaves controls out of scope that the categorization requires. The reverse wastes effort on controls the system does not need, and it confuses the risk picture. Assessors compare the categorization in the risk assessment with the baseline in the plan. Confirm that the categorization record and the selected baseline name the same impact level.

Privacy considerations left out

Systems that process personally identifiable information need the privacy baseline in addition to a security baseline. The privacy baseline is separate and applies regardless of impact level, and PL-10 itself is not part of it. Teams that select only a security baseline often discover late that PII handling was never assessed. Ask whether the system handles PII and, if so, whether the privacy baseline was selected.

Stale selection after system changes

A baseline chosen for the original design may no longer fit after new data types, hosting moves, new users or added external services. An assessor reviewing the plan will check whether the selection was revisited when the system changed. Without a trigger in the change process, the baseline quietly drifts from the system it describes. Add a baseline review step to the change board and to the plan review cycle.

No link to the security plan

PL-10 sits beside PL-2, the system security and privacy plan, and PL-11, tailoring. If the plan lists controls that do not trace back to the selected baseline, or the baseline is never named in the plan, the assessment record breaks at its first link. Assessors trace from the baseline to the plan to the control implementations. Trace each baseline control to the plan entry that addresses it.

Selection not tied to the risk assessment

A baseline picked without reference to the organization's risk assessment cannot show that it answers the threats the system faces. Assessors may ask how the risk assessment informed the choice, and the answer should be traceable in the documents. Confirm that the risk assessment is cited in the selection record and that any gaps it identified are addressed.

Questions buyers ask about PL-10 baseline selection

How much does it cost to select a control baseline for PL-10?

No published price exists for this step, because PL-10 is a documented decision rather than a purchase. The cost is mostly staff time: the authorizing official, system owner, security and privacy leads and the people who own the mission need to agree on the impact level and the baseline that follows from it. Costs rise with the number of systems, the number of mandates that apply (federal, contractual or sector rules), and how many stakeholders must sign off. NIST's risk management FAQ says NIST does not estimate compliance or certification costs, so ask any consultant for a written scope that lists the systems, the stakeholders and the deliverables before agreeing a fee.

How long does baseline selection take for a single system?

The duration depends on how quickly the organization can agree on the system's impact level and the mandates that apply, not on the mechanics of picking a baseline. A system with clear requirements and a single owner can move quickly, while a system with conflicting stakeholder needs or unresolved mandates takes longer. NIST does not set implementation timelines for federal systems; it leaves that to OMB Circular A-130. Ask for a schedule that ties the baseline decision to the system security and privacy plan review, because the selected baseline feeds that plan directly.

What does selecting a baseline require from the internal team?

The team needs a clear system boundary, a recorded impact level, a list of applicable mandates and named owners who can accept the outcome. The NIST discussion for PL-10 says selection is driven by stakeholder needs and applicable mandates, so the work starts with those inputs. Engineers supply the system inventory and data flows, and the risk owner confirms the impact level. Without those inputs, any baseline chosen is a guess that later assessments will challenge.

Can we select a baseline in-house without outside help?

Yes, an organization can select its own baseline, because PL-10 is an internal decision and the organization owns its controls. Outside help is most useful when the team lacks experience with the federal baselines in SP 800-53B or when several systems must be mapped consistently. An implementation partner can prepare the system inventory, draft the selection rationale and organize the evidence, but the organization approves the result. Only an independent assessor issues assessment findings, so the in-house team should not expect a consultant to validate its own decision.

How does PL-10 baseline selection differ from PL-11 baseline tailoring?

PL-10 chooses the starting set of controls, such as the low, moderate or high baseline in SP 800-53B, based on the system's impact and applicable mandates. PL-11 then adjusts that starting set for the specific system by identifying common controls, applying scoping, choosing compensating controls, assigning parameter values and adding controls where needed. In practice, PL-10 is a single decision recorded early, while PL-11 is ongoing work that changes as the system changes. Both controls are documented in the system security and privacy plan, and assessors examine them together.

What will an assessor ask about our baseline selection?

An assessor using SP 800-53A checks PL-10 with one determination statement, using the examine and interview methods. They will examine the procedures for developing and implementing the system security and privacy plan and for reviewing and updating it, and they will interview personnel responsible for organizational risk management. Expect questions about why the chosen baseline matches the impact level, which mandates were considered and who approved the decision. Keep a written record of each input so the answers can be traced to evidence.

Which open-source tools can help document the baseline decision?

The NIST baselines are published as OSCAL profiles in the usnistgov/oscal-content repository, so teams can load the low, moderate, high or privacy profile into their own tooling rather than copying control lists by hand. CISO Assistant, an AGPL-3.0-only platform, supports audits and compliance assessments across many frameworks and can record the system scope and the controls that apply. Confirm with each tool's documentation which NIST release and baseline profiles it supports before relying on it for evidence, since the tool does not replace the organization's own decision.

How OSCAL and self-hosted tools support baseline records

The selection record for PL-10 can be generated from machine-readable content rather than typed by hand. NIST publishes the SP 800-53B low, moderate, high and privacy baseline profiles in OSCAL on GitHub, in the usnistgov/oscal-content repository, which you can review in the OSCAL content repository. Load the profile that matches the impact level you documented, confirm that the profile version matches the SP 800-53 release your assessor will use, and keep the file under version control with the system security and privacy plan. The record should show which profile was selected, the date, the approving role and the reason for the choice, because PL-10 asks for the selection itself and PL-11 then records the tailoring against it. A profile file alone does not show who decided, so store that decision alongside it.

Self-hosted governance tools can hold that record and link it to evidence. CISO Assistant, licensed under AGPL-3.0-only, is one open-source option that manages frameworks, assessments and audits inside your own environment, which keeps baseline decisions on infrastructure you control. Before relying on it for SP 800-53 work, confirm with the project which NIST SP 800-53 release and which baseline profiles it loads, whether it imports OSCAL content directly or requires manual mapping, and how it records the approver and the date for each selection. You can review the project's documentation in its CISO Assistant README. Treat any tool output as a working copy. The authorizing organization owns the selection, and an independent assessor determines whether the evidence meets the control.

How DeployOpen prepares PL-10 evidence

DeployOpen helps organizations that have to select an SP 800-53 baseline for a system and keep that selection defensible. We prepare the system inventory, the selection record and the evidence an assessor will ask for, while the organization keeps ownership of the baseline decision and the independent assessor issues any assessment conclusion.

How we scope

Confirm the system boundary, impact level inputs and the stakeholders who own the baseline decision
Agree in writing which SP 800-53B baseline documents, selection records and reviews are in scope
Define who signs the selection, who reviews it and how it links to the system security and privacy plan

How we build

Record the selected baseline, the impact rationale and the stakeholder inputs in a traceable form
Load the SP 800-53 Rev. 5.2.0 catalog and SP 800-53B profiles into the self-hosted tooling used for control mapping
Prepare the procedures and records an SP 800-53A assessor would examine for PL-10 and related PL controls

How we hand over

Deliver the baseline selection record, data sources, configuration notes and a review schedule in writing
Document how the selection feeds PL-11 tailoring so the next step has a clear starting point
Walk the organization's owners through the evidence so they can answer assessor questions themselves

How we support

Engagements are fixed-scope, and the agreed deliverables are the basis for acceptance
Ongoing support, upgrades and reviews after a new NIST release are available as a retainer
DeployOpen prepares evidence only; independent assessors and authorizing officials issue conclusions and decisions