The guiding principles apply universally — in all circumstances, regardless of the organisation's size, sector, or maturity. They are recommendations, not mandates. Any combination of them may apply at once.
SStart where you are
Do not start from scratch when existing services, processes, programmes, projects, or people can be built upon. Assess what exists now with honest observation before assuming improvement means replacement.
An organisation wants to improve its incident process. Instead of buying a new ITSM tool, the correct first step is to observe the current process in action and measure its actual performance — then decide whether replacement is warranted.
The exam regularly presents a scenario where an organisation is considering replacing an existing process or tool. The correct ITIL answer is almost always to assess the current state first rather than immediately redesigning.
Immediately commissioning a new system without evaluating the existing one.
TThink and work holistically
No service, practice, process, or department works in isolation. Understand how all parts of an organisation work together to create value. Consider end-to-end impact before making changes.
A service desk team reduces resolution time by escalating fewer incidents. However, the second-line team is now overwhelmed. Thinking holistically would have revealed this upstream/downstream effect before the change.
When a scenario describes a problem affecting multiple teams or services, the holistic principle applies. The correct answer considers the wider impact rather than fixing one element in isolation.
Optimising one team or process without considering the knock-on effects on others.
OOptimise and automate
Optimisation means making something as effective as it needs to be. Automation means performing an activity with limited or no human intervention. Critically: optimise before automating. Automating a broken process just makes it fail faster.
An IT team wants to use AI to auto-resolve incidents. Before deploying AI, they must first ensure the incident classification process is accurate and consistent — otherwise the AI will learn from bad data and replicate errors.
This principle is heavily tested in ITIL v5 because of its explicit connection to AI. Any question describing automation or AI deployment should be approached with this principle: humans must first simplify and validate the process, then automate.
Deploying automation or AI to a process that has not first been rationalised and validated.
PProgress iteratively with feedback
Do not attempt to do everything at once. Work in smaller, manageable sections that can be evaluated and adjusted. A feedback loop uses part of the output of an activity as input for the next iteration.
An organisation is redesigning its service catalogue. Rather than redesigning all 200 services at once, the correct ITIL approach is to pilot with 10 services, gather user feedback, refine the approach, then roll out in stages.
Scenarios involving large improvements or transformation programmes will test this principle. The correct approach is always to break work into iterations and gather feedback at each stage, rather than designing a complete solution upfront.
Waiting until a complete solution is ready before any user testing or feedback.
KKeep it simple and practical
Use the minimum number of steps necessary to achieve an objective. If a process, service, action, or metric fails to provide value, eliminate it. Outcome-based thinking — every activity must justify its existence by contributing to a valued outcome.
A change management process has 14 approval steps, most added over time by different managers. Applying "keep it simple" means reviewing which steps genuinely add value and removing the rest.
This principle appears in questions about process design and documentation. The correct answer avoids over-engineering. If a proposed solution requires more steps than are necessary to achieve the goal, a simpler approach is preferred.
Adding complexity to demonstrate thoroughness, rather than to achieve the stated outcome.
FFocus on value
Everything that the organisation does should link back, directly or indirectly, to value for stakeholders and customers. Value is always defined by the consumer — not by the service provider. The questions to ask are: Who is the consumer? What do they value? How does this activity contribute to that?
An IT team is considering whether to produce detailed technical documentation for internal use. The focus-on-value test: does this documentation ultimately contribute to better service for customers? If yes, do it. If it only serves internal reporting, question whether it is worth the effort.
This is the most fundamental principle and underpins the entire ITIL framework. When multiple answers seem plausible, ask which one most directly links the activity to value for the customer. That is usually the correct choice.
Continuing activities that serve internal efficiency but do not contribute to customer value.
CCollaborate and promote visibility
Work with the right people in the right roles at the right time. Involving the correct stakeholders leads to better buy-in, more relevant outcomes, and longer-term success. Visibility of work, progress, and obstacles enables informed decisions and builds trust.
A service improvement initiative is being driven entirely by the IT management team with no input from service desk staff who actually handle the incidents. Collaborating would mean involving front-line staff, whose practical knowledge is essential for meaningful improvement.
Scenarios involving stakeholder communication, transparency, and cross-team working test this principle. The correct answer promotes including relevant stakeholders early, sharing information openly, and making work visible rather than keeping it siloed.
Making decisions in isolation without involving the people who will be affected by or responsible for the outcome.