An outage starts quietly. A user calls an administrator they know, who takes a look and restarts the service. An hour later a second user calls, reaches somebody else, and the service is restarted again. Three days on, nobody in the organisation can answer a simple question: how many times did this happen this month, and why. Neither competence nor goodwill was missing — what was missing was a process to turn isolated interventions into knowledge.
This is exactly the problem ITIL solves. It is not bureaucracy for its own sake, nor a set of forms to fill in, even though that association has stuck to it through years of failed implementations. It is a way to make the work of an IT team repeatable, measurable and resilient to staff turnover. In this article I explain how ITIL differs from ITSM, what version 4 genuinely changed, which practices to start with, and why most implementations run onto the same three rocks.
What is ITIL and why does it still matter?
ITIL (Information Technology Infrastructure Library) is a body of good practice for IT service management — the most widely adopted in the world and the one most often referenced in procurement. It originated in UK public administration in the late 1980s, from a simple need: to standardise how IT suppliers delivered services to government bodies. The rights now sit with PeopleCert, which acquired AXELOS in 2021.
The key word in that definition is service. ITIL shifts the perspective from “we maintain servers” to “we deliver a service that someone uses and someone pays for”. That sounds like semantics but has very concrete consequences. When you think in servers, success is a running server. When you think in services, success is a user who completed their task — even if a server stopped responding along the way and a standby instance took over.
The relevance of ITIL has not faded, despite a changed technology landscape. Cloud, containerisation and DevOps changed how systems are built, but they did not remove the questions ITIL answers: who owns the service, how is an outage reported, who approves a production change, how do we know the service performs as promised. A fully cloud-native, agile team still has to settle these — the only question is whether it does so deliberately or by trial and error.
In nFlo’s practice we most often meet organisations in an in-between state: they have a service desk tool and named SLAs, but the processes live mainly in the heads of a few experienced people. That works until the first holiday, an outage at an awkward hour, or the departure of a key administrator.
Remember: ITIL is not a standard to be implemented in full. It is a library of practices — you take what solves your problem and deliberately leave the rest.
What is the difference between ITIL and ITSM?
This is the most common confusion in the field, and the answer is simple: ITSM is the discipline, ITIL is one way of practising it. ITSM (IT Service Management) covers everything an organisation does to design, deliver, operate and improve IT services. ITIL is the most popular set of good practices describing how to do that.
An analogy that works well with boards: ITSM is cooking, ITIL is a cookbook. You can cook without a particular book, and you can use a different one — COBIT (stronger on governance and audit), VeriSM, or SIAM (useful when several suppliers are involved). Many organisations assemble their own approach from several sources.
An important practical distinction concerns certification. ITIL certifies people, not companies. There is no such thing as an “ITIL-certified company”, although the phrase regularly appears in tender requirements. An organisation wanting to formally confirm service management maturity implements and certifies against ISO/IEC 20000-1. If tender documentation asks for an ITIL certificate from the supplier, it is worth clarifying the intent before bidding.
The third difference concerns tooling. Systems described as “ITSM tools” — Jira Service Management, ServiceNow, GLPI or Zendesk — implement ITIL-inspired processes, but buying a tool is not implementing ITIL. This mistake is both common and expensive: the organisation buys a platform, configures forms, and a year later discovers that only the shape of the tickets has changed, not the way people work.
What did ITIL 4 change compared with ITIL v3?
ITIL 4, published in 2019, answers the criticism most often levelled at version three: that it was too heavy, too sequential and a poor fit for agile ways of working. The change goes deeper than cosmetics, but it does not invalidate the previous version.
The most visible difference is the shift from 26 processes in ITIL v3 to 34 practices in ITIL 4. This is not merely renaming. A process suggests a rigid sequence of steps; a practice is a set of organisational resources dedicated to performing work — people, competences, tools and ways of working. A practice can be realised differently depending on context; a process less so.
The second change replaces the five-stage service lifecycle with a service value chain of six activities: plan, improve, engage, design and transition, obtain/build, and deliver and support. The crucial difference is that these activities do not follow a fixed order — they are combined into paths suited to the situation at hand.
ITIL 4 also introduced seven guiding principles, two of which matter particularly for implementation practice: “start where you are” and “keep it simple and practical”. The first argues against demolishing working arrangements in the name of conformity to a model. The second is a direct warning against redesigning a process nobody will follow.
Completing the picture are the four dimensions of service management: organisations and people, information and technology, partners and suppliers, and value streams and processes. It works as a practical checklist — if you are designing a change and cannot say what happens in each of the four dimensions, the design most likely has a gap.
What is the service value system in ITIL 4?
The Service Value System (SVS) is the overarching construct of ITIL 4, describing how the parts of an organisation work together to turn demand into value. It comprises the guiding principles, governance, the service value chain, practices and continual improvement.
Its value is primarily communicative. The SVS provides language for discussing IT with the board without descending to infrastructure level. Instead of a report on storage array availability, the conversation becomes: how does business demand turn into a working service, and where does that path jam.
The element with the greatest practical impact — and the one most often skipped — is governance. It answers the question of who decides: who approves a high-risk change, who resolves a priority conflict between a project and operations, who accepts a deviation from standard. The absence of these answers is the most common reason a well-documented process fails in practice — because at the critical moment nobody feels entitled to decide.
Which ITIL practices should you implement first?
The answer is three, not thirty-four. Attempting the whole library at once is the surest route to abandoning the project within months.
Incident management comes first almost always, because it produces the fastest effect visible to users. The goal is narrow: restore the service as quickly as possible. The minimum required is a single intake point for tickets, unambiguous priority classification, and the rule that a ticket has an owner until it is closed.
Change enablement comes second, because it is the most effective way to cut self-inflicted outages. A significant share of incidents in a typical organisation originates in a change made without risk assessment and without a rollback plan. This does not mean a committee deliberating for two weeks — it means proportionality: standard changes proceed without approval, risky ones require a decision from an authorised person.
Problem management comes third and is most often omitted, which is a mistake. Without it a team fights the same fires indefinitely. The distinction is simple: an incident is an interruption to a service, a problem is its root cause. Closing an incident with a workaround is fine — provided the problem stays open and someone owns its resolution.
Only once these three are stable does it make sense to reach for configuration management and a CMDB, a service catalogue or service level management. The reverse order — CMDB first — is the classic implementation that ends with a database no longer reflecting reality within six months.
Rule of thumb: if you cannot say how many incidents you had last month and which three services generate most of them, you are not ready for a CMDB. Start by counting.
How does ITIL relate to security incident management?
This distinction deserves deliberate attention, because the same term describes two different processes with different goals. An incident in the ITIL sense is an unplanned interruption to a service or a drop in its quality — success is measured by time to restore. A security incident is a breach of confidentiality, integrity or availability — and there, restoring the service as fast as possible can be actively harmful, because it destroys evidence and may return a compromised system to production.
The organisational consequence matters: the security incident process needs its own escalation path, its own criteria and its own decision-makers. The service desk remains the most common first point of contact, but it needs a clear handover rule — one triggered early, on suspicion, rather than after confirmation.
At the same time, mature ITSM genuinely strengthens security in ways that are easy to overlook. A configuration record answers the question of which systems you actually have — without it, risk assessment is guesswork. Change enablement leaves a trace of who changed what and when, which is often decisive in reconstructing an incident. Supplier management brings order to accountability across the supply chain.
Why do most ITIL implementations fail?
Three recurring causes emerge from our implementation experience — and none of them is technical.
The first is implementing a tool instead of a process. The organisation buys a platform, configures forms and considers the matter closed. A year later, tickets land in the system but are resolved as before — by phone, bypassing the workflow, with the system updated after the fact. The result is duplicated work and data nobody trusts.
The second is designing the process for the auditor rather than for the work. The documentation describes a beautiful multi-stage flow with five levels of approval. In daily reality it is too slow, so people work around it — not out of bad faith, but because they have a job to do. A process that gets bypassed is worse than no process, because it creates an illusion of control.
The third is no process owner with a real mandate. The implementation is assigned to someone without the authority to settle demarcation disputes between teams. When the first conflict arrives — and it always does, because change enablement constrains somebody’s autonomy — there is nobody to resolve it, and the project quietly dies.
The common denominator is this: ITIL changes how people work, not how systems are configured. An implementation run as a technical project fails regardless of the quality of the tool.
How do you measure whether ITSM actually works?
The measure is not the number of practices adopted or the percentage of tickets logged in the system. Those indicators are easy to improve without improving anything that matters.
A set that genuinely tells you something is shorter. The share of recurring incidents shows whether problem management works — if the same outages return month after month, the process exists only on paper. The share of failed or rolled-back changes measures the quality of risk assessment around change. Time to restore, split between critical and other services, is more useful than a single average that masks the cases you care about most.
One indicator usually escapes attention and is worth watching: the share of tickets logged after the fact. If it rises, the process is being bypassed and the data in the system is losing value. It is an early warning indicator — it deteriorates long before SLAs do.
Every metric should come with a note on what decision you will take on its basis. A metric that changes nobody’s behaviour is a reporting cost with no return.
How does ITSM support NIS2 and DORA compliance?
Regulations do not require ITIL, and you should not promise the board that they do. They do require capabilities that mature ITSM delivers as a by-product — and that is the real budget argument.
The NIS2 Directive imposes obligations around incident handling, business continuity, supply chain security and cyber hygiene, together with strict reporting deadlines: an early warning within 24 hours, a notification within 72 hours and a final report within one month. Meeting the 24-hour mark requires a working intake point, unambiguous classification and a named decision-maker — precisely what incident management builds. We cover this further in our article on mapping NIS2 requirements to security standards, which also explains what mapping alone does not cover.
The DORA Regulation, covering financial entities, places additional emphasis on ICT third-party risk management and a register of supplier contracts. Supplier management practice and an orderly record of services and their dependencies are directly useful here.
A warning from practice: ITSM builds operational capability but does not replace regulatory decisions. Thresholds for qualifying an incident, criteria for treating it as significant and the authority to notify a supervisory body are ownership decisions. No service desk tool will make them for you.
What does a 12-month ITSM implementation roadmap look like?
The table below sets out the sequence we most often use in mid-sized organisations. The order matters more than the pace — each stage produces the data needed by the next.
| Stage | Scope of work | Condition for moving on | Typical trap |
|---|---|---|---|
| Months 1–2: starting point | Inventory of critical services, single intake channel, process owner appointed | You know how many tickets arrive and what they concern | Skipping an owner with a decision mandate |
| Months 2–4: incidents | Priority classification, escalation path, handover rule for security cases | Falling share of tickets logged after the fact | An intake form that is too elaborate |
| Months 4–6: change | Split into standard and risky changes, rollback plan, named approver | A measurable rate of rolled-back changes | The approval board as a bottleneck |
| Months 6–9: problems | Root cause analysis of recurring incidents, known error register | Falling share of recurring incidents | No team time set aside for analysis |
| Months 9–12: configuration | Dependency records for critical services, linked to the change process | Records update through change, not by hand | A CMDB built in isolation from change |
The roadmap is deliberately limited in scope. A service catalogue, service level management and automation make sense as the following year — provided the foundation works.
Where should you start in your organisation?
With one control question: can you state today how many incidents you had last month, which three services generate most of them, and what share of changes had to be rolled back? If answering takes a week of gathering data from several sources, your starting point is not tool selection or team training — it is putting the recording of work in order.
The second step is appointing a process owner with a real mandate — someone who can settle a dispute between the project team and operations. Without that, the implementation will stall at the first conflict of interest.
The third is picking one practice and taking it all the way, instead of starting on five fronts at once. Incident management delivers a user-visible effect fastest and builds the credit of trust needed for the harder work of change enablement.
At nFlo we run this from an assessment of the current state, through a design of practices matched to the scale of the organisation, to implementation and handover to the team. If you want to check where you stand and what would deliver the biggest effect in your case — let’s talk.
Three things to remember: ITIL is a library, not a standard — you choose from it deliberately. Implementing a tool is not implementing a process. Without an owner holding a decision mandate, even the best-designed process will not survive the first conflict.
