Von der Kartei zum „Datenhaus“: Eine kleine Geschichte polizeilicher Datenhaltung

Alle Jahre wieder … überlegt sich die deutsche Polizei, ihre Informationssysteme zu modernisieren. Mit dem Programm „Polizei 2020“ startet der nächste Versuch, die bislang getrennten „Datensilos“ durch ein gemeinsame „Datenhaus der deutschen Polizei“ zu ersetzen.

Seit fast 50 Jahren versucht die Polizei in Deutschland, die in den Landeskriminalämtern und im Bundeskriminalamt (BKA) verfügbaren Informationen in einem Verbund zusammenzuführen. Und ebenfalls seit 50 Jahren stehen die Innenminister*innen von Bund und Ländern vor dem Problem, dass die Länder – in denen Fragen einer effizienten Polizeiarbeit immer eines der Topthemen in Wahlkämpfen sind – unabhängig voneinander mit dem Aufbau von Informationsverarbeitungssystemen beginnen. Als die Innenministerkonferenz 1972 den Aufbau des „Informationssystems der Polizei“ (INPOL) beschloss, musste sie eine Reihe nicht kompatibler Systeme miteinander verbinden. Statt eines vereinheitlichten polizeilichen Meldedienstes kam dabei aber nur ein Fahndungssystem heraus. An den Terminals der unteren Polizeibehörden konnten nun Fahndungsausschreibungen über das jeweilige Landesrechenzentrum an das Rechenzentrum des BKA übermittelt und damit automatisch bundesweit verteilt, aktualisiert, gelöscht und abgerufen werden. Damit änderte sich der polizeiliche Alltag rasant, Personenüberprüfungen konnten innerhalb von Sekunden per Funk mit dem Kolleg*innen am Terminal vorgenommen werden.

Neben der Fahndungsdatenbank wurden Datenbanken zu Personen, Institutionen, Objekten und Sachen (PIOS, später kamen „Ereignisse“ hinzu) eingerichtet, offiziell als „Aktenerschließungssysteme“ bezeichnet. Anders als im Kriminalaktennachweis KAN, in dem tatsächlich zunächst nur Fundstellen in Ermittlungsakten hinterlegt sind, ließen sich mit den PIOS-Datenbanken einzelne Daten unabhängig von ihrem Aktenzusammenhang recherchieren.[1] Zugang hatten hier nur die fachlich zuständigen Referate oder Abteilungen. Ab 1976 wurden zu einzelnen Phänomen- oder Sachbereichen „PIOS-Verfahren“ eingeführt, das erste zum Bereich Terrorismus. Diese Verfahren wurden entweder als Verbund- oder Zentraldateien geführt. In den Verbunddateien konnten die örtlichen Sachbearbeiter*innen die Daten direkt und ohne weitere Bearbeitung durch das BKA eingeben. Anders die Zentraldateien, bei denen die Daten mündlich oder per Fernschreiber angeliefert und von einem Mitarbeiter des BKA eingegeben wurden; auch die Abfrage erfolgte auf diesem Weg. Ab 1986 sollte mit der Einrichtung von „Arbeitsdateien“ auf Basis der PIOS-Verfahren der Informationsaustausch in den Bereichen Innere Sicherheit/Staatsschutz, Drogen, „Organisierte“ Kri­minalität u. a. weiter verbessert werden. Daneben wurden zur Bewältigung umfangreicher Ermittlungsverfahren „Spurendokumentationssysteme“ (SPUDOK) eingerichtet, in denen ebenfalls komplexe Suchen möglich waren.

Der PC kommt in die Polizei

Mit den 80er Jahren begann auch eine neue technologische Entwicklung. Elektronische Datenverarbeitung hieß nicht mehr nur Großrechner mit Eingabeterminals, sondern auch PC am Arbeitsplatz. Der hielt auch in den Büros der Kriminalpolizei Einzug. Die folgende Entwicklung ließ sich unter den Schlagworten Vernetzung und dezentrale Datenverarbeitung zusammenfassen.[2] Großrechner, Mehrplatzsysteme (Terminals) in Kriminalämtern und PC-Arbeitsplätze in örtlichen Polizeibehörden sollten in einem Netz zusammengebracht werden und die bis dahin betriebenen Sondernetze für Datenübertragungen per Telefon, Fernschreiber und zwischen Großrechnern ersetzen. Zugleich ermöglichte es der PC, Daten vor Ort zu erfassen und hierfür auch jeweils eigene Verfahren zu entwickeln. In den Polizeibehörden machten sich Kriminalbeamt*innen daran, eigene Datenbanken und Anwendungen zu entwickeln.

Damit entstand ein kreativer Wildwuchs. 1992 beschlossen die Arbeitsgremien der Innenministerkonferenz zu seiner Neu­ordnung das fachliche Grobkonzept für INPOL-Neu, das das alte INPOL ersetzen sollte. Erst 1998 begann der Realisierungsprozess, der aber an der ungenügenden Vorbereitung der Länder scheiterte. 2002 gab es einen bescheideneren Neubeginn, der nicht mehr die volle Integration aller Dienststellen in einen Rechnerverbund vorsah, sondern eine Weiterentwicklung des alten INPOL aus Großrechnern und Eingabeterminals war.

Der eigentliche Makel dieses Systems, nämlich der Wildwuchs aus inzwischen 27 im Verbund genutzten Anwendungen, die nur zum Teil anhand personenbezogener Merkmale durchsucht werden konnten, blieb erhalten.[3] Wie in den alten Tagen der polizeilichen Meldedienste mussten Daten weiterhin mehrfach eingegeben werden – in den zentralen Datenbanken (Personenfahndung, Fingerabdruckdatenbank AFIS etc.) und gegebenenfalls zusätzlich in den Meldediensten. Das eigentliche Ziel, alle Daten nur noch einmal erfassen zu müssen und danach für die verschiedenen Anwendungen freizugeben, konnte nicht erreicht werden. Dafür hätten sich Bund und Länder auf gemeinsame Standards, Schnittstellen oder sogar einheitliche Systeme zur Erfassung der Daten einigen müssen.

INPOL-Neu sollte ursprünglich aber nicht nur ein „Datenpool“ sein, sondern darüber hinaus auch für strategische Auswertungen und Analysen geeignet sein: für Ein- und Ausgangsstatistiken der Kriminalstatistik, für Lagebilder, für operative Führungsaufgaben. 2003 wurde dann nur noch eine Schmalspurvariante des ursprünglichen Plans aufs Gleis gesetzt: Aus der Fahndungsdatenbank wurde INPOL-Z, ein allgemeines Fahndungs- und Auskunftssystem, das die Bedürfnisse der einfachen Einsatzbeamt*innen befriedigte. Die PIOS-Verfahren (und weitere fachspezifische Anwendungen) und Falldateien wurden durch INPOL-Fall ersetzt, in erster Linie für die Kriminalämter. Hier konnten in Freitextfeldern zusätzliche Informationen gespeichert werden – sowohl Text als auch multimediale Inhalte. Alle Objekte in den Dateien ließen sich beliebig verknüpfen, für die Fallanalyse eine zentrale Fähigkeit. Immerhin konnten alle INPOL-Falldateien nun zugleich durchsucht werden, wobei den Sachbearbeiter*innen nur die Treffer angezeigt werden, für die sie die Berechtigung haben (je nach fachlicher Zuständigkeit). Damit wurde auch dem alten hierarchischen Polizeikonzept Genüge getan, dass Informationen von unten nach oben zu liefern sind, aber vor allem die unteren Ränge nur jene Dinge erfahren, die für ihre Aufgabenerledigung notwendig sind. Derzeit betreibt das BKA 38 Verbunddateien, die zum größten Teil im INPOL-Verbund geführt werden, sowie 129 Zentraldateien. Hinzu kommen an die 400 Strafverfolgungsdateien zu einzelnen Fällen, die sog. Amtsdateien.[4]

PIAV – Aufbruch zu alten Ufern

Am Ziel, polizeilich erfasste Daten so vorzuhalten und aufbereiten zu können, dass sie sowohl den Recherchebedürfnissen im einzelnen Fall als auch einer strategischen Aufbereitung genügen – also dem Erkennen neuer krimineller „Trends“ und der Ausrichtung darauf –, haben Politik und Polizeiführung festgehalten. 2006, drei Jahre nach Einführung von INPOL-Neu, beschloss die IMK deshalb den Aufbau des „Polizeilichen Informations- und Analyseverbunds“ (PIAV). Im PIAV werden keine Datenbanken geschaffen, so wie in INPOL-Fall. Vielmehr können die ohnehin vorhandenen Daten in den Informationssystemen der Landeskriminalämter wie über eine Web-Oberfläche von allen durchsucht werden. Dafür müssen entsprechende Schnittstellen programmiert werden.

Als Lehre aus dem INPOL-Desaster beschloss man gleich einen stufenweisen Ausbau: zunächst „PIAV-operativ“ mit Anwendungen für einzelne Deliktsbereiche und am Ende „PIAV-strategisch“. Als Startpunkt entschied man sich für den Bereich Waffen- und Sprengstoffkriminalität. Die alte INPOL-Falldatei „Waffen- und Sprengstoffkriminalität“ (WSK) mit dem alten Meldedienst wurde nun ersetzt.

Bis zur endgültigen Aufnahme des Wirkbetriebs des neuen PIAV-Moduls Mitte 2016 (!!) hatten die zuständigen Sachbearbeiter*innen eine E-Post (eine Art dienstliche E-Mail) an alle zuständigen Dienststellen zu richten, wenn bspw. eine Kalaschnikow irgendwo angeboten wurde. Das führte nur selten zu Trefferfällen, die auch nicht immer aktiv zurückgemeldet wurden (weil die Sachbearbeiter*innen mit eigenen Fällen ausgelastet waren). Nun können über den Anbieter der Waffe, über die Seriennummer, Herstellungsdatum oder Chargennummer Suchabfragen im PIAV gestellt werden: Ist der Händler bekannt? Gibt es ähnliche Seriennummern? Gab es an definierten Orten oder Zeiten schon ähnliche Angebote? Das ersetzt nicht die Recherchearbeit der Sachbearbeiter*innen zu jedem einzelnen „Treffer“, erleichtert aber das Generieren neuer Ermittlungsansätze. Mittlerweile wurde das Modul WSK um „Gemeingefährliche Straftaten und Rauschgiftkriminalität“ erweitert, weitere Bereiche sollen folgen.

Neues Etikett: „Polizei 2020“

INPOL-Neu konnte das Problem der technischen Inkompatibilität der polizeilichen Datentöpfe nicht lösen, und auch PIAV stellte hierfür offenbar keinen überzeugenden Ersatz dar. 2016 wurde deshalb ein weiteres Projekt gestartet, das „einheitliche Fallbearbeitungssystem“ eFBS. Es folgt der Einsicht, dass ein gemeinsames polizeiliches Informationssystem nur dann effektiv ist, wenn die „Quellsysteme“ in allen Polizeibehörden einheitlich funktionieren.

Fallbearbeitungssysteme werden vor allem von der Kriminalpolizei genutzt, um in komplexen Ermittlungsverfahren Daten eingeben und durchsuchbar halten, Verknüpfungen zwischen Personen und Objekten erkennen und Ermittlungsmaßnahmen nachhalten zu können. Daher kommen hier in einem System nicht nur eine Datenbank, sondern noch weitere Anwendungen zum Einsatz, die aber alle über eine gemeinsame Benutzeroberfläche bedient werden können.

Da nicht jede*r Beamt*in in jede Ermittlung schauen darf – sowohl aus datenschutzrechtlichen Gründen als auch zum Schutz von (insbeson­dere verdeckten) Ermittlungen – wird die dahinterliegende Datenbank in mehrere „Töpfe“ geteilt. Aber nur, wenn alle angeschlossenen Fallbearbeitungssysteme nach demselben Informationsmodell funktionieren, also die Informationen in identischer Weise Daten- und Objektkategorien zuweisen, ist die Übermittlung in ein zentrales System möglich, in dem dann die Objekte (Namen, Fahrzeuge, Tatwaffen, Fingerabdrücke etc.) übergreifend abgefragt und verknüpft werden können, um neue Tatkomplexe zu bearbeiten. Bei der Programmierung neuer Anwendungen im Polizeiverbund ist daher nun auch ein „Informationsmodell Polizei“ (IMP) zu beachten. Allerdings ist Baden-Würt­tem­berg bisher das einzige Bundesland, das es geschafft hat, ein auf dem IMP basierendes Asservatenmanagementsystem überhaupt auszuschreiben.[5]

Ebenfalls 2016 wurde eine Modernisierung von INPOL-Neu auf den Weg gebracht. Das alles kostet viel Geld. Bei der Legitimation dieser Ausgaben kamen den Innenministern einige rechtliche Neuerungen zu­pass, die dringend in der gesetzlichen Grundlage für die polizeiliche Datenverarbeitung umgesetzt werden mussten. Das war zum einen das Urteil des Bundesverfassungsgerichts zum BKA-Gesetz und damit zu den Anforderungen an die polizeiliche Datenverarbeitung,[6] und zum anderen das Inkrafttreten der Datenschutzrichtlinie der EU,[7] die ebenfalls Vorgaben zur polizeilichen Datenverarbeitung und zum Informationsaustausch macht.

Der weitere Aufbau von PIAV, die Einführung eines eFBS, die Modernisierung von INPOL-Neu wurden Ende 2016 unter dem Oberbegriff „Polizei 2020“ präsentiert und 2017 erstmals im Haushalt des Bundesinnenministeriums untersetzt. Insgesamt plant der Bund für die Umsetzung des Programms 254 Millionen Euro, wie dem Gesetzentwurf zur Novellierung des BKA-Gesetzes 2017 zu entnehmen war. Hinzu kommen die Kosten bei Bundespolizei und Zollkriminalamt sowie in den Landespolizeien. Insgesamt ist die Rede von 500 Millionen Euro Gesamtkosten, die durch den Bund und die Länder im Rahmen eines „Police-IT-Fonds“ erbracht werden sollen. Im „white paper Polizei 2020“ wird außerdem die Einführung eines einheitlichen Vorgangsbearbeitungssystems eVBS als Ziel genannt.[8]

Zu tun gibt es einiges. Einige Länder sehen gar nicht ein, dass sie ihre zum Teil selbst entwickelten, zum Teil zumindest nach ihren fachlichen Vorgaben angepassten Fall- und Vorgangsbearbeitungssysteme zugunsten eines eFBS bzw. eines eVBS aufgeben sollen.

Beim 2018 in BKA und Bundespolizei eingeführten eFBS handelt es sich um eine Variante des Produkts b-case der Firma Rola security solutions, einer Telekom-Tochter. Auch in zwei Dritteln der Länder ist eine Variante dieses Fallbearbeitungssystems etabliert, RSCase. Diese könnten auf das neue Produkt wechseln; wann und ob sie das tun, ist noch unklar. Notwendig wäre es, denn gleicher Anbieter und gleiches Programm bedeuten nicht, dass diese Systeme untereinander Informationen austauschen können. Bei länderübergreifenden Lagen und Ermittlungen geschieht dies vereinzelt weiter „händisch“.[9] Hamburg, Hessen, Baden-Württemberg und Brandenburg nutzten lange Zeit eine Eigenentwicklung für die Fallbearbeitung, CRIME (Criminal Research Investigation Management Software), sind aber im Februar 2019 ebenfalls bereits auf das eFBS gewechselt.[10]

So lange unterschiedliche FBS genutzt werden, müssen jeweils eigene Anwendungen für die Anbindung an PIAV programmiert werden – nur so können aus dem FBS heraus Informationen direkt in PIAV abgefragt und umgekehrt an PIAV ausgeliefert werden, ohne sie erneut eingeben zu müssen. Gerade für die Kriminalbeamt*innen, die früher bei jedem Vorgang entscheiden mussten, ob sie Daten und Erkenntnisse über die Kriminalpolizeilichen Meldedienste in die Verbunddateien des BKA anliefern und damit ein weiteres Mal eingeben müssen, wäre das sicherlich eine Erleichterung.

Für das Gelingen des Gesamtprojekts wird jedoch die Einführung eines eVBS als deutlich kritischer angesehen. „Ohne dessen Einbindung dürfte das angestrebte Ziel der Einmalerfassung der Daten nicht erreichbar sein“, kommentierte der „Behördenspiegel“.[11] Schließlich werden in den Vorgangsbearbeitungssystemen alle polizeilich relevanten Vorgänge erfasst, von der nächtlichen Ruhestörung über den aufgenommenen Verkehrsunfall bis hin zu angezeigten Kapitalverbrechen. Mit ihnen arbeiten also vornehmlich die uniformierten Polizist*innen der Schutz- und der Verkehrspolizei. Sie enthalten Massen von personenbezogenen Daten von Geschädigten, Verdächtigen, Zeugen oder auch gänzlich unbeteiligten Personen, die im Rahmen der Sachverhaltsaufklärung in Kontakt mit der Polizei gekommen sind. Durch die Fokussierung auf die Bedürfnisse der Dienststellen in der Fläche geriet bei zahlreichen Eigenentwicklungen in diesem Bereich aus dem Blick, dass die dort erhobenen Daten gegebenenfalls einmal außerhalb des eigenen Bundeslandes zur Verfügung stehen müssen.

Datenschutz im Nexus

Der Umgang mit Daten gerät bei der Polizei nicht nur durch Einzelfälle wie „Helene Fischer“ ins Zwielicht. Auch Prüfungen durch Datenschutzbeauftragte fördern regelmäßig einen rechtswidrigen Umgang mit Daten zutage. Die Rationalität des polizeilichen Umgangs mit einmal erhobenen Daten folgt dem Messie-Prinzip: „Man weiß ja nicht, wofür man es noch mal braucht“. Unter diesem Motto kann bereits eine Personalienfeststellung im Rahmen einer polizeilichen Maßnahme gegen andere Personen ausreichen, um weiter gespeichert zu werden. So stellte der bayerische Datenschutzbeauftragte bei einer Prüfung des Kriminalaktennachweises der Landespolizei, einem Vorgangsbearbeitungssystem, tausende unberechtigte Speicherungen fest.[12] Von 54.543 durch das Zoll­kriminalamt in der „Falldatei Rauschgift“ gespeicherten Personendatensätzen mussten nach einer gemeinsamen Prüfung durch die Datenschutzbeauftragten des Bundes und der Länder 43.452 gelöscht werden.[13] Im Bereich der erkennungsdienstlichen Daten beim BKA mussten 2,1 Millionen Datensätze gelöscht werden, die das BKA entweder ungeprüft in seinen eigenen Datenbestand übernommen hatte oder für die keine fristgerechte Prüfung vorgenommen wurde, ob die Daten tatsächlich noch benötigt wurden.[14] Und wie viele selbst erstellte excel-, access- oder word-Dateien auf Polizei-PC schlummern, in denen Beamt*innen wegen der fehlenden Interoperabilität der Datenbanken selbst Daten zusammengeführt haben, kann nur spekuliert werden. Häufige Beanstandungen von Datenschutzbeauftragten beziehen sich außerdem darauf, dass die Speichervoraussetzungen in den Errichtungsanordnungen nicht erfüllt sind oder dazu jedenfalls kein Aktenrückhalt vorliegt.

Die Errichtung der Zentral- und Verbunddateien beim Bundeskriminalamt setzte bislang zwingend immer eine solche Errichtungsanordnung voraus. Darin sind detailliert Zweck der Datei, Speicheranlässe und zu speichernde Daten definiert. Diese Errichtungsanordnungen sind zentraler Maßstab für die Prüfungen durch die Datenschutzaufsicht. Mit dem 2018 in Kraft getretenen neuen Bundeskriminalamtsgesetz wurden diese Errichtungsanordnungen aber abgeschafft. Denn alle polizeilichen Daten sollen ja nun in einem einzigen Informationssystem gespeichert werden. Die Einhaltung datenschutzrechtlicher Standards – in erster Linie der Erforderlichkeit und Zweckbindung – sollen zukünftig vor allem technisch sichergestellt werden. Unter der Überschrift „Stärkung des Datenschutzes durch Technik“ ist im white paper Polizei 2020 die Rede von „dynamischen und zielgerichteten Berechtigungskonzepten“, die weitaus „differenzierter und zielgerichteter“ seien als aktuelle Regelungen. Ein „zielgerichteter und passgenauer Datenschutz“ (sprich: auf keinen Fall mehr als nötig) soll durch ein „modernes, differenziertes und dynamisches Zugriffsmanagement“ gesichert werden.[15] Bei der Vorstellung des Programms sprach der Präsident des BKA immer wieder von einem „Rechte- und Rollenkonzept“, mit dem zukünftig die Vorgaben des Bundesverfassungsgerichts gewahrt werden sollen. Das heißt, dass weiterhin nicht alle Polizist*innen auf alle Daten Zugriff haben, sondern einerseits nur auf diejenigen, die zu ihrer Aufgabenerfüllung erforderlich sind, also die Drogenfahnderin nur auf die Daten mit Bezug zur Rauschgiftkriminalität. Andererseits muss das Konzept der „hypothetischen Datenneuerhebung“ umgesetzt werden, nach dem Informationen aus einer eingriffsintensiven Maßnahme (etwa einer Telefonüberwachung bei gewerbsmäßigem Drogenhandel) nur dann in einer anderen Ermittlung oder einem Gefahrenabwehrvorgang – also zu einem anderen Zweck – verwendet werden dürfen, wenn dabei erneut dieselbe Maßnahme durchgeführt werden dürfte (etwa eine Mordermittlung ohne Zusammenhang zur anderen Tat). Dieses Prinzip setzt zwingend eine entsprechende Kennzeichnung der Daten im Informationssystem voraus – also Angaben zum Erhebungszweck, zur Herkunft der Information, auch zu Aussonderungsprüffristen.

Ein zentrales Problem entsteht nun durch den Nexus, den Übergang vom alten Datenhaltungsregime zum neuen: schon technisch, denn alle Daten müssen zunächst dem Informationsmodell Polizei entsprechen, sonst können sie nicht migriert werden. Praktisch müssen bei der Migration alle personenbezogenen Daten daraufhin geprüft werden, ob sie tatsächlich weiter erforderlich sind. Auch dabei müssen alle speichernden Stellen mitmachen, denn die Daten stehen dann ja dem gesamten Verbund zur Verfügung. Zunächst einmal bleiben jedoch alle Zentral- und Verbunddateien sowie die BKA-eigenen Falldateien so bestehen, wie sie sind – dafür hat sich das BKA eine unbefristete Übergangsregelung in das neue BKA-Gesetz schreiben lassen. Und wie dann das neue Informationssystem beschaffen sein und wie das Rechte- und Rollenkonzept darin umgesetzt werden soll, dazu gibt es noch nicht einmal ein technisches Konzept. Der Bundesdatenschutzbeauftragte stellte für 2018 fest, „dass weder BMI noch BKA mir bislang detaillierte und aussagekräftige Unterlagen für die geplante neue IT-Struktur der deutschen Polizei vorgelegt haben.“[16] An diesem Befund hat sich bis Anfang 2020 nichts geändert.

Von einem einheitlichen Datenhaus, in das alle Polizeibehörden in Deutschland auf dem gleichen Weg ihre Daten zuliefern und in dem alles für alle auch tatsächlich verfügbar ist, ist der aktuelle Zustand also noch weit entfernt. „Kommissar Computer“ bleibt weiterhin science fiction aus den 70ern. Es mag einerseits possierlich sein, dass sich die hochtrabenden Pläne und Ankündigungen so deutlich in der Wirklichkeit blamieren. In dem dadurch weiterwachsenden Wildwuchs von Informationssystemen kommen aber vor allem die Rechte derjenigen unter die Räder, deren Daten dort gespeichert sind.

[1]   Schraut, L.: PIOS-Dateien, Meldedienste und Spurendokumentationen – die wichtigsten Systeme, in: Bürgerrechte & Polizei/CILIP 41 (1/1992), S. 29-34
[2]   Schallbruch, M.; Mörs, S.: Neue Wege in der polizeilichen Datenverarbeitung – Dezentralisierung des Technikeinsatzes und Erschließung neuer Arbeitsgebiete, in: Bürgerrechte & Polizei/CILIP 41 (1/1992), S. 12-18
[3]   Busch, H.: INPOL-Neu – Informatisierung des polizeilichen Alltags, in: Bürgerrechte & Polizei/CILIP 76 (3/2003), S. 12-19
[4]   Stand der Umsetzung des Programms „Polizei 2020“, Antwort auf die Kleine Anfrage der Fraktion DIE LINKE, BT-Drs. 19/15346 v. 21.11.2019
[5]   White paper „Polizei 2020“ v. 18.1.2018, S. 27 (www.bmi.bund.de/SharedDocs/downloads/DE/ veroeffentlichungen/2018/polizei-2020-white-paper.pdf)
[6]   Bundesverfassungsgericht: Urteil v. 20.4.2016, Az.: 1 BvR 966/09 (www.bverfg.de)
[7]   Richtlinie (EU) 2016/680 v. 27.4.2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten durch die zuständigen Behörden zum Zwecke der Verhütung, Ermittlung, Aufdeckung oder Verfolgung von Straftaten oder der Strafvollstreckung sowie zum freien Datenverkehr
[8]   White paper a.a.O. (Fn. 5)
[9]   Polizeiliche IT-Landschaft gleicht einem Flickenteppich“, Meldung des Bundes Deutscher Kriminalbeamter (BDK) v. 30.3.2016 (www.bdk.de)
[10] Diese und viele weitere nützliche Informationen sind unter dem „Glossar“ auf der Seite police-it.org zu finden
[11] Der lange Weg zum gemeinsamen Datenhaus, Behördenspiegel v. 8.1.2020
[12] Schulzki-Haddouti, C.: Außer Kontrolle. Fragwürdiger Datenschutz in Polizeisystemen, in: c´t 2016, H. 13, S. 154-157 (auch auf heise online)
[13] Bundesbeauftragter für den Datenschutz und die Informationsfreiheit: 27. Tätigkeitsbericht für 2017 und 2018, BT-Drs. 19/9800 v. 8.5.2019, S. 78
[14] ebd.
[15] White paper a.a.O. (Fn. 5), S. 10
[16] Bundesbeauftragter a.a.O. (Fn. 13), S. 70

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert