Category: Governance Roles

Common Control Provider

Also known as: CCP, Security Control Provider

Simply put

A Common Control Provider is the organizational official responsible for managing security or privacy controls that multiple information systems share, or inherit, rather than each system implementing its own. By handling these shared controls centrally, the provider allows individual systems to rely on protections that are developed and maintained in one place. This role helps reduce duplicated effort across an organization's systems.

Formal definition

Per NIST terminology, a Common Control Provider is an organizational official responsible for the development, implementation, assessment, and monitoring of common controls, that is, security or privacy controls inherited by one or more organizational information systems. A common control is a control inherited by multiple systems, so the Common Control Provider is accountable for the lifecycle of those inheritable controls rather than for system-specific controls managed by individual system owners. The term Security Control Provider is used interchangeably in NIST glossary sources, though readers should verify the precise scope (security versus privacy controls) against the current authoritative NIST text, as this entry does not address specific implementation, assessment, or authorization procedures.

Why it matters

The Common Control Provider role exists because organizations rarely operate a single information system in isolation. Many protections, physical security of facilities, network boundary defenses, personnel security processes, or enterprise identity management, are logically implemented once and relied upon by numerous systems. Assigning a clear, accountable official for these shared controls lets individual system owners inherit those protections rather than reimplementing and separately assessing them, which generally reduces duplicated effort and helps promote consistency across an organization's security and privacy posture.

The role also introduces a critical accountability boundary that experts insist on preserving. When a system inherits a common control, the responsibility for developing, implementing, assessing, and monitoring that control rests with the Common Control Provider, not with the individual system owner. If that boundary is blurred, or if a common control is assumed to be adequately maintained when it is not, the weakness can propagate to every system that inherits it. Inheritance concentrates both benefit and risk, so the assurance any single system derives from a common control is only as strong as the provider's actual implementation and ongoing monitoring.

Because common controls are inherited, they must be continuously monitored rather than assessed once and treated as permanently satisfactory. A control that was effective at the time of an assessment may degrade, and any degradation affects all inheriting systems. Readers should treat this entry as a role definition only; it does not address the specific assessment, authorization, or continuous monitoring procedures that apply in a given environment, which must be confirmed against current authoritative NIST guidance and any applicable agency tailoring.

Who it's relevant to

Common Control Providers and enterprise security staff

Officials designated to develop, implement, assess, and monitor shared controls need to understand that they hold lifecycle accountability for controls that multiple systems rely on. Because inheriting systems depend on the provider's implementation, providers should be prepared to document the scope of what is offered for inheritance and to sustain ongoing monitoring rather than treating a control as complete after a single assessment.

Information system owners and ISSMs

System owners and Information System Security Managers benefit from clearly distinguishing which controls their system inherits from a Common Control Provider versus which controls they must implement and maintain themselves. Misattributing responsibility, assuming a control is covered by inheritance when it is not, or vice versa, can leave gaps that affect the system's overall protection.

Assessors and auditors

Those evaluating security or privacy controls need to trace inherited controls back to the responsible Common Control Provider and confirm that the provider, rather than the individual system, is accountable for those controls' development, implementation, assessment, and monitoring. This helps avoid double-counting or overlooking shared controls during an assessment.

Authorizing officials and risk executives

Decision-makers weighing organizational risk should recognize that common controls concentrate assurance: a weakness in an inherited control can affect every system that relies on it. Understanding where inheritance boundaries lie supports more accurate risk decisions across a portfolio of systems, though the specific authorization procedures fall outside this role definition and should be confirmed against current authoritative guidance.

Inside CCP

Role Definition

A Common Control Provider is an individual, group, or organization responsible for the development, implementation, assessment, and monitoring of common controls (also called inheritable controls) that can be inherited by one or more information systems. The role is defined within the NIST Risk Management Framework (RMF) guidance, generally NIST SP 800-37, and is applied in DoD, federal civilian, and national security system contexts, though specific responsibilities may be tailored by the implementing organization.

Common (Inheritable) Controls

The controls the provider manages are those implemented once at an organizational or enterprise level and inherited by multiple systems, rather than being implemented independently by each system owner. These are generally drawn from a control catalog such as NIST SP 800-53 at the applicable revision, with the specific set determined through organizational tailoring.

Documentation and Security Plan Artifacts

The provider is generally responsible for documenting the common controls, typically in a security plan or equivalent artifact, so that inheriting system owners can reference the implementation details, assessment results, and any limitations. This documentation supports the authorization and continuous monitoring processes for inheriting systems.

Assessment Support

Common controls are assessed by a security control assessor, and the provider supports these assessments by providing evidence and access. Assessment of common controls is distinct from the authorization decision made by the responsible authorizing official; the two functions should not be conflated.

Continuous Monitoring Responsibility

The provider generally maintains ongoing monitoring of the common controls and communicates changes, deficiencies, or degraded control status to the system owners and authorizing officials that rely on those controls, because inherited protections directly affect the risk posture of every inheriting system.

Common questions

Answers to the questions practitioners most commonly ask about CCP.

Does designating a Common Control Provider mean the inheriting systems no longer have to worry about those controls?

No. Inheritance shifts responsibility for implementing and managing the common controls to the Common Control Provider, but the inheriting systems and their authorizing officials remain accountable for confirming that the inherited controls actually meet their security requirements. If a common control only partially satisfies a system's needs, the remaining portion is typically treated as a hybrid or system-specific control that the inheriting system must address. Inheritance does not eliminate the inheriting system's due diligence; it changes where the primary implementation responsibility sits.

If a Common Control Provider's controls are authorized, are the inheriting systems automatically authorized too?

No. Authorization of the common controls is distinct from authorization of the systems that inherit them. The Common Control Provider generally documents and has its common controls assessed, and those results can be reused by inheriting systems, but each inheriting system still undergoes its own authorization decision by its own authorizing official. Assessment of a control is not the same as authorization of a system, and inheriting authorized common controls does not by itself confer an Authority to Operate on the inheriting system.

How does a Common Control Provider communicate the status of common controls to inheriting systems?

In most implementations, the Common Control Provider makes its security documentation available to inheriting system owners so they can reference the implementation details and assessment results for the controls they inherit. This typically includes making the relevant portions of the security plan, assessment findings, and any plan of action and milestones (POA&M) items visible so inheriting systems understand what they are relying on. You should confirm the specific artifacts and sharing mechanisms against your organization's process and the current authoritative guidance, as practices vary across agencies and programs.

What happens to inheriting systems when a common control has an open weakness or deficiency?

A deficiency in a common control generally affects every system inheriting it. The Common Control Provider is responsible for tracking and remediating such weaknesses, often through a POA&M, but inheriting systems and their authorizing officials should be made aware of the deficiency because it factors into their own risk determinations. In some cases an inheriting system may need to implement compensating or supplementary measures until the common control weakness is resolved. Confirm how open items are communicated and accepted within your specific authorization boundary.

How should inheriting systems handle a control that is only partially provided as a common control?

When a common control does not fully satisfy a system's requirements, it is generally treated as a hybrid control: the Common Control Provider covers the common portion, and the inheriting system implements and documents the remaining system-specific portion. The inheriting system's security documentation should clearly delineate which parts are inherited and which are its own responsibility so that assessors and the authorizing official can see where accountability lies. Verify how your organization documents hybrid and inherited controls under the applicable framework revision.

How does continuous monitoring interact with inherited common controls?

Because an Authority to Operate is time-bound and subject to ongoing continuous monitoring rather than being permanent, inheriting systems rely on the Common Control Provider to continuously monitor the common controls and report changes in their status. If the effectiveness of a common control changes, that change can affect the risk posture of every inheriting system, so the provider should communicate updates in a timely manner. Inheriting system owners should not assume inherited controls remain static and should confirm the monitoring cadence and reporting responsibilities defined for their environment.

Common misconceptions

Once a system owner inherits a common control, they bear no further responsibility for it.

Inheritance transfers implementation responsibility to the Common Control Provider, but the inheriting system owner generally remains responsible for confirming the inherited control adequately addresses the system's specific requirements, for documenting the inheritance, and for accounting for any residual risk. Some controls may also be hybrid, with responsibility shared between the provider and the system.

A Common Control Provider issues authorizations for the systems that inherit its controls.

The provider develops, implements, assesses, and monitors common controls, but it does not grant an Authority to Operate. Authorization decisions are made by the responsible authorizing official for each system. Assessment of a control and authorization of a system are separate functions and should not be treated as equivalent.

Common controls, once established, remain valid indefinitely.

Common controls are subject to continuous monitoring, and their effectiveness can degrade over time. A deficiency in a common control can affect every inheriting system, so the provider must track control status and communicate changes rather than assume a one-time implementation remains adequate.

Best practices

Maintain current documentation of each common control, including implementation details, assessment results, and any limitations, so inheriting system owners can accurately reference and rely on the control.

Clearly communicate the status of common controls, including deficiencies, changes, or degraded effectiveness, to all inheriting system owners and their authorizing officials on an ongoing basis, since inherited controls affect the risk posture of every dependent system.

Establish a defined continuous monitoring process for common controls rather than treating implementation as a one-time activity, and align monitoring frequency and reporting with organizational and RMF expectations.

Coordinate closely with security control assessors to support the assessment of common controls, keeping the assessment function distinct from the separate authorization decisions made by authorizing officials.

Explicitly identify which controls are fully common, hybrid, or system-specific, so that inheriting system owners understand where shared responsibility applies and can address any residual or system-specific requirements.

Verify the applicable control catalog, baseline, and organizational tailoring against the current authoritative source at the relevant revision, as the specific set of common controls and their requirements can change across revisions.