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.
Ihr Download hat gestartet.
Hat nicht gestartet? Word-Datei erneut versuchen oder PDF abrufen.
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 / Werkzeug | Zweck | Verantwortlich | Kritikalitä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
| Begriff | Erklä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
| Rolle | Verantwortung |
|---|---|
| {{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)
| Schritt | Tätigkeit | Verantwortlich | Erwartetes 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 / Ausnahme | Maßnahme | Eskalation 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
| Version | Datum | Autor: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
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 / Werkzeug | Zweck | Verantwortlich | Kritikalität |
|---|---|---|---|
| Monitoring & Alarmierung | Erkennt SLO-Verletzungen und alarmiert | SRE | Kritisch |
| Bereitschaft / Alarmierung | Leitet den Alarm an die Bereitschaft weiter | SRE | Kritisch |
| Statusseite | Informiert Kund:innen über Auswirkungen | Support | Hoch |
| Störungskanal | Koordination in Echtzeit während der Störung | Engineering | Hoch |
4.Begriffe & Abkürzungen
| Begriff | Erklärung |
|---|---|
| Incident Commander (IC) | Die eine Person, die die Reaktion koordiniert (behebt nicht zwingend selbst) |
| SLO | Service Level Objective – das Zuverlässigkeitsziel, auf dem ein Alarm beruht |
| MTTR | Mittlere Zeit bis zur Behebung |
| Nachbetrachtung | Vorwurfsfreie Aufarbeitung nach der Behebung (Post-Incident Review) |
Schweregrade & Reaktionsziele
| Schweregrad | Definition | Reaktion | Behebungsziel |
|---|---|---|---|
| Sev1 | Kompletter Ausfall oder Datenrisiko; die meisten Kund:innen betroffen | IC + Bereitschaft sofort alarmieren | < 1 Stunde bis zur Eindämmung |
| Sev2 | Wichtige Funktion ausgefallen oder stark beeinträchtigt | Bereitschaft alarmieren | < 4 Stunden |
| Sev3 | Geringe oder teilweise Auswirkung; Workaround vorhanden | Ticket zu Geschäftszeiten | Nächster Werktag |
| Sev4 | Kosmetisch oder geringe Auswirkung | Backlog | Geplant |
5.Rollen & Verantwortlichkeiten
| Rolle | Verantwortung |
|---|---|
| Incident Commander | Koordiniert die Reaktion, verantwortet Entscheidungen und Zeitplan |
| Bereitschaftsingenieur:in | Analysiert und setzt Behebung oder Eindämmung um |
| Kommunikationsverantwortliche:r | Aktualisiert Statusseite und interne Beteiligte |
| SRE-Leitung | Prü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)
| Schritt | Tätigkeit | Verantwortlich | Erwartetes Ergebnis |
|---|---|---|---|
| 1 | Alarm bestätigen und prüfen, ob eine echte Störung vorliegt | Bereitschaftsingenieur:in | Störung erklärt oder Alarm als Fehlalarm geschlossen |
| 2 | Schweregrad festlegen und Incident Commander benennen | Bereitschaftsingenieur:in | Sev-Stufe gesetzt, IC benannt |
| 3 | Störungskanal öffnen und erste Statusmeldung veröffentlichen | Kommunikationsverantwortliche:r | Beteiligte und Kund:innen über Auswirkung informiert |
| 4 | Analysieren, eindämmen, dann beheben (Rollback, wenn schneller) | Bereitschaftsingenieur:in | Auswirkung auf Kund:innen gestoppt |
| 5 | Behebung erklären und Abschlussmeldung veröffentlichen | Incident Commander | Statusseite grün, Kanal geschlossen |
| 6 | Vorwurfsfreie Nachbetrachtung innerhalb von 3 Werktagen durchführen | SRE-Leitung | Ursache 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 / Ausnahme | Maßnahme | Eskalation an |
|---|---|---|
| Bereitschaft bestätigt nicht | An die zweite Bereitschaft, dann an die SRE-Leitung eskalieren | SRE-Leitung |
| Schweregrad unklar | Bis zum Gegenbeweis den höheren Schweregrad annehmen | Incident Commander |
| Verdacht auf Sicherheitsvorfall / Datenschutzverletzung | Auf Playbook IR-Security wechseln und Datenschutzbeauftragten informieren | Leitung Informationssicherheit |
11.Mitgeltende Dokumente & Referenzen
- IT-018 Change-Management
- Playbook IR-Security
- Runbooks der Bereitschaft
- Vorlage Nachbetrachtung (Post-Incident Review)
12.Änderungshistorie
| Version | Datum | Autor:in | Änderung |
|---|---|---|---|
| 1.0 | 1. Juni 2026 | SRE-Leitung | Erstfreigabe |
13.Freigabe
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
- Sehen Sie sich die IT-SOP inklusive Systemübersicht und Störungsbeispiel an.
- Als Word (.docx) oder PDF herunterladen oder den Text für Google Docs kopieren.
- 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.