Topics in this domain
- Risk Response Options: Accept, Mitigate, Transfer, Avoid
- Aligning Responses with Appetite and Tolerance
- Cost-Benefit Analysis of Risk Responses
- Bias in Risk Decisions and Reporting
- Risk Owners and Control Owners
- RACI and Escalation
- Third-Party Risk Governance and Due Diligence
- Contracts, SLAs and the Right to Audit
- Monitoring Third Parties and Planning Exit
- Managing Issues, Findings and Control Deviations
- Risk Acceptance, Exceptions and Exemptions
- Control Frameworks and Their Purpose
- Control Types and Functions
- Designing and Selecting Controls
- Implementing Controls and Why Implementations Fail
- Control Design versus Operating Effectiveness
- Control Testing: Objectives, Evidence and Frequency
- Building and Tracking Risk Action Plans
- Collecting and Aggregating Risk Data
- Validating Risk Data Quality
- KRIs, KPIs and KCIs
- Thresholds, Escalation Triggers and Appetite
- Metric Pitfalls and Misuse
- Continuous Monitoring versus Periodic Assessment
- Tailoring Risk Reports to the Audience
- Heat Maps, Dashboards and Scorecards
- Identifying and Assessing Emerging Risks
- Integrating Emerging Risk into Decisions
Designing and Selecting Controls
Select from the risk
Principles of good design
Weighing the trade-offs
| Factor | Question |
|---|---|
| Effectiveness | How much does it reduce the risk? |
| Cost | What’s its total cost over its life? |
| Fit | Does it work with our processes and systems? |
| Usability | Will people use it, or work around it? |
| Side effects | Does it create new risks or slow the business? |
Example. To reduce payment fraud, a manual call-back check was cheap but slow and often skipped. An automated rule that held new-payee payments for independent approval cost more but ran every time, and was chosen.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| FIRST step in selecting a control | Understand the risk and the control objective |
| MOST effective control type, all else equal | Automated preventive |
| Control that people work around | Poor fit; redesign it |
| When to define control evidence | At design |
In short
- Start from the risk and the control objective, not from a product or catalogue.
- Evaluate options for effectiveness, cost, fit with processes and architecture, usability and side effects.
- Prefer automated, preventive controls where they fit, backed by detective controls.
- Good design addresses the root cause, sits at the right point in the process and is hard to bypass.
- Define the owner, evidence and metrics when the control is designed.
Exam traps
- Selecting a control because a vendor recommends it.
- Choosing the most technically advanced control regardless of fit.
- Designing controls that privileged users can easily bypass.
- Leaving ownership and evidence to be sorted out after go-live.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Select from the risk
Principles of good design
1 / 7