ITIL 4 in practice: what is it, what does ITIL 5 change, and when does the framework make sense for a CTO?

Friday, 6:40 p.m. The payment system at a mid-sized fintech stops accepting transactions. The alert reaches three teams, and each assumes the problem sits with the others. Customers learn about the outage from a social media post; customer support learns from customers. Two hours later it turns out the cause was a configuration change deployed that afternoon by the infrastructure team. Nobody logged it, because “it was a small fix”.

On Monday the CTO faces two questions. The board asks why nobody knew who owned the outage. Compliance asks whether it met the criteria of a major ICT-related incident under the EU’s DORA regulation — because if so, the initial notification to the supervisor should have gone out within 4 hours of classifying it. The auditor adds a third: “Do you follow ITIL?”

The CTO remembers ITIL from a previous job: a change advisory board meeting on Tuesdays, a form for every change, weeks of waiting to approve a small fix. The team they lead now deploys a dozen times a day and cannot imagine going back. So the question is: is ITIL the cure for Friday’s chaos, or a return of bureaucracy?

The answer depends on which ITIL you mean. Below we explain what ITIL 4 is, what ITIL (Version 5), released in 2026, changes, which practices to adopt first, how to combine the framework with DevOps and SRE, and when ITIL makes sense and when it is overkill.

What is ITIL, and how does ITIL 4 differ from earlier versions?

ITIL is a body of good practice for IT service management (ITSM). It was created in the 1980s for the UK government agency CCTA, which wanted to bring order to how public administration used IT. The first publications appeared in 1989 and grew to about 30 books. Version 2 followed in 2001 and version 3 in May 2007, updated in 2011.

ITIL v3 was built around the service lifecycle — strategy, design, transition, operation and continual improvement — with 26 processes and functions. It is the version behind many CTOs’ associations, because many organisations implemented it literally, as a set of mandatory processes, forms and boards. We described that problem in our article on strategic ITSM and building IT department authority.

ITIL 4, published in February 2019, was the first major change since 2007. Three differences matter most:

• Practices instead of processes. ITIL 4 drops the service lifecycle and the 26 processes in favour of 34 practices. A practice is a set of organisational resources — people, information, technology, suppliers — designed to achieve an objective. It prescribes neither a sequence of steps nor an organisational structure.
• Value instead of compliance. The starting point is what value a service creates for the customer, not whether a process runs as described.
• Openness to Agile, Lean and DevOps. ITIL 4 explicitly incorporates modern ways of working, and one of its advanced modules, High Velocity IT, is aimed at organisations that deliver changes quickly and often.

Ownership of ITIL has changed too. In 2013 the UK government and Capita set up AXELOS to manage ITIL and PRINCE2. In July 2021 AXELOS was acquired by PeopleCert, which now develops the framework and runs certification.

What does ITIL (Version 5), released in 2026, change, and does ITIL 4 still make sense?

In early 2026 PeopleCert began rolling out ITIL (Version 5). The Foundation exam in the new version came first, in February 2026, with advanced modules released in stages later in the year.

According to PeopleCert, the new version responds to three shifts:

• Organisations manage digital products, not just services. ITIL 5 combines digital product and service management into one lifecycle — from design through build and operation to improvement.
• AI is changing how work is done. The new version is described as “AI-native”: it includes guidance for working in an environment where AI systems perform part of the work, and for managing the risks of using them.
• The qualification scheme had become too complex. ITIL 5 simplifies the certification path: Foundation remains the entry point, and advanced modules are tied to roles.

For a CTO, what matters most is what stays the same. The seven guiding principles are unchanged, and the structure of 34 practices is retained, although some are grouped differently — for example as product and service management practices. PeopleCert states that ITIL 5 is backward compatible: ITIL 4 knowledge and certifications keep their value, and ITIL 4 remains available to those continuing their certification path.

So does ITIL 4 still make sense in 2026? Yes, with one caveat. Practices you implement according to ITIL 4 will not become outdated — incidents, changes and problems are handled on the same principles in both versions. If you are only now planning to certify your team, check which ITIL 5 modules are already available in the language and format you need. The rest of this article describes ITIL 4, because most implementations, tools and materials are still based on it, and notes where ITIL 5 differs.

What does ITIL 4 consist of: the service value system, value chain and four dimensions?

ITIL 4 has two main components: the four dimensions model and the service value system. Both sound abstract, but in practice they work as a checklist that protects against the most common mistakes when changing IT.

The four dimensions of service management are areas to consider for every service and every change:

1. Organisations and people — structure, roles, skills, culture.
2. Information and technology — data, knowledge, tools and systems.
3. Partners and suppliers — relationships with external companies, from a cloud provider to a staff augmentation team.
4. Value streams and processes — how work flows through the organisation.

The fintech example shows why this matters. The company had good technology (dimension 2) but no clearly assigned roles during an incident (dimension 1) and no agreed flow of information about changes (dimension 4). Buying a new monitoring tool would not have solved the problem — one of the most common mistakes when fixing IT.

The service value system (SVS) describes how all parts of an organisation work together to create value. It has five parts: guiding principles, governance, the service value chain, practices and continual improvement.

At the centre of the SVS is the service value chain — six activities that make up all IT work: plan, improve, engage (with stakeholders), design and transition, obtain or build, and deliver and support. It is not a sequence of steps. Different scenarios — handling an incident, shipping a new feature, onboarding an employee — combine these activities in different orders, forming value streams.

In practice, instead of asking “what is our change process?”, you ask “what does the value stream look like from a business request to a working feature in production, and where do we lose time?” That question is much closer to DevOps thinking than to ITIL v3.

What are ITIL 4’s guiding principles, and how do you apply them day to day?

The seven guiding principles are the most practical part of ITIL 4 — and the part ITIL 5 took over unchanged. You can apply them regardless of whether you implement any practice.

1. Focus on value. Every activity should lead to value for the customer or the organisation. An SLA report nobody reads creates no value — replace it with one indicator someone acts on.
2. Start where you are. Before building something new, check what already works. Most companies have informal incident handling — a chat channel, an on-call rota. The starting point is to tidy it up, not replace it.
3. Progress iteratively with feedback. Introduce practices in small steps and measure the effect. Do not spend six months designing the whole of ITSM before the first rollout.
4. Collaborate and promote visibility. Work that cannot be seen cannot be improved. A shared board of changes and incidents often achieves more than a new process.
5. Think and work holistically. A service is the sum of all four dimensions. Optimising one team at the expense of others does not improve the service.
6. Keep it simple and practical. If a process step creates no value, remove it. This principle most clearly separates ITIL 4 from bureaucratic v3 implementations.
7. Optimise and automate. Simplify first, then automate. Automating a bad process only produces errors faster.

For a CTO, principles 2, 6 and 7 are the most useful. Together they form a simple rule: start with what the team already does, remove unnecessary steps, and only then automate. Many failed ITIL implementations did exactly the opposite — bought an ITSM tool, configured textbook processes in it and told teams to adapt.

Which of ITIL 4’s 34 practices are really worth adopting first?

ITIL 4 describes 34 practices in three groups: 14 general management practices (including strategy, risk, supplier and information security management, and continual improvement), 17 service management practices (including incident management, problem management, change enablement, service desk and service level management) and 3 technical management practices (deployment management, infrastructure and platform management, and software development and management).

Nobody implements all 34 at once, and ITIL 4 does not expect it. Our experience with IT departments is that five practices solve most of the problems visible to the board and to customers. Here is each one in a minimum version that works for a team of a few dozen engineers:

Practice	Problem it solves	Minimum version
Incident management	Nobody knows who is running the outage	Severity classification (e.g. 4 levels), an incident lead role, one communication channel, a customer message template
Change enablement (formerly change management)	Changes deployed without others knowing	A change log fed automatically from the pipeline; standard, normal and emergency categories; a board only for high-risk changes
Problem management	The same outages keep coming back	A blameless post-incident review for every major incident, a list of actions with owners and deadlines
Monitoring and event management	Customers report the outage first	Alerts tied to services rather than servers; thresholds agreed with service owners
Service level management	No shared definition of “working”	2–3 indicators per key service (availability, response time), agreed with the business and visible to all

These five practices form a loop: monitoring detects an event, incident management restores the service, problem management removes the cause, change enablement introduces the fix safely, and service level management tells you whether the result is good enough. We covered the first in our glossary entry on incident management and in our article on incident response in 2026.

Note the change of name: ITIL 4 speaks of change enablement, not change management. It is not cosmetic. The aim of the practice is to maximise the number of successful changes, not to control them. See our glossary entry on change management.

Further practices are added when a specific need arises. Knowledge management — when the number of teams and turnover grow. Supplier management — when a significant share of work goes to external partners. IT asset management — when licence and cloud costs get out of control. The last connects directly to Software Asset Management, in which ARDURA Consulting has supported clients for years.

How do you combine ITIL 4 with DevOps, agile and SRE?

The conflict between ITIL and DevOps was real in the days of literally implemented ITIL v3. In ITIL 4 it is largely illusory, because the two answer different questions.

ITIL answers “what” — which practices an organisation needs for services to run reliably: incident, change, problem and service level handling. DevOps and SRE answer “how” — how to perform those practices quickly, automatically and with few hand-offs between teams.

In practice, the combination looks like this:

• Change enablement through the pipeline. A change that passes automated tests and security scans and is deployed through a repeatable pipeline with fast rollback meets ITIL 4’s definition of a standard change — pre-approved, with no board. The change log is fed automatically from the CI/CD system. The board deals only with non-standard, high-risk changes.
• Error budgets instead of arbitrary SLAs. Site Reliability Engineering defines reliability targets (SLOs) and error budgets. That is a concrete implementation of service level management: when the budget runs out, the team shifts priorities from new features to stability.
• Blameless post-incident reviews. This is problem management in the form DevOps culture promotes — focused on learning, not punishment.
• DORA metrics as a measure of practices. The four key metrics from DevOps Research and Assessment — deployment frequency, lead time for changes, change failure rate and time to restore service — measure exactly the practices ITIL describes. We wrote about this in our article on the business value of DevOps and DORA metrics. Beware the shared name: DORA metrics have nothing to do with the EU’s DORA regulation, covered below.

The combination only works with the right culture. ITIL practices introduced in an organisation where teams are afraid to report problems turn into compliance theatre. We described the leader’s role in that shift in our article on building a DevOps culture.

When does ITIL make sense, and when is it overkill?

ITIL is neither mandatory nor universal. It pays off when the cost of chaos exceeds the cost of order. In our experience, several signals show a company has crossed that threshold:

• IT serves many users or external customers, and downtime has a measurable cost — lost transactions, contractual penalties, customer churn.
• Several teams share infrastructure, and one team’s changes affect others’ services.
• The same outages repeat, because nobody is responsible for removing the cause.
• A significant share of work is done by external partners, and responsibilities must be clear.
• The company is subject to regulations requiring documented management of ICT incidents, changes and risk.
• Enterprise customers require ISO/IEC 20000-1 certification or ask about ITSM processes in security questionnaires.

On the other hand, ITIL is overkill when:

• A product team of a dozen or so people develops a single system — an on-call rota, an incident channel and post-incident reviews are enough.
• The company is at an early stage, searching for product-market fit and changing direction every quarter.
• The goal is a certificate, not a problem. Implementing ITIL “because the auditor will ask” ends in documentation nobody uses.

ITIL is not the only option. ISO/IEC 20000-1 (2018 edition) sets requirements for a service management system and can be certified — ITIL is one way of meeting it. SIAM (Service Integration and Management) focuses on coordinating multiple suppliers. VeriSM proposes a service management approach for the whole organisation, not just IT. ITIL 4 draws on all of them, and in practice elements of several are often combined.

How do DORA and NIS2 change ITIL’s role in 2026?

For years, ITIL was a choice. For some companies in the EU it no longer is — not because regulations require ITIL by name, but because they require the practices ITIL describes.

The DORA regulation (Digital Operational Resilience Act) has applied since 17 January 2025 to financial sector entities: banks, insurers, investment firms, payment institutions and their critical ICT providers. It requires, among other things, an ICT risk management framework, incident classification and reporting of major incidents in three stages: an initial notification within 4 hours of classifying the incident as major, but no later than 24 hours after becoming aware of it, an intermediate report within 72 hours and a final report within one month.

The NIS2 directive was transposed in Poland by an amendment to the National Cybersecurity System Act, which took effect in early April 2026. It covers a much wider range of entities than earlier rules — from energy and transport to digital service providers and manufacturers. Major incidents are reported in three stages: an early warning within 24 hours, a full notification within 72 hours and a final report within one month. Companies have a transition period to meet the new requirements.

To meet a 4-hour deadline, an organisation must know, within tens of minutes of detecting a problem, who is running the incident, how to assess its severity and who decides on notification. That is exactly the scope of incident management. The final report requires root cause analysis — problem management. Control of changes to ICT systems — change enablement. Oversight of ICT suppliers — supplier management.

For a CTO in the financial sector or at an entity covered by NIS2, the question is not “should we adopt ITIL” but “how quickly can we document and rehearse practices that are already mandatory”. ITIL 4 provides a ready vocabulary and structure that auditors and supervisors understand. This article is not legal advice — the scope of obligations depends on how a specific entity is classified and should be confirmed with compliance.

How do you implement ITIL 4 step by step without bureaucracy?

Implementing ITIL is not a project with an end date. It is a series of small improvements, each of which should show an effect within a few weeks. The sequence below works for organisations starting from informal IT operations.

Step 1. Name your services. List the services IT provides to the business and customers — not systems, but services: “online payments”, “order handling”, “company email”. Give each an owner and a criticality. Without this, incident priorities cannot be set.

Step 2. Sort out incidents. Introduce severity classification, an incident lead role and one communication channel. Rehearse a major outage scenario with the board and communications. If you are subject to DORA or NIS2, include the notification decision path in the exercise.

Step 3. Make changes visible. A change log fed automatically from the CI/CD pipeline and a change calendar visible to all teams. Define which changes are standard (pre-approved) and which need review.

Step 4. Close the problem loop. After every major incident, a blameless review and a list of actions with owners. Once a month, a check on which actions were completed.

Step 5. Set service levels. For key services, 2–3 indicators agreed with the business. Measure them automatically and show them openly across the organisation.

Step 6. Choose a tool. Only now — once you know how you want to work. An ITSM tool should support your way of working, not define it.

Step 7. Improve continually. Every quarter, a review: which practices work, where time is lost, what to simplify. This is continual improvement, which in ITIL 4 is part of the service value system rather than a separate project.

For a team of a few dozen engineers, steps 1–5 usually take two to four months with part of one coordinator’s time. The key is that the team sees an effect after each step — less chaos during outages, fewer surprises after deployments.

Which mistakes most often turn ITIL into bureaucracy?

ITIL’s bad reputation among engineers comes not from the framework’s content but from how it is implemented. Six mistakes recur most often:

1. Implementing every practice at once. An “ITIL rollout” covering a dozen practices takes a year, and teams see only new forms. Better one practice a month than ten a year.
2. A change board for everything. A board approving every change slows delivery without reducing risk — its members cannot assess hundreds of changes a week. Standard changes should bypass it.
3. Tool before practice. Configuring an ITSM tool with the vendor’s default processes instead of the organisation’s needs.
4. Measuring activity instead of outcomes. The number of closed tickets or the share closed within SLA says little about whether the service works well. Teams quickly learn to optimise the indicator, not the service.
5. ITIL as an operations project. Practices introduced by operations without development teams build a wall between “builders” and “maintainers” — exactly what DevOps was meant to tear down.
6. Certificates instead of change. Sending the whole team on a Foundation course changes nothing if nothing changes in the organisation afterwards.

Each of these breaks one of ITIL 4’s guiding principles — most often “keep it simple and practical” and “focus on value”. That is a good test for any proposed change: does it create value, or only compliance?

Which ITIL certifications should you choose, and is it worth certifying your team?

The ITIL 4 certification scheme has an entry level and two main advanced paths:

• ITIL 4 Foundation — core concepts, principles and practices. The entry point for all further modules.
• ITIL 4 Managing Professional (MP) — four modules: Create, Deliver and Support (CDS), Drive Stakeholder Value (DSV), High Velocity IT (HVIT), and Direct, Plan and Improve (DPI). For people responsible for running services and teams.
• ITIL 4 Strategic Leader (SL) — two modules: Direct, Plan and Improve (DPI) and Digital and IT Strategy (DITS). For IT leaders responsible for strategy.
• Extension modules — including sustainability in digital and IT and managing cloud services.

In ITIL (Version 5), Foundation remains the entry point, and advanced modules are grouped by role and area — including experience, product and service. PeopleCert states that ITIL 4 certificate holders keep their value and have transition paths to the new version. We do not quote exam prices, as they depend on the accredited training organisation, format (course with exam or exam only) and country.

Is it worth certifying your team? Our recommendation varies:

• Foundation for team leads and incident leads — yes. A shared vocabulary shortens discussions and eases conversations with auditors, suppliers and customers.
• Foundation for every engineer — usually not. Invest in incident exercises and post-incident reviews instead.
• Advanced modules (e.g. HVIT, DPI) — for people designing how IT works, and in regulated organisations where ITSM competence must be demonstrated.
• Certification as a supplier requirement — makes sense when an external partner takes over some practices, such as service desk or maintenance. When augmenting your team with DevOps engineers, hands-on incident experience matters more than the certificate itself.

How do you apply ITIL 4 when external partners do part of your IT work?

Few IT departments in 2026 rely solely on their own staff. Public cloud, SaaS vendors, maintenance providers, teams augmented with external specialists — each of these partners takes part in service value streams. An outage at a supplier becomes your incident, and a change deployed by a partner becomes your change.

ITIL 4 addresses this on two levels. The partners and suppliers dimension reminds you that every service depends on external relationships, which must be considered when designing it. The supplier management practice describes how to run those relationships: from choosing a partner, through the contract and shared indicators, to regular reviews.

In practice, what matters most is that ITSM practices include partners rather than stopping at the organisation’s boundary:

• A shared incident procedure. The supplier knows how to report an incident, who the incident lead is on your side and how quickly it must respond. Under DORA or NIS2, that time must fit your own notification deadlines.
• Partners’ changes in your change log. A change to a system maintained by a supplier appears in the same calendar as your teams’ changes.
• Post-incident reviews with the supplier. A cause on the partner’s side requires corrective actions on its side — with an owner and a deadline.
• Service indicators, not component availability. A supplier meeting the SLA for its component while the end-to-end service is down has fulfilled the contract formally but delivered no value.

It works differently when you augment a team with external specialists. In staff augmentation, the partner’s engineers work in your teams, in your tools and according to your practices. The supplier is responsible for selection and continuity of staffing, not for the service. That is why new team members should know your incident procedure and change rules from their first week — as part of onboarding, not a separate project.

When the number of partners grows to several or more and end-to-end services depend on many of them at once, consider SIAM, which describes the role of a service integrator coordinating multiple suppliers. For most mid-sized companies, however, a well-run supplier management practice and including suppliers in the incident and change loop is enough.

How do you assess the maturity of IT service management in your company?

Instead of asking “do we have ITIL?”, assess the maturity level of the key practices. The model below helps set a starting point and the next step. The levels are simplified and do not correspond to PeopleCert’s formal assessment model — they are meant for a conversation within the leadership team.

Area	1. Reactive	2. Repeatable	3. Defined	4. Measured	5. Optimised
Incidents	Customers report outages	On-call rota and incident channel	Severity classification, incident lead, communication templates	Time to detect and restore measured per service	Failure exercises, automated detection and partial self-healing
Changes	Changes deployed without a trace	Manual change log	Change categories, standard changes via pipeline	Change failure rate and lead time measured	Most changes standard, board only for high risk
Problems	The same outages return	Root cause analysis after big outages	Blameless reviews for every major incident	Tracking of corrective actions	Proactive problem detection from trends
Service levels	No definition of “working”	Contractual SLAs without measurement	Indicators for key services	Automated measurement visible to the business	SLOs and error budgets drive priorities
Regulation (DORA/NIS2)	No awareness of obligations	Obligations known, no procedures	Notification and classification procedure	Exercises involving the board	Notifications generated from incident system data
Suppliers	No clear split of responsibility	Contracts with SLAs	Shared incident procedures with suppliers	Supplier performance reviews	Integrated multi-supplier management (SIAM)

Most companies we work with are at level 2 in most areas. For organisations covered by DORA or NIS2, the realistic minimum is level 3 in incidents, changes and regulation.

The key takeaways:

1. ITIL 4 is not ITIL v3. Practices instead of processes, value instead of compliance, openness to DevOps. Bad associations with ITIL mostly come from literal implementations of version 3.
2. ITIL 5 does not invalidate ITIL 4. The guiding principles are unchanged, the practices are retained, and according to PeopleCert ITIL 4 certificates keep their value.
3. Start with five practices. Incidents, changes, problems, monitoring and service levels solve most problems visible to the board and customers.
4. ITIL says “what”, DevOps and SRE say “how”. A change through a tested pipeline can be a standard change with no board.
5. DORA and NIS2 turn ITIL from a choice into a necessity for some companies — not by name, but by the scope of required practices.
6. Measure outcomes, not activity. Time to restore service and change failure rate say more than the number of closed tickets.

At ARDURA Consulting we have been supporting client IT departments in Poland, Europe, the Middle East and the USA for more than ten years — augmenting teams with DevOps and SRE engineers, building software with its later operation in mind and bringing order to IT asset management. We see that the ITSM implementations that work best start from one painful problem, not from the manual.

If you want to assess the maturity of ITSM practices in your organisation, or need engineers who bring experience in incident handling and change automation, talk to our team.