Home › Study Guides › ITIL 4 Guiding Principles, Explained With Examples
The seven principles with a concrete workplace scenario for each — including what every one of them rules out.
The ITIL 4 guiding principles are seven recommendations: focus on value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically, keep it simple and practical, and optimise and automate. They apply to any decision, in any part of an IT organisation.
They read like fortune-cookie wisdom until you watch a team violate every one of them in the same meeting. That is the honest reputation of the guiding principles — generic advice on paper, written to be invoked in real decisions, and most IT teams break two or three without noticing. Unlike the practices, which belong to a domain such as incident management or change enablement, the principles apply to any decision regardless of which practice you are using or what team you are on. Foundation exam questions test whether you can match a described scenario to the correct principle, which means you need to understand what each one rules out, not just what it says.
Focus on value means everything the organisation does should trace back to value for some stakeholder, usually the customer but sometimes internal. That sounds obvious until you watch a team spend a quarter building a feature nobody downstream asked for because it was technically interesting. Picture an IT team that notices its internal dashboard is slow and spends two weeks optimising database queries nobody has complained about, while a genuinely painful onboarding delay for new hires goes unaddressed. Technically productive, but optimised for what was easy to measure rather than what stakeholders needed fixed.
Start where you are means not discarding what already works simply because it is old or unglamorous. Assess the current state honestly, including what is functioning, before deciding what to change. A new IT director joins and wants to replace the entire ticketing system in her first month, assuming the old one must be the problem. Starting where you are would audit the current system first, and might find the tooling is fine — the real bottleneck being that tickets sit unassigned for two days because there is no on-call rotation. Replacing the software would not have fixed that.
Progress iteratively with feedback recognises that big-bang changes are risky and hard to course-correct, while smaller iterations with real feedback loops catch problems while they are still cheap. Rather than rolling out a new self-service password reset tool company-wide overnight, a team pilots it with one department for a fortnight, gathers feedback on confusing steps, fixes the interface, then expands. Rolled out everywhere at once, those same confusing steps would have generated thousands of support tickets instead of a handful.
Collaborate and promote visibility addresses work done in silos, which tends to produce decisions nobody trusts and rework nobody wanted. It does not mean consensus on everything; it means the right people can see what is happening and weigh in before it is locked in. A security team quietly changes a firewall rule to close a vulnerability without telling the application team whose service depends on that port. The fix is technically correct and breaks production an hour later. A simple heads-up in a shared channel would have caught it.
Think and work holistically recognises that no part of a service exists in isolation. A change in one area ripples across the four dimensions — organisations and people, information and technology, partners and suppliers, value streams and processes — and ignoring that is how successful changes create new problems elsewhere. A company switches cloud storage vendors purely on lower unit price, without accounting for retraining support staff, the API differences that break three internal integrations, or the migration window's effect on customer-facing uptime. Sound in isolation; the holistic picture was never considered.
Keep it simple and practical means using the minimum number of steps to accomplish an objective, and removing complexity that is not earning its keep rather than preserving it out of habit. A change request form has fourteen required fields, most copied from a template built for high-risk infrastructure work, and is now used for every change including updating a support-page FAQ. Simplifying the form for low-risk changes while keeping the rigour for genuinely risky ones respects the principle without abandoning necessary control.
Optimise and automate is the one most commonly misunderstood, because automating everything sounds efficient but can lock in inefficiency if you skip the optimisation. Automating a bad process just makes it happen faster and at greater scale. A company automates its error-prone approval workflow for access requests exactly as-is, including the redundant three-person sign-off that was already the bottleneck. The workflow now runs faster while still adding two unnecessary days to every request. Cutting the approval chain to one accountable approver first, then automating, would have actually solved it.
The principles are not a standalone checklist. They are one component of the ITIL 4 service value system, sitting alongside governance, the service value chain, practices and continual improvement, and on the exam you sometimes need to tell a guiding principle question from a practice or value chain activity question, since the scenarios can look similar on the surface.
A few points worth settling. There is no required order — they are not sequential steps but independent considerations that apply simultaneously, and the exam will not ask you to list them in sequence. They are not the same as the four dimensions: the principles are decision-making recommendations, the dimensions are areas a service must account for. More than one principle often applies to a real situation, though exam scenarios are usually written to point clearly at one best answer, so look for the principle matching the specific detail described. And if you want a candidate for most-misapplied in real workplaces, optimise and automate wins comfortably.
The principles are short enough to memorise word for word, but that is not what the exam tests. It tests whether you can recognise which principle a described situation illustrates, which is a harder skill than recall and exactly what varied-scenario flashcard practice builds. The first ten questions of CoStudy's ITIL 4 deck are free with no signup — enough to find out whether you can already tell start where you are apart from keep it simple and practical under exam pressure.
Read this in the CoStudy app →