ITIL 5 Practices: All 34 and the 2 Categories

ITIL 5 practices number thirty-four — the same thirty-four as ITIL 4, with the same names. What changed is how they are grouped: three categories became two, and five practices moved. This guide lists all of them, explains the recategorisation, and covers what it actually means for documentation.

The short answer, if you only need one: nothing about any practice changed. Only its filing did.

The two categories of ITIL 5 practices

ITIL 4 sorted its practices into general management, service management and technical management — 14, 17 and 3 respectively. The current edition uses two categories: 22 product and service management practices, and 12 general management practices. The technical management category no longer exists.

Product and service management practices (22)

Availability management · Business analysis · Capacity and performance management · Change enablement · Deployment management · Incident management · Information security management · Infrastructure and platform 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 financial management · Service level management · Service request management · Service validation and testing · Software development and management

General management practices (12)

Architecture management · Continual improvement · Knowledge management · Measurement and reporting · Organisational change management · Portfolio management · Project management · Relationship management · Risk management · Strategy management · Supplier management · Workforce and talent management

Which ITIL 5 practices actually moved

Five practices changed category. Everything else stayed where it was, under a category that may have a new name.

Practice	ITIL 4 category	Current category
Deployment management	Technical management	Product and service management
Infrastructure and platform management	Technical management	Product and service management
Software development and management	Technical management	Product and service management
Information security management	General management	Product and service management
Service financial management	General management	Product and service management

The arithmetic reconciles exactly, which is a useful check on any summary you read elsewhere. General management goes from 14 to 12 — the old 14 minus information security and service financial. Product and service management arrives at 22 — the old 17 service management practices, plus the 3 technical, plus those same 2. Any account that does not add up to 22 and 12 has something wrong in it.

The 17 former service management practices did not move. Their category was renamed around them, which is a different thing and worth keeping straight when you explain the change to a team.

Why information security and service financial management moved

The two general-to-product moves are the interesting ones, because they say something about the edition’s framing.

Both practices were previously treated as organisational disciplines that service management borrowed. Placing them in product and service management reflects a view that security and cost are properties of the product itself rather than governance applied to it from outside. In practice that is how competent teams already worked — security designed in rather than reviewed at the end, cost understood per product rather than as an IT overhead — but the categorisation now says so.

It changes no control. An information security management policy written against ITIL 4 describes the same practice, with the same purpose and the same activities.

What the recategorisation means for your documentation

Less than the amount of commentary about it would suggest. Categorisation affects how a practice is catalogued, not what it does, who owns it, or what documentation it requires.

In a typical documentation set the change touches:

• One column of one table. The category column of your practice register, for five rows.
• The grouping headings in your practices manual, if it presents practices by category. If your manual has a “technical management practices” section, that section heading is now wrong — though the practices inside it are not.
• Nothing else. Individual practice policies, RACI matrices, metrics catalogues, registers and procedures are unaffected.

One caution. If your practices manual physically groups practice sections under three category headings, relabelling the headings leaves practices sitting under the wrong one. Either move the sections or accept that the manual now presents its own categorisation inaccurately. Moving them is a mechanical job worth doing properly.

How practices relate to the lifecycle

The more useful question than categorisation is which practices your lifecycle activities actually depend on. The framework publishes a mapping of every practice against every activity, marking each as enabling — directly involved in performing the activity — or supporting, meaning it contributes information and methods without being directly involved.

Two things stand out. Design depends on more practices than any other activity, by a wide margin; discover on the fewest. And exactly two practices touch all eight activities: continual improvement enables every one, and knowledge management supports every one.

That mapping is more actionable than the category list. Reading down a column tells you which practices must be capable before an activity is reliable. Reading across a row tells you how much of the lifecycle a weak practice puts at risk — a practice at low capability that enables six activities is a materially bigger exposure than one that enables one. Our guide to the eight-activity product and service lifecycle covers how the activities themselves work.

Assessing practice capability

The current edition pairs the practice list with a maturity model that assesses two different things, and keeping them apart matters. Practice capability scores an individual practice from 1 to 5, from performed informally and dependent on individuals, through standardised and integrated, to continually improved. Value system maturity scores the whole management system across five components: guiding principles, governance, value chain, practices and continual improvement.

They are not averaged. An organisation can run several strong practices inside a weak value system, and the improvement that follows from each finding is different — one is a practice problem, the other is a governance problem.

Three points are worth carrying into any assessment. You do not have to score all 34; scope to the practices carrying current priorities and record why the rest were excluded, because an unexplained gap reads as an oversight later. Score against evidence — documents, records, performance data — since a score with no evidence reference is an opinion. And targeting level 5 everywhere is an anti-pattern: level 3 is a reasonable target for most practices, with 4 or 5 justified where the practice carries regulatory obligation or constrains a critical value stream.

Do you need a policy for every practice?

No, and attempting it is a common way to produce a documentation set nobody reads. Thirty-four standalone policies is a great deal of paper for an organisation that operates twelve practices seriously.

A more workable pattern is a single practices manual covering all 34 at the level of purpose, activities, roles and metrics, with standalone policies only for the practices that carry real obligation — change enablement, incident, problem, information security, service level, supplier and continual improvement in most organisations. Add more as practices mature.

For the framework’s own account, PeopleCert publishes the Foundation syllabus and practice structure. Our overview of everything that changed in ITIL 5 puts the practice change in context.

Frequently asked questions

How many ITIL 5 practices are there?

Thirty-four, the same number as ITIL 4, grouped into two categories instead of three: 22 product and service management and 12 general management.

Were any practices added or removed?

No. All 34 carry forward with the same names. Only five changed category.

What happened to the technical management practices?

The category was dissolved. Its three practices — deployment management, infrastructure and platform management, and software development and management — moved into product and service management.

Do we need to rewrite our practice policies?

No. Each policy documents a practice that exists identically in both editions. The change is to the category column of your practice register.

Which practices matter most?

The ones your lifecycle activities depend on. Continual improvement and knowledge management touch all eight activities; beyond those, it depends on which activities your organisation performs.

Documentation covering all 34

Our ITIL Toolkit includes a practices manual covering all 34 practices in their current two categories — with purpose, key activities, inputs and outputs, RACI and KPIs for each — plus 16 standalone practice policies and a traceability matrix mapping every practice to every lifecycle activity as enabling or supporting. 57 editable templates in total, built against the current edition.