A NIST SP 800-53 baseline is a generic answer. It was selected for every system at a given impact level, not for yours. Tailoring is how you turn that generic set into a control set that fits your system, your environment, and your risk.
It is also the step most often done badly. Some teams treat tailoring as permission to drop controls they find inconvenient. Others never tailor at all, and spend months implementing controls that do not apply. This article covers what NIST SP 800-53B says tailoring involves, how to make each kind of decision, and how to write it down so that an authorizing official or assessor accepts it. It assumes you have already selected a baseline.
What tailoring is, and what it is not
Tailoring modifies a baseline so that it aligns with the system's mission, operating environment, and assessed risk. It can remove controls, add them, or change how they are met. The output is a tailored baseline, documented in the system security plan and approved by whoever authorizes the system.
Tailoring is not a waiver. Removing a control requires a reason grounded in the system as it is, such as "this system has no wireless capability." It cannot be "we have not got to it yet." That belongs in a plan of action and milestones.
Tailoring also has limits set from outside. Controls required by law, regulation, or policy cannot be tailored out. Authorization programs often constrain tailoring further. FedRAMP, for example, publishes its own baselines with parameter values already assigned. If you work inside a program, read its rules on what a provider may change before you start.
The tailoring activities in NIST SP 800-53B
800-53B describes tailoring as a set of activities. Work through them in this order, because each one depends on the one before.
Identify and designate common controls. Find controls that another entity provides and your system inherits, such as physical security from a data center or a policy set from your organization's program.
Apply scoping considerations. Decide which controls, or which parts of them, apply to this system given its technology, environment, and purpose.
Select compensating controls. Where a baseline control cannot be implemented, choose an alternative that provides comparable protection.
Assign values to organization-defined parameters. Fill in every frequency, threshold, role, and selection the remaining controls leave open.
Supplement the baseline. Add controls or enhancements that your risk assessment, threat information, or obligations call for.
Provide specific information for implementation. Add any detail the implementer needs that the control statement leaves out.
The rest of this article takes the activities that generate the most questions.
Scoping: deciding what applies
Scoping considerations are the legitimate reasons a control, or part of one, does not apply. 800-53B discusses several kinds. In practice the common ones look like this:
Technology. A control about a technology the system does not use. Wireless access controls for a system with no wireless capability, or mobile device controls for a system no mobile device can reach.
Physical infrastructure. Physical and environmental controls for facilities the system does not occupy, when a provider operates them. These usually become inherited rather than removed.
Public access. Some controls behave differently for a system that the public uses anonymously, such as identification requirements for a public information site.
Allocation. A control may apply only to certain components. Write down which, rather than declaring the control applicable or inapplicable to the whole system.
Two habits keep scoping honest. First, scope at the level of control parts, not only whole controls: many controls apply in part. Second, state the fact that makes the control inapplicable, so a reviewer can verify it. "Not applicable: the system has no wireless network interfaces, and wireless is disabled at the hardware level on all components" can be checked. "Not applicable" cannot.
Assigning parameter values
Organization-defined parameters are where most of the real decisions live. A control that says to lock a device after an organization-defined period of inactivity is not implementable until someone picks the period.
Values come from a hierarchy. A program such as FedRAMP may assign them. If not, an agency may. If not, your own organization sets them, ideally once, in policy, so every system uses the same value. Three rules help:
Set values from risk, not from your current configuration. Choose the value you can defend, then configure systems to meet it. Working backward from whatever is configured today is easy to spot.
Keep values consistent across documents. The same parameter should read the same in your policy, your system security plan, and your configuration standard. Assessors compare them.
Respect the floor. If a program assigns a value, you can usually be stricter but not looser.
Compensating controls
A compensating control is an alternative used when a baseline control cannot reasonably be implemented as written. It is not an alternative for one you would rather not implement.
Say a hypothetical system includes a legacy component that cannot enforce account lockout after failed logons, which is what AC-7 asks for. The compensating approach might place that component behind an access gateway that enforces the lockout, restrict network access to the gateway alone, and alert on repeated failures at the gateway. The record should state:
the baseline control and why it cannot be implemented as written
the compensating control and the 800-53 controls it draws on
how it provides comparable protection against the same risk
the residual risk, and who accepted it
An authorizing official decides whether the compensating control is adequate. Expect to explain it in person.
Common and inherited controls
Designating common controls is the activity that saves the most effort, and the one that causes the most assessment findings when done loosely.
A control is inherited when another entity implements it and your system relies on it entirely. It is hybrid when the other entity implements part and you implement the rest. Cloud infrastructure is the usual example: physical protection is inherited from the provider, while access control to your accounts is yours, and encryption at rest is often hybrid.
For each inherited or hybrid control, record who provides it, the evidence that they do (an authorization, an assessment report, a contractual commitment), and precisely which parts remain yours. "Inherited from our cloud provider" for a whole family is the most common overreach. Provider responsibility matrices exist to settle exactly this.
Overlays
An overlay is a published set of tailoring decisions for a community, a technology, or a type of information. 800-53B describes how overlays are built and applied. If one exists for your situation, apply it before your own tailoring, and record that you did. It saves you from re-deriving decisions others have already worked out and reviewed.
Recording tailoring decisions
Tailoring that is not written down did not happen, as far as an assessor is concerned. For each decision, record:
- Not done:
the control or control part affected
- Not done:
the decision: removed, inherited, hybrid, compensated, supplemented, or parameter assigned
- Not done:
the rationale, stated as a verifiable fact about the system
- Not done:
the evidence that supports it
- Not done:
who approved it, and when
- Not done:
what change would make you revisit it
The last item is the one people skip. A scoping decision based on "no wireless" stops being valid the day someone adds a wireless access point. Tie each decision to the change that would invalidate it, and review tailoring when the system changes, not only at reauthorization. Our NIST 800-53 framework page has more on how the baselines and catalog fit together, and the families overview explains how controls and enhancements are numbered.
How TrustLynce helps
TrustLynce records tailoring decisions against each control, with the rationale, evidence, and approver attached, and maps inherited controls to the providers they come from. When a control changes status, the decision history stays with it. See control mapping.