If Chapter 2 is about understanding risk, Chapter 3 is about doing something about it and proving it worked. The domain has three movements: choose responses (3A), build controls (3B), and monitor and report (3C). The exam tests this domain as a decision chain — response selection follows from residual risk versus tolerance, control selection follows from the response, and monitoring verifies the whole thing still holds. More than any other domain, the questions here punish answers that sound diligent but act on the wrong step: adding controls to a risk already within tolerance, monitoring without thresholds, or reporting activity instead of risk.
3A1 Risk Response Options
Risk response is the decision about what to do with each assessed risk, and NISTIR 8286A lays out the logic cleanly. The determined exposure is compared with risk tolerance. If exposure is within tolerance limits, the risk may be accepted — acceptance is a conscious decision by someone with the authority to make it, documented and periodically revisited, never the default of doing nothing. If exposure exceeds tolerance, the practitioner works through the other options.
Mitigation applies controls to reduce the likelihood or impact of a risk to a tolerable level — the most common response, and the subject of all of 3B. Risk transfer, also known as risk sharing, moves some of the exposure elsewhere: hiring an external organization to process sensitive transactions such as payment card transactions (reducing the likelihood that sensitive data is processed in-house), or buying cybersecurity insurance (reducing the economic impact if the event occurs). Transfer never transfers accountability — the organization still owns the risk and its consequences; it has only changed who bears part of the cost or the processing.
Avoidance means not doing the risky thing at all: declining the acquisition, discontinuing the product, redesigning the system so the exposure disappears. NISTIR 8286A is explicit that if an unacceptable risk cannot be adequately treated in a cost-effective manner, that risk must be avoided — and equally explicit that risk avoidance is not the same as ignoring a risk. Avoidance is a decision with consequences (lost opportunity, redesign cost), taken deliberately when no proportionate treatment exists.
Two principles govern response selection. First, responses are chosen on residual risk versus tolerance, not inherent risk — Chapter 2's rule, applied. Second, responses must be cost-effective and proportionate: a response that costs more than the exposure it removes destroys value. The practitioner also considers the response's own risk — every new control introduces complexity, and outsourcing introduces third-party risk (3A3).
3A2 Risk and Control Ownership
Every risk needs a named owner, and every control needs a named owner, and they are not always the same person. The risk owner is accountable for the risk — the business person who decides what to do about it, accepts the residual, and answers for the outcome. The control owner is responsible for the control's design, implementation, and operation — often a technical or operational role. The risk owner chooses the response; the control owner delivers the control that implements it.
Ownership fails in predictable ways the exam loves. Orphaned risks — assessed, registered, owned by "the team" — are unmanaged risks. Risk owners without authority — accountable in name but unable to fund the response or accept the residual — produce responses that never happen. And ownership that follows the org chart instead of the risk — the CISO "owning" all cyber risk while business units make the decisions that create it — separates accountability from the power to act. ISACA's supporting tasks make assignment explicit: the practitioner identifies risk owners and control owners and holds each to their distinct accountability.
3A3 Vendor/Supply Chain Risk Management
Third parties extend the enterprise's risk surface beyond its control boundary: suppliers, developers, system integrators, and external service providers all touch the organization's data, systems, or operations. NIST SP 800-161 defines Cybersecurity Supply Chain Risk Management (C-SCRM) as a systematic process for managing exposure to cybersecurity risks throughout the supply chain and developing appropriate response strategies, policies, processes, and procedures. The key word is systematic — not a questionnaire filed at onboarding, but a lifecycle.
The lifecycle runs: establish the C-SCRM frame (strategy, policy, risk tolerance for supply chain exposure), assess suppliers before and during the relationship (due diligence proportionate to criticality — the payroll processor gets more scrutiny than the office-supply vendor), flow security requirements into contracts (right to audit, breach notification timelines, subcontractor controls, data return and destruction), monitor continuously (performance, incidents, financial health, changes in ownership or subcontracting), and plan for exit (data retrieval, access revocation, transition of services).
The exam tests three pressure points. First, criticality drives rigor: assessment depth, contract terms, and monitoring intensity scale with the supplier's access to sensitive data and its importance to critical processes. Second, the organization retains accountability for risks its suppliers create — outsourcing the work never outsources the risk, and regulators and customers hold the enterprise responsible for its vendors' failures. Third, fourth parties matter: the supplier's own suppliers are part of the chain, and contracts should require visibility into material subcontracting. A vendor program that assesses the vendor but ignores its subcontractors has drawn the boundary in the wrong place.
3A4 Issues, Findings, Exceptions and Exemptions Management
Not everything goes according to plan. Issues are problems identified during risk management activities — a control that is not operating, a risk that has grown beyond tolerance, a response that is behind schedule. Findings are the output of assessments and audits — the specific gaps reported with evidence. Both need the same discipline: documented, assigned an owner, given a remediation date proportionate to the risk, tracked to closure, and verified — not merely marked complete when someone says the work is done.
Exceptions and exemptions are the formal way of handling the cases where the standard answer does not apply. An exception is a temporary, approved deviation from policy or control requirements — the legacy system that cannot support multi-factor authentication gets an exception with compensating controls and an expiration date. An exemption is a longer-term or permanent relief from a requirement, granted where the requirement does not fit the circumstances. NIST SP 800-161's rule for exceptions illustrates the discipline: when exceptions are made for compelling operational requirements, approval by the authorizing official should be contingent upon explicitly incorporating risk assessments into the broader assessment and implementing compensating controls to address the gaps. An exception approved by the person who wants it, rather than the risk owner, is self-dealing.
3B1 Control Frameworks, Types, and Standards
Controls are the safeguards that modify risk — the means of managing risk, including policies, procedures, practices, and organizational structures. Practitioners classify controls along several dimensions, and the exam tests all of them.
By function (ISACA's glossary taxonomy): preventive controls avoid undesirable events before they occur — access controls, input validation, segregation of duties, encryption, firewalls. Detective controls identify and report events that have occurred — log monitoring, reconciliations, exception reports, intrusion detection. Corrective controls fix the damage after detection — backups and restore procedures, incident response playbooks, rollback plans. Classify by primary purpose: a firewall that blocks an attack in real time is preventive even though it noticed the attack; a system that only reports it is detective. The exam's trap is the control that both detects and stops — the question asks what it primarily does.
By nature: administrative controls are the rules, procedures, and practices — policies, training, separation of duties. Technical (logical) controls are the system-enforced mechanisms — authentication, encryption, access control lists. Physical controls protect the tangible — locks, guards, fire suppression. A complete control set layers all three: the policy requires visitor logging (administrative), the badge system enforces it (technical), and the locked door makes it real (physical).
By relationship to the requirement: compensating controls are alternatives used when the primary control cannot be implemented — enhanced manual review where automated segregation is technically impossible, with the requirement that they actually reduce risk to an equivalent level and be supportable with evidence. Directive controls guide behavior toward the desired outcome — policies, standards, training. Deterrent controls discourage violations — warning banners, visible cameras.
Control frameworks organize all of this into implementable catalogs. NIST SP 800-53 is the federal control catalog — families of management, operational, and technical controls with baselines by impact level. The NIST Cybersecurity Framework 2.0 organizes outcomes by function (Govern, Identify, Protect, Detect, Respond, Recover). COBIT 2019 provides governance and management objectives. ISO/IEC 27001/27002 specifies the information security management system and its control guidance. The practitioner does not memorize catalogs; the practitioner selects controls from them proportionate to the risk, and the exam tests selection logic, not catalog contents.
3B2 Control Design, Selection, Implementation, and Analysis
Control selection follows the risk response: the response says mitigate, and the control set is how. Good control design starts from the risk scenario — which threat, exploiting which vulnerability, against which asset — and chooses controls that address the actual causal chain, not the generic checklist. A scenario about phishing-driven credential theft calls for MFA (preventive), email filtering (preventive), and monitoring of anomalous logins (detective); a scenario about database misconfiguration calls for configuration baselines and change control. Controls selected without reference to scenarios are decorations.
Design principles the exam tests: defense in depth — layered controls so no single failure is fatal; least privilege — every user, process, and system gets only the access it needs; separation of duties — no single person controls all stages of a critical process (the person who approves payments cannot also disburse them); and fail-secure — when a control fails, it fails closed, denying access rather than granting it.
Implementation turns design into operation: assign the control owner, document the procedure, configure and deploy, train the operators, and establish the evidence the control leaves behind — because a control without evidence cannot be tested (3B3) or monitored (3C4). Then comes analysis: is the control operating as designed, is it actually reducing the risk it was built for, and is it still cost-effective? Controls degrade — configurations drift, staff turn over, threats evolve — and analysis is what catches the decay. A control that was effective at implementation and is never re-analyzed is an assumption, not a safeguard.
Cost-effectiveness runs through all of it. The practitioner compares the control's total cost — implementation, operation, maintenance, and the friction it imposes on the business — against the risk reduction it delivers, measured as the change in exposure (Chapter 2's ALE arithmetic applies directly). A control that costs more than the risk it removes, or that the business bypasses because it is unusable, is a failed design regardless of its technical elegance.
3B3 Control Testing Methodologies
Testing answers two questions: is the control designed correctly, and does it operate effectively? Design testing (a walkthrough of the design against the risk scenario) comes first — there is no point testing the operation of a control that cannot work. Operating effectiveness testing then examines whether the control worked consistently over the period.
SP 800-53A's assessment methods are the tester's toolkit: examine (review documents, configurations, logs — the evidence the control leaves), interview (ask the operators and owners how the control works — and compare the answer to the evidence), and test (actively exercise the control — attempt the unauthorized access, submit the malformed input, trigger the alert). Strong testing combines all three; testing that relies on interviews alone tests the story, not the control.
Testing produces findings (3A4): control deficiencies — design gaps where the control cannot achieve its objective, and operating failures where a sound control was not followed. Deficiencies are rated by the risk they leave exposed, assigned owners, remediated, and retested. The exam's discipline point: testing is periodic and risk-based — critical controls over significant risks are tested more often and more deeply — and test results feed monitoring and reporting, closing the loop from 3C back to the risk register.
3C1 Risk Action Plans
A risk action plan is the documented program for executing the chosen risk responses: what will be done, by whom, by when, with what resources, and how completion will be verified. NISTIR 8286A points to the Plan of Action and Milestones (POA&M) as the instrument that records agreed-upon future risk activities. The plan turns the register's "mitigate" into accountable work — each action names an owner, carries a milestone date proportionate to the risk's severity, and defines the evidence that will demonstrate completion.
Action plans fail the way projects fail: vague actions ("improve security awareness") with no measurable outcome, owners without authority or resources, dates that slip without escalation, and completion declared on effort rather than evidence. The practitioner's discipline is to make every action specific, measurable, owned, and time-bound — and to escalate overdue actions on significant risks rather than quietly re-dating them. The plan is also where the response's cost-effectiveness is rechecked: if implementation costs have grown past the exposure they address, the plan — and the response — needs rethinking, not just more budget.