Blog

A service desk analyst moving towards service management, a project manager supporting a major platform rollout, and a CIO building a common operating model may all ask which ITIL certification first. The answer is usually ITIL 5 Foundation, but the reason for taking it - and the route that follows - should reflect the individual’s role and the organisation’s service-management objectives.

ITIL is not simply a collection of exam badges. It provides a recognised framework for creating value through services, connecting technology teams, suppliers, customers, governance and continual improvement. Selecting the right starting point matters because it establishes the vocabulary and practical context needed for more specialised learning.

A service desk manager asked to improve incident performance needs something different from a transformation leader redesigning service value streams. Both may benefit from ITIL, but selecting the same course simply because it is widely recognised can produce limited value. Knowing how to choose an ITIL course starts with the capability you need to build, not the certificate name alone.

ITIL 5 provides a practical framework for service management in organisations where digital products, suppliers, operations and customer experience must work together. The right learning route can strengthen an individual's career profile or give an enterprise a common language for improving services. The wrong route can leave learners with knowledge that is credible but disconnected from their responsibilities.

A board asks whether cyber risk is being governed properly. A security team needs clearer control requirements. An auditor wants evidence that technology decisions support business objectives. These are related questions, but they are not solved by the same framework. That is the central distinction in COBIT versus NIST: one provides an enterprise governance and management system for information and technology, while the other offers widely used cyber security guidance, profiles and control resources.

For organisations planning a governance, assurance or cyber security capability programme, the choice should not be framed as a contest with one winner. COBIT and NIST often address different layers of the operating model. Selecting the right starting point depends on the business problem, regulatory exposure, existing practices and the teams expected to apply the framework.

A service desk may have capable people, committed suppliers and a well-funded toolset, yet still struggle with inconsistent change outcomes, unclear ownership or recurring incidents. The question of ITIL versus ISO 20000 matters because each offers a different way to address those problems. One helps teams shape and improve service management practices; the other provides a formal, independently auditable benchmark for the service management system.

For professionals, the distinction affects certification choices and career direction. For organisations, it influences governance, investment, assurance and the evidence required to demonstrate that services are controlled and continually improved. They are complementary, but they are not interchangeable.

When technology decisions affect revenue, regulation, customer trust and operational resilience, governance cannot remain a set of policies stored in a shared drive. It needs defined decision rights, measurable objectives and a common language across leadership, technology, risk and assurance functions. COBIT governance framework training gives professionals and organisations a structured way to build that capability.

COBIT is widely used to help enterprises govern and manage information and technology in line with business objectives. For individual professionals, training can provide a recognised route into governance, risk, compliance and assurance responsibilities. For organisations, it can establish a consistent foundation for teams working across IT, cyber security, architecture, service management, audit and transformation.

A failed payment journey, unavailable collaboration platform or degraded customer portal quickly becomes more than a technical issue. It affects revenue, productivity, confidence and the organisation’s ability to operate. ITIL 4 incident management gives service teams a disciplined way to restore normal service as quickly as possible while maintaining clear communication, accountable decision-making and usable operational data.

For service management professionals, the value is not simply knowing the incident management definition for an examination. It is being able to apply a recognised practice in environments where services are interconnected, support is distributed across teams and users expect rapid, transparent action. For organisations, it creates a common operating language that can scale across internal IT, suppliers and business-facing support functions.

A step-by-step guide with templates, examples, and rollout tips

Why the Service Catalog matters even more in ITIL (Version 5)

A Service Catalog is one of those “boring until it saves you” artifacts. When it is done well, it reduces chaos, speeds up delivery, and makes IT feel predictable to the business. When it is done poorly, it becomes a dusty list no one trusts.

ITIL (Version 5) is positioned for the AI and cloud era, with a stronger emphasis on practical implementation and clearer links between product and service lifecycles. That shift makes the Service Catalog even more important because it becomes the shared reference point for what you provide, how people request it, who owns it, and what “good” looks like.

Interest in ITIL (Version 5) has increased sharply since PeopleCert began publishing official updates for the 2026 rollout.

This article focusing on:

• What PeopleCert says is new in ITIL (Version 5)
• What is already available today
• What is planned next and what is still being validated
• How ITIL 4 and ITIL (Version 5) will coexist during the transition
• What changes in qualifications, exams, practices, and renewal

Digital transformation rarely fails on day one.

In fact, it often starts with energy, budget, and strong executive support.

New platforms are selected.

Tools are rolled out.

Dashboards light up.

Teams attend training sessions.

And then, quietly, momentum slows.

Six or twelve months later, the organisation is still using many of the same processes, responding to incidents in the same way, and making decisions with the same delays. The tools are there, but the transformation feels incomplete.

This is not an exception. It is the most common pattern.

Digital transformations usually stall not because the technology is wrong, but because the organisation mistakes tool adoption for capability change.