ITIL stands for Information Technology Infrastructure Library. It's a framework of practices for delivering IT services well: how IT teams plan work, deliver it, support the people using it, and improve on all of that over time.
It isn't software, and it isn't a product you buy. ITIL is closer to a shared vocabulary that IT teams use so they aren't reinventing their process every time someone new joins the team or a new type of problem shows up. When an ITSM platform ships with built-in workflows for incident, problem, or change management, those workflows are usually built around ITIL terms and structure, whether or not the vendor says so explicitly.
Why the Framework Exists
Before something like ITIL, IT departments mostly made their process up as they went. Two teams inside the same company could handle the same kind of outage in two completely different ways, use different words for the same thing, and have no agreed way to say whether the response was actually good. That's fine at a small scale. It falls apart once IT has to support thousands of people, dozens of systems, and an audit trail someone eventually has to defend.
ITIL gave organizations a way out of that: common terms, a documented set of practices, and a way to talk about "value" that doesn't live entirely in one senior engineer's head. That's part of why an ITIL certification still means something on a résumé. It tells the next employer that you already speak the same process language they do, without a six-month onboarding period.
Where It Came From
The UK government's Central Computer and Telecommunications Agency put the first version together in the 1980s, originally to bring some consistency to IT across public-sector projects. It got consolidated into a more usable set of core books through the 1990s and 2000s (often called ITIL v2), and by the mid-2000s had spread well beyond government into large enterprises everywhere.
ITIL v3 arrived in 2007 and organized everything around a service lifecycle: Strategy, Design, Transition, Operation, and Continual Service Improvement. If you've been in IT for more than a decade, this is probably the version you originally trained on. A minor refresh followed in 2011 without touching that core structure.
The bigger break came in 2019 with ITIL 4, which swapped the linear lifecycle for something more flexible and built room for Agile, DevOps, and Lean thinking into the framework itself. AXELOS, a joint venture between PeopleCert and the UK Cabinet Office, owns and maintains ITIL today, and accredits the organizations that run ITIL training and exams.
ITIL Definition
The short version: ITIL is a way to run IT services so the outcomes are predictable, measurable, and repeatable instead of depending on who happens to be on shift.
The "library" part of the name is a holdover from how it was originally published, as a set of books covering different pieces of IT service management. Nobody thinks of it as literal volumes anymore. It's better understood as a menu of practices that organizations pick from based on what they actually need, not a checklist you implement in full on day one.
A few things worth clearing up, since these come up constantly in practice:
You don't need to be ITIL-certified to run an ITSM platform, and there's no such thing as an "ITIL-certified" tool, since certification applies to people, not software. It also isn't mandatory anywhere. It's guidance an organization chooses to adopt, and most only implement the pieces relevant to their size. Nor is it a development methodology competing with Agile or Scrum; it governs how you manage services once they exist, including ones built the Agile way. And it's not the same thing as an ITSM tool, full stop: the framework describes what good service management looks like, the platform is where that management actually happens.
It's fair to ask whether a framework with 1980s roots still has anything to say now that cloud infrastructure, DevOps, and AI-driven service desks have changed how IT actually runs. It does, mostly because the underlying problems haven't gone anywhere. Inconsistent process, unclear ownership, and no visibility into service health are still the things that break at scale. If anything, they matter more as AI agents start handling frontline resolution, because a system can only automate a process reliably if that process was clearly defined in the first place.
What the IT Infrastructure Library Covers
ITIL spans the full lifecycle of an IT service, but a handful of practices come up constantly in day-to-day operations. Incident management is about getting a disrupted service back up fast. Problem management picks up from there and digs into root cause, so the same issue stops recurring. Change management, which ITIL 4 calls change enablement, governs how changes to systems and infrastructure get assessed and approved before anything goes live. There's also request fulfilment for the routine stuff (access requests, provisioning) that isn't really a "problem" at all, knowledge management for making sure a team only has to solve something once, service level management for tracking whether IT is actually hitting the commitments it made, and configuration management for keeping an accurate picture of what assets exist and how they connect.
Put those together and they give an organization a shared language for how work gets done, which is exactly why they end up baked into the workflows of most ITSM platforms.
The Full Set of ITIL 4 Practices
ITIL 4 groups 34 management practices into three buckets. General management practices are organization-wide disciplines applied to IT, things like strategy management, risk management, and workforce planning. Service management practices are the ones tied most directly to daily IT delivery: the practices above, plus service desk, service catalogue management, capacity and performance management, and monitoring and event management. Technical management practices are borrowed from other technology domains and adapted for a service management context, covering deployment, infrastructure and platform management, and software development.
Almost nobody implements all 34 formally. Most organizations start with incident, problem, change, and knowledge management, since those tend to be where the pain shows up first, and grow into the rest as they mature.
A Quick Walkthrough
Here's roughly how these practices play out in a real support scenario. Someone submits a request through the service desk, or an outage gets flagged automatically. The ticket gets logged and categorized, and if it needs a person, it gets routed to whoever's best positioned to handle it, ideally with a knowledge base article from a past similar issue attached. If the same problem keeps coming back, or the root cause isn't obvious, it escalates into problem management for a deeper look. Any fix that touches production goes through change management for a risk check before anyone deploys it. And service level tracking runs underneath all of it, checking whether the response actually landed inside the commitments IT made.
AI-driven ITSM platforms now automate a large chunk of that sequence, with agents handling triage, drafting resolutions off the knowledge base, and routing anything unusual to a human. Who does the work at each step has changed; the ITIL practice defining what "correct" looks like at that step hasn't.
ITIL 4 Overview
ITIL 4 landed in 2019 as the current version of the framework, trading the older, more sequential lifecycle model for something built around two ideas. The Service Value System describes how all components and activities of an organization work together as a system to enable value creation. Within it, the Service Value Chain defines an operating model of six flexible activities that convert demand into actual business value. For a detailed breakdown of both, see the ITIL framework guide. The Four Dimensions Model is the set of lenses (organizations and people, information and technology, partners and suppliers, value streams and processes) you're supposed to look through together, rather than optimizing one at the expense of the others.
The update also expanded the old process list into 34 management practices and, notably, folded Agile, DevOps, and Lean ideas directly into the framework instead of treating them as things happening outside it. That wasn't a cosmetic change. ITIL v3's lifecycle model assumed IT worked in more sequential, slower-moving stages than most teams actually do anymore.
What changed between the two versions, roughly:
| ITIL v3 | ITIL 4 | |
|---|---|---|
| Structure | Linear lifecycle: Strategy, Design, Transition, Operation, CSI | Service Value System, activities interconnect rather than run in sequence |
| Scope | 26 processes | 34 management practices |
| Modern IT | Little direct reference to Agile or DevOps | Agile, DevOps, and Lean built into the model |
| Emphasis | Process compliance | Value created with stakeholders |
| Approach | Prescriptive and sequential | Adaptive, applied based on context |
None of this makes an organization still running ITIL v3-style processes non-compliant with anything. ITIL 4 is an evolution of v3, not a replacement of it, and most of the core practices, incident, change, and problem management among them, carried over conceptually even as the terminology shifted.
ITIL vs ITSM
People mix these up constantly, so it's worth being precise about the difference. ITSM, IT service management, is the overall discipline of designing, running, and improving how IT delivers services to a business and the people who use them. ITIL is one specific, well-documented framework for doing that discipline. It's the most widely adopted one by a wide margin, which is part of why people default to learning it first.
Not every organization doing ITSM runs ITIL, though. Some lean on COBIT, some use ISO/IEC 20000, plenty build their own thing or mix pieces of several. ITIL just tends to win by default because it's better documented than most of the alternatives.
An ITSM platform is a separate thing again: the actual software where incidents get logged, changes get approved, and knowledge gets written down, regardless of which framework shaped how those workflows were designed.
A kitchen analogy sometimes helps here. ITSM is the discipline of running a kitchen well. ITIL is one specific, detailed recipe book covering everything from how an order comes in to how the pantry gets restocked. Other recipe books exist, and plenty of good kitchens borrow from more than one. The stove, the ticket rail, and the register, the tools people actually touch, are the ITSM platform. A kitchen can run without anyone opening the recipe book at all, though most well-run ones keep one nearby.
ITIL Certifications
ITIL certifications validate an individual's knowledge of the framework across four main tiers: Foundation (entry-level basics), Managing Professional (day-to-day service management), Strategic Leader (aligning IT with business strategy), and ITIL Master (demonstrated practical application). They are designed for IT support technicians, operations managers, change managers, and consultants who need a shared service management vocabulary. For a complete role-mapped roadmap, see the ITIL framework guide.
Next Steps
ITIL supplies the practices. What actually puts them into action, especially now that AI is taking on more of the frontline resolution work, is the ITSM platform running underneath them. If you want to see how ITIL-aligned processes show up in a real implementation, the framework guide below goes deeper.
Read the ITIL framework guide →
Frequently Asked Questions
What does ITIL stand for?
Is ITIL a certification or a framework?
What's the difference between ITIL and ITSM?
Is ITIL still relevant with AI-driven IT operations?
Do I need to be ITIL certified to use an ITSM platform?
