ISO 27001 für IT-Dienstleister: Was Systemhäuser und MSPs wirklich brauchen

Montagmorgen, kurz nach neun. Ein Kunde ruft an, weil sein Dienst angeblich gestört ist. Ein anderer schreibt dem Geschäftsführer direkt, dass bitte noch heute zwei Tenant-Admins eingerichtet werden sollen. Im Teamchat meldet jemand denselben Fehler, den ein erfahrener Techniker schon fünfmal mit einem Neustart behoben hat. Und irgendwo dazwischen fällt der Satz: „Das könnte eigentlich ein Bug in unserem selbst entwickelten Kunden-Tool sein. Sagt das mal der Entwicklung.“

Im Ticketsystem steht davon ungefähr die Hälfte. Auch deswegen, weil nicht alle Kunden damit arbeiten wollen. Ob die Admin-Anfrage zum Vertrag gehört, als Projekt abgerechnet wird oder einfach mitgemacht wird, entscheidet man wie beim letzten Mal: nach ein bisschen Diskussion. Vielleicht dieses Mal halt nur mit anderen Leuten als beim letzten Mal.

Wenn Ihnen das bekannt vorkommt, sind Sie trotzdem im richtigen Artikel. Sie suchen nach ISO 27001 für IT-Dienstleister, Systemhäuser oder Managed Service Provider – und genau darum geht es hier. Sie müssen keine zweijährige Reorganisation durchführen und Ihr Unternehmen auf links drehen. Sie müssen aber klären, welche sicherheitsrelevanten Leistungen Sie für Kunden erbringen und wie Sie diese beherrschen. Sonst bleibt ausgerechnet Ihr Kerngeschäft im ISMS eine ziemlich große Nebelbank.

Die kurze Antwort

Für IT-Dienstleister gibt es keine besondere ISO 27001-Zertifizierung. Sie bauen wie andere Unternehmen ein Informationssicherheitsmanagementsystem auf: mit einem definierten Anwendungsbereich, einer Informationssicherheitspolitik, klaren Verantwortlichkeiten, systematischem Risikomanagement, passenden Maßnahmen, internen Überprüfungen, Managementbewertung und schließlich dem Zertifizierungsaudit.

Die Besonderheit steckt in Ihrem Geschäftsmodell. Sie betreiben Systeme, Anwendungen, Netze oder Cloud-Umgebungen für Kunden. Ihre Mitarbeiter besitzen häufig privilegierte Zugänge, verändern Konfigurationen, beheben Störungen, spielen Updates ein und können Daten einsehen oder wiederherstellen. Damit ist Ihr Kundenbetrieb einer der sicherheitsrelevantesten Prozesse im Unternehmen.

ISO 27001 verlangt nicht, dass dieser Betrieb einem bestimmten Framework folgt. Sie müssen ihn aber planen und steuern können. Wenn bei jeder Kundenanfrage neu entschieden wird, was Sie leisten, wer zuständig ist und welche Freigabe erforderlich ist, wird genau das schwierig.

Was IT-Dienstleister für ISO 27001 grundsätzlich brauchen

Der grundlegende Projektweg unterscheidet sich nicht dramatisch von dem anderer Unternehmen.

1. Anwendungsbereich festlegen: Welche Organisationseinheiten, Standorte, Leistungen, Systeme und Teams gehören zum ISMS?
2. Kontext und Anforderungen verstehen: Was erwarten Kunden, Verträge, Gesetze und weitere interessierte Parteien?
3. Das eigene Fulfillment strukturiert aufbauen: Die Abläufe müssen so gestaltet sein, dass die Erwartungen und Anforderungen aus Punkt 2 zuverlässig erfüllt werden.
4. Risiken bewerten: Welche Informationen sind gefährdet, wodurch und mit welchen möglichen Auswirkungen?
5. Risiken behandeln: Welche organisatorischen und technischen Maßnahmen sind nötig?
6. ISMS betreiben: Verantwortlichkeiten, Ziele, Regeln, Prozesse und Nachweise im Alltag verankern.
7. Wirksamkeit prüfen: Kennzahlen, Internes Audit, Managementbewertung und Korrekturmaßnahmen durchführen.
8. Zertifizierung durchlaufen: Stufe 1 und Stufe 2 des Zertifizierungsaudits bestehen.

Für einen IT-Dienstleister kommt allerdings eine sehr praktische Vorfrage hinzu: Was genau gehört zu den Leistungen, deren Informationssicherheit Sie steuern wollen?

Warum Ihr Geschäftsmodell besonders sicherheitsrelevant ist

Typische Tätigkeiten innerhalb des Fulfillments (s.o.) bei IT-Systemhäusern, IT-Dienstleistern und MSPs sind beispielsweise:

• Benutzer und privilegierte Konten anlegen oder ändern;
• Firewalls, Netze, Endgeräte und Server konfigurieren;
• Backups erstellen und Daten wiederherstellen;
• Patches, Updates und Releases einspielen;
• Protokolle und Kundendaten zur Fehleranalyse einsehen;
• Störungen priorisieren und Notfallmaßnahmen auslösen;
• Cloud-Dienste und Lieferanten für Kunden steuern.

Jede dieser Tätigkeiten kann Vertraulichkeit, Integrität oder Verfügbarkeit beeinflussen. Eine allgemeine Richtlinie für sicheren Betrieb genügt daher nicht, wenn ansonsten weiter nach Tagesform entschieden wird.

Auch eine gute Informationssicherheitspolitik gibt nur die Richtung vor. Im Betrieb muss daraus erkennbares Handeln werden.

Was bedeutet „Betrieb“ bei Ihnen eigentlich?

Viele Leistungsbeschreibungen enthalten Wörter wie Betrieb, Support, Managed Service oder Betreuung. Das klingt plausibel, sagt aber noch erstaunlich wenig.

Gehört das Einrichten eines neuen Tenant-Admins dazu? Darf der Kunde eine Firewalländerung einfach per E-Mail bestellen? Ist eine Wiederherstellung im Monatspreis enthalten? Analysieren Sie Anwendungsfehler oder nur die Infrastruktur? Pflegen Sie die Kundendokumentation? Wer entscheidet, ob ein wiederkehrender Fehler an die Entwicklung oder einen Hersteller geht?

Wenn die Antwort immer lautet „Das schauen wir uns dann an, wir rechnen ja nach Stunden ab“, ist die Leistung nicht flexibel beschrieben. Sie ist undefiniert.

Dabei dürfen sich Leistungen selbstverständlich je Kunde unterscheiden. Genau dafür gibt es eine sinnvolle Abstufung:

• Servicekatalog: Welche standardisierten Leistungen bieten Sie grundsätzlich an? Welche sind verpflichtend, welche optional? Welche können nur gemeinsam, welche auch einzeln gebucht werden?
• Vertrag und Leistungsbeschreibung: Welche dieser Leistungen hat der konkrete Kunde beauftragt, mit welchen Grenzen und Servicezeiten?
• Betriebsführungshandbuch: Wie wird die vereinbarte Leistung in der konkreten Kundenumgebung umgesetzt – mit Systemen, Rollen, Kontakten, Übergaben und Besonderheiten?

Kunden dürfen unterschiedliche Leistungen erhalten. Die Unterschiede sollten nur bewusst gestaltet werden, statt bei jedem Ticket neu diskutiert werden zu müssen.

Der Selbsttest: Erkennen Sie Ihren Betrieb wieder?

Ein undefinierter Betrieb lässt sich meistens an sehr konkreten Gewohnheiten erkennen:

• Kundenanfragen kommen per E-Mail, Telefon, Chat, Herstellerportal oder direkt beim Lieblingsmitarbeiter an.
• Nicht jede Anfrage landet in einer gemeinsamen Liste oder im Ticketsystem.
• Mitarbeiter entscheiden spontan, ob eine gewünschte Leistung zum Vertrag gehört.
• Ein Time-and-Material-Vertrag wird als offene Einladung für beliebige Tätigkeiten verstanden.
• Service Requests und Incidents werden nicht unterschieden.
• Jede behauptete Störung erhält dieselbe Behandlung, egal ob Fehlbedienung, Konfigurationswunsch oder Dienstausfall.
• Sobald der Dienst wieder läuft, gilt das Incident-Ticket als erledigt – auch wenn die Ursache unbekannt bleibt.
• Wiederkehrende Fehler werden nicht als Problem analysiert.
• Bekannte Lösungen existieren in Köpfen, alten Chats oder persönlichen Notizen.
• Ein möglicher Bug erreicht die Entwicklung per Zuruf und ohne verbindliche Rückmeldung.
• Zwischen Problem, Entwicklungsaufgabe, Change, Test und Release besteht keine nachvollziehbare Verbindung.
• Niemand kann vollständig zeigen, welche Änderungen in einer Kundenumgebung auf wessen Auftrag vorgenommen wurden.

Wenn Sie sich mehrfach wiedererkennen, haben Sie wahrscheinlich kein reines Dokumentationsproblem. Ihr Betrieb ist schwerer steuerbar, als er sein müsste.

Warum das kein Nebenthema der ISO 27001 ist

Ein ISMS soll Informationssicherheitsrisiken nicht nur beschreiben, sondern beherrschen. Dafür müssen Sie wissen, welche Tätigkeiten, Informationen, Systeme, Personen und externen Leistungen beteiligt sind.

Nehmen wir die spontane Einrichtung eines Tenant-Admins. Für eine saubere Entscheidung wären mindestens folgende Fragen relevant:

• Ist diese Leistung vereinbart?
• Darf der Anfragende sie autorisieren?
• Welches System und welcher Kunde sind betroffen?
• Welche Rechte soll das Konto erhalten?
• Wer prüft und genehmigt die Vergabe?
• Wie wird die Änderung dokumentiert?
• Muss der Kunde anschließend informiert werden?

Wenn solche Fragen jedes Mal improvisiert werden, entsteht nicht nur Aufwand. Es steigt das Risiko, dass eine Anfrage aus dem falschen Kanal, vom falschen Absender oder ohne ausreichende Freigabe umgesetzt wird.

Dasselbe gilt bei Störungen. Ein operativer Incident im Sinne des IT-Service-Managements ist nicht automatisch ein Informationssicherheitsvorfall. Er kann aber einer sein oder sich zu einem entwickeln. Deshalb braucht der Betrieb einen geregelten Übergang zum Umgang mit IT-Security-Vorfällen. Wer Meldungen nicht klassifiziert, erkennt auch diese Schwelle nur zufällig.

Abschnitt 8.1: Prozesse planen und steuern

Abschnitt 8.1 der ISO 27001 bildet für dieses Thema die Klammer. Verkürzt verlangt er, dass die Organisation die notwendigen Prozesse zur Erfüllung der Anforderungen und zur Umsetzung der in Abschnitt 6 festgelegten Maßnahmen plant, verwirklicht und steuert.

Oder noch kürzer: „Notwendige Prozesse müssen geplant und gesteuert werden.“

Die Norm schreibt damit nicht vor, dass Sie ITIL einführen, einen Servicekatalog mit hundert Positionen bauen oder für jede Kleinigkeit eine mehrseitige Prozessbeschreibung verfassen. Sie verlangt auch kein bestimmtes Ticketsystem. Sie erwartet aber ein belastbares Vorgehen dort, wo Prozesse für das ISMS und die Risikobehandlung notwendig sind. Belastbar bedeutet: Es ist bekannt und kann im Zweifelsfall nachgeschlagen werden.

Wenn Ihr Unternehmen als Kerngeschäft IT für Kunden betreibt, werden Sie nicht erklären können, warum ausgerechnet dieser Prozess auf Zuruf läuft. Das gilt umso mehr, wenn Ihre Risikobehandlung auf geregelte Zugriffsvergabe, Änderungskontrolle, Protokollierung, Störungsbearbeitung oder Wiederherstellung setzt.

Warum Einzelfallentscheidungen die Risikoanalyse aufblasen

Flexibilität ist für IT-Dienstleister wichtig. Undefiniertheit ist etwas anderes.

Wenn jeder Kundenwunsch eine grundsätzlich neue Leistung sein kann, müssen Sie gedanklich immer wieder prüfen:

• Entsteht Zugriff auf neue Informationen?
• Kommt ein weiteres System oder Asset hinzu?
• Verändert sich eine Verantwortlichkeit?
• Wird ein neuer Lieferant beteiligt?
• Brauchen Mitarbeiter zusätzliche Rechte?
• Ändern sich Verfügbarkeit oder Wiederherstellungsanforderungen?
• Entsteht eine neue vertragliche oder rechtliche Anforderung?
• Reichen die bestehenden Sicherheitsmaßnahmen weiterhin aus?

Für jedes Ticket braucht es dann schon fast eine eigene Risikoanalyse. Ohne standardisierte Leistungen und Entscheidungskriterien prüfen Ihre Mitarbeiter dieselben Risikofragen ständig informell neu – oder gar nicht.

Ein Servicekatalog bündelt wiederkehrende Entscheidungen. Für einen definierten Service können Sie Risiken, notwendige Freigaben, Standardabläufe, Nachweise und Grenzen einmal sauber gestalten. Kundenspezifische Abweichungen werden dann als Abweichungen sichtbar. Genau dadurch wird Risikomanagement skalierbar.

Was ein geordneter IT-Betrieb mindestens braucht

Sie benötigen keine Service-Management-Kathedrale. Für einen belastbaren Anfang reichen acht Bausteine.

1. Definierte Services

Benennen Sie wiederkehrende Leistungen so, dass Mitarbeiter und Kunden dasselbe darunter verstehen. Dazu gehören Zweck, enthaltene Tätigkeiten, Voraussetzungen und klare Grenzen.

2. Kundenspezifische Leistungsgrenzen

Halten Sie fest, welche Services der Kunde beauftragt hat und wie sie in seiner Umgebung erbracht werden. Ein Betriebsführungshandbuch kann Architektur, Kontakte, Wartungsfenster, Eskalationen und Besonderheiten zusammenführen.

3. Ein geregelter Eingang

Kunden dürfen mehrere Kontaktmöglichkeiten haben. Entscheidend ist, dass jeder relevante Vorgang zuverlässig in einer gemeinsamen Arbeitsliste landet. Sonst fehlen Überblick, Priorisierung und Nachweis.

4. Sinnvolle Klassifikation

Ein Service Request bestellt eine vereinbarte Leistung. Ein Incident meldet eine Störung oder Qualitätsminderung. Ist dafür bereits eine bekannte Lösung oder ein Workaround dokumentiert, wird diese im Incident angewendet. Fehlt beides, wird in diesem vereinfachten Betriebsprozess zusätzlich ein Problem-Ticket eröffnet: Ursache und Lösung werden ermittelt und dokumentiert, damit der Incident gelöst werden kann und beim nächsten Auftreten eine bekannte Lösung bereitsteht.

5. Besitzer, Kriterien und Eskalationen

Legen Sie fest, wer einen Vorgang übernimmt, was ohne zusätzliche Freigabe erledigt werden darf und wann Sicherheit, Geschäftsleitung, Kunde oder Entwicklung beteiligt werden müssen.

6. Dokumentierte bekannte Lösungen

Wiederkehrende Lösungen gehören in eine gepflegte Wissensbasis. Ein neuer Mitarbeiter soll nicht erst zufällig den einen Kollegen finden müssen, der den geheimen Neustart kennt.

7. Ein geregelter Weg zu Bug, Change und Release

Ein Problem mit Produktursache benötigt eine nachvollziehbare Übergabe an die Entwicklung. Daraus können Bug, Priorisierung, Änderung, Test und Release entstehen. Der ursprüngliche Betriebsvorgang darf auf diesem Weg nicht verschwinden.

8. Nachvollziehbare Tickets und Nachweise

Das Ticket sollte zeigen, wer was wann warum entschieden und ausgeführt hat. Das hilft dem Kundenservice, dem ISMS und später auch dem Auditor. Welche Form dokumentierte Information annehmen kann, erläutert unser Artikel über praxistaugliche ISO 27001-Dokumentation.

Dafür müssen Sie kein ITIL-Projekt starten

Die Begriffe Service Request, Incident, Problem, Known Error und Change haben wir uns nicht für Ihren Auditordner ausgedacht. Sie stammen aus dem etablierten IT-Service-Management. ITIL ist ein bekanntes Best-Practice-Framework; ISO/IEC 20000-1 ist die internationale Norm für Service-Managementsysteme.

Sie müssen weder das gesamte Framework einführen noch eine weitere Zertifizierung anstreben. Bewährte Begriffe sind nur praktischer, als dieselben Strukturen unter neuen Namen selbst zu erfinden.

Ein neuer Service-Desk-Mitarbeiter erkennt Begriffe wie Incident, Problem und Change wieder und orientiert sich schnell. Auch Kunden und Partner verstehen standardisierte Übergaben schneller.

Dasselbe gilt für KI. Eine KI kann Tickets klassifizieren, passende bekannte Lösungen vorschlagen und Wissen leichter auffindbar machen. Aber sie braucht eine brauchbare Datenbasis. Wenn Lösungen nur in Mitarbeiterköpfen, privaten Chats und drei verschiedenen Postfächern liegen, automatisiert auch die beste KI vor allem das Suchen im Nebel.

Sie beginnen nicht bei null

Die meisten IT-Dienstleister besitzen bereits technische Mitarbeiter, Verträge, Tickets, Monitoring, Backupwerkzeuge, Checklisten und jahrelange Erfahrung. Häufig existieren gute Abläufe – nur nicht einheitlich, vollständig beschrieben oder über alle Kunden hinweg angewendet.

Auch vorhandenes Logging und Monitoring kann eine starke Grundlage sein. Es muss nur mit klaren Verantwortlichkeiten und Reaktionswegen verbunden werden. Ein Dashboard erkennt noch keine Störung; ein Mitarbeiter muss wissen, welches Ereignis welche Bearbeitung auslöst.

Das ISO-Projekt muss Ihren Betrieb nicht neu erfinden. Es muss vorhandene Praxis sichtbar machen, vereinheitlichen und absichern.

So gehen Sie pragmatisch vor

Starten Sie nicht mit einem 80-seitigen Prozesshandbuch. Nehmen Sie stattdessen die letzten 50 bis 100 Kundenanfragen und sortieren Sie sie.

1. Welche wiederkehrenden Leistungen erbringen Sie?
2. Welche davon sind vereinbart?
3. Welche waren Service Requests, welche Incidents und welche hätten als Problem weiterverfolgt werden müssen?
4. Über welche Kanäle kamen sie herein?
5. Wo fehlten Freigabe, Zuständigkeit oder Nachweis?
6. Welche Lösungen wurden mehrfach neu gesucht?
7. Welche Vorgänge hätten Entwicklung oder Sicherheitsverantwortliche erreichen müssen?

Aus dieser Stichprobe entsteht ein realistisches Bild Ihres Betriebs. Definieren Sie danach zunächst die häufigsten und sicherheitsrelevantesten Services. Richten Sie einen verlässlichen Eingang und wenige klare Kategorien ein. Benennen Sie Verantwortliche und Übergaben. Erst dann schreiben Sie das auf, was im Alltag tatsächlich funktionieren soll.

Sie brauchen dafür übrigens nicht zwangsläufig eine neue ISO-Software. Häufig können vorhandene Werkzeuge die nötigen Regeln, Aufgaben und Nachweise abbilden. Unser Beitrag zur Software für ISO 27001 zeigt, worauf es dabei wirklich ankommt.

Die nächsten Artikel dieser Serie

Dieser Beitrag beschreibt das Gesamtproblem. Die folgenden Artikel gehen jeweils eine Ebene tiefer – weiterhin aus Sicht von IT-Dienstleistern, Systemhäusern und MSPs:

• Servicekatalog, Vertrag und Betriebsführungshandbuch sauber unterscheiden;
• Kundenwunsch, Service Request oder Incident richtig einordnen;
• Incident lösen und Probleme trotzdem weiterverfolgen;
• einen geregelten Eingang und eine vollständige Ticketlage schaffen;
• Known Solutions, Wissensmanagement und KI sinnvoll verbinden;
• vom Problem über Bug und Change bis zum Release kommen;
• einen geordneten IT-Service für ISO 27001 nutzbar machen.

Sie müssen dafür keine theoretische Service-Management-Welt aufbauen. Sie brauchen eine Betriebsstruktur, die zu Ihren Leistungen passt, von Mitarbeitern verstanden wird und Ihre Sicherheitsmaßnahmen zuverlässig in den Kundenalltag bringt.

Interesse geweckt?

Sie möchten ISO 27001 erreichen und dabei Ihren Kundenbetrieb pragmatisch so ordnen, dass er im Alltag und im Audit trägt? Sprechen Sie mit uns