An organization can implement a comprehensive security framework, operate every control, and still get breached. That’s not a failure of the security program. That’s the nature of the risk. But most organizations haven’t done everything right. They’ve implemented the framework without building the foundation it requires, and that gap is where programs quietly fall apart.
Cyber risk shares a defining characteristic with fraud, which often falls under the same program and follows the same playbook without a traditional controls framework behind it. Both involve threats that are adversarial, adaptive, and actively working to circumvent controls are in place. A fire suppression system works reliably because fires don’t study the suppression system. A fire doesn’t probe for gaps in sprinkler coverage or time its ignition to coincide with a maintenance window. The control and the threat exist independently. In cybersecurity, the threat studies the controls, and an attacker who gets blocked by MFA doesn’t move on. They come back targeting the help desk with a social engineering campaign designed to bypass it. The threat evolves in direct response to the controls, and that cycle doesn’t end.
Controls are designed to protect as a system, with each layer reinforcing the others so that a gap in one is covered by another. In practice, they tend to get evaluated in isolation, and the gaps between them are where attacks land. An organization can have strong authentication controls and still be exposed because patching on a critical application server has slipped. The attacker exploits the unpatched vulnerability, establishes a foothold, and moves laterally through the environment. Authentication controls may slow them down. The initial entry, however, had nothing to do with authentication.
Banking fraud illustrates this at a broader scale. Banks have invested heavily in transaction monitoring, anomaly detection, and customer authentication. Those controls protect the institution reasonably well. Rather than attacking the bank’s systems directly, threat actors shifted to targeting customers through the digital channels banks had built, using social engineering to convince people to authorize transactions themselves. The bank’s controls are operating effectively, and yet customers are still getting scammed because the threat moved beyond what institutional controls can reach. Closing that gap would mean making it nearly impossible to bank.
A weak risk assessment leads to wrong controls and resilience plans that won’t hold.
Frameworks like NIST CSF and ISO 27001 have value. They give structure to what would otherwise be chaos, and they provide a common language for measuring maturity. Both are explicitly risk-based. They expect organizations to conduct risk assessments, understand their threat landscape, and use that context to select and prioritize controls. The frameworks are well-designed. The problem is that most organizations don’t perform those assessments at the depth needed to meaningfully inform their program.
These assessments are genuinely difficult to do well. They require experienced practitioners, access to meaningful threat intelligence, and a deep understanding of the business being protected. They are more art than science, and the difference between a risk assessment that drives real decisions and one that produces a color-coded matrix for a quarterly presentation is significant. Many organizations complete the assessment without reaching the level of specificity that would actually inform their program.
When that foundation is weak, everything built on top of it inherits the same blind spots. Controls get implemented according to the catalog, but without a clear understanding of what the business needs to protect, they aren’t covering the right things. The same weakness carries into resilience. Most frameworks prescribe business continuity planning, incident response, and disaster recovery, but those plans are only as good as the risk assessment behind them. An organization can have documented BCP, tested IR playbooks, and a disaster recovery program and still not be protecting what matters because no one did the work of figuring out what that is.
A framework gives you a structured approach for selecting and implementing controls. It can’t tell you what to protect. Only the business can do that. When the security team decides what matters in isolation, none of that alignment exists. Changing that means partnering with executives, information owners, and business leaders to understand what worries them and what could derail their objectives. When a risk assessment starts with those conversations, the security strategy gets built around actual priorities rather than assumptions about what should matter. Controls make sense because they’re protecting what the business identified as critical. Resilience plans make sense because they’re recovering the systems the business said it can’t operate without. The program holds together because the foundation is real.