Natürlich haben die Mathematiker unter den Lesern Recht. Allerdings geht es hier nicht um Mathe, sondern um Prozessmanagement. Was das nun wieder mit Datenschutz oder Informationssicherheit zu tun hat? Einfach weiterlesen.
Seit ungefähr 3 Jahren machen wir regelmäßig stets die selbe Erfahrung bzw. erhalten stets die selben Antworten auf eine bestimmte Frage. Wie diese lautet? Eigentlich ganz trivial. „Wieso gibt es eigentlich bei Ihnen im Haus 3 Prozesse für die Meldung von IT-Störungen, von Datenschutzverletzungen und von Sicherheitsvorfällen?“ Der geneigte Leser erkennt sofort, hier treffen die drei Themen IT-Betrieb (bzw. IT-Servicemanagement), Datenschutz und Informationssicherheit zusammen. Doch werfen wir erst mal einen Blick auf die üblichen Antworten.
Die IT durchaus so (nicht immer, aber durchaus anzutreffen): „Wir haben dafür gar keinen Prozess. Bei uns kann jeder eine Störung melden, wie er oder sie will. Per Telefon, per Email, per Ticketsystem (sofern vorhanden) oder per Turnschuh (also vor der Tür zur Abteilung stehen und anklopfen).“
Der oder die Datenschutzbeauftragte so: „Ich brauche einen eigenen Prozess wegen DSGVO.“ Seltsamerweise findet sich dazu gar nix im Gesetzestext, aber was wissen wir schon.
Und dann bleibt dem oder der ISB nur noch das Achselzucken. Denn noch ein dritter Meldeweg ist meist nicht gewünscht.
Ab in den Helikopter
Was jetzt dieses Fluggerät mit Prozessen zu tun hat? Ganz einfach. Wir wechseln mal in die sog. Helikopter- oder Vogel-Perspektive. Sprich wir verlassen kurz die Widrigkeiten des Alltags, genießen die Höhenluft samt Ausblick und richten nach einer Weile des Kopffreibekommens den Blick nach unten auf unsere Organisation. Aber nicht nur nach unten, sondern auf die idealerweise vorhandenen Prozesse der IT und des Datenschutzbeauftragten.
Der IT-Servicemanagement-Prozess Störung
Irgendwas geht nicht mit der Technik am Arbeitsplatz eines Mitarbeiters. Sei es Hardware oder Software, irgendwas zickt rum. Im Idealfall gibt es Abhilfe für diesen verzweifelten Mitarbeiter über ein vorhandenes Ticket-System, eine Telefon-Hotline oder ähnliches. Dort nimmt sich eine vorgelagerte Stelle (der sog. 1st level support) des Problems an, führt eine Bewertung der Störung durch z.B. im Hinblick auf Dringlichkeit und Komplexität. Danach wird das „Ticket“ in den weiteren Bearbeitungslauf in der IT gegeben. Sollte es sich um einen Sicherheitsvorfall mit schützenswerten Informationen handeln, ist es eher Glück, wenn auch der zuständige Informationssicherheitsbeauftragte (ISB) involviert / informiert wird. Dieses Schicksal teilt zumeist auch der Datenschutzbeauftragte (DSB), wenn es sich um einen Sicherheitsvorfall mit personenbezogenen Daten (einer Untermenge der schützenswerten Informationen in einer Organisation) handelt. In beiden Fällen wäre aber nicht nur aufgrund von Art. 33, 34 DSGVO ein zeitnahe Einbindung der beiden Rollen angeraten.
Der Meldeprozess für Datenschutzverletzungen
In vielen Organisationen ist ein solcher Prozess durchaus schon etabliert — und wird sogar genutzt. Meist hapert es beim Triggern (Anstoß des Prozesses) daran, dass der ursächliche Auslöser nicht als mögliche Datenschutzverletzung auf dem Schirm der Meldenden, also der Mitarbeitenden ist. Aber das ist eine andere Baustelle im Kontext „Erkennen und Melden von Datenschutzverletzungen“. Dazu haben wir übrigens für unsere Datenschutz-Kunden eine Online-Schulung auf unserer eLearning-Plattform am Start.
Im Prozessablauf wird die gemeldete Datenschutzverletzung vom DSB im Hinblick auf Schwere des Risikos (für den Betroffenen, nicht die Organisation) bewertet. Aufgrund dieser Bewertung spricht der DSB an den Verantwortlichen (= die Organisation) eine Empfehlung aus, diese Datenschutzverletzung nach Art. 33 DSGVO an die zuständige Landesdatenschutzbehörde evtl. in Verbindung mit Art. 34 DSGVO an die von der Panne betroffenen Personen zu melden.
Parallel dazu ist durch geeignete Maßnahmen eine Ausweitung des möglichen Schadens zu minimieren. In der Nachbearbeitung gilt es, technische und / oder organisatorische Maßnahmen zu planen und umzusetzen. Damit soll eine Wiederholung einer solchen Datenschutzverletzung vermieden werden.
Und dann war da noch der sog. Sicherheitsvorfall
In der Informationssicherheit gibt es ebenfalls die Anforderung, und auch der gesunde Menschenverstand gebietet die Notwendigkeit, Sicherheitsvorfälle mit schützenswerten Informationen — egal welcher Art und Form — frühzeitig zu erkennen. Und dann an die notwendigen Stellen intern zur Bewältigung / Beseitigung zu kommunizieren. Dabei ist es sehr wichtig, nicht nur an die Untermenge der IT-Sicherheitsvorfälle zu denken oder sich auf personenbezogene Daten zu beschränken. Die internen Ansprechpartner sollten nun zeitnah eine weitere Eskalation des Schadens so gut wie möglich unterbinden. Damit werden die Folgen für die Organisation minimiert, wie Rufschaden, Bußgelder, Schadenersatz, mögliche Rechts- und Vertragsverstöße. Im Anschluß gilt es auch hier, in der Analyse und Nachbearbeitung geeignete technische und organisatorische Maßnahmen zu planen und einzuführen. Ziel: Diese Art von Sicherheitsvorfall zukünftig möglichst unterbinden. Oftmals wird hierzu ein weiterer Meldeprozess in der Organisation etabliert. Durchaus unter Zuhilfenahme der sog. IT-Notfall-Meldekarte des BSI.
Problematik in der Praxis
Aber ist ein Sicherheitsvorfall automatisch ein IT-Notfall? Können Störungen nicht in einen Notfall eskalieren? Sind Datenschutzverletzungen nicht auch ein Sicherheitsvorfall oder Notfall (je nach Ausprägung)?
Und noch viel schwerwiegender:
- Welchen Prozess sollen denn nun die in den Begrifflichkeiten Störung, Datenschutzverletzung, Sicherheitsvorfall und Notfall unbedarften Mitarbeitenden eigentlich nutzen?
- Und was ist, wenn Mitarbeitende aus Versehen bzw. aus Unwissenheit im falschen Meldeprozess landen? Heißt es dann „Nicht mein Tisch. Bitte nutzen Sie den für Ihren Vorgang vorgesehenen Meldeweg!“
- Und wer sich mit Prozessmanagement und / oder Qualitätsmanagement befasst, der ist eh kein Freund von drei mehr oder weniger identischen Arbeitsabläufen für ähnliche Vorgänge.
Es geht auf jeden Fall wichtige Zeit verloren, die im Falle eines eskalierenden Sicherheitsvorfalls dringend benötigt wird, um das potentielle Ausmaß für die Organisation einzudämmen. Von den ganzen Dokumentations- und Pflegearbeiten für drei Prozesse ganz zu schweigen.
Ein möglicher Lösungsansatz
Ja, jetzt formiert sich Widerstand! „Haben wir ja noch nie so gemacht“, „Haben wir schon immer anders gemacht“, “Bis zu meiner Rente in 5 Jahren führe ich nichts Neues mehr ein”, “Wo steht, dass wir das so machen müssen?” und was es alles für Gründe gibt, Veränderungen möglichst zu vermeiden. Menschlich. Und verständlich. Es heißt nicht umsonst, der Mensch ist ein Gewohnheitstier. Aber spielen wir es doch einfach mal gedanklich durch.
Allen drei zuvor genannten Prozessen ist gemein: Es kommt eine Meldung rein. Diese wird bewertet. Dann wird eine entsprechende Aktivität ausgelöst. Bei Bedarf erfolgt eine Analyse und Nachbearbeitung, damit sich der Vorfall möglichst nicht so oft wiederholt. Damit haben wir den groben gemeinsamen Nenner hinter allen drei Prozessen schon gefunden. Gar nicht so schwierig.
Betrachten wir das mal (erst ohne dann mit Ablaufverbinder) als grafischen Prozessablauf. Den Punkt Nachbearbeitung haben wir an der Stelle der Übersichtlichkeit halber ausgespart. Aber das ändert nix an der Sache.
1. Prozess ITSM Störung
2. Prozess Datenschutzverletzung
3. Prozess Sicherheitsvorfall
Ui, die sind ja allesamt (fast) deckungsgleich. Na sowas aber auch. 🙂 Jetzt verschmelzen wir die 3 Prozesse mal zu einem neuen Prozess.
Und fügen nun noch die Ablaufverbinder dazu.
Huch, 1+1+1 ergibt auf ein Mal doch 1 und nicht 3. Quod erat demonstrandum. 🙂
Was es dafür benötigt?
- Blick über den Tellerrand bei den Beteiligten (IT, DSB, ISB und wer sonst noch so benötigt wird)
- Über Bord mit eingefahrenen Sicht- und Denkweisen
- Die Einsicht. dass es auch anders und besser gehen kann
- Den Willen zur Veränderung
- Am Ende einen gut geschulten 1st level support, der die notwendigen Player (ISB / DSB) bei Bedarf zeitnah mit einbindet
Vorteile
- Ein zentraler Meldepunkt für die Mitarbeitenden
- Vermeidung von Irrläufern bzw. zeitlich im Hinblick auf Meldefristen relevanten Verlusten
- Eine zentrale Stelle der Dokumentation (z.B. Ticketsystem)
- 1 statt 3 Prozesse = verringerter Pflege- und Dokumentationsaufwand (2/3 gespart), weniger Schulungsbedarf bei den Mitarbeitenden
Nachteile
- Man muss was ändern
- Es benötigt einen geschulten 1st level support für die Erstbewertung und mögliche Einbindung von ISB / DSB
- Ein Ticketsystem zur Bearbeitung und Dokumentation
- Datenschutz braucht halt doch keinen eigenen Prozess 🙂 (Stichwort “Tanz um das goldene Kalb”)
Schauen wir konkreter auf die Nachteile, so stellen wir fest: 1 und 4 sind mehr emotionale Befindlichkeiten. 2 ist kein Nachteil, sondern sollte eigentlich Standard sein. Und 3, ja, gegen 3 wird oft seitens der IT gewettert. Braucht man nicht. Zu umständlich. Wir werden transparent. Hallo? Es muss nicht der Rolls Royce sein. Selbst die einfachsten, auf einem Raspberry Pi lauffähigen open source Ticket-Systeme sind einfach in der Installation sowie im Betrieb und leisten schon Erhebliches. Und was ist schlecht an Transparenz? Wird nicht dauernd angezweifelt, dass der Personalbedarf der IT notwendig ist? “Was machen die da eigentlich den ganzen Tag?” Dabei sind viele IT-Abteilungen nur noch als Turnschuh-Admins unterwegs. Strategisches Denken, Arbeiten und Handeln, da bleibt gar keine Zeit für. Über ein gut gepflegtes Ticket-System kann die IT das sehr gut belegen und bei Bedarf weitere Personalressourcen einfordern. Hat doch alles sein Gutes. Außer man hat sich und der Organisation die ganze Zeit im Hinblick auf die Arbeitsbelastung in der IT etwas vorgemacht. Aber das sind eher sehr seltene Ausnahmen als die Regel.
Think about it — Gutes Gelingen!
Gerne unterstützen wir Sie im Rahmen unserer Beratungsleistungen rund um Datenschutz und Informationssicherheit bei solchen Vorhaben. Sprechen Sie uns einfach an.
Hahn IT Services, Schwaig
No responses yet