SP 800-53B Baselines & Tailoring Course — RMF Coach

Lesson 1 — What a Control Baseline Is (~8 min)

You categorized the system — a baseline is your running start on which controls to select.

Explain what a control baseline is and the job SP 800-53B does in the RMF Select step.

Your team just finished categorizing a system as FIPS 199 Moderate. Now comes the question that stops new practitioners cold: which of the 1,000-plus controls in SP 800-53 do we actually implement?

Starting from a blank catalog would be hopeless. So NIST gives you a running start: a control baseline — a pre-selected set of controls matched to an impact level. SP 800-53B is the publication that provides those baselines and the rules for adjusting them.

This course teaches the two moves that follow categorization: select the right baseline, then tailor it to your system. It's written for anyone whose risk decisions depend on getting control selection right — system owners, ISSOs, common control providers, and privacy officers.

A control baseline provides a set of controls from the SP 800-53 catalog, chosen for low-, moderate-, or high-impact systems (per FIPS 199) or selected to address privacy risk.

The key word is starting point. A baseline is the minimum, generalized set NIST expects for a given impact level — not a finished control selection for your system. It hasn't yet accounted for your environment, your shared services, or your specific risks.

That's the whole shape of control selection: begin with the baseline that matches your categorization, then adjust it. A baseline saves you from starting at zero; tailoring makes it actually fit.

SP 800-53B does three things: it provides the security and privacy control baselines, it gives guidance for tailoring those baselines, and it explains control overlays (covered at the end of the course).

In the Risk Management Framework, this is the Select step's toolbox. After you Categorize, you Select controls — and 800-53B is how you do that efficiently: start from the baseline, tailor it, document the result.

So the mental file-card is simple: SP 800-53 is the catalog of controls; SP 800-53B is how you pick and adjust a starting set from it. One is the menu, the other is how you order.

Lesson 2 — Choosing a Baseline (~9 min)

Two security choices: which impact baseline, and whether the privacy baseline applies.

Select the right security baseline by impact and determine when the privacy baseline applies.

SP 800-37 names two approaches for selecting controls in the RMF Select step.

In the organization-generated approach, the organization uses its own process to choose controls from the catalog directly — useful when a baseline doesn't fit the situation.

In the baseline approach, you start from one of NIST's pre-built baselines and tailor it. This is the common path, and it's what SP 800-53B is built for.

This course follows the baseline approach: pick the baseline that matches your categorization, then tailor. The organization-generated approach is always available as an alternative when the standard baselines aren't a good starting point.

SP 800-53B provides three security control baselines — low, moderate, and high — that correspond directly to the FIPS 199 security impact categorization required for federal systems.

The rule is mechanical: a system categorized Moderate starts from the Moderate baseline. Higher impact means more controls and more rigor, because the potential harm from a compromise is greater.

Non-federal organizations aren't bound by FIPS 199, but the same three baselines are a widely used, sensible starting point for them too. Either way, the categorization picks the baseline — you don't choose it by preference.

Security isn't the only concern. SP 800-53B provides an initial privacy control baseline for federal agencies to address privacy requirements and manage the privacy risks that arise from processing PII — grounded in privacy-program responsibilities under OMB A-130.

The trigger is simple: if your system processes personally identifiable information, the privacy baseline is in scope, selected by the agency's Senior Agency Official for Privacy (SAOP) alongside the security baseline.

So a system can carry two baselines at once — the security baseline from its FIPS 199 level, and the privacy baseline because it handles PII. The Atlas Grants Portal, holding applicant PII, is exactly that kind of system.

Security and privacy aren't two walled gardens. Many cybersecurity risks contribute to privacy events — a breach that exposes PII is both a security incident and a privacy harm — so the security and privacy baselines overlap.

Some controls appear in both contexts and serve both goals at once. The practical effect: when a control protects PII and the system, you implement it once and it counts for both, rather than duplicating it.

Getting this overlap right is a coordination task between the security team and the SAOP. It's also the first hint of tailoring — deciding, per control, who's responsible and whether it's needed — which is the heart of the next lesson.

Lesson 3 — Baseline Assumptions (~6 min)

Baselines are built on assumptions — know them, because yours might differ.

Explain why baselines carry built-in assumptions and what to do when they don't hold.

A baseline has to work for a diverse range of systems and organizations, so NIST built it on a set of assumptions — about the operating environment, the expected threats, the technologies in use, and how the system is operated.

Those assumptions are what make a baseline a reasonable general starting point. But they're also its limit: your system might face threats the baseline didn't assume, run technology it didn't anticipate, or operate in conditions it didn't expect.

This is exactly why tailoring exists. When a baseline's assumptions match your situation, you keep its controls; where they don't, you adjust — adding, removing, or substituting controls so the protection actually fits. Tailoring isn't second-guessing NIST; it's finishing the job the baseline started.

Lesson 4 — Tailoring the Baseline (~14 min)

Tailoring is where the baseline becomes your system's real control set.

Tailor a baseline using the standard activities: common controls, scoping, compensating controls, ODPs, and supplements.

Once the right baseline is selected and its assumptions considered, the organization begins tailoring — adjusting the baseline to address the uniqueness of the system or organization and align the controls more closely with the specific security and privacy requirements.

Tailoring isn't improvisation. It's a defined set of activities: designate common controls, apply scoping considerations, select compensating controls, assign parameter values, supplement with extra controls, and add implementation specification. We'll walk each one.

The output is a tailored control baseline — the real, system-specific control set — and the rationale gets recorded in the System Security Plan. This is the step where a generic Moderate baseline becomes Atlas's control set.

The first tailoring activity, done as part of the RMF Prepare step, is to identify and designate common controls. A common control is implemented once by a common control provider — at the organization level — and inherited by many systems.

For Atlas, the agency's provider (Priya's team) already runs facility protection, identity services, and incident response. Atlas doesn't re-implement those; it inherits them and points to the provider in its SSP.

Designating common controls reshapes responsibility: it shrinks what each system owner must build and prove, and concentrates shared protections where they're maintained centrally. What remains after inheritance — the system-specific and hybrid controls — is the real scope of the system owner's work.

Scoping considerations let you eliminate unnecessary controls from the baseline so you select only what provides protection commensurate with risk.

Some controls in a baseline assume a condition that may not exist in your system. A control about wireless access doesn't apply to a system with no wireless. A control about mobile devices is moot if none are used. Scoping is the documented judgment that such a control is not applicable here.

The discipline matters: scoping is removing what doesn't apply, with a recorded rationale — not dropping controls you'd simply rather not do. Done right, it focuses effort on the protections that actually reduce your risk.

Sometimes a baseline control is technically infeasible or its implementation would harm the mission or business. Rather than drop the protection, you select a compensating control — an alternative that provides equivalent security or privacy protection by another method.

The bar is equivalence, not convenience. A compensating control must deliver comparable protection and be documented with a rationale: why the baseline control couldn't be used, and how the substitute achieves the same outcome.

The classic case: AC-11 (Device Lock) can't be configured on a specialized appliance, so the team compensates with physical access controls (PE-3) that limit who can reach it — equivalent protection by another means.

This is the difference between compensating and scoping. Scoping removes a control that doesn't apply. Compensating keeps the need and meets it a different way. Both are legitimate; confusing them — dropping a needed control and calling it scoping — is not.

Many controls and enhancements contain assignment and selection operations — open slots called Organization-Defined Parameters (ODPs). Tailoring means assigning values to them so the control specifies a concrete requirement for your system.

An assignment ODP is a fill-in-the-blank: review accounts every [Assignment: frequency] → you set "every 30 days." A selection ODP is a choose-from-list: [Selection: restrict; prohibit] → you pick one. Until you fill them, the control isn't fully defined.

For Atlas, the Moderate baseline includes controls with ODPs like password length, log-retention period, and review frequency. Assigning those values is how Atlas's control set stops being generic text and becomes testable requirements the assessor can later check.

A baseline is a minimum, so tailoring also goes the other direction. Supplementing the baseline means adding controls or enhancements beyond it to address specific threats to the organization, the mission, or individuals' privacy — driven by your risk assessment.

If Atlas faces a threat the Moderate baseline doesn't fully cover — say, a targeted attack pattern on grant fraud — the team adds the controls that address it, even though they're above the baseline minimum.

Tailoring also includes providing additional specification for implementation. Controls state what outcome is intended, not how to achieve it, so you add the detail that defines the intent for your system and makes the control unambiguous to implement and assess. Together, supplementing and specifying ensure the final set both covers your real risks and is concrete enough to act on.

Every tailoring move is a risk decision. While the focus is security and privacy, the decisions are made alongside the other realities organizations must manage — cost, schedule, and performance.

Removing a control via scoping, substituting a compensating control, or supplementing with extra controls each changes the risk picture and the budget, timeline, and mission impact. Tailoring is where those are weighed together.

That's why tailoring decisions are documented with rationale in the SSP. The point isn't to minimize controls or to maximize them — it's to land on a defensible set where the protection is commensurate with risk and the trade-offs were made on purpose, not by accident. An authorizing official reviewing Atlas should be able to see why each tailoring choice was made.

Tailor the Atlas Grants Portal (Moderate, plus the privacy baseline). System owner Marcus starts from the Moderate security baseline.

First, common controls: Atlas inherits facility protection, identity, and incident response from Priya's provider team — those leave Atlas's scope entirely (documented as inherited in the SSP). Next, scoping: Atlas has no wireless and no mobile devices, so those baseline controls are marked not applicable, with rationale. Then ODPs: Dana assigns values — 30-day account review, 90-day log retention, 12-character minimum passwords. One control, full disk encryption on a legacy appliance, is technically infeasible, so Marcus selects a compensating control (network segmentation + monitoring) that gives equivalent protection. Because Atlas processes applicant PII, Tom layers in the privacy baseline, and the risk assessment flags grant-fraud exposure, so the team supplements with a couple of extra controls.

The result: a tailored baseline that's smaller in some places (scoped, inherited) and larger in others (supplemented), every change recorded with rationale. That's Atlas's real control set — your turn to make one of these calls.

Lesson 5 — Capabilities (~6 min)

Protection rarely comes from one control — think in capabilities.

Explain a capability as a set of mutually reinforcing controls and why it helps selection.

Satisfying a security or privacy requirement seldom comes from a single control. It comes from a set of mutually reinforcing controls working together — a capability.

Take "control who can access the system." No single control delivers it. Identification and authentication, account management, access enforcement, and least privilege together form the access-control capability. Remove one and the others weaken.

Using the capability construct as you select controls helps in two ways: it groups related controls so you don't select them in isolation, and it makes the purpose visible — you're buying an outcome (controlled access), not ticking off line items. It also frames assessment later: you judge whether the capability holds, not just whether each control exists on paper.

Lesson 1 — The Baseline Tables (~9 min)

The baselines live in tables — learn to read an 'x' and the exceptions.

Read the SP 800-53B baseline tables, the CPRT view, and the PM-family exception.

The baselines aren't prose — they're tables. Tables 3-1 through 3-20 in Chapter 3 of SP 800-53B identify the controls specified for the privacy baseline and the security baselines in each of the 20 control families.

Reading one is mechanical: find the control's row, then read across the columns. A mark in the Low, Moderate, or High column means that control (or enhancement) is in that baseline; a blank means it isn't. Higher baselines generally include everything the lower ones do, plus more.

So "is AC-2 in the Moderate baseline?" is answered by finding AC-2's row in the AC family table (3-1) and checking the Moderate column. These tables are the authoritative source for what each baseline contains.

The same baseline data is published interactively in the NIST Cybersecurity and Privacy Reference Tool (CPRT). Whether you read the SP 800-53 family list or the SP 800-53B dataset, each control shows its baseline allotment — which of Low, Moderate, High (and privacy) it belongs to — right next to the control text.

This is usually the practical way to work: search a control, see its allotment and its full text together, and export the set you need. It's the same authoritative content as the tables, kept current and machine-readable.

The takeaway is simply where to look: the SP 800-53B tables and the CPRT are two views of one truth about what each baseline includes. For a real system, the CPRT is typically the faster path.

There's an exception to every rule. Table 3-13, for the Program Management (PM) family, specifies that those controls are not applied at the system level. Instead they're captured in an organization-wide information security and/or privacy program plan.

PM controls are deliberately program-level — things like the risk management strategy, the enterprise architecture, and the program plans themselves. They protect the whole organization, so it makes no sense to implement them inside each individual system.

Practically: don't go looking for PM controls in your system's tailored baseline. A system inherits the benefit of the PM program, but the controls are owned and documented at the program level. (FedRAMP and others handle a few families similarly — the principle is the same: some controls belong to the program, not the system.)

Lesson 2 — Updates, Overlays & SCOR (~8 min)

Baselines aren't frozen — they update, and overlays customize them for whole communities.

Explain how baseline updates affect a system, what an overlay is, and the role of SCOR.

Baselines change over time. As controls in the SP 800-53 catalog are added, revised, or withdrawn, the baselines may change with them: a control might be added to a baseline, moved to a higher baseline, or removed.

When that happens to a baseline your system uses, it's a prompt to re-evaluate — not to mechanically apply the diff. A control newly added to the Moderate baseline should be assessed for your system; one that moved up may now be above your level; a withdrawn control's protection may have folded into another control you already have.

This is why control selection is never truly "done." The Monitor step watches for exactly these changes, and a baseline update is one of the events that can send a system back to reconsider its tailored set.

Just as a baseline is an initial control selection, an overlay is an initial collection of controls customized for a specific context — a community of interest, a technology, an environment, or a mission type.

Think of an overlay as pre-done tailoring for a recognizable situation. Instead of every cloud system, or every medical-device system, or every classified system independently making the same tailoring decisions, an overlay captures them once: this is the set, already adjusted, for this kind of system.

You still tailor an overlay to your specific system, but you start from a much closer fit than the generic baseline. Overlays turn one team's hard-won tailoring into a reusable asset for everyone facing the same conditions.

Overlays are shared in one place: the Security and Privacy Control Overlay Repository (SCOR), a public repository maintained by the NIST RMF team.

SCOR holds overlays created and submitted voluntarily by government agencies, the private sector, and subject-matter experts. Before you tailor a baseline from scratch for a common kind of system, it's worth checking SCOR — someone may have already published a vetted overlay for exactly your context.

It also works the other way: if your organization develops a strong tailored set for a recognizable situation, you can contribute it back. SCOR is how the community's tailoring knowledge accumulates instead of being re-derived in every program.

Put it together. A control baseline is your starting point for selecting controls from the SP 800-53 catalog. You pick the security baseline from your FIPS 199 categorization, add the privacy baseline if you process PII, and account for the baseline's built-in assumptions.

Then you tailor: designate common controls to inherit, scope out what doesn't apply, compensate where a control is infeasible, assign ODP values, and supplement for risks the baseline misses — every choice a documented risk decision recorded in the SSP. Think in capabilities, read the baseline tables (or the CPRT), mind the PM exception, and reuse overlays from SCOR where they fit.

The product is a tailored baseline — your system's real, defensible control set — that then flows into Implement and Assess. And because baselines update, you revisit it over the system's life rather than treating it as finished.