Study guide
5.8 Developing the Risk Response Plan: Prioritization and Resources
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
5.8 Developing the Risk Response Plan: Prioritization and Resources
Key Takeaways Explain This Topic AI
The risk response plan consolidates residual risks and deficiencies, prioritizes them, and identifies the resources needed to determine realistic remediation timelines.
Prioritization is driven by risk to the organization, not by technical severity scores, ease of remediation, or the order findings were discovered.
Required resources span financial, personnel, and technical dimensions, and it is the resource analysis that produces a defensible completion date.
A remediation date derived from resource availability is credible; a date chosen to satisfy a policy interval and then missed damages the organization's compliance position.
Quick wins are worth sequencing early only when they do not displace higher-risk remediation, because visible progress is not the same as risk reduction.
Last updated: August 2026
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.
- Prioritization Basis Problem
- CVSS base score Ignores exploitability in this environment, data sensitivity, and compensating controls
- Ease of remediation Produces visible progress while the highest risks stay open longest
- Order of discovery No relationship to risk at all
- Risk to the organization Correct — considers likelihood, impact, exposure, and mission dependency
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:
Resource Questions to Answer
Financial Acquisition cost, professional services, and — routinely forgotten — the recurring licence, support, and operating cost
Personnel Which skills, how many hours, whether those people are available or already committed, whether specialist expertise must be contracted
Technical Infrastructure capacity, test environments, integration dependencies, and change windows in which work can safely occur
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:
Extend the timeline to the next budget cycle, with documented interim risk.
Implement an interim compensating control that reduces exposure while the full fix is pending.
Escalate so leadership can reallocate resources against the risk.
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.