No Description

2018-05-31_de__dsgvo_alles_schall_und_rauch.html 31KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469
  1. <!doctype html>
  2. <html>
  3. <head>
  4. <meta charset="utf-8">
  5. <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
  6. <title>DSGVO - Alles Schall und Rauch?</title>
  7. <link rel="stylesheet" href="reveal.js/css/reveal.css">
  8. <link rel="stylesheet" href="reveal.js/css/theme/black.css">
  9. <!-- Theme used for syntax highlighting of code -->
  10. <link rel="stylesheet" href="reveal.js/lib/css/zenburn.css">
  11. <!-- Printing and PDF exports -->
  12. <script>
  13. var link = document.createElement( 'link' );
  14. link.rel = 'stylesheet';
  15. link.type = 'text/css';
  16. link.href = window.location.search.match( /print-pdf/gi ) ? 'reveal.js/css/print/pdf.css' : 'revealjs/css/print/paper.css';
  17. document.getElementsByTagName( 'head' )[0].appendChild( link );
  18. </script>
  19. </head>
  20. <body>
  21. <div class="reveal">
  22. <div class="slides">
  23. <section><h2>DSGVO - Alles Schall und Rauch?</h2>
  24. <img class="fragment" src="imgs/dsgvo_alles_schall_und_rauch/stargate_command.png">
  25. </section>
  26. <section><h3>Speaker</h3>
  27. <p><span class="fragment">Name:<span> <span class="fragment">Simon<span> <span class="fragment current-visible">Lackerbauer<span><span class="fragment" /></p>
  28. <p class="fragment">Mehr ist mir nicht erlaubt zu sagen, und mehr ist euch nicht erlaubt zu wissen.</p>
  29. </section>
  30. <section><h3>Speaker</h3>
  31. <p>Simon Lackerbauer
  32. <small>
  33. <ul>
  34. <li>Operations Engineer by trade, jurist when nobody's looking</li>
  35. <li>Datenschutzbeauftragter Mayflower GmbH seit 2012</li>
  36. <li>Slides und Sonstiges: <a href="https://github.com/ciil">github.com/ciil</a></li>
  37. </ul>
  38. </small>
  39. </p>
  40. </section>
  41. <section>
  42. <section><h3>Rechtliche Grundlagen</h3>
  43. </section>
  44. <section><h3>Systematische Einordnung</h3>
  45. <ul>
  46. <li>früher: BDSG (deutsches Bundesgesetz)</li>
  47. <li>seit 25.05.2018: Datenschutz-Grundverordnung (DSGVO/GDPR) und BDSG-neu via DSAnpUG-EU<br>
  48. <small>voller Name: Verordnung (EU) 2016/679 des Europäischen Parlaments und des Rates vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, zum freien Datenverkehr und zur Aufhebung der Richtlinie 95/46/EG</small>
  49. </li>
  50. </ul>
  51. </section>
  52. <section><h3>Was ist eine EU-Verordnung?</h3>
  53. <ul>
  54. <li>Es gibt EU-Richtlinien und EU-Verordnungen</li>
  55. <li>Richtlinien sind ... exactly what it says on the tin. Mehr oder weniger grobe Richtlinien, die jeder EU-Mitgliedsstaat selbst implementiert</li>
  56. <li>Verordnungen gelten direkt in allen Mitgliedsstaaten (und gem. EWR-Abkommen nach Inkorporierung auch in Island, Liechtenstein und Norwegen)</li>
  57. <li>Alle 24 Versionen in den <a href="https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679">24 Amtssprachen</a> gelten gleichberechtigt überall (what could possibly go wrong?)</li>
  58. </ul>
  59. </section>
  60. <section><h3>Und deshalb ändert sich jetzt alles?</h3>
  61. </section>
  62. <section><h3>Antwort: Nein.</h3>
  63. <p class="fragment"><small>Ein Großteil des bisherigen Datenschutzrechts gilt im Grundsatz fort. Die allgemeine Aufbruchstimmung rührt mehr daher, dass viele Unternehmen vor Inkrafttreten der DSGVO geltendes Recht verletzt haben, dies aber nicht geahndet wurde. Die allgemeine Befürchtung ist nun, dass Verstöße unter der DSGVO schneller, intensiver und mit Konsequenzen verfolgt werden.</small>
  64. <p class="fragment"><small>Weiterhin sind dort, wo sich tatsächlich Änderungen ergeben, diese häufig noch komplex oder schwer interpretierbar. Dadurch entsteht Rechtsunsicherheit.</small></p>
  65. </section>
  66. <section><h3>Aufbau DSGVO</h3>
  67. <ul>
  68. <li>Am Anfang stehen 173 sog. "Erwägungsgründe"</li>
  69. <li>Dann gibt es 99 Artikel in 11 Kapiteln</li>
  70. <li>Die "wichtigsten" Abschnitte für Normalsterbliche: Kapitel 2 ("Grundsätze") und Kapitel 4 ("Verantwortlicher und Auftragsverarbeiter")</li>
  71. <li>Eine recht schöne Übersicht über die deutschen und englischen Fassungen der DSGVO gibt es unter <a href="https://dsgvo-gesetz.de">dsgvo-gesetz.de</a></li>
  72. </ul>
  73. </section>
  74. <section><h3>Geltungsbereich</h3>
  75. <ul>
  76. <li>Datenschutzrecht bezieht sich <b>immer und ausschließlich</b> auf "personenbezogene Daten"</li>
  77. <li>Personenbezug liegt aber fast immer vor, wenn zumindest <b>irgendjemand</b> in der Lage ist, ein Datum einer natürlichen Person zuzuordnen (bekanntes Beispiel: IP-Adressen)</li>
  78. <li>Gilt für alle Verarbeitungen, die entweder in der EU stattfinden, oder die Daten von EU-Bürgern betreffen.</li>
  79. </ul>
  80. </section>
  81. <section><h3>Und was ändert sich jetzt wirklich?</h3>
  82. </section>
  83. <section><h3>Verarbeitung</h3>
  84. <ul>
  85. <li>bezeichnet "[...] das Erheben, das Erfassen, die Organisation, das Ordnen, die Speicherung, die Anpassung oder Veränderung, das Auslesen, das Abfragen, die Verwendung, die Offenlegung durch Übermittlung, Verbreitung oder eine andere Form der Bereitstellung, den Abgleich oder die Verknüpfung, die Einschränkung, das Löschen oder die Vernichtung"</li>
  86. <li>(vgl. BDSG a.F.: Erhebung, Verarbeitung, Nutzung)</li>
  87. </ul>
  88. </section>
  89. <section><h3>Datenschutzbeauftragter</h3>
  90. <ul>
  91. <li>Für die meisten kleinen und mittleren Unternehmen in Deutschland laut DSGVO nicht mehr vorgesehen</li>
  92. <li class="fragment">Aber: BDSG n.F. führt die alten deutschen Regelungen mit mehr als 9 Beschäftigten fort (§ 38 BDSG)</li>
  93. </ul>
  94. </section>
  95. <section><h3>Frage: Muss ich bei meiner App die DSGVO beachten?</h3>
  96. </section>
  97. <section><h3>Antwort: Ja.</h3>
  98. <p class="fragment"><small>Ausnahme: Statischer Content ohne Interaktionsmöglichkeit und keinerlei Logging.</small></p>
  99. </section>
  100. <section><h3>Frage: Aber was wir entwickeln, wird nur intern von Mitarbeitern des Kunden genutzt. Da gilt die DSGVO also dann nicht?</h3>
  101. </section>
  102. <section><h3>Antwort: Doch.</h3>
  103. <p class="fragment"><small>Mitarbeiterdaten sind personenbezogene Daten. Selbst Kürzel/IDs/etc. sind personebezogene Daten, weil der Kunde sicher irgendwo die Möglichkeit hat, die ID einem Mitarbeiter zuzuordnen.</small></p>
  104. </section>
  105. <section><h3>Weitere Fragen zum Geltungs-/Anwendungsbereich?</h3>
  106. </section>
  107. </section>
  108. <section>
  109. <section><h3>Grundsätze des Datenschutzrechts</h3>
  110. </section>
  111. <section><h3>Verbot mit Erlaubnisvorbehalt</h3>
  112. <ul>
  113. <li>Jede Verarbeitung personenbezogener Daten ist eigentlich verboten.</li>
  114. <li>Dieser Grundsatz hat zwei Ausnahmen:
  115. <ul>
  116. <li>Die Person hat eingewilligt</li>
  117. <li>Ein Gesetz erlaubt die Verarbeitung</li>
  118. </ul>
  119. </li>
  120. <li>Praktisch keine Änderung zu bisher</li>
  121. <li class="fragment">Klassischer Fall der gesetzlichen Erlaubnis: Daten sind nötig zur Vertragserfüllung (Bankdaten, Adresse, etc. bei Versandhandel)</li>
  122. </ul>
  123. </section>
  124. <section><h3>Datenschutzgrundsätze aus Art. 5</h3>
  125. <ul>
  126. <li>Zweckbindung</li>
  127. <li>Transparenz</li>
  128. <li>Datenminimierung</li>
  129. <li>Richtigkeit</li>
  130. <li>Speicherbegrenzung</li>
  131. <li>Integrität und Vertraulichkeit</li>
  132. <li>Rechenschaftspflicht</li>
  133. <li class="fragment">(Kein Direkterhebungsgrundsatz mehr!)</li>
  134. </ul>
  135. </section>
  136. <section><h3>Zweckbindung</h3>
  137. <ul>
  138. <li><b>Vor</b> dem Sammeln von personenbezogenen Daten muss klar sein, für was die Daten erhoben werden</li>
  139. <li>Gilt insbesondere, wenn die Daten aufgrund einer Einwilligung verarbeitet werden</li>
  140. <li>Die Zweckbindung gilt aber auch für aufgrund gesetzlicher Erlaubnis erhobene Daten</li>
  141. <li>In der Regel nicht Aufgabe des Dienstleisters, darauf zu achten</li>
  142. </ul>
  143. </section>
  144. <section><h3>Transparenz</h3>
  145. <ul>
  146. <li>Der Grund für die 400 Mails zum Thema, die jeder von uns über die letzten paar Wochen bekommen hat</li>
  147. <li>Weiter ausgeführt in Artt. 12ff. DSGVO</li>
  148. <li>Man muss vor der Verarbeitung betroffene Personen ausführlich, klar, verständlich, einfach unterrichten</li>
  149. </ul>
  150. </section>
  151. <section><h3>Datenminimierung</h3>
  152. <ul>
  153. <li>Nur die Daten sammeln, die man unbedingt für die Zweckerfüllung braucht</li>
  154. <li>Grober Richtwert der oberen Grenze des Datensammelns selbst mit Einwilligung</li>
  155. <li>Ja, das macht Anwendungsbereiche wie ML nicht unbedingt einfacher, wo man anfangs häufig gar nicht weiß, was die interessantesten Komponenten sind</li>
  156. </ul>
  157. </section>
  158. <section><h3>Richtigkeit</h3>
  159. <ul>
  160. <li>Man könnte denken, dass veraltete Daten auch dem Datenschutz dienen (alte Adressen erschweren das Tracking, etc.)</li>
  161. <li>Die DSGVO sieht aber vor, dass personenbezogene Daten, <b>wenn</b> sie rechtmäßig gesammelt werden dürfen, auch richtig und aktuell sein müssen</li>
  162. <li>Ergo: schon von User-Seite her die Änderung und Löschen möglichst einfach machen</li>
  163. <li>Nicht: "um dieses Feld zu ändern, bitte Mail an Support schreiben"</li>
  164. </ul>
  165. </section>
  166. <section><h3>Speicherbegrenzung</h3>
  167. <ul>
  168. <li>Nur so lange speichern, wie es für die Zweckerfüllung unbedingt erforderlich ist</li>
  169. <li>Wenn in Verbindung stehende Daten darüber hinaus archiviert werden sollen, anonymisieren</li>
  170. </ul>
  171. </section>
  172. <section><h3>Exkurs: anonymisierte Daten</h3>
  173. <ul>
  174. <li>Zuordnung zu realer Person ist nur mit unverhältnismäßig großem Aufwand/Vorwissen möglich</li>
  175. <li>Pseudonymisierung ist keine Anonymisierung</li>
  176. </ul>
  177. </section>
  178. <section><h3>Integrität und Vertraulichkeit</h3>
  179. <ul>
  180. <li>Das ist der Punkt, welcher durch die "technischen und organisatorischen Maßnahmen" verwirklicht werden kann</li>
  181. <li>Angemessener Schutz der datenverarbeitenden Systeme</li>
  182. <li>Bei Auftragsverarbeitung: alle vorigen Punkte liegen größtenteils im Bereich des Auftraggebers, <b>hier</b> ist häufig der Auftragnehmer mitverantwortlich!</li>
  183. </ul>
  184. </section>
  185. <section><h3>Rechenschaftspflicht</h3>
  186. <ul>
  187. <li>Art. 5 Abs. 2: "Der Verantwortliche ist für die Einhaltung des Absatzes 1 verantwortlich und muss dessen Einhaltung nachweisen können"</li>
  188. <li>Heißt in der Regel: Dokumentation von Prozessen und deren Einhaltung</li>
  189. <li>Je leichter irgendwas technisch nachweisbar ist, desto besser für alle</li>
  190. <li>Beispiel: wenn es heißt, dass nur Pubkey-Auth für SSH-Zugänge genutzt wird, dann PW-Auth abschalten. Sowas lässt sich auch einfach testen.</li>
  191. </ul>
  192. </section>
  193. </section>
  194. <section>
  195. <section><h3>Integrität und Vertraulichkeit</h3>
  196. </section>
  197. <section><h3>Moderne Passwortrichtlinien</h3>
  198. <img src="imgs/dsgvo_alles_schall_und_rauch/password_strength.png" width="60%"><br />
  199. <small><a href="https://www.xkcd.com/936/">XKCD #936: Password Strength (CC BY-NC)</a></small>
  200. </section>
  201. <section><h3>Moderne Passwortrichtlinien</h3>
  202. <ul>
  203. <li>Für fast alles: <b>Passwortmanager</b></li>
  204. <li>Sonst: ein paar Pass<b>phrasen</b> für Disk-Encryption, GPG-Keys und als Masterpasswort für PW-Manager</li>
  205. <li>lieber einfach zu merken und lang als mit vielen Sonderzeichen und kurz</li>
  206. <li>2FA für wichtige Services</li>
  207. </ul>
  208. </section>
  209. <section><h3>Display-Sichtschutz für Bahn und Flugzeug</h3>
  210. <ul>
  211. <li>Streng genommen wäre schon das öffentliche Surfen im internen Wiki ein Datenschutzverstoß, weil da häufig Realnamen drin stehen können</li>
  212. <li>Zusätzlich: automatisch und/oder manuell Rechner sperren, sobald man den Platz verlässt</li>
  213. </ul>
  214. </section>
  215. <section><h3>Firmware</h3>
  216. <ul>
  217. <li>Intel AMT und ähnliches deaktivieren</li>
  218. <li>Sich generell im Klaren darüber sein, zu was euer BIOS so in der Lage ist</li>
  219. </ul>
  220. </section>
  221. <section><h3>Betriebssystem und Updates</h3>
  222. <ul>
  223. <li>Windows und Mac: Aktuell mit Auto-Update</li>
  224. <li>Linux: regelmäßig auf aktuellen Stand bringen</li>
  225. <li>Alle Zugriffe idR mit normalen User-Rechten, sudo nur wenn nötig</li>
  226. </ul>
  227. </section>
  228. <section><h3>Festplattenverschlüsselung</h3>
  229. <ul>
  230. <li>Windows Pro: Bitlocker</li>
  231. <li>Mac: FileVault</li>
  232. <li>Linux: z.B. cryptsetup mit luks</li>
  233. </ul>
  234. </section>
  235. <section><h3>Backup</h3>
  236. <ul>
  237. <li>gut: vorhanden</li>
  238. <li>besser: verschlüsselt und offsite</li>
  239. </ul>
  240. </section>
  241. </section>
  242. <section>
  243. <section><h3>Einschätzung des Kunden(projekts)</h3>
  244. </section>
  245. <section><h3>Datenschutzbeauftragter des Kunden</h3>
  246. <ul>
  247. <li>Wer ist das und wie erreicht man ihn?</li>
  248. <li>Informationen im Intranet bereithalten</li>
  249. </ul>
  250. </section>
  251. <section><h3>Produktiv-Daten</h3>
  252. <ul>
  253. <li>Wer hat Kontrolle?</li>
  254. <li>Wo liegen die Daten?</li>
  255. <li>Immer im Hinterkopf behalten: es dreht sich alles weiterhin rein um <b>personenbezogene</b> Daten.</li>
  256. <li>(Das bedeutet natürlich nicht, dass man Vertragspflichten zur Geheimhaltung ignorieren kann.)</li>
  257. </ul>
  258. </section>
  259. <section><h3>Berechtigungen des Teams</h3>
  260. <ul>
  261. <li>Wer vergibt die Berechtigungen?</li>
  262. <li>Gibt es innerhalb des Teams ein gemeinsames Verständnis, nach welchem Prozess an die Produktiv-Daten gegangen wird?</li>
  263. </ul>
  264. </section>
  265. <section><h3>Betreibt man als Auftragnehmer irgendwelche Systeme für den Kunden?</h3>
  266. <ul>
  267. <li>Sind da zB Testdaten drauf? Wie sehen die aus?</li>
  268. <li>Betreibt man vielleicht sogar Produktivsysteme für Kunden?</li>
  269. </ul>
  270. </section>
  271. <section><h3>Freelancer im Team?</h3>
  272. <ul>
  273. <li>Müssen als Unterauftragnehmer in der Regel im Vertrag angegeben sein und müssen mit dem Hauptauftragnehmer wiederrum einen Vertrag über die Auftragsverarbeitung geschlossen haben</li>
  274. </ul>
  275. </section>
  276. <section><h3>Homeoffice?</h3>
  277. <ul>
  278. <li>Was sagt der AV-Vertrag zu Arbeiten außerhalb von Arbeitgeber- oder Kunden-Offices?</li>
  279. <li>(Das deutsche Recht würde ziemlich sicher ein Zugangsrecht des Auftraggebers zu Privatwohnungen verneinen. Aber ein AV-Vertrag kann vorsehen, dass Homeoffice nicht möglich sein soll.)</li>
  280. </ul>
  281. </section>
  282. <section><h3>Allgemein</h3>
  283. <ul>
  284. <li>AV-Vertrag ins Intranet</li>
  285. <li>Das Team sollte sich ein bisschen damit beschäftigt haben (genauso wie mit dem eigentlichen Projektvertrag)</li>
  286. <li>TL, SM, PO sollte das ganze ein bisschen genauer gelesen haben</li>
  287. </ul>
  288. </section>
  289. </section>
  290. <section>
  291. <section><h3>Technische und organisatorische Maßnahmen</h3>
  292. </section>
  293. <section><h3>Rechtsgrundlage DSGVO</h3>
  294. <ul>
  295. <li>Relevante Norm: Art. 32 DSGVO; Inhalt:</li>
  296. <ul>
  297. <li>Pseudonymisierung und Verschlüsselung personenbezogener Daten (lit a)</li>
  298. <li>Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste (lit b)</li>
  299. <li>Backup- und Wiederherstellungsfähigkeit (lit c)</li>
  300. <li>regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der Maßnahmen (lit d)</li>
  301. </ul>
  302. </ul>
  303. </section>
  304. <section><h3>Verhältnis zu Anlage zu § 9 Satz 1 BDSG-alt</h3>
  305. <ul>
  306. <li>Zutrittskontrolle (neu: lit b)</li>
  307. <li>Zugangskontrolle (neu: lit a, b)</li>
  308. <li>Zugriffskontrolle (neu: lit b)</li>
  309. <li>Weitergabekontrolle (neu: lit b)</li>
  310. <li>Eingabekontrolle (neu: lit b)</li>
  311. <li>Auftragskontrolle (neu: Art. 32 Abs. 4)</li>
  312. <li>Verfügbarkeitskontrolle (neu: lit c)</li>
  313. <li>Trennungsgebot (neu: lit b)</li>
  314. </ul>
  315. </section>
  316. <section><h3>Zutrittskontrolle</h3>
  317. <ul>
  318. <li>Hier geht es um den physischen Zugang zum Office. Ist abgeschlossen oder, wenn nicht, jemand am Empfang? Ist der Serverraum (sofern da Daten des Auftraggebers lagern) noch extra abgeschlossen?</li>
  319. </ul>
  320. </section>
  321. <section><h3>Zugangskontrolle</h3>
  322. <ul>
  323. <li>Rechner ist gesperrt, wenn grade keiner dran ist</li>
  324. <li>Rechner ist verschlüsselt, wenn er geklaut wird</li>
  325. </ul>
  326. </section>
  327. <section><h3>Zugriffskontrolle</h3>
  328. <ul>
  329. <li>Hier geht es um <i>berechtigten</i> Zugriff: Wenn jemand schon darf, <b>was</b> darf er dann alles?</li>
  330. <li>letztlich: Berechtigungskonzept</li>
  331. </ul>
  332. </section>
  333. <section><h3>Weitergabekontrolle</h3>
  334. <ul>
  335. <li>Transportweg-Sicherungen: idR geht es hier also um verschlüsselte Verbindung auf Kundensysteme, SSH, VPN, TLS, etc.</li>
  336. <li>Im Fall des tatsächlich physischen Transports (zB im Falle, dass ihr Screenshots/Logs aus Produktion lokal gespeichert habt fürs Debugging) greift wieder die Festplatten-Verschlüsselung</li>
  337. </ul>
  338. </section>
  339. <section><h3>Eingabekontrolle</h3>
  340. <ul>
  341. <li>Wenn ihr grundsätzlich in der Lage seid, personenbezogene Daten beim Kunden auch zu ändern (zB Zugriff auf Produktion), gibt es dann ein Logging dieser Änderungen? Kann also jemand im Nachhinein nachvollziehen, wer und wann irgendwelche Daten geändert hat?</li>
  342. </ul>
  343. </section>
  344. <section><h3>Auftragskontrolle</h3>
  345. <ul>
  346. <li>Einerseits, auf Auftragnehmer-Seite: sind die Mitarbeiter alle geschult und auf den Datenschutz verpflichtet?</li>
  347. <li>Andererseits, im Zusammenspiel mit Auftraggeber: werden Weisungen, die mit der Datenverarbeitung zu tun haben, ordentlich dokumentiert?</li>
  348. </ul>
  349. </section>
  350. <section><h3>Verfügbarkeitskontrolle</h3>
  351. <ul>
  352. <li>Backup- und Restore-Konzept. Ist für den Auftragnehmer nur interessant, wenn er für den Auftraggeber tatsächlich Systeme bereitstellt, auf denen Produktivdaten verarbeitet werden.</li>
  353. <li>(Backups von Geschäftsdaten machen aber grundsätzlich auch ohne DSGVO Sinn.)</li>
  354. </ul>
  355. </section>
  356. <section><h3>Trennungsgebot</h3>
  357. <ul>
  358. <li>Unterschiedliche Daten (sei es aufgrund von Zweckbindung, besondere Kategorien von Daten etc.) müssen getrennt verarbeitet werden. Es reicht hier bereits eine logische Trennung (gleiche DB, verschiedene Tabellen). Liegt auch idR vollständig im Verantwortungsbereich des Auftraggebers.</li>
  359. </ul>
  360. </section>
  361. </section>
  362. <section><h3>Slides</h3>
  363. Die jeweils aktuellen Slides zu diesem Vortrag sind auf GitHub verfügbar: <a href="https://github.com/ciil/talks">github.com/ciil/talks</a>
  364. </section>
  365. <section>
  366. <section><h3>Bonus-Slides</h3>
  367. </section>
  368. <section><h3>Kontaktformular ohne Einwilligung?</h3>
  369. <ul>
  370. <ul>
  371. <li>Ich kann Daten natürlich auch aufgrund eines anderen Erlaubnistatbestandes (Art. 6 I lit. b-f) verarbeiten.</li>
  372. <li>Unterschied: eine Einwilligung gilt idR erstmal unbegrenzt (bis zum Widerruf)</li>
  373. <li>Bei allen Erlaubnistatbeständen: Achtung Zweckbindung</li>
  374. <li>Wenn der Zweck wegfällt, unterliegen die Daten auf einmal einer Löschverpflichtung</li>
  375. </ul>
  376. </ul>
  377. </section>
  378. <section><h3>Eventanmeldung ohne Einwilligung?</h3>
  379. <ul>
  380. <ul>
  381. <li>Auch hier grundsätzlich braucht man grundsätzlich keine Einwilligung.</li>
  382. <li>Lässt sich erstmal schön auf Art. 6 I lit. b stützen</li>
  383. <li>Sobald das Event rum ist, müssen theoretisch alle Daten gelöscht sein (sind nicht mehr notwendig für die Durchführung)</li>
  384. <li class="fragment">(Eine Abschlussmail mag zulässig sein.)</li>
  385. </ul>
  386. </ul>
  387. </section>
  388. <section><h3>Stete Grundsatzfrage: Was will ich denn damit anstellen?</h3>
  389. <ul>
  390. <ul>
  391. <li>Zweckbindung ist das A und O</li>
  392. <li>Verhindert immer genau das "Ich hab die Daten ja schon, also kann ich jetzt Werbung machen"</li>
  393. <li>Teileinwilligungen sind ... möglich, aber recht schwierig richtig hinzubekommen</li>
  394. </ul>
  395. </ul>
  396. </section>
  397. <section><h3>Ist Direktwerbung immer ein berechtigtes Interesse?</h3>
  398. <ul>
  399. <ul>
  400. <li>Erwägungsgründe Nr. 47 S. 7 und Nr. 70 sprechen von "Direktwerbung" als berechtigtem Interesse</li>
  401. <li>Extra Widerspruchsrecht für Direktwerbung: Art. 21 II und III</li>
  402. <li>Dass nun jegliche Daten gesammelt werden dürften, um damit unerwünschte Werbung an Betroffene zu schicken ist selbstverständlich nicht Intention der DSGVO</li>
  403. <li class="fragment">DSGVO ist keine gesetzgeberische Meisterleistung</li>
  404. </ul>
  405. </ul>
  406. </section>
  407. <section><h3>Allgemein: Art. 6 I lit. f</h3>
  408. <ul>
  409. <ul>
  410. <li>Zwei Meinungen: 1. Super Auffangtatbestand!! 2. Viel zu weit, eng auszulegen!</li>
  411. <li>Bis jetzt eigentlich kein Mittelweg erkennbar</li>
  412. <li>Interessenabwägung gerade im werblichen Bereich anders bei Verbrauchern und gewerblichen Kunden?</li>
  413. <li>Den Unterschied automatisiert erkennen wahrscheinlich schwierig</li>
  414. </ul>
  415. </ul>
  416. </section>
  417. <section><h3>Eventfotographie zu PR-Zwecken</h3>
  418. <ul>
  419. <ul>
  420. <li>Verhältnis zw. KUG und DSGVO gerade Thema heißer Debatten</li>
  421. <li>Wohl noch einer der Punkte, an denen Art. 6 I lit. f am ehesten greifen könnten</li>
  422. <li>In jedem Fall: zumindest Informationspflichten: bei E-Mail-Bestätigung/Online-Anmeldung auch kein unverhältnismäßig großer Aufwand (EG 62)</li>
  423. <li>Widerspruch anders als bei KUG wohl stets möglich</li>
  424. </ul>
  425. </ul>
  426. </section>
  427. <section><h3>Eventfotographie zu PR-Zwecken (Teil 2)</h3>
  428. <ul>
  429. <ul>
  430. <li>Je kleiner die Veranstaltung, desto stärker müssen Regelungen beachtet werden</li>
  431. <li>Rechte von Personen, die offensichtlich nicht fotographiert werden wollen, beachten</li>
  432. <li>Möglichst keine Namensnennung am Foto (Foto trotzdem pers.b. Daten)</li>
  433. <li>Situation beachten, keine Fotos von Personen mit Bier in der Hand etc.</li>
  434. </ul>
  435. </ul>
  436. </section>
  437. <section><h3>Eventfotographie zu PR-Zwecken (Teil 3)</h3>
  438. <ul>
  439. <ul>
  440. <li>Eine intensivere Ausarbeitung und stets aktualisierte Einschätzung zum Thema <a href="https://lackerbauer.com/blog/2018-05-27_event_fotografie_unter_der_datenschutz_grundverordnung.html">findet sich in meinem Blog</a>.</li>
  441. </ul>
  442. </ul>
  443. </section>
  444. </section>
  445. </div>
  446. </div>
  447. <script src="reveal.js/lib/js/head.min.js"></script>
  448. <script src="reveal.js/js/reveal.js"></script>
  449. <script>
  450. // More info about config & dependencies:
  451. // - https://github.com/hakimel/reveal.js#configuration
  452. // - https://github.com/hakimel/reveal.js#dependencies
  453. Reveal.initialize({
  454. dependencies: [
  455. { src: 'reveal.js/plugin/markdown/marked.js' },
  456. { src: 'reveal.js/plugin/markdown/markdown.js' },
  457. { src: 'reveal.js/plugin/notes/notes.js', async: true },
  458. { src: 'reveal.js/plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } }
  459. ]
  460. });
  461. </script>
  462. </body>
  463. </html>