ITSM20FB IT Service Management Foundation Bridge Exam Topics and Questions

This topic sets the conceptual ground for everything that follows. Before the exam asks you to apply a process or evaluate a decision, it needs to confirm that you understand why service management exists, what value it creates, and what ISO/IEC 20000-1:2018 is trying to achieve. Get these foundations wrong and you will misread scenario questions throughout the rest of the paper.

– What service management is actually for

The exam does not reward a memorised definition of service management. It rewards understanding the value that service management delivers to an organisation and its customers. That means being able to articulate why structured service management produces better outcomes than ad hoc delivery, and where the value proposition sits: in predictability, accountability, and alignment between IT capability and business need.

Continual improvement sits alongside this. The principle is not simply that organisations should improve; it is that improvement must be structured, measurable, and embedded into normal operations rather than treated as a project that runs once and closes. The exam will test whether you can distinguish a continual improvement mindset from a one-off corrective action.

– ISO/IEC 20000-1 and management system standards

ISO/IEC 20000-1:2018 is the international standard for IT service management, and this topic requires you to identify its purpose and the benefits it offers organisations that achieve conformance. The examinable angle is not the history of the standard but what it does: it defines requirements for a service management system, giving organisations a verifiable baseline.

Management system standards are designed to a common high-level structure, which means an organisation running ISO 9001 or ISO 27001 alongside ISO/IEC 20000-1 can integrate them without duplicating their governance apparatus. That integration logic is directly testable. Know what a service management system is as a concept, how the standard frames it, and why the common structure of management system standards matters practically. Those three angles cover the bulk of what this sub-area demands.

How 1 Introduction to IT Service Management is tested

Items from this topic tend to be concept-recognition and application questions. They present a short scenario, typically a statement from a manager or a description of an organisational situation, and ask you to identify which principle or purpose is illustrated. The trap is selecting an answer that sounds plausible in general IT terms but does not reflect what the standard or the service management discipline actually says.

The continual improvement principle catches candidates who confuse it with reactive problem-solving. Items reward recognising that improvement is planned and ongoing, not triggered only by failure. The ISO/IEC 20000-1 questions reward understanding the standard's intent rather than its clause numbering. Candidates lose marks by treating the standard as a checklist rather than as a requirements framework. The integration angle on management system standards is a favourite for distractor-heavy items: three options will describe plausible but incorrect reasons for integration, and the strongest option will reflect the actual design logic of high-level structure alignment.

Where the first topic establishes the why, this one establishes the how. The SMS topic covers the architecture of the system itself: who is responsible for it, what it must document, how it manages resources, and how it improves over time. It carries the most operational detail of any topic in this exam, and candidates who skim it in favour of the process topic in Topic 3 consistently find themselves short on marks.

– Context, risk, and objectives

The SMS does not exist in isolation. The organisation and the parties it serves, whether customers, regulators, or internal stakeholders, shape what the system must do and how it must perform. The exam tests whether you understand that mapping interested parties and their requirements is a formal input to designing the SMS, not an optional stakeholder exercise.

Risk and opportunity sit alongside context. The standard requires organisations to understand their risks and to treat them systematically, which means the SMS must have a mechanism for identifying, evaluating, and responding to risk rather than reacting when something goes wrong. Service management objectives flow from this: they must be measurable, aligned to the organisation's context, and revisited as context changes. Items on this cluster reward candidates who can connect context analysis to objective-setting rather than treating them as separate activities.

– Leadership, governance, and documentation

Leadership responsibilities under the standard are specific. Top management is not simply expected to endorse the SMS; it is required to demonstrate commitment in defined ways, including ensuring that the SMS policy is established and communicated, that roles are assigned, and that the SMS achieves its intended outcomes. The exam distinguishes between leadership activities that the standard requires and those that are merely good practice.

Governance principles set the framework within which decisions about services are made and accountability is maintained. Documentation requirements are equally concrete: the standard specifies what must be documented, and the exam tests whether you know the difference between what is mandatory and what is discretionary. A common error is assuming that more documentation is always better. Items reward knowing that documentation must be appropriate to the organisation's context, not exhaustive.

– Resources, design, and transition

Resource management under the SMS covers people, knowledge, and infrastructure. The standard requires the organisation to determine and provide the resources needed for the SMS to function and to be maintained. Competence, awareness, and communication are all treated as resource considerations, not as soft factors.

Designing, building, and transitioning new or changed services connects the SMS to the service lifecycle. The requirements here ensure that changes to services are planned and controlled within the SMS rather than handled informally. Candidates often underestimate this sub-area because it overlaps with change and release processes in Topic 3. The distinction worth keeping clear is that this sub-area addresses the SMS-level requirements for managing service transitions, while Topic 3 covers the operational processes that execute them.

– Monitoring, measurement, and continual improvement

The SMS must be monitored and measured, and those results must feed into evaluation and improvement. The standard is specific that this is a closed loop: measurement without analysis, and analysis without action, do not satisfy the requirements. Candidates who treat monitoring as a passive activity will be caught by items that reward an active, cycle-based view.

Continual improvement activities at the SMS level are distinct from fixing individual service failures. The exam tests whether you can identify improvement activities that are targeted at the system itself, its processes and its outputs, rather than at a single incident or problem. The Plan-Do-Check-Act logic underpins this area, and while you do not need to recite it, you do need to apply it when a scenario describes an organisation evaluating and adjusting its SMS.

How 2 Service Management System (SMS) is tested

This topic generates the highest density of scenario-based items in the exam. A typical item describes an organisation's SMS in a partial or flawed state and asks what is missing, what should happen next, or which action best satisfies the standard's requirements. The demand on the candidate is to map the scenario to a specific SMS requirement rather than to a general IT management intuition.

The traps are consistent. One is confusing leadership commitment with management delegation: items reward recognising that certain responsibilities cannot be delegated away from top management. Another is misreading the documentation requirements as either more or less prescriptive than they are. A third trap appears in the monitoring and improvement questions, where candidates select options that describe measuring without acting, or acting without first measuring.

The design and transition sub-area trips candidates who have studied process-level detail but have not thought about what the SMS must require before those processes even run. Items in that cluster reward a requirements-first perspective rather than a process-execution perspective.

Having established the system and its requirements, the exam now turns to the processes that run inside it. This topic covers the operational processes across the full service lifecycle: from managing the service portfolio and supplier relationships, through planning capacity and budgets, to handling incidents, problems, and security. Each process cluster has its own objectives and boundaries, and the exam tests whether you can keep them distinct under pressure.

– Service portfolio, assets, and configuration

Service Catalog Management, Asset Management, and Configuration Management form the foundation of operational visibility. The service catalog is the authoritative record of what services are available and to whom; the exam tests whether candidates understand its role as a live operational tool rather than a marketing document. Asset Management ensures that the components underpinning services are tracked and accounted for throughout their lifecycle.

Configuration Management goes further by capturing the relationships between configuration items, not just their existence. The distinction between an asset register and a configuration management database is directly testable. Candidates who conflate the two will be caught by items that reward understanding why relationship data matters for impact assessment, particularly when a change or incident is being evaluated. The objectives of these three processes connect: you cannot manage what you have not catalogued, and you cannot assess impact without knowing dependencies.

– Relationships, agreements, and suppliers

Business Relationship Management, Service Level Management, and Supplier Management each address a different boundary: between the service provider and the customer, between the provider and the agreed service targets, and between the provider and its supply chain.

Service Level Management is the most heavily tested of the three. Items reward knowing that service level agreements must be based on business requirements and must be measurable, not aspirational. The distinction between an SLA, an OLA, and an underpinning contract is a standard examination point. Supplier Management requires understanding that the provider remains accountable to the customer even when a service component is delivered by a third party. Business Relationship Management is often misread as a customer satisfaction exercise; items reward recognising its formal role in capturing requirements and maintaining the relationship structure that feeds into service design.

– Demand, capacity, and financial management

Capacity Management, Demand Management, and Budgeting and Accounting for Services address the supply side of service delivery. Capacity Management ensures that the service provider can meet agreed service levels now and in the future, which means it is forward-looking as well as reactive. Demand Management sits upstream of capacity: it shapes and influences demand so that capacity planning has reliable inputs.

Budgeting and Accounting for Services is often underestimated by candidates with a technical background. The exam tests whether you understand why financial visibility matters to service management, specifically how costs are attributed to services and how budgeting connects to service decisions. Items in this cluster reward candidates who can trace the relationship between demand forecasts, capacity plans, and financial commitments, rather than treating each process as self-contained.

– Change, release, incident, problem, request, and service assurance

Change Management and Release and Deployment Management are frequently confused. Change Management governs the authorisation and scheduling of changes; Release and Deployment Management handles the packaging and delivery of those changes into the live environment. Items reward keeping the decision authority and the execution activity in the right process.

Incident Management, Service Request Management, and Problem Management form the resolution cluster. The key distinction is between restoring service quickly (incident), fulfilling a pre-approved request (service request), and eliminating the root cause of recurring incidents (problem). Candidates lose marks by applying problem management logic to incident scenarios or vice versa.

Service Availability Management, Service Continuity Management, and Information Security Management round out the topic. Availability Management is concerned with agreed availability targets; Continuity Management with recovering from major disruptions; Information Security Management with protecting information assets across confidentiality, integrity, and availability. Each has a distinct objective, and the exam will test whether you can select the right process for a given organisational need.

How 3 The Operation of the Service Management System is tested

This topic generates the largest number of process-selection and process-boundary items. A scenario will describe a situation, and the item will ask which process owns the activity, which process should be invoked next, or which process objective is being served. The demand is precision: several processes will seem relevant, and the strongest option will be the one that matches the specific objective described.

The most common trap is selecting a process based on surface similarity rather than objective alignment. Incident Management and Problem Management share vocabulary but serve different ends, and items exploit that. Change Management and Release Management share a subject matter but divide the work differently, and that boundary is tested repeatedly.

Service assurance items tend to reward candidates who understand that availability, continuity, and security are separate disciplines with separate triggers, not a single bloc of protective activity. Candidates who have studied the processes individually but not practised applying them to scenarios will find this topic the most time-consuming part of the exam. Checking your coverage across every process cluster, rather than focusing on the ones you already know, is where preparation time pays off here.