ITIL 4 Foundation
Every other certification on this course's list is about proving you can run a reliable system. ITIL 4 Foundation is about something adjacent and, for a lot of readers, more immediately useful: proving you can speak the vocabulary a large, traditional enterprise is already speaking before you ever showed up with an SLO. ITIL — Information Technology Infrastructure Library — is the world's most widely adopted IT service-management framework, and it predates SRE by roughly two decades. It has its own words for "something broke" (Incident), its own word for "we found out why" (Problem), and its own gate for "we're changing production" (Change Enablement, historically enforced by a Change Advisory Board). None of those words are wrong. They're just not SRE's words, and in an ITSM-heavy organization — a bank, an insurer, a hospital system, most government contractors — they were there first. This page covers what ITIL 4 Foundation actually is and tests, the model underneath it, and — because this is an SRE course, not an ITSM one — exactly where its vocabulary and SRE's collide, nowhere more sharply than at the CAB gate versus an error-budget-gated release.
Imagine a big hospital running two rulebooks at once. The first is the hospital-wide policy manual: how any request — a leaking radiator, a full power outage, a broken elevator — gets logged, who has to sign off before a wall gets knocked down, and an agreed definition of "incident" versus "problem" so fifty different departments mean the same thing when they use those words. That's ITIL: one shared vocabulary and workflow for the whole organization, not just the software engineers. The second is the trauma team's own playbook: who's in charge in the first ninety seconds of a crisis, and a hard number, agreed in advance, for how much risk they're allowed to take on this month before they stop scheduling elective surgery and stabilize the ward instead. That's SRE. Big, older companies are usually already running the hospital-wide manual by the time an SRE team shows up and tries to install the trauma team's playbook on top of it — and the argument that starts is almost always the same one: does a committee vote on this risk, or does a number decide it automatically? This page is about walking into that argument on purpose, instead of losing it by accident.
What ITIL 4 is, who publishes it, and who actually sits this exam
☺ Like you're 10: A UK government agency wrote a rulebook for running IT departments in the late 1980s. It's been rewritten three times since, a private exam company now owns it outright, and the newest version quietly borrowed a lot of Agile and DevOps thinking.
ITIL — originally an acronym for Information Technology Infrastructure Library — began as a set of books published by the UK government's Central Computer and Telecommunications Agency (CCTA) in the late 1980s, describing good practice for running IT operations. It has been substantially rewritten roughly once a decade since: ITIL v2 (2001), ITIL v3 (2007, refreshed in 2011), and ITIL 4, published in February 2019, which is the version this exam tests. Ownership of the framework has consolidated sharply along the way. The scheme moved from the UK government's OGC to a joint venture called AXELOS in 2013, and PeopleCert — the same exam body this course's own SRE Practitioner page names as the parent of the DevOps Institute — acquired full ownership of AXELOS in 2021, two years before it went on to acquire DevOps Institute as well. Practically, that means one company now examines and certifies both ITIL and the DevOps Institute's SRE-flavored credentials, on the same exam platform, under the same continuing-education machinery — worth knowing before you assume the two badges come from unrelated worlds.
ITIL 4 is not a light edit of ITIL v3. It replaced v3's rigid, sequential "processes" — Incident Management the process, Change Management the process — with more flexible "practices" assembled around a new four dimensions model and a Service Value System, discussed in full below. The rewrite was a direct response to a specific criticism: ITIL v3 was built for a world of scheduled releases and document-heavy sign-offs, and it aged badly against cloud-native, continuously-deployed software. ITIL 4 was deliberately redesigned to absorb Agile and DevOps thinking rather than stand opposed to it — a fact worth holding onto, because "ITIL is the old, slow framework SRE replaced" is an accurate description of ITIL v3's reputation and an outdated one for ITIL 4 itself, a point this course's own SRE, Other Frameworks & the Future module makes at more length.
Foundation is genuinely broad in its intended audience — service desk agents, IT operations managers, change and problem managers, ITSM tool administrators (ServiceNow, Jira Service Management, and similar), business analysts, and project managers all sit it, usually because their employer mandates it organization-wide rather than because any one of them chose it individually. For the reader of this course specifically, it earns its place on this page for a narrower reason: if you're an SRE or platform engineer who lands inside, or has to negotiate with, an organization that already runs formal ITSM tooling and process, Foundation is the fastest way to learn the vocabulary you'll be handed whether you study it or not — the words on the change-request form, the fields in the "problem record," the acronym everyone in the CAB meeting already knows.
ITIL 4 Foundation tests whether you know the vocabulary and model of IT service management as a general discipline. It contains no mention of SLIs, error budgets, canary releases, or blameless postmortems by those names — those are SRE's own vocabulary for solving some of the same problems ITIL describes more generally, and in some cases for solving problems ITIL doesn't address at all. Passing it proves you can navigate an ITSM-run organization's language. It says nothing about whether you can build or operate a reliable production system — that's every other page on this course.
The ITIL 4 model: four dimensions, the Service Value System, and seven guiding principles
☺ Like you're 10: One big picture — the Service Value System — holds five moving parts, and every part gets checked against four different angles you're not allowed to forget: people, tech, suppliers, and the actual flow of work.
Everything in ITIL 4 sits inside the Service Value System (SVS), which the syllabus breaks into five components. Guiding principles are the seven recommendations, below, that shape every decision. Governance is how the organization is directed and controlled. The service value chain is the operating model — six activities that combine and recombine to turn demand into value. Practices are the 34 sets of organizational resources — covered next — that get pulled into those activities as needed. And continual improvement is a thread running through all of it, not a separate step at the end.
Layered across the whole SVS is the four dimensions model — four angles ITIL insists you check any service design against, so a solution that looks complete from one angle doesn't quietly fail from another:
| Dimension | What it forces you to ask |
|---|---|
| Organizations and people | Roles, responsibilities, culture, staffing — does anyone actually own this, and are they equipped to? |
| Information and technology | The tooling, data, and knowledge the service depends on — including, explicitly, automation. |
| Partners and suppliers | Every relationship the organization depends on but doesn't fully control — vendors, cloud providers, outsourced support. |
| Value streams and processes | How work actually flows end to end — the steps, handoffs, and controls between "someone wants this" and "someone has it." |
All four dimensions sit inside external factors ITIL borrows the acronym PESTLE for — Political, Economic, Social, Technological, Legal, Environmental — constraints the organization doesn't control but has to design around regardless.
The service value chain (SVC) is the six activities that convert demand into value, and the ITIL 4 idea worth remembering here is that practices are not mapped one-to-one onto these activities — a single practice like Incident Management gets pulled into several SVC activities depending on context, and a single activity like Deliver & Support draws on many practices at once.
| SVC activity | In one line |
|---|---|
| Plan | Shared understanding of vision, status, and improvement direction across the organization. |
| Improve | Continual improvement of products, services, and practices — every activity's ongoing companion. |
| Engage | Understanding stakeholder needs and maintaining relationships with customers, users, and partners. |
| Design & transition | Turning requirements into products and services that meet quality, cost, and time-to-market expectations. |
| Obtain/build | Ensuring the service components — developed, purchased, or reused — are available when and where needed. |
| Deliver & support | Ensuring services are delivered and supported to agreed specifications and stakeholder expectations. |
Finally, the seven guiding principles — the closest thing ITIL 4 has to a philosophy, and the piece most study guides underweight relative to how often the exam leans on them:
| Guiding principle | What it means in practice |
|---|---|
| Focus on value | Everything traces back to value for some stakeholder — if it doesn't, question why you're doing it. |
| Start where you are | Don't discard what already works to build something new from scratch; assess the current state honestly first. |
| Progress iteratively with feedback | Resist the urge to do everything at once; small steps with feedback beat one big-bang change. |
| Collaborate and promote visibility | Work across boundaries, and make work and decisions visible rather than siloed. |
| Think and work holistically | No practice or dimension operates in isolation — a change to one ripples into the others. |
| Keep it simple and practical | Use the minimum number of steps to accomplish an objective; complexity that doesn't add value is a cost. |
| Optimize and automate | Maximize the value of human effort — automate wherever it's technically feasible and cost-effective first. |
Hold onto that last one. "Optimize and automate" is the guiding principle that does most of the work later on this page, when the conversation turns to whether ITIL actually mandates a slow, human Change Advisory Board for everything — it doesn't, and this principle is the textual proof.
The 34 practices — and the dozen or so Foundation actually goes deep on
☺ Like you're 10: ITIL names 34 practices split into three families; Foundation expects you to know the purpose of roughly a third of them, and only a handful in real depth.
ITIL 4 organizes its practices — the "toolboxes" of activities, techniques, and resources practitioners draw on — into three families totaling 34:
| General management (14) | Service management (17) | Technical management (3) |
|---|---|---|
| Architecture Management Continual Improvement Information Security Management Knowledge Management Measurement & Reporting Organizational Change Management Portfolio Management Project Management Relationship Management Risk Management Service Financial Management Strategy Management Supplier Management Workforce & Talent Management | Availability Management Business Analysis Capacity & Performance Management Change Enablement Incident Management IT Asset Management Monitoring & Event Management Problem Management Release Management Service Catalogue Management Service Configuration Management Service Continuity Management Service Design Service Desk Service Level Management Service Request Management Service Validation & Testing | Deployment Management Infrastructure & Platform Management Software Development & Management |
Foundation does not expect equal depth on all 34. The published syllabus draws a clear line between practices you must explain "in detail" and practices you only need to know the purpose of. The practices most consistently named for detailed coverage are Continual Improvement, Change Enablement, Incident Management, Problem Management, Service Request Management, and Service Desk; a further set — most commonly Service Level Management, IT Asset Management, Monitoring and Event Management, Release Management, and Deployment Management — is examined at purpose-only depth. Third-party prep material cites the total named-practice count anywhere from 11 to 18 depending on which syllabus revision it was written against, so treat the split above as the stable core rather than a definitive list, and pull the current official syllabus PDF before you build a study plan around it.
Where ITIL's vocabulary collides with SRE's — Incident, Problem, Change, and Service Level
☺ Like you're 10: ITIL and SRE both have words for "something broke" and "we promised a target" — they were built for different reasons, and the two vocabularies don't line up as cleanly as people assume.
This course's own SRE, Other Frameworks & the Future module covers this comparison as one section among several; this page exists to go a level deeper specifically on the practices Foundation itself examines, since that's the vocabulary you'll actually be handed in a CAB meeting or a change-request form.
| ITIL practice | ITIL's own mechanism | SRE's nearest mechanism | The real difference |
|---|---|---|---|
| Incident Management | Restore service fast; priority scored by an Impact × Urgency matrix; a separate Major Incident procedure for the worst cases | Incident management & on-call, incident command | ITIL scores severity mostly by judgment against the matrix; SRE additionally ties severity to a measured trigger — multi-window, multi-burn-rate error-budget consumption — rather than judgment alone. |
| Problem Management | Root-cause analysis producing a Known Error in a Known Error Database (KEDB), often with a documented workaround while the underlying problem stays open | Blameless postmortems, Etsy's origin story | ITIL's problem management is process- and database-driven, and "blameless" isn't a stated requirement of the practice itself; SRE's postmortem is blameless by design and produces tracked, owned engineering action items reviewed by the team that ran the incident, not routed to a separate problem-management function. |
| Service Level Management | A negotiated SLA, reviewed on a calendar cadence — quarterly or annual service reviews are typical | SLIs, SLOs & error budgets | ITIL defines a target and reports against it. SRE's SLO is measured continuously against live telemetry, and an error-budget policy attaches an automatic, pre-agreed consequence the moment the budget hits zero — not at the next scheduled review. |
| Change Enablement | Changes classified Standard, Normal, or Emergency; Normal changes typically route through a Change Advisory Board (CAB) for authorization | Progressive delivery, error-budget-gated releases | Covered in full below — this is the sharpest collision on the page. |
| Monitoring & Event Management | Classify events as informational, warning, or exception, and route accordingly | Monitoring & observability, alert design & alert fatigue | ITIL's event categories are largely static and rule-based; SRE alerting is built to route on burn rate and to actively fight alert fatigue as a first-class design goal, not a side effect. |
| Continual Improvement | A general, org-wide Continual Improvement Register of improvement ideas | Toil & automation, measuring reliability | ITIL frames improvement generically across the whole organization; SRE operationalizes the same instinct narrowly and numerically — an explicit toil ceiling (roughly 50%) and a quantified SLO trend, not a general-purpose register entry. |
Change Enablement versus an error-budget-gated release
ITIL's Change Enablement practice sorts every change into one of three types. A Standard change is pre-authorized, low-risk, well-understood, and documented once — a password reset, a routine disk-space increase — and executed repeatedly without individual review. A Normal change needs assessment and authorization from a change authority, which in most real organizations means it's scheduled for review by a Change Advisory Board: a standing group, often meeting weekly, that evaluates risk, checks for conflicts, and votes to approve or reject. An Emergency change gets fast-tracked through an abbreviated version of the same authorization, because the risk of not changing now exceeds the risk of skipping the full process.
SRE's answer to the same underlying question — how much risk is this change allowed to carry right now? — replaces the committee vote with a number and a pipeline. Automated tests and a canary rollout replace the change-request form's risk description. A live error-budget check replaces the CAB's judgment call: if the service has budget left, the release proceeds automatically; if it doesn't, new releases are blocked by policy until the budget recovers, no meeting required. Progressive delivery & release engineering covers the mechanics — canaries, feature flags, automated rollback — that make this substitution possible.
The caricature of ITIL as a framework that mandates a slow human committee for every change is a real description of how many organizations implemented ITIL v2 and v3 — and an inaccurate one for ITIL 4's own published guidance. ITIL 4's Optimize and automate guiding principle, above, explicitly directs practitioners toward automating standard changes and streamlining authorization wherever it's technically feasible; ITIL 4 does not require a CAB vote for every change, and encourages exactly the kind of automated, policy-driven gating an error budget provides. The friction described on this page is real and worth understanding — but it's more often an artifact of how a specific organization implemented change management a decade ago than a requirement written into the current framework. Don't win the argument by attacking a version of ITIL that isn't the one your CAB is actually using — attack the implementation, not the text.
The sharpest single gap in the table above isn't Change Enablement — it's Service Level Management. ITIL's practice defines an SLA target and reports against it. Nothing in the practice itself mandates an automatic, pre-agreed consequence the moment that target is missed. SRE's error-budget policy is precisely that missing enforcement mechanism: the target exists in both frameworks; the "and here's exactly what happens when you blow it" clause is SRE's own invention.
Format, cost, and prerequisites — verify before you book
☺ Like you're 10: Forty questions, an hour, closed book, roughly two-thirds right to pass — and unlike most credentials on this course's list, the certificate itself doesn't expire.
The table below reflects what PeopleCert and its accredited training organizations generally publish for ITIL 4 Foundation. Treat every figure as a planning aid rather than a source of truth — price, exact timing accommodations, and delivery options vary by region and training bundle, and this exam family has changed publisher and pricing structure within the last few years.
| Item | What's generally published |
|---|---|
| Issuing body | PeopleCert, under the ITIL/AXELOS brand it owns outright |
| Format | Multiple choice, closed book, online-proctored or at an accredited test center |
| Questions | 40 |
| Duration | 60 minutes standard; commonly reported extended time (often around 25% extra) for candidates sitting in a non-native language — confirm the current policy at booking |
| Passing score | 65% — 26 of 40 questions correct |
| Price | Widely variable by region and whether training is bundled — commonly cited in the low-to-mid hundreds of US dollars for an exam-only voucher, more with an accredited training course attached; do not treat any single figure here as current |
| Prerequisites | None formally required — Foundation is the entry point to the whole ITIL 4 scheme |
| Validity | Commonly described as not expiring at the Foundation level itself — unlike the higher-tier Managing Professional and Strategic Leader designations, which sit inside PeopleCert's continuing-education (CPD) scheme once you hold them. Policy here has shifted before; confirm it hasn't shifted again. |
| Languages | Offered in a wide range of languages given how globally the framework is adopted; confirm current availability for yours |
Price, exact time accommodations, delivery options, and validity policy all change without much announcement, and this page is an independent, unofficial snapshot rather than a live feed. Confirm current details on PeopleCert's own site and AXELOS, the brand PeopleCert now owns outright, before you register — search for "ITIL 4 Foundation" directly on either, since exact page paths for certification programs move more often than the programs themselves.
Should an SRE take it — and how it maps onto this course
☺ Like you're 10: Worth it if you're about to work inside a company that already runs this vocabulary everywhere. Skip it if nobody around you has ever said "raise a change ticket."
Take it if…
You're moving into, or already work inside, a large ITSM-heavy organization — a bank, an insurer, a hospital system, a government contractor, or any enterprise running ServiceNow or an equivalent as the backbone of how work gets approved. Foundation is the fastest way to learn the vocabulary you'll be handed regardless of whether you study it: the fields on the change-request form, what a "problem record" actually is, why the CAB meets on Thursdays. You're being asked to sit in CAB meetings or write problem records yourself — showing up able to speak the room's language, rather than translating on the fly, changes how seriously an SRE's error-budget argument gets taken. Procurement, compliance, or a specific framework requires it — vendor questionnaires and some public-sector tenders count certified staff, and ITIL-shaped organizations recognize PeopleCert paperwork instantly; usually paid for by someone other than you.
Skip it if…
You work at a cloud-native shop with no ITSM tooling in sight — the vocabulary this exam teaches has no organization around you to speak it back. You've already internalized Google's SRE book and this course's own material — the exam will mostly test whether you can translate concepts you already practice daily into a different, older vocabulary, which is a real but narrow skill. You're optimizing for a hands-on, engineering credential instead — nothing here is graded on a live system; this course's own CKA and certifications hub pages point toward credentials that actually test operational skill under a clock.
If you do sit it, most of what you're actually studying already has a home on this course, filed under different page titles:
| ITIL Foundation territory | Read on this course |
|---|---|
| Incident Management, Service Desk | Incident management & on-call · Incident command for large-scale incidents |
| Problem Management | Postmortems & blameless culture · Etsy & the origin of blameless postmortems |
| Service Level Management | SLIs, SLOs & error budgets · SREF Module 2 blueprint |
| Change Enablement, Release & Deployment Management | Release engineering & progressive delivery |
| Monitoring & Event Management | Monitoring & observability · Alert design & alert fatigue |
| Continual Improvement, Measurement & Reporting | Toil & automation · Measuring & reporting reliability |
| IT Asset Management, Service Financial Management | Reliability economics |
| ITIL and other frameworks compared to SRE, in full | SRE, Other Frameworks & the Future |
| Vocabulary lookup | Glossary |
Pick one real practice your own team already runs — a change-approval step, an on-call rotation, a weekly ops review. Write it out twice: once using ITIL's vocabulary (which practice is this, and what would a CAB ask about it?), once using SRE's (what SLO or error-budget policy governs it, and what's the automated consequence if it's breached?). If one of the two translations comes up empty — you can describe the ITIL side but not the SRE mechanism, or the reverse — that gap is exactly the kind of blind spot this page exists to close before someone in a CAB meeting finds it for you.
Where ITIL sits next to this course's own certifications
☺ Like you're 10: This one teaches you a whole organization's shared words. The others teach you either SRE's specific words, or how to actually keep a system running — pick based on which gap you have.
Positioned against the rest of this course's certification list, ITIL 4 Foundation sits in a corner none of the others occupy: it's knowledge-based like SRE Practitioner and the SRE Foundation on this course's own certifications hub, but unlike either of those, it isn't about SRE practice at all — it's about the broader IT-service-management vocabulary an SRE team has to speak to the rest of a large organization, not the mechanisms the team uses internally. It shares nothing with the hands-on, performance-graded credentials on this list — CKA, Gremlin's chaos-engineering certification — which test whether you can operate a real system under a clock rather than whether you know a framework's terms.
If you're building out a credential plan rather than picking one exam in isolation: SRE Foundation first if you want the vocabulary this course itself is built around; CKA or a cloud-specific exam from the certifications hub if your gap is hands-on operational skill; and ITIL 4 Foundation specifically when your next role, or your current one, puts you in a room where "raise a normal change" and "get it past the CAB" are sentences people say without explaining them.
Benny the Beaver: New client, big insurance company. They want every deploy to go through something called a CAB before it ships. I nearly automated myself out of a job before I found out what that meant.
Professor Owl: Change Advisory Board. It's ITIL's version of the question our error-budget policy answers — how much risk is this change allowed to carry right now?
Foxy: So which one's right — a committee vote, or a number?
Timmy the Turtle: Wrong question. What does the committee actually check that our error budget doesn't? If the answer is "nothing," automate it and free the CAB's Thursday. If the answer is "a real thing — a compliance sign-off, a cross-team conflict our telemetry can't see" — keep the human step for exactly that, and automate everything else.
Benny the Beaver: Their standard changes are already pre-approved and skip the board entirely. It's only the risky ones that go to committee.
Professor Owl: Then they're closer to us than the stereotype suggests. ITIL 4 itself tells them to optimize and automate — the slow-committee-for-everything reputation is mostly what ITIL v3 organizations never finished updating.
Timmy the Turtle: Learn their words before you try to change their process, Benny. Nobody hands the pipeline keys to the person who can't say what a "problem record" is.
1. Who currently owns and publishes ITIL, and what changed about that ownership in 2021 — and again in 2023? 2. What are the exam format, question count, duration, and pass mark for ITIL 4 Foundation? 3. Name the four dimensions of ITIL 4's four dimensions model. 4. In ITIL's Change Enablement practice, what's the difference between a Standard, a Normal, and an Emergency change — and which one typically routes through a CAB? 5. What's the sharpest single gap between ITIL's Service Level Management and SRE's SLO/error-budget approach, and name one concrete SRE mechanism that fills it?
Check your answers
- PeopleCert owns and publishes ITIL today. In 2021, PeopleCert acquired full ownership of AXELOS, the joint venture that had held the ITIL scheme since 2013. In 2023, PeopleCert separately acquired the DevOps Institute — meaning the same company now examines both ITIL and this course's own SRE Foundation/Practitioner credentials.
- 40 multiple-choice questions, closed book, 60 minutes standard duration (commonly extended for non-native-language sittings), and a 65% pass mark (26 of 40 correct).
- Organizations and people; information and technology; partners and suppliers; value streams and processes — all surrounded by external PESTLE factors the organization doesn't control.
- A Standard change is pre-authorized, low-risk, and executed repeatedly without individual review. A Normal change needs assessment and authorization from a change authority — in practice, this is the one that typically routes through a Change Advisory Board. An Emergency change is fast-tracked through an abbreviated authorization because the risk of delay outweighs the risk of skipping the full process.
- ITIL's Service Level Management defines an SLA target and reports against it, but nothing in the practice itself mandates an automatic, pre-agreed consequence the moment that target is missed. SRE's error-budget policy is exactly that missing enforcement mechanism — for example, automatically blocking new releases the moment a service's error budget is exhausted, with no meeting required to trigger it.