5.8 Developing the Risk Response Plan: Prioritization and Resources

Developing the Risk Response Plan: Prioritization and Resources

Task 5.6 is the final task of Domain 5 and has three explicit outputs: residual risks and deficiencies identified, risk prioritized, and "required resources identified (e.g., financial, personnel, and technical) to determine time required to mitigate risk." That last clause states the causal direction the exam tests: resources determine the timeline, not the other way round.

---

1. Consolidating Residual Risks and Deficiencies

The plan begins by assembling everything that remains outstanding after the response window:

• Findings that were not corrected and now require planned remediation.
• Residual risk from mitigated findings — reduced but not eliminated.
• Risk arising from compensating controls that achieve the objective imperfectly.
• Risk from planned implementations not complete at authorization.
• Risk from inherited controls with known deficiencies at the provider.

Consolidation matters because these arrive from different places and are easily double-counted or lost. The plan must be a single, complete view — an Authorizing Official who later discovers a category of risk that was never consolidated has grounds to question the entire package.

Aggregate risk deserves separate treatment. Ten Low-severity findings that individually pose little threat can combine into a materially higher exposure — weak password policy, no MFA, no lockout, verbose error messages, and outdated TLS are each modest and collectively an authentication-attack pathway. The plan should identify these combinations explicitly, because item-by-item prioritization will otherwise rank each of them at the bottom.

---

2. Prioritization Is Driven by Risk, Not Severity

The most common prioritization failure is sorting by CVSS score, or by whatever is easiest to fix. Neither reflects risk to the organization.

Under NIST SP 800-30 Rev. 1, prioritization weighs threat sources and events, vulnerability severity, predisposing conditions, existing controls, likelihood of occurrence, and impact on mission and assets. This is why a Critical-severity vulnerability on an isolated lab host can rank below a Moderate deficiency on an internet-facing system holding sensitive data.

Practical factors that legitimately raise priority:

• Active exploitation in the wild — a known-exploited vulnerability outranks a theoretically severe one.
• Internet exposure — reachable from an untrusted network.
• Sensitive data or mission-critical function in scope.
• Regulatory deadline attached to the deficiency.
• Blocking dependency — the deficiency prevents other remediations from proceeding.
• Aggregate contribution — the finding forms part of a chain.

---

3. Resources Determine the Timeline

This is the analytical core of the task. For each prioritized item, the plan identifies what is genuinely required:

Then, and only then, the timeline follows. A realistic completion date accounts for procurement lead time, the budget cycle if funding is not already available, engineering effort, testing, the change-approval path, deployment windows, and reassessment.

[!IMPORTANT] Two ways to set a date, one of which is defensible. The wrong method: policy says Moderate findings close in 90 days, so write 90 days. The right method: this fix needs a procurement that takes 60 days, 200 engineering hours from a team with 20 hours a week available, a security test cycle, and a monthly change window — therefore roughly 150 days, which exceeds policy and requires either additional resources or an approved extension. The first approach produces a date the organization will miss; the second produces a date it can defend. A missed POA&M date is worse than an accurate long one, because it demonstrates the organization does not control its own remediation.

When Resources Are Not Available

If required resources cannot be obtained, the honest outcomes are:

1. Extend the timeline to the next budget cycle, with documented interim risk.
2. Implement an interim compensating control that reduces exposure while the full fix is pending.
3. Escalate so leadership can reallocate resources against the risk.
4. Formally accept the risk if it falls within tolerance and remediation genuinely cannot be funded.

What is not acceptable is recording a completion date the organization has no means to meet. That converts a resource problem into a compliance failure and misleads the Authorizing Official about the system's actual trajectory.

---

4. Sequencing and Dependencies

The plan is a schedule, not just a ranked list. Dependencies constrain order: an identity-management deficiency may have to be resolved before access-control findings can be closed; a network segmentation project may be prerequisite to several isolation-based remediations. Sequencing that ignores dependencies produces work that stalls.

Resource contention matters equally. If six high-priority items all require the same two engineers, they cannot proceed in parallel regardless of their priority. Levelling the plan against actual capacity is what makes it executable.

Quick wins have a legitimate but bounded role. Low-effort items with real risk reduction are worth sequencing early because they reduce exposure immediately and build stakeholder confidence. The failure mode is letting them displace higher-risk work — a plan that closes twenty trivial findings while the critical exposure stays open has produced a good-looking metric and no risk reduction.

From Plan to POA&M and Authorization

The risk response plan feeds directly into the POA&M, which carries each item's weakness description, point of contact, required resources, milestones, scheduled completion date, and status. The plan is the analysis; the POA&M is the tracking instrument that carries it forward.

Both then enter the authorization package. The Authorizing Official uses them to answer the question that actually drives the decision: given the residual risk and the credibility of this remediation plan, is operating this system acceptable? A plan with honest priorities, real resource analysis, and defensible dates supports authorization. A plan with optimistic dates and no resource basis invites the AO to conclude that the residual risk is larger than the package claims.