Control Frameworks Built Backwards
This post builds on an excellent discussion started by Jeremy Gledhill on LinkedIn about applying the 5 Whys to risk controls.
Jeremy Gledhill’s application of the 5 Whys to controls, not just incidents, exposes a fundamental flaw: most control frameworks are built backwards.
Organisations start with standardised catalogues—ISO, NIST, industry frameworks—then work backwards to justify coverage. Few start with business context, threat landscape, and actual vulnerabilities to determine which controls reduce risk and which waste resources managing someone else’s risk profile.
Three Compounding Failures
This backwards approach produces three compounding failures that undermine control effectiveness:
Controls That Don’t Address Actual Risk
Catalogue-first design produces controls implemented because they’re “standard,” not because they reduce specific exposure. Resources get consumed demonstrating coverage, not changing outcomes.
When you start with a catalogue instead of contextual threat and vulnerability analysis, you end up implementing controls because they’re recommended by frameworks, not because they materially reduce your specific risk exposure.
Controls That Don’t Work as a System
We test controls in isolation but deploy them where they must integrate to prevent cascading failure.
Consider this common scenario:
- A detective control that triggers too late
- A preventive control creating workarounds under pressure
- A corrective control requiring manual intervention when teams are stretched
Result: simultaneous collapse under stress, not defence in depth.
Individual controls might look well-designed in isolation. But when they fail to integrate—when one control’s assumptions invalidate another’s effectiveness, or when controls create conflicting incentives—the entire system becomes brittle rather than resilient.
Controls That Can’t Survive Their Own 5 Whys
Context-first design: the 5 Whys surfaces whether a control changes outcomes.
Catalogue-first design: the 5 Whys exposes the control exists to demonstrate compliance, not manage risk.
Starting With Context
Strong risk management starts with context, not catalogues:
- What are we protecting and why? Understand business impact, not just asset lists.
- What threats are credible in our environment? Focus on realistic attack scenarios, not theoretical possibilities.
- What vulnerabilities exist in our systems? Identify actual weaknesses, not catalogue every potential gap.
- Which controls materially reduce likelihood, impact, or detection time? Quantify effectiveness where possible.
- How do they integrate under stress to prevent cascading failure? Test control interaction, not just individual performance.
From Inventory to System
Most control frameworks are compliance inventories, not defence systems designed for business context.
The gap between these two approaches becomes visible when you ask: “Can we explain why each control exists in relation to specific threats, and how they integrate to prevent cascading failure?”
If the answer is no, you’re managing inventory, not risk.
Applying the 5 Whys Earlier
The 5 Whys should be applied before controls are selected, not after they fail.
When selecting controls:
- Why this control? What specific risk does it reduce?
- Why this implementation? What makes this approach effective in our context?
- Why these resources? Does the investment match the risk reduction?
- Why these assumptions? What conditions must hold for this control to work?
- Why this integration point? How does this control reinforce or conflict with others?
Asking these questions during control selection prevents implementing controls that look good on paper but fail under operational pressure.
The Path Forward
Building effective control frameworks requires:
- Start with business context - Understand what matters and why
- Analyse actual threats - Focus on credible scenarios in your environment
- Identify real vulnerabilities - Base controls on actual weaknesses, not theoretical gaps
- Design for integration - Ensure controls work together, not just individually
- Test under stress - Validate control effectiveness under realistic pressure
- Apply 5 Whys continuously - Question assumptions before and after implementation
Many control frameworks would fail their own 5 Whys analysis if we applied the same rigour we expect from the processes they’re meant to govern.
Want to discuss control framework design or risk management approaches? Connect with me on LinkedIn.