IT-SOP Vorlage: Arbeitsanweisung für den IT-Betrieb

Eine IT-SOP für den echten Betrieb – Systeme, Berechtigungen, Change-Management und Störungsmanagement.

Teil unserer kostenlosen SOP-Vorlagen.

Word herunterladen (.docx)

PDF herunterladen Kostenlos · Keine Anmeldung · Kein Wasserzeichen

1.Titelblock & Dokumentenlenkung

SOP-Titel {{SOP-Titel}}
Dokumentennummer {{Dokumentennummer}}
Version {{Version}}
Gültig ab {{Gültig ab}}
Nächste Überprüfung {{Nächste Überprüfung}}
Dokumentenverantwortliche:r {{Dokumentenverantwortliche:r}}
Freigegeben durch {{Freigegeben durch}}

Dieser Block gehört auf Seite eins, damit jede:r das Dokument auf einen Blick prüfen kann – auch im Audit. Setzen Sie die nächste Überprüfung auf 6–12 Monate und benennen Sie genau eine verantwortliche Person.

2.Zweck

Beschreiben Sie in ein bis zwei Sätzen, warum es diesen Ablauf gibt und welches Ergebnis er bei korrekter Ausführung liefert.

Schreiben Sie das „Warum“, nicht die Schritte. Beispiel: „Diese Arbeitsanweisung stellt sicher, dass jede Kundenerstattung korrekt, richtlinienkonform und innerhalb von zwei Werktagen bearbeitet wird.“

3.Geltungsbereich

Legen Sie fest, für welche Teams, Standorte, Systeme und Situationen diese Arbeitsanweisung gilt – und nennen Sie ausdrücklich, was sie nicht abdeckt.

Klare Grenzen verhindern, dass die Anweisung auf falsche Fälle angewendet wird. Ausnahmen in einer eigenen Zeile nennen.

Betroffene Systeme & Werkzeuge

System / WerkzeugZweckVerantwortlichKritikalität
{{System}}{{Wofür es genutzt wird}}{{Team / Rolle}}{{Kritisch / Hoch / Niedrig}}
{{System}}{{Wofür es genutzt wird}}{{Team / Rolle}}{{Kritikalität}}
{{Identitäts- / Zugriffssystem}}{{SSO, MFA, Berechtigungsvergabe}}{{IT / Informationssicherheit}}{{Kritisch}}

Führen Sie die Systeme auf, die dieser Ablauf berührt, wer sie verantwortet und wie kritisch sie sind. Wer das führende System und seine:n Verantwortliche:n benennt, verhindert, dass Zugriffe, Änderungen und Störungen durchrutschen.

4.Begriffe & Abkürzungen

BegriffErklärung
{{Begriff}}{{Erklärung in einfacher Sprache}}
{{Abkürzung}}{{Wofür sie steht}}

Nur Begriffe erklären, die neue Kolleg:innen missverstehen könnten. Gibt es keine, Abschnitt behalten und „keine“ eintragen – Auditor:innen erwarten ihn.

5.Rollen & Verantwortlichkeiten

RolleVerantwortung
{{Rolle}}{{Wofür diese Rolle in diesem Ablauf verantwortlich ist}}
{{Rolle}}{{Wofür diese Rolle in diesem Ablauf verantwortlich ist}}

Verantwortung Rollen zuordnen, nicht Personen – so überlebt die SOP jeden Personalwechsel. Pro Rolle ein bis zwei Zeilen.

6.Voraussetzungen, Material & Ausrüstung

  • {{Zugang oder Berechtigung, die vor dem Start nötig ist}}
  • {{Werkzeug, System oder Login}}
  • {{Material oder Dokument, das vorliegen muss}}

Alles auflisten, was vor Schritt 1 bereit sein muss. Eine kurze Checkliste verhindert halb erledigte Durchläufe.

7.Sicherheit & Compliance

Nennen Sie die Schutzmaßnahmen sowie die Vorschriften, Betriebsanweisungen und internen Richtlinien, die dieser Ablauf einhalten muss.

Hat der Ablauf keinen Sicherheits- oder Compliance-Bezug, Abschnitt behalten und „entfällt“ eintragen. Betroffene Vorschriften, Betriebsanweisungen oder Richtlinien namentlich nennen.

8.Ablauf (Schritt für Schritt)

SchrittTätigkeitVerantwortlichErwartetes Ergebnis
1{{Mit einem Verb beginnen – eine Tätigkeit pro Schritt}}{{Rolle}}{{Woran man erkennt, dass es richtig gemacht wurde}}
2{{Nächste Tätigkeit}}{{Rolle}}{{Erwartetes Ergebnis}}
3{{Nächste Tätigkeit}}{{Rolle}}{{Erwartetes Ergebnis}}

Etwa 5–15 nummerierte Schritte. Jeder beginnt mit einem Verb, enthält genau eine Tätigkeit und ein beobachtbares Ergebnis, damit jede:r prüfen kann, ob der Schritt erledigt ist.

9.Qualitätsprüfung & Abnahmekriterien

  • {{Messbarer Prüfpunkt, der bestätigt, dass die Arbeit korrekt erledigt wurde}}
  • {{Zweites Abnahmekriterium}}

2–4 messbare Prüfpunkte – eine prüfende Person muss jeden mit einem klaren Ja oder Nein beantworten können.

10.Störungen & Ausnahmen

Störung / AusnahmeMaßnahmeEskalation an
{{Häufiger Fehler}}{{Korrekturmaßnahme}}{{Rolle / Ansprechperson}}
{{Sonderfall}}{{Wie damit umzugehen ist}}{{Rolle / Ansprechperson}}

Die Störungen aufnehmen, die tatsächlich vorkommen. Wer eskaliert bekommt, muss namentlich als Rolle stehen – sonst bleiben Ausnahmen liegen.

11.Mitgeltende Dokumente & Referenzen

  • {{Formular, Checkliste oder Richtlinie, auf der diese SOP aufbaut}}
  • {{Vor- oder nachgelagerte SOP}}

Formulare, Betriebsanweisungen, Richtlinien und angrenzende SOPs verlinken, die als Nächstes gebraucht werden.

12.Änderungshistorie

VersionDatumAutor:inÄnderung
1.0{{Gültig ab}}{{Dokumentenverantwortliche:r}}Erstfreigabe
{{Version}}{{Datum}}{{Autor:in}}{{Was geändert wurde}}

Bei jeder Änderung eine Zeile ergänzen. Die Zeile 1.0 ist als Beispiel vorausgefüllt.

13.Freigabe

Dokumentenverantwortliche:r Name Unterschrift Datum
Freigabe Name Unterschrift Datum

Beide Unterschriften bestätigen, dass der Ablauf korrekt ist und zur Anwendung freigegeben wird.

Ein ausgefülltes Beispiel für ein SaaS-/IT-Betriebsteam mit Sev1–Sev4-Matrix und Reaktionszielen.

1.Titelblock & Dokumentenlenkung

SOP-Titel Störungsmanagement Produktion (Incident Response)
Dokumentennummer IT-031
Version 1.0
Gültig ab 1. Juni 2026
Nächste Überprüfung 1. Dezember 2026
Dokumentenverantwortliche:r SRE-Leitung
Freigegeben durch Leitung Engineering

2.Zweck

Diese Arbeitsanweisung stellt sicher, dass Störungen in der Produktion schnell und einheitlich erkannt, kommuniziert und behoben werden, damit die Auswirkung auf Kund:innen minimal bleibt und aus jeder Störung gelernt wird.

3.Geltungsbereich

Gilt für kundenwirksame Ausfälle und Beeinträchtigungen der SaaS-Plattform von der Erkennung bis zur veröffentlichten Nachbetrachtung. Nicht abgedeckt sind Routineänderungen (IT-018) und Sicherheitsvorfälle, die das Playbook IR-Security auslösen.

Betroffene Systeme & Werkzeuge

System / WerkzeugZweckVerantwortlichKritikalität
Monitoring & AlarmierungErkennt SLO-Verletzungen und alarmiertSREKritisch
Bereitschaft / AlarmierungLeitet den Alarm an die Bereitschaft weiterSREKritisch
StatusseiteInformiert Kund:innen über AuswirkungenSupportHoch
StörungskanalKoordination in Echtzeit während der StörungEngineeringHoch

4.Begriffe & Abkürzungen

BegriffErklärung
Incident Commander (IC)Die eine Person, die die Reaktion koordiniert (behebt nicht zwingend selbst)
SLOService Level Objective – das Zuverlässigkeitsziel, auf dem ein Alarm beruht
MTTRMittlere Zeit bis zur Behebung
NachbetrachtungVorwurfsfreie Aufarbeitung nach der Behebung (Post-Incident Review)

Schweregrade & Reaktionsziele

SchweregradDefinitionReaktionBehebungsziel
Sev1Kompletter Ausfall oder Datenrisiko; die meisten Kund:innen betroffenIC + Bereitschaft sofort alarmieren< 1 Stunde bis zur Eindämmung
Sev2Wichtige Funktion ausgefallen oder stark beeinträchtigtBereitschaft alarmieren< 4 Stunden
Sev3Geringe oder teilweise Auswirkung; Workaround vorhandenTicket zu GeschäftszeitenNächster Werktag
Sev4Kosmetisch oder geringe AuswirkungBacklogGeplant

5.Rollen & Verantwortlichkeiten

RolleVerantwortung
Incident CommanderKoordiniert die Reaktion, verantwortet Entscheidungen und Zeitplan
Bereitschaftsingenieur:inAnalysiert und setzt Behebung oder Eindämmung um
Kommunikationsverantwortliche:rAktualisiert Statusseite und interne Beteiligte
SRE-LeitungPrüft die Einstufung und führt die Nachbetrachtung durch

6.Voraussetzungen, Material & Ausrüstung

  • Zugriff auf Monitoring, Logs und Deploy-/Rollback-Werkzeuge
  • Bereitschaftsplan aktuell und erreichbar
  • Zugriff auf Statusseite und Störungskanal
  • Runbooks für die häufigsten Fehlerbilder im Wiki verlinkt

7.Sicherheit & Compliance

Kundendaten durchgehend schützen: keine Geheimnisse oder personenbezogenen Daten in den Störungskanal einfügen, Datenschutzrichtlinie beachten. Besteht der Verdacht auf einen Sicherheitsvorfall oder eine Datenschutzverletzung, sofort das Playbook IR-Security auslösen und den Datenschutzbeauftragten informieren – die Meldefrist nach Art. 33 DSGVO beträgt 72 Stunden.

8.Ablauf (Schritt für Schritt)

SchrittTätigkeitVerantwortlichErwartetes Ergebnis
1Alarm bestätigen und prüfen, ob eine echte Störung vorliegtBereitschaftsingenieur:inStörung erklärt oder Alarm als Fehlalarm geschlossen
2Schweregrad festlegen und Incident Commander benennenBereitschaftsingenieur:inSev-Stufe gesetzt, IC benannt
3Störungskanal öffnen und erste Statusmeldung veröffentlichenKommunikationsverantwortliche:rBeteiligte und Kund:innen über Auswirkung informiert
4Analysieren, eindämmen, dann beheben (Rollback, wenn schneller)Bereitschaftsingenieur:inAuswirkung auf Kund:innen gestoppt
5Behebung erklären und Abschlussmeldung veröffentlichenIncident CommanderStatusseite grün, Kanal geschlossen
6Vorwurfsfreie Nachbetrachtung innerhalb von 3 Werktagen durchführenSRE-LeitungUrsache und Maßnahmen dokumentiert

9.Qualitätsprüfung & Abnahmekriterien

  • Schweregrad und IC wurden innerhalb des Reaktionsziels festgelegt
  • Kund:innen sahen bei jeder Sev1/Sev2 ein Update auf der Statusseite
  • Die Behebung ist in der Produktion verifiziert, nicht nur ausgerollt
  • Eine vorwurfsfreie Nachbetrachtung mit verantworteten Maßnahmen ist veröffentlicht

10.Störungen & Ausnahmen

Störung / AusnahmeMaßnahmeEskalation an
Bereitschaft bestätigt nichtAn die zweite Bereitschaft, dann an die SRE-Leitung eskalierenSRE-Leitung
Schweregrad unklarBis zum Gegenbeweis den höheren Schweregrad annehmenIncident Commander
Verdacht auf Sicherheitsvorfall / DatenschutzverletzungAuf Playbook IR-Security wechseln und Datenschutzbeauftragten informierenLeitung Informationssicherheit

11.Mitgeltende Dokumente & Referenzen

  • IT-018 Change-Management
  • Playbook IR-Security
  • Runbooks der Bereitschaft
  • Vorlage Nachbetrachtung (Post-Incident Review)

12.Änderungshistorie

VersionDatumAutor:inÄnderung
1.01. Juni 2026SRE-LeitungErstfreigabe

13.Freigabe

Dokumentenverantwortliche:r Name Unterschrift Datum
Freigabe Name Unterschrift Datum

IT-SOP: Aufbau und Inhalte

Eine Arbeitsanweisung für den IT-Betrieb ergänzt die Standardabschnitte um das, was IT-Prozesse besonders macht. Diese Vorlage gibt die Bausteine vor:

  • Betroffene Systeme mit Verantwortlichen und Kritikalität
  • Berechtigungen nach minimalen Rechten, MFA und Change-Management
  • Ablauf Schritt für Schritt mit Verantwortlichkeit und Ergebnis
  • Schweregrade, Eskalation und Nachbetrachtung im Beispiel
  • Mitgeltende Dokumente: Runbooks, Playbooks, Änderungshistorie

Vorlage als Word oder PDF herunterladen

Sehen Sie sich die vollständige Vorlage auf der Seite an und laden Sie sie als Word-Datei (.docx) oder PDF herunter – oder kopieren Sie den Text für Google Docs. Kostenlos, ohne Anmeldung und ohne Wasserzeichen.

So funktioniert es

  1. Sehen Sie sich die IT-SOP inklusive Systemübersicht und Störungsbeispiel an.
  2. Als Word (.docx) oder PDF herunterladen oder den Text für Google Docs kopieren.
  3. Systeme und Verantwortliche eintragen, Berechtigungs- und Change-Regeln festlegen und die Schweregrad-Matrix an Ihren Service anpassen.

Häufig gestellte Fragen

Was gehört in eine IT-SOP?

Eine IT-Arbeitsanweisung benennt die betroffenen Systeme und Werkzeuge mit Verantwortlichen, die Regeln für Berechtigungen und Change-Management sowie einen Ablauf Schritt für Schritt mit Prüfpunkten. Diese Vorlage ergänzt die Standardabschnitte um eine Systemübersicht und einen Hinweis zu minimalen Rechten und Change-Management – mit einem ausgefüllten Beispiel zum Störungsmanagement.

Was ist eine Schweregrad-Matrix für Störungen?

Eine Schweregrad-Matrix stuft Störungen – meist Sev1 bis Sev4 – nach Auswirkung auf Kund:innen ein und legt je Stufe Reaktions- und Behebungsziel fest. Sie sagt der Bereitschaft, wie schnell sie reagieren und wen sie einbeziehen muss. Das Beispiel enthält eine Sev1–Sev4-Tabelle mit Reaktionszielen.

Was ist der Unterschied zwischen SOP und Runbook?

Eine SOP legt fest, wie ein wiederkehrender Ablauf mit Rollen, Geltungsbereich und Prüfpunkten durchgeführt wird. Ein Runbook ist die konkretere, oft befehlsgenaue Schrittfolge für eine Aufgabe oder einen Alarm. Üblich ist eine übergeordnete SOP, die die Runbooks im Abschnitt „Mitgeltende Dokumente“ verlinkt – genau dafür hat diese Vorlage einen Abschnitt.

Warum betont eine IT-SOP minimale Rechte und MFA?

Minimale Rechte und Multi-Faktor-Authentifizierung begrenzen den Schaden, wenn ein Konto kompromittiert wird, und halten jede Aktion einer Person zuordenbar – beides sind Basismaßnahmen nach BSI IT-Grundschutz und ISO 27001 und häufige Prüfpunkte im Audit. Die Vorlage nennt sie in einem eigenen Hinweis, damit sie nicht implizit bleiben.