0.3 Kennzeichnungen, Quellen und Versionsstände

Kurz erklärt

Dieses Buch unterscheidet zwischen offiziellen ITIL-Inhalten, allgemeinen Best Practices, zusätzlichen Praxisempfehlungen, technischen Herstellerangaben und Erfahrungsberichten.

Dadurch soll jederzeit erkennbar bleiben:

woher eine Information stammt,

wie verlässlich sie ist,

für welchen Anwendungsbereich sie gilt,

ob sie von einer bestimmten Version abhängt,

und ob sie vor der praktischen Anwendung zusätzlich geprüft werden muss.

Warum diese Unterscheidung wichtig ist

Nicht jede hilfreiche Aussage besitzt dieselbe Herkunft oder Verbindlichkeit.

Ein offizieller ITIL-Begriff hat eine andere Bedeutung als:

eine allgemeine Empfehlung für den IT-Betrieb,

ein Erfahrungswert eines Administrators,

eine Herstelleranleitung,

ein Community-Beitrag,

oder ein Ergebnis aus einer eigenen Testumgebung.

Werden diese Informationsarten vermischt, kann leicht der falsche Eindruck entstehen, dass eine persönliche Empfehlung eine offizielle ITIL-Vorgabe sei.

Dieses Buch trennt deshalb möglichst klar zwischen:

offiziellen Framework-Inhalten,

technischen Herstellerinformationen,

anerkannten Best Practices,

zusätzlichen Praxisempfehlungen,

Community-Erfahrungen,

und eigenen Tests.

Grundsatz

Eine hilfreiche Empfehlung muss nicht direkt aus ITIL stammen.

Sie muss jedoch eindeutig als Empfehlung erkennbar sein und darf nicht als offizielle Vorgabe dargestellt werden.

Die verwendeten Kennzeichnungen

Kennzeichnung	Bedeutung
ITIL-Grundlage	Begriff, Modell, Prinzip, Practice oder andere Aussage aus dem offiziellen ITIL-Framework
Offizielle Quelle	Aussage aus einer offiziellen Veröffentlichung, Norm oder Herstellerdokumentation
Best Practice	allgemein anerkannte und bewährte Vorgehensweise
Praxisempfehlung	zusätzliche Empfehlung für den konkreten Arbeitsalltag
Praxisbeispiel	vereinfachte oder realistische Situation zur Erklärung eines Zusammenhangs
Community-Hinweis	Erfahrungsbericht oder Lösungsansatz ohne gleichwertige offizielle Bestätigung
Eigener Test	Erkenntnis aus einer dokumentierten eigenen Testumgebung
Versionsabhängig	Aussage kann sich durch eine neue Version ändern
Umgebungsabhängig	Aussage gilt nur unter bestimmten technischen oder organisatorischen Bedingungen
Sicherheitsrelevant	Handlung oder Information kann die Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen
Betriebliche Vorgabe beachten	interne Regeln, Berechtigungen oder Freigabeprozesse können Vorrang haben
Nicht abschließend geprüft	Aussage oder Sonderfall benötigt noch eine zusätzliche fachliche Prüfung

Nicht jede Seite benötigt alle Kennzeichnungen.

Sie werden nur dort verwendet, wo sie zum Verständnis oder zur sicheren Anwendung beitragen.

ITIL-Grundlage

Die Kennzeichnung ITIL-Grundlage wird verwendet, wenn ein Inhalt unmittelbar aus dem ITIL-Framework stammt oder einen offiziellen ITIL-Begriff in eigenen Worten erklärt.

Beispiele:

Definition eines Service

Guiding Principles

ITIL Practices

Incident Management

Problem Management

Continual Improvement

Rollen, Modelle oder Wertströme aus dem Framework

Beispiel für die Verwendung:

ITIL-Grundlage

Incident Management konzentriert sich darauf, die negativen Auswirkungen von Störungen zu minimieren und den normalen Servicebetrieb möglichst schnell wiederherzustellen.

Eine solche Aussage wird nicht mit zusätzlichen technischen oder persönlichen Empfehlungen vermischt, ohne diese getrennt zu kennzeichnen.

Offizielle Quelle

Die Kennzeichnung Offizielle Quelle wird verwendet, wenn eine Aussage aus einer maßgeblichen Primärquelle stammt.

Dazu gehören beispielsweise:

offizielle ITIL-Veröffentlichungen,

offizielle PeopleCert-Veröffentlichungen,

Herstellerdokumentationen,

technische Produkthandbücher,

veröffentlichte Standards und Normen,

Sicherheitsrichtlinien anerkannter Behörden,

oder offizielle Dokumentationen eines Softwareprojekts.

Beispiele:

Thema	Bevorzugte offizielle Quelle
ITIL-Begriff oder ITIL-Modell	PeopleCert beziehungsweise offizielle ITIL-Publikation
Microsoft-Produkt	Microsoft Learn oder offizielle Produktdokumentation
Linux-Befehl	offizielle Manpage oder Projektdokumentation
Docker-Funktion	offizielle Docker-Dokumentation
Sicherheitsmaßnahme	Herstellerdokumentation, BSI oder einschlägiger Standard
Netzwerkstandard	veröffentlichter Standard oder RFC
Softwarekonfiguration	offizielle Dokumentation der verwendeten Version

Wichtig

Eine offizielle Quelle ist grundsätzlich zu bevorzugen, sie muss aber trotzdem zur konkreten Aussage passen.

Eine allgemeine Produktseite belegt beispielsweise nicht automatisch eine bestimmte Menüeinstellung oder technische Kompatibilität.

Best Practice

Eine Best Practice ist eine bewährte Vorgehensweise, die sich in vielen vergleichbaren Situationen als sinnvoll erwiesen hat.

Sie ist nicht automatisch:

gesetzlich vorgeschrieben,

technisch zwingend,

für jedes Unternehmen geeignet,

oder Bestandteil des offiziellen ITIL-Frameworks.

Beispiele:

Änderungen zunächst in einer Testumgebung prüfen

vor risikoreichen Änderungen einen Rückfallplan erstellen

wichtige Arbeitsschritte mit Zeitstempel dokumentieren

bei kritischen Störungen regelmäßige Statusmeldungen versenden

nach einer Wiederherstellung die Überwachung fortsetzen

wiederkehrende Lösungen als Wissensartikel dokumentieren

Best Practice

Eine bewährte Vorgehensweise muss an die Größe, Risiken, Prozesse und technische Umgebung des jeweiligen Unternehmens angepasst werden.

Praxisempfehlung

Eine Praxisempfehlung ergänzt das offizielle Framework um konkrete Hinweise für den Arbeitsalltag eines Systemintegrators.

Beispiel:

Praxisempfehlung

Notiere bei einer laufenden Störung mindestens:

Uhrzeit,

Beobachtung,

durchgeführte Maßnahme,

und Ergebnis.

Dadurch lässt sich der Ablauf später wesentlich leichter rekonstruieren.

Diese Empfehlung ist sinnvoll, aber nicht automatisch eine wörtliche ITIL-Vorgabe.

Praxisempfehlungen werden verwendet, wenn sie:

eine Handlung verständlicher machen,

typische Fehler vermeiden,

Risiken reduzieren,

die Zusammenarbeit verbessern,

oder eine spätere Dokumentation erleichtern.

Praxisbeispiel

Praxisbeispiele übertragen theoretische Inhalte auf eine realistische Arbeitssituation.

Beispiel:

Praxisbeispiel

Nach einem nächtlichen Update können sich mehrere Benutzer nicht mehr anmelden.

Technisch muss die Ursache untersucht werden. Aus Sicht des Service Managements müssen zusätzlich Auswirkung, Priorität, Kommunikation, Eskalation und Dokumentation berücksichtigt werden.

Praxisbeispiele sind nicht als vollständig vorgeschriebene Musterlösung zu verstehen.

Die tatsächliche Vorgehensweise hängt unter anderem ab von:

der technischen Umgebung,

den betroffenen Services,

der Anzahl der Benutzer,

bestehenden Verträgen,

internen Prozessen,

Sicherheitsanforderungen,

und vorhandenen Berechtigungen.

Community-Hinweis

Community-Beiträge können besonders bei seltenen Fehlern, undokumentierten Besonderheiten oder neuen Softwareproblemen hilfreich sein.

Mögliche Quellen sind:

Herstellerforen,

GitHub-Issues,

Fachforen,

technische Communities,

Diskussionsplattformen,

oder Erfahrungsberichte anderer Administratoren.

Ein Community-Beitrag ist jedoch kein sicherer Beleg dafür, dass:

die Lösung allgemein funktioniert,

die Ursache korrekt bestimmt wurde,

die Maßnahme vom Hersteller unterstützt wird,

die Vorgehensweise sicher ist,

oder sie zur eigenen Version und Umgebung passt.

Community-Hinweis

Ein Community-Beitrag kann einen wertvollen Lösungsansatz liefern.

Vor der Anwendung müssen Version, Umgebung, Risiken und mögliche Nebenwirkungen geprüft werden.

Community-Aussagen werden nach Möglichkeit mit offiziellen Quellen oder eigenen Tests abgeglichen.

Eigener Test

Die Kennzeichnung Eigener Test wird verwendet, wenn eine Aussage in einer selbst kontrollierten Umgebung praktisch geprüft wurde.

Eine solche Angabe sollte möglichst enthalten:

getestetes Produkt,

verwendete Version,

Betriebssystem oder Plattform,

relevante Konfiguration,

durchgeführte Schritte,

beobachtetes Ergebnis,

und Datum des Tests.

Beispiel:

Eigener Test

Die beschriebene Funktion wurde unter der angegebenen Softwareversion in einer Testumgebung erfolgreich geprüft.

Das Ergebnis bestätigt nicht automatisch die Funktion unter älteren Versionen, anderen Plattformen oder abweichenden Konfigurationen.

Merke

Ein erfolgreicher eigener Test belegt das Verhalten der getesteten Umgebung.

Er beweist nicht automatisch eine allgemeine oder offiziell unterstützte Kompatibilität.

Versionsabhängige Informationen

Technische und organisatorische Inhalte können sich durch neue Versionen verändern.

Dies betrifft beispielsweise:

ITIL-Versionen,

Betriebssysteme,

Softwareprodukte,

Firmware,

Menüpfade,

Programmierschnittstellen,

Befehlsoptionen,

Sicherheitsrichtlinien,

Zertifizierungsinhalte,

und Herstellerempfehlungen.

Versionsabhängige Angaben werden deshalb nach Möglichkeit mit folgenden Informationen versehen:

Angabe	Beispiel
Produkt oder Framework	ITIL
Version	Version 5
zusätzlich berücksichtigt	ITIL 4
fachlich geprüft am	August 2026
Quelle	offizielle PeopleCert-Veröffentlichung
mögliche Abweichung	ältere Begriffe oder Strukturen können weiterhin verwendet werden

Aktueller ITIL-Versionsstand dieses Buches

Stand August 2026 ist ITIL Version 5 die aktuelle Generation des Frameworks.

ITIL 4 ist weiterhin in offiziellen Angeboten und in vielen Unternehmen, Schulungsunterlagen, Prozessen und Zertifizierungen verbreitet.

Dieses Buch verwendet deshalb folgende Regeln:

Neue oder grundlegend überarbeitete Inhalte werden vorrangig anhand von ITIL Version 5 geprüft.

Weiterhin relevantes Wissen aus ITIL 4 bleibt erhalten.

Unterschiede zwischen ITIL 4 und ITIL Version 5 werden gekennzeichnet.

Begriffe aus ITIL 4 werden nicht automatisch als falsch oder unbrauchbar dargestellt.

Veraltete Begriffe werden nicht ohne Hinweis als aktueller Stand übernommen.

Prüfungswissen wird von allgemeinem Praxiswissen getrennt.

Versionsangaben werden ergänzt, wenn ein Unterschied für das Verständnis oder die praktische Anwendung wichtig ist.

Versionsabhängig

Ein Unternehmen kann weiterhin Prozesse, Begriffe und Werkzeuge verwenden, die sich an ITIL 4 oder einer noch älteren ITIL-Ausgabe orientieren.

Für die tägliche Arbeit ist deshalb nicht nur der aktuelle Framework-Stand wichtig, sondern auch die tatsächlich eingeführte Arbeitsweise des Unternehmens.

ITIL-Version und betriebliche Umsetzung unterscheiden

Die verwendete ITIL-Version bestimmt nicht automatisch, wie ein Unternehmen arbeitet.

Unternehmen können:

nur einzelne ITIL Practices verwenden,

eigene Prozessnamen besitzen,

ältere Begriffe weiterverwenden,

mehrere Frameworks kombinieren,

interne Rollen anders benennen,

oder ITIL nur als Orientierung nutzen.

Beispiel:

Ein Unternehmen kann einen Vorgang intern als „Störungsticket“ bezeichnen, obwohl im ITIL-Kontext der Begriff Incident verwendet wird.

Ein anderes Unternehmen kann ein Change Advisory Board einsetzen, obwohl nicht jeder Change zwingend durch ein solches Gremium bewertet werden muss.

Praxistipp

Prüfe beim Einstieg in ein Unternehmen immer:

welche Begriffe dort verwendet werden,

welche Prozesse tatsächlich gelten,

wer welche Verantwortung besitzt,

welche Freigaben erforderlich sind,

und wo die verbindlichen Arbeitsanweisungen dokumentiert sind.

Umgebungsabhängige Informationen

Eine technische Anleitung kann korrekt sein und trotzdem nicht zur eigenen Umgebung passen.

Mögliche Unterschiede sind:

Betriebssystem,

Softwareversion,

Hardwareplattform,

Netzwerkarchitektur,

Berechtigungsmodell,

Hochverfügbarkeitskonzept,

Cloud- oder On-Premises-Betrieb,

Sicherheitsrichtlinien,

Mandantenstruktur,

oder unternehmensinterne Konfiguration.

Beispiel:

Umgebungsabhängig

Der Neustart eines einzelnen Dienstes kann in einer Testumgebung unkritisch sein.

In einem Cluster, einer Hochverfügbarkeitsumgebung oder einem produktiven System kann derselbe Schritt zusätzliche Auswirkungen besitzen.

Vor technischen Eingriffen muss deshalb geprüft werden:

Gilt die Anleitung für die verwendete Version?

Ist die Systemrolle identisch?

Bestehen Abhängigkeiten zu anderen Services?

Gibt es Redundanz oder Hochverfügbarkeit?

Wird eine Freigabe benötigt?

Ist ein Rückfallplan vorhanden?

Kann die Änderung Benutzer oder andere Systeme beeinflussen?

Sicherheitsrelevante Inhalte

Sicherheitsrelevante Hinweise werden besonders gekennzeichnet.

Sie betreffen beispielsweise:

Benutzerkonten und Berechtigungen,

Kennwörter und Zugangsdaten,

Firewall-Regeln,

Verschlüsselung,

Protokollierung,

Backups,

Produktivsysteme,

personenbezogene Daten,

Sicherheitsvorfälle,

oder den Einsatz administrativer Befehle.

Sicherheitsrelevant

Eine technisch mögliche Handlung ist nicht automatisch zulässig oder sicher.

Vor der Ausführung müssen Berechtigung, Auswirkung, Datenschutz, betriebliche Vorgaben und Wiederherstellungsmöglichkeiten geprüft werden.

Sicherheitsrelevante Befehle oder Änderungen sollen nicht ohne Hinweise zu folgenden Punkten veröffentlicht werden:

Voraussetzungen,

benötigte Berechtigungen,

mögliche Auswirkungen,

Schutzmaßnahmen,

Rückfallmöglichkeit,

und notwendige Kontrolle nach der Durchführung.

Quellenhierarchie

Bei widersprüchlichen oder unterschiedlich verlässlichen Angaben wird folgende Reihenfolge als Orientierung verwendet:

geltendes Recht und verbindliche betriebliche Vorgaben

offizielle Normen, Standards und Sicherheitsanforderungen

offizielle ITIL- und PeopleCert-Veröffentlichungen

offizielle Hersteller- oder Projektdokumentation

bestätigte Hersteller-Supportaussage

anerkannte Fachliteratur

dokumentierte Best Practice

reproduzierbarer eigener Test

nachvollziehbarer Community-Bericht

unbestätigte Einzelmeinung oder Vermutung

Diese Reihenfolge ist keine starre Bewertung für jeden Einzelfall.

Die passende Quelle hängt von der jeweiligen Aussage ab.

Beispiel:

Für die Bedeutung eines ITIL-Begriffs ist eine offizielle ITIL-Publikation maßgeblich.

Für einen konkreten Menüpfad einer Software ist dagegen die aktuelle Herstellerdokumentation entscheidend.

Für einen Fehler, den der Hersteller nicht dokumentiert hat, können Community-Berichte und eigene Tests ergänzend wertvoll sein.

Wenn Quellen einander widersprechen

Widersprechen sich mehrere Quellen, wird nicht automatisch die zuerst gefundene Aussage übernommen.

Stattdessen wird geprüft:

Welche Quelle ist offiziell oder primär?

Auf welche Version bezieht sich die Aussage?

Wann wurde die Quelle veröffentlicht oder aktualisiert?

Behandeln die Quellen wirklich dieselbe Umgebung?

Wurde die Aussage durch Tests bestätigt?

Hat der Hersteller seine Empfehlung später geändert?

Ist möglicherweise nur eine bestimmte Konfiguration betroffen?

Kann der Widerspruch nicht eindeutig geklärt werden, wird er auf der Seite kenntlich gemacht.

Beispiel:

Nicht abschließend geprüft

Die verfügbaren Quellen beschreiben unterschiedliche Ergebnisse.

Die Abweichung kann mit der verwendeten Version oder Konfiguration zusammenhängen. Vor einer produktiven Anwendung ist ein eigener Test erforderlich.

Mindestangaben für Quellen

Eine Quelle sollte so angegeben werden, dass sie eindeutig wiedergefunden und bewertet werden kann.

Geeignete Angaben sind:

Herausgeber oder Hersteller,

Titel der Dokumentation,

behandelte Version,

Veröffentlichungs- oder Aktualisierungsdatum,

Abruf- oder Prüfdatum,

und betroffener Abschnitt.

Beispiel:

PeopleCert: ITIL FAQ – Frequently Asked Questions about ITIL
Behandelter Stand: ITIL Version 5
Fachlich geprüft: August 2026