FitSM: FitSM – Tutorial (about 60 minutes)

FitSM is a free, lightweight family of standards for IT service management (ITSM): the way an organisation plans, delivers, operates and controls the IT services it provides to customers. It is used by research and academic computing centres, public-sector IT departments, small and medium-sized service providers and, above all, by federations in which several independent organisations deliver services together. After this tutorial you will be able to explain how FitSM is organised, what its requirements and processes ask for, how to introduce it step by step, how capability and maturity are assessed, and how it fits next to ITIL and ISO/IEC 20000-1.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: FitSM is maintained by the FitSM working group within the non-profit association FitSM e.V. in Munich, Germany (formerly called ITEMO e.V., the name still printed in the documents). The current generation is the version 3 series, which replaced the 2.x documents that are still offered as "previous versions". At the time of checking, the latest published core parts were FitSM-0 Overview and vocabulary v3.0.1 (released June 2025), FitSM-1 Requirements v3.0.1 (released May 2024), FitSM-2 Process activities and implementation v3.0.2 (released December 2025) and FitSM-3 Role model v3.0.1 (released May 2024), together with the FitSM-6 maturity and capability assessment tool for version 3.0. The core documents are published under a Creative Commons Attribution 4.0 licence and can be downloaded at no cost. FitSM is not an ISO or national standard; it is a community standard designed to be compatible with ISO/IEC 20000-1 and ITIL. No newer major version had been announced. Verified 2026-10-29 on the official downloads page.

Who it is for: IT operations staff, service desk leads, team leaders and managers in IT departments, research infrastructure and data centre staff, quality and compliance people, and anyone asked to "introduce service management" without a large budget or a team of consultants.

Prerequisites: none. Some experience of working in or with an IT team helps, because FitSM is easiest to understand when you can picture real tickets, outages, changes and customers.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check. Because the FitSM documents are free, keep FitSM-1 open in another window while you read; it is only about a dozen pages long.

Learning objectives:

You will be able to explain where FitSM came from, why it was designed to be lightweight and which principles guide it.
You will be able to use the core FitSM vocabulary correctly, including service, configuration item, SLA, OLA, underpinning agreement, incident, problem, known error and federation.
You will be able to describe the seven parts of the FitSM family and the structure of FitSM-1: seven groups of general requirements and fourteen processes.
You will be able to plan a realistic introduction of FitSM, including the role model, documentation, tools and the order in which to tackle processes.
You will be able to explain how FitSM-6 capability and maturity levels work and what organisational and personnel certification involve.
You will be able to compare FitSM with ITIL, ISO/IEC 20000-1, COBIT and ISO/IEC 27001 and decide when each is the better fit.

Lesson 1 – Origins, purpose and scope

Why FitSM was created

In the early 2010s, European research e-infrastructures such as grid and cloud computing federations were growing fast. Dozens of universities and laboratories contributed computing, storage and networking resources to shared services used by scientists across many countries. Nobody owned the whole chain: a researcher's job might pass through a portal run by one partner, a scheduler run by another and storage in a third data centre. When something broke, it was often unclear who should fix it, who should tell the user and who should make sure it did not happen again.

The established answers to these questions, ITIL and the international standard ISO/IEC 20000, assume a single service provider with a clear management hierarchy. Their guidance is also extensive. ITIL in particular is a large library of books, and many small teams found that they could not translate it into a practical first step. Organisations that were not ready for certification against ISO/IEC 20000 had no simple yardstick to tell them whether they were improving.

The European Commission therefore co-funded a project called FedSM under its Seventh Framework Programme, running from 2012 to 2015. Its goal was to raise the maturity of service management in federated infrastructures. The project's results were published under the name FitSM from 2013 onwards so that organisations outside the research world would also adopt them. After the project ended, a working group took over maintenance of the standard and continues to revise it, train people and run certification schemes together with commercial partners.

What "lightweight" means

FitSM is lightweight in a precise sense. It does not try to describe every good practice in IT management; it defines a small set of requirements that any provider of IT services should be able to meet, and stops there. FitSM-1 contains 82 requirements in total, each written as a single short "shall" statement. Compare this with thousands of pages of good-practice guidance elsewhere. The intention is that a team can read the requirements in an afternoon, assess itself against them in a day or two, and start improving the following week.

The guiding principles

FitSM-0 describes seven principles. Three of them are ideas shared by ITSM in general:

Service and customer orientation – what IT delivers is organised as services with clearly agreed service levels, shaped around what customers actually need.
Process orientation – the work needed to plan, deliver, operate and control services is carried out within well-understood, effective processes rather than ad hoc.
Continual improvement – the whole management system follows the plan-do-check-act cycle, and services and processes are regularly evaluated so that improvements can be found and implemented.

Four further principles express the particular spirit of FitSM:

Practicality – prefer simple, proven guidance to elaborate theory.
Consistency – get repeatable performance first; detailed documentation can follow.
Sufficiency – "good enough and working" beats a perfect solution that never arrives.
Extendibility – FitSM is a base you can extend with knowledge from other frameworks, not a closed system.

A procedure so detailed that nobody follows it violates consistency and sufficiency, however impressive it looks.

Scope

FitSM applies to any organisation, or part of an organisation, that provides IT services to customers: commercial companies, government agencies, universities and non-profit bodies, regardless of size or type of service. The customers can be internal (other departments of the same company) or external. FitSM explicitly supports federations, where several independent partners jointly deliver services without a strict supply chain or hierarchy. That federated focus is one of the main things that sets FitSM apart.

FitSM covers the management of IT services. It is not a software development method, a technical architecture standard or a detailed security control catalogue. It has an information security management process, but organisations that need a complete security management system usually combine FitSM with ISO/IEC 27001.

Lesson 2 – Key concepts and vocabulary

FitSM-0 defines around eighty terms so that everyone involved uses the same language, which matters especially when several organisations work together. The following terms are the ones you need most often. The explanations are in our own words.

IT service – a way of delivering value to a customer, enabled by information technology, for example "research data storage" or "email". A service is described from the customer's perspective, not as a list of servers.
Service component – a logical part of a service that is not delivered on its own to customers, such as the database behind a web portal. Components can come from internal teams or suppliers.
Configuration item (CI) – anything that contributes to delivering services and therefore needs its configuration controlled: hardware, software, network devices, but also documents such as SLAs and licence records.
Configuration management database (CMDB) – the store of information about CIs and their relationships. It does not have to be one product; several connected data sources can together form the CMDB.
Service management system (SMS) – the whole set of policies, processes, procedures, roles, resources and tools a provider uses to manage its services. It is a way of managing, not a piece of software.
Service portfolio – the internal, complete view of all services: planned, live and being retired, including information needed to manage them.
Service catalogue – the customer-facing description of the services that can be ordered or used. It is typically a subset of the information in the portfolio.
Service level agreement (SLA) – a documented agreement between the provider and a customer that describes a service and the service targets, such as availability or response times.
Operational level agreement (OLA) – an agreement between the service provider and an internal supplier (or, in a federation, a federation member) about a supporting service or component and its operational targets.
Underpinning agreement (UA) – an agreement with an external supplier about the supporting service or component it provides and the related operational targets; in effect an SLA in which the provider is the customer. FitSM-0 notes that it is also called an underpinning contract (UC).
Incident – an unplanned disruption of a service or component, or a degradation in quality below what has been agreed.
Service request – a user request for something standard that is not a disruption: a new account, a password reset, more storage quota or information.
Problem – the underlying cause of one or more incidents, often not yet known when the incidents happen.
Known error – a problem that has not been resolved yet but for which a workaround or other measure to reduce its impact is documented.
Workaround – a way of reducing or eliminating the effect of an incident or problem without fixing the cause.
Change – adding, modifying, replacing or removing a CI or anything else that is under change control. An emergency change is one that must be implemented very urgently to avoid harm; a major change is one that may significantly affect services.
Federation, federation member and federator – a federation is a group of parties that jointly deliver services without a strict hierarchy; each party is a member, and the federator is the body that coordinates them.
Capability level and maturity level – capability describes how effectively a single process or general aspect is implemented; maturity describes the overall effectiveness of the whole SMS based on the combination of capability levels.
Nonconformity – a situation in which a requirement is not fulfilled; FitSM treats compliance and conformity as near synonyms.
Key performance indicator (KPI) – a selected metric used to track the effectiveness or efficiency of a service or process against its goals.

Two distinctions beginners often miss

Incident versus problem. An incident is about restoring service as quickly as possible; a problem is about understanding and removing the cause. When a storage system fails at 09:00, the service desk handles the incident and restores access, perhaps by switching to a replica. Problem management later asks why the failure happened and whether it will happen again. Mixing the two leads either to slow restoration (people investigate while users wait) or to endless repeats (nobody investigates at all).

SLA, OLA and UA. These three agreements form a chain. The SLA faces the customer. OLAs face internal or federated partners. UAs face external suppliers. If the SLA promises a four-hour fix but the storage vendor's contract allows two business days, the SLA cannot be met reliably. Aligning the three is one of the most valuable things FitSM pushes you to do.

Lesson 3 – Structure of the FitSM family

Seven parts

FitSM is a family of documents rather than a single book. Three parts form the heart of the standard and are needed by everyone; the others are aids that grow over time.

Figure 1 – The FitSM family: the core standard (parts 0 to 3) and the implementation aids (parts 4 to 6) that build on it.

FitSM-0 Overview and vocabulary – the principles, an overview of the family and the process model, and the terms and definitions used by all other parts.
FitSM-1 Requirements – the normative part. It states what an SMS must achieve. If you are audited, you are audited against FitSM-1.
FitSM-2 Process activities and implementation – for each group of general requirements and each process: an objective, key questions to ask, recommended activities for setting it up and for running it, inputs, outputs and interfaces to other processes. It is guidance: you may meet the requirements in other ways.
FitSM-3 Role model – the basic roles needed to run an SMS and its processes, with their typical tasks, plus guidance on using a RACI matrix.
FitSM-4 Templates and samples – ready-to-use documents such as an SLA template, a sample service management policy, a sample service portfolio and catalogue, a process definition template, a procedure template, a basic service report and a service design and transition package.
FitSM-5 Implementation guides – short guides on specific topics, for example how to identify and specify services, a checklist of ITSM documentation and how to move from FitSM towards ISO/IEC 20000-1 compliance.
FitSM-6 Maturity and capability assessment scheme – a spreadsheet tool with descriptions of capability levels for every requirement, used both for self-assessment and in formal audits.

FitSM-1: general requirements

FitSM-1 has two sections. The first contains 17 general requirements (GR) for the service management system as a whole, grouped into seven categories. Each category has a short code that appears throughout the family:

GR1 Top management commitment and accountability (MCA) – a top manager is named as SMS owner, a service management policy exists and is communicated, and management reviews take place.
GR2 Documentation (DOC) – the key elements of the SMS and each process are documented, key process outputs and activities are recorded, and documents are controlled (approval, distribution, review, versioning).
GR3 Scope and stakeholders (SCS) – stakeholders and their needs, including legal and contractual requirements, are analysed, and the scope of the SMS is defined accordingly.
GR4 Planning (PLAN) – a service management plan sets goals, timing, roles, training and tools, and other plans are aligned to it.
GR5 Implementing (DO) – the plan is carried out and the defined processes are actually followed and enforced.
GR6 Monitoring and reviewing (CHECK) – the SMS and its processes are measured with KPIs, and assessments or audits take place at planned intervals.
GR7 Continually improving (ACT) – nonconformities and deviations lead to actions that prevent recurrence, and the policy, plan and processes are improved through the continual service improvement process.

GR4 to GR7 are deliberately labelled with the four steps of the plan-do-check-act (PDCA) cycle. GR1 to GR3 set the stage: someone senior must own the system, the boundaries must be clear and the essentials must be written down.

Figure 2 – The seven groups of general requirements: commitment, documentation and scope set the stage for a plan-do-check-act cycle.

FitSM-1: process-specific requirements

The second section contains 65 process requirements (PR), grouped by the fourteen processes of the FitSM process model. Each process has between three and six requirements. The table summarises each process in our own words.

Code	Process	Purpose in brief	Number of requirements
PR1 SPM	Service portfolio management	Keep the portfolio, evaluate proposals for new or changed services, manage services through their lifecycle and identify the suppliers behind each service.	4
PR2 SLM	Service level management	Maintain the catalogue, agree SLAs, OLAs and UAs, and evaluate performance against their targets.	5
PR3 SRM	Service reporting management	Decide which reports are needed, specify them with their recipients and deliver them as specified.	3
PR4 SACM	Service availability and continuity management	Identify availability and continuity needs, assess risks, act to reduce them and monitor availability.	4
PR5 CAPM	Capacity management	Know capacity and performance requirements and current usage, plan future capacity, and analyse utilisation warnings.	4
PR6 ISM	Information security management	Define security requirements and policies, assess risks, implement controls, handle security incidents and manage access consistently.	5
PR7 CRM	Customer relationship management	Know the customers, give each a contact person and communication channels, hold service reviews, handle complaints and manage satisfaction.	6
PR8 SUPPM	Supplier relationship management	Know internal and external suppliers, assign contacts and escalation channels, and evaluate suppliers regularly.	4
PR9 ISRM	Incident and service request management	Register, classify, prioritise, escalate, resolve and close incidents and requests consistently, keep users informed and handle major incidents.	6
PR10 PM	Problem management	Find problems from incident trends, investigate them, register known errors with workarounds and keep that information current.	4
PR11 CONFM	Configuration management	Define the scope and CI types, keep CI information and relationships in a CMDB, control CIs and verify the data periodically.	5
PR12 CHM	Change management	Register, classify, assess and approve changes consistently, review and close them, and publish a schedule of changes.	6
PR13 RDM	Release and deployment management	Define release strategies, bundle approved changes into releases, plan, build and test them, prepare for failure and evaluate deployments.	6
PR14 CSI	Continual service improvement management	Identify, assess and control improvements to services and processes based on reports, measurements, assessments and audits.	3

The FitSM training scheme groups these processes into two halves. The first eight (SPM to SUPPM) concern planning and delivering services: what is offered, agreed, protected and resourced. The last six (ISRM to CSI) concern operating and controlling services day to day: handling what goes wrong, controlling what is changed and improving.

How FitSM-2 is organised

FitSM-2 mirrors the structure of FitSM-1. For each general requirement group it gives an objective, a few key questions, recommended activities for the initial setup, activities for operating and maintaining the SMS, and key outputs. For each of the fourteen processes it gives an objective, key questions, setup activities, ongoing activities, inputs, outputs, key interfaces to other processes and a process chart. Reading the key questions first is often the quickest way to discover what is missing in your organisation.

The language of requirements

FitSM-1 uses "shall" for every requirement, in the same way as ISO standards. Many requirements contain phrases such as "in a consistent manner" or "at planned intervals". These are deliberate. "Consistent manner" means that two people handling the same type of case should do it the same way, usually because a procedure or tool guides them. "At planned intervals" means that the timing is decided in advance and recorded, not that it happens when someone remembers. An auditor will look for evidence of both.

Lesson 4 – How it works in practice

Start with commitment and a problem statement

FitSM-2 recommends beginning with a short problem statement: what goes wrong today because service management is weak, and what the organisation hopes to gain. Typical points are repeated outages, unclear responsibilities between teams, customer complaints, failed changes or an upcoming audit. The problem statement is the basis for the service management policy, which top management approves, and for convincing the person who will become SMS owner. Without visible commitment from the top, FitSM projects stall at the first conflict between teams.

The role model

FitSM-3 describes a small set of roles that make the SMS work. A role is a bundle of responsibilities with a defined context; it becomes "implemented" when it has a clear definition and a named, competent person assigned. One person can hold several roles, and in a small organisation many will.

Figure 3 – The FitSM role model: accountability flows from the SMS owner through process owners, while managers, case owners and staff do the operational work.

SMS owner – a member of top management who is accountable for the whole SMS: approves the policy and goals, nominates process owners and managers, decides on resources and conducts management reviews. There is one SMS owner for the SMS.
SMS manager – the operational coordinator of the SMS, often described as its project manager, except that the job does not end when the system is in place. The SMS manager maintains the service management plan, keeps people aware and competent, tracks the effectiveness and maturity of the SMS and escalates to the owner.
Process owner – accountable for one process: sets its goals and policies within the overall policy, appoints and supports the process manager, approves significant changes to the process and decides on its resources. In practice the SMS owner often also acts as owner for several processes.
Process manager – the day-to-day leader of one process: maintains the process definition, makes sure people know how to apply it, monitors execution and results, and reports on performance.
Case owner – responsible for one individual case through its lifetime: an incident owner, a problem owner, a change owner, a customer relationship manager for one customer, a service owner for one service. Case owners make sure their case is handled properly and not forgotten; they do not necessarily make every decision about it.
Process staff – anyone performing tasks in a process without holding one of the other roles, for example technicians resolving tickets according to a procedure.

FitSM-3 suggests describing the involvement of roles in each activity with a RACI matrix, where R means responsible (does the work), A accountable (owns the outcome and approves), C consulted and I informed. It gives three simple rules: each activity should have exactly one A, each activity needs at least one R, and the same role should not be both A and R for the same activity. The rule against combining A and R is about checks and balances: someone other than the person doing the work should own the outcome.

A typical implementation sequence

FitSM does not prescribe a fixed order, but a sequence that works for most organisations looks like this:

Appoint the SMS owner and SMS manager, write the problem statement and agree the service management policy.
Define the scope: which services, locations, organisations, technologies and customers are included. In a federation, also which members participate. Start narrow if necessary; GR3 expects the scope to be reviewed and extended later.
Assess the current state with the FitSM-6 tool, set a target capability level for each process and record the gaps (a gap analysis).
Write the service management plan: goals and milestones, roles, training and awareness, tools. Use the gap analysis to decide what to tackle first.
Identify and describe the services. Many teams discover that what they called services are really components ("the Oracle cluster") rather than things customers value ("student records system"). The FitSM-5 guides on identifying and specifying services help here.
Introduce the high-volume operational processes first, typically incident and service request management, change management and a basic configuration management, because they produce quick, visible benefits and the data that other processes need.
Add agreements and reporting: catalogue, SLAs, OLAs and UAs, and simple service reports that compare performance with targets.
Add the planning and protection processes: availability and continuity, capacity, information security, supplier and customer relationship management, release and deployment, portfolio management.
Measure, audit and improve: define KPIs for each process, run internal audits, hold management reviews and register improvement opportunities in the CSI process.

Documentation and records

GR2 asks for a modest but essential set of documents: a scope statement, the service management policy, the service management plan, a definition of each process (goals, inputs, activities, outputs, roles, interfaces, and related policies and procedures where needed) and records of key activities. Records are the evidence: incident tickets, change records, minutes of service reviews, audit reports. FitSM-4 templates provide starting points. A wiki or document management system with clear ownership, approval and version history is usually enough; what matters is that documents are controlled and match what people actually do.

How the operational processes interlock

Processes deliver value through their interfaces. The following diagram shows the classic flow from a user's report to a lasting fix.

Figure 4 – How incident, problem, change, release and configuration management pass work to each other, from a user's report to a lasting fix.

Notice the feedback loops. Known errors flow back to the service desk so that the next similar incident is resolved faster. Configuration data flows back so that technicians can see which services depend on a failed component. Service level management (not shown) sets the targets that drive incident priorities, and service reporting turns the records into reports for customers and management.

FitSM in a federation

In a federation, a federator often coordinates the SMS for the federated services, while members operate their own components under OLAs, and the SMS owner may be nominated jointly by the members' top managers. Typical needs are a shared or connected ticket system, common classification and priority schemes, escalation paths across organisational boundaries and a joint change schedule.

Lesson 5 – Assessment, certification and compliance

Capability and maturity in FitSM-6

FitSM-6 is a spreadsheet that lists every FitSM-1 requirement with narrative descriptions of what typical practice looks like at different levels. The assessor chooses, for each requirement, the description closest to reality. The tool then summarises the results per process and for the SMS as a whole, shows a gap analysis against chosen targets, and provides sheets for conclusions and audit details.

The version 3 tool uses five capability levels:

Figure 5 – The five FitSM-6 capability levels, from no awareness of the required activities to managed, monitored and aligned practice.

Level 0 – the required activities are not understood and their key outputs do not exist.
Level 1 – people know what should happen, but work is reactive and uncontrolled, responsibilities are unclear and documents, if any, do not reflect reality.
Level 2 – activities are repeatable and reasonably effective and key outputs exist, but documentation and practice still diverge noticeably: either people do things well without writing them down, or documents describe things that are only partly done.
Level 3 – activities and responsibilities are defined and performed effectively; documentation is sufficient and matches practice; expected outputs are produced.
Level 4 – beyond level 3, activities are also managed and monitored, their effectiveness and efficiency are evaluated regularly, reviews lead to improvement and outputs are aligned with each other.

Capability levels are given to individual requirements and processes; the maturity of the whole SMS is derived from the combination of these capability levels. This distinction matters when you report results: "our change management is at level 3" is a capability statement, while "our SMS is mature enough for certification" is a maturity statement.

Self-assessment

Anyone can use FitSM-6 for a self-assessment. Its value depends entirely on honesty. Good practice is to assess with a small group that includes people who do the work, not just managers; to ask for evidence (a ticket, a document, a report) before choosing a level; and to repeat the assessment at planned intervals so that progress can be seen. FitSM-6 recommends support from someone experienced in ITSM. The tool itself warns that its results alone are not sufficient evidence for a certificate, which requires an assessment by a certified FitSM auditor and validation by a recognised certification body.

Internal audits and management reviews

GR6 requires assessments or audits at planned intervals, and FitSM-0 explains that auditors should not audit their own work. In a small organisation this may mean that the change manager audits incident management and vice versa, or that a partner organisation in a federation performs audits for another member. Audit findings and KPI results feed the management review, in which the SMS owner evaluates the suitability, maturity and efficiency of the SMS and decides on follow-up actions.

Organisational certification

FitSM offers an organisational certification, which the official site presents as a pilot scheme. It works as follows: a certified FitSM auditor reviews the SMS over a few days, depending on the organisation's size, and evaluates it against the FitSM-1 requirements using the FitSM-6 tool, in which the scope (all processes) and target capability levels for certification are pre-set. APMG International, acting as certification authority, validates the audit results and issues the certificate and a digital badge. Fees consist of the auditor's fee and the certification authority's fee. Older secondary sources sometimes state that FitSM has no organisational certification; that was true before the organisational scheme was introduced and is now out of date.

FitSM certification is not accredited certification in the sense of ISO/IEC 20000-1. If a contract or tender asks specifically for ISO/IEC 20000-1, a FitSM certificate does not satisfy it, although an organisation that meets FitSM-1 has done much of the groundwork. One of the FitSM-5 guides addresses the step from FitSM towards ISO/IEC 20000-1 compliance.

Certification of persons

FitSM also has a personnel qualification scheme, with training certified by APMG and ICO:

Foundation – a one-day course on basic ITSM concepts, the FitSM process model and FitSM-1, with an optional short multiple-choice exam. No prerequisites.
Advanced: Service Planning and Delivery (SPD) – a two-day course covering the eight planning and delivery processes (portfolio, service level, reporting, availability and continuity, capacity, information security, customer and supplier relationships).
Advanced: Service Operation and Control (SOC) – a two-day course on the six operational processes (incident and request, problem, configuration, change, release and deployment, continual improvement).
Expert – for holders of both advanced certificates; it focuses on implementation methods, process interfaces, organisational change and conducting audits. An expert bridge course provides a side entry for experienced ITSM professionals.
Auditor – a certification as FitSM auditor, offered in cooperation with ICO, for people who will perform the organisational audits.

Personal certificates show that an individual understands FitSM; they say nothing about whether that person's employer has a working SMS. Keep the two kinds of certification apart when you read job advertisements or supplier claims.

Lesson 6 – Worked example

This example is fictional but realistic. Three universities operate a shared research computing service called "Meridian", offering high-performance computing, research data storage and a cloud platform to about 4,000 researchers. Each university runs part of the infrastructure; a small coordination office at one of them acts as federator. Complaints are rising: outages are announced late or not at all, users do not know whom to contact, and a storage upgrade at one site broke jobs at another site.

Step 1 – Commitment and scope

The coordination office writes a two-page problem statement listing recent incidents, their impact on researchers and the main causes: no shared ticket system, no joint change schedule and unclear responsibilities. The three universities' IT directors agree to nominate the head of the coordination office as SMS owner and appoint an SMS manager at 50 % of a full-time post. The SMS owner signs a one-page service management policy committing to service orientation, process orientation and continual improvement.

For the first year, the scope is limited to the three user-facing services (computing, storage and cloud) as delivered by the three universities to registered researchers. Internal campus IT is excluded. Stakeholders are listed: researchers, research group leaders, the funding agency, the three IT departments, two hardware vendors and a network provider. The funding agency's reporting obligations and data protection law are recorded as external requirements.

Step 2 – Baseline and target

The SMS manager runs a FitSM-6 self-assessment over two half-day workshops with staff from each site. Results: incident handling is level 1 at two sites and level 2 at the third; change management is level 0 to 1 (changes are announced by email when people remember); configuration information exists only as spreadsheets per site; there is no catalogue or SLA. Information security is level 2 because one university already runs an ISO/IEC 27001 programme. The target for the first year is level 2 for all processes in scope and level 3 for incident and service request management and change management, which caused most complaints.

Step 3 – Plan and roles

The service management plan lists milestones per quarter, the training needed (FitSM Foundation for all 25 staff involved, advanced courses for the process managers) and the tools: a shared ticket system hosted by the federator, connected to the sites' local tools by email interfaces. Process owners and managers are named. The SMS owner acts as process owner for most processes; process managers are spread across the three sites so that each university holds part of the responsibility. A RACI matrix for change management makes the federation's change advisory group accountable for approving major changes, while each site's change owner is responsible for preparing and implementing them.

Step 4 – Services and agreements

Using the FitSM-5 guide, the team turns a list of 40 "services" (mostly components such as "Lustre file system" or "Slurm scheduler") into three customer-facing services with a handful of options each. A simple catalogue is published on the user portal. An SLA template from FitSM-4 is adapted into one SLA per service, agreed with a researcher advisory board representing customers. Behind it, each university signs an OLA with the federator describing the components it operates and targets such as response times and maintenance windows. Existing vendor contracts are reviewed as underpinning agreements; one storage support contract offers only next-business-day response, which is too slow for the SLA's target, so the SLA target is adjusted and the contract is flagged for renegotiation.

Step 5 – Operational processes

Incident and service request management is defined with one classification scheme and one priority matrix based on impact and urgency. Major incident criteria are agreed: any outage affecting more than one site or more than 200 users. Every incident gets an incident owner. Users are informed through the portal's status page. Within three months, all incidents and requests are registered in the shared tool and the monthly report shows resolution times against SLA targets.

Change management introduces a shared schedule of changes. Changes are classified as standard (pre-approved, low risk, such as adding nodes of an approved type), normal and emergency, and those affecting more than one site count as major and go to the weekly federation change meeting. Each change is assessed for benefits, risks, impact and effort. A post-implementation review is required for major and emergency changes. The storage upgrade that once broke jobs at another site would now appear on the joint schedule and be assessed for cross-site impact before approval.

Configuration management starts small: CI types are limited to services, service components, servers, storage systems and network links, and relationships between them. The three spreadsheets are merged into a CMDB in the ticket tool, and a quarterly verification compares it with the monitoring system's inventory.

Step 6 – Measure, audit, improve

Each process manager proposes three KPIs, for example the share of incidents resolved within target, the number of failed changes and the percentage of CIs verified in the last quarter. After nine months, the federation arranges an internal audit: the change manager from one university audits incident management at another, and vice versa. The audit finds that major incident reviews are not always held. This nonconformity is recorded, a corrective action assigned and the improvement registered in the CSI register.

At the annual management review, the SMS owner sees that incident and change management have reached level 3, most other processes level 2, and that complaints have fallen. The review decides to extend the scope to a new data analytics service, to start capacity planning for the next hardware refresh and to prepare for a FitSM organisational audit in the second year. The cycle starts again with an updated plan.

Lesson 7 – Relationship to other standards and frameworks

FitSM was designed to be compatible with other ITSM approaches, and most organisations use it alongside at least one of them. Knowing the differences helps you decide what to adopt and how to avoid duplication.

Framework or standard	What it is	How it relates to FitSM
ISO/IEC 20000-1 (current edition 2018)	The international standard specifying requirements for a service management system, with accredited third-party certification.	Closest relative. FitSM-1 is similar in style (requirements with "shall") and covers comparable ground, but is much shorter and easier to achieve. FitSM is often used as a stepping stone; a FitSM-5 guide addresses the route towards ISO/IEC 20000-1 compliance.
ITIL (owned by PeopleCert)	A widely used body of IT and digital service management guidance, describing practices in depth, with a large personnel certification scheme.	Complementary. ITIL explains how to perform practices in detail; FitSM states a minimal set of auditable requirements. FitSM's extendibility principle encourages using ITIL guidance to design processes that meet FitSM requirements. ITIL itself has no organisational certification.
COBIT (ISACA)	A framework for the governance and management of enterprise information and technology, with objectives across the whole of IT.	Broader and more governance-oriented. COBIT can position service management within enterprise governance; FitSM gives a concrete, lightweight model for the service management part.
ISO/IEC 27001	The international standard for an information security management system, with Annex A controls and accredited certification.	FitSM's information security management process covers essentials such as risk assessment, controls, security incidents and access management. Organisations that need a full security management system or certification combine FitSM with ISO/IEC 27001 and share common elements such as document control, audits and management review.

A practical rule: use FitSM-1 as the checklist of what must exist, FitSM-2 and FitSM-3 as the default design, and draw on ITIL or other sources when you need more depth on a specific practice. When certification against ISO/IEC 20000-1 or ISO/IEC 27001 becomes a business requirement, extend the same management system instead of building a parallel one. Because FitSM uses the same plan-do-check-act logic and similar concepts (policy, scope, plan, audits, management review), much of the existing work carries over.

FitSM also fits agile and DevOps teams: it requires consistent assessment and approval of changes and tested releases, but lets you define change types with their own handling steps, so automated pipelines with pre-approved standard changes and automated tests can meet the requirements if the rules and records exist.

Common pitfalls and best practices

Common pitfalls:

Treating FitSM as a documentation project. Writing process descriptions that nobody follows gives a false sense of progress. FitSM-6 rates such a situation no higher than level 2, because documentation and practice diverge.
Calling components services. A catalogue full of technical components confuses customers and makes SLAs meaningless. Services must be described in terms of the value they deliver.
Skipping the general requirements. Teams that jump straight to incident management without an SMS owner, scope and plan often build islands of process that collapse when priorities change.
Introducing all fourteen processes at once. Spreading effort thinly delays visible benefits and exhausts staff. A phased plan based on the gap analysis works better.
Inflating the self-assessment. Choosing the level you hope for rather than the one you can prove hides the real gaps and leads to surprises in an audit.
Making one person both accountable and responsible for everything. In small teams this is tempting, but it removes the independent check on outcomes that the RACI rules are meant to provide.
Ignoring the agreement chain. SLAs promised without matching OLAs and supplier contracts are broken as soon as a dependency fails.

Best practices:

Start from a clear problem statement and link every improvement to a pain point the organisation recognises.
Prioritise high-volume, high-pain processes such as incident and service request management and change management, and use their records as evidence and as data for other processes.
Keep procedures short and usable, and embed them in the ticket or workflow tool so that the consistent way is the easy way.
Use the FitSM-4 templates and FitSM-5 guides rather than inventing documents from scratch; adapt them to your size.
Assess honestly and repeatedly with evidence, involving practitioners, and track capability over time.
In federations, agree common schemes early: classification, priorities, escalation paths and a joint change schedule.

Summary and key takeaways

FitSM is a free, lightweight family of IT service management standards that originated in the EU-funded FedSM project and is maintained by the FitSM working group within FitSM e.V.; the current generation is version 3.
Its principles combine general ITSM ideas (service orientation, process orientation, continual improvement) with practicality, consistency, sufficiency and extendibility.
The family has seven parts: vocabulary, requirements, process activities, role model, templates, implementation guides and an assessment tool.
FitSM-1 contains 17 general requirements in seven groups, built around the plan-do-check-act cycle, and 65 requirements for fourteen processes.
The role model separates accountability (SMS owner, process owners) from operational leadership (SMS manager, process managers) and assigns case owners to individual incidents, changes and other cases.
FitSM-6 rates each requirement on capability levels 0 to 4, supports honest self-assessment and gap analysis, and is the basis for audits.
An organisational certification is offered via certified auditors with APMG as certification authority, and personal certificates exist at foundation, advanced, expert and auditor levels.
FitSM is compatible with ISO/IEC 20000-1 and ITIL and is often used as a practical first step towards formal ISO certification.

Reflection questions

Think about an IT team you know. Which FitSM processes would you introduce first, and what evidence from its current problems supports your choice?
List three things your organisation calls "services". Are they really services in the FitSM sense or service components, and how would you rewrite them from the customer's point of view?
Draw a small RACI matrix for approving and implementing a major change in your environment. Does it follow FitSM-3's three rules, and what would you change if it does not?
If you were the SMS manager in a federation of independent organisations, how would you persuade members to accept a common priority scheme and a joint change schedule?
Your management asks whether to pursue FitSM organisational certification or go directly for ISO/IEC 20000-1. Which factors would you weigh, and what would you recommend for your context?