How do you tailor an NIST 800-53 baseline without removing controls you cannot remove?
When a contract, agency or FedRAMP requirement names an SP 800-53B baseline, NIST 800-53 tailoring is the sanctioned way to adjust it to your system. Tailoring works through six defined activities: identifying and designating common controls, applying scoping considerations, selecting compensating controls, assigning values to organization-defined parameters, supplementing the baseline with additional controls or enhancements, and providing specification information for implementation. No control leaves the baseline without a documented, risk-based decision, and every control in the selected baseline must still be accounted for.
Your answer depends on four things. The first is the system impact level, which selects the low, moderate or high baseline and sets the starting point. The second is the mission and business context, since a tailoring decision must be defensible on those needs rather than on cost alone. The third is inheritance: a control that a cloud provider or shared service implements as a common control does not need to be implemented again by your system, but you must confirm the provider's responsibility and how it is documented. The fourth is the legal and agency rule set, because SP 800-53B says it is inappropriate to tailor out controls tied to applicable federal laws, regulations or policies, and OMB may prohibit tailoring specific controls. Confirm those prohibitions with your authorizing official or contracting officer before you draft anything.
Your organization owns every tailoring decision, including the risk acceptance behind any compensating control, and the authorizing official owns the authorization decision. Record each choice and its justification in the system security and privacy plan. An independent assessor will later test those decisions against the SP 800-53A procedures, so a decision without a written rationale becomes a finding. An implementation partner can prepare the baseline worksheets, parameter tables, inheritance matrix and documentation, and can help configure the systems that carry out the chosen controls. The partner does not decide what is tailored out and does not certify the result.
What are the six tailoring activities in SP 800-53B?
The six SP 800-53B tailoring activities take a baseline from a generic starting point to a system-specific control set, with each step producing a record that an assessor can trace back to the baseline and to the organization's risk decisions.
Identify and designate common controls
Start by deciding which controls will be implemented once at the organization level and inherited by systems, rather than built separately into each system. The owner of each common control, usually a shared service or enterprise function, is named and accepted as the control provider. The output is a designated common control list that states the provider, the controls covered and the systems permitted to inherit them. The step is complete when every common control in the list has a named provider and a documented inheritance statement that a system owner can cite.
Apply scoping considerations
Review the baseline against the system's actual environment and remove or mark as not applicable any control whose subject does not exist in the system, such as a component the system does not use. SP 800-53B does not allow controls to be dropped arbitrarily, so each scoping decision needs a written, risk-based rationale tied to mission and business needs. The output is a scoping rationale that lists every baseline control and its disposition, with the reason for each exclusion. The step is complete when every control in the selected baseline is accounted for, with none left unexplained.
Select compensating controls
Where a baseline control is technically infeasible, not cost effective or would harm mission functions, select an alternative that gives equivalent or comparable protection. SP 800-53B expects compensating controls to come from SP 800-53 where possible and to be justified in writing. The organization, not the assessor, must assess the residual risk and formally accept it. The output is a compensating control record that names the original control, the replacement, the protection it provides, and the risk acceptance by the responsible official. The step is complete when each record has a signed acceptance and a rationale an assessor can test.
Assign values to organization-defined parameters
Many controls leave specific values to the organization, such as review frequencies, password settings or event types, through organization-defined parameters. The OSCAL catalog for Release 5.2.0 defines 1,600 such parameters across its active controls and enhancements, so this step is substantial for any system. Each value is set through the assignment and selection operations in the control text. The output is a parameter value register that lists each parameter, its chosen value and the justification. The step is complete when no parameter in the selected controls remains unassigned, and each value matches what the system's implementation and monitoring actually do.
Supplement the baseline with additional controls
Where the risk assessment or an applicable overlay shows that the baseline does not cover a threat, add controls or enhancements from SP 800-53. Because SP 800-53B says tailoring must not remove controls required by applicable laws, regulations or policies, check those requirements before deciding what to add or keep. The output is a supplementation record that lists each added control or enhancement, the threat or requirement that drove it, and the owner responsible for implementing it. The step is complete when each addition traces to a documented risk or requirement and appears in the system security and privacy plan.
Provide specification information for implementation
Translate the tailored control set into implementation guidance for the engineers, administrators and service providers who will build and operate the controls. This includes the specification details that describe how each control is to be met in the system, including inherited common controls, parameter values and any compensating controls in use. The output is a set of implementation specifications that the system security and privacy plan can reference directly. The step is complete when each control in the tailored set has a responsible party, an implementation description, and a clear pointer to the evidence that will later show it works.
Which controls can never be tailored out of a baseline?
No control in the selected baseline may disappear without a recorded decision. SP 800-53B says organizations do not arbitrarily remove controls. Every control in the baseline must be accounted for, and any removal must rest on an explicit, risk-based determination that can be defended in terms of mission and business needs. The decision and its justification belong in the system security and privacy plan, where an assessor and an authorizing official will look for them. A control that is simply absent from the plan, or dropped because it is inconvenient to build, fails this test even if the removal would seem harmless to the engineering team.
Controls tied to applicable federal laws, regulations or policies are the hard limit. SP 800-53B states that it is inappropriate to tailor out a security or privacy control that pertains to an applicable law, regulation or policy. It also notes that OMB may prohibit federal agencies from tailoring specific controls. The practical consequence is that a tailoring workshop cannot settle this question alone. Before any draft decision is written, confirm with the authorizing official, the agency's security office and the contract which controls are fixed for your system, including any controls set by OMB direction, statute or the sponsoring program. Record the answer in writing, because it defines the outer boundary of every other tailoring choice.
Treat the fixed list as an input to tailoring, not a conclusion. Ask the authorizing official for the list of non-removable controls, the reasons behind each one, and whether any parameter values or enhancements are also fixed. Then check the proposed tailoring plan against that list line by line. Where a fixed control cannot be implemented as written, the correct route is an agreed compensating control or a formal risk acceptance, not silent removal. Guidance on those alternatives appears elsewhere on this page, and the authorizing official owns the decision either way.
Common controls, compensating controls and parameter values: how each one changes the baseline
A baseline from SP 800-53B is a starting point, and tailoring changes what a specific system must implement. The four cards below cover the tailoring moves that change the control set most often, and each one shifts who does the work and what the assessor will ask to see.
Common controls and inheritance
A common control is implemented once by an internal or external provider, and systems that inherit it do not implement it themselves. The organization that designates a common control owns its implementation and must give inheriting systems a precise description of what the control covers and what remains with each system owner. Check that the provider's assessment covers the control, that the inheriting system's plan names the provider, and that the responsibility split is written down. Under SP 800-53B, the more controls implemented as common controls, the greater the potential savings, because protection is amortized across many systems. The assessor will ask for the provider's control description, the inheritance statement in each system security plan, and the assessment results for the common control.
Scoping considerations
Scoping removes baseline controls that do not apply to the system's actual function, environment or information. Examples include controls for a hardware component the system does not contain or a service it does not use. Scoping is not a way to drop controls that reflect applicable federal laws, regulations or policies, and SP 800-53B says those cannot be tailored out. The system owner documents each scoped-out control with a reason tied to the system's boundary and technology, and the authorizing official reviews the decision. Assessors will check that every baseline control is accounted for and that each exclusion matches the system as it is actually built.
Compensating controls and accepted risk
A compensating control replaces a baseline control that is technically infeasible, not cost effective or harmful to mission functions. It must give equivalent or comparable protection, come from SP 800-53 where possible, and carry a written rationale. The organization that proposes it owns the justification, and the authorizing official must assess and accept the residual risk. Check that the compensating control addresses the same threat as the original, that its limits are stated, and that the risk acceptance is recorded with an expiry or review point. The assessor will ask for the rationale, the risk assessment supporting it, the signed acceptance and the test results showing the compensating control works.
Organization-defined parameters and their values
Many controls leave a value for the organization to set, such as a password lifetime, a review frequency or a retention period. The SP 800-53 Release 5.2.0 OSCAL catalog defines 1,600 such parameters across 1,014 active controls and enhancements, and the system owner sets each value through the assignment and selection operations in the control text. Each value must be specific enough to test and consistent across the system security plan, configuration baselines and monitoring tools. Check that every parameter in the selected baseline has a value, that values are not left at a generic placeholder, and that they match what the technology actually enforces. The assessor will compare the stated values against configuration evidence and logs.
Supplemented controls and enhancements
Supplementation adds controls or enhancements beyond the selected baseline when the risk assessment shows a gap, for example when the threat environment or mission requires stronger protection. Each added control needs the same specification as baseline controls: an owner, an implementation statement and an assessment path. The additions often reflect overlay guidance or regulatory expectations for the sector. Check that each supplemented item traces to a risk finding or a stated requirement, and that the added work is funded and assigned. The assessor will expect the added controls in the plan, the rationale for each addition and evidence that they operate, just as they would for baseline controls.
Where each tailoring decision is recorded and who signs it
This table maps each SP 800-53B tailoring activity to the record that holds it, the owner who approves it and what an assessor will check. Read it as a trail: organization-level decisions sit in the organizational baseline documentation, system-level decisions sit in the system security and privacy plan, and both must agree with the assessment record. Confirm the required format and sign-off path with the authorizing official or contracting agency before you build the records.
| Tailoring activity | Record that holds it | Owner who approves it | What an assessor will check |
|---|---|---|---|
| Identifying and designating common controls | Organizational baseline documentation and the common control inheritance statement in each dependent system security and privacy plan | Common control provider's authorizing official, with acceptance by each inheriting system's authorizing official | The provider's implementation is documented, the inheriting system names the control, and the provider's assessment covers it |
| Applying scoping considerations | Organizational tailoring record (SP 800-37 Task P-4) and the scoping rationale in the system security and privacy plan (Task S-2) | Organization-level risk executive for organizational scoping, authorizing official for system scoping | Each scoping decision is tied to mission or business needs, is risk-based and does not remove a control required by law or policy |
| Selecting compensating controls | Compensating control rationale in the system security and privacy plan, with the residual risk statement | Authorizing official, who must assess and accept the resulting risk | The baseline control is technically infeasible, not cost effective or mission-harming, and the alternative gives equivalent protection |
| Assigning organization-defined parameter values | Parameter values recorded in the control implementation statements and the system security and privacy plan | System owner proposes values; authorizing official accepts them | Each parameter has a value, the value matches the stated policy, and the assessment procedure uses the same value |
| Supplementing baselines with additional controls or enhancements | Additional controls listed in the system security and privacy plan with the risk justification that drove the addition | Authorizing official, on recommendation from the information system security officer | The added control is implemented and assessed, and the reason for adding it traces to a threat or requirement |
| Providing specification information for implementation | Control implementation statements and supporting technical specifications stored with the system documentation | System owner and security engineering lead | Specifications match the deployed configuration and the control's assessment objects can be examined |
| Tailoring out a control (where allowed) | Explicit risk-based determination in the system security and privacy plan, with every baseline control still accounted for | Authorizing official, after confirming no applicable law, regulation or OMB restriction applies | The removal is defensible, is not a control tied to applicable federal law or policy, and appears in the plan |
| Adopting an overlay or a community baseline | Overlay reference and any local tailoring recorded in the system security and privacy plan and the organizational baseline | Authorizing official, with the overlay owner's requirements confirmed with the contracting agency | The overlay version used is named, its tailoring is documented, and the assessment covers the overlay's controls |
Should tailoring happen at the organization level, the system level or both?
Organization-level tailoring produces one tailored baseline that many systems reuse. A central function, usually the risk executive or a security architecture group, decides which baseline controls apply across the enterprise, assigns parameter values once, and designates which controls are common controls provided to every system. This model suits shared services, identity platforms, logging infrastructure and common control providers, where the same protection should behave identically wherever it is inherited. SP 800-53B notes that a system inheriting a common control does not implement that control itself, and that the more controls are implemented as common controls, the greater the potential savings because protection is spread across many systems.
- Ownership: The central risk function owns the baseline and its parameter values, and each system owner accepts that baseline when authorizing.
- Documentation: The tailored baseline is recorded once as an organization-level artifact, and each system security and privacy plan points to it rather than restating it.
- Typical risk: A central value set that fits most systems may not fit a high-impact system, and that gap is easy to miss when no one checks the local plan.
- Common control records: Each common control needs a documented provider, scope and inheritance statement that the inheriting system can cite.
- Ask a partner or assessor: Which controls will be common, who signs the inheritance statements, and how changes to the central baseline reach systems already authorized.
Before committing, confirm that the central baseline is documented well enough that an assessor can trace each inherited control to its provider and to the parameter values in use.
System-level tailoring starts from a baseline and adjusts it for one system's mission, authorization boundary and data. The system owner and authorizing official decide which controls are added, which compensating controls replace infeasible ones and which parameter values fit that system's risk. This is the most precise model, because the decision reflects the actual boundary, data types and threats of the system. It is also the model where undocumented or inconsistent choices accumulate fastest, since each system team can reach a different answer to the same question.
- Ownership: The system owner proposes tailoring decisions, and the authorizing official accepts the residual risk.
- Documentation: Every deviation, addition and parameter value appears in that system's security and privacy plan with a stated rationale.
- Typical risk: Two systems holding the same data class may end up with different password lengths or log retention periods, with no recorded reason for the difference.
- Compensating controls: Each compensating control needs a rationale showing comparable protection, and the risk it leaves must be accepted explicitly.
- Ask a partner or assessor: How many systems share each data class, which parameter values are fixed by policy, and what the assessor will require to justify each deviation.
Before committing, confirm whether any tailoring decision is already fixed by applicable law, regulation or agency policy, because those controls cannot be tailored out at either level.
The combined approach uses an organization-level baseline as the default and lets each system record only its deviations. SP 800-53B states that tailoring can be done at the organization level, the system level or both, and both is common in practice because it gives shared controls a single source while still allowing local decisions. The organization sets defaults and parameter values, and each system's plan lists where it differs and why. The reviewer then checks one reference point plus a short list of exceptions, rather than rebuilding the baseline for every system.
- Ownership: The central function owns defaults, and system owners own deviations, with the authorizing official accepting each deviation's residual risk.
- Documentation: The organization-level baseline is referenced by each plan, and each plan carries a deviation table showing the control, the change and the justification.
- Typical risk: Deviations accumulate without review, so the default stops describing what systems actually do.
- Review cadence: Deviations should be revisited when the central baseline changes, when a system changes boundary, and at each reauthorization.
- Ask a partner or assessor: Whether the assessor will accept a referenced default baseline, what format the deviation record should take, and who approves a deviation before it is implemented.
Before committing, confirm that every system plan can show the same default, the same deviation list and the same approver, so that an assessor can test the model from either end.
How do overlays package tailoring for whole communities?
An overlay is a fully specified set of controls, enhancements and supporting parameter values that serves a community of interest, a technology or an environment rather than one system. SP 800-53B Appendix C describes it as derived either by tailoring an existing baseline or by building a set independently. The example categories it lists include industry sectors such as healthcare and finance, technologies such as cloud and industrial control systems, environments such as space, threat types such as insider threats, and statutory requirements such as HIPAA, FISMA and the Privacy Act. For an organization, an overlay matters because it moves tailoring decisions from each system's security plan into a shared, reviewable document. If your agency or contract names a sector or technology overlay, start by reading its applicability section and comparing its parameter values with the baseline you already selected.
NIST's Security Control Overlay Repository lists three published overlays based on SP 800-53 Rev. 5: SP 800-161 Rev. 1 for supply chain risk management, SP 800-82 Rev. 3 for operational technology, and SP 800-171 Rev. 3 for controlled unclassified information. The SP 800-171 Rev. 3 overlay shows tailoring at scale. It starts from the SP 800-53B moderate baseline and removes controls marked as primarily a federal responsibility, controls not directly related to CUI confidentiality, controls adequately covered by other controls, and controls that do not apply. Each removal is a documented decision, so a contractor can trace why a control in the moderate baseline does not appear in its requirement set. Use that same pattern, with each removal recorded against its reason, when you tailor a system from a published overlay.
NIST's COSAiS project is developing SP 800-53 control overlays for securing AI systems, with planned use cases covering generative AI assistants, predictive AI, single-agent and multi-agent systems, and AI developers. NIST has released a concept paper and a predictive AI annotated outline, but its project page listed no initial public draft overlay as of October 2026. Do not plan an ATO schedule, budget or contract clause around these overlays until a draft or final version is published. Check the COSAiS project page before each planning cycle, and in the meantime tailor the moderate or high baseline for AI systems with documented, risk-based decisions that you can later reconcile with the published overlay.
Common questions about tailoring and overlays
Can we drop a control we consider not applicable to our system?
Only with a documented, risk-based decision that the organization can defend on mission and business grounds. SP 800-53B does not let organizations remove controls from a baseline arbitrarily: every control in the selected baseline must be accounted for, and the decision and its justification belong in the system security and privacy plan. Controls that pertain to applicable federal laws, regulations or policies cannot be tailored out, and OMB may prohibit tailoring specific controls for federal agencies. Ask your authorizing official or compliance lead which controls are off limits for your system before any scoping work starts.
What must a compensating control show to be accepted?
A compensating control must give equivalent or comparable protection to the baseline control it replaces, and it is only justified when the baseline control is technically infeasible, not cost effective or harmful to mission functions. SP 800-53B expects compensating controls to be drawn from SP 800-53 where possible and to come with a written rationale. The organization must then assess the resulting risk and formally accept it, which is a management decision rather than a technical one. An assessor will test whether the rationale holds and whether the risk acceptance is recorded, so treat both as evidence to prepare in advance.
Does an overlay replace the baseline for our system?
No. An overlay is a fully specified set of controls, enhancements and parameter values built for a community of interest, technology or environment, and it adjusts the baseline rather than replacing it for every system. SP 800-53B gives examples such as healthcare or finance sectors, cloud or industrial control systems, and statutory requirements such as HIPAA. Published overlays include SP 800-171 Rev. 3 for controlled unclassified information, which starts from the moderate baseline and removes or reassigns controls. Check which overlays your authorizing body or contract references, then confirm with them how that overlay combines with the baseline you selected.
Can our implementation partner make the tailoring decisions for us?
No. The organization owns its tailoring decisions, and the authorizing official accepts the residual risk they create. An implementation partner can analyze the system, draft proposed tailoring with rationale, document parameter values, and prepare the evidence that supports each decision. The organization then reviews, approves and signs off on those choices. Ask any partner to show how it will route decisions to your risk owners and record them in the system security and privacy plan, and confirm in the written scope which decisions remain with your staff.
How does tailoring change the effort of an assessment?
Tailoring changes what the assessor tests, so every decision needs enough documentation for an independent reviewer to trace it. An assessor will check whether each removed, supplemented or compensated control has a stated basis, whether parameter values are set and consistent, and whether common controls inherited from another provider are backed by that provider's evidence. Undocumented or inconsistent tailoring usually produces findings that take longer to resolve than the decision itself. Structure your tailoring record around the SP 800-53A procedures so the assessor can follow each decision to its test result.
Do we need AI overlays for our AI systems today?
Confirm the current status before relying on them. NIST's COSAiS project is developing SP 800-53 control overlays for securing AI systems, covering use cases such as generative AI assistants, predictive AI, single-agent and multi-agent systems, and AI developer controls. NIST has released a concept paper and a predictive AI annotated outline, but its project page listed no initial public draft overlay as of October 2026. Until a final overlay is published, you can tailor the standard baseline for your AI system, document the AI-specific risks you have identified, and track the COSAiS project for updates that may change your tailoring.
What usually causes tailoring to fail review, and how to avoid it
Assessors and authorizing officials usually reject tailoring for the same few reasons: decisions that were never justified, baseline controls that disappear from the record, and overlays or inherited controls applied without checking. Each card below names one failure mode, the fix, and the document where the fix should be recorded so a reviewer can trace it.
Removing controls without a risk-based determination
A control is dropped from the baseline because it looks inconvenient, costly or unfamiliar, with no explanation tied to mission or business needs. SP 800-53B requires tailoring decisions to be defensible on mission and business needs with explicit risk-based determinations. Before removing anything, record the risk reasoning, who accepted it, and why no applicable law or policy requires the control. Record the decision in the system security and privacy plan.
Baseline controls left unaccounted for
Tailoring tables often list the controls that were changed but not the ones left alone, so a reviewer cannot tell whether the full baseline was considered. SP 800-53B expects every control in the selected baseline to be accounted for. Build a control-by-control register that shows each baseline control as retained, tailored, inherited as common, or replaced by a compensating control, and check that the register totals match the baseline before submission.
Copying an overlay without checking applicability
Teams adopt an overlay because it sounds relevant, such as an operational technology or AI overlay, without confirming that their systems fall within its stated community, technology or environment. An overlay is a fully specified set of controls meant for a defined audience, so mismatched use creates gaps and false claims. Compare the overlay's applicability section against the system boundary and record the reasoning in the plan.
Undocumented parameter values
Organization-defined parameters govern how often reviews happen, how long accounts stay idle and how quickly flaws get fixed, and leaving them blank or unexplained makes many controls impossible to assess. Assigning values is a tailoring activity in its own right. Set a value for each parameter the system uses, state the rationale, and keep the values consistent with the policies that actually run the system. Record them in the plan and the control implementation statements.
Compensating controls without rationale or accepted risk
A compensating control is substituted for a baseline control, but the file never shows why the original was infeasible, not cost effective or harmful to mission functions. SP 800-53B requires equivalent or comparable protection, a rationale, and an explicit risk acceptance by the organization. Document the infeasibility reason, map the substitute to the original control's protective intent, and obtain the authorizing official's written acceptance of the residual risk. Record it in the plan of action and milestones or the risk acceptance record.
Inconsistent decisions across shared common controls
When several systems inherit one common control, each system may describe it differently, or one system may tailor a parameter the provider never agreed to. An assessor then finds that the inherited control does not mean the same thing everywhere. Keep one authoritative description of each common control in the provider's documentation, and have every inheriting system's plan reference that description and its parameter values. Reconcile the inheriting plans whenever the provider changes a value.
How DeployOpen prepares tailoring documentation and evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares the tailoring records, system configuration and evidence that your organization and its independent assessor review. DeployOpen does not make tailoring decisions on your behalf or issue assessment reports.
How we scope
- Each engagement starts with a written scope listing the baseline, systems, overlays and tailoring decisions covered.
- We confirm which controls are organization-level, system-level or common controls before any build work begins.
- Scope, deliverables and timelines are agreed in writing, and a quote follows from that written scope.
How we build
- We configure parameter values and compensating control settings on the platforms in scope and record each setting.
- We map every control in the selected baseline to a tailoring decision, a platform setting or an inherited common control.
- We test the configured controls against the agreed assessment objectives so gaps are found before an assessor arrives.
How we hand over
- You receive tailoring records that show each decision, its risk-based justification and the owner who accepted it.
- Documentation is delivered in formats your system security and privacy plan team can reference and maintain.
- Handover includes a walkthrough so your staff can explain configurations to assessors and the authorizing official.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers when your overlays or baselines change.
- We can update tailoring records when NIST releases new SP 800-53 versions or overlay drafts, within the agreed scope.
- Confirm with DeployOpen in writing which support, testing and update tasks sit inside any retainer before signing.
