History of ITIL: How the Framework Evolved from ITIL v1 to Version 5

The history of ITIL is often told as a sequence of editions: ITIL v1, v2, v3, the 2011 update, ITIL 4, and now ITIL Version 5. That chronology is useful, but it misses the more important development. ITIL’s history is not a sequence of replacements; it is a widening of the management object.

ITIL began as guidance for making government IT operations more consistent, reliable, and economical. It then organized operational work into connected processes, placed those processes inside a service lifecycle, reframed the organization as a service value system, and finally extended explicit lifecycle accountability across digital products, services, experiences, transformation, and AI-enabled capabilities.

It is not that every new edition invalidated the last. Earlier disciplines became parts of a broader management system. Incident, problem, change, configuration, service-level, continuity, supplier, and improvement capabilities still matter. What changed was the scope of the outcome leaders were expected to govern.

Answer in brief: ITIL evolved from a late-1980s library of operational guidance into a process-oriented IT service management framework, then into a service lifecycle, a flexible service value system, and an integrated digital product-and-service lifecycle. Each major edition widened what organizations had to coordinate while preserving useful capabilities from earlier versions. [1][3][4][5]

The History of ITIL at a Glance

The timeline shows how each major ITIL edition widened the principal object of management while retaining valuable disciplines from earlier versions.

The visual establishes the historical progression; the table below explains the management problem, contribution, common misapplication, and enduring value associated with each edition.

The dates mark the editions. The management objects explain why the editions mattered.

What is ITIL?

ITIL is adaptable best-practice guidance for managing technology-enabled products and services so they create value reliably across strategy, design, delivery, support, governance, and continual improvement. It gives organizations shared concepts, practices, principles, and operating structures for connecting day-to-day service management with business outcomes.

The name originally expanded to Information Technology Infrastructure Library, reflecting its beginnings as a collection of publications. As the framework broadened, ITIL increasingly functioned as its name rather than a literal description of its boundaries. Version 5 addresses products, services, experience, transformation, strategy, and AI-enabled operating conditions – a scope far wider than infrastructure management alone.

This article owns the historical evolution of ITIL from v1 to Version 5. It does not attempt to provide a full implementation method, certification pathway, practice-by-practice reference, or migration plan. Those are separate decisions. The history is valuable here because it reveals which operating assumptions each edition was designed to correct.

Why ITIL Kept Changing

A management framework changes when its organizing assumptions stop explaining the work around it.

The original ITIL problem was operational inconsistency. Different departments procured, supported, and controlled technology in different ways. Service quality varied, responsibilities were difficult to compare, and costs were hard to govern. Reusable guidance could reduce avoidable variation.

Once recurring activities were more clearly defined, the next problem was integration. A service desk could handle incidents well while change, configuration, capacity, availability, continuity, and service-level work remained disconnected. ITIL v2 made the process system easier to understand and operate.

Process maturity then exposed a larger gap. Well-run processes did not necessarily produce a well-conceived or well-governed service. Leaders also had to decide which services should exist, how they should be designed and transitioned, how risk should be controlled before operation, and how improvement should continue across the service’s life. ITIL v3 supplied that lifecycle frame.

The lifecycle frame eventually met a faster and less linear delivery environment. Agile teams, DevOps, cloud services, product operating models, automation, and continuous delivery did not move neatly through one sequence of stages. ITIL 4 therefore emphasized guiding principles, practices, value streams, and the Service Value System.

Version 5 responds to another expansion. Technology management is now distributed across business functions, product teams, platform teams, suppliers, cloud ecosystems, data organizations, risk functions, and AI initiatives. Digital products depend on ongoing services; services are experienced through digital products; and changes in one area can create enterprise consequences elsewhere. The framework therefore makes integrated product-and-service lifecycle accountability more explicit.

CIO Index summarizes this movement through the ITIL Management Object Ladder:

1. Operational work: Are essential support and control activities performed consistently?
2. Processes: Do related activities operate as connected, repeatable management systems?
3. Service lifecycle: Is a service governed from strategic conception through continual improvement?
4. Value system: Do governance, practices, value streams, people, partners, information, and technology work together to co-create value?
5. Integrated digital lifecycle: Are products, services, experiences, transformation, and AI governed end to end across organizational boundaries?

The ladder is a CIO Index analytical model, not an official ITIL maturity model. It provides the throughline for the history that follows: each edition made a wider object governable, but none removed the need to manage the layers beneath it.

ITIL v1: Making Operational Service Work Repeatable

The Problem ITIL V1 Addressed

ITIL emerged from work initiated by the United Kingdom’s Central Computer and Telecommunications Agency, commonly known as the CCTA, during the 1980s. Historical sources describe the effort as a response to inconsistent service quality and excessive cost in government IT. The aim was to identify practices that could improve the effective and efficient provision of technology services across departments. [1][2]

The first publications appeared around the end of the 1980s; 1989 is commonly cited as the release point. The original library eventually grew to more than 30 volumes. [1][9] It covered help desk work, change control, contingency planning, infrastructure, service levels, availability, cost, customer relationships, and other operational and management concerns.

The scale of the library reflected the scale of the problem. Early enterprise computing environments were technically complex, organizationally fragmented, and often managed as collections of hardware, software, and specialist teams. ITIL introduced a crucial change in perspective: technology should be managed as a service to a customer, with defined responsibilities and agreed expectations.

What v1 Changed

ITIL v1 did not offer one elegant operating architecture. Its contribution was more foundational: it made recurring service work visible, nameable, and reusable.

Once incident handling, change control, contingency planning, capacity, configuration, and service-level responsibilities had recognizable forms, managers could document them, train people, compare performance, assign ownership, and improve them. The first rung of the Management Object Ladder was therefore operational work.

This was a major advance over purely component-centered management. But operational practices could still be selected and applied separately. The library gave organizations knowledge without always giving them a coherent management system.

The Unresolved Limitation

More than 30 publications were difficult to absorb, prioritize, and apply as one system. Organizations could improve individual activities without understanding their dependencies or handoffs. The next question was no longer simply, “Do we know how to perform this work?” It was, “Do these activities operate as connected processes?”

That question produced ITIL v2.

ITIL v2: Turning Guidance into a Process System

ITIL v2 was released around 2000-2001. It consolidated the large body of v1 guidance into nine publications. Two books – Service Support and Service Delivery – became the best-known core of the framework. [1]

Service Support concentrated on the operational processes needed to keep services functioning and respond to disruption. Service Delivery concentrated on the management commitments needed to provide services at agreed levels over time. Together, they gave practitioners a more accessible view of how core IT service management processes related to one another.

The Management Shift in v2

The important change was not merely that fewer books were easier to read. ITIL v2 made the process the dominant management object.

An incident was no longer just a ticket handled by a technician. Incident management became a defined process with a purpose, roles, activities, interfaces, measures, and expected outcomes. Change was not simply technical work scheduled by engineers. Change management became a control process connecting risk, authorization, coordination, and implementation. Service-level management linked provider performance with agreed customer expectations.

This process orientation helped professionalize IT service management. It enabled organizations to create process owners, establish common workflows, configure service-management tools, measure handoffs and performance, train practitioners in a shared vocabulary, and define operational controls across teams and suppliers.

ITIL v2 spread as enterprise applications, distributed infrastructure, outsourcing, service desks, and formal service-level agreements made operational interdependence more visible. For many practitioners, ITIL became synonymous with this process set.

The Unresolved Limitation

A mature set of service support and delivery processes could improve control without answering larger questions:

• Which services should exist?
• What customer and business outcomes should they support?
• How should investment, demand, architecture, suppliers, risk, capacity, and continuity be considered before operation?
• How should new or changed services be designed and transitioned?
• How should improvement occur across the service’s life rather than inside individual processes?

Process compliance could therefore become a substitute for service judgment. Organizations might optimize incident, change, or configuration metrics while no one owned the complete service outcome.

ITIL v2 made processes governable. The next question was whether the service itself was being governed end to end.

ITIL v3 and ITIL 2011: Governing the Service Lifecycle

ITIL v3 was released in 2007. It reorganized the framework around five lifecycle publications: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement. [2][3]

The processes familiar from v2 did not disappear. They were placed inside a broader model that asked how a service should be conceived, designed, introduced, operated, and improved.

The Five Lifecycle Stages

Service Strategy addressed choices about which services should be offered, to whom, under what value proposition, with what demand, funding, and provider model.

Service Design translated strategic intent into a design that considered architecture, technology, processes, suppliers, capacity, availability, continuity, security, and service levels.

Service Transition addressed how new and changed services should be built, tested, evaluated, released, deployed, and transferred into operation with controlled risk.

Service Operation covered the work required to deliver and support live services, including event, incident, request, problem, access, and operational control activities.

Continual Service Improvement connected measurement, review, and improvement across the lifecycle rather than treating improvement as an occasional project.

The Management Shift in v3

ITIL v3 changed the organizing question from “Are our processes defined?” to “Are we governing the service across its life?”

A service could fail before entering operation because demand was misunderstood, architecture was weak, supportability was not designed, suppliers were poorly integrated, transition risk was ignored, or measures were disconnected from business outcomes. Lifecycle thinking made these upstream and downstream dependencies visible.

This was the third rung of the Management Object Ladder: the service lifecycle. Process owners still mattered, but their work had to contribute to an end-to-end service outcome. The lifecycle also strengthened the relationship between IT service management and business strategy. A service was not merely an operational output; it was a means through which customers achieved outcomes.

Where Lifecycle Thinking Helped – and Where It was Misused

Used well, v3 encouraged cross-functional ownership. Service owners could consider strategic, design, transition, operational, and improvement obligations together. Process owners could see how their work supported a larger lifecycle.

Used mechanically, the same model could become a sequence of gates, documents, and committees. Some organizations treated the five books as a prescribed waterfall through which every change had to pass. The result was bureaucracy, not better lifecycle governance.

The problem was not lifecycle thinking. It was the assumption that a lifecycle diagram had to become a linear delivery method. As technology work became more iterative, product-oriented, cloud-based, and continuously delivered, the framework needed to preserve lifecycle responsibility without forcing a rigid sequence.

ITIL 2011: Refinement, Not a New Architecture

The core v3 publications were updated in 2011. The update incorporated user and training-community feedback, clarified concepts, corrected inconsistencies, and improved alignment across the five books. Historical references characterize ITIL 2011 as an update rather than a new numbered version. [10][11]

The dominant management object did not change. The service lifecycle remained central. ITIL 2011 made that model more internally consistent and usable.

Its place in the history is instructive: not every release represents a conceptual revolution. Framework stewardship also requires correction, clarification, and consolidation. The next major change came when the environment challenged the lifecycle as the framework’s primary visible architecture.

ITIL 4: From Service Lifecycle to Service Value System

ITIL 4 was introduced in 2019. [3] Its central architecture became the Service Value System, or SVS. The SVS connected guiding principles, governance, the service value chain, management practices, and continual improvement. Four dimensions – organizations and people, information and technology, partners and suppliers, and value streams and processes – encouraged leaders to consider the whole system through which value is created. [5]

Why ITIL 4 was Needed

By the late 2010s, many technology organizations were using Agile development, DevOps, Lean, cloud platforms, automation, product teams, and continuous delivery. Work moved through networks of teams and suppliers rather than one centralized pipeline. Services evolved continuously instead of progressing once through a fixed lifecycle.

A framework centered too visibly on lifecycle stages could be interpreted as sequential and prescriptive. ITIL 4 shifted attention toward value streams: combinations of activities and practices used to respond to demand or opportunity and create value.

Processes Became Part of Broader Practices

ITIL 4’s management practices broadened the process concept. A practice includes not only a flow of activities but also the people, competencies, information, technology, partners, policies, and other resources required to perform work effectively.

This did not make process discipline obsolete. It recognized that a documented workflow cannot succeed when roles, skills, tools, data, suppliers, governance, and incentives work against it. ITIL v2’s operational lessons remained necessary, but they were nested inside a more holistic view of organizational capability.

Value Co-creation and Adaptable Principles

ITIL 4 emphasized value co-creation rather than value delivered unilaterally by a provider. Customers, users, sponsors, suppliers, and service providers all influence outcomes. Its guiding principles encouraged organizations to focus on value, start where they are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically, keep it simple and practical, and optimize and automate.

These principles made adaptation explicit. They challenged the idea that “implementing ITIL” meant reproducing a universal process model.

The Management Shift in ITIL 4

ITIL 4’s dominant object was the system of value creation.

That system could contain multiple value streams, practices, products, services, partners, technologies, governance mechanisms, and improvement loops. The service lifecycle did not become meaningless, but it was no longer the framework’s primary visible structure.

This was the fourth rung of the Management Object Ladder: the value system. The shift solved an important problem of rigidity, but it created a new practical question. In a flexible network of value streams and product teams, how should explicit end-to-end lifecycle accountability for products and services remain visible?

That question became more urgent as cloud, digital ecosystems, distributed ownership, and AI spread technology management across the enterprise.

ITIL Version 5: Integrating Products, Services, Experience, Transformation, and AI

ITIL Version 5 emerged in 2026. Official guidance describes it as an evolution of ITIL 4, not a reset. The guiding principles and Service Value System continue, while the framework becomes more explicit about digital products and services, experience, transformation, strategy, and AI-enabled operating conditions. [4][5]

Why Version 5 Appeared

Official rationale points to the enterprise-wide effects of cloud and AI. Technology decisions are increasingly distributed across business functions, product teams, platform teams, vendors, and external ecosystems. A capability that works locally can create integration, data, reporting, security, support, resilience, or customer-experience problems elsewhere. [6][12]

The boundary between product and service management has also weakened. A digital product depends on ongoing services such as cloud hosting, identity, data pipelines, cybersecurity, observability, support, suppliers, and continual enhancement. A service is often experienced through a product interface. Treating products and services as separate management worlds creates gaps in ownership.

AI adds another layer. Models and automated agents can alter how work is performed, decisions are made, risks are introduced, users experience services, and outcomes are measured. Responsible use therefore requires governance, transparency, controls, human accountability, data discipline, and continual monitoring – not only technical implementation.

The Eight-Stage Product and Service Lifecycle Model

Version 5 introduces an explicit eight-stage Product and Service Lifecycle Model: [5]

1. Discover
2. Design
3. Acquire
4. Build
5. Transition
6. Operate
7. Deliver
8. Support

The lifecycle provides a practical view of how work applies across products and services, while the Service Value System retains the broader organizational context.

This combination is historically significant. Version 5 is not a return to v3. It reintegrates explicit lifecycle accountability within the value-system architecture inherited from ITIL 4. The lifecycle is more visible, but it sits inside an adaptable system rather than replacing it.

Continuity in The Practices

PeopleCert states that the 34 management practices remain largely the same, with adjustments and a new organization into two groups: product and service management practices, and general management practices. [13]

That continuity reinforces the historical pattern. Version 5 does not ask practitioners to forget incident management, problem management, change enablement, service configuration management, service-level management, continual improvement, or the wider ITIL 4 practice set. It asks organizations to use those capabilities inside a broader product, service, experience, transformation, and AI context.

The Management Shift in Version 5

The dominant object becomes the integrated digital product-service-experience lifecycle.

A CIO is no longer governing only live-service reliability or ITSM process efficiency. The leadership task includes strategic alignment, product decisions, service performance, user and customer experience, transformation capacity, supplier ecosystems, AI use, data and technology architecture, operational resilience, and measurable value across the lifecycle.

This is the fifth rung of the Management Object Ladder. It does not erase the lower rungs. It makes their limitations more visible when they are treated as the whole operating model.

Who Has Stewarded ITIL?

ITIL’s institutional history influenced how the framework was developed, published, accredited, and commercialized.

The CCTA initiated the original work and later became part of the Office of Government Commerce. Responsibility subsequently moved within the UK government, including the Cabinet Office. In 2013, the Cabinet Office announced a joint venture with Capita to own and develop the Best Management Practice portfolio, including ITIL. That venture became AXELOS. [8]

AXELOS oversaw the transition from the v3/2011 era to ITIL 4. In July 2021, PeopleCert completed its acquisition of AXELOS and became the custodian of ITIL and other portfolio frameworks. [7]

These ownership changes belong in the timeline, but they are not the intellectual explanation of ITIL’s evolution. The framework changed as technology delivery, organizational structures, sourcing, customer expectations, and management practices changed. Stewardship determined how those responses were developed and distributed.

What Changed – and What Did Not

The history now supports a more useful synthesis than a list of version features.

What Changed: The Scope of Coordination

Each major edition widened the relationships that had to be managed.

ITIL v1 coordinated recurring operational work and responsibilities. V2 coordinated processes and handoffs. V3 coordinated processes and decisions around the lifecycle of a service. ITIL 4 coordinated practices and value streams within a Service Value System. Version 5 connects products, services, experience, transformation, technology, and AI across an integrated lifecycle.

As the management object widened, the dominant leadership risk changed. Early ITIL addressed inconsistency. V2 addressed fragmented processes. V3 addressed lifecycle blindness. ITIL 4 addressed rigidity and weak value orientation. Version 5 addresses distributed digital accountability.

What Did Not Change: Disciplined Management Remains Necessary

The vocabulary changed, but organizations still need to define ownership, control risk, restore service, learn from failure, manage demand, coordinate change, govern suppliers, measure performance, and improve continually.

An organization cannot leap to enterprise digital product management while neglecting incident response, configuration knowledge, service continuity, change risk, or supplier accountability. Modern product and AI language cannot compensate for weak operational capability.

The reverse is also true. Excellent incident and change processes cannot compensate for fragmented product ownership, unclear customer outcomes, weak architecture, poor experience, or local technology decisions that create enterprise risk.

Later ITIL editions are therefore best understood as broader containers for earlier capabilities, not wholesale replacements. The historical question is not which version to preserve. It is whether the organization’s management scope has expanded as far as the digital outcome it claims to own.

Apply the ITIL Management Object Ladder

The history becomes practical when leaders use it to diagnose the dominant unit of accountability in their operating model. The following discussion aid is a CIO Index interpretation, not an official ITIL assessment.

The visual provides the complete diagnostic at a glance. The table below preserves the detailed evidence, strengths, blind spots, and governance implications for each level.

The ladder is not a ranking in which every organization should maximize every layer. Different services, products, and risks may require different levels of governance. Its value is diagnostic: it exposes when the stated ambition and the actual management object do not match.

One Enterprise, Two Historical Strengths – and One Accountability Gap

Consider an enterprise with a respected service desk, disciplined change controls, stable infrastructure operations, mature incident and problem processes, autonomous product teams, continuous deployment, cloud-native platforms, and strong product analytics.

On paper, the organization combines the strengths of several ITIL eras. V2-style process discipline keeps operations controlled. ITIL 4-style value streams and product practices support rapid delivery. Dashboards show improving resolution times, frequent releases, and strong feature adoption.

Yet the customer portal, mobile application, identity platform, data services, contact-center technology, AI capabilities, and supporting suppliers have different owners, funding models, roadmaps, and measures. Product teams release quickly, but support teams learn about changes after deployment. Experience defects move between teams. Dependency and configuration knowledge is incomplete. Reliability objectives differ by product. AI features are approved locally without a complete service, data, risk, or operational view.

The organization does not have a simple “old ITIL versus modern product management” problem. It has an accountability gap between management objects.

Its operational processes are valuable and should be preserved. Its product velocity is also valuable. The missing capability is integrated lifecycle governance: who owns the complete digital outcome from discovery through support; how product, service, experience, architecture, suppliers, risk, and AI decisions are reconciled; and what evidence determines whether the outcome is improving.

This is why ITIL’s history matters. A later framework does not win by displacing the earlier one. It wins only when the organization can nest earlier strengths inside a wider and genuinely governed outcome.

Five Executive Questions Before Adopting Version 5 Language

1. What is our real unit of accountability? Is it a ticket, a process, a service, a value stream, a product, or an integrated product-service outcome?
2. Where does lifecycle ownership break? Identify the point – discover, design, acquire, build, transition, operate, deliver, or support – where decisions, evidence, or accountability become fragmented.
3. Which earlier capabilities create real value and must be preserved? Distinguish durable operational control from bureaucracy that has lost its purpose.
4. Which modern concepts exist only in vocabulary? Test whether product, value, experience, transformation, and AI language is reflected in funding, decision rights, measures, architecture, supplier governance, and ownership.
5. What evidence would prove that the operating model changed? Look for faster feedback, clearer accountability, fewer cross-functional failures, better experience, controlled risk, operational resilience, and measurable outcomes – not completion of a framework rollout.

These questions prevent a recurring failure: adopting the language of a later ITIL edition while retaining the governance mechanics of an earlier one.

Frequently Asked Questions About ITIL History

When was ITIL first created?

The CCTA began the work in the mid-to-late 1980s, and 1989 is commonly cited as the release point for the first ITIL publications. The original library expanded over subsequent years, so its beginning is better understood as a period of development and publication than as one launch event. [1][2][9]

Why was ITIL originally developed?

ITIL was developed to improve the quality, consistency, and cost-effectiveness of government IT services. It promoted service orientation, defined responsibilities, and reusable management practices when technology organizations were often centered on technical components rather than customer requirements. [1]

What was the main difference between ITIL v2 and ITIL v3?

ITIL v2 organized guidance around connected service support and service delivery processes. ITIL v3 retained those process capabilities but placed them inside a five-stage lifecycle covering strategy, design, transition, operation, and continual improvement. [1][2][3]

Was ITIL 2011 a new version?

No. ITIL 2011 was an update to the v3 publications. It corrected inconsistencies, clarified concepts, and improved alignment across the lifecycle guidance; it did not introduce a new numbered framework architecture. [10][11]

Did ITIL 4 eliminate processes?

No. ITIL 4 shifted the framework’s visible architecture toward practices, value streams, guiding principles, and the Service Value System. Processes remain part of practices, but a process alone is not considered a complete description of organizational capability.

Does ITIL Version 5 replace ITIL 4?

Official guidance presents Version 5 as an evolution rather than a reset. It retains the guiding principles and Service Value System, preserves substantial continuity in the management practices, and introduces a more explicit Product and Service Lifecycle Model with stronger product, experience, transformation, and AI context. [4][5][13]

Are older ITIL skills still useful?

Yes. Incident, problem, change, configuration, service-level, continuity, supplier, and improvement capabilities remain essential when they are used inside a broader operating model. Their purpose and interfaces must evolve as products, services, experience, value streams, and enterprise governance become more integrated.

The Decision ITIL History Should Change

The wrong lesson from ITIL history is that leaders should continuously replace one framework vocabulary with another. The stronger lesson is that technology management must expand when the object being managed expands.

When IT was primarily centralized infrastructure and support, operational consistency was a major advance. When services depended on connected teams and tools, process integration became essential. When outcomes depended on decisions made before and after operation, lifecycle governance mattered. When digital work became continuous and cross-functional, value systems and value streams became necessary. When products, services, experiences, ecosystems, and AI became inseparable, enterprise-wide lifecycle accountability became unavoidable.

The practical choice is not between preserving the past and adopting the future. It is deciding how to nest durable operational disciplines inside a management system broad enough for the technology organization now being led.

The final management-object test is therefore:

What is the broadest digital outcome this organization claims to own, and where do its decision rights, accountabilities, measures, controls, and evidence remain trapped at a narrower historical layer?

A leadership team should be able to answer four follow-on questions:

• Who owns the outcome across its full lifecycle?
• What evidence shows that capability, experience, resilience, risk, and value improved rather than activity merely increased?
• Which earlier operational disciplines are essential to making the broader model reliable?
• What condition would trigger redesign of the operating model, governance, or product-service boundary?

That is the durable value of ITIL’s history. It is not a museum of methods. It is a record of how the object of technology management expanded – and a diagnostic for whether the organization expanded with it.

Editorial and applicability note: This article was researched and reviewed on July 27, 2026. Version 5 was being introduced through a phased release, so current PeopleCert guidance should be checked before making certification or transition decisions. The ITIL Management Object Ladder is a CIO Index analytical model, not an official PeopleCert or ITIL model.

References

1. IT Process Wiki, “History of ITIL,”
2. University of Utah, “ITIL 4 History, Guiding Principles, and Best Practices,”
3. ILX Group, “The History of ITIL: From Origins to ITIL Version 5,” March 17, 2026.
4. PeopleCert, “Understanding the Evolution of ITIL,”
5. ITIL / PeopleCert, “ITIL Foundation Version 5: What’s New?,”
6. ITIL / PeopleCert, “Why Now Is the Right Time for ITIL Version 5?,” February 27, 2026.
7. PeopleCert, “PeopleCert Completes AXELOS Acquisition,” July 2021.
8. UK Cabinet Office, “New Deal Will Market Government Professional Qualifications,” April 26, 2013.
9. TechTarget, “What Is ITIL? A Guide to the IT Infrastructure Library,” September 18, 2024.
10. University of Utah, “ITIL Versions: What Are the Differences?,”
11. IT Process Wiki, “ITIL 2011,”
12. ITIL / PeopleCert, “Moving from ITIL 4 to ITIL Version 5 – What Organizations Need to Know and Do,” May 8, 2026.
13. PeopleCert, “Understanding the Evolution of ITIL – Practices and Continuity,”