Inherited Controls
Inherited Controls are a fundamental concept in the governance, risk, and compliance (GRC) framework, particularly relevant during the selection and approval of security and privacy controls. These are controls that a system or organization receives from another entity, rather than implementing the… Inherited Controls are a fundamental concept in the governance, risk, and compliance (GRC) framework, particularly relevant during the selection and approval of security and privacy controls. These are controls that a system or organization receives from another entity, rather than implementing them independently. In essence, inherited controls are security and privacy measures that are provided by a common infrastructure, shared service, or parent organization, and are leveraged by dependent systems without needing to re-implement them. In practice, inherited controls arise frequently in environments where multiple systems share a common platform, hosting environment, or organizational structure. For example, a cloud service provider may implement physical security controls at its data centers. Any organization using that cloud provider's services would inherit those physical security controls rather than implementing their own physical safeguards. The concept of inherited controls is critical for several reasons. First, they promote efficiency by eliminating redundant implementation of the same controls across multiple systems. Second, they ensure consistency in how certain controls are applied across an enterprise. Third, they reduce costs and resource burdens on individual system owners who can rely on centralized implementations. However, inherited controls also introduce responsibilities and risks. The inheriting organization must verify that the providing entity has properly implemented and maintains those controls. This requires clear documentation, formal agreements, and ongoing monitoring. If the provider fails to maintain an inherited control, all dependent systems are affected. During the control selection and approval process, organizations must clearly identify which controls will be inherited, from whom they will be inherited, and establish accountability for their effectiveness. Frameworks such as NIST SP 800-53 formally recognize inherited controls and require organizations to document control inheritance relationships in their security and privacy plans. Ultimately, understanding and properly managing inherited controls is essential for maintaining a robust security posture, ensuring compliance, and effectively managing risk across interconnected systems and organizational boundaries in any comprehensive GRC program.
Inherited Controls: A Comprehensive Guide for CGRC Exam Preparation
Understanding Inherited Controls in the Selection and Approval Framework
Why Inherited Controls Are Important
Inherited controls are a foundational concept in the Risk Management Framework (RMF) and play a critical role in how organizations efficiently manage security and privacy controls across information systems. Understanding inherited controls is essential because:
- They reduce redundancy by allowing multiple systems to leverage common controls provided by a shared entity or infrastructure.
- They promote cost efficiency by eliminating the need for every system to independently implement every control.
- They ensure consistency in security implementation across an organization's portfolio of systems.
- They streamline the authorization process by enabling system owners to focus on system-specific controls rather than re-implementing enterprise-wide protections.
- They support the concept of common control providers, which is central to NIST SP 800-37 and the RMF lifecycle.
What Are Inherited Controls?
An inherited control is a security or privacy control that is not implemented directly by the information system or system owner but is instead provided by another organizational entity, shared infrastructure, or common control provider. The system owner relies on the implementation of that control by another party and inherits the protection it provides.
Key definitions to understand:
- Common Control: A control that is implemented once and provides protection for multiple information systems. These are typically managed by a common control provider.
- Common Control Provider: An organizational official or entity responsible for the development, implementation, assessment, and monitoring of common controls.
- System-Specific Control: A control that is implemented specifically for and by a particular information system.
- Hybrid Control: A control that is partially inherited from a common control provider and partially implemented at the system level.
For example, physical security controls (PE family) for a data center are often inherited by all systems hosted in that data center. The facility management team serves as the common control provider, and individual system owners inherit those physical and environmental protection controls.
How Inherited Controls Work
The process of identifying, designating, and managing inherited controls follows a structured workflow within the RMF:
Step 1: Control Selection
During the Select step of the RMF, the system owner, in coordination with the authorizing official and security/privacy professionals, identifies the baseline controls applicable to the system based on its categorization (FIPS 199/FIPS 200 and NIST SP 800-53).
Step 2: Control Designation
Each selected control is designated as one of the following:
- Common – fully provided by a common control provider
- System-specific – implemented entirely by the system owner
- Hybrid – shared responsibility between the common control provider and the system owner
Step 3: Identification of Common Control Providers
For controls designated as common or hybrid, the system owner must identify who the common control provider is and document the inheritance relationship. This is typically recorded in the System Security Plan (SSP).
Step 4: Verification and Documentation
The system owner must verify that the common control provider has:
- Properly implemented the inherited control
- Had the control assessed by an independent assessor
- Documented the control's implementation status and any deficiencies
- Received authorization from an appropriate authorizing official
Step 5: Continuous Monitoring
Inherited controls must be continuously monitored by the common control provider. The system owner must stay informed about:
- Changes to the inherited control's implementation
- Assessment results and findings
- Any Plan of Action and Milestones (POA&M) items related to inherited controls
- Changes in the authorization status of the common control provider's system
Key Considerations for Inherited Controls
- Responsibility does not transfer entirely: Even though a control is inherited, the system owner retains accountability for ensuring the control adequately protects their system. If an inherited control is found to be deficient, the system owner must account for the residual risk.
- Documentation is critical: The SSP must clearly identify which controls are inherited, from whom, and the status of those controls.
- Risk acceptance: If an inherited control has known weaknesses, the system owner and authorizing official must decide whether to accept the residual risk, implement compensating controls, or find an alternative.
- Common controls can fail: If a common control provider loses their authorization or a common control fails, all systems inheriting that control are affected. This creates a single point of failure risk that must be managed.
- Reciprocity and reuse: Inherited controls support the principle of reciprocity, where one organization's assessment and authorization results can be leveraged by another.
Inherited Controls in the System Security Plan (SSP)
The SSP must document the following for each inherited control:
- The control identifier (e.g., PE-1, PE-2)
- The name and contact information of the common control provider
- The implementation status of the inherited control
- The date of the last assessment
- Any known deficiencies or POA&M items
- The authorization status of the provider's system
Roles and Responsibilities
- System Owner: Identifies which controls can be inherited, documents inheritance in the SSP, monitors the status of inherited controls, and manages residual risk.
- Common Control Provider: Implements, documents, assesses, and monitors common controls. Communicates changes and assessment results to inheriting system owners.
- Authorizing Official (AO): Reviews the adequacy of inherited controls during the authorization decision and accepts or rejects the associated risk.
- Information System Security Officer (ISSO): Assists the system owner in tracking inherited control status and ensuring proper documentation.
- Senior Agency Information Security Officer (SAISO/CISO): May oversee the organization-wide common control program and ensure common control providers fulfill their responsibilities.
Examples of Commonly Inherited Controls
- Physical and Environmental Protection (PE): Data center physical security, fire suppression, environmental controls
- Personnel Security (PS): Background checks, personnel screening conducted by HR
- Planning (PL): Organization-wide security planning activities
- Program Management (PM): Enterprise risk management, organization-wide security program
- Certain Access Control (AC) controls: Network access control implemented at the enterprise level
- Certain Contingency Planning (CP) controls: Alternate processing sites managed centrally
Exam Tips: Answering Questions on Inherited Controls
1. Know the Definitions Cold
Be absolutely clear on the difference between common controls, system-specific controls, and hybrid controls. Exam questions often test whether you can correctly classify a control scenario.
2. Remember: Inheritance ≠ Abdication of Responsibility
A very common exam trap is presenting a scenario where a system owner claims they don't need to worry about an inherited control. The correct answer is almost always that the system owner retains accountability and must verify the control's effectiveness.
3. Focus on the Common Control Provider Role
Expect questions about who is responsible for implementing, assessing, and monitoring common controls. The answer is the common control provider, not the inheriting system owner.
4. Understand the Impact of Common Control Failures
If a question describes a scenario where a common control is found deficient or a common control provider loses authorization, recognize that all inheriting systems are impacted. The system owners must reassess their risk posture.
5. Documentation Questions
Questions may ask where inherited controls are documented. The primary answer is the System Security Plan (SSP). The SSP must identify the control, the provider, and the implementation status.
6. Hybrid Controls Are Tricky
Pay close attention to scenarios describing controls that are partially provided by a common control provider. These are hybrid controls, and both the provider and the system owner share implementation responsibility.
7. Continuous Monitoring of Inherited Controls
The common control provider is responsible for continuous monitoring, but the system owner must stay informed about the status. If the exam presents a scenario about monitoring responsibilities, distinguish between who monitors (the provider) and who must be aware (the system owner).
8. Scenario-Based Questions
When you encounter a scenario question, ask yourself:
- Who implemented the control? (Common control provider or system owner?)
- Is the control fully provided or shared? (Common vs. hybrid)
- What happens if the control fails? (Impact on all inheriting systems)
- Who accepts the risk? (The authorizing official for each inheriting system)
9. Key NIST References
Be familiar with these publications as they relate to inherited controls:
- NIST SP 800-37 (RMF) – Discusses control designation and inheritance in the Select step
- NIST SP 800-53 – The control catalog from which controls are selected
- NIST SP 800-53A – Assessment procedures, including how common controls are assessed
- NIST SP 800-18 – Guide for developing security plans, including documenting inherited controls
10. Elimination Strategy
When in doubt, eliminate answers that suggest:
- The system owner has no responsibility for inherited controls (incorrect – they always have accountability)
- Inherited controls don't need to be documented (incorrect – they must be in the SSP)
- Only the system owner assesses inherited controls (incorrect – the common control provider arranges assessment)
- Inherited controls are permanently fixed and never change (incorrect – they require continuous monitoring)
Memory Aid: Think of inherited controls like renting an apartment in a building. The building owner (common control provider) provides fire alarms, structural integrity, and security cameras. As a tenant (system owner), you inherit those protections, but you're still responsible for knowing they work and locking your own door (system-specific controls). If the fire alarm system fails, every tenant is affected.
Master Governance, Risk & Compliance
CGRC authorization, risk & continuous monitoring
- Authorization Framework: NIST RMF, system categorization, and control selection
- Risk Management: Assessment, analysis, and ongoing risk monitoring
- Continuous Monitoring: Security control assessment and ongoing authorization
- 100% Satisfaction Guaranteed: Full refund if unsatisfied
- Risk-Free: 7-day free trial with all premium features!