Erfahren Sie anhand von Praxisbeispielen, was sich hinter dem Ansatz "Privacy by Design" verbirgt und wie dieser im Unternehmen optimal umgesetzt werden kann. [...]
Datenschutz-Anforderungen umzusetzen ist eine ganzheitliche betriebliche Aufgabe. Sie betrifft alle Unternehmensbereiche und -prozesse, in denen personenbezogene Daten verarbeitet werden. Hier müssen Beteiligte kontinuierlich geprüfte Verfahren bereitstellen, um einen datenschutzkonformen und transparenten Umgang mit personenbezogenen Daten zu gewährleisten. Demzufolge stellt sich IT-Führungskräften die Frage, was sie priorisieren müssen, um diese Aufgabe nachhaltig zu lösen.
„Privacy by Design“ und die DSGVO
(Die folgenden Abschnitte zeigen auf, wie neu erhobene und bestehende Personendaten behandelt werden müssen, damit sich Unternehmen souverän und konform im Spannungsfeld zwischen Business-Aktivität, IT-Sicherheit und Datenschutz in der IT bewegen.) Schon während des Designs einer Software- oder Datenbanklösung gilt es Faktoren zu beachten, die auf das Datenschutzthema ausstrahlen. Mit folgender „Privacy by Design“-Checkliste halten Entwickler und Administratoren den (Mehr-)Aufwand bei der Implementierung DSGVO-relevanter Punkte überschaubar:
Klare Trennung von Datentypen
Für datenschutzkonforme System-Entwicklungen ist es notwendig, Daten redundant zu speichern und sie mindestens in diese Kategorien aufzuteilen:
- Informationsdaten;
- widerrufliche Einwilligungsdaten;
- Archivierungsdaten.
Bei Informationsdaten handelt es sich um Informationen zu einer Person, die nicht der gesetzlichen Archivierungspflicht unterliegen. Sie müssen umgehend nach Erfüllung des Erhebungszwecks gelöscht werden. Dazu gehören beispielsweise Kreditkartendaten – diese sind nach dem Bezahlvorgang zu löschen.
Widerrufliche Einwilligungsdaten, oder Opt-in-Daten, sind Informationen, die bis zum Widerruf zu einem bestimmten Zweck vorgehalten werden, um einen wiederkehrenden Wunsch umsetzen zu können. Beispiele hierfür sind die E-Mail-Adresse für den Newsletter oder der Geburtstag für jährliche Glückwünsche. Für werbliche Maßnahmen wie einen Newsletter-Versand dürfen Unternehmen ausschließlich Daten verwenden, für die deren Eigentümer die explizite, temporäre und widerrufliche Zustimmung abgegeben haben (Opt-in). Sobald Datenschutzbehörden nachweisen können, dass eine Kontaktaufnahme zu Personen erfolgt ist, die nicht explizit über Opt-in zugestimmt haben, können sie Unternehmen mit erheblichen Geldstrafen belegen. Wichtig ist zudem, den Dateneigentümern relevante Informationen transparent zur Verfügung zu stellen. Diese müssen unkompliziert überblicken können, wie ihre Daten verwendet werden und wie sie die einmal erteilte Zustimmung jederzeit widerrufen können. Unternehmen sollten darauf achten, Antworten und Aktionen sorgfältig für Audits zu dokumentieren. Empfehlenswert ist zudem, einen Datenbank-Bereich für Textbausteine zu designen, wie etwa Einwilligungsvorlagen oder juristische Texte.
Archivierungsdaten stellen eine Sammlung an Informationen dar, die benötigt werden, um Vorgänge nachvollziehen zu können, beispielsweise für die gesetzlichen Aufhebungsfristen im medizinischen Bereich oder in der Buchhaltung. Das sind unter anderem Rechnungsdaten zum Kauf von Produkten und Dienstleistungen. Erst nach Ablauf der gesetzlichen Aufbewahrungspflicht dürfen diese Archivierungsdaten gelöscht werden – ein Löschvorgang, der mit Inkrafttreten der DSGVO bindend ist. Diese Daten dürfen von den Unternehmen nicht mehr verarbeitet werden.
„Privacy by Default“: Beispiel Berücksichtigung von Archivierungspflichten
Im Design neuer Software- und Datenbankentwicklungen sollte für nahezu jedes Datenfeld eine Tabelle mit den dazugehörenden gesetzlichen Archivierungspflichten hinterlegt sein. Beispiele für solche Datenfelder sind etwa Rechnungsnummer, Rechnungsdatum und der Netto-Betrag. Mitarbeiter müssen Belege entsprechend der Abgabeverordnung (AO) nach Steuerrecht zehn Jahre archivieren, Belege gemäß Handelsgesetzbuch (HGB) sechs Jahre.
Wesentlich für Neuprojekte sind jedoch branchenbezogene Spezifika bezüglich Archivierungsauflagen. So müssen Unternehmen bei der Verarbeitung von Daten wie einer Arztrechnung eine Frist von bis zu 30 Jahren berücksichtigen, beispielsweise in Verbindung mit Patientendaten nach Strahlenschutz- beziehungsweise Röntgenverordnung, Gleiches gilt auch für auch für Aufzeichnungen nach dem Transfusionsgesetz. Gelten für personenbezogene Daten mehrere und dabei divergierende Auflagen zur Archivierung, so empfiehlt es sich, nicht nur die maximale Archivierungszeit, sondern alle Fristen anzulegen.
Auch sollten Verantwortliche rollenbasierend den Terminus „Ansichtsfristen“ pro Feld hinterlegen. Was bedeutet dies? Archivierungsdaten für Rechnungen sind nur fünf Jahre für die „Rolle A“ einsehbar, für die „Rolle B“ in der ganzen Laufzeit. Bei besonders schützenswerten Informationen wie Gesundheitsdaten ist ein Einblick für Administratoren ohne Betriebsrat und / oder Datenschutzbeauftragte zu unterbinden. Eine auf dem Datenfeld basierende Verschlüsselung, die für bestimmte Informationen das Verfallsdatum bereits einbaut, eignet sich hierfür am besten.
Datenschutz für bestehende Systeme
Was passiert mit Datenbanken, deren Datenspeicher zum Bersten gefüllt sind, während niemand weiß, welche personenbezogenen Daten darin lagern? Bei vielen Anwendungen existiert keine Transparenz darüber, wo diese Daten liegen und wer im Unternehmen für die allgemeine Speicherung verantwortlich zeichnet. In dieser Situation befinden sich aktuell viele Firmen, Behörden und Institutionen. Berücksichtigen IT-Beauftragte Datenschutz und Entwicklungseffizienz, dann ist es unmöglich, auf diese Situation aufzubauen, neue Daten unter DSGVO-Gesichtspunkten zu behandeln und den bestehenden Datenpool zu ignorieren.
Es gilt also, alle personenbezogenen Daten im Unternehmen zu identifizieren und sie zuzuordnen. Diese umfangreichen und komplizierten Prozesse stellen oft eine der größten Herausforderungen auf dem Weg zur Datenschutzkonformität dar. Nicht erkannte, frei flottierende und unsachgemäß gespeicherte Datenbestände bergen jedoch ein hohes Risiko für Sicherheitsverletzungen und können eine Haftung nach DSGVO nach sich ziehen. Konzentrierte Anstrengungen, diese nicht verwendeten Daten zu finden und zu löschen, reduzieren die Strafen im Ernstfall erheblich.
Datenlöschung als Datenschutzmodul
Was müssen Entwickler und Leiter in Fachabteilungen über brauchbare Lösungen wissen? Sie benötigen zum Start eine Beschreibung des Löschprozesses personenbezogener Daten in den operativen und dispositiven Systemen des Unternehmens. Bei der Entwicklung und dem Einsatz von Software muss eine datenschutzkonforme Löschung dieser Daten oberste Priorität haben.
Derzeit gibt es nahezu keine Standardsoftware, mit der Nutzer konform Daten löschen. Diesen Punkt sahen Anwendungsentwickler in der Konzeption von Software früher meist nicht vor. Um den Anforderungen der DSGVO gerecht zu werden, müssen sie nun nachträglich flächendeckend Softwareänderungen durchführen.
Um eine aufwendige und fehleranfällige manuelle Löschung zu vermeiden, bietet sich die Entwicklung automatischer Löschroutinen an. Auch wenn Übersichten personenbezogener Daten erstellt werden, sollten Entwickler Prozesse softwareseitig unterstützen, um die enormen Aufwände und Fehleranfälligkeit einer manuellen Auswertung zu vermeiden.
„Privacy by Default“: Mindestprüfungen und Pseudonymisierung
Bei bestehenden IT-Systemen müssen Entwickler etablierte Prozesse wie Audits und Penetrations-Tests adaptieren. Solche Projekte sind teilweise mit großen Herausforderungen verbunden. Es gibt hierbei jedoch Mindestanforderungen, um bestehende Systeme zu überprüfen.
Unter der Voraussetzung, dass mindestens drei Umgebungen (Dev=Entwicklung, Test und Prod=Produktion) vorhanden sind, sollten Administratoren, Entwickler und IT-Sicherheitsmitarbeiter idealerweise folgende Schritte automatisiert vornehmen:
- Schwachstellenanalyse (Vulnerability Scans)
- Schadsoftware-Überprüfungen (Malware Scans)
- Compliance Scans sowie Härtungen, bei denen IT-Komponenten auf Sicherheitsaspekte hin verändert werden
- Historisierung der Codes innerhalb der Software-Entwicklung (idealerweise bei jedem Commit), Einführung eines Versionskontrollsystems (beispielweise mit GIT)
Diese Mindestprüfungen gilt es auszuführen und die Ergebnisse in der Deployment-Pipeline lückenlos zu dokumentieren. Ein praxisnahes Konzept zeigt auf, wie IT-Beauftragte anfallende Daten verarbeiten und worauf sie gesondert achten müssen:
Zu Beginn erfassen Projektverantwortliche alle anfallenden Daten und klassifizieren sie. Im Klassifizierungsprozess spielt auch eine Rolle, dass neben der DSGVO noch weitere Gesetze, Regularien und Behördenauflagen existieren, die berücksichtigt werden müssen. Dazu zählen die Abgabenordnung (AO) als elementares Gesetz des deutschen Steuerrechts, das IT-Sicherheitsgesetz (IT-SiG, weithin unter KRITIS bekannt) und diverse eHealth-Gesetze wie die EU-Verordnungen zu Medizinprodukten und In-vitro-Diagnostika.
Diese Verordnungen widersprechen sich zum Teil und erfordern eine permanente und gründliche Prüfung aller Parameter, die für die eigenen Daten greifen. Festhalten lässt sich, dass bei unterschiedlichen Zeiträumen zur Datenspeicherung und Archivierung immer der längste zählt.
Als Nächstes sollten Projektverantwortliche prüfen, wie personenbezogene Daten, die sich auf Geschäftsaktivitäten beziehen, in datenschutzkonformem Umfang gesammelt werden können und / oder wie eine Pseudonymisierung der Daten gelingt. Diese Pseudonymisierung ist gemäß Artikel 4 DSGVO definiert als die „Verarbeitung personenbezogener Daten in einer Weise, dass diese ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden“.
Prinzipientreu und klar definiert
Die aufgeführten Maßnahmen und Schritte verfolgen das gemeinsame Ziel, „Privacy by Design“ bzw. „Privacy by Default“ gemäß Artikel 25 DSGVO so umzusetzen, wie es die europäischen Datenschutzbehörden fordern.
Die kanadische Datenschutzbeauftragte Ann Cavoukian, hatte schon in den 1990er Jahren sieben Prinzipien für Privacy by Design postuliert (PDF):
- Proaktiv statt reaktiv vorgehen, Vorbeugen statt Reparieren.
- Datenschutz gilt als Standardeinstellung.
- Datenschutz ist in den Entwicklungsprozess eingebettet.
- Volle Funktionalität sollte erreicht werden, Datenschutz und Sicherheit gilt es gemeinsam und nicht als Gegensätze zu betrachten.
- Sicherheit muss durchgängig und entlang des gesamten Lebenszyklus implementiert sein.
- Sichtbarkeit und Transparenz müssen gewährleistet sein, Offenheit ist ein zentraler Faktor.
- Der Fokus liegt auf den Nutzer und Respekt für dessen Privatsphäre.
Datenschutzbeauftragte, Entwickler und Administratoren agieren nach diesen Prinzipien, sobald sie Datenschutz als Standardeinstellung vornehmen. Dies meint eine datenschutzpriorisierende Voreinstellung in einer Anwendung, bei dem der Nutzer beispielsweise bei Software-Fehlern selbst via Klick entscheidet, ob sein Nutzungsverhalten an den Softwaresupport übermittelt wird.
Wenden die Verantwortlichen die oben skizzierten Maßnahmen wie Datentypen-Trennung, Datenminimierung und Datenlöschung an, so haben sie Datenschutz eingebettet. Sie können durch den Aufbau zeitnah Auskünfte erteilen und Daten auf gesetzeskonforme Art löschen. Dank dieser datenschutzkonformen Voreinstellungen, also „Privacy by Default“, agieren alle Beteiligten und betrachten Datenschutz als vorbeugende Maßnahme, nicht als Abhilfe.
Der Fokus liegt dabei auf dem Schutz des Anwenders. Ein Beispiel: Wenn in einem Support-Fall für Smartphones alle Daten wie Standortdaten, Geräte- und Kommunikationsdaten des Nutzers vorliegen, benötigt der Support-Mitarbeiter jedoch höchstwahrscheinlich nur die Telefonnummer, um dem Kunden zu helfen. Es ergibt also keinen Sinn aus Sicht dieser Maxime, alle verfügbaren Informationen bis hin zu Lokalisierungs-Daten (GPS) zu übermitteln. Wenn diese nutzerzentrierte Gestaltung bei der Entwicklung von Software-Produkten mitgedacht wird, gelingt die geforderte Wahrung der Privatsphäre.
Wesentlich bei allen Prozessen sind die Prinzipien der Sichtbarkeit und Transparenz. Entscheidet sich beispielsweise ein Kunde dafür, sich für einen Newsletter anzumelden, schaffen die freiwillige Zustimmung über ein Opt-in-Verfahren sowie ein offensichtlich aufgeführtes Widerrufsrecht Vertrauen durch Offenheit.
Auf Administratorenseite muss gewährleistet sein, dass nur Berechtigte zweckgebundenen Zugriff auf personenbezogene Daten erhalten. Dabei ist zwischen Lese- und Bearbeitungszugriff zu unterscheiden. Die damit erreichte durchgängige Sicherheit bietet Schutz während des gesamten Lebenszyklus der gespeicherten Daten bis hin zu ihrer Löschung. Als Maßnahmen dienen maßgeblich, aber nicht nur ein Rollen- und Rechtekonzept sowie die konsequente Verschlüsselung der Daten nach aktuellen Kryptografie-Standards, wobei die Maximal-Ausprägung die richtige Wahl ist.
Das gewünschte Ergebnis ist die volle Funktionalität von „Privacy by Design“. Hierbei sollten parallel alle Interessen und Ziele von IT-Seite einerseits und Nutzerseite andererseits zu einem Ansatz verschmelzen, der aufgrund seiner klaren Struktur und Eindeutigkeit auf Kompromisse verzichten kann.
Eine exakte Bestandsaufnahme aller datenverarbeitenden Prozesse und ihrer IT-Systeme im Unternehmen bildet die Basis aller „Privacy by Design“- und „Privacy by Default“-Maßnahmen. Darauf bauen Überlegungen zu Datenschutz-Projekten, zu ihrem Umfang, dem personellen Einsatz und den eingesetzten Methoden auf.
*Pierre Gronau ist seit über 25 Jahren für namhafte Unternehmen als Senior IT-Berater mit umfangreicher Projekterfahrung tätig. Zu seinen Kompetenzfeldern gehören Server-Virtualisierungen, IT-Sicherheit, moderne Cloud- und Automationslösungen sowie Informationsschutz in kritischen Infrastrukturen.
Be the first to comment