Privacy ist ein Thema, das immer wieder zur Sprache kommt. Die wiederholte Berichterstattung über missbräuchliche Datenverarbeitung und Data-Breaches einerseits und die Digitale Transformation, bei der Benutzer sensitive Daten in der Cloud platzieren andererseits, veranlassen Kunden dazu immer höhere Ansprüche an den Schutz ihrer Daten zu stellen. Mit der GDPR bzw. DSGVO kommen noch die hohen rechtlichen Anforderungen hinzu.

Informationssicherheit und Privacy

Viele Firmen sind aktuell verunsichert, ob sie mit ihren IT-Security-Massnahmen und einem allfällig vorhandenen ISMS bereits die Anforderungen an den Datenschutz erfüllen. Je nach Umfeld müssen Firmen dem Schweizer DSG, der DSGVO sowie noch weiteren branchenspezifischen Vorgaben gerecht werden. In unserer Artikelserie zur Privacy beantworten wir folgende Fragen:

• Wie sieht der Weg zu einem Schutz der Privatsphäre aus?
• Auf welchen Standards können Firmen aufbauen?
• Mit welchen Werkzeugen können die Massnahmen Dritten gegenüber dokumentieren und ausgewiesen werden?

Bei der Privacy liegt das Ziel, so wie es das Schweizer DSG formuliert, im «Schutz der Persönlichkeit und der Grundrechte von Personen, über die Daten bearbeitet werden.». Die Informationssicherheit hat zum Ziel, Informationen zu schützen. Die beiden Themen sind nicht identisch, passen jedoch wunderbar zusammen: Die Informationssicherheit lernt durch die konzeptionelle Arbeit in der Privacy besser zu verstehen, welche Schutzbedürfnisse sie zu erfüllen hat.

In der Privacy stellt sich auch die Frage, welche Daten gesammelt werden und wozu. Privacy hat somit Einfluss auf die Definition des Business-Prozesses und der zu erbringenden Dienstleistung (was wird gesammelt, wozu und warum). Schlussendlich arbeiten die Fachgebiete Hand in Hand: Der Prozess muss die Anforderungen der Privacy erfüllen; die Informationssicherheit muss sowohl den Prozess als auch die Daten zu schützen. Das Eine geht nicht ohne das Andere.

Das ISO Privacy Framework

ISO definiert im Standard 29100:2011 ein «Privacy Framework». Es stellt ein grundlegendes Framework sowie Terminologie zum Umgang mit PII dar. Letzteres − die Personally Identifiable Information − bezieht sich auf alle Formen von Daten durch die eine Person einerseits identifizierbar wird, andererseits aber auch Rückschlüsse auf ihr Verhalten oder die persönliche Situation gezogen werden können. Die Formulierung sei an dieser Stelle bewusst offengehalten. Der Standard selber enthält längere Ausführungen darüber, wie Planer in ihrem Vorhaben die relevanten Daten identifizieren können.

Ein Beispiel: PII kann z. B. eine Kreditkarten-, Telefon-, oder Kundennummer sowie zugehörige Transaktionsdaten sein, die einer Person zuzuordnen sind. Es ist dabei unerheblich, ob diese Person der eigene Kunde ist. Auch die Daten, die man über Mitarbeiter seiner Kunden oder Kunden der Kunden hat, können relevant sein. Für einen IT-Dienstleister kann somit sein Ticketing-System relevant werden, sobald dort ungefragt solche Daten in ein Ticket reinkopiert werden.

Involvierte Stellen und der Datenaustausch

Der Standard teilt die Datenverarbeitung in vier Stellen auf, wie die nachfolgende Grafik zeigt. Der PII Principal ist die natürliche Person, die identifizierbar wird. Der PII Controller entscheidet wieso die Daten erhoben und verarbeitet werden müssen und auch wie. Er ist aus rechtlicher Sicht verantwortlich für die Einhaltung der Vorschriften.

Ein PII Controller kann auch einen PII Processor als Stellvertreter bestimmen, der an seiner statt oder unterstützend gemäss seinen Anweisungen die Datenverarbeitung vornimmt. Die drei erwähnten Stellen sind vollständig vernetzt, d. h. PII können frei hin und her fliessen.

Es ist dabei unerheblich, ob der PII Principal eine vertragliche Beziehung zum PII Controller oder PII Processor hat, denn schlussendlich obliegt den beiden die Verantwortung über sämtliche PII, die sie haben, unabhängig vom eingehenden Kanal, und beide müssen sicherstellen, dass sie gemäss den vereinbarten Richtlinien handeln. Es muss also auch geklärt sein, was passiert, wenn einem ungefragt Daten über Dritte zugeschickt werden.

Relevant sind auch alle Drittstellen (3rd Parties), denn sie erhalten PII und dürfen sie verarbeiten, handeln jedoch nicht nach Anweisung des PII Controllers. Sie bauen bei sich ein eigenes Privacy Framework auf und werden damit selber zum PII Controller − allerdings ohne Einblick durch den ersten, ursprünglichen PII Controller.

Dies bedeutet, dass die PII eine Kette von Privacy Frameworks durchlaufen können, bis sie schlussendlich irgendwo landen und weder der ursprüngliche PII Controller noch der PII Principal mehr wissen, wie genau sie verarbeitet werden. Wer seinen Kunden einen starken Schutz der Privatsphäre verspricht, sollte daher schon von Beginn an überlegen, welche Drittstellen involviert sein sollen und vor allem warum.

Die elf Prinzipien in der Privatsphäre in der Datenverarbeitung

Der PII Controller ist zuständig zu entscheiden, weshalb und wie PII verarbeitet werden. Im Rahmen der Entscheidung zur Abwicklung der Verarbeitung obliegt ihm auch die Anwendung der «privacy principles» aus dem ISO 29100:2011 Standard:

1. Consent and Choice: PII müssen nach «opt-in» Verfahren erhoben werden − d. h. der PII Principal kann über ein einfaches Verfahren seine Zustimmung erteilen oder entziehen.
2. Purpose Legitimacy and Specification: Die Erhebung der Daten erfolgt nur soweit es rechtlich zulässig ist. Der PII Principal erhält eine einfache Erklärung über den Zweck der Erhebung und Verarbeitung.
3. Collection Limitation: PII sollen nur soweit erhoben werden, wie es zur Erbringung der Dienstleistung notwendig ist. Der PII Controller muss den Zweck der Erhebung erklären können.
4. Data Minimization: In Verarbeitungsprozessen sollen nur die Daten berücksichtigt werden, die notwendig sind. Daten sollen also nicht grundsätzlich überallhin verteilt werden, sondern nur dorthin, wo auch die relevanten Prozesse ablaufen.
5. Use, Retention and Disclosure Limitation: Die Übertragung der PII, sowie auch die Weitergabe an Dritte, darf nur soweit erfolgen, wie es zur Erbringung der jeweiligen Dienstleistung notwendig ist.
6. Accuracy and Quality: Die Qualität muss sichergestellt sein − d. h. keine falschen oder abgelaufenen Daten gesammelt werden − insbesondere in den Fällen, in denen dem PII Principal durch falsche Daten ein Schaden entstehen kann.
7. Openness, Transparency and Notice: Die PII Principals haben Zugriff auf die Richtlinien und Vorgaben des PII Controllers, wobei diese klar und einfach verständlich formuliert sein müssen.
8. Individual Participation and Access: Die PII Principals haben Einsicht in die Daten und dürfen Korrekturen und die Entfernung verlangen. Dies muss kostenlos und nach angemessener Authentifizierung erfolgen.
9. Accountability: Die Verantwortung zur Umsetzung der Massnahmen zum Schutz der PII muss definiert sein und die Massnahmen und deren Effektivität ist regelmässig zu prüfen.
10. Information Security: Alle involvierten Systeme müssen auf technischer Ebene geschützt sein, z. B. durch Anwendung von Controls aus Anhang A von ISO 27001 (bzw. ISO 27002) und einem standardisierten Verfahren zur Risikoanalyse.
11. Privacy Compliance: Die beteiligten Stellen müssen nachweisen, dass sie die Vorgaben (u. a. Policy und rechtlichen Vorgaben) einhalten und, soweit es sinnvoll ist, regelmässige Audits durchführen.

Der PII Controller muss veranlassen, dass die relevanten Fachkräfte und Geschäftsverantwortlichen sich mit diesen Prinzipien auseinandersetzen. Er ist auch dafür verantwortlich, dass die Vorgaben und Entscheide dokumentiert sind und die beauftragten PII Processors diese umsetzen.

Wieso das wichtig ist

Diese elf Prinzipien der Privacy haben keine direkte Entsprechung in der IS. Entscheide über die Vertraulichkeit, Integrität und Verfügbarkeit bedeuten per se noch keinen Entscheid über den erwünschten Schutz der PII Principals.

Die Privacy-Prinzipien sind vielmehr etwas, das parallel zu der Informationssicherheit angewendet werden muss. Sie sind gesondert zu eruieren und zu beurteilen. Bei einem Projekt muss beides, sowohl die Anforderungen der IS als auch der Privacy, berücksichtigt und miteinander koordiniert werden.

Ausblick

Der nächste Artikel unserer Blogserie wird aufzeigen, wie durch ein Privacy Impact Assessment (PIA) diese Anforderungen strukturiert identifiziert und beurteilt werden können.