Kundenanfragen verschwinden: Brauchen IT-Dienstleister für ISO 27001 ein Ticketsystem?

Der Kunde ruft seinen Lieblingsadministrator direkt an: „Unser Backup meldet seit heute Morgen einen Fehler. Kannst du mal schauen?“

Der Administrator sagt: „Ja, mache ich nach meinem Termin.“ Dann meldet ein anderer Kunde einen größeren Ausfall, die Mittagspause fällt aus und am nächsten Morgen liegt der Administrator mit Fieber im Bett.

Im Ticketsystem steht nichts. Im gemeinsamen Postfach steht nichts. Der Rest des Teams weiß nicht einmal, dass es eine Aufgabe gibt. Die Information über den fehlerhaften Backupjob liegt ausschließlich im Gedächtnis eines kranken Mitarbeiters – und ist damit für das Unternehmen ungefähr so gut verfügbar wie dessen Wohnungsschlüssel.

Vier Wochen später braucht der Kunde eine Wiederherstellung. Die neuesten wiederherstellbaren Daten sind jetzt fast einen Monat alt. Der Ärger ist groß.

Das ist kein exotischer Auditfall. Es ist ganz gewöhnlicher schlechter Betrieb. Und es zeigt, warum geregelte Kommunikation für IT-Dienstleister unmittelbar mit Informationssicherheit zusammenhängt.

Die kurze Antwort

ISO 27001 schreibt kein Ticketsystem und kein bestimmtes Helpdesk-Produkt vor. Sie verlangt aber, dass die für das ISMS relevante interne und externe Kommunikation geregelt ist und Informationen auf angemessenen Wegen übertragen werden.

Für einen IT-Dienstleister bedeutet das praktisch: Kunden dürfen per Telefon, E-Mail, Portal oder gegebenenfalls Chat Kontakt aufnehmen. Aber jede relevante Meldung braucht einen verlässlichen Weg in eine gemeinsame Arbeitslage. Dort muss sie für die zuständigen Mitarbeiter verfügbar sein, übernommen, priorisiert und bis zur Erledigung verfolgt werden können.

Nicht jeder erlaubte Kommunikationskanal muss selbst das Ticketsystem sein. Aber jeder relevante Eingang braucht einen geregelten Weg hinein.

Bei einem sehr kleinen Systemhaus kann anfangs ein gemeinsames Postfach mit einer verbindlich gepflegten Aufgabenliste genügen. Wenn mehrere Mitarbeiter, Kunden, Servicezeiten und Prioritäten zusammenkommen, ist ein richtiges Ticketsystem meistens schlicht die vernünftigere Lösung.

Eine verlorene Kundenmeldung ist ein Verfügbarkeitsproblem

Beim Schutz von Informationen denken viele zuerst an Vertraulichkeit. Niemand soll das Admin-Passwort lesen, der Kundenbericht soll verschlüsselt übertragen werden und die Logdatei gehört nicht in einen öffentlichen Chat. Alles richtig.

Informationen müssen aber auch verfügbar sein. Das bedeutet nicht, dass jede Nachricht jederzeit weltweit abrufbar sein muss. Es bedeutet, dass die Organisation auf eine Information zugreifen kann, wenn sie diese für ihre Aufgabe benötigt.

Die telefonische Meldung über den fehlerhaften Backupjob ist eine Information. Sie ist für den Betrieb sogar ziemlich wichtig. Wenn sie nur im Kopf des angerufenen Administrators liegt, steht sie dem übrigen Unternehmen nicht zur Verfügung. Dasselbe gilt für eine Nachricht im persönlichen E-Mail-Postfach, einen privaten Chat oder einen Zettel unter der Tastatur.

Aus der fehlenden Verfügbarkeit entstehen sehr bodenständige Folgen:

• Niemand kann die Aufgabe bei Urlaub, Krankheit oder Überlastung übernehmen.
• Die Meldung kann nicht nach Auswirkungen und Dringlichkeit priorisiert werden.
• Es gibt keine Wiedervorlage und keine Eskalation, wenn sie liegen bleibt.
• Andere Mitarbeiter bearbeiten möglicherweise denselben Sachverhalt doppelt.
• Der genaue Wortlaut des Kunden wird beim Weitererzählen verkürzt oder verändert.
• Niemand erkennt, ob eine zugesagte Reaktionszeit bereits läuft.
• Ein betroffener Kundendienst bleibt länger gestört, weil schon die Information über die Störung verschwunden ist.

Der Kunde erlebt am Ende nicht „mangelnde Verfügbarkeit einer Information“. Er erlebt: „Ich habe das gestern gemeldet und heute sagt man mir, bei Ihnen weiß niemand davon. Geht's noch?“

Das ist dieselbe Sache in weniger festlicher Sprache.

Abschnitt 7.4: Kommunikation braucht einen vorgesehenen Weg

Abschnitt 7.4 der ISO 27001 verlangt, die für die Informationssicherheit relevante interne und externe Kommunikation zu bestimmen. Unser separater Artikel über die Kommunikation im ISMS nach Abschnitt 7.4 erklärt die Anforderung ausführlich. Für den Kundenbetrieb eines MSP oder Systemhauses lässt sie sich sehr praktisch anwenden.

Eine Meldung über einen Ausfall, einen fehlerhaften Backupjob, einen verdächtigen Zugriff oder eine gewünschte Änderung kann für Informationssicherheit und Leistungserbringung relevant sein. Deshalb sollte feststehen:

• welche Kontaktwege Kunden nutzen dürfen;
• welche Meldungen sofort dokumentiert werden müssen;
• wer Telefonate und persönliche Nachrichten in einen gemeinsamen Vorgang überführt;
• wann eine Meldung bestätigt oder zurückgefragt wird;
• wie dringende oder sicherheitsrelevante Inhalte eskaliert werden;
• wer mit dem Kunden über Bearbeitung und Ergebnis kommuniziert.

Das verlangt keine zwölfseitige Kommunikationsmatrix. Eine klare Regel im Betriebsprozess reicht häufig: „Jede betriebliche Kundenanfrage wird unverzüglich im Ticketsystem erfasst. Wer sie über einen anderen zugelassenen Kanal entgegennimmt, eröffnet das Ticket.“

Damit ist auch die unselige Diskussion beendet, ob der Kunde „schuld“ sei, weil er beim falschen Mitarbeiter angerufen hat. Wenn Sie den Anruf als Kontaktweg akzeptieren, brauchen Sie intern einen funktionierenden Übergang. Der Kunde muss Ihr Organigramm nicht auswendig lernen.

A.5.14: Auch Verfügbarkeit gehört zum Schutz der Übertragung

ISO 27001 A.5.14 behandelt die Übermittlung von Informationen innerhalb der Organisation und zwischen der Organisation und anderen Parteien. Dafür sollen angemessene Regeln, Verfahren oder Vereinbarungen bestehen.

Häufig wird diese Maßnahme fast ausschließlich als Frage der Verschlüsselung gelesen: Darf die Datei per E-Mail verschickt werden? Muss der Anhang geschützt sein? Wie wird der Empfänger geprüft? Unser ausführlicher Artikel über die sichere Informationsübermittlung nach A.5.14 behandelt diese Themen.

Für Kundenmeldungen ist aber noch eine andere Frage wichtig: Kommt die Information so an, dass die Organisation anschließend darauf zugreifen und reagieren kann?

Ein Telefonat überträgt Information. Eine persönliche E-Mail ebenfalls. Der Übertragungsweg endet nur nicht sinnvoll damit, dass genau ein Mitarbeiter die Nachricht gehört oder gelesen hat. Für die betriebliche Verwendung muss sie in der gemeinsamen Umgebung verfügbar werden.

Die Fragen lauten deshalb nicht nur:

• Durfte der Kunde diese Information über diesen Kanal senden?
• War der Empfänger wirklich der richtige Mitarbeiter?

Sondern auch:

• Ist die Meldung nach der Übertragung für die zuständige Organisation verfügbar?
• Bleibt ihr Inhalt vollständig und dem richtigen Kunden zugeordnet?
• Kann ein Vertreter die Bearbeitung übernehmen?
• Ist erkennbar, ob die Nachricht angenommen, bearbeitet und abgeschlossen wurde?

A.5.14 schreibt damit weiterhin kein Ticketsystem vor. Die Maßnahme hilft aber sehr gut zu erklären, warum eine betriebliche Nachricht nicht in einer persönlichen Kommunikationssackgasse enden darf.

Mehrere Eingangskanäle sind erlaubt – mehrere Schattenlisten nicht

Kunden möchten auf unterschiedlichen Wegen Kontakt aufnehmen. Ein Portal ist strukturiert, eine E-Mail bequem, ein Telefonat bei einem dringenden Ausfall menschlich und schnell. Das muss kein Problem sein.

Das Problem entsteht, wenn jeder Kanal seine eigene Arbeitswelt bildet:

• Portal-Tickets stehen im Helpdesk.
• E-Mails liegen in persönlichen Postfächern.
• Telefonate stehen auf Notizzetteln.
• Chatnachrichten verschwinden im Gesprächsverlauf.
• Der Geschäftsführer führt eine eigene Liste wichtiger Kundenwünsche.
• Techniker merken sich Zurufe bis nach dem nächsten Termin.

Dann besitzt das Unternehmen nicht mehrere Kontaktwege, sondern mehrere unvollständige Warteschlangen. Niemand sieht das gesamte Arbeitsvolumen. Prioritäten werden pro Postfach vergeben und Vertretung bedeutet, möglichst viele Kollegen anzurufen.

Die bessere Regel lautet: Kontaktwege dürfen verteilt sein, die Arbeitslage nicht.

E-Mails an eine zentrale Supportadresse können automatisch Tickets erzeugen. Portalnachrichten landen ohnehin dort. Telefonate werden durch den annehmenden Mitarbeiter erfasst. Bei zulässigen Chats braucht es eine Weiterleitung oder einen klaren manuellen Schritt. Entscheidend ist nicht, ob alles vollautomatisch läuft. Entscheidend ist, dass kein relevanter Vorgang von der Erinnerung des Empfängers abhängt.

Der Lieblingsadministrator darf Lieblingsadministrator bleiben

Viele Kunden möchten ihren vertrauten Ansprechpartner direkt erreichen. Das ist verständlich und muss nicht verboten werden. Gerade kleinere Systemhäuser leben von persönlicher Beziehung und kurzen Wegen.

Die Lösung lautet nicht zwangsläufig: „Rufen Sie uns nie wieder an und füllen Sie dieses Formular mit 19 Pflichtfeldern aus.“

Der angerufene Administrator kann freundlich zuhören und anschließend selbst ein Ticket eröffnen. Oder er leitet die Nachricht an eine Adresse weiter, die daraus automatisch eines macht. Wichtig ist nur, dass die Arbeit danach nicht mehr ausschließlich an seiner persönlichen Verfügbarkeit hängt.

Das Ticket nimmt ihm die Kundenbeziehung nicht weg. Es macht sie vertretbar. Ein Kollege kann sehen, was besprochen wurde, Rückfragen übernehmen und den Kunden informieren, wenn der Lieblingsadministrator tatsächlich einmal Urlaub macht, krank wird oder einfach gerade einen anderen Server aus dem Graben zieht.

Ein gemeinsames Postfach ist ein Anfang, aber noch kein vollständiger Prozess

Für ein kleines Team kann eine zentrale Adresse wie support@... sehr viel verbessern. Alle Mitarbeiter sehen neue Meldungen und eine Abwesenheit legt nicht sofort den gesamten Eingang lahm.

Ein gemeinsames Postfach beantwortet allerdings noch nicht automatisch:

• Wer übernimmt die Anfrage?
• Welche Meldung ist dringend?
• Was ist bereits in Bearbeitung?
• Worauf wartet das Team noch?
• Welche Reaktionszeit droht abzulaufen?
• Wann ist der Vorgang wirklich erledigt?

Wenn Mitarbeiter Nachrichten mit bunten Fähnchen markieren, verschieben und gelegentlich wieder auf ungelesen setzen, kann das eine Weile funktionieren. Mit wachsendem Volumen wird daraus schnell E-Mail-Ballett.

Ein Ticketsystem ergänzt Zuständigkeit, Status, Priorität, Wiedervorlage, Eskalation und Bearbeitungshistorie. Es muss deshalb nicht besonders großartig aussehen. Es muss zuverlässig zeigen, welche Arbeit vorhanden ist und was daraus geworden ist.

Was beim Eingang mindestens erhalten bleiben sollte

Dieser Artikel soll nicht noch einmal erklären, wie ein Vorgang als Request, Incident oder Problem klassifiziert wird. Das behandelt unser Beitrag Service Request oder Incident? ausführlich. Zuerst muss die Meldung überhaupt zuverlässig ankommen.

Für die erste Erfassung reichen meist wenige Informationen:

• Kunde und meldende Person;
• Zeitpunkt und ursprünglicher Eingangskanal;
• Inhalt möglichst nah an der ursprünglichen Meldung;
• betroffener Service oder betroffenes System, soweit bekannt;
• erkennbare Auswirkungen und Dringlichkeit;
• Rückruf- oder Kontaktmöglichkeit;
• aktueller Verantwortlicher und Bearbeitungsstatus;
• Hinweis auf einen möglichen Sicherheitsbezug.

Der Mitarbeiter muss am Telefon keine technische Diagnose erfinden. „Kunde meldet: Backup seit heute Morgen fehlerhaft“ ist besser als eine selbstbewusste Vermutung, die später alle in die falsche Richtung schickt.

Nach der Erfassung kann der Vorgang eingeordnet, ergänzt und an den richtigen Bearbeitungsweg übergeben werden. Welche Leistungen der Kunde überhaupt beauftragt hat, ergibt sich aus Servicekatalog, Vertrag und Betriebsführungshandbuch. Welches konkrete System betroffen ist und wer es betreibt, gehört in die Asset- und Konfigurationssicht des IT-Dienstleisters.

Typische Fehler

Nur Portal-Tickets zählen als echte Arbeit

Der Kunde ruft wegen eines Ausfalls an, aber niemand erfasst den Vorgang, weil er das Portal hätte benutzen sollen. Eine gewünschte Lenkung der Kunden ersetzt nicht den internen Umgang mit tatsächlich eingegangenen Meldungen.

Der persönliche Empfänger soll später daran denken

„Mach ich nachher“ ist keine Warteschlange. Sobald der nächste dringende Vorgang kommt, kämpft die Kundenmeldung gegen Kalender, Telefon und menschliches Kurzzeitgedächtnis.

Eine Weiterleitung gilt bereits als Übergabe

Der Administrator schickt die E-Mail an drei Kollegen. Nun wissen vier Personen davon, aber niemand ist verantwortlich. Verteilung ist noch keine Zuweisung.

Telefonnotizen enthalten nur „Bitte zurückrufen“

Dann beginnt der nächste Mitarbeiter wieder bei null. Kunde, betroffenes System, Auswirkung und Anlass sollten so weit erfasst werden, wie sie im Gespräch bekannt sind.

Das Ticketsystem ist nur ein Archiv erledigter Arbeiten

Tickets werden nachträglich angelegt, damit Zeiten abgerechnet werden können. Für Verfügbarkeit, Priorisierung und Vertretung hilft das zu spät. Der Vorgang muss entstehen, wenn die Arbeit bekannt wird – nicht erst, wenn sie fertig ist.

Der offizielle Weg ist im Alltag unbrauchbar

Wenn das Eröffnen eines Tickets länger dauert als die Fehlerbehebung, bauen Mitarbeiter Nebenwege. Der geregelte Weg muss so einfach sein, dass er auch an einem hektischen Montag benutzt wird.

So führen Sie einen geregelten Eingang pragmatisch ein

Beginnen Sie nicht mit der Auswahl eines neuen Tools. Beobachten Sie eine Woche lang, woher echte Kundenarbeit kommt.

1. Sammeln Sie die verwendeten Kanäle: Portal, zentrale E-Mail, persönliche E-Mail, Telefon, Chat und direkte Zurufe.
2. Markieren Sie, welche Kanäle erlaubt, nur geduldet oder für bestimmte Informationen ungeeignet sind.
3. Legen Sie für jeden erlaubten Kanal fest, wie daraus ein gemeinsamer Vorgang wird.
4. Bestimmen Sie, wer den Eingang regelmäßig sichtet und offene Vorgänge verteilt.
5. Definieren Sie wenige Pflichtangaben, die für Übernahme und Rückfrage wirklich benötigt werden.
6. Sorgen Sie für Vertretung und Eskalation, wenn ein Vorgang unbearbeitet bleibt.
7. Prüfen Sie nach einigen Wochen, welche Meldungen trotzdem noch außerhalb der gemeinsamen Arbeitslage auftauchen.

Damit entsteht keine Service-Management-Kathedrale. Es entsteht die schlichte Fähigkeit, bekannte Arbeit nicht zu verlieren. Genau diese Betriebsgrundlage macht ISO 27001 für IT-Dienstleister erheblich glaubwürdiger – und den Montagmorgen für alle Beteiligten etwas weniger überraschend.

Interesse geweckt?

Sie möchten Ihre Kundenkommunikation so ordnen, dass keine sicherheitsrelevante Aufgabe im persönlichen Postfach oder Mitarbeiterkopf verschwindet? Sprechen Sie mit uns.