ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
Moving from ITIL 4 to ITIL 5 sounds like a documentation rewrite and mostly is not. One document is genuinely superseded. A handful need a vocabulary pass. Several subjects are new and have nothing to replace. Knowing which is which saves weeks.
This guide sets out what actually needs changing, in what order, and what you can safely leave alone — plus the one thing organisations get wrong when they attempt it.
Start here, because it changes the whole calculus. PeopleCert has stated the release is phased and that existing ITIL 4 certifications remain fully relevant. ITIL 4 is a previous edition, not a withdrawn standard.
Your documentation carries no certification that expires. There is no audit that fails because a policy references the service value chain. If you also hold ISO/IEC 20000-1, that is a separate certifiable standard and nothing in this edition change affects it.
So the ITIL 4 to ITIL 5 transition is a documentation exercise you schedule, not an incident you respond to. Treat anyone selling it as urgent with suspicion.
Sort your documentation set into four buckets. Almost everything lands in the first two.
| Bucket | What it contains | Effort |
|---|---|---|
| No change | Practice policies, RACI, metrics catalogue, registers, procedures, runbooks, cross-mappings to other frameworks | None |
| Vocabulary only | Anything naming the Service Value System; document furniture; version references | Scripted find-and-replace |
| Real revision | Practices manual (category structure), four dimensions, guiding principles, index | Hours each |
| Rewrite | Whatever describes the six-activity value chain | One document |
The largest bucket by far is the first. Every practice policy you own documents a practice that exists identically in the current edition, with the same name and the same purpose. An incident management policy written against ITIL 4 needs nothing beyond a header change.
ITIL 4’s service value chain had six activities. The current edition replaces them with an eight-activity product and service lifecycle, and the eight are not a relabelling of the six — they do not correspond one to one.
Whatever document in your set describes those six activities is superseded. Rebuild it around the eight, and resist the temptation to publish a row-by-row mapping between old and new. The framework does not publish one, the activities genuinely do not map cleanly, and a table asserting they do is an invention your readers will rely on. Our guide to the eight-activity lifecycle covers the structure in detail.
Because the value chain sits inside the value system, whatever describes your Service Value System also needs its value chain section revised. The rest of that document — governance, principles, practices, improvement — is unaffected.
The practice recategorisation is the change that generates the most commentary and the least work. Three categories became two; five practices moved. In a documentation set this is the category column of your practice register, for five rows.
One caution worth acting on. If your practices manual physically groups its practice sections under three category headings, relabelling the headings leaves practices filed under the wrong one — a manual that presents its own categorisation inaccurately. Move the sections rather than rename the headings. It is mechanical work, and doing it properly takes an afternoon. Our breakdown of the 34 practices and the two categories lists exactly which five moved.
Adopting the new terms — ITIL Value System for Service Value System, product and service lifecycle for service value chain, digital products and services for services — is optional for an organisation implementing service management. It matters mainly when you are training people, so that documentation and training use the same words.
The failure mode is doing it partially. A document set where half the documents say Service Value System and half say ITIL Value System is worse than either consistent choice, because readers cannot tell whether the difference is meaningful. Run it as one scripted pass across every document, including headers, footers and document properties, and verify no occurrences survive.
Everything above is editing. The genuinely new material is where the effort goes, and none of it has an ITIL 4 predecessor to revise:
If you have limited time, spend it here rather than on vocabulary. A renamed value system does not improve anything; an AI use case register might prevent something.
Do the improvement model wording while you are in there: steps 6 and 7 are reworded, from “did we get there?” to “are we getting there?” and from “how do we keep the momentum going?” to “how do we keep the improvements relevant?”. Small edit, and it signals the shift from a verdict delivered once to a question asked continuously.
Two audiences ask about this and they need different answers.
Leadership wants to know whether the organisation is exposed. The answer is no: ITIL is not certifiable, the previous edition is not withdrawn, and no obligation attaches to the version number. What is worth raising is the new subject matter — an AI governance gap is a real exposure, and it exists whether or not you migrate.
Practitioners want to know whether their knowledge is stale. Mostly not. The 34 practices they operate are unchanged in name and purpose. What changed is the structure around them and the vocabulary. Someone certified against ITIL 4 who reads the value chain change and the AI capability model is current for practical purposes.
Avoid framing the migration as a compliance activity in either conversation. It is not one, and describing it as one makes every future genuine compliance deadline slightly less credible.
The common error in an ITIL 4 to ITIL 5 migration is rewriting from secondary sources. The commentary on this edition contradicts itself — published accounts differ on the number of lifecycle activities and on what the improvement model steps say. Documentation built on the wrong one of those is worse than documentation that is simply a version behind, because a previous edition is defensible and an invented model is not.
If you cannot verify a structural claim against the official publication, leave the document as ITIL 4 and say so. Our overview of what changed in ITIL 5 sets out what is confirmed.
PeopleCert publishes the Foundation syllabus and scheme details for the certification side of the question.
No. ITIL 4 remains a previous edition of a non-certifiable framework. Migrate when there is a reason — usually training alignment or the new subject matter.
The editing is days, not weeks, for a typical set. Building the new material — AI governance, value streams, experience — is where the months go, and that is new work rather than migration.
No. ISO/IEC 20000-1 is a separate certifiable standard with its own requirements. Nothing in this edition change touches it.
Existing ITIL 4 certifications remain valid. A bridge route exists for individuals who want the current credential. That is a personal development decision, not a documentation one.
In documentation, no — pick one vocabulary and apply it consistently. In capability terms you already are, since the practices are identical.
If the migration turns out to be larger than you want to run in-house, our ITIL Toolkit is 57 editable templates written against the current edition — the eight-activity lifecycle with a policy per activity, all 34 practices in their correct categories, the AI governance set, value stream mapping, experience management and maturity assessment. It includes a transition guide recording exactly what moved from ITIL 4, so you can see what changed rather than take it on trust.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026