Category: Security Controls & Tailoring

Common Controls

Also known as: Inherited Controls, Inheritable Security Controls

Simply put

Common controls are security protections put in place once at an organizational or enterprise level and then reused, or 'inherited,' by multiple information systems instead of each system building its own version. This approach lets many systems rely on a shared safeguard rather than duplicating the same effort separately. Note that the vendor product usage of 'common control' in software development is unrelated to this cybersecurity meaning.

Formal definition

As defined by NIST, a common control is a security control that is inherited by one or more organizational information systems. Responsibility for a common control's development, implementation, assessment, and monitoring generally rests with a designated common control provider, an organizational official accountable for that control's lifecycle. Inheritance does not eliminate a system owner's responsibility to confirm that an inherited control adequately addresses the receiving system's specific requirements, and residual or system-specific portions of a partially inherited (hybrid) control typically remain the receiving system's responsibility. Practitioners should verify the current authoritative definitions and any applicable tailoring against the relevant NIST and CNSS publications, as terminology and control baselines evolve across revisions.

Why it matters

Common controls are a foundational efficiency mechanism in the Risk Management Framework (RMF) and similar authorization processes. Rather than requiring every information system to independently design, implement, assess, and monitor safeguards such as physical facility protections, personnel security screening, or enterprise-wide network defenses, an organization can establish these once and allow multiple systems to inherit them. This reduces duplicated effort, promotes consistency across an organization's security posture, and can streamline the assessment burden when a system pursues its authorization.

The concept also introduces accountability that practitioners must handle carefully. Because responsibility for a common control's development, implementation, assessment, and monitoring rests with a designated common control provider, a weakness in a widely inherited control can propagate risk across every system that relies on it. A single deficiency at the enterprise level can therefore affect many systems simultaneously, which makes clear ownership and ongoing monitoring essential.

A common expert-flagged mistake is treating inheritance as a way to offload responsibility entirely. Inheritance does not eliminate a system owner's obligation to confirm that an inherited control adequately addresses that system's specific requirements. Where a control is only partially inherited as a hybrid, the residual or system-specific portions typically remain the receiving system's responsibility. Assuming a control is fully covered simply because it appears on an inheritance list is a frequent source of gaps.

Who it's relevant to

Common Control Providers

Organizational officials accountable for the development, implementation, assessment, and monitoring of controls inherited by multiple systems. They must maintain clear documentation of what each control covers and communicate its status to inheriting system owners, since deficiencies can affect every system that relies on the control.

System Owners and ISSMs

Those managing individual information systems benefit from inheritance to reduce duplicated effort, but retain responsibility for confirming that inherited controls adequately address their system's specific requirements. They must also identify and address the system-specific portions of any hybrid controls that are not fully covered by inheritance.

Security Control Assessors and Auditors

Assessors need to understand which controls are inherited, which are hybrid, and which are system-specific in order to scope assessments accurately and avoid double-counting or overlooking residual responsibilities that remain with the inheriting system.

Authorizing Officials

AOs making risk-based authorization decisions should understand how a system's reliance on common controls affects its overall risk posture, including the possibility that a weakness in a shared control could affect multiple systems under their purview.

Inside Common Controls

Inheritable Security Controls

Controls that are developed, implemented, assessed, and managed by an entity other than the information system owner, and whose protections can be inherited by one or more systems. Common controls are a core concept within the NIST Risk Management Framework (RMF) as described in NIST SP 800-53 and NIST SP 800-37, and are generally selected from the applicable control catalog and baseline.

Common Control Provider

The organizational official or entity responsible for the development, implementation, assessment, and ongoing monitoring of common controls. This role is distinct from the system owner and is accountable for documenting the controls and making assessment results available to systems that inherit them.

Hybrid Controls

Controls that are partially provided as common controls and partially implemented at the system level. In most implementations, the common portion is inherited from the common control provider while the remaining portion must be addressed by the individual system owner.

System-Specific Controls

Controls that are the sole responsibility of the individual system owner and are not inherited. Distinguishing these from common and hybrid controls is essential to allocating responsibility accurately within the RMF.

Inheritance Documentation

Records within the security plan and related authorization artifacts that identify which controls are inherited, from whom, and the extent of that inheritance. This documentation supports the authorizing official's risk determination and, as of the applicable revision of the governing publications, should reflect current assessment status.

Common questions

Answers to the questions practitioners most commonly ask about Common Controls.

Does inheriting a common control mean my system is automatically compliant with that control?

No. Inheriting a common control does not by itself make your system compliant. Inheritance transfers responsibility for the shared portion of the control to the providing organization, but the inheriting system owner generally remains accountable for confirming the control is adequate for the system's needs, that it actually covers the system's boundary, and that any system-specific or hybrid portions are addressed. Compliance also is not the same as security; a properly inherited control still requires verification that it operates effectively for your environment. Confirm the specifics against your organization's control provider agreements and current authorization guidance.

If a common control is authorized once, does that authorization cover all systems that inherit it indefinitely?

No. A common control's authorization is not a one-time or permanent event any more than an Authority to Operate is permanent. Common controls are subject to continuous monitoring, and their effectiveness must be reassessed over time. If the providing organization's implementation changes, degrades, or is not maintained, inheriting systems may be affected. Inheriting system owners should track the status of the controls they rely on rather than assuming an earlier authorization remains valid. Verify monitoring and reassessment expectations against current authoritative guidance.

How do I identify which controls in my baseline can be treated as common controls?

Common controls are generally identified by determining which controls are provided by another entity, such as an organization-wide, enterprise, or infrastructure provider, and are inheritable by multiple systems rather than implemented uniquely by each system. This identification typically occurs during system categorization and control selection, and depends on how your organization has designated and documented common control providers. Because designations and tailoring vary by organization and by the applicable revision of the governing control catalog, confirm the specific common control designations against your organization's official documentation.

How should common controls be documented in a System Security Plan?

In most implementations, the System Security Plan identifies each control as system-specific, common (inherited), or hybrid, and records the provider for any inherited or hybrid controls along with the portions inherited versus implemented locally. The intent is to make the division of responsibility clear so that assessors and authorizing officials can see what the system is relying on from another party. Exact documentation formats and expectations vary by organization and applicable guidance, so verify the required content against your current authorization process.

What are hybrid controls, and how do they relate to common controls?

A hybrid control is one where part of the control is provided as a common control by another entity and part is implemented by the individual system. In these cases, responsibility is shared: the inheriting system owner is generally accountable for the system-specific portion while relying on the provider for the common portion. It is important to document clearly which portion is inherited and which is implemented locally so that no part of the control is left unaddressed. Confirm how hybrid responsibilities are divided in your specific environment against your organization's documented arrangements.

What should an inheriting system owner do to maintain assurance over controls provided by a common control provider?

An inheriting system owner should generally confirm that the inherited controls cover the system's boundary and needs, track the status and continuous monitoring results of those controls, and stay informed of changes to the provider's implementation that could affect the inheriting system. Because responsibility for the shared portion rests with the provider but overall accountability for the system remains with the system owner, maintaining assurance is an ongoing activity rather than a one-time acceptance. Verify the specific monitoring, reporting, and coordination expectations against your organization's provider agreements and current guidance.

Common misconceptions

Once a control is designated as common and inherited, the system owner has no remaining responsibility for it.

This is true only for fully inherited common controls. For hybrid controls, the system owner generally retains responsibility for the system-specific portion, and even for fully inherited controls the system owner should confirm that the inheritance is appropriate for the system's impact level and document reliance on it. Verify allocation against the governing security plan and current NIST guidance.

Inheriting a common control means the inheriting system automatically satisfies that control and no risk remains.

Inheritance transfers implementation responsibility, not risk elimination. The common control provider's assessment results still carry residual risk that must be considered by the authorizing official, and inheritance does not equate to security or to a completed authorization. Assessment and authorization remain distinct activities.

Common controls, once established and inherited, remain valid indefinitely.

Common controls are subject to continuous monitoring and periodic assessment just as system-specific controls are. If a common control provider's protections degrade or change, inheriting systems may be affected, and an Authority to Operate that relies on those controls is time-bound rather than permanent.

Best practices

Clearly document each control as common, hybrid, or system-specific in the security plan, and identify the responsible common control provider so that responsibility allocation is unambiguous.

Confirm that inherited common controls are appropriate for the inheriting system's impact level and tailoring before relying on them, rather than assuming automatic coverage.

For hybrid controls, explicitly define and document which portion is inherited and which portion the system owner must implement to avoid gaps in coverage.

Obtain and review current assessment results and continuous monitoring status from the common control provider, recognizing that inheritance does not eliminate residual risk that the authorizing official must consider.

Establish communication with the common control provider so that changes or degradation in common controls are promptly reflected in inheriting systems' risk posture and authorization decisions.

Verify control designations, allocations, and inheritance arrangements against the applicable revisions of NIST SP 800-53 and NIST SP 800-37 and any agency-specific tailoring, since baselines and guidance change across revisions.