Study guide
5.5 Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer
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.5 Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer
Key Takeaways Explain This Topic AI
The five recognized risk responses are avoid, accept, share, mitigate, and transfer, and every identified risk must resolve to exactly one of them.
Mitigation reduces likelihood or impact but never eliminates risk, so every mitigated risk leaves residual risk that must still be accepted by an authorized official.
Avoidance is the only response that removes the risk entirely, because it removes the activity that generates it.
Transfer and sharing move financial or operational consequences to another party but never move statutory or regulatory accountability.
Acceptance is a formal, documented decision by an official with the authority to make it, not the default outcome when nothing else is done.
Last updated: August 2026
Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer
Task 5.4 requires that a risk response be "assigned (e.g., avoid, accept, share, mitigate, transfer) based on identified vulnerabilities or deficiencies." These five options are exhaustive: every risk the assessment surfaces resolves to exactly one of them. The exam tests whether you can select the right one from a scenario and whether you know who is authorized to choose it.
1. The Five Responses
Response What Happens Risk After Choose When
Avoid Eliminate the activity, capability, or asset that generates the risk Zero — the risk no longer exists The risk exceeds tolerance and the activity is not essential
Mitigate Implement controls that reduce likelihood or impact Reduced, never zero The activity is necessary and controls are cost-effective
Transfer Shift financial consequence to a third party Financially offset; operationally unchanged The impact is quantifiable and insurable
Share Distribute risk across parties through partnership or contract Distributed Another party is better positioned to manage part of it
Accept Formally decide to bear the risk without further action Unchanged Risk is within tolerance, or mitigation costs more than the exposure
Avoid
The only response that reduces risk to zero, because it removes the source. Discontinuing a legacy file-transfer service, declining to collect a data element, or cancelling a feature all eliminate the associated risk entirely.
The cost is capability. Avoidance forgoes whatever benefit the activity provided, which is why it is appropriate only when the risk genuinely exceeds tolerance and the activity is not mission-essential. An exam scenario describing a marginal-value service with unacceptable risk is usually pointing at avoidance; one describing a mission-critical function is not.
Mitigate
The most common response and the one the RMF is built around. Controls reduce likelihood (patching, hardening, access restriction), impact (encryption, segmentation, backups), or both.
The essential property: mitigation never reaches zero. Every mitigated risk leaves residual risk , and that residual risk must still be formally accepted. Candidates often treat "mitigate" as terminal — it is not. Mitigation is followed by acceptance of what remains.
Transfer
Moves the financial consequence elsewhere — cyber liability insurance being the canonical example. The breach still happens; the money to respond comes from a policy.
Important
Accountability is never transferable. Insurance can pay for breach response, notification, and legal costs. It cannot make the insurer responsible to the regulator. Under FISMA, HIPAA, or the GDPR, the agency head, covered entity, or controller remains accountable regardless of coverage. Exam options claiming that insurance or outsourcing "relieves the organization of liability" or "transfers statutory accountability" are always wrong.
Share
Often grouped with transfer, but distinct. Sharing distributes both the management and the consequence across parties — a cloud shared-responsibility model, a partnership, a consortium arrangement. Where transfer is mainly financial, sharing is operational: the cloud provider genuinely manages physical and hypervisor security, and genuinely bears the consequence of failing at it.
The residual obligation is that the sharing party must verify the other party's performance. Inheriting a control from a Cloud Service Provider still requires confirming the provider's authorization is current and that the customer-responsibility controls in the responsibility matrix are implemented locally. Sharing responsibility is not abandoning oversight.
Accept
A deliberate, documented decision to bear a risk without further action, appropriate when the residual risk is within organizational tolerance or when mitigation would cost more than the exposure it removes.
Acceptance is not what happens when nobody does anything. Unaddressed risk is not accepted risk — it is unmanaged risk, and it is a finding in its own right. Valid acceptance requires a decision by an official with the authority to make it, a documented rationale, a record in the risk register, and, in most organizations, a defined review date.
2. Who Decides
Authority is scoped by magnitude, and misattributing it is a common exam trap.
- Risk Level Decision Authority
- Within a system, inside delegated tolerance System owner, per organizational policy
- System-level residual risk affecting authorization Authorizing Official
- Risk crossing multiple systems or missions Risk Executive (Function)
- Enterprise-level strategic risk Executive leadership / head of agency
The Authorizing Official holds the non-delegable authority to accept residual risk for system authorization. An ISSO, system owner, or assessor may analyze, recommend, and prepare the package — none can accept the risk in the AO's place. Where a shared service creates risk for multiple consumers, escalation to the Risk Executive is correct, because no single system owner can accept a risk they impose on others.
3. Selecting the Right Response
Work through four questions in order:
Is the activity essential? If not, and the risk exceeds tolerance → avoid .
Are cost-effective controls available? If yes → mitigate , then accept what remains.
Is a third party better placed to manage or absorb part of it? If yes → share or transfer — remembering that accountability stays put.
Is the remaining risk within tolerance? If yes → accept formally. If no, return to step 2 with more resources, or escalate.
Responses Combine
Real decisions rarely use one response. A payment platform might mitigate through encryption and segmentation, share infrastructure risk with a PCI-compliant provider, transfer breach-response cost through cyber insurance, and accept the residual risk that remains — all for the same risk. Exam items describing layered arrangements are testing whether you can identify each component correctly rather than forcing a single label.
Note
Documenting the decision. Every response decision records the risk, the chosen response and its rationale, the decision-maker and date, and — for accepted risks — the review date. Mitigation decisions additionally generate POA&M entries with milestones and completion dates. Accepted risks live in the risk register without POA&M entries, because no corrective action is planned. Getting this routing right is directly examinable.