3.5 Documenting Control Selection and Securing Stakeholder Agreement
Key Takeaways
- 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.
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.
Two assessors review two systems whose implemented control sets are identical. System A documented a justification for scoping out PE-18; System B simply has no PE-18 implementation statement. What is the assessment outcome?
A system security plan states that control IR-4 is a hybrid control shared between the enterprise Security Operations Center and the application team, but does not describe the division of responsibility. What risk does this create?
Why does RMF Task S-6 require the Authorizing Official to approve the system security plan and continuous monitoring strategy before implementation begins rather than at authorization?