ITIL Framework: Service Value System, Practices and ITIL 5 Explained

The ITIL framework is the best-known body of practice for IT service management: how organisations design, deliver, support and improve the technology services their customers and staff rely on. If you run a SaaS platform, a managed service, a support desk or an IT department, you are already doing the things ITIL describes, such as handling incidents, approving changes and agreeing service levels. ITIL gives those activities a shared vocabulary and tested practices.

ITIL 4, published in 2019, reorganised the framework around a service value system and 34 management practices. In early 2026, PeopleCert launched ITIL Version 5, which keeps the 34 practices but regroups them and adds new content, including on AI. This guide explains the structure, the practices that matter most for software and IT service companies, how to adopt ITIL without bureaucracy, and how it relates to ISO/IEC 20000-1, COBIT and security standards.

What is ITIL?

ITIL is a framework of best practice guidance for managing technology-enabled services. It is not a standard with requirements and it is not a law. It describes concepts, principles and practices that organisations adapt to their own context. The name originally stood for IT Infrastructure Library, from the series of books in which it was first published; today it is used as a name on its own.

ITIL 4 is built around the service value system (SVS), which shows how the parts of an organisation work together to turn demand into value:

• Guiding principles: recommendations that guide decisions in any situation.
• Governance: how the organisation is directed and controlled.
• Service value chain: six activities (plan; improve; engage; design and transition; obtain or build; deliver and support) combined into value streams.
• Practices: sets of organisational resources for performing work, such as incident management.
• Continual improvement: a recurring activity at every level.

ITIL 4 also describes four dimensions that every service and practice must consider: organisations and people; information and technology; partners and suppliers; and value streams and processes.

History and why ITIL was introduced

ITIL was developed in the 1980s by the UK government's Central Computer and Telecommunications Agency, which found that government IT services varied widely in quality and wanted a consistent approach. Version 2 (around 2000) became widely adopted internationally, focusing on service support and service delivery processes. Version 3 (2007, revised in 2011) introduced the service lifecycle of strategy, design, transition, operation and continual improvement. In 2013 ITIL passed to AXELOS, a joint venture of the UK Cabinet Office and Capita; PeopleCert acquired AXELOS in 2021.

ITIL 4, launched in 2019, responded to agile, DevOps, cloud and digital product development by moving from processes to practices and value streams. ITIL Version 5 was launched in early 2026, with its Foundation qualification first and further modules released in stages, including an AI governance extension. Training providers report that it keeps all 34 practices while regrouping them, so organisations using ITIL 4 do not need to change their practice set.

Who uses ITIL?

• Internal IT departments supporting employees and business systems.
• Managed service providers and IT outsourcing firms, where clients often specify ITIL-aligned processes and reporting in contracts.
• SaaS companies running production operations, customer support and incident communication.
• Government bodies and large enterprises, many of which require ITIL-certified staff in tenders.

ITIL is voluntary and global. It becomes a contractual expectation when a client or tender requires ITIL-aligned service management or staff with ITIL certifications.

The seven guiding principles

1. Focus on value: everything should link back to value for customers and stakeholders.
2. Start where you are: build on what already works instead of starting from scratch.
3. Progress iteratively with feedback: improve in small steps and learn from each.
4. Collaborate and promote visibility: work across teams and make work visible.
5. Think and work holistically: consider the whole system, including all four dimensions.
6. Keep it simple and practical: avoid steps that add no value.
7. Optimise and automate: improve first, then automate where it helps.

The 34 practices

ITIL 4 groups its 34 practices into three categories. ITIL Version 5 keeps the practices and reorganises the groups; check the current publications for the new grouping.

Group (ITIL 4)	Practices
General management (14)	Architecture management, continual improvement, information security management, knowledge management, measurement and reporting, organisational change management, portfolio management, project management, relationship management, risk management, service financial management, strategy management, supplier management, workforce and talent management
Service management (17)	Availability management, business analysis, capacity and performance management, change enablement, incident management, IT asset management, monitoring and event management, problem management, release management, service catalogue management, service configuration management, service continuity management, service design, service desk, service level management, service request management, service validation and testing
Technical management (3)	Deployment management, infrastructure and platform management, software development and management

The practices that matter most for software and SaaS companies

Incident management

Minimise the negative impact of incidents by restoring normal service as quickly as possible. In practice: monitoring and alerting, an on-call rota, severity definitions, an incident commander role for major incidents, status page updates, and a record of every incident with timestamps.

Problem management

Reduce the likelihood and impact of incidents by finding root causes and managing known errors. Blameless post-incident reviews with tracked actions are the most effective form for engineering teams.

Change enablement

Maximise successful changes by assessing risk, authorising changes and managing the schedule. ITIL 4 renamed it from "change management" to stress enabling flow: low-risk standard changes can be pre-authorised and automated through CI/CD, while risky changes get more review. Auditors for SOC 2, ISO/IEC 27001 and SOX look for evidence of this.

Service level management

Set clear, business-based targets for service performance, agree them with customers, and measure and report against them. For SaaS, this covers uptime, response and resolution times, and support hours.

Service desk and service request management

Capture demand for incident resolution and service requests through a single point of contact, with clear channels and categorisation.

Monitoring and event management, release and deployment management

Observe services, detect events that matter, and move changes into production reliably, which in modern teams is mostly pipeline automation with rollback.

Service continuity management

Ensure services can continue or recover after a disaster, linked to ISO 22301 and disaster recovery planning.

A worked incident flow for a SaaS team

ITIL does not prescribe tools or exact steps, but a typical ITIL-aligned major incident in a small SaaS company looks like this:

1. Detect: monitoring raises an alert on error rates or latency; the alert opens an incident record automatically and pages the on-call engineer.
2. Classify: the engineer sets severity using written definitions (for example, severity 1 when a core feature is unavailable to many customers) and declares a major incident if needed.
3. Coordinate: an incident commander is named, a dedicated channel is opened, and a first status page update goes out within the time your service level agreement promises.
4. Restore: the team focuses on restoring service (rollback, failover, scaling) before diagnosing root cause.
5. Communicate: regular status updates to customers and internal stakeholders until resolution.
6. Close and review: the incident record is completed with a timeline, and a blameless post-incident review identifies contributing factors and actions.
7. Problem management: actions are tracked as problem records until the underlying cause is fixed, and known errors are documented for support staff.

Each step leaves a record, which is exactly the evidence that SOC 2, ISO/IEC 27001 and client audits ask for under incident management.

What to put in a service level agreement

Service level management is where ITIL meets the contract. A useful SLA for a software or managed service usually defines:

• The service covered, and what is out of scope (for example, third-party integrations or customer-side configuration).
• Availability target and how it is measured, including planned maintenance windows and exclusions.
• Support hours and channels, and severity definitions with response and resolution targets for each.
• Incident communication: how and how quickly customers are informed.
• Reporting: what reports are produced, how often and with which metrics.
• Service credits or remedies, if any, and how they are claimed.
• Review: when the SLA and performance are reviewed together.

Targets should be ones you can measure automatically and meet consistently. An ambitious target that is missed every month damages trust more than a modest one that is always met.

How to adopt ITIL step by step

1. Start where you are: map how you currently handle incidents, changes, requests and service levels.
2. Define your services and who consumes them, with a simple service catalogue.
3. Pick a few practices with the biggest impact, usually incident, change enablement, problem and service level management.
4. Define roles: practice owners, on-call, incident commander, change approvers.
5. Configure tools: ticketing, monitoring, status pages and CI/CD integrated so that records are created automatically.
6. Agree service levels with customers and measure them.
7. Run post-incident reviews and track problem actions.
8. Train people, for example with ITIL Foundation for key staff.
9. Improve continually using the continual improvement model: what is the vision, where are we now, where do we want to be, how do we get there, take action, did we get there, how do we keep the momentum going.

Fitting ITIL to agile and DevOps teams

Engineering teams sometimes resist ITIL because they associate it with change advisory boards and slow approvals. ITIL 4 and Version 5 do not require either. Change enablement lets you classify most routine deployments as standard changes, pre-authorised because they pass automated tests and peer review in the pipeline. Normal changes with more risk, such as schema migrations or network changes, get a lightweight review by someone with the right expertise. Emergency changes are allowed with review afterwards. The guiding principles "keep it simple and practical" and "optimise and automate" are the test: if a step adds no value, remove it; if it adds value but is manual, automate it. Done this way, ITIL documents and strengthens what good DevOps teams already do, and produces the records auditors need without slowing delivery.

Documentation you will need

• Service catalogue and service descriptions.
• Service level agreements and reports.
• Incident, problem and change procedures with severity and risk definitions.
• Incident, problem and change records.
• Configuration and asset records.
• Release and deployment procedures.
• Continuity and recovery plans with test records.
• Supplier list and contracts.
• Continual improvement register.

Certification: people, not organisations

ITIL certifications are for individuals, issued by PeopleCert: Foundation, then advanced modules. Organisations cannot be "ITIL certified". When a client wants independent assurance of a service provider's service management, the right standard is ISO/IEC 20000-1, which an accredited body can certify and which aligns with ITIL practices. ITIL 4 certificates remain valid, and PeopleCert offers an optional route to Version 5 qualifications.

Timeline and cost considerations

ITIL is adopted progressively. Introducing structured incident and change practices in a small operations team can happen quickly; organisation-wide adoption with service catalogues, SLAs and reporting takes longer. Costs include publications and training (PeopleCert membership and exams), an ITSM tool, staff time for process design, and the time spent recording work. Over-engineered processes are the most common hidden cost.

Benefits and the risk of unmanaged services

ITIL practices reduce outage time, prevent repeat incidents, make changes safer, and give customers clear commitments and reports. They also provide much of the evidence that security and service audits look for.

There is no penalty for not using ITIL. Without structured service management, organisations see repeated incidents with unknown causes, risky unreviewed changes, unclear support commitments and difficult audits.

Common mistakes and challenges for IT companies

• Bureaucracy. A change advisory board for every small change slows delivery without reducing risk. Use standard changes and automation.
• Tool first, practice second. An ITSM tool does not create good practice by itself.
• No problem management. Incidents are closed but root causes are never fixed.
• Vague service levels that customers and engineers interpret differently.
• Treating ITIL and DevOps as opposites. ITIL 4 and Version 5 are designed to work with agile and DevOps.

Best practices, tools and technologies

• Integrate monitoring, alerting, on-call and ticketing so incidents are recorded automatically.
• Use CI/CD with automated tests as the control for standard changes; require extra approval only for high-risk changes.
• Publish a status page and incident communication templates.
• Run blameless post-incident reviews and track actions to completion.
• Measure a few things well: availability, incident counts by severity, mean time to restore, change failure rate.

Monitoring, incident handling and change control for client applications are part of our maintenance and support service.

How ITIL relates to other frameworks

Framework	Relationship
ISO/IEC 20000-1	The certifiable service management system standard; ITIL practices help meet its requirements.
COBIT	Governance framework; ITIL implements many of its management objectives.
ISO/IEC 27001	Security management; ITIL's information security management practice and change enablement support it.
ISO 22301	Business continuity management; aligned with ITIL service continuity management.
ISO 9001	Quality management; shares the focus on customers and continual improvement.

Real-world implementation examples

ITIL is used by governments and enterprises worldwide; many public sector tenders ask for ITIL-certified staff and ITIL-aligned processes for outsourced IT services. Large IT outsourcing firms build their delivery models and service reports around ITIL practices.

An illustrative case for a SaaS company: repeated outages after releases lead the team to adopt change enablement and problem management. Low-risk changes go through the automated pipeline as standard changes; database migrations and infrastructure changes need a second reviewer and a rollback plan; every major incident gets a review with tracked actions. The change failure rate drops, and the same records satisfy the change management controls in the company's SOC 2 audit.

Next steps

1. Map your current service management activities.
2. Choose three or four practices to improve first.
3. Integrate tools so records are created as work happens.
4. Agree and measure service levels.
5. Consider ISO/IEC 20000-1 if clients need certification.

Frequently asked questions

What is the latest version of ITIL?

ITIL Version 5, launched by PeopleCert in early 2026. It succeeds ITIL 4 (2019) and keeps the 34 management practices with a new grouping.

Can a company be ITIL certified?

No. ITIL certifications are for individuals. Organisations seeking certification for service management use ISO/IEC 20000-1.

Is ITIL mandatory?

No. It is voluntary best practice, though contracts and tenders often require ITIL-aligned processes or certified staff.

How many practices are in ITIL 4?

Thirty-four: 14 general management, 17 service management and 3 technical management practices.

What is the ITIL service value system?

The model showing how guiding principles, governance, the service value chain, practices and continual improvement work together to create value from demand.

What is the difference between ITIL and ISO 20000?

ITIL is guidance; ISO/IEC 20000-1 is a requirements standard that can be certified. ITIL practices are commonly used to meet ISO/IEC 20000-1.

Does ITIL work with DevOps and agile?

Yes. ITIL 4 and Version 5 were designed to work with agile and DevOps, for example through value streams and change enablement that supports automated deployments.

What is the difference between ITIL and COBIT?

COBIT is about governing and controlling enterprise IT; ITIL is about managing services. Organisations often use COBIT for governance and ITIL for service delivery.

Do ITIL 4 certificates still count?

Yes. ITIL 4 qualifications remain valid, and PeopleCert provides an optional route to Version 5 qualifications.

Which ITIL practices should a small SaaS team start with?

Incident management, change enablement, problem management and service level management usually give the most value first.

What is change enablement?

The ITIL 4 practice that maximises the number of successful changes by assessing risk, authorising changes and managing the schedule, while allowing low-risk changes to flow quickly.