Das ISMS zum DIMS (PIMS) nach ISO 27552 aufbohren.

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.

PIMS? DSMS? ISO/IEC 27552?

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

Grundlagen des Risikomanagements: Assets, Schwachstellen und Bedrohungen.

Das im vorangegangenen Beitrag beschriebene Assetmanagement ist eine grundlegende Voraussetzung für ein funktionierendes Risikomanagement. Wer seine Assets nicht kennt, kann auch kaum Risiken mit Bezug zu diesen Assets identifizieren. Die ISO 27001 ist in diesem Zusammenhang nicht sonderlich hilfreich. In Kapitel 6.1.2 wird nur gefordert einen Prozess zur Informationssicherheitsrisikobeurteilung festzulegen und anzuwenden, der c) die Informationssicherheitsrisiken identifiziert. Dazu muss der Prozess Risiken im Zusammenhang mit dem Verlust der Vertraulichkeit, Integrität und Verfügbarkeit innerhalb des Anwendungsbereichs des ISMS und die Risikoeigentümer identifizieren. Wie das gehen soll, steht da aber nicht.

Read More

Was ist ein Asset?

Diese Frage wird oft diskutiert. Viele finden die Antwort recht schnell in ihrem Inventar oder ihrer CMDB. Tatsache ist, dass die Norm in den Kapiteln 4 – 10, also den Kapiteln, die das Managementsystem beschreiben, keinen direkten Bezug auf Assets liefert. Asset kann frei als „Wert“ übersetzt werden. Also, alles was für eine Organisation von Wert ist, ist ein Asset. Die Norm ISO/IEC 27000, also das Mutterschiff, sagt in Kapitel 3.2.2 ganz klar, dass Information ein Wert ist, der, ebenso wie andere wichtige Unternehmenswerte, zu schützen ist. Dabei muss berücksichtigt werden, dass Information in unterschiedlicher Form vorliegt und auf verschiedenen Medien gespeichert wird. Information kann auf Papier geschrieben werden, auf Magnetbändern archiviert werden oder einfach in den Köpfen der Mitarbeiter vorhanden sein. Information wird häufig auf verschiedenste Weise verarbeitet und hier spielen IT-Systeme eine wichtige Rolle.

Read More

Die Informationssicherheitspolitik

Vorab ein Wort unter uns: Ich finde den Begriff Politik in diesem Zusammenhang nicht besonders gut gewählt. Er ist eine Übersetzung des englischen Begriffs „Policy“, der in der Norm häufig verwendet wird und überwiegend als „Richtlinie“ oder „Leitlinie“ übersetzt wird. Diese Begriffe finde ich besser als Politik und ich habe bislang in meiner Arbeit auch überwiegend den Begriff „Leitlinie“ an dieser Stelle verwendet und darum bleibe ich auch in diesem Blogeintrag dabei.

Die Leitlinie zur Informationssicherheit oder Informationssicherheitsleitlinie (im Folgenden einfach Leitlinie genannt) definiert die Grundlage, die Ziele und die Rahmenbedingungen des Managementsystems. Sie enthält die Absichten und die Motivation des Top Managements zur Etablierung des Managementsystems. Die Veröffentlichung der Leitlinie gilt auch als Startschuss des Managementsystems. Inhaltlich sind die Anforderungen an die Leitlinie schnell erfüllt. Es gibt aber gute Gründe etwas mehr in die Leitlinie zu packen, als nur die Mindestanforderungen.

Read More

Führung und Verpflichtung – Teil 2

Mit Bezug zur Informationssicherheit und dem Informationssicherheits-Managementsystem muss die oberste Leitung, das Top Management, Führung und Verpflichtung zeigen. Die Norm teilt diese Anforderung in 8 Teilaufgaben. Die ersten 4 habe ich im letzten Teil bereits besprochen:

  • Politik und Ziele
  • Integration
  • Ressourcen
  • Bedeutung des ISMS

Aus diesen Teilaufgaben wird bereits deutlich an welcher Stelle und zu welchem Zweck sich das Top Management engagieren muss. Die weiteren Teilaufgaben erfordern ein noch deutlich gesteigertes Engagement des Top Managements.

Read More

Führung und Verpflichtung

Die Norm ISO/IEC 27001 beschreibt ein auf die Erfüllung von Zielen und Anforderungen sowie auf kontinuierliche Verbesserung ausgerichtetes Managementsystem. Die Anforderungen werden von den sogenannten interessierten Parteien bestimmt. Die Ziele werden vom Top Management vorgegeben. Bereits durch diese Vorgehensweise wird klar dass das Managementsystem einen Top-Down Ansatz verfolgt.

Führung und Verpflichtung

Auch die Bezeichnung Managementsystem lässt darauf schließen, denn Management hat die Bedeutung von steuern und lenken. Es muss also dann auch einen Steuerer und Lenker geben. Das kann eine Einzelperson (z.B. Geschäftsführer) oder ein Gremium (z.B. Vorstand) sein.

Read More

Schnittstellen und Abhängigkeiten

Niemand ist eine Insel. Diese Erkenntnis begleitete uns bereits in den vergangen Beiträgen zum Thema Kontext und Geltungsbereich. Bei der Definition des Geltungsbereichs sind neben den internen und externen Themen und den interessierten Parteien auch die Schnittstellen und Abhängigkeiten zu berücksichtigen. In diesem Beitrag geht es ebendiese Schnittstellen und Anhängigkeiten.

Read More

Geltungsbereich

Niemand ist eine Insel. Wie im vorherigen Beitrag beschrieben, ist es wichtig zu Beginn der ISMS Implementierung den Kontext zu analysieren. In diesem Beitrag geht es um die Frage, wie sich aus dem Kontext der Geltungsbereich ableitet, welche Optionen es dabei gibt und welche Auswirkungen die verschiedenen Optionen haben.

Read More

Kontext der Organisation

Niemand ist eine Insel. Auch ein Unternehmen oder eine Organisation ist keine Insel. Es gibt immer einen Kontext, ein Umfeld, Schnittstellen und Abhängigkeiten.Eine Organisation die ein Informationssicherheits-Managementsystem aufbauen möchte muss diese Themen berücksichtigen.

Die Norm ISO/IEC 27001 greift diese Themen richtigerweise gleich zu Beginn der Implementierung auf. In Kapitel 4.1 „Verstehen der Organisation und ihres Kontextes“ wird dazu gesagt: „Die Organisation muss externe und interne Themen bestimmten, die für ihren Zweck relevant sind und sich auf ihre Fähigkeiten auswirken, die beabsichtigten Ergebnisse ihres Informationssicherheits-Managementsystems zu erreichen“

Read More