SP 800-53 Control Tailoring: A Daunting Task Made Systematic

SP 800-53 Rev 5 contains 20 control families and over 1,000 controls and control enhancements. When a practitioner first looks at this list with the task of "tailor this to your system," it's reasonable to feel overwhelmed. Where do you start? What can you legitimately exclude? What requires organizational sign-off? What are the rules?

The good news: tailoring is a defined process with documented rules in SP 800-53B. Once you understand those rules, the task changes from "figure out which of 1,000 controls apply" to "apply a four-step decision framework to a curated starting point." That's a much more tractable problem.

What Tailoring Is (and Isn't)

Tailoring is the process of adjusting a selected control baseline to fit a specific system's environment, mission, and risk profile. It is emphatically not removing controls you don't want to implement, reducing scope without justification, or substituting convenience arguments for risk-based decisions.

NIST SP 800-53B states explicitly that tailoring decisions must be documented, justified on risk grounds, and approved by the authorizing official or their designated representative. Tailoring is a documented risk management decision, not an editing pass on a checklist.

The Four Tailoring Actions

SP 800-53B defines the tailoring process; the four actions below draw on it to organize that process into a practical sequence. Applied in order, they turn a baseline into a customized control set. The grouping is a working structure for this article, not a numbered four-step list prescribed verbatim by the standard.

1. Apply Scoping Considerations

Scoping allows exclusion of controls that are not applicable to the system based on its technology type, operational environment, or information type. SP 800-53B defines six scoping considerations: common security controls (inherited rather than system-implemented), operational environment differences, technology type (a system with no removable media may scope out MP-7), public access characteristics, scalability, and relative importance of the CIA security objectives for the specific system.

2. Select Compensating Controls

When a baseline control cannot be implemented as specified, due to technical constraints, operational requirements, or legacy system limitations, a compensating control may be substituted if it provides equivalent protection. Compensating controls require explicit documentation of why the original control is not implementable and how the substitute achieves comparable risk reduction.

3. Supplement the Baseline

Tailoring isn't only about reduction, it also includes adding controls. If your system handles information with higher sensitivity than the baseline assumes, operates in a higher-risk environment, or has specific mission requirements, you should add controls from SP 800-53 Rev 5 that aren't in the selected baseline. Privacy controls from the SP 800-53 Privacy Appendix, the CUI Overlay, the cloud overlay, and sector-specific overlays are common sources of supplemental controls.

4. Assign Organization-Defined Parameter Values

Many SP 800-53 controls contain "organization-defined" parameters, placeholders for values the organization must specify. AC-2(a) requires the organization to define account types to be managed. AU-11 requires the organization to set a retention period. CP-9 requires a backup frequency. These must be set explicitly and documented in the SSP. Leaving them as "organization-defined" without specifying actual values makes the SSP unauditable.

The Inheritance Question

One of the most impactful tailoring decisions, and the most underused, is correctly designating control inheritance. Controls can be Common (implemented by an external entity and inherited by the system), System-Specific (implemented entirely by the system and its owners), or Hybrid (shared responsibility between both). Correctly leveraging inheritance dramatically reduces what must be implemented and documented at the system level.

A system running on a FedRAMP-authorized cloud platform inherits significant portions of physical protection, media protection, and infrastructure controls. These don't need to be re-implemented, they need to be correctly designated and referenced. The cloud provider's Customer Responsibility Matrix (CRM) specifies exactly which controls are fully inherited, hybrid, or customer-implemented.

Overlays: Pre-Built Tailoring for Specific Contexts

SP 800-53B defines several overlays, pre-built tailoring packages for specific contexts that add, remove, or modify controls in the baseline to address a particular risk environment:

• Privacy Overlay: Adds privacy controls for systems processing Personally Identifiable Information. Required for systems subject to the Privacy Act.
• CUI Overlay: A federal tailoring package for systems handling Controlled Unclassified Information. It is the federal-side counterpart to SP 800-171, which NIST derived from the SP 800-53 Moderate baseline for nonfederal organizations. The two cover overlapping protections for different populations: a nonfederal contractor implements 800-171 directly, not this overlay.
• Cloud Overlay: Adjusts controls for shared-responsibility cloud deployment models.
• OT / ICS tailoring (NIST SP 800-82): Guidance for operational and industrial control systems, where availability requirements and patch cadences differ from IT. SP 800-82 Rev 3 supplies an OT control overlay against SP 800-53; note there is no standalone "ICS overlay" in the SP 800-53B catalog the way the Privacy and CUI overlays exist.

Documenting Tailoring Decisions in the SSP

Every tailoring decision, exclusion, compensating control, parameter value, inheritance designation, must be documented in the SSP with enough detail that an assessor can evaluate its appropriateness. Sparse justifications ("not applicable") create findings. Detailed ones ("not applicable, scoping consideration: technology type; system has no removable media capability as confirmed by hardware inventory documented in CM-8") survive assessment.

The System Security Plan tool at Risk Posture Tools structures this documentation control-by-control, with fields for implementation status, responsible entity, inheritance designation, exclusion rationale, and system-specific narrative. Organization-defined parameters are called out explicitly so none are left undefined.

Making Tailoring Decisions Defensible

The test for any tailoring decision: can you explain to an assessor why this decision doesn't create unacceptable gaps in the system's security posture? If the answer is yes and the documentation reflects that reasoning, the decision will hold. If the answer is "it was easier" or "we've always done it this way," it won't.

Tailoring done well is evidence of a mature, risk-aware security program. The authorized baseline isn't the most comprehensive one, it's the most appropriate one for your system and mission. Making that case, with evidence, is what separates authorization packages that succeed from ones that go back for revisions.

Frequently asked questions

What is control tailoring in SP 800-53?

Tailoring is the process of adjusting a selected control baseline to fit a specific system's environment, mission, and risk profile. It is not removing controls you don't want to implement, reducing scope without justification, or substituting convenience arguments for risk-based decisions. Tailoring is a documented risk management decision, not an editing pass on a checklist.

Can I just exclude SP 800-53 controls I don't want to implement?

No. Per SP 800-53B, tailoring decisions must be documented, justified on risk grounds, and approved by the authorizing official or their designated representative. Scoping allows you to exclude controls that are genuinely not applicable to the system based on its technology type, operational environment, or information type, but every exclusion must carry a documented justification.

When can I use a compensating control instead of the baseline control?

A compensating control may be substituted when a baseline control cannot be implemented as specified, due to technical constraints, operational requirements, or legacy system limitations, and only if the substitute provides equivalent protection. It requires explicit documentation of why the original control is not implementable and how the substitute achieves comparable risk reduction. Designating a control as compensating simply to avoid implementation, rather than because of a genuine technical constraint, is a common mistake; assessors are specifically trained to scrutinize compensating control rationales, and a vague justification like "operational requirement" without specifics will not survive assessment.

What is the difference between Common, System-Specific, and Hybrid controls?

Common (inherited) controls are implemented by an external entity such as enterprise IT, a cloud provider, or an organizational common control program, and the system documents them with a reference to the provider's SSP or service description. System-Specific controls are implemented entirely by the system and its owners and require a full implementation narrative in the SSP. Hybrid controls are a shared responsibility, part inherited and part system-specific, documented with a narrative describing each party's portion. Correctly leveraging inheritance dramatically reduces what must be implemented and documented at the system level.

Related reading

• System Security Plan (SSP) Template: Structure, Sections, and a Free Builder
• RMF Simplified: How the Seven Steps Bring Clarity to System Authorization
• CMMC Level 2: What It Demands and How to Know Where You Stand
• the free SSP builder