How practices work in ITIL

ITIL-130 followed work as it flows through the service value system: from opportunity and demand, through the six value chain activities, to value. That flow tells you what has to happen. Practices tell you how an organization is equipped to make it happen. This course and ITIL-141 study the practices that matter most for running services day to day. ITIL-140 covers the service support practices: the service desk, incident management, problem management, service request management, change enablement, and monitoring and event management. ITIL-141 covers service delivery and improvement practices such as service level management, configuration, release and deployment, relationship, supplier and information security management.

This first lesson explains what ITIL means by a practice, how practices are grouped, how they contribute to value chain activities and value streams, and what the Foundation exam expects you to know about them. It also clears up a source of confusion that catches many newcomers: the word incident means different things in service management, information security and occupational health and safety.

As in the earlier courses, HSM University is independent. ITIL® is a registered trademark of PeopleCert. All scenarios and questions are original, and the course does not reproduce official text or exam questions.

What a practice is

In ITIL 4, a management practice is a set of organizational resources designed for performing work or accomplishing an objective. The definition is deliberately broad. A practice is not just a process document. It includes the people and skills, the information and tools, the partners and suppliers, and the value streams and processes needed to do a type of work well. In other words, each practice is described through the same four dimensions of service management you met in ITIL-110 and ITIL-130.

Think of incident management. A process flowchart for logging and resolving incidents is part of it, but on its own a flowchart restores nothing. The practice also needs trained people who know how to diagnose faults, a tool that records incidents and links them to services and configuration items, monitoring that detects failures, suppliers who answer when their components fail, and agreements that say how quickly each type of incident should be resolved. A practice is the whole capability, not one part of it.

Practices are not departments

A common misunderstanding is to equate a practice with a team. An organization may have a team called the service desk, but the service desk practice also depends on knowledge written by other teams, tools run by an infrastructure group and agreements negotiated by service level managers. Equally, a single team may contribute to several practices. A network operations team might handle events, resolve incidents, investigate problems and implement changes in the same week.

This matters because organizations that equate practices with departments tend to create handoffs and queues between them. Work bounces from team to team while each team optimizes its own metrics. ITIL-130 showed how value stream thinking cuts across these silos. Practices supply the capabilities that value streams draw on; value streams describe how those capabilities combine to create a particular outcome.

How many practices, and how are they grouped?

ITIL 4 describes 34 management practices in three groups. General management practices (14) come from wider business management and apply across the organization: examples include continual improvement, information security management, knowledge management, relationship management, risk management and supplier management. Service management practices (17) developed within IT service management: examples include incident, problem, change enablement, service desk, service level, service request and monitoring and event management. Technical management practices (3) adapt technology management for service management purposes: deployment management, infrastructure and platform management, and software development and management.

ITIL (Version 5), launched in 2026, keeps a count of 34 practices but reorganizes them. Published summaries of the Version 5 practice set, checked in October 2026, describe two groups instead of three: product and service management practices (22) and general management practices (12). The technical group disappears, and a handful of practices move between groups. The six practices in this course keep their names and broadly their purposes in those summaries. Because practice descriptions and groupings can change between versions and editions, always check the current official materials before relying on exact wording.

The six practices in this course

Each practice has a purpose statement. The official wording is owned by PeopleCert, so the descriptions below are paraphrases that capture the idea you need to recognize.

Two further practices run through the whole course even though they are formally covered elsewhere. Knowledge management, a general management practice, is the subject of lesson 10 because support depends on it so heavily. Service level management, covered in ITIL-141, sets the targets that support practices are measured against, so lesson 11 uses it when discussing metrics.

What the Foundation exam expects

The ITIL 4 Foundation syllabus distinguishes two levels of knowledge about practices. For a set of 15 practices, candidates need to recall the purpose. For seven of them, candidates need to explain them in more detail, including key terms and how they work. The seven are continual improvement, change enablement, incident management, problem management, service desk, service level management and service request management. Five of the seven belong to this course; continual improvement was covered in ITIL-120 and ITIL-130, and service level management is covered in ITIL-141. Monitoring and event management is in the purpose-only list.

The Version 5 Foundation syllabus may weight topics differently. ITIL-101 described how to check the current syllabus for the exam you plan to take. This course teaches the practices in enough depth for either edition and for real work, and the capstone in lesson 12 includes an exam strategy for practice questions.

Practices and the value chain

Practices do not map one-to-one onto value chain activities. Each practice contributes to several activities, and each activity draws on several practices. Incident management, for example, contributes most heavily to deliver and support, but it also contributes to engage (communicating with affected users), improve (incident records reveal where services are fragile) and design and transition (incidents after a release show whether transition worked). ITIL publications express this with a heat map that shows how strongly each practice contributes to each activity.

You do not need to memorize heat maps. What matters is the idea behind them: a practice is a reusable capability, and value streams combine practices as needed. When you design or improve a value stream, you ask which practices it needs at each step and whether those practices are mature enough.

The code below builds a small illustrative grid of this kind for all six practices and reports, for each value chain activity, which practice contributes most. The scores are invented for teaching; the point is the technique of making contributions visible.

# Illustrative contribution scores, 0 = none to 3 = high (invented for teaching)
activities = ["plan", "improve", "engage", "design/transition", "obtain/build", "deliver/support"]
scores = {
    "service desk":        [0, 1, 3, 1, 0, 3],
    "incident":            [0, 2, 2, 1, 1, 3],
    "problem":             [1, 3, 1, 2, 2, 2],
    "service request":     [0, 1, 3, 1, 2, 3],
    "change enablement":   [1, 2, 1, 3, 2, 2],
    "monitoring/event":    [0, 2, 0, 1, 1, 3],
}
print(f"{'practice':20}" + "".join(f"{a[:9]:>10}" for a in activities) + "   total")
for p, row in scores.items():
    print(f"{p:20}" + "".join(f"{v:>10}" for v in row) + f"{sum(row):>8}")
print()
for j, a in enumerate(activities):
    best = max(scores, key=lambda p: scores[p][j])
    total = sum(r[j] for r in scores.values())
    print(f"{a:18} strongest: {best:18} activity total: {total}")

practice                  plan   improve    engage design/tr obtain/bu deliver/s   total
service desk                 0         1         3         1         0         3       8
incident                     0         2         2         1         1         3       9
problem                      1         3         1         2         2         2      11
service request              0         1         3         1         2         3      10
change enablement            1         2         1         3         2         2      11
monitoring/event             0         2         0         1         1         3       7

plan               strongest: problem            activity total: 2
improve            strongest: problem            activity total: 11
engage             strongest: service desk       activity total: 10
design/transition  strongest: change enablement  activity total: 9
obtain/build       strongest: problem            activity total: 8
deliver/support    strongest: service desk       activity total: 16

The output shows deliver and support drawing on every support practice, which is why this course spends so much time there, and plan drawing on them least. A real organization would build such a grid from its own value streams and use it to decide where practice improvement would help most.

Practice success factors and key metrics

ITIL practice guidance describes each practice through practice success factors: the conditions that must be in place for the practice to fulfil its purpose. For incident management, examples are detecting incidents early, resolving them quickly and efficiently, and continually improving the approach. Each success factor has key metrics that show whether it is being achieved. Detection might be measured by the share of incidents detected by monitoring before users report them; resolution by the share resolved within target times; improvement by the trend in repeat incidents.

Success factors protect against a trap discussed in ITIL-120: measuring activity instead of outcomes. A service desk that answers thousands of calls is busy, but whether it is succeeding depends on whether users get what they need quickly and whether the number of avoidable contacts is falling. Throughout this course, each practice is presented with its success factors and with metrics that reflect them, along with cautions about how each metric can be gamed.

Three meanings of incident

The word incident is used in three professional fields with three different meanings, and the confusion causes real errors in policies, contracts and exam answers.

In ITIL, an incident is an unplanned interruption to a service or a reduction in its quality. A printer that will not print, a website that loads slowly and an application that crashes are all incidents. The goal of incident management is to restore normal service as quickly as possible.

In information security, a security incident is an event that actually or potentially jeopardizes the confidentiality, integrity or availability of information or systems, or that violates security policies. Some security incidents are also ITIL incidents (ransomware that encrypts a file server interrupts a service), but many are not (an employee emailing confidential data to a personal account may interrupt nothing). Security incident response follows its own guidance. In the United States, NIST published Revision 3 of Special Publication 800-61 in April 2025, which aligns incident response with the NIST Cybersecurity Framework 2.0. CISSP-113 and the planned CISSP-116 cover that discipline.

In occupational health and safety, an incident is an event that caused or could have caused injury, illness or damage. The HSE courses at HSM University, such as HSE-403 on incident investigation, use the word in that sense.

Practices in different organizations

The same practice looks different in a five-person software start-up and in a national bank. In the start-up, the developers may carry pagers, resolve incidents, make changes and talk directly to customers; the practices exist but are informal and blended. In the bank, there may be dedicated teams for each practice, regulatory reporting obligations and formal authorities. ITIL does not prescribe one model. The guiding principle start where you are, from ITIL-120, applies: understand what each practice already looks like in your organization before redesigning it.

Public sector organizations add further considerations. Government service desks in Canada must offer service in both official languages where the Official Languages Act applies, and provincial governments have their own language and accessibility requirements. In the United States, federal agencies must make support channels accessible under Section 508 of the Rehabilitation Act. Those obligations shape the service desk practice as much as any ITIL guidance does.

How to study the practices

Each practice lesson in this course follows a similar pattern. It explains the purpose in plain words, the key terms the exam and the workplace use, how the work flows, the people and tools involved, the success factors and metrics, common failure patterns and how the practice connects to the others. Worked examples and short programs show the arithmetic behind priority, availability, staffing, risk and improvement decisions. The final lesson brings everything together in a redesign of support for an invented organization.

One habit will help throughout: whenever you read about a practice, ask what outcome it protects for the user and how you would know whether it is working. That question connects the practices to the value focus that runs through all of ITIL.