Study guide
3.5 Documenting Control Selection and Securing Stakeholder Agreement
ISC2 Certified in Governance, Risk and Compliance CGRC
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
0.1 ISC2 CGRC Exam Structure, Logistics & Passing Strategy 0.2 NIST RMF 7-Step Lifecycle & GRC Architecture
2 Chapter 1: Security and Privacy Governance, Risk Management, and Compliance Program
1.1 Enterprise Governance & GRC Frameworks 1.2 Security and Privacy Objectives: CIA, Non-Repudiation and Privacy Concepts 1.3 Multi-Tier Risk Management & Assessment Methodologies 1.4 System Development Life Cycle and Information Life Cycle Management 1.5 Establishing and Operating the Compliance Program 1.6 Legal, Regulatory & Federal Compliance Drivers 1.7 Privacy Governance, Organizational Roles & ISC2 Code of Ethics
3 Chapter 2: Scope of the System
2.1 System Boundary Definition, Architectural Context & Types 2.2 Identifying Information Types with NIST SP 800-60 2.3 System Categorization Process & Impact Analysis (FIPS 199 / SP 800-60) 2.4 Impact and Risk Determination Under Non-Federal Frameworks 2.5 System Registration, Environment & Interconnection Agreements
4 Chapter 3: Selection and Approval of Framework, Security, and Privacy Controls
3.1 Control Catalogs & NIST SP 800-53 Rev. 5 Structure 3.2 Control Allocation & Inheritance Models 3.3 Control Tailoring, Scoping & Overlay Guidance 3.4 Data Handling and Marking Requirements 3.5 Documenting Control Selection and Securing Stakeholder Agreement 3.6 Continuous Monitoring Strategy & Control Selection Approval
5 Chapter 4: Implementation of Security and Privacy Controls
4.1 Developing the Implementation Strategy: Resourcing, Funding and Timeline 4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes 4.3 System Security and Privacy Plan (SSP/SSPP) Development 4.4 Security Engineering Principles & Technical Control Implementation 4.5 Secure Baseline Configuration & System Hardening 4.6 Implementing Compensating and Alternate Controls 4.7 DevSecOps, SDLC Integration & Supply Chain Risk Management 4.8 Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers
6 Chapter 5: Assessment/Audit of Security and Privacy Controls
5.1 Security Assessment Plan (SAP) & Assessor Independence 5.2 Assessment Methods, Objects & Depth/Coverage 5.3 Assessment Execution, Vulnerability Scanning & Testing 5.4 Preparing the Initial Assessment/Audit Report 5.5 Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer 5.6 Stakeholder Collaboration, Corrective Action and Reassessment 5.7 Security Assessment Report (SAR) & Risk Findings Analysis 5.8 Developing the Risk Response Plan: Prioritization and Resources
7 Chapter 6: System Compliance and Authorization
6.1 The Core Authorization Package & Supporting Artifacts 6.2 Plan of Action and Milestones (POA&M) Architecture & Management 6.3 System Risk Acceptance Criteria and Stakeholder Concurrence 6.4 Authorization Decision Process & Decision Types 6.5 Residual Risk Acceptance, Terms of Authorization & Continuous ATO 6.6 Documenting and Communicating the Compliance Decision
8 Chapter 7: Compliance Maintenance and Continuous Monitoring
7.1 Continuous Monitoring Strategy & Operations (NIST SP 800-137) 7.2 Configuration Management & Security Impact Analysis (NIST SP 800-128) 7.3 Incident Response and Contingency Activities in Sustained Compliance 7.4 Awareness, Training, Evidence Collection and Monitoring-Strategy Revision 7.5 Ongoing Remediation, POA&M Sustainment & Annual Reviews 7.6 Event-Driven Reauthorization & System Decommissioning
3.5 Documenting Control Selection and Securing Stakeholder Agreement
Key Takeaways Explain This Topic AI
Control selection documentation must record not only which controls were selected but the traceable rationale for every tailoring decision, because an undocumented decision is indistinguishable from an omission at assessment time.
Each control must have a named responsible party before the SSP is approved, since unallocated controls are the leading cause of controls that are never implemented.
Common Control Providers must formally agree to provide the controls that systems intend to inherit; assumed inheritance is a recurring audit finding.
Stakeholder agreement converts control allocation from an assumption into a commitment, which is why RMF Task S-6 requires Authorizing Official approval before implementation begins.
Machine-readable formats such as OSCAL make control selection traceable and reusable, but they do not replace the requirement for documented human rationale.
Last updated: August 2026
Documenting Control Selection and Securing Stakeholder Agreement
The final two bullets of CGRC task 3.2 — "Control selection documentation" and "Control allocation and stakeholder agreement" — determine whether all the analytical work of baseline selection and tailoring actually survives contact with implementation. A tailoring decision that nobody recorded, or a control assigned to nobody in particular, produces the same outcome as never having made the decision at all.
1. What the Documentation Must Prove
An assessor reading the control-selection record should be able to reconstruct how the organization got from a FIPS 199 category to this exact control set without asking anyone a question. That requires four traceable elements:
Element What It Records Why an Assessor Needs It
Starting baseline The SP 800-53B baseline selected and the categorization that produced it Establishes the authorized starting point
Every tailoring action Each scoping decision, enhancement, parameter value, overlay, and compensating control Distinguishes a deliberate decision from an accidental gap
Justification The technical or mission rationale for each action, with the approving authority Makes the decision defensible and reviewable
Allocation The named party responsible for implementing each control Ensures nothing is orphaned
Important
The governing asymmetry: a control that is absent with documented justification is a tailoring decision . The identical control absent without justification is a finding . The control set can be byte-for-byte identical in both cases — only the documentation differs. This is the single most efficient point in the whole RMF at which to prevent assessment failures.
Organization-Defined Parameters
SP 800-53 controls contain assignment and selection statements the organization must fill in — AC-7 requires defining the number of consecutive failed login attempts and the lockout duration; AU-11 requires defining a retention period. These organization-defined parameters (ODPs) are part of the selection record, not implementation detail.
Their importance is that they define the assessment objective . If the SSP leaves AC-7's threshold blank, the assessor has no criterion to test against and the control cannot be assessed as satisfied — the finding is a documentation defect rather than a technical one. Where an overlay, a FedRAMP baseline, or organizational policy prescribes a value, the record must show that prescribed value was used rather than a locally invented one.
2. Allocating Controls to Responsible Parties
Control allocation assigns each selected control to the party who will implement it. Every control must resolve to exactly one of these:
- Allocation Responsible Party Documentation Requirement
- System-specific The system owner / development team Full implementation statement in the SSP
Common (inherited) A Common Control Provider Provider identity, their system identifier, authorization status and date
- Hybrid Split between CCP and system owner Explicit statement of which portion each party owns
- Not applicable None — scoped out Justification for why the control does not apply
Hybrid controls are where allocation most often fails. Recording "IR-4 is hybrid" is insufficient. The record must state that the enterprise Security Operations Center provides 24/7 monitoring and initial triage, while the application team provides local escalation playbooks and data-spill containment. Without that split, both parties can reasonably believe the other owns the ambiguous middle — and at assessment, nobody implemented it.
3. Stakeholder Agreement Is a Commitment, Not an Assumption
The blueprint pairs allocation with stakeholder agreement deliberately. Allocation is what the system owner intends ; agreement is what the other parties have committed to .
Common Control Provider agreement is the critical case. A system owner cannot unilaterally decide to inherit a control. The CCP must confirm that the control is in fact provided, that its authorization is current, that the implementation actually covers the consuming system's environment, and that assessment results will be shared. A system that documents inheritance the provider never agreed to has a control that is implemented by nobody — a gap that typically surfaces only when the assessor requests the provider's evidence.
The reciprocal obligation matters too: the CCP must notify consuming systems when an inherited control changes, degrades, or loses authorization. Without that notification path, a downstream system can be operating on an inherited control that quietly stopped working.
Other stakeholders whose agreement belongs in the record:
Security Control Assessor — an early testability review confirms the selected controls and their ODPs can actually be assessed, catching untestable formulations before implementation money is spent.
Senior Agency Official for Privacy — must concur on privacy control selection wherever PII is processed.
Information Owner/Steward — confirms handling, marking, and retention requirements for their data types.
Business/mission owner — confirms that controls do not obstruct the mission, since a control that blocks operations gets bypassed in practice.
4. RMF Task S-6: The Formal Gate
Task S-6 (Plan Review and Approval) is where the whole selection package becomes binding. The Authorizing Official or designated representative, coordinating with the SAOP where privacy is involved, formally reviews and approves the System Security Plan and the continuous monitoring strategy .
This approval is a genuine decision gate, and its purpose is economic. The AO is confirming before implementation spending begins that if the documented controls are correctly implemented, the residual risk will be acceptable. Discovering at Step 5 that the AO considers the selected baseline inadequate means the implementation was built to the wrong specification — the most expensive class of rework in the framework.
Note
Documentation is a living artifact. Approval at S-6 is not the end. Every subsequent tailoring change — a new enhancement after a threat advisory, a parameter revised after an incident, a control reallocated when a service moves to a CCP — must be recorded with its own rationale and approval. An SSP whose selection record stopped being updated at initial authorization no longer describes the system, and assessors treat divergence between the documented and actual control set as a finding in its own right.
Machine-Readable Selection Records
Expressing the selection record in OSCAL — NIST's Open Security Controls Assessment Language — lets baselines, tailoring decisions, parameter values, and inheritance relationships be represented in JSON, XML, or YAML. The gains are real: automated verification that every baseline control is addressed, machine-resolvable inheritance chains, and diffable change history. What OSCAL does not do is supply the rationale . A machine-readable record with empty justification fields is exactly as indefensible as an undocumented spreadsheet.