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
Implementing Controls and Why Implementations Fail
From design to operation
A control is implemented when it operates, has an owner and produces evidence, not when a tool is installed.
Why implementations fail
Checking it’s real
- Is there a named operational owner?
- Does it cover the full scope intended?
- Has it been tested in production conditions?
- Is evidence produced and retained?
- Has residual risk been re-assessed?
Example. A DLP tool was bought and installed, and the data loss risk was marked “treated”. A year later, testing showed the tool was in monitor-only mode with no one reviewing alerts. The risk had never really been reduced.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| When is a control implemented | When it operates, is owned and produces evidence |
| MOST common cause of control failure | Lack of ownership or poor fit with processes |
| After a new control goes live | Test it and re-assess residual risk |
| Changes to a control | Through change management |
In short
- A control is implemented when it operates, has an owner and produces evidence, not when a tool is installed.
- Implementation follows plan, build, test, deploy, hand over and monitor.
- Common failure causes: no owner, poor fit, scope gaps, lack of resources, no testing and later changes.
- Changes to controls go through change management.
- After implementation, reassess residual risk based on the control as it actually works.
Exam traps
- Marking a risk treated once the tool is purchased.
- Skipping testing because the vendor says the product works.
- No handover to an operational owner.
- Assuming a control stays effective after system changes.
Slides
Click the slide and use the arrow keys. F toggles full screen.
From design to operation
Why implementations fail
1 / 7