Why Security Best Practices May Fail in Reality

It’s been a little while since my last post. I went back to university in January, so things have been busy – but it’s good to be back.

One thing that’s stood out to me recently is how much of the security advice we rely on is built around “best practices”. On paper, they make perfect sense. In reality, they often don’t hold up.

Security “best practices” are usually presented as universal truths – apply least privilege, patch quickly, follow the shared responsibility model, implement zero trust.

Individually, none of these are wrong. The problem is that they assume a level of clarity, control, and consistency that rarely exists in real environments. In practice, security isn’t implemented in isolation. It exists alongside competing priorities, legacy systems, unclear ownership, and constant change.

Take least privilege as an example. In theory, it’s straightforward – give users only the access they need. In reality, access requirements change quickly, teams move fast, and over-restricting access can slow down delivery. The result is often a compromise that looks good on paper but drifts over time.

Or consider patching. The guidance is clear: patch quickly to reduce risk and attack surface. But in production environments, patching can introduce instability, require downtime, or conflict with business priorities. So decisions get delayed, exceptions are made, and risk becomes something that’s managed rather than eliminated.

The shared responsibility model is another good example. It’s meant to clarify ownership, but in practice it often does the opposite. When responsibilities are split across teams, it can lead to gaps where everyone assumes someone else is handling it.

These gaps aren’t usually caused by a lack of awareness. Most teams know what the “right” thing to do is.

The issue is that best practices are designed for ideal conditions, while most organisations operate far from ideal conditions. There are always trade-offs – between security and speed, control and usability, risk and delivery. When those trade-offs aren’t acknowledged, best practices become difficult to apply in a meaningful way.

What tends to work better is a shift in focus – away from rigid adherence to best practices, and towards making informed, context-driven decisions. That might mean prioritising the most critical risks rather than trying to address everything at once. It might mean clearly defining ownership instead of relying on shared models. Or accepting that some level of risk is unavoidable, and managing it accordingly.

Good security is rarely about doing everything “by the book”. It’s about understanding where controls will actually be effective, and where they won’t.

Best practices are a useful starting point, but they’re not a substitute for judgement. Security doesn’t fail because people ignore best practices. It fails because applying them in the real world is more complex than the guidance suggests.

The goal isn’t to implement security perfectly – it’s to make decisions that still hold up when things aren’t.