ITIL vs COBIT: running the service, and proving it's governed
ITIL runs IT services; COBIT tells the board what must be governed and how to prove it. Where they overlap, which to start with, and a template that joins them.
ITIL and COBIT aren't rivals. They answer different questions for different people.
ITIL asks: are we running our services well? COBIT asks: are we doing the right things with IT, and can we prove it to the board, the auditor and the regulator?
I hold certificates in both, and I've used both in delivery. The organisations that get value from them use ITIL to run the work and COBIT to govern it. The ones that struggle pick one and expect it to do both jobs.
What each one is
ITIL is guidance for IT service management, published by PeopleCert. The current version, ITIL (Version 5), sets out 34 management practices, such as incident management, problem management, change enablement and service level management. It's written for the people who design, run and improve services.
COBIT is a framework for the governance and management of enterprise information and technology, published by ISACA. The current edition, COBIT 2019, has 40 governance and management objectives in five domains:
| Domain | What it covers |
|---|---|
| EDM: Evaluate, Direct and Monitor | Governance: the board's job |
| APO: Align, Plan and Organise | Strategy, budgets, risk, suppliers, service agreements |
| BAI: Build, Acquire and Implement | Projects, requirements, changes, configuration |
| DSS: Deliver, Service and Support | Operations, incidents, problems, continuity, security |
| MEA: Monitor, Evaluate and Assess | Performance, internal control, compliance, assurance |
COBIT's central idea is that governance and management are different jobs. The board evaluates options, sets direction and monitors results. Management plans, builds, runs and monitors the work. ITIL lives almost entirely on the management side.
The difference in one table
| ITIL | COBIT | |
|---|---|---|
| The question | How do we run this service well? | Are the right things being done, and can we show it? |
| Main readers | Service desk, operations, service and product owners | Board, CIO, risk, internal audit |
| Gives you | Practices, guiding principles, how-to guidance | Objectives, controls, decision rights, capability levels 0 to 5 |
| Strongest at | Incidents, problems, change, service levels | Decision rights, risk, assurance, alignment with the business |
| Measures | Service outcomes: availability, restoration time, satisfaction | Capability and conformance: is the control designed, followed, evidenced? |
| Certification | People, through PeopleCert | People, through ISACA |
Where they meet
Many COBIT objectives describe what must be managed; the matching ITIL practice describes how to run it. These are the pairs I use most:
| COBIT 2019 objective | ITIL practice that runs it |
|---|---|
| APO09 Managed Service Agreements | Service level management |
| APO10 Managed Vendors | Supplier management |
| BAI06 Managed IT Changes | Change enablement |
| BAI10 Managed Configuration | Service configuration management |
| DSS02 Managed Service Requests and Incidents | Incident management; service request management |
| DSS03 Managed Problems | Problem management |
| DSS04 Managed Continuity | Service continuity management |
| MEA01 Managed Performance and Conformance Monitoring | Measurement and reporting |
The EDM domain has no ITIL equivalent. ITIL acknowledges governance, but it doesn't tell a board how to set risk appetite or which decisions it must keep for itself. That's COBIT's territory.
Two examples from delivery
A control that paid for itself. On one enterprise migration, the governance step before sign-off asked one question: had compatibility been checked for every critical dependency, not just the ones in the test plan? It hadn't. A VPN defect was sitting in the gap, and catching it averted a projected $2.5M business impact. The question is COBIT thinking: a decision right, held by someone with the authority to pause go-live, and evidence required before approval. Answering it is ITIL work: change enablement and testing. Either framework alone leaves a gap like that open; together they close it.
A practice that needs an owner. Structured ITIL problem management is how my teams cut recurring incidents by 40%. The practice is ITIL. What keeps a practice like that working is the accountability COBIT asks for: one named owner for each problem record, a measure reported every month, and evidence that actions closed. Without it, problem records stay open for months while every team says the fix is someone else's.
Which one to start with
Start with the pressure you're actually under.
- Outages, SLA breaches, repeat incidents, unhappy users: start with ITIL. Fix incident, problem and change first; they're where service quality is won or lost.
- Audit findings, a regulator's questions, a board asking about IT risk: start with COBIT. Use its design factors to choose which objectives matter for your organisation, rather than trying to implement all 40.
- Both, which is the usual case: run ITIL practices for the work, and put a thin COBIT layer on top for decision rights, accountability and evidence.
Don't implement either framework in full. COBIT says so itself: its design factors exist so you tailor it. And ITIL gives direction, not instructions.
For people, the same rule applies. Service desk and operations managers get more from ITIL first. Anyone in IT governance, risk or audit, or reporting to a board, needs COBIT. A service delivery lead who talks to both the desk and the board needs both.
The template that joins them
For each practice that matters most to you, fill in one row. If you can't fill a cell, you've found your first governance gap.
| ITIL practice | COBIT objective | Accountable person (a name, not a team) | Measure reported monthly | Evidence an auditor can see |
|---|---|---|---|---|
| Incident management | DSS02 | e.g. restoration within target, by priority | SLA report and breach reviews | |
| Problem management | DSS03 | e.g. recurring incidents, problems closed on time | Problem records with root cause and dated actions | |
| Change enablement | BAI06 | e.g. failed changes, emergency change rate | Change records with category and authorisation | |
| Service level management | APO09 | e.g. SLA compliance against goal | Signed SLA and monthly service review | |
| Supplier management | APO10 | e.g. supplier SLA performance | Contract, review minutes and escalations |
The accountable person column is where most organisations get stuck. If you can't agree who owns closing an incident or problem record, the closure ownership tool works through it in a few questions and gives you the words to get a stakeholder to accept it. It runs in your browser; nothing you enter is sent to ITSM Compass.
The rule
Use ITIL to run the service. Use COBIT to decide who's accountable and to prove the controls work. If a framework is creating meetings instead of decisions, it's been copied, not designed: see governance is not bureaucracy.
Not sure whether ITSM and ITIL are the same thing? Start with ITSM vs ITIL.
Want this working in your organisation?
Take the free 3-minute ITSM maturity check, or book a 15-minute call to talk it through.