ITSM20F.EN IT Service Management Foundation Exam Topics and Questions

This topic sets the conceptual floor for everything that follows. Before you can reason about systems, processes, or audits, you need to be precise about what a service actually is, why management of it creates value, and what ISO/IEC 20000-1:2018 is trying to achieve. Candidates who treat this as background reading rather than examinable material tend to lose easy marks on definition-level questions that look straightforward but hinge on exact distinctions.

– What service management is and why it matters

The exam tests whether you can articulate the value of service management in concrete terms, not in vague generalities. Knowing that services exist to deliver outcomes for customers is a start, but the examinable edge is understanding what separates an IT service from a non-IT service and why that boundary matters operationally. The principle of continual improvement is also in scope here: you need to understand it as a structured discipline with defined activities, not just a philosophy. The phrase 'Adapt and Adopt' is specific to this syllabus and carries a precise meaning: frameworks and standards are not meant to be implemented verbatim but adjusted to the organisation's context while preserving their intent. That distinction shows up in scenario items where a candidate must judge whether a proposed implementation approach is appropriate.

– ISO/IEC 20000-1:2018 and management system standards

ISO/IEC 20000-1:2018 is the standard this entire exam orbits. You need to know its purpose and the benefits it is designed to deliver, but the non-obvious examinable point is how management system standards are architected to coexist. The High Level Structure (sometimes called Annex SL) means that ISO/IEC 20000-1 shares a common clause framework with ISO 9001, ISO 27001, and others. That design choice allows organisations to integrate multiple standards without duplicating policy and governance overhead. Items in this area test whether you understand that integration is a feature of the standard's design, not an afterthought. Understanding what a service management system is, as a concept distinct from the tools or processes inside it, is the other anchor point here.

How 1 Introduction to IT Service Management is tested

Items from this topic tend to be definition and concept items: short scenarios or direct questions that reward precise recall and the ability to distinguish between closely related terms. The 'Adapt and Adopt' concept is a reliable source of traps because candidates conflate it with either strict compliance or unconstrained customisation. Items reward the middle position: purposeful adaptation within the standard's intent.

The IT service versus non-IT service distinction also appears in scenario form, where a candidate must classify a described service correctly before reasoning about it. The value of service management question is often presented as a 'which of these best describes' item, where all options sound plausible and the strongest option is the one grounded in customer outcomes rather than internal efficiency.

For the ISO/IEC 20000-1:2018 material, items frequently test the integration angle: candidates who only memorised the standard's purpose without understanding the High Level Structure tend to pick answers that treat standards as isolated artefacts. Marks are lost by candidates who know the what but not the why.

Where the first topic establishes what a service management system is, this one asks you to operate inside it. The SMS topic is the heaviest in terms of structural detail: leadership, governance, documentation, resources, design, monitoring, and continual improvement all sit here. Candidates who read this as a list of headings rather than an interconnected system tend to struggle with scenario items that require them to trace a decision or a gap back to its root in the SMS framework.

– Context, leadership and governance

The organisation does not exist in isolation, and neither does its SMS. The exam tests whether you understand how interested parties, including customers, regulators, and internal stakeholders, shape the scope and boundaries of the system. Organisational risks and opportunities feed directly into how the SMS is scoped and prioritised: this is not a general risk management concept but a specific input to SMS design. Leadership responsibilities are examinable in concrete terms. Senior management is expected to demonstrate commitment through defined actions, not just endorsement, and items will present scenarios where you must judge whether leadership behaviour meets that bar. Governance principles set the accountability structure that makes the SMS function. Candidates who treat governance as synonymous with oversight miss the examinable point: governance defines who decides, who acts, and who is held accountable.

– Documentation and resource management

Documentation requirements in ISO/IEC 20000-1:2018 are specific and examinable. The standard distinguishes between documented information that must be maintained and documented information that must be retained, and items test whether you know which is which and why it matters. Candidates who treat documentation as a bureaucratic checkbox tend to lose marks on items that ask about the purpose behind a documentation requirement. Resource management sits alongside documentation as an enabler of the SMS: you need to understand what categories of resource are in scope and what the standard requires the organisation to do about them. This is not about budgeting in detail but about the management obligations the standard places on the organisation.

– Designing, building and transitioning services

The SMS is not a static structure. It must govern how new and changed services are introduced, and the exam tests whether you understand what the standard requires at each stage of that lifecycle. The key distinction here is between the planning activities (what must be decided before work begins) and the transition activities (what must be controlled as a new service moves into operation). Candidates who blur these boundaries pick answers that allow organisations to skip planning steps or treat transition controls as optional. Items in this area are often scenario-based: a described organisation is about to introduce a new service, and you must identify which SMS requirement applies or which step has been missed.

– Monitoring, measurement and continual improvement

The SMS must be monitored and evaluated, not just operated. This group covers the requirements for measuring performance, analysing results, and feeding findings back into improvement activity. The examinable distinction is between monitoring (ongoing observation), measurement (quantified data collection), analysis (drawing conclusions from data), and evaluation (judging adequacy against objectives). Items test whether you can apply these in sequence and identify where in the cycle a described organisation has broken the chain. Continual improvement for the SMS itself, as opposed to improvement of individual services, is a separate examinable concept. The standard requires that improvement be planned and resourced, not reactive. Candidates who treat improvement as something that happens after problems appear miss the proactive obligation the standard places on the organisation.

How 2 Service Management System (SMS) is tested

This topic generates more scenario-based items than the first topic. You will be given a described organisation and asked to identify what the SMS requires, what is missing, or which action best satisfies a stated obligation. The trap is that most wrong options are plausible: they describe things a reasonable organisation might do, but they do not match what the standard specifically requires.

Leadership and governance items reward answers that reflect defined, accountable behaviour rather than general good management. Documentation items reward precision about what must be maintained versus retained. Design and transition items reward candidates who keep planning and transition activities in the correct sequence.

Candidates lose marks most often in two places. First, they apply general management logic instead of the specific SMS requirements, which produces answers that are sensible but wrong. Second, they underestimate the monitoring and improvement group: items here test the full cycle from data collection to improvement action, and stopping at measurement without completing the analysis step is a common error in both practice and the exam.

Everything in the first two topics describes what the SMS must be and how it must be governed. This topic is where you must show you understand how it actually runs. The process groups here cover the full operational lifecycle: from managing the service portfolio through to resolving failures and assuring continuity. The volume of processes is the main challenge. Candidates who learn each process in isolation without understanding how they connect tend to fail scenario items that span more than one process.

– Managing the service portfolio

Service Catalog Management, Asset Management, and Configuration Management form the foundation of operational visibility. The service catalog is the authoritative source of what services are offered and to whom: items test whether you understand its role as a management tool, not just a customer-facing document. Asset Management is concerned with knowing what the organisation owns and controls; Configuration Management goes further by tracking the relationships between components and how changes to one affect others. The Configuration Management Database (CMDB) is the mechanism, but the examinable point is why accurate configuration data matters for incident resolution, change assessment, and continuity planning. Items in this group often present a scenario where missing or inaccurate configuration data causes a downstream problem, and you must identify which process has failed and what its correct objective is.

– Relationships, agreements and demand

Business Relationship Management, Service Level Management, and Supplier Management sit together because they all govern the terms on which services are delivered and received. Business Relationship Management is about maintaining the right understanding between the service provider and its customers: the exam tests whether you can distinguish this from Service Level Management, which is about agreeing and monitoring specific performance targets. Service Level Agreements and Operational Level Agreements both appear in scope, and candidates must know which applies to which relationship. Supplier Management extends the same discipline to third-party providers. The standard requires that supplier relationships be managed with the same rigour as customer relationships, and items test whether you understand what that obligation entails in practice. Budgeting and Accounting for Services and Demand Management also sit in this cluster: capacity must be planned against anticipated demand, and financial accountability must be maintained across the service lifecycle.

– Change, release and transition

Change Management and Release and Deployment Management are consistently high-value areas in operational exams, and this one is no exception. Change Management controls the authorisation and scheduling of changes to services and infrastructure: the examinable distinctions are between change types (standard, normal, and emergency) and the controls that apply to each. Items reward candidates who know that emergency changes follow a different approval path, not that they bypass control entirely. Release and Deployment Management governs how approved changes move into the live environment. The exam tests the boundary between these two processes: Change Management decides whether a change happens; Release and Deployment Management controls how it happens. Candidates who merge the two lose marks on items that ask which process owns a specific activity.

– Resolution, fulfilment and service assurance

Incident Management, Service Request Management, and Problem Management are grouped by the resolution and fulfilment label but serve different purposes. Incident Management restores service as quickly as possible; Problem Management identifies and removes the underlying cause to prevent recurrence. The distinction between an incident and a problem is a reliable source of exam items, and candidates who treat them as the same thing lose marks consistently. Service Request Management handles pre-approved, low-risk requests through a separate channel: items test whether you know why that separation exists and what goes wrong when it collapses. Service Availability Management, Service Continuity Management, and Information Security Management form the assurance layer. Availability and continuity are related but not identical: availability is about normal operation targets, continuity is about recovery when normal operation fails. Information Security Management in this context is about protecting services, not about the full scope of an ISMS, and items test that boundary.

How 3 The Operation of the Service Management System is tested

This topic produces the highest volume of scenario items in the exam. You will be presented with operational situations and asked to identify the correct process, the correct activity within a process, or the reason a described approach does or does not meet the standard's requirements.

The most common loss of marks comes from two sources. First, candidates confuse processes that sit close together: Incident Management versus Problem Management, Change Management versus Release and Deployment Management, and Business Relationship Management versus Service Level Management are the three pairs that appear most often in examinable scenarios. Items reward the candidate who can identify the precise boundary.

Second, the assurance processes (Availability, Continuity, Information Security) are often underrevised because candidates assume they are peripheral. They are not: items from this group test whether you understand the specific objective of each process and can apply it in a scenario where more than one process seems relevant. The strongest answers in this topic are always process-specific, not general best-practice statements.