Vorlage für den DSGVO‑Anfragenablauf: Export, Berichtigung und Löschung — Rollen, Genehmigungen, Fristen und Nachweisdokumentation, die Sie in Ihrer App speichern können.
Ein strukturierter Ablauf für DSGVO‑Anfragen ist der Unterschied zwischen ruhigem Umgang mit Datenschutzanfragen und hektischem Reagieren bei jeder eingehenden E‑Mail. Personen können Auskunft über ihre personenbezogenen Daten verlangen (Zugriff), deren Berichtigung fordern oder Löschung verlangen. Solche Anfragen sind normal für jede App, die Profile, Nachrichten, Bestellungen, Support‑Tickets oder Analyse‑IDs speichert.
Ad‑hoc‑Bearbeitung bricht schnell zusammen. Eine Anfrage landet im Postfach, wird weitergeleitet und verwandelt sich in manuelle Datenbankprüfungen und Screenshots. Fristen werden übersehen, versehentlich werden falsche Datensätze exportiert, und Teams vergessen Daten, die außerhalb der Hauptdatenbank leben (z. B. E‑Mail‑Tools, Zahlungsanbieter oder Logs). Die größte Lücke ist meist dieselbe: kein klarer Audit‑Trail, der beweist, was wann getan wurde.
Ein gut gestalteter Ablauf macht Anfragen vorhersehbar und wiederholbar. Er sollte drei Ergebnisse liefern: Geschwindigkeit (die Anfrage gelangt zu den richtigen Verantwortlichen mit Fälligkeitsdaten und Erinnerungen), Genauigkeit (Export, Berichtigung oder Löschung erfolgen in den relevanten Systemen vollständig) und Nachweis (Sie können Abschlussnachweise mit Genehmigungen, Zeitstempeln und betroffenen Daten vorlegen).
Der Umfang ist entscheidend. Der Ablauf sollte Daten innerhalb Ihrer App (Datenbank, Dateien, interne Admin‑Tools) und verbundene Systeme abdecken (Zahlungen, Messaging, CRM, Analytics, Backups, Cloud‑Speicher). Ein einfaches Beispiel: Eine Nutzerin verlangt Löschung, aber ihre E‑Mail existiert weiterhin im Support‑Tool und ihre Kunden‑ID bleibt bei Stripe. Ohne definierten Scope werden Sie die Anfrage „abgeschlossen“ markieren und trotzdem personenbezogene Daten behalten.
Wenn Sie das in einer Plattform wie AppMaster bauen, ist das Ziel, jeden Anfragetyp auf eine konsistente Reihe von Schritten, Rollen und aufgezeichneten Ergebnissen abzubilden, sodass Compliance nicht davon abhängt, wer gerade Dienst hat.
Eine DSGVO‑Anfrage liegt vor, wenn eine Person Sie bittet, mit ihren personenbezogenen Daten etwas zu tun. Personenbezogene Daten sind alle Informationen, die jemanden direkt oder indirekt identifizieren können, wie Name, E‑Mail, Geräte‑ID oder Support‑Ticket‑Verlauf.
Vereinfacht gesagt sind Sie entweder Datenverantwortlicher (Sie entscheiden, warum und wie Daten verwendet werden) oder Auftragsverarbeiter (Sie verarbeiten Daten für jemand anderen). Viele Apps sind je nach Funktion beides, daher sollte Ihr Ablauf für jede Anfrage festhalten, welche Rolle gilt.
Die häufigsten Anfragetypen sind Zugriff (Export), Berichtigung (Korrektur) und Löschung (Erasure). Behandeln Sie diese als unterschiedliche Pfade, denn jede hat andere Risiken und benötigt andere Nachweise.
Die meisten Anfragen haben eine Frist, und der Timer beginnt normalerweise, wenn Sie die Anfrage erhalten, nicht wenn es Ihnen gerade passt. Ihr Ablauf sollte Daten wie Eingang, Verifikation, Scope und Abschluss sichtbar machen. Das hilft, Fristen einzuhalten und liefert einen sauberen Audit‑Trail, falls später gefragt wird, was passiert ist.
Sie möchten genug Informationen, um die richtigen Datensätze zu finden, aber nicht so viel, dass Sie neues Datenschutzrisiko erzeugen. Typischerweise müssen Sie wissen, wer die Anfrage stellt (und wie Sie die Person verifizieren), welche Aktion gewünscht ist (Export, Korrektur, Löschung), welcher Account oder welches Identifikationsmerkmal zu durchsuchen ist und wohin die Antwort geliefert werden soll (ein sicherer Kanal).
Wenn die Anfrage unklar ist, stellen Sie Rückfragen, statt zu raten.
Manchmal dürfen oder müssen Sie eine Anfrage einschränken oder ablehnen, zum Beispiel wenn Sie die Identität nicht verifizieren können, die Anfrage sich wiederholt oder Gesetze Sie verpflichten, bestimmte Unterlagen aufzubewahren (z. B. Rechnungen). Auch dann dokumentieren Sie Entscheidung, Begründung und was stattdessen getan wurde, etwa partielle Löschung oder eingeschränkter Export.
Ein DSGVO‑Ablauf läuft schneller und sicherer, wenn jeder Schritt einen namentlich benannten Inhaber hat. Das Ziel ist einfach: eine Person genehmigt, eine andere führt aus, und später können Sie beweisen, was passiert ist.
Beginnen Sie mit einer kleinen Menge an Rollen, die zur Arbeitsweise Ihrer Firma passen. In kleinen Teams kann dieselbe Person mehrere Rollen übernehmen, aber die Berechtigungen sollten getrennt bleiben.
Eine praktische RACI‑artige Aufteilung sieht so aus:
Security wird meist konsultiert, nicht für jeden Schritt ausführend. Security definiert Identitätsprüfungen, überprüft ungewöhnliche Muster (z. B. wiederholte Anfragen) und bestätigt, dass Exporte sicher geliefert werden.
Die Trennung von Zuständigkeiten ist besonders wichtig bei Löschungen. Die Person, die die Löschfunktion ausführen kann, sollte nicht die alleinige Entscheidungsbefugnis über die Löschung haben. Das reduziert Fehler und das Risiko von Missbrauch.
Um verzögerte Anfragen zu vermeiden, planen Sie Abdeckung und Übergaben im Voraus: setzen Sie für jede Rolle eine primäre und eine vertretende Person (Urlaub passiert), definieren Sie eine Eskalationsstelle, wenn Fristen gefährdet sind, verlangen Sie Statusnotizen bei jeder Übergabe und führen Sie ein einziges Fallprotokoll mit Zeitstempeln und Genehmigungen.
Wenn Sie das als internes Tool bauen (z. B. in AppMaster), modellieren Sie Rollen als berechtigte Aktionen: wer genehmigen kann, wer ausführen darf und wer nur lesen darf. Diese Struktur macht den Ablauf von vornherein prüfbar.
Der Intake entscheidet über Erfolg oder Misserfolg des DSGVO‑Workflows. Kommen Anfragen an verschiedenen Stellen und werden ad hoc bearbeitet, verlieren Sie Zeit und einen sauberen Nachweis. Ziel ist ein nachverfolgter Fall pro Anfrage mit klarem Verantwortlichen, Zeitstempeln und einem wiederholbaren Ablauf.
Akzeptieren Sie Anfragen über eine kleine Anzahl von Kanälen, leiten Sie sie aber alle in dieselbe Queue. Viele Teams nutzen ein In‑App‑Formular (schnell und strukturiert), ein Datenschutz‑Postfach, ein Support‑Ticketportal und telefonische oder Chat‑Nachverfolgung, die ein Agent protokolliert (eine Anfrage nie nur mündlich behandeln).
Ob die Anfrage in‑App oder per E‑Mail beginnt: erfassen Sie dieselben Kernfelder. Halten Sie das Formular kurz, aber spezifisch genug, damit Ihr Team das richtige Konto findet und versteht, was die Person verlangt. Nützliche Intake‑Felder sind: Anfragetyp (Export/Zugriff, Berichtigung, Löschung), Kontenkennzeichen (User‑ID, E‑Mail, Telefon, Kundennummer), Zustellziel (In‑App‑Download, verifizierte E‑Mail‑Antwort, Postanschrift falls wirklich nötig), bereits vorhandene Identitätssignale (letzte Anmeldung, jüngste Bestell‑ID, die letzten 4 Ziffern eines gespeicherten Zahlungstokens usw.) und ein Freitextfeld.
Erstellen Sie einen Fall in dem Moment, in dem die Anfrage eintrifft. Nutzen Sie eine Regel wie „eine Anfrage = ein Fall“, damit Sie später auditieren können. Geben Sie ihm eine eindeutige Fall‑ID (z. B. GDPR‑2026‑00128) und protokollieren Sie Kanal, Intake‑Zeit, Anfragende Person und wer den nächsten Schritt besitzt.
Senden Sie schnell eine Eingangsbestätigung, auch wenn Sie noch nicht handeln können. Bleiben Sie sachlich: bestätigen Sie die Fall‑ID, sagen Sie, dass Sie die Identität prüfen, und nennen Sie einen realistischen Zeitrahmen. Vermeiden Sie Zusagen wie „wir löschen sofort alles“. Erklären Sie, was als Nächstes passiert, was Sie von der Person benötigen (falls nötig) und wie Sie den Abschluss bestätigen, wenn der Fall geschlossen ist.
Identitätsprüfungen sollten verhältnismäßig sein. Wenn jemand eine einfache Kopie seines Profils aus einem eingeloggten Konto anfragt, brauchen Sie in der Regel nicht dieselbe Prüfung wie bei einer Löschung, die Bestellungen, Rechnungen oder Teamarbeitsbereiche betreffen könnte.
Eine gute Regel: prüfen Sie mit Signalen, die Sie bereits haben, und sammeln Sie keine neuen sensiblen Dokumente.
Beginnen Sie mit der sichersten Option: bestätigen Sie, dass die anfragende Person das bekannte Konto kontrolliert.
So vermeiden Sie, dass Sie einen neuen Berg sensibler Identitätsdokumente anlegen, den Sie wiederum schützen, aufbewahren und im Sicherheitsfall melden müssten.
Manchmal kommt eine Anfrage von einem Anwalt, Elternteil oder anderem bevollmächtigten Vertreter. Fragen Sie nach zwei Dingen: dem Nachweis der Identität der betroffenen Person (wie oben minimal gehalten) und dem Nachweis der Vertretungsbefugnis.
In der Praxis ist das meist eine unterschriebene Vollmacht der betroffenen Person plus eine Möglichkeit, diese zu bestätigen (z. B. Antwort von der im Konto hinterlegten E‑Mail). Stammende Agenten innerhalb derselben Organisation (z. B. ein Admin für einen Mitarbeiter) sollten durch interne Richtlinien dokumentiert und in ihrem Handlungsspielraum eingeschränkt werden.
Können Sie die Identität nicht prüfen, bearbeiten Sie die Anfrage vorerst nicht. Fordern Sie die minimal nötigen zusätzlichen Angaben an, pausieren Sie den Ablauf und protokollieren Sie jeden Schritt (was Sie angefragt haben, wann und was eingegangen ist). Löschen Sie Verifikationsartefakte, sobald die Prüfung abgeschlossen ist.
Bevor jemand Daten exportiert, ändert oder löscht, braucht es eine Triage‑Phase. Hier werden die meisten Probleme verhindert: vergessene Systeme, falscher Anfragetyp oder Arbeit, die gestartet wird, bevor klar ist, was wirklich verlangt wird.
Schreiben Sie den Scope in klarer Sprache auf. Beantworten Sie drei Fragen: welche Daten, wo sie gespeichert sind und welcher Zeitraum relevant ist. Prüfen Sie außerdem, ob etwas die Aktion pausieren oder einschränken muss, z. B. ein laufender Streitfall, Betrugsermittlung oder eine rechtliche Aufbewahrungspflicht.
Eine einfache Triage‑Checkliste umfasst: was die Person verlangt (Zugriff/Export, Berichtigung, Löschung oder gemischte Anfrage), welche Systeme relevante Daten enthalten könnten (App‑DB, Support‑Inbox, Abrechnung, Analytics), welche Identifikatoren Sie nutzen werden (E‑Mail, User‑ID, Telefon, Bestellnummer), welcher Zeitraum gilt (alle Zeiten vs. bestimmter Zeitraum) und welche Einschränkungen bestehen (rechtliche Aufbewahrung, gemeinsames Konto, Daten, die andere Personen betreffen).
Klassifizieren Sie gemischte Anfragen früh. „Sende mir meine Daten und lösche dann mein Konto“ sollte zu zwei getrennten Nachweisen führen: ein Datenpaket und eine Löschaktion, jeweils mit eigener Genehmigung und Protokoll.
Entscheiden Sie, ob eine manuelle Prüfung erforderlich ist. Auslöser sind sensible Daten, gemeinsame Konten (Familien‑ oder Teamlogins), Einträge, die andere Personen betreffen, oder alles, was interne Notizen exponieren könnte. In solchen Fällen fügen Sie einen Prüfenden hinzu, bevor Sie etwas senden oder löschen.
Setzen Sie interne Fristen und Eskalationspunkte. DSGVO‑Fristen sind eng, also zielen Sie auf ein kurzes internes Ziel (z. B. Triage innerhalb von 2 Arbeitstagen) und definieren Sie, wer benachrichtigt wird, falls der Fall stockt.
Beispiel: Eine Nutzerin verlangt Löschung, aber die Triage findet offene Rechnungen in der Abrechnung und Support‑Tickets, die andere Kunden erwähnen. Sie können weiter vorgehen, benötigen aber wahrscheinlich partielle Löschung, Beibehaltung von Finanzunterlagen und eine dokumentierte Prüfungsfreigabe. In Tools wie AppMaster ist das leichter zu managen, wenn Statusänderungen, Genehmiger und Abschlussnotizen an einem Ort erfasst werden.
Ein guter Ablauf für Auskunftsanfragen bedeutet nicht „alles rauswerfen“. Es geht darum, später genau erklären zu können, was Sie durchsucht, was Sie geliefert und warum Sie es so geliefert haben.
Beginnen Sie mit einer (und halten Sie aktuell) einfachen Datenkarte pro Nutzer. Listen Sie auf, wo die Daten eines Nutzers liegen können: Kernprofiltabellen, Bestellungen und Rechnungen, Support‑Tickets, Chatnachrichten, hochgeladene Dateien, Audit‑Events und Logs, sowie Drittanbietersysteme (z. B. Zahlungsanbieter), damit Sie diese nicht in Hektik vergessen.
Führen Sie den Export als vorhersehbare Abfolge durch:
Beispiel: Eine Kundin verlangt ihren Export, aber Ihre Support‑Notizen nennen einen anderen Kunden beim Namen. Nehmen Sie die Notiz auf, entfernen Sie die Identifikatoren der anderen Person und protokollieren Sie diese Redaktion und warum sie erfolgte.
Wenn Sie das in einem Tool wie AppMaster umsetzen, behandeln Sie Exporterzeugung und Genehmigung zum Versand als getrennte Schritte. So lässt sich leichter eine zweite Kontrolle einfügen und es entstehen sauberere Nachweise, falls Sie später zeigen müssen, was wann geliefert wurde.
Eine Berichtigungsanfrage bedeutet, eine Person sagt, dass bestimmte Daten über sie falsch sind und wollte sie korrigiert haben. Ziel ist, das zu korrigieren, was korrigierbar ist, ohne historische Belege zu überschreiben, die erhalten bleiben müssen.
Definieren Sie, was „Berichtigung" in Ihrer App umfasst. Häufige Beispiele sind Profilfelder (Name, E‑Mail, Adresse), Kontoeinstellungen und Präferenzen. Es kann auch nutzergenerierte Inhalte betreffen (z. B. Anzeigename in einem Kommentar) und einige transaktionale Metadaten (z. B. falsche Liefertelefonnummer). Behandeln Sie finanzielle und Audit‑Daten mit besonderer Vorsicht.
Genehmigungsregeln halten Support schnell, aber sicher. Eine praktische Aufteilung ist: Support darf niedrigrisikoige Profilfelder (Tippfehler, Formatierungen) nach Basisprüfung korrigieren, ein Datenverantwortlicher bzw. Privacy‑Lead genehmigt Änderungen an Identitätsfeldern oder alles, was mit Abrechnung und Zugang zusammenhängt, und die Technik prüft Änderungen, die Kerntransaktionstabellen oder Integrationen betreffen.
Ihre Audit‑Spur sollte alten Wert, neuen Wert, Begründung, wer die Änderung durchgeführt hat, wann und zu welchem Fall erfassen. In AppMaster können Sie das als eigene "Berichtigungsprotokoll"‑Tabelle im Data Designer modellieren und Genehmigungen im Business Process Editor erzwingen.
Wenn es Streit über die Richtigkeit gibt, protokollieren Sie beide Positionen und pausieren die Änderung, bis Sie untersucht haben. Vermeiden Sie außerdem das Überschreiben historischer Datensätze, die intakt bleiben müssen (Rechnungen, Sicherheitslogs). Fügen Sie stattdessen eine korrigierende Anmerkung oder einen Zusatz ein, sodass die Historie wahr bleibt, während die aktuellen Daten korrekt werden.
Eine Löschanfrage klingt einfach, bis Abhängigkeiten auftauchen: Rechnungen, die Sie aufbewahren müssen, Betrugssignale, die Sie nicht einfach entfernen dürfen, oder Support‑Tickets, die andere Personen erwähnen. Behandeln Sie Löschung als kontrollierten Job mit klaren Entscheidungs‑ und Nachweispfaden.
Wählen Sie basierend auf Ihren Daten und Aufbewahrungspflichten eines der drei Ergebnisse:
Schreiben Sie die Entscheidung in die Fallakte, besonders wenn eine vollständige Löschung aus rechtlichen Gründen nicht möglich ist.
Mappen Sie die Nutzerdaten zu Systemen, die die Vorgehensweise beeinflussen: Zahlungen und Rechnungen, Betrugsprävention, Support‑Historie, Produkt‑Analytics, E‑Mail‑ und SMS‑Logs sowie Dateiuploads.
Muss ein Zahlungsbeleg bleiben, können Sie meist das Nutzerprofil löschen oder anonymisieren und die Rechnung mit minimalen Feldern aufbewahren. Bei Support‑Historie denken Sie über Schwärzung von Namen und E‑Mails nach, während das Gespräch selbst für Qualitätszwecke erhalten bleibt.
Halten Sie die Schritte konsistent, damit Sie später die Erledigung nachweisen können:
Wenn Sie das in AppMaster abbilden, behandeln Sie die Löschung als Business Process mit expliziten Zuständen, Genehmigungen und wiederholbaren Aufgaben.
Senden Sie Löschanweisungen an Drittparteien (Zahlungen, Messaging, Analytics) und protokollieren Sie deren Bestätigungen. Speichern Sie Nachweise: Job‑Logs, Zeitstempel, die Operator‑ oder Automations‑ID und eine Abschlussnotiz, die auflistet, was gelöscht, anonymisiert oder behalten wurde und warum.
Die meisten Compliance‑Fehler entstehen nicht aus böser Absicht, sondern weil Arbeit über E‑Mails, Chats und Schnelllösungen verteilt wird.
Die erste Falle ist das Fehlen einer einzigen Fall‑ID. Ohne sie können Sie nicht zeigen, wer was wann angefragt hat, wie Sie die Identität geprüft haben, was Sie getan haben und wann Sie fertig waren.
Ein zweiter häufiger Fehler sind fehlende Genehmigungen. Wenn dieselbe Person genehmigen und ausführen kann, rutscht ein Fehler leichter durch. Schon ein leichter Zwei‑Personen‑Check hilft, besonders bei Löschungen und Exporten.
Löschungen schlagen in zwei Richtungen fehl. Over‑Deleting entfernt Daten, die Sie noch für Sicherheit, Betrugsabwehr oder rechtliche/ buchhalterische Zwecke benötigen. Under‑Deleting ist häufiger: Teams löschen die Hauptdatenzeile, vergessen aber Anhänge, Logs, Analytics‑Events, Volltextindizes, Caches und Hintergrundjobs, die die Daten später wiederherstellen.
Exporte sind ebenfalls riskant. Daten aus vielen Quellen zusammenzuführen kann kleine Join‑Fehler produzieren, die Informationen anderer Nutzer enthalten. Interne Notizen sind ein weiterer häufiger Stolperstein: Kommentare wie „verdächtiger Betrug" oder „VIP‑Rabatt" können im Export landen, obwohl sie nur für Mitarbeitende gedacht waren.
Beispiel: Ein Support‑Agent exportiert „alle Tickets" für einen Kunden, aber die Exportabfrage enthält auch Nachrichten aus einem Shared‑Inbox oder einem zusammengeführten Kontakt. Das ist ein Datenschutzvorfall, der durch eine wohlmeinende Abkürzung entstanden ist.
Einfach wirkende Guardrails verhindern die meisten Probleme: eine einzelne Fall‑ID und alle Aktionen darunter protokollieren, Rollen für Intake, Genehmigung und Ausführung trennen, eine Datenkarte pflegen (Tabellen, Dateien, Logs, Suche, Caches, asynchrone Jobs), scoped Export‑Templates verwenden und mit Testkonten prüfen sowie Abschlussnachweise speichern (was geändert/gelöscht wurde, von wem und wann).
Wenn Sie das in AppMaster umsetzen, behandeln Sie den Fall als erstklassiges Objekt und lassen jeden Workflow‑Schritt automatisch einen Audit‑Eintrag schreiben.
Ein guter DSGVO‑Ablauf ist an einem hektischen Tag leicht zu bedienen und später leicht nachzuweisen. Können Sie zwei Fragen schnell beantworten – was haben wir getan und wann haben wir es getan – sind Sie auf der sicheren Seite.
Nutzen Sie für jeden Fall dieselbe Checkliste (Zugriff, Berichtigung oder Löschung): Intake protokollieren und Fall‑ID, Verantwortliche und Fälligkeitsdatum vergeben; Identität sicher prüfen und die Prüfmethodik festhalten (nicht die Rohdokumente); Scope festlegen (Produkte, Accounts, Zeitraum, Datenquellen); richtige Genehmigungen einholen (Privacy‑Lead, Legal, System‑Owner bei Bedarf); ausführen, den Anfragenden informieren und Abschlussnachweise speichern.
Für Nachweise brauchen Sie nicht mehr personenbezogene Daten, aber verlässliche Metadaten. Mindestens sollten Sie Fall‑ID, Anfragetyp, Methode der Identitätsprüfung (nicht die Originaldokumente), Zeitstempel für jeden Schritt, Genehmiger‑Namen oder Rollen, durchgeführte Aktionen und einen Verweis auf das Deliverable (z. B. Export‑Datei‑ID, Ticket‑Nummer oder Löschjob‑ID) aufbewahren.
Um Fehler zu reduzieren und Antworten zu beschleunigen, standardisieren Sie zentrale Nachrichten, damit jeder Anfragende klare, einheitliche Updates bekommt. Halten Sie drei Vorlagen bereit: Eingangsbestätigung (Was wir erhalten haben, erwarteter Zeitrahmen, wie wir die Identität prüfen), Info‑Anfrage (was fehlt und wie es bereitgestellt wird) und Abschlussmeldung (was geliefert oder geändert wurde, was nicht möglich war und warum, und wie man Beschwerde einlegt).
Nächste Schritte: Implementieren Sie den Ablauf in Ihrer App, damit er nicht in verstreuten E‑Mails lebt. Modellieren Sie den Fall als Datensatz mit Statusschritten, hängen Sie Evidenzreferenzen an, und fügen Sie rollenbasierte Genehmigungen sowie Audit‑Logs hinzu.
Teams bauen dieses interne DSGVO‑Falltool oft in AppMaster (appmaster.io), weil Sie dort die Fall‑Tabelle im Data Designer definieren, Genehmigungen und Ausführungsschritte im Business Process Editor einrichten und die Audit‑Spur direkt an jede Statusänderung binden können. Richtig umgesetzt wird der Ablauf wiederholbar, messbar und rechtssicher.
Was ist das Erste, das wir tun sollten, wenn eine DSGVO-Anfrage eingeht?Erstellen Sie sofort einen einzelnen nachverfolgten Fall, sobald die Anfrage eingeht. Überprüfen Sie dann die Identität, grenzen Sie die betroffenen Datenquellen ein und führen erst danach die Schritte Export/Berichtigung/Löschung durch. Behandeln Sie „Zugriff“, „Berichtigung“ und „Löschung“ als getrennte Pfade, damit für jede Aktion die passenden Genehmigungen und Nachweise vorliegen.
Wie prüfen wir die Identität, ohne einen Ausweis-Scan anzufordern?Nutzen Sie bereits vorhandene Signale statt neuer sensibler Dokumente. Ein sicherer Standard ist die Verifikation über das eingeloggte Konto oder indem Sie nur an die in den Akten hinterlegte E‑Mail antworten. Für risikoreichere Aktionen wie Löschung fügen Sie eine zweite Bestätigung hinzu.
Warum brauchen wir für jede Anfrage eine Fallnummer und eine Prüfspur?Weil nur so später nachgewiesen werden kann, was passiert ist. Ein Fallprotokoll mit Zeitstempeln, zuständigen Personen, Genehmigungen und Abschlussnotizen verhindert verpasste Fristen, beseitigt Verwirrung („das hat doch schon jemand erledigt“) und liefert Belege für den Betroffenen oder eine Aufsichtsbehörde.
Welche Informationen sollten wir beim Intake sammeln (und welche vermeiden)?Sammeln Sie nur das Nötige, damit Sie die richtigen Datensätze finden und die Antwort sicher liefern können: Anfragetyp, Kontenkennzeichen, gewünschter Übermittlungsweg und die Methode der Identitätsprüfung. Vermeiden Sie es, „vorsorglich“ zusätzliche personenbezogene Daten zu erfassen – das schafft nur weiteres Risiko und Aufbewahrungsaufwand.
Was bedeutet „Scope der Anfrage festlegen“ genau?Das heißt: schriftlich festhalten, welche Daten Sie durchsuchen wollen, wo sie liegen und welcher Zeitraum relevant ist. Ein praktischer Standard umfasst Ihre App‑Datenbank plus verknüpfte Tools wie Zahlungsanbieter, Support‑Systeme, Messaging, Analytics, Dateispeicher und Backups, auf die Sie vernünftigerweise zugreifen können.
Was ist die sicherste Vorgehensweise bei einer Auskunftsanfrage (Datenexport)?Erzeugen Sie ein strukturiertes Paket (häufig JSON oder CSV) und fügen Sie eine kurze, leicht verständliche Zusammenfassung hinzu, damit die Person nachvollziehen kann, was sie erhält. Prüfen Sie das Paket auf Daten anderer Personen und interne Notizen, ehe Sie es ausliefern, und dokumentieren Sie genau, welche Systeme durchsucht und welche Dateien erstellt wurden.
Wie behandeln wir eine Berichtigungsanfrage, ohne Audit/Historie zu zerstören?Korrigieren Sie standardmäßig aktuelle Profilfelder, aber schreiben Sie keine historischen Belege um (z. B. Rechnungen oder Sicherheitsprotokolle). Wenn ein Feld nicht überschrieben werden darf, fügen Sie einen Korrektureintrag oder eine Notiz hinzu. Protokollieren Sie alten Wert, neuen Wert, Begründung, wer die Änderung vorgenommen hat und wann.
Müssen wir alles löschen, wenn jemand Löschung verlangt?Nicht immer. Entscheiden Sie im Fall, welches Ergebnis angemessen ist: vollständige Löschung, Anonymisierung oder Deaktivierung des Kontos. Häufig ist eine teilweise Löschung oder Anonymisierung richtig, wenn gesetzliche Aufbewahrungspflichten (z. B. Buchhaltungsunterlagen) bestehen. Dokumentieren Sie in den Abschlussnotizen, was behalten wurde und warum.
Was sind die häufigsten Fehler, die Teams bei DSGVO-Anfragen machen?Zu viel zu löschen (Daten entfernen, die Sie gesetzlich oder aus Sicherheitsgründen behalten müssen) und zu wenig zu löschen (nur die Hauptdatenreihe entfernen, aber Anhänge, Logs, Caches, Suchindizes oder Drittanbietersysteme übersehen) sind die häufigsten Fehler. Ein weiterer klassischer Fehler ist, beim Export versehentlich Daten anderer Personen mitzuziehen.
Wie können wir diesen Workflow als internes Tool in AppMaster umsetzen?Modellieren Sie die Anfrage als "Fall" mit Statusschritten, Zuständigen, Fälligkeitsdaten und Evidenz‑Referenzen, und erzwingen Sie Genehmigungen sowie Ausführungsrechte als berechtigte Aktionen. In AppMaster nutzt man typischerweise den Data Designer für Fall‑ und Audit‑Tabellen und den Business Process Editor, um wiederkehrende Abläufe und automatische Audit‑Einträge zu implementieren.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
