After years of working with different teams, hospitals, and software organisations, I've noticed a consistent pattern. The systems that failed were almost always the ones trying to do too much. The teams that stayed secure weren't necessarily the ones with the most advanced technology. They were the ones who made deliberate choices to keep things simple.
It took me a long time to realise that simplicity isn't minimalism. It's intentional design. And in practice, it's one of the strongest security controls we have.
When Complexity Breaks People
Security failures are rarely just technical. More often, they happen because systems become so restrictive or inconvenient that people start working around them. When controls ignore how users actually operate, the result is predictable: shadow workflows, personal devices, and insecure shortcuts.
In hospitals, for example, data-sharing processes can become so complex that clinicians revert to exchanging medical images on WhatsApp. Not out of negligence, but because the official process is unworkable under real-world time pressure. The same thing happens with aggressive web filtering or blanket bans on AI tools: people simply switch to their personal laptop or phone.
These controls look good in policy documents, but they often create more risk, more exceptions, and more support tickets. Complexity doesn't just break systems. It breaks user behaviour, and that is often far more dangerous.
Where Technical Complexity Creates Risk
Technical complexity introduces risks that are less visible but equally damaging.
Fragmented identity is a prime example. Everyone agrees that SSO improves security, yet implementing SSO everywhere is still harder than it should be. The "SSO tax" is real. And even when organisations achieve broad SSO coverage, outdated password policies (mandatory resets every 30 or 90 days, strict composition rules) undermine the whole effort. Users fall back on incremental passwords or predictable patterns. Much of this stems from IT practices that have not evolved in line with modern NIST or ANSSI guidance, and from outdated assumptions about how authentication actually works today.
Security tools themselves are not always the source of complexity. It's how they're combined and operated. A company running ten security tools can deliver a smoother experience than one running two, if the ecosystem is well integrated and invisible to users. Conversely, a full Microsoft 365 security stack can create friction if misconfigured, while a mixed environment (Google Workspace, SentinelOne, NinjaOne, Okta or JumpCloud) can feel seamless. Tool count matters far less than coherence.
Cloud architecture suffers from the same pattern. Many teams still treat AWS or Azure as a virtual datacenter and lift-and-shift their legacy layouts unchanged. This almost always results in systems that are fragile, expensive, and painful to operate. It's not a cloud problem. It's a misunderstanding of what cloud is designed for.
Networking often follows legacy logic as well. Flat networks segmented into dev/stg/prod and accessed through a VPN belong to an earlier era. Modern access approaches, delivered through tools like Tailscale or Twingate, offer fine-grained, identity-based access while dramatically simplifying the user experience. "Zero Trust" as a term may be vague, but the principle is straightforward: legacy networks are both more complex and less secure.
And then there are environments built around exceptions. These typically appear in organisations where IT tries to control every permission, every group, every approval. Over time, exceptions pile up because the rules don't match reality. The result is a fragile system held together by workarounds.
Automation can create its own complexity when used prematurely. Many companies automate processes before simplifying them. The outcome is predictable: brittle workflows, unclear ownership, and failures that are harder to diagnose. Automating a broken process does not fix the process. It simply makes the failure faster and more opaque.
Governance as the Foundation for Simplicity
Governance is often misunderstood. Many small and mid-size organisations either have no governance at all or treat it as bureaucracy that slows everything down. In reality, governance is what keeps IT, security, and operations coherent and aligned with business objectives. It defines who is accountable for what, how decisions are made, and where risk is accepted.
Without governance, organisations drift into a form of security chaos. One common pattern is that IT ends up taking full responsibility for security simply because nobody else does. Risk appetite is never defined, responsibilities are unclear, and IT becomes the default owner of everything. This pushes teams into a defensive posture: restrictive controls, slow approvals, and an overwhelming workload. Users disengage, workarounds appear, and the environment becomes harder to maintain.
In several organisations I've worked with, I've seen the consequences of unclear governance. When roles and responsibilities aren't defined, IT ends up carrying the full weight of security decisions, often alone. This naturally leads to defensive behaviour: tighter restrictions, slower approvals, and an overwhelming workload. Over time, users disengage, workarounds appear, and the environment becomes harder to maintain. Despite good intentions, the result is more complexity, not less, and security suffers rather than improves.
Good governance isn't about bureaucracy. It's about clarity. It's what allows IT and security teams to operate deliberately, not defensively.
What Makes a System Simple Enough to Be Safe
Simplicity doesn't mean cutting corners or eliminating tools. It means designing systems that are intentional, predictable, and aligned with real-world behaviour.
A simple system starts with strong identity and a clear source of truth. When identity is consistent, everything else becomes easier: access, audit evidence, automation. Predictable automation patterns, like Infrastructure as Code with Terraform or Ansible, reduce entropy across environments. I've seen teams manage multi-cloud more effectively with good IaC than others manage a single cloud by hand.
Transparency is another key indicator. Hidden flows, undocumented exceptions, and tribal knowledge create fragility. Systems are safer when access patterns and expectations are explicit.
A lack of exceptions is also a sign of simplicity. If a rule generates constant exceptions, the rule itself is often the problem. Adjusting the rule creates more stability than compensating for it endlessly.
Finally, documentation matters. Not corporate templates or 80-page PDFs, but practical information that sits where people actually work. A system that can be understood in under thirty minutes is not only easier to operate. It's easier to secure.
Principles for Leaders
- Start with identity before tools.
- Reduce exceptions instead of adding controls.
- Simplify processes before automating them.
- Prioritise user experience. It's a security control.
- Choose predictable patterns over clever architectures.
- Define risk appetite clearly and share responsibility.
- Document what matters and ignore the rest.
The Bottom Line
The organisations I've seen stay secure over time weren't the ones with the biggest budgets or the most tools. They were the ones disciplined enough to avoid unnecessary complexity and clear enough in their governance to make simplicity possible. Simplicity forces better thinking. It reduces cognitive load, operational overhead, and the need for workarounds. It's not elegance for its own sake. It's resilience.