Skip to main content
Policy Authority
Category: Controls Management

Common Control

Also known as: inherited control, inheritable control
Simply put

In a security and controls context, a common control is a safeguard that is put in place once but can be relied upon, or 'inherited,' by more than one system or program rather than being built separately for each. This approach lets multiple systems share the protection provided by a single control. Note that 'common control' also has an unrelated meaning in corporate accounting and regulatory law, where it refers to shared control over entities.

Formal definition

As defined in the NIST security controls context, a common control is a security control that is inherited by one or more organizational information systems or programs. Rather than being implemented and assessed independently within each system boundary, the control is provided at an organizational or shared level and its protection is inherited by the systems that rely on it. The term should be distinguished from system-specific controls, which apply to a single information system, and from hybrid controls, which combine common and system-specific elements. This entry addresses the security and controls usage; it does not cover the separate accounting and legal meaning of 'common control' (for example, common-control transactions under ASC 805 or 'common control' as defined for regulatory purposes under 29 CFR § 779.221), which concern shared or non-sole control over entities or net assets rather than inheritable safeguards.

Why it matters

In the NIST security controls context, common controls address a practical challenge: many safeguards, such as physical facility protections, personnel security processes, or shared network defenses, are not unique to any single information system but instead protect several systems at once. Defining these as common controls allows the protection to be implemented and assessed once at an organizational or shared level and then inherited by the systems that rely on it, rather than being duplicated, documented, and assessed independently within every system boundary. This can reduce redundant effort and promote consistency in how a given safeguard is applied across an organization.

The inheritance model also carries a concentration consideration. Because multiple systems depend on a single common control, a weakness or failure in that control may affect all of the inheriting systems simultaneously. Clear identification of which controls are common, and clear assignment of responsibility for their implementation and assessment, therefore matters for understanding where shared dependencies exist.

Finally, the term is a common source of confusion because 'common control' has an entirely separate meaning in corporate accounting and regulatory law, where it refers to shared control over entities or net assets. Under that usage, a common-control transaction does not meet the definition of a business combination because there is no change in control over the net assets, and 'common' control there is understood to include the sharing of control rather than sole or complete control by one party. Practitioners should be careful to establish which meaning is intended in a given document, as the two are unrelated.

Who it's relevant to

Security and controls practitioners
Those responsible for implementing and assessing controls need to identify which safeguards are provided commonly and inherited by multiple systems, versus those that are system-specific or hybrid, so that responsibility for implementation and assessment is assigned appropriately and dependencies are understood.
Internal auditors and assurance functions
Assurance providers evaluating a control environment need to understand where controls are inherited across systems, since a single common control may affect multiple inheriting systems. Note that assessing a common control is an assurance activity distinct from the management activity of operating it.
Accounting and financial reporting professionals
Practitioners working with business combinations and consolidations encounter 'common control' in an unrelated sense, referring to shared control over entities or net assets. This entry addresses the security and controls usage and does not cover common-control transactions under accounting standards or common control as defined for regulatory purposes; those should be treated as separate concepts.

Inside Common Control

Shared control implementation
A common control is a single control that is implemented once and relied upon by multiple systems, business units, or processes, rather than being separately deployed for each.
Central ownership and responsibility
Common controls typically have a designated owner or provider responsible for their design, implementation, and ongoing operation on behalf of the organizations or systems that inherit them.
Inheritance relationship
Systems or units that rely on a common control inherit its protection without independently operating it, which creates a dependency that should be documented and understood by the inheriting parties.
Scope and applicability boundaries
A common control has a defined scope indicating which systems, environments, or units it covers; controls or portions of controls falling outside that scope may need to be addressed separately, sometimes as hybrid controls.
Assurance and monitoring arrangements
Because many parties depend on a single control, arrangements for testing, monitoring, and reporting on its effectiveness are commonly centralized and communicated to those relying on it.

Common questions

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

Does implementing a common control mean each dependent system or unit no longer has any responsibility for that control?
No. While a common control is inherited by multiple systems, business units, or processes rather than implemented separately by each, the inheriting parties typically retain responsibility for confirming that the control as provided actually meets their specific needs. Inheritance addresses shared implementation and operation, but it does not automatically transfer accountability for the residual risk to the provider. Dependent parties commonly remain responsible for identifying gaps where the common control does not fully cover their context and for supplementing it where necessary. The defining feature of a common control is shared provision, not the elimination of local responsibility.
Is a common control the same thing as a general IT control or an entity-level control?
Not necessarily. These terms are related but distinct. A common control is defined by being provided once and inherited by multiple systems or units, regardless of its nature. A general IT control refers to a control over the IT environment that supports application-level controls, and an entity-level control operates broadly across an organization. A given control may fall into more than one of these categories, but the classifications answer different questions: common control describes how the control is provided and inherited, general IT control describes what layer it operates at, and entity-level control describes its organizational breadth. Treating them as synonyms can obscure important distinctions about ownership and scope.
How do you document the boundary of what a common control does and does not cover?
A common practice is to define the control's scope, the parties that provide it, and the parties that inherit it, along with an explicit statement of what remains the responsibility of the inheriting party. Some frameworks describe controls that are only partially inherited, where the provider covers part of the implementation and the inheriting party must complete the remainder. Documenting this boundary helps prevent gaps where each party assumes the other is responsible. The specific documentation format varies by framework and organization, and this entry does not prescribe particular templates or tooling.
Who should own a common control, and how is that ownership assigned?
Ownership is typically assigned to the party that provides and operates the control, since that party is best positioned to maintain it and attest to its operation. Inheriting parties commonly rely on that owner's representations while retaining responsibility for confirming suitability for their own context. Clear ownership assignment helps avoid situations where a widely inherited control has no accountable maintainer. Assignment approaches differ across organizations and frameworks; this entry does not cover specific governance structures or role definitions.
How can inheriting parties gain assurance that a common control is operating effectively?
Inheriting parties often rely on evidence produced by the control provider, such as testing results, monitoring output, or independent assessments where available. It is important to distinguish the management activity of operating the control from any independent assurance over it; assurance functions evaluate the control but do not operate it. Where a common control is critical to multiple inheriting parties, coordinated or centralized testing can reduce duplicated effort. The appropriate level and source of assurance depends on the risk involved and applicable requirements, which vary by jurisdiction and sector.
What happens when a common control changes or fails, and how should that be handled?
Because a common control is inherited by multiple parties, a change or failure can affect all of them simultaneously, which concentrates risk. A common practice is to establish change management and notification processes so that inheriting parties are informed of modifications, degradations, or failures that could affect their reliance on the control. Inheriting parties may then need to reassess their residual risk and consider compensating measures. This concentration effect is a recognized trade-off of common controls; the specific escalation and remediation procedures depend on the organization and are outside the scope of this entry.

Common misconceptions

Inheriting a common control means an inheriting system or unit has no remaining responsibility for it.
Inheriting parties commonly retain responsibility for understanding the control's scope, confirming it actually covers their environment, and addressing any gaps or portions outside its coverage. Reliance does not by itself transfer all accountability.
A common control fully protects every system that relies on it.
A common control applies only within its defined scope. Where coverage is partial, additional or hybrid arrangements may be needed, and reliance on a control does not guarantee that all relevant risks are treated.
Designating a control as common is primarily an efficiency measure with no downside.
While centralizing a control can reduce duplication, it also concentrates dependency, so a weakness or failure in the common control may affect all parties that inherit it. This makes clear ownership, monitoring, and communication important.

Best practices

Document the scope of each common control explicitly, identifying which systems, units, or environments it covers and where coverage stops.
Assign a clear owner or provider accountable for the design, operation, and ongoing effectiveness of the common control.
Communicate inheritance relationships to all parties that rely on the control so they understand their remaining responsibilities.
Identify portions of a control that fall outside common coverage and address them separately, for example through hybrid arrangements, rather than assuming full protection.
Establish centralized monitoring, testing, and reporting so that the effectiveness of the common control is visible to those who depend on it.
Consider the concentration of dependency created by common controls and confirm that a failure would be detected and managed across all inheriting parties.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide