ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
The ITIL product and service lifecycle is the biggest structural change in ITIL 5, and the one most likely to make existing documentation wrong. ITIL 4’s service value chain had six activities. The current edition replaces them with eight, and treats them very differently from the way most people read the word “lifecycle”.
This guide covers the eight activities, what each is for, why they are explicitly not a sequence, and how to work out which of them your organisation actually performs.
The framework describes the lifecycle as a model for managing digital products and the services delivered from them. Products and services are not alternatives here — they are two aspects of the same technology solution, and the focus of management shifts between them as work moves across the activities.
| Activity | Purpose | Typical output |
|---|---|---|
| Discover | Keep the product roadmap and service offerings aligned to consumer need and strategy. | Updated roadmap; requirements and problem statements |
| Design | Turn requirements into a solution that meets or exceeds them. | A design with testable acceptance criteria |
| Acquire | Obtain or allocate the resources needed to build the product. | Verified components; recorded licence and exit terms |
| Build | Create, configure and test the technology that constitutes the product. | A tested, versioned increment |
| Transition | Move the new or changed product into the live environment. | Authorised deployment; updated runbooks |
| Operate | Run the product so that it performs as agreed. | Monitored performance; handled events |
| Deliver | Deliver the services that run on the live product. | Fulfilled requests; service level reporting |
| Support | Restore normal operation, and feed what is learned back. | Restored service; findings into design |
Compare that against ITIL 4’s six — plan, improve, engage, design and transition, obtain/build, and deliver and support — and the shape of the change becomes clear. The old set mixed governance activities (plan, improve) with delivery activities. The new set is entirely about what happens to a product, with improvement handled as a practice rather than a chain link.
This is where most summaries go wrong, and where documentation written from them goes wrong too.
The word lifecycle invites a picture of eight steps performed in order, each finishing before the next begins. The framework explicitly rejects that reading. The activities are better pictured as stepping stones: a given piece of work crosses whichever ones it needs, in whatever order the work requires, and the scope and order vary with the product’s architecture and the organisation’s context.
Two practical consequences follow.
Do not impose sequence for tidiness. There are real dependencies — transition should not happen without an authorised change — but a policy that requires design to complete before build begins has invented a waterfall the framework does not ask for. If your documentation imposes an order, it should be able to name the control reason.
Not every organisation performs every activity. A managed service provider that builds nothing still performs discover, transition, operate, deliver and support. Writing eight activity policies for an organisation that performs five produces three documents nobody will ever follow.
These eight activities do not sit alongside the value chain. From the organisational perspective, they are it — the complete set of activities through which value is enabled by providing a product or service.
A value stream is something different: one path through those activities, producing one output for one consumer. Provisioning a new starter is a value stream. Resolving a major incident is a value stream. Both cross a handful of the eight activities and skip the rest.
Conflating the two is the single most common defect in service management documentation, and it is easy to spot: a document that says “map your value chain” is almost always describing value stream mapping and using the wrong noun. The distinction matters because they are managed differently — the value chain is designed once and reviewed rarely; value streams are mapped, measured and improved continuously.
The current edition adds a concept with no ITIL 4 equivalent. Organisations combine the activities in a small number of recurring patterns, determined by whether they build the product, consume it, or both.
Record which pattern applies before adopting anything. It determines which activity policies are in scope, and it is the first question an assessor will ask if your documentation describes activities you visibly do not perform.
Each activity is enabled by practices directly involved in performing it, and supported by others that contribute information and methods without being directly involved. The framework publishes the full mapping, and the distribution is worth knowing before you plan improvement work.
Design carries by far the heaviest practice load of any activity; discover the lightest. That is not an accident of drafting. Design decisions commit the organisation across almost every practice it operates, which is why a thin design activity is expensive later and why “we will work it out in build” is the most costly sentence in the lifecycle.
Two practices touch every one of the eight: continual improvement enables all of them, and knowledge management supports all of them. No other practice spans the whole lifecycle, which tells you something about where to invest first.
The published mapping gives a count of enabling and supporting practices per activity, and the shape of it is instructive when you are deciding where to put effort.
| Activity | Enabling practices | Supporting practices |
|---|---|---|
| Discover | 6 | 6 |
| Design | 17 | 7 |
| Acquire | 8 | 12 |
| Build | 15 | 6 |
| Transition | 14 | 11 |
| Operate | 14 | 5 |
| Deliver | 14 | 5 |
| Support | 14 | 11 |
Design at 17 enabling practices is nearly three times discover at 6. Acquire is unusual in the other direction — only 8 practices are directly involved, but 12 support it, which reflects how much of procurement depends on information held elsewhere: asset records, financial data, supplier performance, security requirements.
If you are staging an improvement programme, this table is a better guide than a maturity score on its own. Raising a practice that enables six activities pays back across six; raising one that enables a single activity does not.
Our overview of what changed in ITIL 5 covers the wider picture, and whether ITIL 4 is still current addresses the certification question. PeopleCert publishes the Foundation syllabus and what is new directly.
Eight: discover, design, acquire, build, transition, operate, deliver and support. ITIL 4’s service value chain had six.
Design and transition survive as separate activities rather than one combined link. Plan and improve are not activities in the current edition — improvement is handled through the continual improvement practice and model.
No. The framework is explicit that these are not performed as a cycle, and describes them as stepping stones crossed in whatever order the work requires.
Only for the activities your value chain pattern actually includes. A service provider that builds nothing does not need a build policy.
The value chain is the organisation’s complete set of activities — all eight. A value stream is one path through them, producing one output for one consumer.
Rebuilding a documentation set around the ITIL product and service lifecycle means a framework document plus a policy for each activity you perform, each naming the practices that enable it. Our ITIL Toolkit provides exactly that — 57 editable templates including a lifecycle framework, eight activity policies, all 34 practices in their current categories, and a traceability matrix mapping every practice to every activity as enabling or supporting.
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026
August 31, 2026