Version: V1.0
Bezugsquelle: https://www.datenschutz-mv.de/datenschutz/datenschutzmodell/
Dieser Baustein dient vorrangig der Umsetzung folgender DS-GVO-Anforderungen (vgl. SDMV2b-Methodik-Handbuch, Teil B):
| Anforderungen der DS-GVO | Gewährleistungsziele |
|---|---|
| Rechenschafts- und Nachweisfähigkeit (Art. 5 Abs. 2, Art. 7 Abs. 1, Art. 24 Abs. 1, Art 28 Abs. 3 lit. a, Art. 30, Art. 33 Abs. 5, Art. 35, Art. 58 Abs. 1 lit. a und lit. e DS-GVO) | Transparenz |
| Evaluierbarkeit (Art. 32 Abs. 1 lit. d DS-GVO) | Umsetzung aller Gewährleistungsziele |
Die Planung und Spezifikation einer Verarbeitung ist mit der Festlegung der Mittel (i. S. d. Art. 4 Satz 1 Nr. 7 DS-GVO) ein aus datenschutzrechtlicher Sicht erforderlicher Schritt. Dieser Schritt hat sich an den Grundsätzen der Verarbeitung personenbezogener Daten nach Art 5 DS-GVO zu orientieren. Die DS-GVO fordert zudem in Art. 25 die Durchsetzung von Datenschutzanforderungen bereits im Prozess der Technikgestaltung und durch datenschutzfreundliche Voreinstellungen der verwendeten IT-Systeme („Data protection by design and by default“).
In der Planungsphase ist daher die Verarbeitungstätigkeit und die mit ihr verbundenen Verarbeitungsvorgänge mit hinreichender Tiefe so zu spezifizieren, dass die Verarbeitungstätigkeit mit ihren wesentlichen Daten, Systemen und Diensten sowie Prozessen der Verarbeitung präzise und vollständig festgelegt sowie nachvollziehbar und prüfbar dokumentiert ist. Dazu müssen Verantwortliche alle relevanten Aspekte sichten und zusammenstellen, die normativ gefordert und folglich funktional notwendig sind. Diese müssen dann in einer oder in mehreren Spezifikationen aufgegriffen, verdichtet und festgelegt werden.
Die Spezifikationen der technischen Komponenten einer Verarbeitungstätigkeit SOLLTEN die Form eines Lasten- und Pflichtenhefts annehmen (M41.S01). Der Auftraggeber (im Datenschutz immer der Verantwortliche) beschreibt im Lastenheft möglichst präzise die Gesamtheit der umzusetzenden Anforderungen. Das Pflichtenheft beschreibt dann in konkreter Form, wie und womit der Auftragsverarbeiter die Anforderungen des Auftraggebers einzulösen beabsichtigt. Im Zuge der Umsetzung des Vorhabens kann die Führung der Umsetzung auf die kontinuierliche Verbesserung der Spezifikationen übergehen; das Lasten- und Pflichtenheft müssen nicht nachgeführt werden. Dem Verantwortlichen wird empfohlen, die diesbezüglichen Aufgaben in einem organisationsinternen, umsetzungsbefugten Gremium zu implementieren. Es ist nicht der oder die Datenschutzbeauftragte für die Planung und Durchsetzung von Datenschutzanforderungen zuständig oder gar verantwortlich. Doch der Verantwortliche sollte den Datenschutzbeauftragten gemäß Art. 39 Nr. 1 lit. c DSGVO zu Rate ziehen.
Als ein wesentlicher Teil der Planungsphase einer Verarbeitungstätigkeit MUSS der Verantwortliche prüfen, ob eine Datenschutz-Folgenabschätzung (DSFA) gemäß Art. 35 DS- GVO erforderlich ist. Zu diesem Zweck muss er eine Schwellwertanalyse durchführen. Mit einer Schwellwertanalyse wird die Risikostufe der Verarbeitungstätigkeit bestimmt (M41.P01). Wenn die Schwellwertanalyse als Ergebnis voraussichtlich ein geringes oder normales Risiko ausweist, liegt die Begründung dafür vor, dass keine DSFA durchzuführen ist. Wenn das Ergebnis ein voraussichtlich hohes Risiko ausweist, MUSS der Verantwortliche grundsätzlich für die Verarbeitungstätigkeit eine DSFA mit den in Art. 35 DS-GVO festgelegten Bestandteilen und Abläufen durchführen. Für die Untersuchung mehrerer ähnlicher Verarbeitungsvorgänge mit ähnlich hohen Risiken kann eine einzige Abschätzung vorgenommen werden (Art. 35 Abs. 1 Satz 2 DS-GVO).
Von der Risikostufe hängt die Spezifikation der Ausgestaltung der Verarbeitung, die Auswahl und Dimensionierung der technischen und organisatorischen Maßnahmen (Schutzmaßnahmen) sowie die Intensität der Überwachung der Verarbeitung und Schutzmaßnahmen ab.
Der Umfang der zu spezifizierenden Schutzmaßnahmen ergibt sich aus den Anforderungen der DS-GVO, insbesondere aus den Grundsätzen für die Verarbeitung personenbezogener Daten gemäß Art. 5 DS-GVO und den Betroffenenrechten nach Art. 12ff DS-GVO. Die Orientierung an den Gewährleistungszielen hat sich im Kontext der Modellierung von Anforderungen der IT-Sicherheit und ihrer systematischen Durchsetzung bewährt. Die Grundsätze der DS-GVO aus Artikel 5 bzw. die Gewährleistungsziele sowie weiterer, spezifischer Anforderungen der DSGVO müssen in jedem Falle in einer Spezifikation vollständig beachtet bzw. umgesetzt werden, einschließlich des methodisch zu erbringenden Nachweises ihrer Wirksamkeit insbesondere durch Dokumentation und Protokollierung (vgl. Art. 5 Abs. 2, Art. 24 Abs. 1, Art. 32 Nr. 1 lit. d DS-GVO). Damit ein Nachweis der Wirksamkeit von Maßnahmen gelingt, müssen alle für die Verarbeitungstätigkeit relevanten Komponenten auf den unterschiedlichen Ebenen (Rechtsgrundlagen, Prozessgestaltungen, Sachbearbeitung, Fachapplikation, Kommunikationstechniken) während der Planung identifiziert und durch Spezifikationen prüfbar und letztlich (datenschutz-)rechtlich beurteilbar gemacht werden.
2.1 Spezifizieren durch Vorwegnahme von Anforderungen im Kontext des Kontrollierens, Prüfens und Beurteilens
Es ist für die Strukturierung einer Planungsphase hilfreich, die Aktivitäten des Kontrollierens, Prüfens und Beurteilens zu unterscheiden, um die notwendigen Schutzmaßnahmen identifizieren zu können. Das Durchlaufen dieser drei Aktivitäten bildet die Voraussetzung für den Verantwortlichen, Entscheidungen bzgl. der Verarbeitungstätigkeit, mit der Ausrichtung der Ziele und der Bestimmung der dafür einzusetzenden Mittel, verantworten zu können.
Die Mittel zur Gewährleistung von Kontrollierbarkeit, Prüfbarkeit und Beurteilbarkeit einer Verarbeitungstätigkeit sind
-
die Spezifikation der Daten, Systeme und Dienste sowie Prozesse, mit Ausweis insbesondere der funktionalen Sollwerte (ist die Funktion dieses Bausteins),
-
die Dokumentation der Verarbeitungstätigkeit (einschließlich ihrer Daten, Systeme und Dienste sowie Prozesse), um einen laufenden Betrieb prüfbar zu machen. Dazu müssen sowohl die Sollwerte als auch die Methode zur Gewinnung von Soll- und Ist- Werten schriftlich festgehalten werden (siehe den Baustein „Dokumentation“) sowie
-
die Protokollierung der Ereignisse eines Regelbetriebs anhand gespeicherter funktionaler Ist-Werte (siehe den Baustein „Protokollieren“), um Sachverhalte bzgl. der Verarbeitungstätigkeit und der darin eingesetzten Komponenten in der Vergangenheit aufklären zu können.
Um eine Verarbeitungstätigkeit hinsichtlich der Einhaltung der Anforderungen der DS-GVO bzw. der Gewährleistungsziele kontrollieren zu können, MÜSSEN diese in prüfbare funktionale Sollwerte bzw. Prüfkriterien übersetzt werden. Dazu muss zunächst ermittelt werden, welche Daten, Systeme und Dienste, Prozesse, Eigenschaften, Funktionen oder Ereignisse einer Verarbeitungstätigkeit für die Umsetzung von Anforderungen der DS-GVO bzw. der Gewährleistungsziele relevant oder nicht relevant sind (siehe auch Abschnitt 2.4). Die funktionalen Sollwerte bzw. Prüfkriterien werden bezüglich der ermittelten relevanten Komponenten festgelegt.
In der Praxis SOLLTEN die Bestimmung der relevanten Komponenten und die Übersetzung der datenschutzrechtlichen Anforderungen in Prüfkriterien durch Besprechungen all derjenigen Mitarbeiterinnen und Mitarbeiter, von denen ein materiell wesentlicher Beitrag bzgl. der Komponenten einer Verarbeitungstätigkeit zu erwarten ist, erfolgen (M41.P02).
Eine Prüfung basiert auf dem Vergleich von (funktionalen) Soll- und Ist-Werten, die für relevante Komponenten erhoben bzw. gemessen werden. Der Zweck des Prüfens im Datenschutz ist das Gewinnen von funktional erzeugten Prüfergebnissen in einer datenschutzrechtlich beurteilbaren Form. Diese Prüfungsanforderungen bzw. die Prüfkriterien müssen eine Spezifikation aufgreifen.
Es lassen sich dabei mindestens drei Prüf- bzw. Spezifikationstiefen unterscheiden, die für den Betrieb und die Überwachung von Verarbeitungstätigkeiten sowie deren Schutzmaßnahmen beachtet werden müssen (M41.P03):
Die DS-GVO gibt eine Anforderung für die Verarbeitung von personenbezogener Daten vor, die mit Hilfe generischer Maßnahmen des SDM umgesetzt werden kann.
Beispiel: Die DS-GVO verlangt in Art. 5 Abs. 2 in Verbindung mit Art. 24 Abs. 1, dass der Verantwortliche eine datenschutzkonforme Verarbeitung personenbezogener Daten nachweisen können muss. Das Standard-Datenschutzmodell (SDM) übersetzt im Kapitel D1 (Generische Maßnahmen) diese normative Anforderung in eine funktional zugängliche Anforderung und verlangt, Transparenz bzgl. der Nachweisbarkeit der ausgewählten Schutzmaßnahmen durch Spezifikation und Dokumentation des funktional Geforderten sowie die Protokollierung des laufenden Betriebs. In der Spezifikation einer Verarbeitungstätigkeit müssen entsprechend diese drei Themen bearbeitet werden. Eine Prüffrage auf diesem Niveau könnte sich darauf beziehen, ob die Ereignisse einer Verarbeitungstätigkeit durchgängig protokolliert werden, ob die Protokolle durch ein Backup gesichert, revisionsfest, verschlüsselt, dokumentiert, im Hinblick auf Zweckbestimmtheit geprüft sind, und nicht zuletzt im Hinblick auf Erfüllung von Auskunftsansprüchen oder Datenlecks sowohl ereignisgetrieben als auch regelmäßig ausgewertet werden.
Das SDM weist konkrete Anforderungen an Methoden, Strukturen und Komponenten für generischen Maßnahmen aus, die durch Schutzmaßnahmen aus den SDM-Bausteinen als konkrete Soll-Werte umsetzbar sind.
Beispiel: Das SDM verlangt im Baustein Protokollierung, dass Protokolleinträge für bestimmte Aktivitäten mindestens einen Bezug zum Zeitpunkt, einen Bezeichner für die auslösende Quelle sowie für das Ereignis innerhalb dieser Aktivität aufweisen müssen. Entsprechend muss die Struktur der Protokolle mindestens dreistellig spezifiziert werden. Eine Prüffrage auf diesem Prüfniveau könnte bspw. lauten, ob die Protokolldaten einen Zeitstempel sowie einen Bezeichner für die Ereignisse und einen Bezeichner für die auslösenden Quellen aufweisen.
Das SDM weist Anforderungen in den Bausteinen aus, die für konkrete, funktionale Soll- Werte, abhängig von der Risikostufe, herangezogen werden können.
Beispiel: Das SDM verlangt für die in Protokollen verwendeten Zeitstempel, dass diese bei hohem Risiko zertifiziert sein sollten, um bei Auswertungen zweifelsfrei kausale Zuschreibungen von Ereignissen auch in langen Prozessketten vornehmen zu können. Somit wäre die notwendige Qualität eines Zeitstempels zu spezifizieren. Dies muss dann sowohl im Hinblick auf die Vertrauenswürdigkeit des Zeitstempels als auch des notwendigen Auflösungsniveaus geschehen, um die Abfolgen verschiedener Ereignissen hinreichend voneinander unterscheiden zu können. Auch die anderen Einträge eines Protokolls, bspw. die Bezeichner für Ereignisse und auslösende Quellen, können bestimmte Eigenschaften aufweisen. Auf diesem Niveau wären demnach die Eigenschaften der in der Protokollierung verwendeten Zeitstempel zu spezifizieren. Welche Qualitäten hier gefordert sind, ergibt sich aus der Messbarkeit von Ereignissen bzw. den Aktivitäten der technischen und organisatorischen Maßnahmen. Wenn bspw. eine explizit angestoßene Verschlüsselung als eine Aktivität der Maßnahme stattgefunden hat, dann können in der Dokumentation zur Verschlüsselung die Algorithmen, die Implementierung in einer bestimmten Programmiersprache, die gesamten Umstände der Verschlüsselungsaktivitäten beschrieben werden – was zu spezifizieren ist – und anhand der Protokollierung sollte prüfbar sein, dass zu einem bestimmten Zeitpunkt eine bestimmte Datei oder Mail mit dem bestimmten Verschlüsselungsprogramm, auf Veranlassung einer anderen Applikation oder eines Nutzers, tatsächlich wirksam verschlüsselt wurde. Bei automatisierten Verschlüsselungen (z. B. Festplattenverschlüsselungen, TLS, VPN, etc.) sollten die Konfigurationsschritte (Aktivierung/Deaktivierung) einer Verschlüsselung protokolliert werden.
Prüfergebnisse sind ohne Kontextbildung nicht angemessen interpretierbar bzw. beurteilbar. Abweichungen zwischen Soll- und Ist-Werten müssen dahingehend datenschutzrechtlich beurteilt werden können, ob eine Verarbeitungstätigkeit trotz dieser Abweichungen datenschutzrechtlich konform („compliant“) oder nicht konform ist. Der Zweck einer Beurteilung besteht darin, ein Dokument zu erzeugen, das den Verantwortlichen (oder den von ihm für zuständig Erklärten) entscheidungsfähig macht, um festgestellte Mängel zu beheben.
Beispiel: Es werden anhand der Spezifikation dem ersten Augenschein nach funktionale Abweichungen festgestellt. Entgegen diesem Anschein kann es rechtliche Umstände geben, in denen von einer Protokollierung abgesehen werden kann (Spezifikationstiefe 1), in denen der Zeitpunkt einer Aktivität nicht relevant ist (Spezifikationstiefe 2) oder die Vertrauenswürdigkeit eines Zeitstempels nicht beachtet werden muss (Spezifikationstiefe 3). Oder aber es zeigt sich, dass rechtlich relevante Aspekte nicht in hinreichender Spezifikationstiefe beachtet und bearbeitet wurden und es rechtlich begründbare funktionale Spezifikationslücken gibt. Der Verantwortlich muss aus dem Beurteilungsergebnis dann Entscheidungen bzgl. der Abhilfe treffen, die er dann erneut in die Spezifikation gibt.
Bereits in der Planungsphase MUSS der Verantwortliche deshalb vorläufige Spezifikationsentwürfe und Prüfergebnisse, die bspw. anhand von Tests erzeugt wurden, rechtlich beurteilen, um ihre Geeignetheit sicherzustellen (M41.P04).
Komponenten und der gewünschten Eigenschaften Die folgenden Aspekte einer Verarbeitung MÜSSEN vom Verantwortlichen, unabhängig von der Risikostufe, spezifiziert werden:
- Eine Beschreibung der Datenverarbeitung („Verarbeitungstätigkeit“, „Verarbeitung“, „Verarbeitungsvorgänge“) MUSS unter funktionalen und organisatorischen Aspekten inkl. der Festlegung der Verantwortlichkeit erarbeitet werden. Dies ist in der Regel mehr als nur ein Erfassen einer Verarbeitungstätigkeit im Sinne einer Inventarisierung aller Verarbeitungstätigkeiten einer Organisation, wie es das Verzeichnis der Verarbeitungstätigkeiten gemäß Art. 30 DS-GVO vorschreibt. Beschrieben werden müssen vornehmlich die zu verarbeitenden personenbezogenen Daten sowie die damit in Verbindung stehenden Datei- oder Datenbankfelder (M41.D01). Benannt werden müssen außerdem die dabei zum Einsatz kommenden Systeme und Dienste sowie Prozesse auf einem zunächst allgemein verständlichen Niveau als Anker für die nachfolgenden spezifischen Ausführungen (M41.S02). Es müssen insbesondere die Schnittstellen zwischen den Systemen und Diensten sowie die Datenflüsse zwischen diesen dargestellt werden. Sollte dabei der Zweck der geplanten Verarbeitung noch nicht ausreichend beschrieben worden sein, um die Verarbeitung spezifizieren zu können, ist dies nachzuholen. Dabei ist es hilfreich, wenn auch die Grenzen der Verarbeitung beschrieben werden, indem erläutert wird, welche anderen, denkbaren Zwecke explizit nicht verfolgt bzw. erfüllt werden sollen (M41.P05).
- Die an der Verarbeitung beteiligten Organisationen/Akteure und die betroffenen Personen MÜSSEN identifiziert werden. Dies ist die Voraussetzung, um sämtliche Rechtsbeziehungen mit ihren gesetzlichen Grundlagen sowie Erfordernissen für eine vertragliche Gestaltung und ggf. das Einholen von Einwilligungen zu erkennen. Das hat Auswirkungen auf die technische Gestaltung (M41.P06).
- Die für die Verarbeitung notwendigen Rechtsgrundlagen MÜSSEN identifiziert und zusammengestellt werden. Stellt sich dabei heraus, dass keine tragfähigen Rechtsgrundlagen vorhanden sind, muss die Verarbeitung so lange unterbleiben, bis die Rechtsgrundlagen geschaffen wurden. Dabei können sich im Kontext der Spezifikation weitere Regelungsbedarfe ergeben. Vor Beginn der Verarbeitungstätigkeit müssen in der Regel spezifische Vertragsbestandteile, Texte zur Einwilligung und Datenschutzerklärungen erstellt werden. Der Verantwortliche MUSS prüfen, ob die Rechtsgrundlagen Detailregelungen enthalten (bspw. Lösch- und Mindestaufbewahrungsfristen, Übermittlungsbefugnisse), die die Verarbeitung unmittelbar konkretisieren (M41.P07).
- Der Verantwortliche MUSS typische Einsatzszenarien der Verarbeitung bzw. Verarbeitungstätigkeit („Usecases“) erarbeiten, um daraus ein Angreifermodell bilden zu können, in denen beteiligte Akteure befugt und unbefugt (als Angreifer) auf Daten zugreifen könnten. Anhand der Usecases und Akteure können so relevante Komponenten erkannt werden, deren Funktionieren datenschutzrechtlich überprüft werden muss (M41.P08).
- Eine datenschutzrechtliche Risikoanalyse (Schwellwertanalyse) zur Ermittlung des Risikos der geplanten Verarbeitungstätigkeit MUSS durchgeführt werden (Details siehe SDM-V2b-Methodik Abschnitt D 3.2.1). Das betrifft auch Verarbeitungen mit einem unmittelbar erkennbaren geringen Risiko für Betroffene, um begründen zu können, dass keine DSFA durchgeführt wurde (M41.P01).
- Der Verantwortliche MUSS eine angemessene Struktur für die Form der Spezifikation (z. B. als Lastenheft/ Pflichtenheft), der Dokumentation und Protokollierung festlegen (M41.P09).
- Um die für die geplanten Einsatzszenarien notwendigen Schutzmaßnahmen erkennen, bestimmen und dimensionieren zu können, MÜSSEN die Risikokriterien aus den Grundsätzen gemäß Art. 5 DS-GVO bzw. den Gewährleistungszielen des SDM für die Verarbeitungstätigkeit hergeleitet werden. Die Schutzmaßnahmen der auf den verschiedenen Ebenen genutzten Komponenten sind ein wesentlicher Teil des Lastenhefts. Erforderlich ist zudem das Festlegen der Konfigurationen und der Mittel, mit denen die Prüfbarkeit im laufenden Betrieb sichergestellt werden kann. Hierbei SOLLTE insbesondere der Referenzmaßnahmen-Katalog des SDM herangezogen werden (M41.P10). Es SOLLTE ein Migrationskonzept für den Fall erstellt werden, dass ein Altdatenbestand in eine neue Verarbeitungstätigkeit bzw. in eine neue Applikation übernommen werden muss (M41.P11).
- Nach Abschluss dieser Arbeiten SOLLTE ein Bericht zu den vorgenannten Aktivitäten erstellt werden, der dem Verantwortlichen als Grundlage dient, die Risiken zu beurteilen und über die (Priorisierungen der) Implementation der Funktionen der Verarbeitungstätigkeit sowie der technischen und organisatorischen Maßnahmen entscheiden bzw. diese priorisieren zu können. Bei einem hohen Risiko MUSS dieser Bericht die Form eines DSFA-Berichts mit seinen Anforderungen gemäß Art. 35 DS- GVO annehmen (M41.P12). Ein Konzept zur Umsetzung der Anforderungen an die Verarbeitung MUSS anhand der vorgenannten Dokumentationen sowie der Entscheidungen des Verantwortlichen erarbeitet werden. Dies kann in Form eines Lastenhefts geschehen. Der Verantwortliche MUSS dieses Konzept bzw. Lastenheft vor der Umsetzung förmlich abnehmen (M41.P13). Ein Testkonzept für die Wirksamkeit der Funktionen insbesondere der technischen und organisatorischen Maßnahmen MUSS erstellt werden. Mit derartigen Tests MUSS der Verantwortlichen dokumentieren und nachweisen, dass alle Anforderungen erfüllt werden können (M41.P14). Es MUSS ein Pilotierungskonzept erstellt werden, wenn für eine begrenzte Zeit ein Produktivbetrieb zu Testzwecken (Pilotbetrieb) durchgeführt werden soll. Fehler, die sich sonst erst im Produktivbetrieb zeigen, sollen während dieses Pilotbetriebs erkannt und behoben werden (M41.P15). Rechtlich gilt ein Pilotbetrieb bereits als Regelbetrieb, so dass vor der Aufnahme des Pilotbetriebs alle datenschutzrechtlichen Anforderungen erfüllt sein müssen.
- Es MUSS für den Übergang vom Pilot- in den Produktivbetrieb ein Prozess zur Freigabe der Verarbeitung – oder wenn es sich nur um die Erneuerung der IT- Unterstützung handelt, dann muss nur diese freigegeben werden – durch den Verantwortlichen festgelegt werden. Dabei ist auch festzulegen, mit welchen Mitteln die permanente Überprüfung und Beurteilung des Produktivbetriebs der Verarbeitung im Kontext eines organisationsweit operierenden Datenschutz- Managements sichergestellt werden kann (M41.P16).
Als Voraussetzung für die Klärung der konkreten, funktionalen technischen und organisatorischen Anforderungen und Maßnahmen muss die rechtliche Situation geklärt sein. Diese Klärung kann aus dem Planungsbereich angestoßen werden. Die Prüfung von Rechtsgrundlagen liegt definitionsgemäß außerhalb des vom SDM beanspruchten Regelungsumfangs.
Die Spezifikation einer Verarbeitung muss die folgenden Ebenen analysieren und dokumentieren:
- die Gestaltung der Prozesse („Fachlichkeit“) der Verarbeitungstätigkeit, die den fachrechtlichen und datenschutzrechtlichen Anforderungen genügen müssen,
- die Nutzung einer Fachapplikation durch die Sachbearbeitung,
- die Technik der Datenverarbeitung, der Prozesse, IT-Systeme und Dienste,
- die Schnittstellen von Prozessen und IT-Systemen sowie
- die jeweilige Administration der vorgenannten Ebenen.
Aus der Beschreibung der Prozesse, aus denen die Verarbeitungstätigkeit besteht, und der Berücksichtigung insbesondere der datenschutzrechtlichen Anforderungen, müssen die konkreten funktionalen Anforderungen bzgl. der Funktionen der Fachapplikation, der dafür genutzten Techniken, Schnittstellen und Administration, entsprechend der bestimmten Risikostufe und der festgelegten Spezifikationstiefe, spezifiziert werden (M41.P17).
Eine Spezifikation MUSS Prozessabläufe beschreiben mit Bezug zum Erreichen des beschriebenen Zwecks sowie allgemeingehaltene Beschreibungen der dafür notwendigen Daten und IT-Komponenten, als Anker für präzise Dokumentation. Dabei sind auch die fachgesetzlichen und vertraglichen sowie die datenschutzrechtlichen Anforderungen zu berücksichtigen (M41.P18). Von dieser Ebene ausgehend ist die Angemessenheit und Erforderlichkeit der technischen Umsetzung zu beurteilen.
Eine Fachapplikation ist ein IT-System, das als Komponente in einer Verarbeitungstätigkeit genutzt wird. Die Spezifikation einer Verarbeitungstätigkeit MUSS von der Ebene der Sachbearbeitung ausgehend gestaltet werden, weil diese das Objekt der Rechtsgrundlage bildet, aus der sich alle Eigenschaften der verwendeten Daten, Systeme und Dienste sowie Prozesse ableiten (M41.S03).
Von der Sachbearbeitung ausgehend sind weitere arbeitsteilige Rollen zu definieren und Berechtigungen zu erteilen. Dabei sollten die folgenden Aspekte bzgl. der Sachbearbeitung beachtet werden:
- ausreichende Festlegung der Funktionalitäten der Fachapplikation,
- ausreichend gestaltete Anwendbarkeit der Fachapplikation mit einem nachvollziehbaren Nutzerinterface,
- ein Anwendungshandbuch, um die Funktionen zu verstehen und Fehlnutzungen zu vermeiden,
- vollständige Dokumentation der Fachapplikation seitens des Herstellers (Systemhandbuch),
- klare Anweisungen (Dienstanweisungen) zur Sachbearbeitung bzw. zur Nutzung der Fachapplikation sowie
- Überprüfbarkeit bei Fehlhandlungen der Sachbearbeitung.
Zum Schutz der von der Verarbeitung betroffenen Personen ist in einem genau abgegrenzten und festgelegten Rahmen eine dem Risiko angemessene, datenschutzrechtliche Kontrollmöglichkeit der Sachbearbeitung anhand von Protokollierungen vorzusehen, die jedoch nicht zweckentfremdend zur Leistungskontrolle genutzt werden dürfen. Speziell für die Auswertung der Protokolle SOLLTE deshalb ein separates Protokollierungskonzept vorgesehen und der Zugriff durch die Beteiligung verschiedener Rollenträger bspw. mittels des 4-Augen-Prinzip abgesichert sein (M41.S04).
Zur Spezifikation von Schutzvorkehrungen in der Fachapplikation empfiehlt es sich, folgende Fragen zu beantworten:
-
Wie kann sichergestellt werden, dass die Fachapplikation in der vorgesehenen Zeit und an den gewünschten Orten (Telearbeit?) verfügbar ist?
-
Wie lässt sich sicherstellen, dass die Richtigkeit der Daten und ggfs. der Verarbeitung geprüft werden können?
-
Wie kann sichergestellt werden, dass nur Befugte Zugriffe auf die Daten nehmen können?
-
Wie kann der Umfang der Datenerhebung und der weiteren Verarbeitung gestaltet werden, damit sichergestellt ist, dass mit den Daten und genutzten IT-Systemen nur zweckgemäß gearbeitet werden kann?
-
Wie kann sichergestellt werden, dass die Fachapplikation bei Bedarf geändert werden kann, um bspw. neue rechtliche und funktionale Anforderungen erfüllen zu können? Wie kann zugleich sichergestellt werden, dass keine nicht-autorisierten Änderungen durchgeführt werden können?
-
Wie lässt sich sicherstellen, dass die Rechtmäßigkeit der Verarbeitung und der Nachweis darüber jederzeit erbracht werden kann?
-
Wie lässt sich sicherstellen, dass Betroffene ihre gesetzlich garantierten Rechte wahrnehmen können?
Eine Fachapplikation muss in der Lage sein, Daten sicher zu speichern, zu verändern und zu löschen und ausgeführte Funktionalitäten im erforderlichen Umfang zu protokollieren.
Fachapplikationen setzten auf IT-Infrastrukturen auf, die ihrerseits zur Umsetzung von Datenschutz- und IT-Sicherheitsanforderungen sorgsam zu spezifizieren und auszuwählen sind. Zu dieser Infrastruktur zählt die Hardware sowie applikationsunabhängige Software.
Diese Systeme MÜSSEN im Hinblick auf Betrieb, funktionale Eigenschaften und technische und organisatorische Maßnahmen mit Blick auf die ablaufenden Verarbeitungstätigkeiten und den Nachweis der Wirksamkeit der für die Systeme getroffenen Maßnahmen spezifiziert werden (M41.S05).
Um beispielsweise ein Netzwerk zu planen, sind die folgenden Aspekte zu spezifizieren und in Form von Netzplänen zu dokumentieren:
- Festlegung der Topologie des Netzwerks,
- Festlegung der Hosts im Netzwerk,
- Festlegung der laufenden Services auf den Hosts,
- Konfiguration aller Services und Applikationen,
- Konfiguration aller Protokolle und Logs.
Schnittstellen für Datenflüsse zwischen Systemen mit unterschiedlichen Verantwortlichen sind grundsätzlich als Indikatoren für potenzielle Zweckänderungen zu betrachten, denen deshalb eine besondere rechtliche Aufmerksamkeit geschenkt werden muss.
Zu solchen Schnittstellen zählen Hardware-Schnittstellen (Laufwerke, USB, Monitor und Drucker), Software-Schnittstellen (Exportoptionen aus Programmen, APIs, Zugriffe auf Datenbanken) sowie insbesondere Netzwerk-Schnittstellen an Routern und Switches, an denen Datenabflüsse eingerichtet werden können. Besondere Aufmerksamkeit muss auch generalisierten Adaptern gelten wie beispielsweise einem ESB (Enterprise Service Bus) oder einer Clearingstelle bzw. einem Nachrichtenbroker, bei denen die Kommunikationen über einen gemeinsam genutzten Kommunikationsbus für eine Vielzahl von Punkt-Zu-Punkt- Verbindungen zwischen Anbietern und Nutzern von Softwarediensten geleitet werden (M41.S06).
Die folgenden Fragen MÜSSEN beantwortet werden: Wie wird sichergestellt,
- dass eine rechtlich korrekt eingerichtete Schnittstelle verfügbar ist und der Status geprüft werden kann,
- dass diese Schnittstelle nur von befugten Empfängern/Sendern genutzt wird,
- dass die Nutzung der Schnittstelle – oder auch eine zurückgewiesene Nutzung – transparent (beantragt, rechtlich reguliert, dokumentiert, protokolliert) erfolgt,
- dass die technischen Übertragungswege (bspw. E-Mail, Webservices, postalisch angemessen sind und abgesichert werden;
- dass die Fließrichtung und die Kategorien der zu übertragenden Datenfelder definiert und mit dem Empfänger abgestimmt sind,
- dass eine Schnittstelle geschlossen werden kann und
- dass Änderungen in Formaten, Protokollen oder Aufrufformen, die sich auf die Nutzung der Schnittstelle auswirken, von der Schnittstelle auch berücksichtigt werden?
Der Administration muss insofern besondere Beachtung geschenkt werden, weil ein Administrator mit weitreichenden Befugnissen ausgestattet sein muss, um die technischen Eigenschaften zu implementieren und zu konfigurieren. Ein Administrator ist rechtlich jedoch grundsätzlich nicht befugt, auf die Inhaltsdaten der Sachbearbeitungsebene zuzugreifen.
Vielfach lässt sich ein Zugriff durch Administratoren, insbesondere zur Behebung von Funktionsstörungen oder Systemänderungen, aber nicht vollständig vermeiden. Weil beiden Anforderungen zugleich gerecht zu werden grundsätzlich schwierig ist, ist auf eine sorgfältige Spezifikation kleinteiliger Administrationsrollen und Berechtigungen sowie der Dokumentation der Administrationstätigkeiten und des revisionsfesten Nachweises darüber insbesondere durch Protokollierung zu achten (M41.P19).
Eine Spezifikation der Administrationsaktivitäten und deren Überwachung sind in einem nochmals gesteigerten Maße notwendig, wenn die Fachadministration nicht durch organisationseigenes Personal geschieht, sondern bspw. eine Fernwartung durch Dritte durchgeführt wird. Dies gilt in einem nochmals gesteigerten Maße, wenn ein Fachverfahren im Rahmen einer Auftragsverarbeitung bspw. in einem Rechenzentrum betrieben und administriert wird und die Durchsetzung der fachlichen Weisungen an Administrationen und die Kontrolle dieser Umsetzung unmittelbar nicht möglich sind (M41.P20).
In einem genau abgegrenzten und festgelegten Rahmen MUSS eine datenschutzrechtliche Kontrolle einer Administration zum Schutz der von der Sachbearbeitung verarbeiteten Daten Betroffener anhand von fachlichen Protokollierungen erfolgen, die jedoch nicht zur Leistungskontrolle genutzt werden dürfen (M41.P21).
Folgende Fragen MÜSSEN in Bezug auf Administratoren in einer Planungsphase beantwortet werden: Wie ist sichergestellt, dass
- Administratoren ausreichend verfügbar sind (Service Level etc.)?
- nur solche Administratoren eingesetzt werden, die fachlich ausgebildet sind und kompetent agieren? Das betrifft auch den Vertretungsfall.
- nur vertrauenswürdige und befugte Administratoren tätig werden, die nachweisbar
- auf Wahrung der Vertraulichkeit verpflichtet wurden?
- sämtliche relevante Administrationstätigkeiten vollständig und integer protokolliert und in angemessener Weise durch Vorgesetzte nachweislich überprüft werden?
- Administratoren keinen Rollenkonflikten unterliegen bzw. arbeitsteilig agieren und
- Administratoren an Änderungen von Verarbeitungstätigkeiten angemessen beteiligt sind?
Die in Kapitel 2.2 ausgeführten Schritte sind Voraussetzung, um die Anforderungen aus Art. 35 DS-GVO zu erfüllen.
Drei Aspekte sind für eine Vorprüfung einer DSFA zu beachten:
- die Durchführung der DSFA-Schwellwertanalyse und die anschließende Entscheidung darüber, ob eine DSFA durchzuführen ist,
- die Entscheidung darüber, wer die DSFA durchführt sowie
- die Entscheidung darüber, wie die DSFA systematisch durchgeführt werden soll.
Der Verantwortliche MUSS für jede Verarbeitungstätigkeit eine DSFA-Schwellwertanalyse durchführen und dokumentieren (M41.P01).
Der Verantwortliche MUSS in einem DSFA-Bericht die Risiken für die geplante Verarbeitungstätigkeit ausweisen und geeignete Schutzmaßnahmen festlegen (M41.P22). Die Anforderungen des Artikel 35 DS-GVO umfassen darüber hinaus die Phase der wirksamen Implementation von technischen und organisatorischen Maßnahmen inklusive der Maßnahmen zum Nachweis über die Wirksamkeit der Schutzmaßnahmen.
Insbesondere bei komplexen Verarbeitungstätigkeiten SOLLTE der Verantwortliche eine Prozessmodellierung der gesamten Verarbeitungsvorgänge vornehmen, bspw. mit den Mitteln der Geschäftsprozessmodellierung (BPM, Business Process Modeling). Eine von den Beteiligten gepflegte, vollständige und aktuelle Prozessmodellierung trägt dazu bei, dass Subprozesse und Änderungen für die Beteiligten sichtbar sind und immer wieder der Zweck der Verarbeitungstätigkeit, die zu treffenden Schutzmaßnahmen inkl. der Überwachung anhand der Entwürfe zur praktischen Umsetzung geprüft werden können (M41.P23).
Der Verantwortliche selbst ist für die Durchführung einer DSFA verantwortlich, nicht der oder die Datenschutzbeauftragte (DSB). Der Verantwortliche SOLLTE jedoch den Rat der oder des DSB einholen (Art. 35 Abs. 2, Art. 39 Abs. 1 lit. c DS-GVO). Die Zuständigkeit bzw. Funktion des oder der DSB besteht darin, die Durchführung der DSFA zu überwachen.
<Eine DSFA SOLLTE als ein konventionelles Projekt aufgesetzt und durchgeführt werden. Ein Projektmanager MUSS dann mit der Durchführung beauftragt und mit Ressourcen (Personal/Expertise, Zeit, Werkzeuge, Budget, Methode) ausgestattet werden.
Verantwortliche können sowohl organisationsinterne Stellen als auch Externe beauftragen, eine DSFA zu erstellen. Erfolgt die Beauftragung extern, MUSS ein fachlich geeigneter Ansprechpartner beim Verantwortlichen benannt werden. Für die Erstellung der DSFA MÜSSEN Ressourcen bereitgestellt werden. Die für die Erstellung der DSFA Benannten MÜSSEN dann auch die Rolle eines Projektleiters einnehmen können, aus der sich gegenüber der Linienorganisation spezifisch-erweiterte Weisungs-Befugnisse an Mitglieder der DSFA- Projektgruppe ergeben können. In der Praxis finden sich zunehmend Konstellationen bspw. durch gemeinsame Verantwortung gem. Art. 26 DS-GVO, in denen die Datenschutzbeauftragten zweier Organisationen wechselseitig als DSFA-Projektmanager in der jeweils anderen Organisation agieren können (M41.P24).
Generell zeigt sich, dass zur Durchsetzung von operativen Datenschutz-Anforderungen, analog zur Durchsetzung von Anforderungen der IT-Sicherheit, die Einrichtung einer administrativ wirksamen Organisationseinheit notwendig ist, die wesentlicher Bestandteil eines Datenschutzmanagement-Systems (DSMS) ist. Im Rahmen einer Datenschutz- Organisationseinheit werden dann differenzierte Rollen ausgebildet und besetzt, so die von Datenschutz-Koordinatoren, die auf Weisung des Leiters der Organisationseinheit Schutzmaßnahmen durchsetzen oder kontrollieren, sowie DSFA-Projektmanager und DSFA-Teammitglieder.
Die in Kapitel 2.2. aufgelisteten und dort bereits näher beschriebenen Schritte SOLLTEN idealtypisch methodisch-systematisch in den folgenden Phasen erfolgen, um den gehobenen Anforderungen an die Spezifikation insbesondere Schutzmaßnahmen durch eine DSFA auch durch professionelle Durchführung der Analyse der Datenschutzrisiken für Betroffene zu genügen:
- Vorbereitung / Planung der DSFA für eine Verarbeitungstätigkeit;
- Durchführung der DSFA, Ergebnis: DSFA-Bericht;
- technische und rechtliche Machbarkeitsprüfung der geplanten/spezifizierten Implementation gemäß des DSFA-Berichts;
- Priorisierungsentscheidungen des Verantwortlichen;
- Änderungen der Pläne / Spezifikation, Durchführung von Funktionstest,
- Fortschreibung der DSFA; Implementation der Verarbeitung und der Schutzmaßnahmen, inkl. Umsetzung der Dokumentations- und Protokollierungsanforderungen; Durchführung von Funktionstests und Test der organisatorischen Maßnahmen
- Nachweis der Wirksamkeit der Schutzmaßnahmen gemäß Dokumentation und Protokollierung, nochmalige Prüfung der Rechtsgrundlagen oder externe Auditierung;
- Freigabe der Verarbeitung (oder einer erneuerten IT-Struktur) durch Verantwortlichen.
Diese Folge von Phasen entsprechen einem zweimaligen Durchlaufen des Plan-Do-Check- Act-Zyklus, der charakteristisch für ein Datenschutzmanagementsystem ist (vgl. SDM-V2b, S. 47f).
| 1 Vorbereitung DSFA | 2 Durchführung DSFA | 3. Umsetzung DSFA | 4. Überprüfung DSFA |
|---|---|---|---|
| 1.1 Zusammenstellung des DSFA-Teams | 2.1 Modellierung der Risikoquellen | 3.1 Umsetzung der Abhilfemaßnahmen | 4.1 Ggfs. Überprüfung und Audit der DSFA |
| 1.2 Prüfplanung | 2.2 Risikobeurteilung | 3.2 Test der Abhilfemaßnahmen | 4.2 Fortschreibung |
| 1.3 Festlegen des Beurteilungsumfangs (Scope) | 2.3 Auswahl geeigneter Schutzmaßnahmen | 3.3 Dokumentation: Nachweis über die Einhaltung der DSGVO | |
| 1.4 Identifikation und Einbindung von Akteuren undbetroffenen Personen | 2.4 Erstellung des DSFA-Berichts | 3.4 Freigabe der Verarbeitungsvorgänge | |
| 1.5 Bewertung der Notwendigkeit/Verhältnismäßigkeit in Bezug auf den Zweck | |||
| 1.6 Identifikation der Rechtsgrundlagen |
Tabelle 1: Idealtypisch eingerichtete Phasen der Durchführung einer DSFA aus dem "Kurzpapier 5" der DSK 2018a.
Hat eine Form der Verarbeitung, insbesondere bei Verwendung neuer Technologien, aufgrund der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge, so führt der Verantwortliche vorab eine Abschätzung der Folgen der vorgesehenen Verarbeitungsvorgänge für den Schutz personenbezogener Daten durch (Art. 35 Abs.1 DS-GVO).
Dabei sind an die Durchführung einer DSFA Anforderungen hinsichtlich der Qualität und Detailtiefe zu stellen, die insbesondere den mit dem untersuchten Verarbeitungsvorgang verbundenen Risiken für die Rechte und Freiheiten natürlicher Personen gerecht werden. Die DSFA MUSS vorab, also vor Beginn der Verarbeitung personenbezogener Daten, durchgeführt werden. Bei „Altverfahren“ MÜSSEN die durch die DSGVO neu hinzugekommenen Aspekte gemäß Art. 35 gegenüber den Berichten zu einer Vorabkontrolle aufgegriffen und bearbeitet werden. Die Integrität und Vertrauenswürdigkeit der Analysen und Empfehlungen ist durch ein systematisches Vorgehen im Kontext einer erprobten Methodik unter Beteiligung von Experten sicherzustellen. Es ist die Transparenz der Herbeiführung von Entscheidungen der DSFA-Projektgruppe zu belegen. Ganz wesentlich ist dabei, dass sich der Zweck der Durchführung der DSFA immer an der Sicherung der Rechte und Freiheiten Betroffener ausrichtet. Und es sollte eine Flexibilität für berechtigte Einwände bestehen (M41.P25).
DSK 2018a:
Kurzpapier Nr. 5: „Datenschutz-Folgenabschätzung nach Art. 35 DS-GVO“ https://www.datenschutzkonferenz-online.de/media/kp/dsk_kpnr_5.pdf
DSK 2018b:
Kurzpapier Nr. 18: „Risiko für die Rechte und Freiheiten natürlicher Personen“ https://www.datenschutzkonferenz-online.de/media/kp/dsk_kpnr_18.pdf
DSK 2018c:
„Liste der Verarbeitungen, für die eine DSFA durchzuführen ist“, V1.1 vom 18.07.2018, https://www.lda.bayern.de/media/dsfa_muss_liste_dsk_de.pdf
| Nr. | Maßnahme | P, D, C, A1 | Gültigkeit |
|---|---|---|---|
| M41.D01 | Spezifikation der Daten, die von der Verarbeitungstätigkeit verarbeitet werden | P | V1.0 |
| Nr. | Maßnahme | P, D, C, A1 | Gültigkeit |
|---|---|---|---|
| M41.S01 | Aufträge aus der Spezifikation sollten in Form eines Lasten und Pflichtenheft erfolgen | P | V1.0 |
| M41.S02 | Allgemein verständliches Erfassen und Benennen der Daten, IT-Systeme und Dienste sowie der Prozesse | P | V1.0 |
| M41.S03 | Spezifikation der Fachapplikation | P | V1.0 |
| M41.S04 | Spezifikation eines Protokollierungskonzepts | P | V1.0 |
| M41.S05 | Spezifikation der IT-Infrastruktur und IT-Systeme in Bezug auf Erfüllung des Zwecks und der technischen und organisatorischen Maßnahmen | P | V1.0 |
| M41.S06 | Spezifikation der Schnittstellen der Systeme | P | V1.0 |
| Nr. | Maßnahme | P, D, C, A1 | Gültigkeit |
|---|---|---|---|
| M41.P01 | Durchführen einer Risikoanalyse, die der Durchführung einer DSFA vorausgeht („Schwellwertanalyse“) | P | V1.0 |
| M41.P03 | Festlegen der Spezifikationstiefe, mit ihren jeweiligen Daten, Systemen und Diensten sowie Prozessen | P | V1.0 |
| M41.P04 | Rechtliche Beurteilung einer Spezifikation während der Planungsphase | P | V1.0 |
| M41.P05 | Herstellung einer hinreichend ausführlichen Beschreibung der Verarbeitungstätigkeit einschl. der dabei zu verwendenden Daten, Systeme und Dienste sowie Prozesse | P | V1.0 |
| M41.P06 | Identifikation der an der Bearbeitung beteiligten Akteure und Betroffenen | P | V1.0 |
| M41.P07 | Identifikation der Rechtsgrundlagen bzw. der noch beizubringenden Rechtsgrundlagen | P | V1.0 |
| M41.P08 | Bildung von Einsatzszenarien bzw. Usecases einschl. eines daraus abgeleiteten datenschutzrechtlich relevanten Angreifermodells | P | V1.0 |
| M41.P09 | Festlegung der Strukturen der Spezifikation, Dokumentation, Protokollierung | P | V1.0 |
| M41.P10 | Anhand der Gewährleistungsziele und der Risikostufe die notwendigen technischen und organisatorischen Maßnahmen für die geplanten Einsatzszenarien erkennen, bestimmen und dimensionieren | P | 1.0 |
| M41.P11 | Erarbeitung eines Migrationskonzepts für Übernahme von Altdaten | P | V1.0 |
| M41.P12 | Erstellung eines Berichts zur Spezifikation einer Verarbeitungstätigkeit vor Entscheidungen des Verantwortlichen zur Implementation empfohlener Maßnahmen | P | V1.0 |
| M41.P13 | Erstellung eines Konzepts zur Umsetzung der Empfehlungen aus der Spezifikationsphase oder aus einem DSFA-Bericht | P | V1.0 |
| M41.P14 | Erstellung eines Konzepts zur Durchführung von Test der implementierten Maßnahmen | P | V1.0 |
| M41.P15 | Erstellung eines Konzepts für eine Pilotphase | P | V1.0 |
| M41.P16 | Festlegung der Übergabe von Projekt- und Betriebsmodus unter Sicherstellung der Überwachung des Betriebs durch das DS-Management durch den Verantwortlichen | P | V1.0 |
| M41.P17 | Festlegung der zu spezifizierenden Ebenen der Verarbeitungstätigkeit | P | V1.0 |
| M41.P18 | Spezifikation der fachlichen Prozessabläufe, zunächst unter allgemeiner Beschreibung der verwendeten IT- Komponenten | P | V1.0 |
| M41.P19 | Spezifikation der Aktivitäten der lokalen Administration von Programmen und Systemen | P | V1.0 |
| M41.P20 | Spezifikation der Aktivitäten Administration von Programmen und Systemen bei Nutzung einer AV | P | V1.0 |
| M41.P21 | Spezifikation der Überwachung der Aktivitäten der Administration durch Protokolle | P | V1.0 |
| M41.P22 | Erstellen des DSFA-Berichts | P | V1.0 |
| M41.P23 | Nutzung einer Prozessmodellierungsmethode | P | V1.0 |
| M41.P24 | Spezifikation der Durchführung einer DSFA (Projektmanager, Methode) | P | V1.0 |
Dieser Baustein bezieht sich auf die Tätigkeit der Spezifikation innerhalb der Phase Plan im Datenschutzmanagement-Lebenszyklus und bildet die entsprechenden Pflichten des Verantwortlichen ab, welche auf eine einzelne Verarbeitungstätigkeit aber auch die gesamte Organisation angewendet werden können. Wird der Baustein auf die die gesamte Organisation angewendet, sind die getroffenen Maßnahmen im Datenschutzmanagement der Organisation zu betrachten.
Dieser Baustein darf – ohne Rückfrage bei einer Aufsichtsbehörde – kommerziell und nicht kommerziell genutzt, insbesondere vervielfältigt, ausgedruckt, präsentiert, verändert, bearbeitet sowie an Dritte übermittelt oder auch mit eigenen Daten und Daten Anderer zusammengeführt und zu selbständigen neuen Datensätzen verbunden werden, wenn der folgende Quellenvermerk angebracht wird:
Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (Datenschutzkonferenz). Veränderungen, Bearbeitungen, neue Gestaltungen oder sonstige Abwandlungen der bereitgestellten Daten sind mit einem Veränderungshinweis im Quellenvermerk zu versehen. Datenlizenz Deutschland – Namensnennung – Baustein „Planen und Spezifizieren“ (www.govdata.de/dl-de/by-2-0).