Am 25.10.2022 wurde die neue neue Version der ISO/IEC 27001:2022 in Englisch veröffentlicht. Ich möchte hier einen kurzen Überblick über die wesentlichsten Änderungen und deren Auswirkungen geben. (HINWEIS: Die Übersetzung ist von mir. Der Wortlaut der offiziellen Übersetzung wird sicher ein anderer sein.)

Anhang A: Die prominenteste Änderung ist sicher die Anpassung des Anhang A an die neue Version der ISO/IEC 27002:2022. Da diese Änderungen sehr umfangreich sind und auch von anderen Autoren zur Genüge beleuchtet wurden, will ich darauf nicht ausführlich eingehen.

Kontext der Organisation (4.2): Die neue Version lässt hier Spielraum in Bezug auf die Bewertung der Relevanz der Anforderungen interessierter Parteien und fügt explizit einen Punkt 4.2.c ein: “welche dieser Anforderungen durch das ISMS adressiert werden.” Es sollten also die relevanten Anforderungen identifiziert werden und dann muss ermittelt werden, welche dieser Anforderungen tatsächlich in das ISMS einfließen. Auch wenn hier keine explizite Dokumentationsanforderung formuliert ist, empfehle ich diese Aussagen zu dokumentieren und auch festzuhalten, welche Begründung zur Auswahl der Anforderungen geführt hat.

Ziele und Zielerreichung 6.2: Informationssicherheitsziele müssen jetzt “überwacht” (6.2.d be monitored) werden und die Ziele müssen als dokumentierte Information vorliegen (6.2.g).

Planung von Veränderungen 6.3: Dieser Punkt ist neu. Wenn die Organisation den Bedarf feststellt, das ISMS anzupassen, dann müssen diese Änderungen entsprechend gesteuert werden (“the changes shall be carried out in a planned manner.”)

Kommunikation 7.4: Endlich. Punkt e) “(einschließlich) der Prozesse, mit welchen die Kommunikation bewerkstelligt wird.” ist weggefallen. Hand aufs Herz, es wusste sowieso niemand so wirklich, was damit gemeint war.

Betriebliche Planung und Steuerung 8.1: Der Absatz wurde deutlich weiter gefasst. Wo sich der alte Absatz noch explizit auf 6.1 bezog, wird jetzt in der Planung der gesamte Normpunkt 6 erfasst. Auch müssen sich die Prozess nicht mehr nur auf die Erfüllung der Informationssicherheitsanforderungen beziehen, sondern allgemein auf Anforderungen. Das können dann z.B. auch kaufmännische oder operative Anforderungen sein. Zusätzlich wurde eine stärkere Prozessorientierung aufgenommen, heißt es doch, dass zur Erfüllung der Anforderung

• Prozesskriterien und;
• Prozesssteuerung im Einklang mit diesen Kritierien

etabliert werden muss.

Außerdem müssen nicht mehr nur ausgegliederte Prozesse, sondern auch Produkte und Dienstleistungen die relevant für das ISMS sind, gesteuert werden.

Internes Audit 9.2: Das Kapitel wurde leicht umstrukturiert. Die allgemeinen Anforderungen sind jetzt in 9.2.1 zu finden, das interne Auditprogramm (heißt jetzt tatsächlich als Kapitel so) hat ein eigenes Kapitel 9.2.2 bekommen. Inhaltliche Änderungen sind mir keine aufgefallen.

Managementbewertung 9.3: Auch das Kapitel ist jetzt in Unterkapitel aufgeteilt.

• Die alte Einleitung ist wortgleich zum Kapitel 9.3.1 geworden.
• Die Inhalte der Managementbewertung sind in Kapitel 9.3.2 “Management review inputs” aufgeführt und ergänzt worden um einen neuen Punkt c, sinngemäß “Änderungen der Bedürfnisse und Erwartungen interessierter Parteien, die relevant für das ISMS sind”. Hier kann ich mir durchaus vorstellen, dass z.B. gesetzliche Anforderungen denen interessierte Parteien unterworfen sind, o.ä. aufzuführen sind.

Verbesserung 10: Der Inhalt hat sich nicht geändert, aber die beiden Unterkapitel sind vertauscht worden.

Auch wenn einige der Änderungen auf den ersten Blick marginal erscheinen, müssen wir doch überlegen, wie diese Änderungen umzusetzen sind. Ich sehe hier nicht, dass es mit einem Satz in irgendeiner Leitlinie getan ist. Gerade die Änderungen in 6) und 8) können einiges an Aufwand bedeuten. Dazu kommen natürlich auch noch die Änderungen im Anhang A, die ja nicht nur inhaltlicher Natur sind, sondern auch eine komplett neue Struktur und Herangehensweise an die Definition des Sicherheitsniveaus darstellen. Also: viel zu tun.

Viele verbinden mit dem Begriff Blockchain die digitale Währung Bitcoin. Wir verwenden Blockchain als Überbegriff über ein Sammelsurium an Technologien. Dieser Artikel gibt einen ersten Überblick über die Welt der Blockchains.

Blockchain

Einfach ausgedrückt ist eine Blockchain eine Reihe an Datensätzen mit Zeitstempel, die von einer Anzahl an Nodes (Computer) gespeichert werden. Diese Nodes werden nicht von einer einzelnen Entität gesteuert. Diese Datensätze werden in Blöcken gespeichert und mit dem Hashwert des vorangegangenen Blocks verschlüsselt. Daraus entsteht eine Kette an Blöcken. Sobald ein neuer Block gespeichert wird, ist der vorherige Block nicht mehr veränderbar. Jeder Teilnehmer (Node) hält eine Kopie der gesamten Blockchain vor und wird permament aktualisiert. Über einen komplexen Mechanismus einigen sich die Nodes untereinander, wer die Inhalte des aktuellen Blocks festlegen darf.
Die wichtigsten Eigenschaften einer Blockchain sind

• Unveränderlichkeit
• Transparenz
• Dezentralisierung

Unveränderlichkeit

Die Unveränderlichkeit ist zweifellos eines der wichtigsten Merkmale jeder Blockchain. Unveränderlichkeit bedeutet, dass kein Entwickler oder Teilnehmer Daten einfügen oder verändern kann ohne Validierung durch andere Teilnehmer. Wenn eine Transaktion an eine Blockchain übergeben wird, muss eine bestimmte Anzahl Teilnehmer diese Transaktion für valide erklären damit sie in den Block aufgenommen wird. Wenn eine Transaktion in einen Block aufgenommen wird, kann sie nicht mehr verändert werden. Die Teilnehmer, die eine Transaktion validieren können, werden Validatoren genannt. Jede Blockchain hat einen eigenen Mechanismus um die Vertrauenswürdigkeit eines Validatoren zu verifizieren. Überwiegend sind das rein technische Verfahren, wodurch menschliche Unzulänglichkeiten oder Agendas ausgeschlossen werden.

Dezentralisierung

Dezentralisierung bedeutet, dass es keine einzelne Person oder Autorität gibt, die die Kontrolle über die Verarbeitung der Daten hat. Eine herkömmliche Netzwerkinfrastruktur folgt dem Client-Server Model. In diesem Model werden Betrieb und Entwicklung von einer oder mehreren Personen gesteuert, die einer Organisation oder Organisationseinheit zugeordnet werden. Die Regeln werden von der Organisation oder einer übergeordneten Autorität (z.B. einer Regierung) festgelegt.
Eine dezentrale Blockchain löst diese Abhängigkeit auf. Die Teilnehmer (Nodes) sind über die ganze Welt verteilt und kommunizieren verschlüsselt über das Internet. Der Ausfall oder das Abschalten eines Nodes hat keine Auswirkung auf die Blockchain. Keine zentrale Stelle entscheidet über die Teilnahme an der Blockchain, die Teilnahme ist grundsätzlich jedem möglich.

Transparenz

Die gesamte Blockchain ist für alle Teilnehmer einsehbar. Jede einzelne Transaktion, kann nachvollzogen werden. Natürlich enthält eine Transaktion in einer Blockchain sehr stark vereinfachte Daten. Eine Bitcoin Transaktion enthält nur die ID der sendenden und empfangenden Wallet und die Anzahl transferierter Satoshi. Aus der Transaktion geht nicht hervor, wer der Eigentümer der Wallet ist. Der Inhalt der Transaktionen ist abhängig von der Blockchain und dem Zweck der Blockchain. Spezielle Blockchains können auch für die verschlüsselte Ablage von Daten verwendet werden.

Sicherheit

Informationssicherheit zielt auf die Aspekte Vertraulichkeit, Integrität und Verfügbarkeit ab. Diese Aspekte können in einer Blockchain zu einem extrem hohen Grad gewährleistet werden. Die dezentrale Datenhaltung gewährleistet die Verfügbarkeit, da es keine Stellen gibt an denen ein Ausfall Folgen für die gesamte Blockchain hätte. Die Unveränderlichkeit gewährleistet die Integrität gewissermaßen absolut, da ein Angreifer die Mehrheit der Nodes kontrollieren müsste um eine Veränderung zu validieren. Die Vertraulichkeit wird durch Verschlüsselungsverfahren gewährleistet die nach heutigem Standard nicht geknackt werden können. Sie Sicherheit wird durch die verwendeten Verfahren gewährleistet und hängt nicht von einer übergeordneten Stelle ab. Jeder Teilnehmer autorisiert Transaktionen durch die Verwendung eines privaten Schlüssels. Die größte Schwachstelle ist daher die Aufbewahrung des privaten Schlüssels. Das liegt aber in der Verantwortung des Teilnehmers.

Warum Blockchain auf dsgvo-support.de?

Bei uns geht es um die Aspekte Datenschutz und Informationssicherheit. Die großen Herausforderungen sind dabei (neben den rein gesetzlichen Verpflichtungen) die Gewährleistung der obengenannten Sicherheitsaspekte unter Berücksichtigung der Einschränkungen der DSGVO. Ein hohes Sicherheitsniveau zu gewährleisten ist teuer und aufwändig und gerade für kleine Unternehmen oft nicht möglich. Der Einsatz von Dienstleistern bedeutet ein hohes Risiko, da zwar das Sicherheitsniveau angehoben werden kann, aber dafür eine Abhängigkeit von einer externen Stelle besteht. Gerade beim Einsatz von Cloud Anbietern besteht noch zusätzlich das Problem dass der Dienstleister einer anderen Gerichtsbarkeit untersteht und ein Zugriff auf die Daten durch fremde Regierungseinrichtungen nicht ausgeschlossen werden kann.
In den letzten Monaten hat es viele interessante Entwicklungen gegeben, die Blockchains für die Verarbeitung personenbezogener Daten interessant werden lassen. Die meisten dieser Projekte stecken noch in den Kinderschuhen, wir möchten trotzdem frühzeitig darüber berichten, damit diese Entwicklungen auch unseren Lesern zugänglich sind.

Nachdem nun das Cookie-Urteil des BGH veröffentlicht wurde, sind einige offene Fragen beantwortet worden, gleichzeitig haben sich aber mit jeder beantworteten Frage gefühlt zwei neue aufgetan. Brauche ich einen Cookie Banner für meine Website? Was aber, wenn ich nur funktionelle Cookies setze? Ab wann gelten Cookies nicht mehr als funktionelle Cookies? Wie muss der Cookie Banner gestaltet sein, damit ich eine wirksame Einwilligung der User einhole und mich vor Bußgeldern schütze? Wie kann ich meine Website datenschutzkonform gestalten und dennoch möglichst hohe Einwilligungsraten erreichen, um meine Website noch besser den Bedürfnissen meiner Kunden anpassen zu können?

Sehen wir uns erst mal das neueste Urteil des BGH zu dem Thema an. Was hat der BGH gesagt, bzw. was hat er nicht gesagt?

„Cookie dürfen nur noch mit Einwilligung gesetzt werden“

FALSCH

Der BGH hat ebenso wenig wie der EuGH gesagt, dass sämtliche Cookies nur noch mit Einwilligung gesetzt werden dürfen. In der Entscheidung ging es lediglich um die Frage, ob eine Einwilligung, die mittels eines vorangekreuzten Kästchens eingeholt wurde, wirksam ist. Das hat der BGH mit Bezug auf das TMG (Telemediengesetz), welches richtlinienkonform auszulegen ist, ausdrücklich verneint. Wir können also festhalten: Wenn auf einer Website einwilligungsbedürftige Cookies gesetzt werden sollen, darf die Einwilligung nicht mittels eines vorangekreuzten Kästchens eingeholt werden, sondern der User muss eine echte und freie Wahl haben. 

Bezieht sich dieses Erfordernis auf alle Cookies? Nein, es geht hier um Cookies, die zur Erstellung von Nutzerprofilen für Zwecke der Werbung oder der Marktforschung gesetzt werden. Dabei wird nicht unterschieden, ob es sich bei den verarbeiteten Daten um personenbezogene Daten handelt oder nicht.

Das heißt also, dass für funktionelle Cookies, die für den Betrieb der Website notwendig sind, keine Einwilligung des Users eingeholt werden muss. Das gesamte Urteil des BGH vom 28. Mai 2020 kann hier nachgelesen werden: https://www.bundesgerichtshof.de/SharedDocs/Pressemitteilungen/DE/2020/2020067.html?nn=10690868 .

Deshalb nun die wichtige Frage: Was sind funktionelle Cookies eigentlich? Welche Cookies fallen darunter?

Sehen wir uns an, was die Aufsichtsbehörden dazu sagen.

Auf der Website der Datenschutzaufsichtsbehörde Baden-Württemberg beispielweise wird gezeigt, dass man für Cookies, die keine seitenübergreifende Nachverfolgung des Users ermöglichen und zum Betrieb des Telemediendienstes notwendig sind, die also für wesentliche Funktionen zwingend erforderlich sind, häufig keine Einwilligung braucht. Als Beispiel wird die Warenkorb-Funktion genannt. 

Cookies, die den User seitenübergreifend tracken und die die Informationen vielleicht sogar an Dritte, möglicherweise auch ins Ausland transferieren (wie bei Google Analytics der Fall; solche Cookies werden im Folgenden als Tracking Cookie bezeichnet) bedürfen einer ausdrücklichen Zustimmung des Users (Nachzulesen unter https://www.baden-wuerttemberg.datenschutz.de/faq-zu-cookies-und-tracking-2/ ).

Auch das bayerische Landesamt für Datenschutzaufsicht sagt auf seiner Website ganz klar, dass für Dienste wie Google Analytics vor Verwendung die Einwilligung des Users eingeholt werden muss (nachzulesen unter https://www.lda.bayern.de/de/faq.html ).

Wir haben nun also in etwa abgesteckt, für welche Cookies eine Einwilligung eingeholt werden muss.

Nun kommt die nächste Hürde: Die Einwilligung so zu gestalten, sodass sie nach DSGVO wirksam ist und die Daten der User rechtmäßig verarbeitet werden dürfen. In Art. 4 Nr. 11 werden die Kriterien für eine wirksame Einwilligung im Sinne der DSGVO genannt. Die Einwilligung wird hier wie folgt definiert: „jede freiwillig, für den bestimmtem Fall, in informierter Weise und unmissverständliche abgegebene Willensbekundung in Form einer Erklärung oder einer sonstigen eindeutig bestätigenden Handlung, mit der die betroffene Person zu verstehen gibt, dass sie mit der Verarbeitung der sie betreffenden personenbezogenen Daten einverstanden ist”.

In Art. 7 DSGVO werden ebenfalls Bedingungen für eine wirksame Einwilligung beschrieben. Dieser Artikel legt fest, dass der Verantwortliche nachweisen können muss, dass die betroffene Person eingewilligt hat (das ist bei Verwendung eines Consent Managers vorgesehen), dass die Einwilligung von anderen Sachverhalten klar getrennt sein muss und dass die betroffene Person jederzeit die Möglichkeit haben muss, ihre Einwilligung zu widerrufen, wobei der Widerruf genauso einfach sein muss wie es das Erteilen der Einwilligung war.

Erwägungsgrund 32 der DSGVO konkretisiert die Anforderung an eine wirksame Einwilligung dahingehend, dass Untätigkeit oder Stillschweigen der betroffenen Person keine wirksame Einwilligung darstellen sollen.

Was bedeutet das für die Praxis?

Die Einwilligung muss zunächst freiwillig erteilt werden, das heißt der User muss eine echte und freie Wahl haben, er darf also nicht in irgendeiner Form gezwungen werden, seine Einwilligung zu erteilen und muss die Möglichkeit haben, seine Einwilligung zu verweigern, ohne dass ihm daraus Nachteile entstehen.

Das bedeutet auch ein, dass eine wirksame Einwilligung nicht durch vorangekreuzte Kästchen eingeholt werden kann und auch ein Opt-out-Verfahren nicht zu einer wirksamen Einwilligung führt. 

Die Einwilligung muss außerdem für den konkreten Fall und informiert erfolgen. Sie darf also nicht mit anderen Inhalten gekoppelt werden und muss von etwaigen anderen Vertragsteilen und Sachverhalten klar abgegrenzt sein.

Weiter müssen dem User zum Zeitpunkt der Einholung der Einwilligung alle Informationen aus Art. 13 zur Verfügung gestellt werden.

Unzulässig sind somit alle Banner, die lediglich darauf hinweisen, dass auf der Website Cookie verwendet werden und dass sich der Benutzer durch Weitersurfen mit dem Setzen von Cookies einverstanden erklärt, denn so wird keine wirksame Einwilligung nach DSGVO eingeholt.

Außerdem muss darauf geachtet werden, dass der User seine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen kann. Dabei muss der Widerruf genauso einfach sein wie das Erteilen der Einwilligung. Hat der User also durch einen Klick seine Einwilligung gegeben, so muss der User genauso seine Einwilligung auch widerrufen können. 

Umsetzung in der Praxis

In der Praxis gibt es verschiedene Möglichkeiten, diese Anforderungen umzusetzen. Man kann den Cookie Banner entweder als Overlay einbinden oder etwas dezenter an den oberen und unteren Rand des Bildschirms. Vorteil des Overlays ist, dass sich der User auf jeden Fall aktiv entweder für oder gegen Cookies entscheiden muss und deshalb in den meisten Fällen die Einwilligungsraten höher sein werden.

Darin liegt auch gleichzeitigt der Nachteil, da es den Usern extrem auf den Cookie („Keks“) gehen kann. Surft ein User jedoch einfach weiter, ohne auf den dezenten Cookie Banner einzugehen, dürfen keine Trackingcookies gesetzt werden, da der User nicht aktiv eingewilligt hat. Bei jeder Alternative muss der Websitebetreiber darauf achten, dass durch den Cookie Banner weder das Impressum noch die Datenschutzhinweise verdeckt sein dürfen.

Für welche dieser Optionen man sich letztendlich entscheidet, muss jeder Websitebetreiber selbst für sich abwägen.

Grundsätzlich kann man den Cookie-Banner beispielsweise so gestalten, dass der User entweder alle Cookies akzeptieren kann oder in den weiteren Einstellungen seine Präferenzen festlegt.

Klickt der User auf Einstellungen, wird ihm ein zweites Fenster angezeigt, in welchem die Cookies nach Kategorien aufgelistet werden, z. B. funktionelle Cookies, Cookies für Marketingzwecke, Tracking-Cookies usw. Klickt der User auf „mehr Informationen“, werden ihm die einzelnen Cookies im Detail aufgelistet. Man kann den Banner so konfigurieren, dass der User entscheiden kann, welchen Cookies er zustimmt und welche er ablehnt. Sinnvoll ist außerdem ein Link zu den Datenschutzhinweisen, damit der User alle Informationen gemäß Art. 13 erhalten kann.

Wichtig ist hierbei, dass sämtliche Skripte unterbunden werden, bis der User eingewilligt hat und dass die Einwilligungskästchen nicht vorangekreuzt sind.

Entscheidet man sich dafür dem User die Möglichkeit zu geben, den Banner einfach weg zu klicken und der User nutzt diese Möglichkeit, so wurde keine Einwilligung in Trackingcookies erteilt und solche dürfen nicht gesetzt werden.

Dabei kann der Banner natürlich in das Marketingkonzept des Unternehmens eingebunden werden. Im Netz findet man durchaus kreative Lösungen, die den User dazu animieren, seine Einwilligung abzugeben, und dennoch gesetzeskonform sind. 

Fazit:

Für Cookies, die rein für den Betrieb der Website notwendig sind, muss nach wie vor keine Einwilligung eingeholt werden. Für Cookies dagegen, die den User seitenübergreifend tracken und/oder Daten an Dritte weitergeben, muss eine Einwilligung eingeholt werden. Als Beispiel für einwilligungsbedürftige Cookies nennen die Aufsichtsbehörden die Cookies von Google Analytics.

An die Einwilligung sind bestimmte Kriterien geknüpft: sie muss freiwillig erteilt werden, darf also nicht angenommen oder durch ein Opt-out Verfahren eingeholt werden. Zwingend notwendig ist ein Opt-in, wobei die Kästchen nicht voreingekreuzt sein müssen. Die Einwilligung darf auch nicht mit anderen Inhalten gekoppelt werden und muss genauso einfach zu widerrufen sein, wie sie erteilt wurde.

Durch den Banner dürfen Impressum und Datenschutzerklärung nicht verdeckt sein und der Verantwortliche muss dem User die Pflichtinformationen nach Art. 13 zur Verfügung stellen, zum Beispiel durch die Datenschutzhinweise auf der Website.

In dieser Folge geht es um die Nebenaspekte der Informationssicherheit:

• Authentizität
• Nicht-Abstreitbarkeit
• Verantwortlichkeit
• Verlässlichkeit

Anhand von Praxisbeispielen werden die Aspekte erläutert. Es werden Fragen zur Vorbereitung auf die Zertifizierung gestellt und die Bedeutung der Nebenaspekte erklärt. Auch der Zusammenhang zu den Hauptaspekten wird herausgestellt.

Die Hauptaspekte der Informationssicherheit sind

• Vertraulichkeit
• Integrigät
• Verfügbarkeit

Vertraulichkeit: Informationen nur solchen Personen/Entitäten zur Verfügung stellen, die auch berechtigt sind, diese Information zu erhalten. Beispiele und Quizfragen dazu im Video.

Integrität: Information davor schützen, dass sie verändert, umsortiert, gelöscht, wiederhergestellt usw. werden. Warum das eine Frage von Leben und Tod sein kann, erkläre ich im Video.

Verfügbarkeit: Information dann verfügbar machen, wenn sie benötigt wird. Wie ergänzen sich Verfügbarkeit und Vertraulichkeit? Ist Verfügbarkeit der wichtigste Aspekt der Informationssicherheit? Antworten gibt es im Video.

In diesem Video gibt es auch Vertiefungsfragen zum Thema und am Schluß ein Schmankerl für Klugscheißer.

Einleitungsvideo von David Gabel zum Thema “Was ist Informationssicherheit?” Der 1. Teil der Videoreihe beschäftigt sich genau mit dieser Frage.

Informationssicherheit ist die Aufrechterhaltung von

• Vertraulichkeit
• Integrität
• Verfügbarkeit

von Information.

Nebenaspekte der Informationssicherheit sind

• Authentizität
• Nicht-Abstreitbarkeit
• Verantwortlichkeit
• Verlässlichkeit

Aus gegebenen Anlass möchten wir über ein paar Aspekte informieren, die bei Telearbeit und HomeOffice zu berücksichtigen sind. Der Datenschutz schließt HomeOffice und mobiles Arbeiten nicht grundsätzlich aus. Eine klare gesetzliche Regelung für die datenschutzrechtliche Zulässigkeit von Telearbeit und Mobilem Arbeiten gibt es nicht. Es obliegt dem Verantwortlichen unter Berücksichtigung des Zwecks und der Risiken, die Zulässigkeit von HomeOffice und des mobilen Arbeitens zu prüfen und entsprechende Maßnahmen zur Sicherstellung des Datenschutzes und der Informationssicherheit zu implementieren. Eine Zulässigkeitsvoraussetzung kann dabei natürlich die öffentliche Sicherheit und Gesundheitsvorsorge für die Mitarbeiter sein.

Die folgenden Punkte sollen als Anregung dienen HomeOffice als Maßnahme in Betracht zu ziehen und dabei Sicherheits- und Datenschutzaspekte mit Bedacht und Augenmaß zu berücksichtigen.

Technische Maßnahmen zur Risikominimierung (Art. 32 DSGVO)

Medienbruchfreie Gestaltung
Durch die medienbruchfreie Gestaltung der Tele- bzw. mobilen Arbeit und der voll elektronischen Datenverarbeitung fällt die Notwendigkeit zum Transport von Unterlagen weg. Dadurch wird das Risiko von Verlust, Beschädigung und unbefugter Einsichtnahme reduziert.
Bei medienbruchfreier Gestaltung birgt HomeOffice ein geringeres Missbrauchsrisiko als das Mobile Arbeiten, da der HomeOffice Arbeitsplatz vom Arbeitgeber / von der Dienststelle in gewissem Umfang kontrolliert werden kann.

Verschlüsselung
Mobile Datenträger können leicht verlorengehen. Dieses Risiko kann allerdings reduziert werden, wenn die Daten auf dem mobilen Gerät verschlüsselt werden und der Transport des mobilen Gerätes nur im gesperrten Zustand erfolgt. Dabei gilt zu berücksichtigen, dass der Verlust eines mobilen Datenträgers mit personenbezogenen Daten auch wenn er verschlüsselt ist, ein meldepflichtiger Vorfall sein kann.

Sichere Verbindungen
Öffentliche Netzwerkzugänge (WLAN im Hotel, Flughafen, Bahnhof usw.) dürfen über mobile Geräte nur genutzt werden, wenn ein Zugriff auf die Unternehmensinfrastruktur durch ein VPN mit entsprechend starker Verschlüsselung erfolgt. Das VPN sollte so konfiguriert sein, dass während der Sitzung keine lokalen Netzwerkverbindung aktiv sein können. Der Zugriff auf lokale Ressourcen (z.B. Drucker, USB-Sticks) sollte vom VPN nicht möglich sein.

Shoulder Surfing
Beim mobilen Arbeiten im öffentlichen Bereich (z.B. Zug, Flughafen etc.) sollte außerdem darauf geachtet werden, dass der Bildschirm und die Tastatur der genutzten mobilen Geräte durch Passanten und Videokameras nicht einzusehen sind.
Dienstliche Telefonate mit Personenbezug sollten, wie vertrauliche dienstliche Gespräche, im öffentlichen Raum nur geführt werden, wenn ein Mithören ausgeschlossen werden kann.

Gerätesicherheit
Die Nutzung mobiler Geräte und HomeOffice sollte nur mit einer Zwei-Faktor Authentifizierung möglich sein. Sicherheitskarten, RFID-Chips und andere hardwarebasierte Authentifizierungsmittel sollten getrennt von dem mobilen Gerät aufbewahrt werden. Nicht benutzte Neztwerkverbindungen (IR, Bluetooth usw.) sowie physikalische Anschlüsse (z.B.) sollten deaktiviert sein. Die Nutzung mobiler Geräte sollte durch den Einsatz eines MDM protokolliert und überwacht werden.

Datenträgersicherung
Datenträger sollten nur verschlüsselt und gesperrt transportiert werden. Unterlagen sollten nur in verschlossenen und nicht einsehbaren Behältern transportiert werden. Datenträger und Unterlagen sollte nie unbeaufsichtigt gelassen werden. Bei der Telearbeit müssen geeignete Räumlichkeiten und Arbeitsmittel zur sicheren Aufbewahrung und vertraulichen Behandlung von Unterlagen und Datenträgern mit personenbezogenen Daten vorhanden sein. Auch die mit dem Beschäftigten in häuslicher Gemeinschaft lebenden Personen dürfen keinen Zugriff auf vertrauliche Unterlagen haben.

Organisatorische Maßnahmen zur Risikominimierung (Art. 24 DSGVO)

Kontrolle des HomeOffice Arbeitsplatzes
Im Rahmen von HomeOffice muss der Arbeitgeber die Möglichkeit des Zugangs zur Wohnung des Beschäftigten haben. Das notwendige Zutrittsrecht des Arbeitsgebers muss vertraglich mit dem Beschäftigten vereinbart werden, wobei auch das Einverständnis der in häuslicher Gemeinschaft mit ihm zusammenlebenden Personen umfasst sein muss. Die sonstigen Kontrollberechtigten, wie z. B. der betriebliche Datenschutzbeauftrage und der Beauftragte für Arbeitssicherheit, sollten in das Zutrittsrecht einbezogen werden.

Trennung der privaten und dienstlichen Nutzung
Eine private Nutzung der vom Arbeitgeber zur Verfügung gestellten IT-Ausstattung sollte unzulässig sein. Personenbezogene Daten und andere vertrauliche Informationen sollten nicht auf privater Hardware verarbeitet werden dürfen. Sollten private Geräte für HomeOffice und mobiles Arbeiten zulässig sein, sollten auf dem Gerät getrennte Sicherheitsbereiche eingerichtet werden in denen zwischen privaten und betrieblichen Daten unterschieden werden kann. Der Sicherheitsbereich zur dienstlichen Nutzung sollte außerhalb der Kontrolle des Mitarbeiters liegen. Eine Datenübertragung zwischen den Bereich sollte ausgeschlossen sein. Die Weiterleitung von beruflichen E-Mails an ein privates Postfach sollte ebenso wie der Versand von beruflichen E-Mails von einem privaten Postfach untersagt sein.

Betriebsvereinbarung
Es sollte eine Betriebs-/Dienstvereinbarung mit den Grundsätzen zum Datenschutz und zur Informationssicherheit im HomeOffice und dem mobilen Arbeiten geben. Diese Vereinbarung sollte die Verantwortlichkeiten für Datenschutz und Informationssicherheit klar regeln. Dabei ist darauf zu achten, dass bei der Entscheidung ob eine Tätigkeit im HomeOffice durchgeführt werden kann, frühzeitig der Datenschutzbeauftragte einzubinden ist. (Art. 38 Abs. 1 DSGVO)

Verzeichnis der Verarbeitungstätigkeiten
Die Verlagerung oder Erweiterung einer Verarbeitungstätigkeit in das HomeOffice oder mobilem Arbeiten ist im Verzeichnis der Verarbeitungstätigkeiten zu berücksichtigen.

HomeOffice ist eine wichtige Maßnahme in der aktuellen Situation. Wir als Datenschutzbeauftragte unterstützen diese Maßnahmen und möchten gerne dafür sorgen, dass auch während dieser Zeit das Datenschutz- und Sicherheitsniveau aufrechterhalten bleibt. Fragen dazu beantworten wir natürlich gerne, auch aus dem HomeOffice.

Aktuell beschäftigen wir uns sehr viel mit dem Thema Cookies und Tracker auf Websites. Während immer mehr Websitebetreiber dazu übergehen, sich über Cookie Banner eine Einwilligung zu „erschleichen“ werden die Aufsichtsbehörden nicht müde, darauf hinzuweisen, dass dies nicht zulässig ist. Der Banner Hinweis: „Mit der weiteren Nutzung der Website willigen Sie in die Nutzung von Cookies ein.“ darf auf den meisten Websites nicht verwendet werden. Hier die gängigsten Fehler, die dabei gemacht werden:

• Cookies werden meistens bereits auf der Startseite gesetzt. D.h. Das erste Mal werden die Cookies gesetzt bzw. ausgelesen vor der „weiteren Nutzung der Website“. Das bedeutet, dass die Einwilligung zu dem Zeitpunkt noch gar nicht vorliegt. Es fehlt also an einer gültigen Rechtsgrundlage.
• Nach Meinung der meisten Aufsichtsbehörden, kann die Handlung selbst nicht auch die Einwilligung darstellen. D.h. Die Nutzung der Website als Einwilligung zu werten ist schwach und dürfte überwiegend zu unwirksamen Einwilligungen führen. (siehe auch hier) Hierzu ist auch Artikel 7 DSGVO zu beachten, der verlangt, dass der Verantwortliche die Einwilligung nachweisen kann (Art. 7 Abs. 1 S. 1 DSGVO) und dass der Widerruf der Einwilligung genauso einfach möglich sein muss, wie die Einwilligung selbst (Art. 7 Abs. 3 S. 4 DSGVO). Beides dürfte bei der CookieWall schwierig bis gar nicht möglich sein.
• Die Datenschutzerklärung kann erst gelesen werden, nachdem der Nutzer durch „die weitere Nutzung der Website“ seine Einwilligung erklärt hat. Eine Einwilligung ohne ausreichende Information ist aber sowieso unwirksam. (Art. 6 Abs. 1 S. 1 lit a) DSGVO)

Wir raten daher dringend davon ab so einen CookieBanner zu verwenden. Wenn Sie keine Tracking und/oder Marketing Cookies verwenden, sondern nur Cookies, die für den Betrieb der Website nötig sind (z.B. Shoppingcart oder Loadbalancing) dann braucht es denn Banner gar nicht. Dafür reicht der Hinweis in der Datenschutzerklärung. Sollten Sie aber Markting oder Tracking Cookies (Google Analytics usw.) einsetzen, dann muss der Banner so gestaltet sein, dass eine wirksame Einwilligung eingeholt wird. Die folgenden Punkte müssen dabei mindestens berücksichtigt werden:

• Vor der Erteilung der Einwilligung müssen alle Marketing Cookies und Tracker deaktiviert sein.
• Es muss möglich sein, sich über die Art der Cookies, deren Zweck und Laufzeit zu informieren, bevor die Einwilligung erteilt wird.
• Es muss die Möglichkeit geben, jederzeit auf demselben Weg, die Einwilligung zu widerrufen.
• Empfehlenswert: Im Einwilligungsscreen Marketing und Tracking Cookies deaktiviert lassen, bis der Nutzer sie aktiviert.
• Empfehlenswert: Do-Not-Track-Einstellung des Browsers verarbeiten und respektieren.

Es gibt eine Menge professionelle und preiswerte Lösungen für Cookie Banner, die die Anforderungen der DSGVO erfüllen. Es lohnt nicht das Risiko einzugehen und eine halbgare kostenfreie Lösung zu nutzen. Ebensowenig lohnt es sich, sich etwas selbst zu programmieren oder programmieren zu lassen. Für alle gängigen Content Management Systeme gibt es fertige Plugins.

Den Cookie Banner korrekt einzusetzen und zu konfigurieren ist technisch nicht besonders schwierig. Allerdings wird man damit rechnen müssen, dass bei korrekter Anwendung, viele Besucher der Website ihre Einwilligung verweigern werden. Ob das ein großer Verlust ist, hängt tatsächlich davon ab, welche Auswertungen gemacht werden sollen. Es lohnt also immer auch der Blick auf die Anforderungen und die aktuell eingesetzten Tools, um zu sehen ob es nicht von Haus aus datenschutzfreundlichere Lösungen gibt.

Wer schon ein ISMS betreibt ist gut gerüstet um mit denselben Werkzeugen auch die Anforderungen des Datenschutzes zu managen. Natürlich wird viel darüber geredet, dass ein ISMS nativ bereits gut geeignet ist, die Anforderungen des Artikel 32 DSGVO zu erfüllen. Aber die DSGVO besteht aus so viel mehr als nur aus Vertraulichkeit, Verfügbarkeit und Integrität der Daten.

Die Norm ISO/IEC 27552 schickt sich an, die Werkzeuge des ISMS so zu ergänzen, dass damit auch die Anforderungen der DSGVO respektive des Datenschutzes gemanaged werden können. Das wäre dann sogar zertifizierbar und könnte so auf dem Zertifikat stehen: ISO/IEC 27001 mit Erweiterung ISO/IEC 27552 oder so ähnlich. Das muss mit der Zertifizierungsstelle ausgehandelt werden. Die ISO/IEC 27552 alleine ist nicht zertifizierbar, würde auch keinen Sinn machen, denn sie ist explizit als sektorspezifische Erweiterung geschrieben. Die wesentlichen Aspekte der Erweiterung will ich kurz erläutern um dann in weiteren Beiträgen auf die Details einzugehen

Kontext: Zu Beginn jeder ISMS Implementierung steht die Betrachtung des Kontext. Aus dem Kontext wird der Geltungsbereich des ISMS und die Rahmenbedinungen hergeleitet. Mit der Erweiterung sind zusätzliche Aspekte im Kontext zu betrachten. Dazu gehören z.B. die zu beachtenden Datenschutzgesetze DSGVO, BDSG und weitere relevante Gesetze, aktuelle Rechtsprechung, Orientierungshilfen und Statements der Aufsichtsbehörden. Außerdem muss die Rolle des Unternehmens berücksichtigt werden. Das Unternehmen kann neben Verantwortlicher auch Auftraggeber oder Auftragnehmer in einer Auftragsverarbeitung nach Art. 28 DSGVO sein. Auch eine gemeinsame Verantwortlickeit nach Art. 26 DSGVO muss im Kontext betrachtet werden. Entsprechend sind die Vorgaben zu erfassen und zu erfüllen.

Interessierte Parteien: Das ein oder andere ISMS betrachtet die Mitarbeiter des Unternehmens als interessierte Partei. Mit der Erweiterung gehören sie definitiv dazu, ebenso wie Kunden (natürliche Personen), Leads, Websitebesucher und andere deren personenbezogene Daten verarbeitet werden ohne das bereits ein Vertragsverhältnis besteht. Auch die Aufsichtsbehörde gehört zu den interessierten Parteien, ebenso wie Auftraggeber und Auftragnehmer in einer Auftragsverarbeitung. Die jeweiligen Anforderungen ergeben sich direkt aus dem Gesetz.

Geltungsbereich: Der typische Geltungsbereich eines ISMS umfasst die IT und Bereiche der Wertschöpfungskette in denen die Unternehmenswerte eine Rolle spielen. Häufig ist der Geltungsbereich bewusst eng gewählt, da die Implementierung getrieben wird durch äußere Anforderungen. Ausgehend von der Kontextbetrachtung und den Anforderungen der interessierten Parteien muss der Geltungsbereich auch die Unternehmensbereich beinhalten in denen personenbezogene Daten verarbeitet werden. Dazu gehört üblicherweise neben der IT auch die Personalabteilung und Marketing/Vertrieb. Natürlich können dazu auch noch weitere Bereiche gehören. Auch die Systeme im Geltungsbereich müssen ergänzt werden. War z.B. bislang die Telefonanlage nicht im Geltungsbereich, weil nicht kritisch für die Leistungserbringung, dann muss sie jetzt mit dazugenommen werden, da dort personenbezogene Daten verarbeitet werden. Mehr dazu im Punkt Risikomanagement.

Schnittstellen: Ein Unteraspekt des Geltungsbereichs sind die Schnittstellen und Abhängigkeiten. Mit der Erweiterung kommen neue Schnittstellen dazu, z.B. zur Aufsichtsbehörde, zur Mitarbeitervertretung, zu Verbraucherschutzverbänden oder zu einem externen Datenschutzschutzbeauftragten. Auch zu Auftragsverarbeitern oder zu Auftraggebern einer Auftragsverarbeitung müssen Schnittstellen definiert und dokumentiert sein und gesteuert werden.

Leitlinie: Die Leitlinie sollte auch angepasst werden. Es muss klar daraus hervorgehen, dass es nicht nur um den Schutz des Unternehmens geht, sondern auch um den Schutz der Personen, deren Daten verarbeitet werden. Auch wenn die Schutzgrunddebatte rund um die DSGVO noch nicht abgeschlossen ist, sollte man sich mit diesen juristischen Details nicht rumschlagen. Die Rechte und Freiheiten der Menschen, deren Daten verarbeitet werden müssen geschützt werden. Darauf muss sich das Top Management in der Leitlinie festlegen. In der Leitlinie wird das Managementsystem umbenannt. Aus “Informationssicherheit” wird “Datenschutz und Informationssicherheit”, aus Informationssicherheits Managementsystem” wird “Datenschutz und Informationssicherheits Managementsystem (DIMS)”. Oder wer es lieber englisch mag: Aus “information security” wird “privacy and information security”, aus “information security management system” wird (Achtung!!!) “privacy and information management system (PIMS)”. Außerdem sollten in der Leitlinie auch zusätzliche Verantwortlichkeiten festgelegt werden, wie z.B. der Datenschutzbeauftragte, das Mitglied der obersten Leitungsebene, das für Datenschutz verantwortlich ist, vielleicht noch bereichsspezifische Verantwortlichkeiten. Es gibt noch eine Menge weitere sinnvolle Inhalte für die Leitlinie, wenn es um Datenschutz geht, aber ich brauche ja auch noch Stoff für weitere Beiträge.

Risikomanagement: Das ist sicher der spannendste Teil, denn hier geht es an’s Eingemachte. Risikomanagement in einem ISMS ist für viele schon eine Herausforderung. Das merke ich in meinen Workshops immer wieder. Die Angst davor, das Ungewisse und die Ahnung der Komplexität wirkt manchmal lähmend. Keine weiß wo er anfangen soll. Zum Glück ist es aber gar nicht so schwer. Dazu habe ich ja schon geschrieben und werde bestimmt noch mehr schreiben. Um das Risikomanagement um Datenschutz zu erweitern muss erst mal eine Grundsatzentscheidung getroffen werden: ein integriertes Risikomanagement oder zwei separate Prozesse. Ich bevorzuge jetzt einfach mal den integrierten Prozess. Dazu muss das Risikomanagement erweitert werden um Risiken der Verarbeitung personenbezogener Daten und des Mißbrauchs oder der Verletzung des Schutzes personenbezogener Daten. Dazu müssen neue Kriterien festgelegt werden. Analog zum Schutzbedarf bei Assets, müssen Verarbeitungsprozesse personenbezogener Daten auf ihr Risiko hin bewertet werden. Eine Datenschutz Folgenabschätzung (Vergleichbar mit der Risikoeinschätzung nach ISO 27001) muss gemacht werden, wenn a) die Verarbeitung ein voraussichtlich hohes Risiko für die betroffenen Personen birgt oder b) die Aufsichtsbehörden den Prozess auf die Positivliste gesetzt haben. Um die Bewertung nach a) zu machen, verwende ich die Risikokriterien der WP29. Die Einschätzung des Risikos kann dann nicht mehr nach Auswirkungen für das Unternehmen erfolgen, sondern muss dem Risiko für die betroffenen Personen Rechnung tragen (Eine entsprechende Methodik dazu liefert die ISO 29134). Dazu sind andere Auswirkungsklassen nötig. Während Unternehmensrisiken häufig nach kaufmännischen Gesichtspunkten bewertet werden, sind die Risiken für betroffenen Personen vielfältigter. Dazu gehören z.B. Verletzung der Rechte, finanzielle Auswirkungen, Verlust des Ansehens, Gefahr für Leib und Leben, Auswirkungen auf nur mittelbar Beteiligte (z.B. Familienangehörige) usw. Hier müssen also entsprechende Kategorien und Abstufungen festgelegt werden, mit denen die Risiken für die betroffenen Personen beurteilt werden können. Auch hier kann eine Matrix nach Auswirkung und Eintrittswahrscheinlichkeit festgelegt und Risikoakzeptanzkriterien festgelegt werden. Die aus der Risikobewertung resultierende Anwendbarkeitserklärung muss dann um die zusätzlichen Maßnahmen für Verantwortliche (Kapitel 7 ISO 27552) und/oder Auftragsverarbeiter (Kapitel 8 ISO 27552) ergänzt werden. Die bereits in der Anwendbarkeitserklärung enthaltenen Maßnahmen müssen um Datenschutzaspekte ergänzt werden. Die entsprechenden Umsetzungshinweise dazu sind im Kapitel 6 ISO 27552 zu finden.

Sonstiges: Zusätzliche KPI für die Leistungsbewertung machen Sinn und können entwickelt werden. Auch die Managementbewertung kann ergänzt werden, aber das muss nicht explizit gemacht werden, da es sich in einem integrierten Managementsystem sowieso ergibt. Das Auditprogramm sollte um Auditaktivitäten rund um den Datenschutz erweitert werden. Dazu gehören nicht nur technische Überprüfungen, sondern z.B. auch Reifegradmessungen in den verschiedenen Bereichen. Transparenzprüfung der Informationspflichten usw. Die weiteren Bestandteile des ISMS bleiben, bis auf die Namensänderung, weitestgehend gleich.

Fazit: Die Anpassungen des Managementsystems sind überschaubar. Die zusätzlichen Aufgaben die sich daraus ergeben sind aber doch aufwendig, müssen aber sowieso gemacht werden, da sie sich im Wesentlichen aus den Anforderungen für Verantwortliche nach DSGVO ergeben. Das Managmentsystem erleichtert aber die Steuerung dieser Aktivitäten und sorgt dafür, dass das Thema nicht wieder in Vergessenheit gerät.

Die Welt braucht Standards und Normen. Auch wenn es kaum jemand zugeben will, ist es doch gut, wenn man sich darauf verlassen kann, dass Dinge einfach so sind wie sie sind, weil es mal jemand so festgelegt hat. Ich weiß, niemand möchte ein standardisiertes Leben führen und das ist auch gut so. Schließlich sind wir alle Individuen. Aber ganz so einfach ist es nicht. Unser Leben wäre nämlich unendlich komplizierter, wenn es keine Standards gäbe. Zeiteingaben, Steckdosen, Netzwerkverbindungen. Standards können das Leben leichter machen. Beim Datenschutz ist es ähnlich. Die Herangehensweise der Unternehmen an den Datenschutz variiert stark. Um bei einer Zusammenarbeit ein gemeinsames Verständnis zu erlangen bedarf es einer einheitlichen Grundlage. Die DSGVO sieht z.B. in Artikel 42 Zertifizierungsverfahren, Datenschutzsiegel- und prüfzeichen vor, “die dazu dienen, nachzuweisen, dass diese Verordnung bei Verarbeitungsvorgängen von Verantwortlichen oder Auftragsverarbeitern eingehalten wird.” Hier wird eine Produkt- oder Prozesszertifizierung für Verarbeitungsvorgänge beschrieben. Sie kann dazu dienen Vertrauen zu schaffen, dass Daten entsprechend den Vorgaben der DSGVO verarbeitet werden.

Read More