Why IT Security Governance Keeps Failing, and What Actually Needs to Change

Jon Pertwee · February 2026

I have heard a variation of the following sentence from IT managers on more than one occasion, in organisations of different sizes, in different industries, in different countries:

,The person saying this is not being lazy or cynical. They are accurately describing the situation they are in. The governance framework exists. It was implemented, probably with considerable effort, possibly to satisfy an audit or achieve a certification. And now it sits on a shared drive, quietly becoming less accurate and less relevant, while the organisation continues to operate as though it doesn’t exist.

This is the normal state of IT security governance in most organisations. Not the state that COBIT white papers describe. The actual state.

I want to examine why this happens, because the standard explanations are not quite right, and what a more honest approach to governance looks like in practice.

The Standard Account and Why It Falls Short

The conventional explanation for governance failure goes roughly as follows: organisations lack leadership commitment, they fail to allocate sufficient resources, they do not embed governance into day-to-day operations, and they treat compliance as a one-time event rather than a continuous process. The solution is therefore better leadership buy-in, more resources, clearer accountability structures, and a culture of continuous improvement.

This is not wrong, exactly. But it is describing symptoms rather than causes, and it implies that the problem is one of effort or intent, that organisations fail at governance because they are not trying hard enough, or do not take it seriously enough. In my experience, that is rarely the actual problem.

The problem is structural. It has three interlocking components that each make the others worse.

Three Structural Problems

First: senior management does not understand IT risk as a corporate risk.

This is not a criticism. Most senior leaders have built their expertise in finance, operations, commercial strategy, or their industry domain. IT risk is genuinely difficult to understand without a technical foundation, and the way IT professionals typically communicate risk: in technical language, with reference to systems and protocols that mean little to a non-technical audience, does not help.

The result is that IT security tends to get treated as an IT problem. It sits in the IT budget, it is managed by IT staff, and it surfaces in board-level discussions only when something goes wrong. The strategic dimension: the question of what the organisation’s dependence on IT actually means for its risk exposure, rarely gets the attention it deserves. Security is seen as a cost of running IT systems, not as a component of managing enterprise risk.

Second: IT managers are often reluctant to drive governance upward.

This is the structural problem that I think is least discussed. The IT manager who understands that governance needs senior ownership faces a significant personal risk in pursuing it. To get leadership engagement, they need to sit in a room with people more senior than them and explain, clearly and confidently, why IT security is a corporate risk management issue rather than a technical one. They need to speak in business language: impact, exposure, liability, continuity, rather than technical language. They need to be comfortable challenging assumptions and asking difficult questions.

Many IT managers are not in that position, not because they lack capability, but because the role has not equipped them for it. They were hired to manage systems, not to conduct risk conversations with the board. If they try and it goes badly, they carry the professional consequences. If they do not try, the governance stays in the shared drive and nobody has to have an uncomfortable conversation.

The result is a structural stand-off: the people with the technical knowledge to drive governance do not have the organisational position to do so, and the people with the organisational position to own governance do not have the technical knowledge to understand what they are being asked to own.

Third: most governance frameworks are too complicated to be maintained in practice.

COBIT, ISO 27001, NIST: these are serious, comprehensive frameworks. They are also, in their complete form, formidably complex. Implementing them properly requires sustained effort, specialist knowledge, and ongoing commitment to keep documentation current as systems, threats, and regulatory requirements evolve.

Most organisations do not have the capacity for that. They implement the framework to a level sufficient for certification or audit, declare success, and move on. The framework is then maintained at that level of adequacy until the next certification cycle, which means it is gradually becoming less accurate as the organisation changes around it.

The IT manager who says nobody reads the governance documentation is describing the logical endpoint of this process. The documentation has drifted far enough from operational reality that it is no longer useful as a guide to what the organisation actually does or should do. At that point, updating it feels like effort spent on something that will not be used, and not updating it carries no immediate consequences.

Why Incidents Drive Governance More Than Frameworks Do

In practice, the most reliable driver of genuine governance improvement is not a framework implementation, it’s an event. A breach, a significant outage, a regulatory finding, a near-miss that makes the exposure visible in a way that abstract risk assessments don’t.

This is not how it should work. It is governance by consequence rather than governance by design, reactive rather than preparative. But it is how it works in most organisations, for a simple reason: an incident makes the cost of inadequate governance concrete and immediate in a way that a risk register or a compliance gap analysis does not.

When a senior manager receives a call at midnight because the organisation’s systems are down, or when a regulator writes to ask why a data breach was not reported in time, IT security governance stops being an abstract IT concern and becomes a very specific corporate problem with a very specific owner. Conversations that could not happen before the incident happen immediately after it.

This is the tail wagging the dog. The governance work that should have been done systematically over time gets done hurriedly in response to the event that would have been prevented if it had been done properly. The frameworks do not prevent this cycle, they describe what good looks like after the fact, and organisations implement them reactively to demonstrate that they have addressed whatever the incident exposed.

What a More Honest Approach Looks Like

None of this means that governance frameworks are useless or that the standard advice is wrong. ISO 27001 and COBIT describe genuinely good practices. The problem is not the frameworks themselves, it’s the conditions under which they are typically implemented and maintained.

A more honest approach to IT security governance starts from these premises:

• • • Governance needs to be translated into business risk language before it goes near senior management. The conversation should notbe ‘we need to implement COBIT’, it should be ‘here’s what happens to this organisation if these systems fail or are compromised, here is the likelihood of that happening, and here is what it would cost to reduce that likelihood to an acceptable level.’ That is a risk management conversation that a board can engage with.
    • Frameworks should be scoped to what can actually be maintained. A governance framework that covers the ten most critical risks clearly and is reviewed quarterly is more valuable than a comprehensive framework that covers everything and is reviewed never. Completeness is less important than currency and usefulness.
    • Ownership needs to be assigned at a level where it can be exercised. If IT security governance is owned by someone who does not have the authority to make decisions about resources, policy, or risk appetite, it’s not really owned, it’s just administered. Governance that matters needs to sit with someone who can act on what it reveals.
    • The IT manager’s position needs to be recognised for what it is. Asking an IT manager to drive governance conversations with senior leadership without giving them the support, training, and organisational backing to do so, is setting them up to fail. Organisations that want better governance need to invest in the people who are supposed to deliver it.

An Honest Starting Point

The organisations I have seen handle security governance most effectively are rarely the ones with the most sophisticated frameworks. They are the ones where someone in a position of genuine authority has decided that IT risk is their problem, not their IT manager’s problem, not their CISO’s problem, but theirs, and has allocated the attention and resources to manage it accordingly.

That decision almost never comes from reading a white paper about governance best practices. It usually comes from an uncomfortable conversation, a near-miss, or an event that made the exposure undeniable. The goal of good governance practice is to make that conversation happen before the event, rather than because of it.

If you are an IT manager navigating this landscape, or a senior leader who has started to wonder whether your organisation’s governance is as solid as the documentation suggests, feel free to get in touch.