4. Datenschutz und Recht

Datenschutz und Recht

Datenschutz kommt in Projekten meistens am Schluss, in Gestalt einer kopierten Datenschutzerklärung. Das ist die teure Reihenfolge. Recht ist eine Entwurfsvorgabe, und sie steht am Anfang, weil sie bestimmt, welche Felder Ihre Tabellen überhaupt haben.

Der Satz, um den es geht: Was nicht erhoben wird, muss nicht geschützt, nicht gelöscht, nicht herausgegeben und im Ernstfall nicht gemeldet werden. Datensparsamkeit ist damit auch die billigste Sicherheitsmaßnahme, die es gibt. Ein Feld, das es nicht gibt, taucht in keinem Leck auf.

Diese Woche erfassen Sie, was Ihr Projekt tatsächlich verarbeitet, ordnen jeder Verarbeitung eine Grundlage zu, bauen Löschung und Auskunft als Funktion und schreiben die Pflichttexte, die zu Ihrer Anwendung passen und nicht zu einer anderen.

Keine Rechtsberatung

Dieses Kapitel vermittelt das, was Entwicklerinnen und Entwickler kennen müssen, um rechtskonform zu bauen und die richtigen Fragen zu stellen. Es ersetzt keine juristische Beratung, und im Zweifel entscheidet nicht Ihr Gefühl, sondern eine Fachperson.

Grundbegriffe

Personenbezogene Daten

Personenbezogen ist alles, was sich auf eine bestimmbare Person beziehen lässt. Der Begriff ist weiter, als die meisten annehmen: Name und Mailadresse natürlich, aber auch IP-Adresse, Cookie-Kennung, Gerätekennung, Standort, Buchungshistorie und das Foto, auf dem jemand erkennbar ist.

Besondere Kategorien sind noch strenger geschützt: Gesundheit, Herkunft, Religion, Gewerkschaftszugehörigkeit, politische Meinung, Sexualleben, biometrische Daten. In einem Schulprojekt haben sie in aller Regel nichts verloren. Wer sie doch braucht, braucht eine belastbare Grundlage und meistens eine Folgenabschätzung dazu.

Pseudonymisiert heißt: Der Name ist durch eine Kennung ersetzt, die Zuordnung liegt woanders. Das bleibt personenbezogen und damit im Anwendungsbereich der DSGVO. Anonym heißt: Die Zuordnung ist für niemanden mehr herstellbar. Nur dann sind die Daten draußen, und echte Anonymisierung ist deutlich schwieriger, als sie klingt, weil wenige Merkmale zusammen oft schon eindeutig sind.

Die Rollen

Rolle	Wer ist das in Ihrem Projekt
Verantwortlicher	Wer über Zweck und Mittel entscheidet, also Ihr Projekt bzw. die Stelle, für die Sie es bauen
Auftragsverarbeiter	Wer in Ihrem Auftrag verarbeitet: Hoster, Mailversender, Zahlungsdienst
Betroffene Person	Wessen Daten Sie verarbeiten

Die Unterscheidung ist keine Wortklauberei. Der Verantwortliche haftet, und mit jedem Auftragsverarbeiter braucht er einen Vertrag nach Artikel 28.

Grundsätze als Leitlinien

Grundsatz	Was das im Code heißt
Rechtmäßigkeit	Für jede Verarbeitung gibt es eine benannte Grundlage
Zweckbindung	Daten aus der Anmeldung werden nicht für Werbung verwendet
Datenminimierung	Jedes Feld ist begründet, der Rest wird gestrichen
Richtigkeit	Benutzer können ihre Daten korrigieren
Speicherbegrenzung	Jede Kategorie hat eine Frist und einen Löschmechanismus
Integrität und Vertraulichkeit	Verschlüsselung, Rechte, Härtung aus dem Vorjahr
Rechenschaftspflicht	Sie können all das belegen, deshalb docs/datenschutz.md

Rechtsgrundlage vor Erhebung

Bevor ein Feld ins Formular kommt, beantworten Sie: Warum darf ich das speichern? Sechs Grundlagen stehen in Artikel 6, vier davon sind praktisch relevant.

Grundlage	Passt für	Beispiel im Projekt
Vertrag	Alles, was zur Leistung nötig ist	Name und Mailadresse für die Buchung
Rechtliche Verpflichtung	Was Gesetze verlangen	Rechnungsdaten, sieben Jahre nach § 132 BAO
Berechtigtes Interesse	Betrieb und Sicherheit, nach Abwägung	Server-Protokolle zur Fehlersuche und Missbrauchsabwehr
Einwilligung	Alles Freiwillige	Newsletter, Reichweitenmessung, eingebettete Karte

Der häufigste Fehler ist, alles auf Einwilligung zu stützen. Das ist die schwächste Grundlage, weil sie jederzeit widerrufbar ist. Wenn jemand die Einwilligung zur Speicherung seiner Buchungsdaten widerruft, können Sie den Vertrag nicht mehr erfüllen. Für Vertragsdaten ist die Einwilligung schlicht die falsche Wahl.

Eine Einwilligung ist nur wirksam, wenn sie freiwillig (kein Nachteil bei Ablehnung), informiert (verständlich, wofür genau), granular (Newsletter getrennt von Reichweitenmessung), widerrufbar (so leicht wie die Erteilung) und dokumentiert ist (wann, wofür, in welcher Fassung). Und das Kopplungsverbot: Die Nutzung darf nicht davon abhängen, dass jemand in etwas einwilligt, das für die Leistung nicht nötig ist.

Legen Sie das je Datenkategorie in einer Tabelle in docs/datenschutz.md fest. Das ist zugleich der Kern Ihres Verarbeitungsverzeichnisses.

Datenminimierung und Löschkonzept

Erheben Sie weniger

Gehen Sie Ihre Formulare Feld für Feld durch und fragen Sie: Was passiert, wenn dieses Feld fehlt? Geburtsdatum, wenn nur „volljährig ja/nein” gebraucht wird. Telefonnummer, die niemand anruft. Genaue Adresse, wenn die Postleitzahl reicht. Streichen ist gründlicher als absichern.

Fristen

Kategorie	Aufbewahrung	Danach
Konto	solange aktiv, plus Karenzfrist	löschen
Buchungen	laufendes Jahr plus Verjährung	anonymisieren für Statistik
Rechnungsdaten	sieben Jahre (§ 132 BAO)	löschen
Server-Protokolle	7 bis 30 Tage	automatisch löschen
Einwilligungsnachweis	solange die Einwilligung gilt, plus Nachweisfrist	löschen
Sicherungen	Rotationszeitraum, etwa 30 Tage	überschreiben sich selbst

Fristen ohne Mechanismus sind Absichtserklärungen. Es braucht einen Auftrag, der regelmäßig läuft und tatsächlich löscht, und einen Nachweis, dass er läuft.

Löschen heißt überall löschen

Der Klassiker: Der Datensatz verschwindet aus der Anwendungstabelle und lebt weiter in den Protokollen, in der Suchmaschine, in der Kopie beim Mailversender und in der Sicherung.

Für Sicherungen gibt es eine praktikable Antwort, und sie lautet nicht „wir durchsuchen jedes Backup”. Sicherungen rotieren, also legen Sie die Aufbewahrungsdauer fest, dokumentieren sie, und wer eine Sicherung einspielt, wendet die zwischenzeitlichen Löschungen danach erneut an. Diesen Ablauf schreiben Sie auf, bevor Sie ihn brauchen (Kapitel 11).

Manche Daten dürfen Sie gar nicht löschen, etwa Rechnungen. Dann wird das Konto anonymisiert statt gelöscht:

export async function deleteAccount(userId: string) {
  await db.$transaction([
    // Invoices have to stay, but without any personal reference
    db.invoice.updateMany({
      where: { userId },
      data: { name: "deleted", email: null, address: null },
    }),
    db.booking.updateMany({
      where: { userId },
      data: { userId: null, note: null },
    }),
    db.consent.deleteMany({ where: { userId } }),
    db.session.deleteMany({ where: { userId } }),
    db.user.delete({ where: { id: userId } }),
  ]);

  await mailProvider.deleteContact(userId);         // at the processor as well
  logger.info({ operation: "account-deletion" });   // log without personal reference
}

Betroffenenrechte als Funktion

Auskunft, Berichtigung, Löschung, Datenübertragbarkeit, Widerspruch und Widerruf sind Rechte mit Frist: einen Monat. Wer das als Mailvorgang mit Handarbeit löst, hält die Frist beim ersten Mal und beim zehnten nicht mehr.

Bauen Sie zwei Funktionen in den Kontobereich: Daten herunterladen, das alle Daten zu dieser Person maschinenlesbar ausgibt, und Konto löschen mit dem Ablauf von oben. Beides braucht eine Bestätigung, damit niemand versehentlich löscht, und beides gehört im Protokoll vermerkt.

Cookies und Tracking

Die Regel steht nicht in der DSGVO, sondern im Telekommunikationsgesetz (§ 165 Abs. 3 TKG): Zugriff auf Informationen im Endgerät braucht eine Einwilligung, außer die Speicherung ist für den vom Nutzer gewünschten Dienst unbedingt erforderlich. Das ist eng gemeint.

Ohne Einwilligung	Nur mit Einwilligung
Sitzungscookie der Anmeldung	Reichweitenmessung
Warenkorb	Werbenetzwerke
Spracheinstellung, die der Benutzer gewählt hat	eingebettete Karten und Videos von fremden Servern
Sicherheitsmerkmale gegen CSRF	Wiedererkennung über Besuche hinweg

Ein Banner ist damit nur nötig, wenn Sie etwas aus der rechten Spalte tun. Wer nichts davon tut, braucht auch kein Banner, und das ist ein legitimes Entwurfsziel.

Wenn Sie eines brauchen, muss es funktionieren:

• Vor dem Klick wird nichts geladen und nichts gesetzt. Ein Banner über einem bereits laufenden Zähler ist wirkungslos.
• „Alle ablehnen” ist genauso leicht erreichbar wie „Alle annehmen”: eine Ebene, gleiche Größe, gleiche Auffälligkeit.
• Keine vorangekreuzten Kästchen, kein Weiterscrollen als Zustimmung, keine Farbtricks.
• Widerruf ist jederzeit möglich, über einen dauerhaft erreichbaren Punkt.

Diese Gestaltungstricks haben einen Namen, Dark Patterns, und sie sind inzwischen abgemahnt und untersagt worden. Nebenbei ärgern sie Ihre Benutzer, was in Kapitel 6 wieder Thema wird.

Eingebettete Inhalte sind die häufigste unbemerkte Übertragung. Eine Landkarte, ein Video, eine Schrift von einem fremden Server: In dem Moment, in dem die Seite lädt, kennt der fremde Anbieter die IP-Adresse Ihres Besuchers. Die Lösungen sind bekannt und einfach: Schriften lokal ausliefern (im Vorjahr schon aus Performancegründen), Karten und Videos erst nach einem Klick laden, und den Hinweis dazuschreiben, was beim Klick passiert.

Server-Protokolle sind ebenfalls eine Verarbeitung, weil die IP-Adresse darin steht. Grundlage ist das berechtigte Interesse an Betrieb und Sicherheit, dazu gehört eine kurze Frist und der Verzicht auf alles, was darüber hinausgeht.

Drittanbieter aus Kapitel 3

Bevor ein fremder Dienst mit personenbezogenen Daten in Produktion geht, arbeiten Sie diese Liste ab und legen das Ergebnis nach docs/datenschutz.md:

1. Welche Daten gehen hin? Feldweise, nicht pauschal.

2. Ist er Auftragsverarbeiter oder eigener Verantwortlicher? Ein Hoster verarbeitet in Ihrem Auftrag. Ein Zahlungsdienst entscheidet vieles selbst und ist dann Mitverantwortlicher mit eigenen Pflichten.

3. Gibt es einen Auftragsverarbeitungsvertrag? Seriöse Anbieter stellen ihn bereit, oft als Teil der Nutzungsbedingungen. Wenn keiner auffindbar ist, ist das ein Ausschlussgrund.

4. Wo stehen die Server? Innerhalb der EU ist es einfach. Bei Übermittlung in Drittstaaten brauchen Sie eine Grundlage, etwa einen Angemessenheitsbeschluss oder Standardvertragsklauseln.

5. Welche Subunternehmer setzt er ein? Die Liste steht meist im Vertrag und ändert sich.

6. Wie lange speichert er? Und löscht er auf Zuruf, wenn jemand sein Konto löscht?

Informationspflichten

Datenschutzerklärung. Sie beschreibt, was Sie tatsächlich tun: welche Daten, zu welchem Zweck, auf welcher Grundlage, wie lange, an wen weitergegeben, welche Rechte bestehen, wer der Ansprechpartner ist. Eine kopierte Erklärung, in der Dienste stehen, die Sie nicht verwenden, ist schlechter als keine, weil sie belegt, dass niemand hingesehen hat. Sie entsteht aus Ihrem Verarbeitungsverzeichnis, nicht aus einer Vorlage.

Impressum. In Österreich verlangt § 5 ECG bei geschäftsmäßigen Websites Namen, Anschrift, Kontaktdaten und, sofern vorhanden, Firmenbuch- und Umsatzsteuerdaten; dazu kommt die Offenlegung nach dem Mediengesetz. Für ein Schulprojekt reicht in der Regel ein schlanker Block mit Betreiber, Kontakt und dem Hinweis, dass es sich um ein Unterrichtsprojekt handelt.

Verarbeitungsverzeichnis. Nach Artikel 30 eine Tabelle mit Verarbeitungstätigkeiten. Für Ihr Projekt genügt:

| Tätigkeit | Kategorien | Betroffene | Grundlage | Empfänger | Frist |
|---|---|---|---|---|---|
| Kontoverwaltung | Name, Mail, Passwort-Hash | Mitglieder | Vertrag | keine | Konto plus 30 Tage |
| Buchungen | Termin, Maschine, Benutzer | Mitglieder | Vertrag | keine | 12 Monate, dann anonym |
| Zahlungen | Betrag, Referenz | Zahlende | Vertrag | Zahlungsdienst (AV) | 7 Jahre |
| Reichweitenmessung | gekürzte IP, Seitenaufrufe | Besucher | Einwilligung | keine | 14 Monate |
| Server-Protokolle | IP, Zeitpunkt, Pfad | Besucher | berechtigtes Interesse | keine | 14 Tage |

Datenschutz-Folgenabschätzung. Nötig bei voraussichtlich hohem Risiko, etwa umfangreicher Verarbeitung besonderer Kategorien, systematischer Überwachung öffentlicher Bereiche oder umfangreichem Scoring. Die meisten Schulprojekte brauchen keine; die Prüfung, ob man eine braucht, gehört trotzdem in einem Absatz dokumentiert.

Datenpanne: 72 Stunden

Wird bekannt, dass personenbezogene Daten offengelegt, verändert oder verloren wurden, gilt eine Meldefrist von 72 Stunden an die Datenschutzbehörde. Bei hohem Risiko müssen zusätzlich die betroffenen Personen verständigt werden.

Für den Betrieb heißt das dreierlei. Sie brauchen Protokolle, die im Nachhinein zeigen, was passiert ist, und zwar länger als drei Tage. Sie brauchen einen festgelegten Weg, wie eine Meldung intern hochgeht, samt Namen. Und Sie brauchen jemanden, der entscheidet. In Kapitel 11 wird daraus ein Teil des Notfallplans.

Weitere Vorschriften in Kürze

Barrierefreiheit. Für öffentliche Stellen gilt das Web-Zugänglichkeitsgesetz, seit Mitte 2025 gilt für bestimmte private Dienstleistungen zusätzlich das Barrierefreiheitsgesetz, mit dem der European Accessibility Act umgesetzt wurde. Maßstab ist WCAG auf Stufe AA. Umgesetzt wird das in Kapitel 6.

Urheberrecht. Bilder, Schriften, Symbole und Code haben Urheber. Kostenlos ist nicht dasselbe wie frei, und eine Bildersuche ist keine Lizenzquelle. Notieren Sie zu jedem Fremdinhalt Herkunft und Lizenz, einschließlich der geforderten Namensnennung, in einer Datei im Repository.

Datenschutz durch Technikgestaltung

Artikel 25 verlangt datenschutzfreundliche Voreinstellungen. Übersetzt in Entscheidungen, die Sie ohnehin treffen:

• Was ist die Voreinstellung? Ein neues Profil ist privat, nicht öffentlich. Der Newsletter ist aus, nicht an.
• Wie tief wird protokolliert? Vollständige Anfragekörper im Protokoll sind bequem und enthalten Namen, Adressen und manchmal Passwörter. Was Sie hier weglassen, müssen Sie in Kapitel 10 nicht mühsam wieder herausfiltern.
• Wer sieht welche Felder? Die Rechteebene „Feld” aus Kapitel 2 ist hier die passende Antwort.
• Wo liegt wie lange was? Getrennte Aufbewahrung für getrennte Zwecke.

Häufige Stolperfallen

1. Einwilligung als Universallösung, auch dort, wo der Vertrag die richtige Grundlage wäre.
2. Banner, das Tracking schon vor dem Klick startet.
3. „Ablehnen” versteckt oder zwei Ebenen tiefer als „Annehmen”.
4. Löschung nur in der Anwendungstabelle, nicht in Protokollen, Sicherungen und beim Drittanbieter.
5. Fristen aufgeschrieben, aber kein Auftrag, der sie umsetzt.
6. Schriften, Karten und Videos von fremden Servern eingebunden, ohne Grundlage und ohne Hinweis.
7. Datenschutzerklärung kopiert, samt Diensten, die Sie nie verwendet haben.
8. Kein Auftragsverarbeitungsvertrag mit dem Dienst, der seit drei Monaten Ihre Mails versendet.
9. Echtdaten in der Testumgebung oder auf dem Notebook zum Ausprobieren.
10. Personenbezogene Daten im Protokoll, die dort ein Jahr liegen bleiben.

Lernergebnisse

• Erklären: personenbezogene Daten, besondere Kategorien sowie Pseudonymisierung und Anonymisierung unterscheiden.
• Erklären: die Rollen Verantwortlicher, Auftragsverarbeiter und betroffene Person im eigenen Projekt zuordnen.
• Analysieren: die Verarbeitungen des eigenen Projekts erfassen und je Kategorie eine Rechtsgrundlage benennen.
• Beurteilen: beurteilen, wann eine Einwilligung nötig, wirksam und wann sie die falsche Grundlage ist.
• Erschaffen: ein Löschkonzept mit Fristen, Mechanismus und Umgang mit Sicherungen erstellen.
• Anwenden: Auskunft und Löschung als Funktion der Anwendung umsetzen, einschließlich Anonymisierung, wo Löschen nicht zulässig ist.
• Beurteilen: ein Einwilligungsbanner auf Wirksamkeit und Dark Patterns prüfen.
• Beurteilen: einen Drittanbieter datenschutzrechtlich bewerten und die Freigabe begründen.
• Erschaffen: Verarbeitungsverzeichnis, Datenschutzerklärung und Impressum passend zum eigenen Projekt erstellen.
• Anwenden: datenschutzfreundliche Voreinstellungen und protokollarme Gestaltung in eigenen Entwürfen berücksichtigen.

Arbeit am Jahresprojekt

In docs/datenschutz.md:

• Verarbeitungsverzeichnis nach der Tabelle oben, vollständig für Ihr Projekt.
• Je Kategorie eine Rechtsgrundlage und eine Aufbewahrungsfrist.
• Liste aller Drittanbieter mit Rolle, Vertrag, Serverstandort und übermittelten Feldern.
• Löschkonzept einschließlich Protokollen und Sicherungen.
• Vermerk zur Frage der Folgenabschätzung.

In der Anwendung umgesetzt:

• Datenexport und Kontolöschung im Kontobereich, Löschung wirkt auch beim Drittanbieter.
• Ein automatischer Auftrag, der Fristen durchsetzt, mit Nachweis eines Laufs.
• Einwilligung nur dort, wo sie nötig ist, ohne Dark Patterns, mit Widerruf.
• Keine fremden Server im Seitenaufbau ohne Klick.
• Datenschutzerklärung und Impressum, passend zur tatsächlichen Verarbeitung.

Passende Übungen

• Aufgabe - Verarbeitungsverzeichnis des eigenen Projekts
• Aufgabe - Löschkonzept umsetzen (inklusive Logs und Backups)
• Aufgabe - Einwilligungsbanner ohne Dark Patterns
• Aufgabe - Drittanbieter datenschutzrechtlich prüfen