RMFInsider

RMF Step 2, Select, takes the impact levels from categorization, pulls the matching control baseline from CNSSI 1253 (for DoD and national security systems) or NIST 800-53B (for other federal systems), applies any required overlays, and then tailors the result: removing controls that do not apply, adding controls the risk picture demands, and documenting every one of those decisions. The output is the approved control set your system will implement, assess, and monitor for the life of the authorization. Every hour spent getting it right here is repaid several times over in Steps 3 through 6.

This picks up where the CNSSI 1253 categorization walkthrough left off. If the whole lifecycle is new, the RMF step-by-step guide is the map.

Start with the baseline the categorization gives you

CNSSI 1253 defines baselines per impact level for each of confidentiality, integrity, and availability, which is why DoD baselines are written as three letters (M-M-M, M-M-L, H-M-M). The control set is the union of what each impact level requires. A Moderate-Moderate-Moderate system lands somewhere north of 300 controls and enhancements before tailoring. In eMASS, entering the categorization on the system record generates this baseline automatically. Check it against the CNSSI 1253 tables anyway; instances get updated at different times and a stale baseline table is a real thing that has happened.

Apply overlays before you tailor

Overlays add, remove, or modify controls for a specific system type or data type. Common ones in DoD work:

• Privacy overlay when the system handles PII.
• Classified information overlay for systems processing classified data.
• Intelligence overlay for IC-affiliated systems.
• Space platform, cross-domain, and industrial control system overlays for those environments.
• Cloud (DoD Cloud Computing SRG) considerations by impact level, which behave like an overlay in practice.

Overlays are selectable in eMASS on the system record. Apply them first, because tailoring decisions made against an un-overlaid baseline will be wrong the moment the overlay lands. The AI overlays coming through NIST COSAiS will join this list for systems with AI components.

Tailoring out: removing controls that do not apply

A control can be tailored out when the system has no component or function the control addresses. No wireless means the AC-18 family is not applicable. No mobile devices, AC-19. No public-facing content, AC-22. The test is architectural fact, not convenience. “We don’t want to do that” is not a tailoring justification; it is a future POA&M item.

Each tailored-out control needs a written justification that references evidence: the boundary diagram, the hardware/software list, or the system description in the SSP. In eMASS, that justification goes in the control’s N/A or tailoring rationale field. An SCA reading “Not applicable, the system has no wireless capability per boundary diagram v3 and the hardware list dated 2026-08” will move on. An SCA reading “N/A” with nothing else will open the boundary diagram themselves, and now you are having a conversation you did not want.

Tailoring in: adding controls the baseline missed

Baselines are generic. Your system might face a threat the baseline’s authors did not weight heavily: a public-facing interface on a system categorized Low for confidentiality, an ICS component in an otherwise ordinary enclave, a dependency on a single vendor’s cloud region. Tailoring in means adding controls or enhancements from 800-53 that address those risks. It also means adding organization-specific controls or parameter values your component or program mandates (the DoD-specific parameter values in CNSSI 1253 are already applied by the baseline, but component policy may tighten them further).

SCAs respect a system that tailored in a few controls; it signals someone thought about the actual risk rather than shipping the default. It also front-loads controls that would otherwise appear as findings later.

Compensating controls

When a baseline control cannot be implemented as written (a legacy application that cannot enforce a password policy, a medical device that cannot be patched), you document a compensating control that provides equivalent protection: network isolation, additional monitoring, procedural checks. The compensating control needs its own implementation statement and evidence, and the original control stays in the baseline marked as satisfied through compensation, not tailored out. The difference matters at assessment: tailored out means “does not apply,” compensated means “applies, met differently.”

Identify what will be inherited

Select is also where you mark controls as common (fully inherited), hybrid, or system-specific. Get the inheritance matrix from your hosting provider and enclave now, request the inheritance in eMASS, and you will avoid writing implementation statements for 60 to 100 controls somebody else already owns. How to inherit controls in eMASS is the click path.

Document the tailoring decisions in one place

eMASS holds the per-control rationale, but reviewers want the summary. Add a tailoring section to the SSP (or a standalone tailoring memo) that lists: the categorization and resulting baseline, overlays applied, every control tailored out with its one-line justification, every control tailored in with its rationale, compensating controls, and the inheritance summary. Have the ISSM and, where your process requires it, the AO or SCA sign off on the tailored baseline before you start implementing. A signed baseline ends the “why is this control even here” argument before it starts, which is the most valuable thing a piece of paper can do in this business. The SSP writing guide shows where that section sits.

Select-step mistakes that show up months later

• Tailoring out to shrink the workload. Every control removed without an architectural reason comes back as a finding, now with the added flavor of “and you tried to hide it.”
• Forgetting the overlay. Discovering the privacy overlay applies during assessment adds forty controls to a package that was “done.”
• Not freezing the baseline. If the control set keeps changing during implementation, nobody can say what “complete” means. Freeze it, sign it, and handle changes through the security impact analysis process; how to write a security impact analysis covers that.
• Ignoring parameter values. Many controls have organization-defined parameters (how many failed logins, how many days of inactivity). CNSSI 1253 sets DoD values; your component may tighten them. Record the value you are implementing against on each control.

Output of Step 2, in one list

• Approved, tailored control baseline in eMASS with overlays applied.
• Per-control tailoring rationale entered for every N/A.
• Inheritance requested and inheritance type set on each control.
• Parameter values recorded.
• Tailoring summary in the SSP, signed.
• Continuous monitoring strategy drafted (Select is where 800-37 puts it, even though everyone writes it later).

The RMF Checklist breaks those into the individual tasks, in order, so nothing from Select shows up as a surprise in Assess.