Wenn ich einen pragmatischen Datenschutz‑Audit für eine SaaS‑Lösung durchführe, verfolge ich ein klares Ziel: in einer einzigen Session die relevanten Datenflüsse, Subprocessor‑Verhältnisse und die wichtigsten vertraglichen Controls so zu prüfen, dass ich danach direkte Empfehlungen geben kann. Das klingt ambitiös — mit der richtigen Struktur und den richtigen Fragen ist es aber gut machbar. In diesem Artikel beschreibe ich meinen Ablauf, praktische Checklisten und typische Stolperfallen, die ich in Projekten immer wieder sehe.

Vorbereitung: Ziel, Umfang und Teilnehmer klären

Bevor ich loslege, kläre ich drei Dinge:

  • Scope — Welche Dienste, welche Komponenten und welche Kundendaten sind betroffen? Geht es um ein komplettes Produkt oder ein einzelnes Modul (z.B. Authentifizierung, Payment, Analytics)?
  • Risiko‑Fokus — Liegen sensible Daten (Gesundheit, Finanzen, personenbezogene Daten von Kindern) vor? Dann priorisiere ich diese Bereiche.
  • Teilnehmer — Wer ist dabei? Ideal sind Product Owner, ein Technical Lead, DevOps, Legal oder ein Datenschutzbeauftragter (sofern vorhanden).

    • Mit diesen Informationen plane ich eine 60–90 Minuten Session. Kürzer ist möglich, länger ist meist ineffizient, weil Entscheidungen und Fakten dann nicht synchron sind.

    Ablauf der Session: Agenda und Rollen

    Meine Session hat eine feste Agenda, damit wir strukturiert bleiben:

  • 5–10 Minuten: Ziel und Scope vorstellen
  • 20–30 Minuten: Datenflüsse (Live‑Mapping)
  • 20–25 Minuten: Subprocessor‑Check
  • 15–20 Minuten: Vertragliche Controls und offene Punkte
  • Rest: To‑dos und Priorisierung

    • Ich übernehme normalerweise die Moderation und das Live‑Mapping (z. B. in einem Miro‑Board oder direkt in einem Google Doc). Eine Person aus dem Team sollte technische Details liefern, eine andere die Vertragslage.

    Datenflüsse in einer Session kartieren

    Das Herz des Audits ist das Verständnis, welche Daten wohin fließen. Ich nutze eine einfache Visualisierung und folge diesen Schritten:

  • Startpunkt definieren: Welche Eingaben erzeugt das System? Beispiele: Registrierung, Uploads, API‑Events, Integrationen von Dritt‑Anbietern.
  • Datenklassen bestimmen: personenbezogen, sensibel, pseudonymisiert, aggregiert. Ich markiere sensibel mit Rot.
  • Transit‑Pfade aufzeichnen: Client → Frontend → Backend → Datenbank → Drittservice. Für jedes Segment notiere ich: Verschlüsselung in Transit, Verschlüsselung at Rest, Zugriffskontrollen.
  • Persistenzpunkte identifizieren: Wo werden Daten gespeichert (Logs, Backups, Analytics)?

    • Während des Mappings frage ich immer nach dem konkreten Zugriff: Wer (Personen/Services) kann die Rohdaten lesen? Gibt es Admin‑Console‑Accounts, automatisierte Jobs oder Supportzugriffe?

    Subprocessor prüfen: schnell und effektiv

    SaaS‑Anbieter nutzen oft Subprocessor (z. B. AWS, Stripe, SendGrid). Ziel ist es, Transparenz über diese Liste und ihre Rollen zu bekommen.

  • Offizielle Liste anfordern: Viele Anbieter haben ein Dokument mit Sub‑Processor‑Angaben. Falls nicht vorhanden, bitte um exportierbare Liste (CSV, JSON).
  • Rollen verstehen: Ist der Dienst nur Hosting (IaaS), oder verarbeitet er personenbezogene Daten aktiv (z. B. Tracking/Logging, Payment)?
  • Standort & Datenübermittlung: Wo sind die Server/Datencenter? Gibt es Drittstaatenübermittlungen (z. B. USA) und welche Rechtsgrundlage (Standardvertragsklauseln, UK/GDPR‑Äquivalente) liegt vor?
  • Sicherheit & Compliance: Gibt es Zertifikate (ISO 27001, SOC2) und aktuelle Reports? Ich notiere Ablaufdaten und Gültigkeit.

    • Wichtig: Ich unterscheide Subprocessor, die nur Infrastruktur bereitstellen, von solchen, die tatsächlich Zugriff auf Klartextdaten haben. Letztere werden priorisiert.

    Vertragliche Controls in einer Session prüfen

    In 15–20 Minuten kann man gute erste Aussagen zu den wichtigsten vertraglichen Punkten treffen. Ich habe dafür eine Checkliste, die ich live durchgehe:

  • Auftragsverarbeitungsvertrag (AVV/DPA): Existiert einer? Ist er aktuell und signierbar?
  • Subprocessor‑Klausel: Verpflichtet der Anbieter zur Mitteilung neuer Subprocessor und zur Möglichkeit zum Widerspruch?
  • Datenlöschung: Gibt es klare Regeln zur Löschung nach Vertragsende und für Backups?
  • Rechte betroffener Personen: Wie unterstützt der Anbieter Lösch‑/Auskunfts‑/Übertragbarkeitsanfragen?
  • Sicherheitsvorfälle: Meldefristen (z. B. 72 Stunden), Kommunikation und Forensics‑Unterstützung.
  • Verfügbarkeit & SLAs: Gibt es garantierte Backups, Wiederherstellungszeiten und Haftungsbeschränkungen?

    • Wenn beim Anbieter typische Lücken bestehen (z. B. keine DPA, keine Widerspruchsoption bei Subprocessor‑Änderungen), markiere ich das als "Blocker" oder "High Risk" — abhängig von der Sensibilität der Daten.

    Tools und Hilfsmittel, die ich verwende

    Für ein pragmatisches Audit sind einige Tools sehr hilfreich:

  • Miro/Whimsical für Live‑Datenflussdiagramme
  • Google Docs/Sheets für Subprocessor‑Listen und Vertragsnotizen
  • Postman oder Browser‑DevTools für API‑Calls und Headers (z. B. um zu sehen, ob sensible Daten im Request‑Body landen)
  • WireShark/tcpdump selten, aber nützlich, wenn ich Transportverschlüsselung prüfen muss
  • Security & Compliance Reports (SOC2, ISO) als PDF‑Uploads zum schnellen Durchsehen

    • Praktische Prüfungen während der Session

    Neben dem Mapping gibt es ein paar Quick‑Checks, die ich direkt anstelle:

  • Registrierungstest: Sende Testdaten und prüfe, ob sensible Felder (z. B. Telefonnummer, ID‑Nummern) unverschlüsselt in Logs oder 3rd‑party‑Requests auftauchen.
  • Backup‑Sichtung: Frage nach Backup‑Retention und Verschlüsselung.
  • Admin‑Zugriffe: Prüfe, ob Supportaccounts Zugriff auf Kundendaten haben und wie dieser Zugriff dokumentiert/geloggt ist.
  • DSAR‑Prozess: Lasse mir ein Beispiel für eine Auskunftsanforderung zeigen (Workflow, Zeit bis zur Antwort).

    • Priorisierung und konkrete To‑dos

    Am Ende der Session priorisiere ich die gefundenen Punkte in drei Stufen:

  • Blocker (sofort): Vertragsmängel oder Subprocessor mit Zugriff auf sensible Daten ohne DPA.
  • High (2–4 Wochen): Fehlende Verschlüsselung at rest, unlimitierte Supportzugriffe, kein Incident‑Response‑Plan.
  • Medium/Low: Logging‑Optimierung, Retention‑Hygiene, SLA‑Verbesserungen.

    • Für jeden Punkt formuliere ich eine konkrete Handlungsempfehlung: Wer macht was bis wann. Das macht es für Product/Legal/DevOps leicht, die nächsten Schritte umzusetzen.

    PrüfpunktTypische FragenPriorität
    DatenflüsseWer hat Zugriff? Werden Daten an Dritte weitergeleitet?High
    SubprocessorListe vorhanden? Zugriff auf Klartext?Blocker/High
    VerschlüsselungIn Transit? At Rest? Key‑Management?High
    VerträgeGibt es DPA, Meldungsfristen, Löschfristen?Blocker

    Wenn du dieses Vorgehen adaptierst, wirst du in einer einzigen Session überraschend viele offene Fragen klären können. Mir reicht das Ergebnis oft, um eine risikoorientierte Roadmap zu erstellen — und um schnell zu entscheiden, ob ein Service für sensible Daten geeignet ist oder nicht.