Home / Glossary / ITIL (IT Infrastructure Library)
Tech & ITITIL (IT Infrastructure Library)
By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site
A widely used framework of best practices for running IT as a dependable service.
ITIL is a framework for IT service management (ITSM): incident, problem and change management, with each ticket prioritised by its impact and urgency. Ticketing tools such as ServiceNow and Jira put it into practice, and it is the shared vocabulary of many IT help desks. It is not software, and an incident (restore service fast) is not a problem (remove the root cause).
The intuition
ITIL is a library of written guidance for running IT as a service that holds up, and it is the fastest way to understand why help desks everywhere look the same. The UK's Central Computer and Telecommunications Agency published the first volumes in 1989 so that government departments would stop inventing their own way of running computer operations; the framework is now owned by PeopleCert, which acquired its previous custodian Axelos in 2021. Most people never read a page of it. They meet it as the shape of a ticket queue: a field called impact, a status called resolved, a person called the change authority. That shared vocabulary is the real product. When your supplier, your service desk and your own team all mean the same thing by a P1 incident, the handover between them stops being a negotiation about words.
The distinctions that matter most are three record types, and each has its own purpose. An incident is an unplanned interruption to a service or a reduction in the quality of a service, and the goal is to restore service quickly; a workaround counts as success, so a restart that gets people working again resolves the incident even though nobody knows why it broke. A problem is the cause, or potential cause, of one or more incidents, and the goal is to reduce how often incidents happen and how much they hurt; a problem that has been analysed but not yet resolved is a known error, and the workaround is recorded against it. A change is the addition, modification or removal of anything that could have a direct or indirect effect on a service, authorised on the strength of its risk. In most implementations priority comes from two fields rather than from argument: impact, how much of the business is affected, and urgency, how soon a fix is needed, read off a matrix published in advance.
ITIL 4, published in February 2019, restructured the framework around a service value system, four dimensions, seven guiding principles and 34 management practices, and renamed processes as practices; change management appeared first as change control and was renamed change enablement soon after. The successor, branded ITIL (Version 5), rolled out through 2026, with PeopleCert putting the Foundation exam live on 12 February 2026 and further modules following; ITIL 4 stays available and a bridge exam exists for people already certified. At the edges the framework misbehaves in two directions. Too much and a one-line dashboard filter needs the same approval as a database migration, so people route around the process; too little and an outage has no owner. Practitioners tune the dial with standard changes, pre-approved and repeatable, and reserve full authorisation for genuine risk. If you build data or finance systems, you are both a customer of the service desk and the owner of a service, so incident management, problem management, change enablement and service request management are the four practices you will actually use.
One failed overnight load, walked through as an incident, then a problem, then a change
- 08:05 on a Tuesday: the finance desk opens the daily profit and loss dashboard and sees Monday's figures. Raise an incident with the fields the matrix needs: service = Daily P&L dashboard, impact = High (all 40 people on the desk), urgency = High (the 09:00 review), which on a three by three matrix gives priority P1. The desk's P1 target is resolution within 4 hours, so the clock reads 08:05 + 4:00 = 12:05.
- Restore first, diagnose later. The on-call engineer finds last night's load job in a failed state and reruns it at 09:05: airflow dags trigger pnl_daily. The dashboard refreshes at 09:20, so the rerun itself took 09:20 - 09:05 = 15 minutes. Resolution time is 09:20 - 08:05 = 1 hour 15 minutes, inside the 4-hour target, and the incident is resolved even though nobody yet knows why the job failed.
- Close the incident and open a problem, because this is not the first time. The ticket history for this service shows the same failure on 3 of the last 10 nights, a failure rate of 3 / 10 = 30%, and each one cost about the same 75 minutes of a trading morning: 3 x 75 = 225 minutes lost in two weeks.
- The problem record is where the investigation lives: type = Problem, linked incidents = INC-4310, INC-4392, INC-4471. The cause: the load starts at a fixed 02:00 and reads an upstream file that arrives at a variable time. On the three failing nights the file landed at 02:14, 02:31 and 02:47. The job was configured with 2 retries 5 minutes apart, so its last attempt fell at 02:00 + 2 x 5 minutes = 02:10, which on the worst night was 47 - 10 = 37 minutes too early.
- Publish a known error before the fix exists: the problem has been analysed but not resolved, and the workaround is documented as "if the dashboard header shows yesterday's date, trigger pnl_daily and allow 15 minutes". The next occurrence becomes a short service desk action instead of an escalation, which is the whole reason workarounds get written down.
- Raise the change, because removing the cause means altering production. Type = Normal change: it touches a scheduled production job, so it needs assessment and authorisation. It is not a standard change (this path has never been pre-approved) and not an emergency change (nothing is broken right now). Proposal: wait for the file with a sensor instead of a fixed start, and raise the retry policy to 6 retries 15 minutes apart, covering 6 x 15 = 90 minutes.
- Put the exact difference in the change record so the reviewer does not have to guess. The fixed 02:00 start gains a sensor that waits for the upstream file, and the DAG's default arguments go from retries: 2, retry_delay: 5 minutes to retries: 6, retry_delay: 15 minutes. The new 90-minute window covers the worst observed delay of 47 minutes with 90 - 47 = 43 minutes to spare. Back-out plan: revert the DAG file to the previous Git commit and redeploy. Implementation window: Thursday 18:00, when no report is running.
- Close the loop. Link the change to the problem, and close the problem only after the job has run clean through a full cycle; if the incident recurs, the problem reopens and the known error stays published. Had the desk been dark on the morning of the board pack with no workaround at all, the same fix would have gone through as an emergency change: authorised on the spot by the change authority, with the assessment and review done afterwards rather than before.
The incident bought the morning back, the problem explained why, and the change stopped it happening again; skip either of the last two and you will run the same P1 next week.
Common pitfalls
- Resolving the incident and calling the job done. Service is back but the cause is untouched, so the same outage returns while your incident count climbs and your problem queue stays empty; a second occurrence is the usual signal to open a problem.
- Arguing about priority instead of looking it up. Priority comes from impact and urgency on a matrix everyone agreed in advance, so when seniority decides it instead, one person's inconvenience outranks a genuine outage and the P1 label stops meaning anything.
- Logging a service request as an incident. Asking for access to the reporting schema is routine work you offer on purpose, not an unplanned interruption, and mixing the two inflates incident counts and makes service level reporting meaningless.
- Assuming the tool makes you ITIL-aligned. ServiceNow, Jira Service Management and Freshservice ship ITIL-shaped fields, but they only encode the practices you actually run; ITIL is guidance you adapt, and it certifies individuals, while the standard an organisation gets audited against is ISO/IEC 20000.
- Putting every change through full authorisation. When a one-line dashboard filter needs the same approval path as a schema migration, people learn to make the change quietly and log it later; classify the repeatable low-risk work as standard changes and pre-approve it once.
Frequently asked questions
What is ITIL in simple terms?
ITIL is a published set of best practices for running IT as a service: how to handle outages, requests, changes, suppliers and service levels. It is guidance and a shared vocabulary, not software you install and not a rule you are obliged to follow. Organisations adopt the parts that fit, usually through a ticketing tool that encodes the practices they chose.
What is the difference between an incident and a problem in ITIL?
An incident is an unplanned interruption or a drop in service quality, and it is closed as soon as service is restored, including by a workaround. A problem is the cause, or potential cause, of one or more incidents, and it is closed only when that cause has been removed or knowingly accepted. One outage can therefore produce an incident that closes in an hour and a problem that stays open for a month.
What is ITIL 4 and how does it differ from ITIL v3?
ITIL 4 was published in February 2019. It replaced the v3 service lifecycle with a service value system, added four dimensions and seven guiding principles, and reorganised the content into 34 management practices. The names moved too: processes became practices, and change management became change enablement (published first as change control, then renamed), although the daily work of incident, problem and change looks much the same.
Is there an ITIL 5, and does ITIL 4 still count?
Yes. PeopleCert, which owns ITIL after acquiring Axelos in 2021, rolled out the version branded ITIL (Version 5) during 2026, with the Foundation exam going live on 12 February 2026 and further modules released after it. ITIL 4 remains available and existing ITIL 4 certificates keep their value, with a shorter bridge exam offered to holders who want to move across.
How is incident priority calculated in ITIL?
Priority is read off a matrix combining impact, how much of the business the incident affects, and urgency, how quickly a resolution is needed. ITIL does not mandate one grid, but a common setup uses three levels of each, giving a three by three matrix mapped to priorities P1 to P5. Because the matrix is published in advance, assigning priority is a lookup rather than a debate, and it is what the service level targets attach to.
Is ITIL certification worth it for a data or finance analyst?
The vocabulary is worth learning; the certificate is rarely worth funding yourself early on. Knowing incident, problem, change and service request is what lets you raise a ticket that gets actioned, read an outage report and get a pipeline change approved, and that takes an afternoon. The Foundation certificate mainly pays off in service management, operations or consulting roles, or when an employer pays for it.