Der EDÖB hat die Schlussberichte in seiner Sachverhaltsabkläung in Sachen Xplain AG, fedpol und BAZG jeweils mit Datum vom 25. April 2024 veröffentlicht, nach einer für die Verhältnisse des EDÖB sehr speditiven Sachverhaltsabklärung.
Hintergrund
Hintergrund war der bekannte Double Extortion-Ransomware-Angriff auf Xplain. Eine recht detaillierte Beschreibung findet sich bei Inside IT, ebenso wie ein Interview mit dem CEO von Xplain vom Februar 2024.
Die Angreifer, eine Gruppe namens Play, hatte im Mai 2023 eine grössere Datenmenge erbeutet. Kritisch war dies deshalb, weil Xplain seit 2000 schwergewichtig als IT-Provider der Bundesverwaltung im Bereich der inneren Sicherheit tätig war, bspw. für das BAZG (Bundesamt für Zoll und Grenzsicherheit). Auf den betroffenen Systemen – Referenzinstallationen, Entwicklungs‑, Test‑, Administrations- und Build-Umgebungen – befanden sich offenbar rund 1.5 TB an Daten, wovon ca. 600 GB exfiltriert und – weil Xplain von einer Lösegeldzahlung abgesehen hatte – rund 430 GB (146’623 Dateien; ein grosser Teil aber Duplikate) veröffentlicht wurden; dies vermutlich ohne genauere inhaltliche Prüfung der Daten durch die Angreifer. Das NCSC, das die Bewältigung des Vorfalls seitens des Bundes geleitet hatte, hat zu den betroffenen Daten einen Bericht erstellt und veröffentlicht.
Betroffen waren vor allem Daten von Xplain, des fedpol, des BJ und weiteren dem EJPD zuzuordnenden Stellen, ferner des VBS, des Seco und weiterer kantonaler und Bundesbehörden. Die Daten enthielten auch Personendaten, neben einigen als intern oder vertraulich – aber nicht geheim – klassifizierten Datenobjekten. Der EDÖB illustriert den Vorfall wie folgt:
Administrativuntersuchung des Bundesrats
In der Folge des Angriffs hatte neben dem EDÖB der Bundesrat ab Ende August 2023 durch Oberson Abels eine Administrativuntersuchung durchführen lassen, die mit einem auf den 28. März 2024 datierten Bericht abgeschlossen wurde (noch laufend sind Strafverfahren der BA). Gegenstand der Untersuchung war dabei, wie Xplain in den Besitz von produktiven Daten der Bundesverwaltung kommen konnte, ob dabei ein Mangel an ausreichenden TOMs ursächlich war und ob die Bundesverwaltung ihre Pflichten beim Monitoring von Xplain verletzt hat.
Der Bericht kam zum Ergebnis, dass auf Seiten des Bundes Prozessmängel bestanden (z.B. fehlendes Vieraugenprinzip bei der Übermittlung von Produktivdaten an Xplain), dass Xplain nicht angemessen überwacht worden war und dass der Bund auch datenschutzrechtliche Pflichten im Verhältnis zu Xplain als Auftragsbearbeiter verletzt hat. Offenbar bestand auch Unklarheit bei der zersplitterten Zuständigkeit innerhalb der diversen beteiligten Bundesstellen. Ebenfalls wurde eine Abhängigkeit von Xplain festgestellt.
Der Bundesrat hat deshalb an seiner Sitzung vom 1. Mai 2024 beschlossen, Massnahmen zu ergreifen. Eine Verbesserung der Situation erwartet er schon aufgrund des am 1. Januar 2024 in Kraft getretenen ISG, aber er hat weitere Massnahmen beschlossen, die jeweils bis Ende 2024 umzusetzen sind:
- zusätzliche Sicherheitsvorgaben zur Zusammenarbeit mit Lieferanten (bis Ende 2024 erstellt), zur Stärkung der Kontroll- und Auditfähigkeit;
- funktionsbezogenes Ausbildungskonzept für die Schulung und Sensibilisierung von Mitarbeitenden in Bezug auf Sicherheitsvorgaben;
- Übersicht über die vorhandenen Kommunikationsmittel der Bundesbehörden;
Weiter ist das VBS beauftragt, den IKT-Grundschutz des Bundes bis Ende 2024 zu überprüfen und ggf. Anpassungen vorzuschlagen. Das BACS zudem “aufzeigen”, wie die Koordination bei der Bewältigung von Cyberangriffen zwischen Bund, Kantonen und Lieferanten abläuft und nach welchen Kriterien das Ausmass der Cyberangriffe beurteilt werden soll.
Schlussbericht i.S. Xplain
Übergangsrecht
Im Schlussbericht zu Xplain kommt der EDÖB zum Ergebnis, dass diverse Empfehlungen auszusprechen sind. Wie bei allen unter dem alten Recht begonnenen Sachverhaltsabklärungen stellt sich allerdings das Problem, dass sie übergangsrechtlich (Art. 70 DSG) formell wie materiell nach dem alten DSG abzuschliessen waren bzw. sind. Das führt dazu, dass die Ergebnisse und ggf. Empfehlungen des EDÖB im Grunde genommen rechtshistorischen Charakter haben, denn anders als der EDÖB bei der Durchführung der Sachverhaltsabklärung unterstehen die Adressaten der Sachverhaltsabklärung seit dem 1. September 2023 dem neuen DSG. Es fragt sich deshalb jeweils, ob die Empfehlungen des EDÖB auch unter dem neuen Recht beachtlich wären. Der EDÖB verweist deshalb im Schlussbericht wiederholt auf das neue Recht, um den Erwägungen etwas mehr Gewicht zu verleihen; eine eigentliche Prüfung, inwiefern das neue dem alten DSG tatsächlich entspricht, erfolgt aber nicht.
Dazu kommt der Umstand, dass Art. 70 DSG nur für die eigentliche Sachverhaltsabklärung eine Weitergeltung des alten Rechts vorsieht. Da eine etwaige Klage vor dem Bundesverwaltungsgericht durch den EDÖB oder den Adressaten der Abklärung ein neues, eigenes Verfahren eröffnen würde – es ist kein Rechtsmittelverfahren –, wäre hierfür eine eigene Übergangsregelung erforderlich. Da eine solche fehlt, können wohl weder der EDÖB noch der Adressat des Schlussberichts vor dem Bundesverwaltungsgericht klagen (für die Adressaten galt ein Klagerecht nach Art. 35 lit. b VGG, der durch das neue DSG aber gestrichen wurde).
Soweit eine Empfehlung abgelehnt oder nicht umgesetzt wird, bliebe dem EDÖB also nur eine Untersuchung nach dem neuem DSG. Da das VwVG auf die Sachverhaltsabklärung nur analog angewandt wurde, müsste der EDÖB dabei den Sachverhalt nach den Regeln des VwVG neu erheben und nach dem neuen Recht würdigen. Die Übergangsregelung von Art. 70 DSG ist mit anderen Worten im Ansatz verfehlt, verliert aber immerhin laufend an Bedeutung (viele Sachverhaltsabklärungen sind nicht mehr hängig).
Rechtliche Erwägungen
In rechtlicher Hinsicht hat der Schlussbericht zwei Hauptthemen, einerseits die Rolle von Xplain und andererseits die Einhaltung der Datensicherheit. Dabei stützt sich der EDÖB auf seine Sachverhaltsfeststellungen, die Xplain allerdings als unrichtig eingestuft hatte.
Xplain war aus Sicht des EDÖB in zwei Rollen tätig:
- Als Verantwortliche im Bereich der eigenen Bearbeitungen:
Xplain handelt als Verantwortlicher, soweit Personendaten über Kunden, Mitarbeitende etc. bearbeitet werden. Dabei hat Xplain die Grundprinzipien des Datenschutzgesetzes einzuhalten […].
- Als Auftragsbearbeiter, soweit Xplain Software entwickelte:
Das Kerngeschäft von Xplain ist die Entwicklung von Standard-Software für die Innere Sicherheit […]. Im Rahmen dieser Tätigkeit werden auch Personendaten des Auftraggebers an Xplain übertragen, so insbesondere im Rahmen von Projektdaten und bei Fehlerbehebungen […]. Es spielt keine Rolle, dass die Übertragung dieser Daten nur ein Nebeneffekt der eigentlichen Aufgabe von Xplain ist. Es ist auch unerheblich, dass diese Datenbearbeitungen einen geringen Umfang im Vergleich zu den Kerntätigkeiten von Xplain ausmachen. […] Wie die Vertragsvereinbarungen zeigen, ist insbesondere bei den mit Xplain vereinbarten Dienstleistungen das Bearbeiten von Personendaten enthalten […]. Xplain ist in dieser Konstellation als Auftragsbearbeiter im Sinne von Art. 10a aDSG zu qualifizieren.
Der EDÖB hält sich hier nicht mit einer genaueren Analyse der Rollen auf. Nach der insbesondere vom BayLDA, aber auch vom EDSA vertretenen und auch in der Schweiz rezipierten “Schwerpunkttheorie” wäre massgebend, ob die Bearbeitung von Personendaten eigentlicher Gegenstand der Leistungserbringung ist (Auftragsbearbeitung, bspw. bei Hosting- oder SaaS-Leistungen) oder lediglich Nebeneffekt einer anders gelagerten Dienstleistung (Tätigkeit als Verantwortlicher, bspw. Dienstleistungen der freien Berufe).
Das liegt wohl im Interesse der Bundesstellen – soweit Xplain ein Verantwortlicher wäre, würde sich die Frage stellen, ob Xplain überhaupt Personendaten zur Verfügung gestellt werden dürfen, was bei einem Auftragsbearbeiter viel einfacher ist. Anzumerken bleibt, dass auch ein Verantwortlicher eine Hilfsperson im (amts-)geheimnisrechtlichen Sinn sein kann und entsprechend beigezogen werden darf, wenn er lege artis bestellt und einbezogen wird.
Dazu kommt aber eine weitere Rolle von Xplain: Diejenige des Verantwortlichen, weil im Rahmen einer Auftragsbearbeitung die entsprechenden Vorgaben nicht eingehalten werden:
Xplain hat in der Funktion als Auftragsbearbeiter Personendaten nach den Vorgaben des Verantwortlichen zu bearbeiten, insbesondere nach den vertraglichen Vorgaben und im Rahmen dessen, was der Auftraggeber selbst tun dürfte (Art. 10a Abs. 1 lit. a aDSG).
Soweit sich Xplain nicht an diese Vorgaben hält, wird sie selbst zum datenschutzrechtlich Verantwortlichen.
Im vorliegenden Sachverhalt zeigt sich, dass Xplain die ihr übermittelten Personendaten nicht vertragsgemäss gelöscht hat […]. Für die Aufbewahrung dieser Personendaten – die später im Darknet publiziert wurden – ist Xplain Verantwortlicher.
Das ist weder ganz richtig noch ganz falsch. So absolut formuliert gäbe es keinen vertragsbrüchigen Auftragsbearbeiter, sondern nur den angemassten Verantwortlichen. Der Begriff des Verantwortlichen ist aber nicht so weit – er verlangt bekanntlich einen ausreichenden Einfluss auf die Zwecke und die Mittel der Bearbeitung. Verletzt ein Auftragsbearbeiter eine Sicherheitsanforderung, wird er dadurch noch nicht zum Verantwortlichen. Ein solcher Rollenwechsel entsteht erst, wenn der Verantwortliche aus eigenen Motiven – Zweckbestimmung – eine eigene Bearbeitung vornimmt oder wesentliche Mittel der Bearbeitung setzt. Bei einer Datenspeicherung über das vertraglich Vorgegebene hinaus geschieht dies allerdings; hier wird der Auftragsbearbeiter tatsächlich ein Verantwortlicher. Es liegt daher bspw. im Interesse des Auftragsbearbeiters, eine weitere Speicherung in Backups usw. ausdrücklich zu regeln – geschieht das nicht und unterbleibt eine Datenlöschung nach dem Ende der eigentlichen Auftragsbearbeitung, ist der Auftragsbearbeiter ein Verantwortlicher, der höchstwahrscheinlich seine Pflichten (bspw. zur Information der Betroffenen) verletzt.
Der EDÖB hält weiter fest:
- Die beauftragenden Bundesstellen durften grundsätzlich davon ausgehen, dass Xplain angemessene TOMs ergriffen hat, “da Xplain als Verantwortlicher dem aDSG untersteht und atzt 7 aDSG einzuhalten hat”. Das ist eine etwas seltsame Begründung, aber richtig ist jedenfalls, dass auch ein Auftragsbearbeiter den Bearbeitungsgrundsätzen einschliesslich der Datensicherheit untersteht, also eigene Pflichten hat, und dass der Verantwortliche ein gewisses Vertrauen in die Einhaltung der entsprechenden Pflichten haben darf. Es ist deshalb nicht generell zwingend, in einer ADV eine Liste von TOMs aufzuführen, auch wenn dies häufig ist (oft allerdings mit nichtssagenden Umschreibungen sehr generischer TOMs).
- Soweit der Verantwortliche spezifische Sicherheitsanforderungen hat, muss er sie aber vertraglich überbinden. (Zudem hält der IKT-Grundschutz der Bundesverwaltung fest, dass die IKT-Sicherheitsvorgaben des Bundes verbindlich vertraglich zu regeln sind.)
- Der Verantwortliche müsse die Umsetzung und Einhaltung der Sicherheitsmassnahmen prüfen – nicht falsch, aber nicht auf alle Auftragsbearbeitungen verallgemeinerbar:
Der Auftragsbearbeiter selbst hat Audits durchzuführen und ungewöhnliche Sicherheitsvorfälle dem Verantwortlichen zu melden. Dies ergibt sich bereits aus den Grundschutzmassnahmen von Art. 7 aDSG und aus dem Grundsatz von Treu und Glauben. Der Verantwortliche kann sich ein Auditrecht ausbedingen und sich auch Auditberichte des Auftragsbearbeiters vorlegen lassen.
- Die Speicherung von Personendaten über das Erforderliche hinaus verletzt den Grundsatz der Verhältnismässigkeit.
- Xplain habe die Pflicht zur Mitteilung der Sicherheitsverletzung vernachlässigt (allerdings existierte eine solche Pflicht unter dem aDSG nur auf vertraglicher Basis oder in bestimmten Konstellationen als Ausfluss des Sicherheitsgrundsatzes):
Xplain hat unmittelbar nach dem Ransomware-Vorfall verschiedene Massnahmen getroffen, um den Schaden zu minimieren […]. Dabei fällt auf, dass Xplain sich der Schwere des Vorfalls offensichtlich nicht bewusst war und die Bundesverwaltung erst zehn Tage nach dem Vorfall informierte, obwohl eine Frist für solche Vorfälle von 24 Stunden vereinbart war.
Interessant ist ein weiterer Punkt: Der EDÖB prüft die Einhaltung der Mindestanforderungen an die Datensicherheit durch Xplain und stellt Verletzungen fest – dies aber, ohne eine abstrakte Regel für die Bestimmung des minimalen Schutzstandards zu nennen oder aufzustellen. Der EDÖB hält zwar zu Recht fest, dass aus der Tatsache eines Sicherheitsvorfalls nicht auf unzureichende TOMs zu schliessen ist (ein Gedanke, der in Art. 4 Abs. 2 PrHG besonders deutlich zum Ausdruck kommt):
Allein die Tatsache, dass Personendaten vom Fileserver von Xplain im Darknet publiziert wurden, lässt noch nicht darauf schliessen, dass die Massnahmen nicht angemessen waren. Ein Restrisiko einer Datenschutzverletzung verbleibt bei jeder Datenbearbeitung. Entscheidend ist, ob die dem Risiko der Datenbearbeitungen angemessenen Massnahmen getroffen wurden.
Daran sollte man auch bei der Übermittlung von Personendaten ins Ausland denken. Aber: Der EDÖB geht so vor, dass er Sicherheitsmassnahmen nennt, die nicht getroffen worden waren – bspw. der Betrieb eines SOC oder die Abbildung vertraglicher Vorgaben in eigenen Prozessen –, und kommt direkt zum Ergebnis, dass dadurch Anforderungen an die Datensicherheit verletzt wurden. Auch wenn das im Ergebnis einleuchtet und sich der EDÖB auf recht generische Empfehlungen beschränkt, ist das Vorgehen rechtlich betrachtet eigentlich lückenhaft. Der EDÖB hätte die Faktoren nach Art. 1 DSV – oder vielmehr: nach Art. 8 ff. und 20 ff. aVDSG – prüfen müssen, d.h. er hätte
- darlegen müssen, wie die Risiken für die Betroffenen ex ante einzuschätzen waren, unter Berücksichtigung des Ermessensspielraums des Verantwortlichen,
-
den Stand der Technik beurteilen müssen, und
-
den Aufwand für die Implementierung weiterer möglicher Massnahmen, unter Berücksichtigung der Wirksamkeit der möglichen Massnahmen.
Was das vorliegende Verfahren ebenfalls zeigt:
- Sicherheitsmassnahmen werden in einem Vertrauensklima sehr oft vernachlässigt und erst kritisch geprüft, wenn eine Verletzung erfolgt ist. Das belegt die Wichtigkeit externer Prüfungen (bspw. Pentests oder anderer Security Reviews), und zwar besonders bei einer engen und langjährigen Zusammenarbeit.
- Es ist nicht unzulässig, dem Auftragsbearbeiter Pflichten im Bereich der Datensicherheit zu überlassen, sogar der Regelfall. Wie weit die Verantwortung des Verantwortlichen geht und wie weit jene des Auftragsbearbeiters, ist schwierig zu sagen – eine zentrale TOM besteht für beide Parteien aber darin, genau diese Schnittstelle zu regeln.
- Sicherheit ist auch eine Prozessfrage. Prozesse müssen existieren und eingeübt werden. Sie funktionieren im Ernstfall nicht, wenn sie im Standardbetrieb nicht funktionieren.
- Unternehmen haben oft ein falsches Gefühl der Sicherheit bei den eigenen Bearbeitungen, wohl aus zwei Gründen: Zum einen finden interne Bearbeitungen gefühlt in einem geschützten Raum statt – interne Prozessmängel sind so gesehen unschön, aber unschädlich. Zum anderen ist abstrakt bekannt, wie häufig Cyberangriffe geworden sind, aber das führt nicht zu einem Gefühl der Bedrohung, sehr zu unrecht allerdings.
- Eine Kontamination von Systemen mit Personen- oder anderen heiklen Daten kann sich rächen. Das betrifft nicht nur die Speicherung von Kundendaten bei IT-Dienstleistern, sondern genauso eine unterlassene Löschung oder Anonymisierung von Daten auf eigenen Systemen, die von einem Breach betroffen sein können, was zu einem Erklärungsnotstand gegenüber Betroffenen führen kann.
Empfehlungen
Der EDÖB empfiehlt Xplain folgende Massnahmen:
Mit Bezug auf die Datensicherheit:
- Xplain trifft angemessene TOMs nach dem Gesetz und den vertraglichen Vorgaben der Bundesverwaltung, dies in Bezug auf
- die Bearbeitung besonders schützenswerter Personendaten im Rahmen von Support- und Wartungsprozessen,
- die Bearbeitung von Personendaten unter einem qualifizierten Geheimnisschutz
- die Entwicklung von Software im sensitiven Bereich der Inneren Sicherheit.
- Xplain weist diese TOMs der Bundesverwaltung regelmässig nach, indem sie
- ein ISMS aufbaut (wobei dies nach einem international anerkannten Standard zu zertifizieren ist, solange Xplain mit der Bundesverwaltung im Bereich der Inneren Sicherheit zusammenarbeitet);
- ein Risikomanagement etabliert und
- Massnahmen laufend evaluiert;
- Xplain “sensibilisiert” ihre Mitarbeitenden
- Xplain führt periodisch interne und externe Audits durch.
Mit Bezug auf weitere Grundsätze:
- Xplain bindet die vertraglichen Pflichten in die eigenen Prozesse ein, und
- setzt ein Löschkonzept gemäss den gesetzlichen und vertraglichen Vorgaben um.
Veröffentlichung des Schlussberichts
Strittig war, ob und wie der Schlussbericht zu veröffentlichen ist. Xplain hatte erfolglos verlangt, von einer Veröffentlichung abzusehen, im Wesentlichen offenbar, weil der Sachverhalt nicht richtig erstellt worden sei. Eventualiter hatte Xplain weitgehende Schwärzungen verlangt, offenbar bis hin zu einer Anonymisierung des Schlussberichts. Der EDÖB hat zwar wie üblich gewisse Schwärzungen vorgenommen, aber nicht so weitgehend, auch weil eine Anonymisierung in diesem Fall faktisch nicht möglich gewesen wäre.
Es fragt sich allerdings tatsächlich, wie weitgehend die Veröffentlichungspraxis des EDÖB gehen darf. Nach dem alten wie auch dem neuen DSG kann der EDÖB die Öffentlichkeit über Feststellungen und Verfügungen informieren, heute also auch über Untersuchungen und Verfügungen, aber nur “in Fällen von allgemeinem Interesse” (Art. 57 Abs. 2 DSG; Art. 30 Abs. 2 aDSG). Diese Formulierung ist missverständlich: Der EDÖB kann bei solchen Fällen nicht generell informieren, sondern nur, soweit an der Information konkret ein öffentliches Interesse besteht. Dabei sind einige Faktoren zu berücksichtigen:
- Nicht jedes Interesse der Öffentlichkeit ist ein öffentliches Interesse – das gilt bei Medien ebenso wie beim EDÖB. Nicht alles, worüber Medien schreiben wollen, erfolgt im öffentlichen Interesse. Die Medienöffentlichkeit rechtfertigt deshalb nicht jede Veröffentlichung. Sie kann im Gegenteil sogar ein Grund sein, von einer Veröffentlichung abzusehen.
- Das Interesse der Öffentlichkeit an der Tätigkeit des EDÖB im Allgemeinen ist nicht durch die Veröffentlichung eines Schlussberichts zu befriedigen, sondern durch Tätigkeitsberichte oder Medienmitteilungen.
- Das Interesse des EDÖB, die eigene Wirksamkeit zu belegen, ist kein öffentliches Interesse.
- Das öffentliche Interesse an der Information verlangt keine detaillierte Information. Die Aufmerksamkeitsspanne der Öffentlichkeit ist kurz.
- Das Interesse an der Rechtsfortbildung und an Kenntnis der Praxis des EDÖB ist ein öffentliches Interesse. Es könnte und sollte durch Leitfäden u.dgl. befriedigt werden, nicht durch Schlussberichte, die in rechtlicher Hinsicht oft sehr oberflächlich begründet werden.
Schlussberichte i.S. fedpol und BAZG
Die Sachverhaltsabklärung i.S. fedpol und BAZG richtete sich anders als bei Xplain nicht auf die internen Prozesse von Xplain, sondern auf das Vorgehen der Behörden selbst. Inhaltlich überschneiden sich die Schlussberichte allerdings.
Der EDÖB bestätigt aber nochmals klar, dass der Verantwortliche ein gewisses Grundvertrauen in den Auftragsbearbeiter haben darf:
Der Verantwortliche hat dem Auftragnehmer klare Vorgaben für Sicherheitsmassnahmen zu machen und deren Umsetzung und Einhaltung zu kontrollieren. Sofern der Auftragnehmer selbst dem aDSG untersteht, kann der Verantwortliche davon ausgehen, dass die technischen und organisatorischen Massnahmen der Datensicherheit (Art. 7 aDSG) angemessen erfüllt sind.
Der Verantwortliche muss den Auftragsbearbeiter u.U. aber dennoch überwachen:
Der Verantwortliche ist deshalb verpflichtet, den Auftragsbearbeiter sorgfältig auszuwählen, zu instruieren und soweit nötig zu überwachen.
In der Sache sieht der EDÖB Mängel insbesondere bei der vertraglichen Einbindung von Xplain, beim Vertrauen in eine vermutete Prüfung durch das BAZG, das eine von fedpol genutzte Applikation bereits im Einsatz hatte, und bei fehlenden Überwachungsmassnahmen.
Hier empfiehlt der EDÖB sowohl dem fedpol aus auch dem BAZG folgendes:
- Die Auftragsdatenbearbeitung sei nicht klar geregelt gewesen. Die Auftragsdatenbearbeitung sei daher dahingehend zu konkretisieren, dass sich die Parteien “bewusst machen”, ob bzw. unter welchen Voraussetzungen Personendaten die Systeme des Bundes verlassen dürfen. Er empfiehlt hier folgendes:
- Zu prüfen, wann es notwendig ist, dass Personendaten im Rahmen von Supportprozessen die Systeme des Bundes verlassen und in Systemen von Xplain gespeichert werden;
- jeweils die notwendigen TOMs zu bestimmen, und bei einer notwendigen Speicherung bei Xplain insbesondere die Grundsätze der Datenminimierung und Datensicherheit abzusichern;
- die entsprechenden Datenübertragungen in klaren Vereinbarungen festzuhalten.
- Sollte fedpol weiter mit Xplain zusammenarbeiten (was offenbar der Fall ist – die vom Untersuchungsbericht festgestellte Abhängigkeit wird fortbestehen –, sind “datenschutzrechtliche Kriterien zu berücksichtigen” . Die datenschutzrechtlichen Prozesse und deren Einhaltung sind regelmässig zu überwachen.
- Bei der nächsten Entscheidung zur weiteren Zusammenarbeit muss fedpol kontrollieren, ob ein zertifiziertes ISMS besteht.
- Die datenschutzrechtlichen Prozesse und deren Einhaltung sind regelmässig zu kontrollieren, durch interne oder externe Kontrollen oder einen anderen Nachweis.
- Zudem sind die Mitarbeitenden kontinuierlich auf datenschutzrechtliche Risiken zu “sensibilisieren”.
- Verträge sind im Bereich Datensicherheit zu präzisieren und ggf. zu vereinheitlichen.
Dem fedpol empfiehlt der EDÖB weiter, bei Anwendungen, die von einem anderen Bundesamt verwendet werden, mindestens eine eigene SCHUBAN durchzuführen.