ITIL 4 Foundations

Training notes turned into a practical guide to ITIL v4

Disclaimers

1. Opinions expressed in this post (and in any of all my posts) are solely, unless otherwise specified, those of the author, me. Those opinions absolutely do not reflect the views, policies, positions of any organizations, employers, or affiliated groups.

2. If you are a colleague and recognize the situation described below, remember: I'm critiquing the system, not the people.

3. Render unto Caesar what is Caesar's: Claude helped me find up-to-date documentation links and helped beautify all the diagrams used (and not used) in this article.

4. This article has been proofread by Mame Astou and Abdoul Karim. Thank you both.
   
   

Hook

I tend to stay in my lane. Focus on what I understand, the perimeter I actually control. Everything beyond my code, my systems, my terminal (the hierarchy, management, all the people I work with who don't write programs) has always been a blur to me. Vague, formless, abstract. Sometimes genuinely incomprehensible. Not because I think those people are wrong, but because whatever they do has always felt like noise I couldn't parse.

I'll grudgingly admit, though: since joining this biomedical research center, everything that happens outside my direct work has become the most interesting part of the job. Humans are fascinating creatures to observe from a safe distance. Maybe it's because my actual technical work is no longer the hardest thing on my plate. Or maybe because what happens in the corridors and meeting rooms has a direct, outsized impact on my work, on my freedom to do that work the way I'd want to.

The hardest thing is collaborating with many other people, exchanging information in a way that everyone actually understands each other. Not just hears: understands. The hardest thing is listening, really listening to what others have to say, deeply, absorbing and retaining what they meant. Then responding, expressing yourself in a way that gets through, in a way that convinces. Making the right compromises, the right calls, and moving forward together, making sure everyone gets something of what they came for.

Last Tuesday, I was enrolled in an ITIL 4 Foundations training organized by my hierarchy. The stated goals were clear: garantir la disponibilité des systèmes (ensure system availability), structurer la gestion des incidents (structure incident management), and parler le même langage (speak the same language). Perfectly reasonable goals.

In practice: sitting in a room while someone talks through concept after concept, deploying words and definitions at high velocity, is its own endurance sport. It's made harder by the fact that some concepts I thought I already knew get redefined with vocabulary I would never have chosen — and some familiar words get used in ways that are subtly but persistently disorienting.

That said, I have to be honest: ITIL 4 is not the bureaucratic nightmare its reputation suggests. If anything, I realized I'd already been practicing most of these concepts; informally, imperfectly, without knowing there was a name for them. Done right, this is a coherent framework that actually acknowledges modern realities: Agile, DevOps, SRE, Lean.

Since I took notes anyway, might as well turn them into something useful. I hope you'll learn something. Music \o/

Table of contents

1. What is itil 4?
2. Why should your organization care?
3. The vocabulary
4. Pestle: external forces
5. The service value system (svs)
6. The service value chain (svc)
7. The 4 dimensions
8. The 7 guiding principles
9. The 34 practices
10. Incident management
11. Problem management
12. Service request management
13. What kind of ticket is this?
14. Change enablement
15. Continual improvement
16. Governance and risk management
17. ITIL 4 ↔ agile, devops, lean
18. Case study
19. Maturity baseline
20. Tooling
21. Where does this break down?
22. ITIL 4 for Python/Django developers
23. ITIL v5
24. Conclusion

What is ITIL 4?

ITIL (Information Technology Infrastructure Library) is a framework for IT Service Management (ITSM). It provides guidance on how organizations can use IT as a tool to facilitate business transformation and growth.

Key facts:

• Origin: Developed in the 1980s by the UK government's CCTA (Central Computer and Telecommunications Agency) to standardize IT practices across public services.
• ITIL 4 (released 2019): The current version. A major rethink compared to ITIL v3, designed to integrate with modern approaches: Agile, DevOps, Lean, SRE.
• Owner: Currently maintained by PeopleCert, which acquired AXELOS (the previous owner) in 2021.
• Who uses it? Organizations of all sizes, across industries. Particularly common in banking, telecom, healthcare, public sector, and large IT departments.

One thing ITIL 4 gets right that its predecessors didn't: it explicitly acknowledges that you don't need to implement all 34 practices. You pick what fits. This was not how earlier versions were often sold and it caused a lot of unnecessary process theater in organizations that implemented ITIL like a checkbox exercise.

Why should your organization care?

During the training, an interesting observation was made about three organizational thresholds where ITIL practices start to become relevant:

The practical implication: you don't need all of ITIL. A 7-person startup building an internal tool doesn't need a Change Advisory Board. A bank with 200 IT staff probably does. ITIL 4's design philosophy is, understand the principles, apply the practices that solve your actual problems, and leave the rest on the shelf.

The vocabulary

Before we can discuss the framework, we need to agree on definitions. ITIL has precise meanings for words we use casually.

Who's involved?

In practice: the customer decides what they need, the user interacts with it daily, and the sponsor pays for it.

What are we delivering?

The value equation

This is arguably the most important concept in ITIL v4:

Value = Utility × Warranty

• Utility: What the service does — fit for purpose. Does it support the customer's performance or remove a constraint?
• Warranty: How reliably it does it — fit for use. Is it available when needed? Secure? Capable of handling the load?

A service that does the right thing but crashes every Monday morning has no value. A service that's always available but solves the wrong problem also has no value. We need both, because a zero on either side collapses the product.

And value is subjective, contextual, and co-created. The provider alone cannot create value, it's always produced in interaction with the customer. This shifts the conversation from "we delivered the system" to "did the customer actually get what they needed?"

PESTLE: The external forces you cannot control

ITIL v4 acknowledges that organizations don't operate in a vacuum. PESTLE analysis provides a structured lens for scanning the external environment:

PESTLE is not unique to ITIL, it's a general strategic analysis tool. ITIL v4 borrows it because service management decisions are always made inside an organizational and environmental context. We never want to build a technically excellent system that doesn't survive its first compliance audit or budget cut.

The big picture: Service Value System (SVS)

The Service Value System (SVS) is ITIL v4's model for how an organization creates value. Think of it as the engine diagram for your IT service operations.

It takes opportunities and demands as input, runs them through a system of governance, practices, and activities, and outputs value for all stakeholders.

The SVS is composed of five components:

1. Guiding Principles — universal recommendations that apply to all decisions
2. Governance — the framework for directing and controlling the organization
3. Service Value Chain (SVC) — the set of interconnected activities that turn demand into value
4. Management Practices — the 34 practices that provide organizational capability
5. Continual Improvement — the persistent drive to improve everything

NOTA BENE: Guiding Principles and Continual Improvement are not steps in a sequence. They're a mindset that applies to all activities, at all times. You don't "do continual improvement" after you're done. You do it while you're doing everything else.

Inside the SVS: the Service Value Chain (SVC)

The Service Value Chain is the operational model at the core of the SVS. It defines 6 activities that can be combined in different ways. The combination for a given service or request is called a value stream.

The SVC is not linear. An incident resolution primarily activates Engage, Deliver & Support, and Improve. A new service launch activates all six. A routine service request might only need Engage and Deliver & Support.

The 4 dimensions

Every component of the SVS should be considered from 4 perspectives. Ignoring any of them is one of the most reliable ways to make a project fail.

These 4 dimensions are interdependent. Migrating to a new monitoring tool (Information & Technology) means retraining people (Organizations & People), renegotiating vendor contracts (Partners & Suppliers), and redesigning on-call workflows (Value Streams & Processes).

The 7 guiding principles

These are universal principles that guide decision-making in any circumstance. They apply regardless of which practices you're implementing.

1. Focus on value
Every activity should link back to value for stakeholders. Before starting anything, ask: who benefits, and how? If you can't answer that, stop.

2. Start where you are
Never ever assume you need to start from scratch. Assess what already works before designing something new. Most organizations already have something useful, the goal is to build on it, not erase it.

3. Progress iteratively with feedback
Don't try to design the perfect solution upfront. Deliver in small increments, gather feedback, adjust. This is the same philosophy behind Agile sprints and DevOps Continuous Delivery.

4. Collaborate and promote visibility
Work done in silos fails. Decisions made without the right people in the room fail. Make work visible: kanban boards, incident dashboards, change calendars; and involve stakeholders early, not at the end.

5. Think and work holistically
Services are systems. A change to one component can have unexpected effects elsewhere. Consider end-to-end impact, not just the piece in front of you. Lol!

6. Keep it simple and practical
If a process step doesn't add value, eliminate it. If a tool creates more overhead than it saves, reconsider. Complexity is the enemy of reliability. Where I come from, we say keep it simple and stupid, see here

7. Optimize and automate
First, optimize the process (eliminate waste, reduce friction). Then, automate what remains. Automating a broken process gives you broken results, faster. The order matters.

The 34 management practices

ITIL v4 defines 34 practices designed for performing work or accomplishing an objective. They replace what ITIL v3 called "processes" (the shift reflects that a practice includes culture, tools, and knowledge, not just the steps).

They're organized into 3 categories:

The full list of 34 ITIL 4 practices exists for reference. No, you do not need to apply all 34 ITIL v4 practices. ITIL v4 is designed to be adopted and adapted. The core philosophy is to use only the practices that address your organization's specific needs, pain points, and goals.

When you start, you need to identify your top 3 pain points (e.g., too many incidents, slow changes) to pick the right practices to implement first.

Here, we are almost starting from zero and we are already overwhelmed to the max. I would like to suggest 4 practices that, if we don't have them, we're operating blind:

1. IT asset management → What do we actually own?
2. Service request management → What are our users asking for?
3. Incident Management → What is broken right now?
4. Change Enablement → What is changing and why?

The 4 together cover the 4 basic operational questions any IT team needs answered at any moment. Everything else can be phased in.

Incident management

Incident management is the practice responsible for managing the lifecycle of all incidents: unplanned interruptions or reductions in the quality of a service. Before we go further, let's nail the vocabulary:

These are distinct. An incident is what you respond to at 2am. A problem is what you investigate to prevent the next one. Conflating them is how teams fix the same incident repeatedly without ever addressing what's actually causing it.

The 7-Step incident lifecycle

Incident Priority Matrix

Priority is determined by Impact (how many users/processes are affected) and Urgency (how quickly the business needs resolution). The matrix:

Priority codes (not to be confused with Biosafety Levels):

• P1 (Critical): Production down, major business impact. Immediate response, all hands.
• P2 (High): Significant service degradation. Fast response, escalation ready.
• P3 (Medium): Partial impact, workaround available. Normal SLA response.
• P4 (Low): Minimal impact, cosmetic or edge case. Can be scheduled.

Escalation

The process within incident and service request management used to transfer issues to higher levels of authority or expertise when they cannot be resolved within normal, front-line support procedures.

When should we escalate ? When the incident exceed SLA timeframes, require higher expertise, or need more management authority.

There are 2 types:

• Functional escalation: pass to someone with more technical expertise
• Hierarchical escalation: involve management when impact warrants it or when SLA breach is imminent

A crisis is when an incident has business-wide consequences that require executive involvement. Knowing when a P1 becomes a crisis (and who to call) should be documented before the crisis, not during it.

Problem management

Problem management is the practice responsible for managing the lifecycle of problems — the underlying causes of incidents. Where incident management asks "how do we restore service?", problem management asks "why did this happen, and how do we prevent the next one?"

The two practices are deliberately separate. Conflating them is one of the most reliable ways to spend your career fixing the same incident on a loop.

The problem lifecycle

1. Detection — from incident trends, monitoring alerts, or staff observation
2. Logging — create a problem record, link to related incident(s)
3. Categorization — which service? which component?
4. Prioritization — frequency × impact of the incidents it causes
5. Investigation — root cause analysis (5 Whys, Fishbone diagram, timeline reconstruction)
6. Resolution — either a permanent fix (closes the problem) or a workaround (creates a known error record and keeps the problem open)
7. Closure — documented, linked to any changes raised to permanently fix it

A known error is not a failure state. It means you've investigated, identified the root cause, and documented a workaround. Anyone who hits the same incident now resolves it in minutes instead of hours. The problem stays open until the permanent fix ships.

Root cause analysis tools

• 5 Whys: ask "why?" five times in sequence. Stop at the systemic cause, not the immediate trigger. "The server crashed" is an event. "The deployment process has no memory limit check" is a root cause.
• Fishbone (Ishikawa) diagram: map contributing factors across categories (People, Process, Technology, Environment) to avoid anchoring on the first obvious suspect.
• Timeline reconstruction: rebuild the sequence of events from logs, alerts, and operator notes. Frequently reveals that the "incident" started hours before anyone noticed.

Service request management

Service request management handles predefined, pre-approved requests from users. Nothing is broken (that's an incident), and nothing unexpected is being modified in the IT environment (that's change enablement). These are expected, routine interactions between users and the IT team.

Examples: new user account, software installation, password reset, access to a shared folder, equipment request.

The key property: pre-approved

Every item in the service catalog has already been assessed for risk and policy compliance. When a user submits a service request, the IT team fulfills it — they don't re-assess it. This is why the service catalog matters: without it, every request is treated as novel, lands in someone's inbox, and creates invisible coordination overhead.

The automation case

Service requests represent the highest automation opportunity in the entire ITIL framework. If a request is genuinely predefined, low-risk, and repeatable, a human approving it manually every time is waste. Password resets, account provisioning, access to pre-approved groups — these can and should eventually be automated.

The path: design the process → document it → automate it. Automation without a clean process just speeds up a mess. This is guiding principle 7 applied directly: optimize first, then automate.

A mature service catalog has two properties: it is exhaustive (users can find everything IT actually offers) and increasingly self-service (as many requests as possible can be fulfilled without human intervention). Neither property is achieved on day one, but both should be the explicit direction of travel.

What kind of ticket is this?

In daily IT operations, the most common source of friction is not the absence of a practice — it is not knowing which practice applies. Is this broken thing an incident or a problem? Is this request a service request or a standard change?

Change enablement

Change Enablement manages the lifecycle of all changes to maximize the probability of success and minimize disruption.

ITIL v4 recognizes 3 change types:

The CAB (Change Advisory Board)

The CAB is a group that reviews and authorizes significant normal changes. Typical members: IT operations, security, business stakeholders, and the change owner. The CAB doesn't exist to slow things down, it exists to catch problems before they become incidents. It is the organizational mechanism that prevents the finance team from being unable to run payroll on a Friday.

A proper CAB dossier for a normal change includes:

• Impact: which services, users, and systems are affected?
• Risk: what's the probability of failure, and what's the impact if it fails?
• Rollback plan: how do we revert cleanly if the change fails? (Tested rollback, not theoretical)
• Post-implementation review: how do we verify success after deployment?

Continual improvement

Continual improvement is both a guiding principle and a dedicated practice in ITIL 4. It ensures the organization continuously improves its services, practices, and the SVS itself.

The Continual Improvement Register (CIR) is the operational tool: a log of all improvement ideas, their status, priority, and outcomes. Think of it as a backlog specifically for operational improvements, not features, not incidents, but how we work.

The 7-Step improvement model

This model is cyclical by design. Reaching step 7 doesn't mean you're done, it means you start over with a new vision.

Measuring improvement: SLA vs XLA and beyond

SLA vs XLA deserves its own paragraph. An SLA measures what the system does (was uptime ≥ 99.9%?). An XLA measures how the user felt about it. You can meet every SLA and still have furious users, because the system was slow even within the threshold, or the error messages were unhelpful, or the support experience was frustrating. XLAs align IT metrics with actual business outcomes, not just technical compliance.

3 Axes of improvement

• Strategic: organization-wide, long-term (e.g., "reach 95% automated change deployment by end of year")
• Tactical: team/process level, medium-term (e.g., "reduce MTTR on P1 incidents by 40% this quarter")
• Operational: day-to-day (e.g., "update the incident categorization taxonomy this sprint")

Governance and Risk Management

Governance sits at the top of the SVS. It provides direction and ensures the organization stays aligned with its objectives and obligations. Three functions:

• Direct: Set strategy, policies, and organizational objectives
• Evaluate: Assess organizational performance, risks, and compliance
• Monitor: Track adherence to policies and verify outcomes

For service management, governance ensures that the SVS is accountable: decisions are traceable, risks are understood, and exceptions are handled systematically.

Risk Management in ITIL follows a straightforward formula:

Risk = Probability × Impact

Three responses:

1. Mitigate: reduce probability or impact (implement redundancy, add monitoring, require peer review)
2. Transfer: shift the risk to another party (insurance, contractual SLAs with vendors, outsourcing)
3. Accept: acknowledge the risk and decide to live with it (for low probability, low impact scenarios)

Risk isn't inherently bad. The problem is unacknowledged risk, for example: changes deployed without a risk assessment, dependencies unknown until they fail, vulnerabilities known but not documented. Risk management doesn't eliminate uncertainty; it makes it visible and traceable.

ITIL 4 ↔ Agile, DevOps, Lean

One of the major improvements in ITIL v4 over its predecessors is the explicit integration with modern practices. The framework doesn't compete with DevOps or Agile. It provides the governance layer that makes them sustainable at scale.

The official ITIL 4 and DevOps resources make the integration case explicitly. The short version: ITIL handles governance and accountability; DevOps handles speed and flow. You need both. Speed without governance creates chaos. Governance without speed creates bureaucracy. ITIL v4 was redesigned precisely to not be the bottleneck.

Case study

Here is what ITIL v4 looks like applied to a real IT direction inside a biomedical research center in Senegal. Any resemblance to real persons, living or dead, is purely coincidental.

Part 1 — Service catalog

The official list of what the IT direction provides, to whom, under what terms. It is the operational contract between the IT team and the rest of the organization. Without it, users don't know what to ask for, IT doesn't know what they're accountable for, and incidents pile up in a shared mailbox nobody consistently monitors.

Below: 5 services covering the majority of what a research institute IT direction actually handles day-to-day.

Part 2 — RFC & CAB Dossier: LIMS major version upgrade

A Request for Change (RFC) is the formal input to the Change Enablement practice. For a Normal or a Major change, it triggers a full CAB review before any action is taken. Here is what a complete dossier looks like.

Context: The institute uses a LIMS (Laboratory Information Management System) to track samples, tests, and results across all its labs. The vendor has released version 4.0, which drops support for the current version 3.x at end of year. The upgrade is not optional, but it touches sample data, active test runs, and integrations with the syndromic surveillance platform.

RFC identification

Justification

The current LIMS v3.x reaches vendor end-of-life on 2026-12-31. After that date: no security patches, no bug fixes, no vendor support. Version 4.0 also introduces a native REST API required by the next release of the syndromic surveillance platform. This change is driven by compliance (security posture) and technical dependency (surveillance platform roadmap) simultaneously.

Impact assessment

Risk assessment

Implementation plan

Hard rollback decision point: Sunday 04:00. If not complete and validated by then, rollback is initiated regardless of progress. No exceptions — the lab opens at 07:30.

Rollback procedure

Triggered if: any required checkpoint fails and cannot be resolved within 30 minutes, OR the 04:00 hard deadline is reached.

1. Stop all LIMS application services on both nodes
2. Drop the migrated database: dropdb lims_production
3. Restore from the pre-migration dump: pg_restore -d lims_production /backup/lims-premig-20260523.dump
4. Verify integrity: compare row counts for samples, tests, results tables against the pre-migration snapshot
5. Redeploy the v3.8 package from artifact registry on both nodes
6. Restart application services, verify cluster health
7. Remove maintenance mode, run the same smoke test suite
8. Notify all stakeholders: rollback completed, root cause analysis scheduled Monday

Estimated rollback duration: 45 minutes. The 04:00 decision point leaves 2.5 hours of margin before lab opening.

Communication plan

Post-implementation review

Scheduled: Monday 2026-05-25, 10:00 / 30 minutes. Attendees: IT Ops lead, application owner, one representative per affected lab department.

Agenda:

1. Did deployment complete within window? If not: what caused the overrun?
2. Were all required checkpoints met? Document any deviations or waivers.
3. User-reported issues since go-live (collected Monday morning, before the review)
4. Was rollback triggered? If yes: full root cause analysis before next major change
5. Were Application Support SLAs met during the post-go-live monitoring period?
6. Update the LIMS runbook with any new procedures discovered during the upgrade
7. Close RFC-2026-014 in the ITSM tool; status: Successful or Successful with deviations

The output feeds directly into the Continual Improvement Register: anything harder than expected, any gap in the rollback procedure, any user adoption friction; logged as improvement items before the next major change.

Maturity baseline

Before selecting practices to implement, identify where your organization currently stands. The goal is not to jump to level 5 — it is to take the next step from wherever you are.

Quick self-assessment

Answer each question — each "yes" adds one point:

1. Does every IT request, incident, and change go through a single tracked system — and does the team use it consistently?
2. Can any user in your organization find, in under 2 minutes, what IT offers and how to request it?
3. Is there a process by which the IT team communicates planned changes to affected users before they happen?
4. After a major incident, does the team systematically document what happened and what will prevent recurrence?
5. Is there a maintained list of known improvement items, reviewed at least monthly?

Tooling

No tool enforces ITIL by itself. The process has to exist first, the tool just reduces friction. That said, the right tooling makes the difference between a practice that lives on paper and one that teams actually follow.

A word on scope: ServiceNow is the de facto enterprise standard and covers nearly everything in the table below. It is also expensive, slow to configure, and overkill for most organizations below a few hundred IT staff.

The open source column below deserves serious consideration. GLPI in particular covers incident, change, CMDB, and knowledge management in a single self-hosted package.

If you're under 50 staff, start with GLPI and Prometheus — everything else is optional.

Where does this break down?

ITIL v4's reputation for bureaucratic theater doesn't come from the framework itself — it comes from predictable patterns in how organizations implement it. Here are the failure modes that appear most often.

The CAB becomes a bottleneck — or a rubber stamp

The CAB fails in two symmetric ways:

• Bottleneck mode: every change, including routine low-risk ones that should be standard, gets queued for a weekly meeting nobody prioritizes. Teams start bypassing the process because it costs more than it saves. Shadow changes accumulate.
• Rubber stamp mode: the CAB meets, approves everything without real scrutiny, and provides no value beyond a compliance checkbox. Teams stop writing quality RFC dossiers because nothing ever gets challenged.

Both paths lead to the same outcome: the CAB becomes theater rather than governance.

The fix is structural: ruthlessly classify standard changes and remove them from CAB scope entirely. The CAB should only review changes that genuinely require multi-stakeholder risk assessment. If your CAB is reviewing password resets, something went wrong in the classification step.

The Continual Improvement Register becomes a graveyard

The CIR is a backlog of improvement items. In organizations that implement it but don't maintain it, it becomes a list of things that were logged and then forgotten. Items accumulate, nobody assigns owners, nothing gets closed. Teams stop logging new items because they've learned nothing will happen anyway.

The CIR needs a review cadence — monthly minimum — and every item needs an owner and a target date. An improvement item without both is a wish, not a commitment. Treat the CIR like a product backlog: prioritize, assign, close.

SLA gaming

SLAs create a metric. Metrics can be gamed. Common patterns:

• Tickets closed prematurely to hit the response time target, then re-opened when the user escalates.
• Tickets parked in "pending user response" status indefinitely to pause the SLA clock.
• Categorization manipulation to assign a lower priority with a more comfortable deadline.

The result: SLA compliance looks good on the dashboard while user satisfaction is deteriorating. This is exactly the gap XLAs were designed to expose. If your SLA compliance is consistently high but users are visibly unhappy, check whether the metric is being measured honestly.

Incident and problem management conflate

The same incident gets resolved for the fourth time this month. Each resolution was logged. Each SLA was met. Nobody opened a problem ticket after the second occurrence. Root cause never investigated. The team is fully occupied fixing the same thing repeatedly — which is the opposite of continual improvement.

The fix is a threshold rule: any incident that recurs more than N times in a rolling period automatically generates a problem ticket. That threshold is a policy decision. Make it explicit, write it down, enforce it.

Tool-first implementation

An organization buys ServiceNow (or its equivalent), then tries to configure it to match existing informal processes. The tool enforces workflows. The workflows don't match how people actually work. Adoption fails. The tool gets blamed.

The correct sequence: define the process → document it → configure the tool to support it. A tool reduces friction in a process that already works; it cannot substitute for the process.

ITIL as compliance theater

The organization implements ITIL because an audit requires it. Forms are filled out. Tickets are opened and closed on schedule. SLA reports are generated. Nobody reads them. The framework exists on paper while informal processes continue in parallel.

The diagnostic: if you can't name three specific problems that ITIL practices solved in the last quarter, your implementation is theater. Pick one practice, one pain point, one measurable outcome. Get that working — visibly, demonstrably — and then add the next one.

ITIL 4 for Python/Django developers

If you write Django code daily, you've been doing service management without the vocabulary. ITIL names the disciplines you're already practicing — informally, inconsistently, and often without the parts that matter most.

Django migrations = Normal Changes

Every python manage.py migrate on production is a Normal Change. It touches persistent data, may be irreversible without preparation, and if it fails mid-run it can leave the schema in an inconsistent state. The RFC dossier for a non-trivial migration:

• Impact: which tables change? which queries might break?
• Risk: additive (low), destructive (high), or data backfill (variable)?
• Rollback plan: python manage.py migrate <app> <previous> — tested on staging, not theoretical.
• Post-implementation check: verify row counts, run smoke tests, watch error rate for 15 minutes.

The developers who skip the staging rollback test are the ones who spend their Saturday recovering a production database.

Management commands = Standard Changes

createsuperuser, collectstatic, clearsessions — predefined, low-risk, documented. They belong in your service catalog as standard changes: run by following the procedure, log the run, no CAB review needed. The moment a management command touches financial data, research records, or performs an irreversible bulk operation, it graduates to a Normal Change and needs a dossier.

The CI/CD pipeline is Change Enablement in code

Your GitHub Actions or GitLab CI pipeline is an automated CAB. Each stage is a checkpoint:

A merge gate that requires all checks to pass is the automated equivalent of CAB approval for standard changes. You've been calling it "CI/CD." What ITIL adds: the rollback plan needs to be tested, not just written. A git revert is not a rollback plan if you've never run it against a production data snapshot.

Sentry + structured logging = Incident identification

The 7-step incident lifecycle starts with identification. In a Django application:

• LOGGING config with structured output → categorizable, searchable logs
• Sentry alert → automated identification (lifecycle step 1)
• Sentry error grouped by fingerprint → categorization (step 3)
• Error rate + affected user count → prioritization (step 4)
• /health endpoint returning degraded → warranty failure visible to monitoring

python manage.py check --deploy is the pre-deployment checklist equivalent — it catches misconfigurations before they become incidents. Running it in CI is reasonable. Skipping it is how DEBUG=True ends up in production.

The postmortem = Problem management

After a production incident: the service is restored, the incident is closed. Problem management starts now.

1. git log --since="48 hours ago" + deploy history — what changed before the incident?
2. Reconstruct the timeline from Sentry, structured logs, and deploy timestamps
3. Apply 5 Whys to the root cause — stop at the systemic failure, not the immediate trigger
4. Create a problem ticket with the root cause documented
5. If a workaround exists before the permanent fix ships, log a known error record
6. The permanent fix becomes a Normal Change with a rollback plan

A GitHub issue tagged post-incident with root cause, workaround, and fix plan is a perfectly adequate known error record. The tool doesn't matter; the discipline does.

Value = Utility × Warranty, in code

• Utility (fit for purpose): does the feature solve the actual user problem? Test coverage verifies your code does what you wrote. It cannot verify you wrote the right thing. Developers who never talk to users are building on assumptions they haven't tested.
• Warranty (fit for use): test coverage + CI pass + staging smoke test + error rate within SLO after deploy. A feature that works in CI and silently corrupts data in production has warranty = 0.

The developer temptation is to optimize for utility (shipping features) while treating warranty as someone else's problem. ITIL's value equation makes the trade-off explicit: both factors are required, and a zero on either side collapses the value entirely.

ITIL v5

We've been taught during the training ITIL v5 was launched in february 2026. I tried to watch this video to have an overview of what is ITIL v5. The only thing I understood was: "The new pace of changes today driven by cloud, ai, digital products, experience-focused services, demand a new way of thinking." ITIL v5 answers that need. Phew!

Conclusion

ITIL v4 is a framework providing a vocabulary and a structure for conversations your organization was probably already having informally: Who decides what gets changed? How do we prioritize when everything is on fire? How do we know we're actually improving?

The most valuable takeaways from this training:

1. Value is co-created, not delivered. You can deploy perfect infrastructure and still fail if users can't get value from it.
2. SLA ≠ user happiness. XLAs measure what actually matters to the business.
3. ITIL v4 and DevOps are complementary. ITIL provides the accountability layer that makes continuous delivery safe at organizational scale.
4. Adopt and adapt. Apply the practices that solve real problems, and leave the rest on the shelf until you need them.

If your systems go down and nobody knows who to call, what changed yesterday, or how long things have been broken, that's not a technical problem. That's a service management problem. ITIL v4 gives you the vocabulary to fix it.

More on this topic

Congratulations, you made it to the end. If you enjoyed this, please like, share & subscriiiibe. You might also like my amazing post about AWS fundamentals or how I'm helping save lives in West Africa using free software.

This article is a summary of a three-day training course. Impossible to explore all the aspects of ITIL v4 in such a short post. Here are some useful links to lean more:

• ITIL 4 official certification path
• ITIL 4 Guiding Principles explained
• 34 ITIL 4 management practices
• What are XLAs and how do you use them?
• The Phoenix project
• Biosafety Levels

Even more:

• Apollo 13 – An ITSM Case Experience (GamingWorks)
• GameChangingInsight ITIL simulations
• ITIL v4 quiz (open source)
• Purple Griffon ITIL 4 quiz
• Career Smarter mock exam
• PeopleCert official sample questions
• Career Smarter mock exam