Tailoring Security Controls

The NIST Risk Management Framework (RMF) is a six step process as follows:

  • Categorize both the information and the system based on impact.
  • Select a baseline set of security controls.
  • Implement the controls.
  • Assess the effectiveness of the security controls.
  • Authorize the system to operate.
  • Monitor the ongoing state of protection the security controls are providing.

The second step begins with selecting a baseline of controls. This is done automatically, according to the impact level designated in step 1. The second step continues by tailoring and supplementing the baseline set of controls as needed. In the past, this step has been underutilized. It allows us to change the controls in order to make them work more effectively in the actual operating environment. The baseline set was designed with a general purpose and it should be obvious that the controls need some level of customization for a good fit.

Tailoring of controls is needed because the baseline assignments include some assumptions that may limit the applicability or effectiveness of controls, as follows:

  • Information systems are located in physical facilities
  • User information is relatively persistent
  • Information systems are multi-user
  • Some user information is not shareable
  • Information systems exist in networked environments
  • Systems are general purpose
  • Resources exist to implement controls

When these general assumptions don’t fit the information system or the environment it is operating in, some controls will likely need tailoring to make them fit well. Because of the general nature purpose of the baselines, there may be situations in the security needs of the system that are not addressed by the baseline. Here are some possible examples:

  • Insider threats
  • Classified data on systems
  • Advanced Persistent Threats (APT)
  • Specialized protection requirements
  • Connections across differing security domains

The tailoring process involves the following steps:

  • Designating common controls
  • Applying scoping considerations
  • Selecting compensating controls
  • Assigning specific Organization-Defined Parameters (ODPs)
  • Supplementing the baseline
  • Providing implementation specifications



Common controls can be applied to more than one information system and are often “inherited” by sub-systems that have common security protection needs as the mother system.

Large organizations often have more than one “information system” and these individual systems may require different security control baselines or controls that have been tailored in different ways. But these different systems often “share” some controls that are identical and are managed centrally for the entire organization. These controls can be declared as “common controls”. Common controls can be inherited by more than one system. When common controls are declared, some of the workload of security planning is consolidated, making the process more consistent, more cost effective and easier to achieve and maintain compliance and authorization.

When controls are considered to apply for a single system, they are considered to be “system-specific” controls. When they can apply to more than one system, they are considered to be “common” controls. When some part of a control applies to a single system, while other parts of a control can apply to more than one system, they can be considered as “hybrid” controls. All security controls should be declared as either common, system-specific, or hybrid.

The PM family of controls are considered to be foundational to the rest of the security controls and are NOT considered to be candidates for common controls. The first control in each of the other families is a control about “Policy and Procedure” and these are good candidates for common controls. (eg. AC-1, AT-1, AU-1, CA-1, …)

Common controls:

  • Are centrally managed
  • Can be inherited by other systems
  • Must have responsibilities assigned to either an information system, a system owner, or a group
  • Should be selected on the basis of context, not simply by the language in the control
  • Can have one status for one system and another status for another system

Here is a security control that directly applies to the use of common controls:

The organization centrally manages [Assignment: organization-defined security controls and related processes].

Security control PL-9 (above) is not selected for any baseline and must be added as a supplementary controls during the Tailoring process, if it is to be used. It presents an opportunity to list centrally managed controls and it offers some suggested candidates:

  • AC-2 (0) (1) (2) (3) (4)
  • AC-17 (0) (1) (2) (3) (9)
  • AC-18 (0) (1) (3) (4) (5)
  • AC-19 (0) (4) (6) (8) (9)
  • AC-22 (0)
  • AC-23 (0)
  • AT-2 (0) (1) (2)
  • AT-3 (0) (1) (2) (3)
  • AT-4 (0)
  • AT-5 (0)
  • AU-6 (0) (1) (3) (5) (6) (9)
  • AU-7 (0) (1) (2)
  • AU-11 (0)
  • AU-13 (0)
  • AU-16 (0)
  • CA-2 (0) (1) (2) (3)
  • CA-3 (0) (1) (2) (3)
  • CA-7 (0) (1)
  • CA-9 (0)
  • CM-2 (0) (1) (2)
  • CM-3 (0) (1) (4)
  • CM-4 (0)
  • CM-6 (0) (1)
  • CM-7 (0) (4) (5)
  • CM-8 (all)
  • CM-9 (0) (1)
  • CM-10 (0)
  • CM-11 (0)
  • CP-7 (all)
  • CP-8 (all)
  • SC-43 (0)
  • SI-2 (0) (1)
  • SI-3 (0) (1)
  • SI-7 (0)
  • SI-8 (0) (1)

Most if not all of these controls should be considered as good candidates for common controls.

The importance of common controls is found in the following factors:

  • Increased consistency across systems
  • More cost effective management and measuring
  • Precursor to other tailoring measures
  • Force a clear definition of responsibility



Some controls may not be applicable or appropriate for use in a specific system or operating environment. These controls may need to be modified, or replaced by another control or even eliminated entirely from the baseline. When this is done, any protections lost by changing controls must be included in risk assessment documentation and may need consideration for other methods of mitigation. Under NIST guidance, we are allowed the flexibility to make “explicit risk-based decisions” on how to make scoping changes in order to achieve the needed security requirements. Any scoping changes that are made should be documented in detail in the System Security Plan (SSP) to explain the nature of the change, the risk analysis involved and the rationalization for accepting the final risk posture after the change.

The following areas should be considered for scoping:

    Security controls are applicable only to information system components that provide or support the information security capability addressed by the controls. Some of the controls that are included in the baselines may not apply to some systems or may not apply to some system components.
  • OPERATIONAL ENVIRONMENT – Assumptions about the existence of certain operational/environmental factors are built in to some controls. The baseline may need tailoring when these factors are significantly changed or absent. Here is a list of common operational/environmental factors to consider:
    • Mobility – The basic assumption is that information systems are in fixed locations and non-mobile facilities. If the systems are mobile, the security controls may need tailoring.
    • Single-User Systems and Operations – For systems that are intended to be used by a single user over time, controls that deal with shared access, concurrent access, and other multi-user issues may not be required.
    • Data Connectivity and Bandwidth – Systems that are not networked or have limited networking or bandwidth requirements may not need controls that deal with connectivity. A careful analysis may be required to determine this.
    • Limited Functionality Systems or System Components – Items that may be considered as information systems or system components that have limited capabilities (printers, scanners, cameras, phones, tablets, and more) may also have limited requirements for some controls.
    • Information and System Non-Persistence – Many controls assume there will be some level of persistence involved with both data and the systems themselves. If there is little or no persistence, controls may not be needed. This will particularly apply to controls dealing with storage and backup, but the growing use of virtual machines may also require some attention for this area.
    • Public Access – There may be large differences in the security requirements of information systems that allow public access and those that do not. The areas of Access Control and Identification and Authentication may require close attention.
  • SECURITY OBJECTIVES – While the overall security objectives for information systems are to protect Confidentiality (C), Integrity (I), and Availability (A), individual controls may support only one or two of those objectives. Since we select the overall Impact level for any system using the “high water mark” rule, it becomes possible for a baseline to include controls
    that are not needed or should have a lower level of importance. In those cases, the appropriate controls may be downgraded or eliminated to correspond to the lower impact level baseline. When this is done, the downgrading change must:
    • Reflect the correct impact level for the CIA objectives that are supported.
    • Be supported by an assessment of risk.
    • Not adversely affect the level of protection.

The following controls and control enhancements are candidates for downgrading:

    • Confidentiality: AC-21, MA-3 (3), MP-3, MP-4, MP-5, MP-5 (4), MP-6 (1), MP-6 (2), PE-4, PE-5, SC-4, SC-8, SC-8 (1)
    • Integrity: CM-5, CM-5 (1), CM-5 (3), SC-8, SC-8 (1), SI-7, SI-7 (1), SI-7 (5), SI-10
    • Availability: CP-2 (1), CP-2 (2), CP-2 (3), CP-2 (4), CP-2 (5), CP-2 (8), CP-3 (1), CP-4 (1), CP- 4 (2), CP-6, CP-6 (1), CP-6 (2), CP-6 (3), CP-7, CP-7 (1), CP-7 (2), CP-7 (3), CP-7 (4), CP-8, CP-8 (1), CP-8 (2), CP-8 (3), CP-8 (4), CP-9 (1), CP-9 (2), CP-9 (3), CP-9 (5), CP-10 (2), CP-10 (4), MA-6, PE-9, PE-10, PE-11, PE-11 (1), PE-13 (1), PE-13 (2), PE- 13 (3), PE-15 (1)
  • TECHNOLOGY – Controls that refer to specific technologies are applicable only if those technologies are implemented in the system. Controls do not require automated mechanisms to be developed if they do not already exist. If automated mechanisms are not available, compensating controls are used to meet requirements.
  • MISSION REQUIREMENTS – When a control interferes with or degrades mission or business functions, it may not be applicable or appropriate.

Any protections lost by changing controls must be included in risk assessments and may need consideration for other methods of mitigation

All changes must be justified and documented in the System Security Plan (SSP)



Compensating controls are:

  • Alternative controls to those in existing baselines.
  • Selected after scoping considerations.
  • Used under the following conditions:
    • Baseline 800-53 controls must be used first.
    • Document why the original control could not be used and how the new control provides security protection
    • Assess and accept the risk involved



Organizationally Defined Parameters (ODPs) are embedded in many controls, using “Assignment:” and “Selection:” statements that allow the control to be tailored to the environment and needs of the system.

The following is an example taken from the 800-53 Catalog of Security Controls:


The organization:
a. Identifies, reports, and corrects information system flaws;
b. Tests software and firmware updates related to flaw remediation for effectiveness and
potential side effects before installation;
Installs security-relevant software and firmware updates within [Assignment: organization-
defined time period] of the release of the updates; and

[EXPLANATION: the text “[Assignment: organization-defined time period]” is a parameter that needs to be defined by the organization using the control, according to their requirements.]

ODPs are typically defined after scoping guidance is applied and compensating controls are declared. Once they are declared, they should be included in the SSP.



For needs beyond the standard baselines


  • Advanced Persistent Threat (APT) – CM-5 (4), SC-7 (13), SC-25, SC-26, SC-29, SC-30
  • Connections across security domains – AC-4 control enhancements
  • Mobile devices – AC-7 (2), MP-6 (8)
  • Classified information – AC-3 (5), AC-16, MA-5 (4)

Supplementary controls are used for enhancing security without changing the baseline control selection.

Alternative strategies include:

  • Restrictions on types of technologies
  • Limiting information or the manner of automation
  • Prohibiting external access
  • Prohibiting information on publicly accessible system components



Additional detail may help:

  • Define the intent of a control
  • Ensure security requirements are met

Information may involve:

  • Refinement of implementation details
  • Refinement of scope
  • Iteration that applies a control to different scopes

Comments are closed.