Sinnvolle Integration eines Informationssicherheits- und Datenschutzkonzeptes

veröffentlicht am 18. Mai 2022 | Lesedauer ca. 4 Minuten

Es gibt enorme Synergien zwischen einem Informationssicherheits- und einem Daten­schutzmanagementsystem. Eine getrennte Führung kann durchaus Sinn ergeben, auf Dauer sollte aber eine Synchronisation stattfinden, um Konflikte und Ineffizienzen zu vermeiden.

• In welchen Bereichen liegt eine Verbindung zu einem Datenschutzmanagementsystem (DSMS) vor »

• In Ergänzung zu den obigen Synergien stellt sich die Frage, in welchen Bereichen eine datenschutzrechtliche Einzelbetrachtung weiterhin notwendig ist »

• Fazit »

Die Aufgabe der beiden Managementsysteme verrät schon ihre Bezeichnung. Ein Informationssicherheits­mana­gement­system (ISMS) bezieht sich auf den Schutz von Informationen und umfasst jegliche Informationen, die aus Sicht der Institution zu schützen sind (z. B. technische Daten, Geschäftsgeheimnisse etc.). Bei einem Da­ten­schutzmanagement bezieht sich der Schutz auf einen Teilausschnitt, nämlich die personenbezogenen Da­ten, die durch die gesetzlichen Pflichten der DSGVO einem besonderen Schutz unterworfen sind.

Insofern bietet es sich an, ein ISMS als den gedanklichen Ausgangspunkt zu betrachten, um die Frage nach einer Integration beider Systeme zu prüfen. Nähert man sich einem ISMS mit einem anerkannten Framework wie der ISO/IEC 27001, erhält man durch die dort beschriebene sogenannte Controls Checklist einen sehr gu­ten Überblick über die Anforderungen. Diese Controls Checklist befindet sich im Annex A des ISMS und stellt in den Details die Anknüpfungspunkte zum Datenschutzmanagement her.

In welchen Bereichen liegt eine Verbindung zu einem Datenschutzmanagementsystem (DSMS) vor

A.5 Informationssicherheitsrichtlinie, A.6 Organisation der Informationssicherheit sowie A.18 Compliance/Konformität

Die Controls fordern eine notwendige Beschreibung der Sicherheitsorganisation (Aufbau, Ablauf) und der Ver­antwortlichkeiten sowie der Instrumente, durch die die Konformität mit dem Framework sichergestellt wird. Eine Erweiterung um ähnliche Anforderungen aus dem Datenschutz ist hier angebracht und geboten.

A.8 Asset Management, A.9 Zugriffskontrolle, A.10 Kryptografie, A.11 Physische & Umgebungssicherheit, A.12 Betriebssicherheit sowie A.13 Kommunikationssicherheit

In diesen Controls wird der Umgang mit Assets (Endgeräte, Infrastruktur, Server, Applikationen, Cloud-Ele­men­te, etc.) und deren technischen sowie organisatorischen Schutzmechanismen gefordert. Im daten­schutz­recht­lichen Sinne sind das die sogenannten TOMs (technische und organisatorische Schutzmaß­nahmen), die jedoch in diesem Bereich explizit nur auf die personenbezogenen Daten gerichtet sind.

A.14 Systemerwerb, Entwicklung & Wartung

Innerhalb dieser Anforderungen wird auf die Schutzmechanismen im Umfeld von jeglicher Veränderung (durch Erwerb/Neuinstallation, Einbringung von eigenen Services sowie die Auswirkungen durch Wartung) einge­gan­gen. Auch das Datenschutzrecht sieht im Umfeld von Privacy-by-Design und Privacy-by-Default spezielle For­der­ungen vor, die hierdurch sinnvoll eingebettet werden können.

A.15 Lieferantenbeziehungen

Jede Lieferantenbeziehung (ausgelagerte Prozesse, Bezug von Einzelleistungen, Kauf von Produkten, etc.) hat Einfluss auf das eigene Schutzniveau. Daher wird an dieser Stelle der Umgang (On-/Off-Boarding, laufende Überwachung) mit Lieferanten gefordert. Eine analoge Forderung hält auch das Datenschutzrecht vor und er­gänzt hier die konkrete Auswahl sowie die vertragliche Untermauerung im Umgang mit der Verarbeitung perso­nenbezogener Daten, etwa bei den Partnern für die Auftragsverarbeitung.

A.16 Informationssicherheitsstörfallmanagement sowie A.17 Informations­sicher­heits­aspekte des Geschäfts­kontinuitäts­managements

Innerhalb dieser Forderungen werden das Erkennen und Reagieren auf Störfälle sowie die Differenzierung, ab wann ein Notfall vorliegt, thematisiert. Das Kontinuitätsmanagement fordert zudem die Auseinandersetzung, wo Risiken gegeben sind und wie mit Vorsorge- und Wiederanlaufplänen dagegen gesteuert wird. Das Daten­schutzrecht fordert auf dieser Ebene ebenfalls – sogar mit einer Frist belegt –wie mit Datenschutz­verletzungen umzugehen ist und dass der Betrieb in angemessener Zeit wiederhergestellt sein muss.

Aus den oben ausgeführten Punkten lässt sich klar ableiten, dass eine „Erweiterung“ der Anforderungen aus einem ISMS in Richtung Datenschutz, Sinn ergibt. Zum einen lassen sich die datenschutzrechtlichen Anfor­derungen an diesen Stellen „einfach“ ergänzen. Zum anderen ist es dringend zu vermeiden, dass parallele Rege­lungen entstehen, welche sich ggf. sogar widersprechen.

In Ergänzung zu den obigen Synergien stellt sich die Frage, in welchen Bereichen eine datenschutzrechtliche Einzelbetrachtung weiterhin notwendig ist:

Verzeichnis der Verarbeitungstätigkeiten

Das Datenschutzrecht fordert eine dedizierte Auseinandersetzung mit Prozessen, die personenbezogenen Daten verarbeiten („Verarbeitungen“). Diese Prozesse sind zu beschreiben und datenschutzrechtlich zu bewer­ten. Die Beschreibung umfasst dabei auch den Bezug zu der verwendeten Technik und den Schutzmecha­nis­men (TOMs).

Archivierungs- und Löschkonzept

In einem ausgeprägteren Umfang fordert der Datenschutz, dass die Daten gelöscht werden müssen, wenn sie nicht mehr benötigt werden. Oftmals gehen hier Regelungen analog des ISMS nicht tief oder detailliert genug vor, weil z. B. die Zweckbindung und die Löschauflagen speziell für personenbezogene Daten noch nicht detail­liert genug ausgearbeitet wurden.

Auftragsdatenverarbeitung

Eine Auftragsdatenvereinbarung aus datenschutzrechtlicher Sicht dient der klaren Abgrenzung der Verant­wortung hinsichtlich der sicheren und gesetzeskonformen Verarbeitung von personenbezogenen Daten. Dabei kann die Entstehung solcher Leistungsbeziehungen – ähnlich innerhalb von ISMS – auch außerhalb des IT-Betriebs stattfinden (Aktenvernichtung, Veranstaltungsmanagement, Newsletter-Versendungen, etc.) und ge­hört „übergreifend“ geregelt.

Datenschutzinformation / Einwilligungen

Insbesondere beim Einsatz von Webseiten oder Webapplikationen – aber nicht nur dort – ist eine Unterrichtung der Betroffenen (Datenschutzinformation) und vermehrt auch das Einholen von Einwilligungen gefordert, die dokumentiert und verwaltet werden müssen.

Prozess zur Sicherstellung der Betroffenenrechte

Datenschutzrechtlich haben Betroffene (Bewerbende, Interessenten, Mitarbeitende, etc.) das Recht z. B. Auskunft zu erhalten oder eine Datenlöschung zu beantragen. Dieser Prozess über den Eingang des Antrags, der Bearbeitung und der Vollzugsmeldung an den Betroffenen muss sicher und transparent organisiert werden.

Prozess zur Meldung von Datenschutzverletzungen

Ergänzend zu den Anforderungen aus den obigen Controls zum Vorfallsmanagement ist bei Erkennung einer ggf. an die Datenschutzaufsicht meldepflichtigen Situation klar zu regeln, wie der Prozess zur Meldung einer Datenpanne abzulaufen hat. Zu klären ist in diesem Zusammenhang wer nach welcher Entscheidung wann und wie die Datenschutzbehörde informieren muss bzw. zur Kommunikation gegenüber Betroffenen berechtigt ist.

Fazit

Die vorangegangenen Ausführungen geben einen Einblick, wo sich ein ISMS mit einem Datenschutzmanage­ment „verträgt“ und es Vorteile schafft, diese zu integrieren. In einer größeren Institution kann es jedoch zu einer Hürde auf dem Weg zur Integration kommen. Ausschlaggebend für die Definition des Wirkungsbereichs eines ISMS ist immer der sogenannte Scope, also der Geltungsbereich innerhalb der Organisation. Oftmals wird ein ISMS nur für einen Ausschnitt einer Institution (z. B. der IT) eingerichtet, wohingegen der Datenschutz für die gesamte Institution gilt. Sollte sich ein ISMS nur bedingt mit dem Geltungsbereich aus datenschutz­recht­licher Sicht decken – was von der Definition des Verantwortlichen abhängig ist – kann es zu Interessens­kon­flikten kommen. Ein solcher Konflikt sollte frühzeitig gelöst werden.