6.3 System Risk Acceptance Criteria and Stakeholder Concurrence
Key Takeaways
- Risk acceptance criteria are established at the organizational tier before any individual authorization decision, so that decisions are consistent rather than improvised per system.
- Risk appetite is the level of risk an organization is willing to pursue; risk tolerance is the permissible variation around it, and the two are not interchangeable.
- Criteria must define not only severity thresholds but categories of risk that are never acceptable regardless of business justification.
- Stakeholder concurrence on risk treatment must be obtained from mission owners, privacy officials, and any party that inherits or is affected by the risk.
- When stakeholders cannot reach concurrence, the correct action is escalation to the Risk Executive rather than a unilateral decision by the system owner.
System Risk Acceptance Criteria and Stakeholder Concurrence
Task 6.2 requires a determination of the system's risk posture, and two of its four bullets are governance rather than analysis: "system risk acceptance criteria" and "stakeholder concurrence for risk treatment options." These exist to prevent the failure mode where each authorization decision is made on instinct, so that two comparable systems receive opposite decisions from two Authorizing Officials.
1. Criteria Come Before the Decision
Risk acceptance criteria are established at Tier 1 as part of the organizational risk management strategy — PM-9 in SP 800-53 — and applied at Tier 3 when individual systems are authorized. Establishing them in advance produces three properties a defensible programme needs:
- Consistency. Comparable risks receive comparable decisions across systems and across Authorizing Officials.
- Predictability. System owners know before they build what will and will not be acceptable, so they design to that standard rather than discovering it at Step 5.
- Defensibility. A decision traceable to published criteria withstands audit and oversight; a decision explicable only as "the AO was comfortable" does not.
Appetite and Tolerance Are Different Things
The exam tests this distinction directly.
| Term | Definition | Example |
|---|---|---|
| Risk appetite | The amount and type of risk an organization is willing to pursue to achieve its objectives | "We will adopt emerging cloud services to accelerate mission delivery, accepting moderate operational risk" |
| Risk tolerance | The permissible variation around the appetite — the practical thresholds | "No High residual risk on internet-facing systems; no unmitigated Critical vulnerabilities beyond 15 days" |
Appetite is strategic and directional; tolerance is operational and measurable. An organization can have a high appetite for innovation risk and a very low tolerance for privacy risk simultaneously, and expressing both correctly is what lets a system owner interpret leadership's intent.
2. What Defensible Criteria Contain
Criteria expressed only as a severity threshold are incomplete. A usable set addresses five dimensions:
| Dimension | Question It Answers |
|---|---|
| Severity thresholds | What residual risk level may be accepted, and by whom, at each system impact level |
| Categorical exclusions | Which risks are never acceptable regardless of business justification |
| Aggregate limits | How much accumulated risk one system, or the portfolio, may carry |
| Time bounds | For how long a risk may be accepted before mandatory re-evaluation |
| Conditions | What compensating measures or monitoring must accompany an acceptance |
Categorical exclusions carry the most weight in practice. Some risks are unacceptable irrespective of the mission benefit: operating in violation of a statute, processing regulated data without the legally required safeguards, accepting a known-exploited critical vulnerability on an internet-facing system, or continuing to operate a system whose compensating controls have demonstrably failed. Publishing this list prevents the slow erosion in which each individual exception seems reasonable and the cumulative posture becomes indefensible.
[!IMPORTANT] Risk acceptance is time-bounded, not permanent. An accepted risk carries a review date. Threat environments change, a vulnerability that was theoretical becomes actively exploited, and a compensating control that worked degrades. An acceptance recorded once and never revisited is a governance failure that audits reliably surface — the organization is carrying a risk it evaluated under conditions that no longer hold.
3. Aggregate Risk
Criteria must address accumulation, because per-item evaluation systematically underestimates exposure. Twelve individually acceptable Moderate risks on one system may combine into an unacceptable posture, and the same is true across a portfolio: fifty systems each carrying one accepted authentication weakness constitute an enterprise-wide authentication problem, not fifty independent local decisions.
This is a principal reason the Risk Executive (Function) exists. Individual Authorizing Officials see their own systems; someone must maintain the enterprise view and identify when a pattern of locally reasonable acceptances has produced an organizationally unreasonable result.
4. Whose Concurrence Is Required
"Stakeholder concurrence for risk treatment options" means the parties who bear the consequences agree with how the risk is being handled. Concurrence is not the same as authority: the Authorizing Official alone accepts the risk, but the AO should not do so over the objection of a party who carries its effects.
| Stakeholder | Why Their Concurrence Matters |
|---|---|
| Mission / business owner | Bears the operational consequence if the risk materializes; can say whether a treatment obstructs the mission |
| Information Owner / Steward | Owns the data at stake and may have obligations the system owner does not see |
| SAOP / privacy official | Required wherever PII is involved; privacy risk is not the AO's specialism |
| Common Control Provider | Where the treatment depends on an inherited control they must actually provide |
| Systems that inherit from this one | Accepting a risk in a shared service pushes that risk onto every consumer |
| Interconnected partners | A risk accepted on one side of an interconnection is exported across it |
| Risk Executive (Function) | Where the risk affects the enterprise posture or crosses mission boundaries |
| External authority | Regulator, FedRAMP body, or contracting authority where the framework requires it |
The final three rows are where candidates most often go wrong. A risk accepted in a shared service is not a local decision. If an enterprise identity service accepts a residual authentication risk, every consuming system inherits it — usually without being asked. The correct governance is to notify consumers, document the exported risk in the provider's authorization package, and escalate to the Risk Executive, because no single AO can accept a risk they are imposing on peers.
5. When Concurrence Cannot Be Reached
Disagreement is a normal governance signal, and the response is escalation, not override.
- Clarify the disagreement. Is it about the facts (how likely is this really?), the evaluation (is Moderate the right rating?), or the treatment (should we mitigate instead)? Factual disputes are often resolved with more evidence.
- Seek additional analysis where the dispute is technical.
- Escalate to the Risk Executive (Function) where it is genuinely a difference of judgment about organizational risk.
- Escalate to executive leadership where the disagreement is between senior officials with competing mandates — typically mission delivery against security or privacy.
- Document the dissent. If the AO proceeds over a recorded objection, both the decision and the objection belong in the record.
That last step matters more than it appears. A documented dissent gives the organization an honest history: if the risk later materializes, the record shows the concern was raised, considered, and overruled by an accountable official — which is a defensible governance posture. A record that silently omits the objection is not.
[!NOTE] Concurrence is documented, not assumed. The record identifies who concurred, on what basis, and when. Circulating a package with no response and treating silence as agreement is the most common real-world failure, and it collapses immediately under audit when a stakeholder states they never reviewed it.
An enterprise identity service that fifty systems inherit from proposes to accept a residual authentication weakness. Its Authorizing Official considers the risk acceptable for the service itself. What is the correct governance treatment?
How do risk appetite and risk tolerance differ in an organizational risk management strategy?
A system owner circulates a risk treatment package to stakeholders, receives no responses within the review period, and records concurrence on the basis that no one objected. What is the deficiency in this approach?