DSGVO-Schnellcheck

So setzen Sie es um:

Mindestens: Eine E-Mail-Adresse, an die Auskunftsersuchen geschickt werden können, mit garantierter Antwort binnen 30 Tagen. Besser: Ein „Meine Daten"-Bereich im Benutzerkonto, in dem Nutzer ihre gespeicherten Daten selbst einsehen können. Bei internen Anwendungen reicht ein dokumentierter Prozess (z. B. Anfrage an IT-Abteilung mit Ticket-System).

So setzen Sie es um:

Ideal: Nutzer können Stammdaten (Name, Adresse, Kontakt) selbst im Profil bearbeiten. Für Daten, die nicht selbst änderbar sein sollen (z. B. Vertragsdaten): Ein Formular oder eine E-Mail-Adresse zur Korrekturanfrage. Wichtig: Die Korrektur muss auch in Backups und bei Dritten nachgezogen werden.

So setzen Sie es um:

Eine E-Mail-basierte Löschanfrage ist rechtlich ausreichend — aber nur, wenn sie zuverlässig und fristgerecht (30 Tage) bearbeitet wird. Komfortabler: Ein „Konto löschen"-Button im Benutzerprofil. Wichtig: Gesetzliche Aufbewahrungsfristen (z. B. 10 Jahre für Rechnungen) haben Vorrang — dann wird gesperrt statt gelöscht. Löschen heißt auch: Backups und verbundene Systeme berücksichtigen.

So setzen Sie es um:

Ein „Daten exportieren"-Button im Benutzerkonto, der eine CSV- oder JSON-Datei erzeugt. Mindestens: Auf Anfrage per E-Mail wird ein Export innerhalb von 30 Tagen bereitgestellt. Der Export muss die vom Nutzer bereitgestellten Daten enthalten — nicht unbedingt abgeleitete Daten (z. B. interne Bewertungen).

So setzen Sie es um:

Bei Werbung: Ein Abmeldelink in jeder E-Mail plus eine Opt-out-Seite. Bei berechtigtem Interesse: Ein Kontaktweg (E-Mail, Formular), über den der Widerspruch erklärt werden kann. Die Anwendung muss den Widerspruch technisch umsetzen können — also ein Flag „Verarbeitung gesperrt" pro Nutzer.

So setzen Sie es um:

Eine Checkbox (nicht vorausgewählt!) vor dem Absenden eines Formulars, z. B.: „Ich bin damit einverstanden, dass meine Daten zum Zweck der Anfrage verarbeitet werden." Bei Vertragserfüllung (z. B. Bestellung) ist keine zusätzliche Einwilligung nötig — aber eine Information. Wichtig: Die Einwilligung muss dokumentiert werden (wer, wann, wofür).

So setzen Sie es um:

Wenn die Einwilligung per Checkbox erteilt wurde, muss der Widerruf genauso einfach sein — z. B. ein Klick im Benutzerkonto oder ein Abmeldelink. Nicht ausreichend: „Bitte schreiben Sie einen Brief an unsere Zentrale." Ein Medienbruch (online erteilt → offline widerrufen) ist unzulässig.

So setzen Sie es um:

Ein permanent sichtbarer Link „Datenschutz" im Footer oder in der Navigation. Die Erklärung muss benennen: Welche Daten, warum, wie lange, an wen weitergegeben, welche Rechte. Bei internen Anwendungen: Aushang oder Link im Intranet. Tipp: Einfache Sprache verwenden, nicht nur Juristendeutsch.

So setzen Sie es um:

Bei jedem Formular kurz angeben, wofür die Daten verwendet werden: „Ihre Daten werden ausschließlich zur Bearbeitung Ihrer Anfrage verwendet." Wenn Daten später für einen neuen Zweck genutzt werden sollen, muss erneut informiert/eingewilligt werden. Intern: Verarbeitungsverzeichnis pflegen.

So setzen Sie es um:

Formulare kritisch prüfen: Braucht das Kontaktformular wirklich Geburtsdatum und Telefonnummer? Pflichtfelder auf das Minimum beschränken. Faustregel: Wenn Sie nicht in einem Satz erklären können, wofür ein Feld gebraucht wird, ist es überflüssig. Optional-Felder klar als solche kennzeichnen.

So setzen Sie es um:

Pro Datenkategorie eine Frist definieren, z. B.: Bewerbungsunterlagen 6 Monate nach Absage, Logfiles 90 Tage, inaktive Accounts 2 Jahre, Rechnungen 10 Jahre (gesetzlich). Diese Fristen dokumentieren und — idealerweise automatisiert — durchsetzen (z. B. Cronjob der alte Daten löscht).

So setzen Sie es um:

Variante A (ideal): Automatische Löschung per Zeitsteuerung — z. B. ein Hintergrundjob, der monatlich Daten löscht, deren Frist abgelaufen ist. Variante B (Minimum): Eine dokumentierte Checkliste, die quartalsweise abgearbeitet wird (manuell, aber nachweisbar). In beiden Fällen: Protokollieren, was wann gelöscht wurde.

So setzen Sie es um:

Testdatenbank mit anonymisierten oder fiktiven Daten befüllen (Faker-Libraries nutzen). Wenn echte Daten zum Debuggen nötig sind: Nur mit Zugangsschutz und nach dem Test sofort wieder löschen. Produktivdatenbanken niemals 1:1 in die Testumgebung kopieren.

So setzen Sie es um:

Ein SSL/TLS-Zertifikat einrichten (bei den meisten Hostern kostenlos via Let's Encrypt). HTTP-Zugriffe automatisch auf HTTPS umleiten. Auch interne Anwendungen im Firmennetz sollten HTTPS nutzen — spätestens wenn Mitarbeiter über VPN oder von extern zugreifen.

So setzen Sie es um:

Spalten mit besonders sensiblen Daten (Gesundheitsdaten, Bankverbindungen, Ausweiskopien) auf Anwendungsebene verschlüsseln — z. B. mit AES-256. Die Schlüssel getrennt von der Datenbank aufbewahren. Für normale Stammdaten (Name, E-Mail) ist Datenbank-Verschlüsselung „at rest" ausreichend (die meisten Cloud-Anbieter bieten das standard).

So setzen Sie es um:

Jedes Framework bietet eingebaute Passwort-Hashing-Funktionen — diese nutzen, niemals selbst implementieren. PHP: password_hash(), Laravel: Hash::make(). Bestehende Klartext-Passwörter beim nächsten Login automatisch hashen. Passwort-Regeln (Mindestlänge 8–12 Zeichen) erzwingen.

So setzen Sie es um:

Mindestens: Admin vs. Normaler Benutzer unterscheiden. Besser: Feingranulare Rollen (z. B. Sachbearbeiter sieht nur eigene Fälle, Teamleiter sieht das Team, Admin sieht alles). Das Prinzip „Need to know" umsetzen. Bei kleinen Teams reicht oft: Admin, Bearbeiter, Nur-Lesen.

So setzen Sie es um:

Ein Audit-Log, das mindestens speichert: Wer (User-ID), wann (Zeitstempel), was (welche Aktion auf welchem Datensatz). Nicht nötig: Jeden Lesezugriff loggen. Sinnvoll: Änderungen, Löschungen, Exporte und Zugriffe auf besonders sensible Daten. Das Log selbst schützen (nicht durch normale Benutzer löschbar).

So setzen Sie es um:

Automatische tägliche Backups (Datenbank + Dateien). Mindestens monatlich testen, ob die Wiederherstellung funktioniert. Backups verschlüsselt und an einem anderen Ort aufbewahren (nicht auf demselben Server). Aufbewahrungsfrist für Backups definieren — auch Backups unterliegen den Löschfristen!

So setzen Sie es um:

Eine Tabelle (Excel reicht aus!) mit folgenden Spalten: Verarbeitungstätigkeit, Zweck, betroffene Personengruppen, Datenkategorien, Empfänger, Löschfristen, technische Schutzmaßnahmen. Pro Anwendung/Prozess eine Zeile. Muss nicht perfekt sein — aber es muss existieren und aktuell gehalten werden.

So setzen Sie es um:

Für jeden externen Dienst, der personenbezogene Daten verarbeitet, einen AV-Vertrag abschließen: Hoster, Cloud-Provider, E-Mail-Dienst, Newsletter-Tool, Analyse-Tool. Die meisten großen Anbieter stellen fertige AV-Verträge bereit (oft unter „Datenschutz" oder „DPA" auf der Website). Sammeln und ablegen.

So setzen Sie es um:

Prüfen: Verarbeitet die Anwendung Gesundheitsdaten, erstellt sie Profile, bewertet sie Personen automatisch, überwacht sie öffentliche Bereiche? Falls ja: Eine strukturierte Risikoanalyse durchführen und dokumentieren. Vorlagen gibt es bei den Aufsichtsbehörden (z. B. LfDI). Falls nein: Kurz dokumentieren, warum keine DSFA nötig ist.

So setzen Sie es um:

Ein einseitiges Dokument mit: Wer muss informiert werden (intern), wer meldet an die Behörde, Kontaktdaten der zuständigen Aufsichtsbehörde, Vorlage für die Meldung. Den Prozess einmal im Jahr durchsprechen. Wichtig: Die 72-Stunden-Frist beginnt bei Kenntnis — nicht erst nach Analyse.

So setzen Sie es um:

Mindestens jährlich eine kurze Unterweisung (30–60 Minuten): Was sind personenbezogene Daten, worauf achten, was tun bei Verdacht auf Datenpanne. Muss kein teures Seminar sein — ein internes Meeting oder ein kurzes E-Learning reicht. Teilnahme dokumentieren (Unterschrift oder digitaler Nachweis).