ITIL and COBIT in Practice: Frameworks vs. Reality

There is a version of ITIL that lives in documentation binders, SharePoint sites, and the PowerPoint decks of IT governance consultants. It describes a world where every change request flows through a formal change advisory board, every incident is categorized and resolved according to a service level agreement, and every problem gets a root cause analysis that feeds back into the knowledge base. It is a sensible world. It is not, in most organizations, the world that actually exists.

ITIL, the IT Infrastructure Library, is a framework for IT service management published by AXELOS. It defines processes for incident management, problem management, change management, service level management, and a range of other disciplines. The processes are logically constructed. The definitions are clear. The intent, at its core, is that IT operates as a service organization with defined outputs, measurable quality, and documented accountability. None of that is wrong. The implementation failure is almost always organizational rather than conceptual.

What tends to happen in practice is that the formal ITIL process becomes the official channel while the actual work runs on informal ones. An incident occurs. The IT team gets a Slack message from someone who knows someone. The person who can actually fix the problem gets a phone call. The fix happens. Then, afterward, someone logs it in the ticketing system because the ticketing system is what the audit requires. The documentation reflects the process. The process did not actually drive the work. This is not cynical rule-breaking. It is what happens when the overhead of the formal process exceeds the time pressure of the actual problem.

I have seen this pattern described repeatedly by practitioners, and I think it reflects something real about how organizations function under pressure. ITIL's change advisory board process, for instance, is designed to prevent unauthorized changes from breaking production systems. That is a legitimate goal. But when a production outage is happening and the fix is a one-line configuration change, the organization has a choice: follow the CAB process and extend the outage by several hours, or make the change and backfill the documentation. Most organizations, in the moment, choose option two. The CAB process was not designed for emergencies. The emergency does not care.

COBIT is a broader governance framework, published by ISACA, that maps IT governance to business goals, risk management, and regulatory compliance. Where ITIL is focused on service management processes, COBIT is focused on governance structure: how does the board ensure IT is being managed well, how are risks identified and controlled, how does IT strategy connect to business strategy? COBIT is especially prevalent in regulated industries. Finance and healthcare organizations often implement COBIT because their auditors want to see evidence of IT governance, and COBIT provides a well-documented framework that auditors recognize and can evaluate against.

This is where the problem gets subtle. When a framework is adopted primarily because auditors want to see it, the implementation often optimizes for auditability rather than for operational value. COBIT compliance becomes about producing the right evidence rather than about making better decisions. The risk register gets maintained because it is in the audit scope. The board IT committee meeting gets documented because the auditors will ask for minutes. Whether the risk register reflects actual risk management conversations, whether the board IT committee has genuine insight into technology decisions, these are harder to measure and so they get less attention.

Neither framework is bad. I want to be clear about that, because I think the "frameworks vs. reality" narrative can tip into cynicism that the frameworks do not deserve. ITIL, when implemented thoughtfully, does improve service consistency and reduces the organizational chaos that comes from ad-hoc IT support. COBIT, when implemented genuinely, does help boards understand IT risk in ways they would not otherwise have access to. The problem is not the frameworks. The problem is that implementing them well requires organizational discipline, clear ownership, and consistent enforcement over time. Those things are hard. They require sustained leadership attention and the willingness to absorb short-term friction for long-term consistency. Most organizations find it easier to implement the artifacts of the framework without fully implementing its discipline.

What determines whether a framework implementation actually changes behavior, rather than just producing documentation, is mostly a governance question. Who owns the process? Do they have authority to enforce it when it is inconvenient? Is there meaningful consequence for working around it? If the change advisory board chair cannot say no to a senior executive who wants to push a change through off-cycle, the CAB is not really governing change. It is a ceremony. Ceremonies have their place, but they should not be confused with governance.

The IS literature on IT governance makes this point in various ways. There is a meaningful difference between having governance structures and having effective governance. Structures, rules, and committees are necessary but not sufficient. What makes them effective is the organizational culture and political will to actually use them as intended. A COBIT framework in an organization where the board treats IT as a black box is not doing much governing. An ITIL incident management process in an organization where the most effective path to resolution is always through personal relationships rather than tickets is not managing incidents in any meaningful sense. The documentation exists. The governance does not.

The question worth asking, before investing in framework implementation, is not "which framework is right for us." It is "do we have the organizational conditions that make any governance framework actually work." The conditions are: clear ownership with real authority, consistent enforcement regardless of seniority, and leadership that uses the framework's outputs to make decisions rather than treating it as a compliance exercise. Without those conditions, the framework will generate documentation and not much else.