Most organisations aren’t short on security controls. They have MFA, firewalls, backup systems, EDR, awareness training, and control registers mapped neatly to NIST or ISO 27001.
Yet breaches keep happening through weaknesses that, on paper, look addressed. MFA exists but not on every privileged account. Backups run but no one’s confirmed they restore in time. Logs are collected but not from the systems that matter most.
The problem usually isn’t a missing control. It’s a control with a gap. So the right question isn’t “Do we have this control?” It’s “Is it actually reducing the risk it’s meant to reduce?”
Presence Isn’t Effectiveness
A control can exist and still fail to work a policy approved but never implemented, a tool deployed to only part of the environment, a process that holds up in an audit but breaks down on a busy Friday. Effectiveness means the control produces its intended outcome in the organisation’s real operating conditions not just that a document or screenshot proves it exists.
Five Ways Controls Quietly Fail
1. Design gaps The control works exactly as designed, but the design itself is weak (e.g., a 90-day password policy with no MFA requirement).
2. Implementation gaps Good design, incomplete rollout (EDR required everywhere, but several business units are still uncovered).
3. Coverage gaps The control works for most of the environment but misses privileged accounts, legacy systems, third parties, or service accounts exactly the paths attackers look for.
4. Operating gaps The control exists but isn’t performed consistently: alerts generated but not investigated, access reviews chronically late, backups that run but error out.
5. Evidence gaps Nobody can actually demonstrate the control is working. Not proof of failure but proof of uncertainty, which shouldn’t be quietly treated as success.
Why Control Registers Create False Confidence
Red/amber/green dashboards flatten everything into the same categories, so a missing policy review date can look just as urgent as absent MFA on privileged remote access. Two controls both labelled “implemented” can have wildly different effectiveness one automated and monitored, the other a manual step one person remembers to do. The goal isn’t more green statuses. It’s understanding which gaps actually move the needle on risk.
Frameworks like NIST CSF 2.0 and the CIS Controls are useful for organising what to consider but they don’t tell you which weakness matters most for your organisation, right now. That requires connecting controls to real risk scenarios, assets, and consequences.
A Risk-Based Way to Close Gaps
- Define the outcome not “we have a SIEM,” but “critical security events are detected and investigated fast enough to limit damage.”
- Connect controls to risk scenarios a control with no link to a real, material risk should be challenged.
- Define what “effective” looks like measurable targets (coverage %, time-to-remediate, detection time), not vague aspirations.
- Gather real evidence configs, tickets, interviews, testing, exercises matched to the actual claim being verified.
- Describe the gap precisely what was expected, what was found, who’s affected, and which risk scenario it touches.
- Estimate the risk effect likelihood, impact, business importance, compensating controls, and exposure duration.
- Pick a proportionate response fix a config, extend coverage, add monitoring, accept the risk, or retire the process. Not every gap needs a new product.
The MFA Example
An org reports MFA as “fully implemented.” Dig in, and you find legacy remote access unsupported, third-party accounts excluded, emergency credentials sitting in a shared vault, and failed logins logged but unmonitored. Same headline status five different underlying gaps, each needing a different fix, prioritised by what they actually expose.
Questions Worth Asking
- What risk scenario is this control meant to reduce?
- What’s outside its coverage?
- How do we know it’s actually working and how would we know if it failed?
- What would our exposure be without it?
- Is the fix proportionate to the risk it removes?
Where PurpleWASP Fits
Control information is usually scattered across spreadsheets, audit reports, and disconnected tools making it hard to see how one weak control ripples across assets and risk scenarios. PurpleWASP connects controls to assets, owners, evidence, and FAIR-based risk scenarios in one workflow turning “twenty controls are partially implemented” into “these three gaps materially affect our ransomware exposure, and closing two of them meaningfully reduces it.”
The Bottom Line
Controls shouldn’t be judged by whether they appear in a framework mapping. They should be judged by whether they reliably do what they’re supposed to do. That means examining design, implementation, coverage, operation, evidence, and dependencies then spending limited resources on the gaps that actually matter.