Aufbewahrung von Logs und DLRs bei A2P-SMS: Fristen, Zugriff und nachvollziehbare Löschung
Praxisleitfaden für eine Aufbewahrungsrichtlinie für A2P-SMS-Logs und DLRs auf Basis von Zweckbindung, Datenminimierung, eingeschränktem Zugriff, Nachvollziehbarkeit und überprüfbarer Löschung.
Die Aufbewahrung von SMS-Protokollen ist eine Entscheidung für Betrieb, Sicherheit und Governance
Die Aufbewahrung von A2P-SMS-Logs und DLRs sollte nicht mit einer einzigen Frist für alle Daten geregelt werden. Ein Versand erzeugt Nachweise, die für Support, Abstimmung, Betrugsermittlungen, Qualitätsanalysen, Incident-Bearbeitung und die Abwehr von Ansprüchen nützlich sind. Zugleich können einige dieser Nachweise personenbezogene Daten, Inhalte oder Informationen enthalten, die eine Reidentifizierung einer Person oder Kampagne ermöglichen.
Soweit die DSGVO gilt, verlangen die Grundsätze der Zweckbindung, Datenminimierung und Speicherbegrenzung, dass identifizierbare Daten nur so lange aufbewahrt werden, wie dies für spezifische, ausdrückliche und rechtmäßige Zwecke erforderlich ist. Branchenspezifische, steuerliche, vertragliche, regulatorische oder prozessuale Pflichten, die für die jeweilige Organisation gelten, können die Entscheidung ebenfalls beeinflussen.
Eine vertretbare Richtlinie ist nicht jene, die die meisten Daten am längsten speichert. Sie ist jene, die für jede Protokollklasse erklären kann, welchem Zweck sie dient, wer sie benötigt, welchen Zugriff diese Person erhält, wann sich die Zugriffsstufe ändert und wie die Daten nach Ende ihres Bedarfs gelöscht oder anonymisiert werden.
- Definieren Sie den Zweck, bevor Sie die Frist festlegen.
- Behandeln Sie Inhalte, Rufnummern, Kennungen, Metadaten und technische Ereignisse getrennt.
- Ermitteln Sie geltende Pflichten nach Rechtsraum, Vertrag und Geschäftsfunktion.
- Benennen Sie verantwortliche Eigentümer für Genehmigung, Umsetzung und Überprüfung der Richtlinie.
- Lassen Sie geltende Fristen und Ausnahmen rechtlich sowie datenschutzrechtlich prüfen.
Welche Nachweise ein A2P-SMS-Versand erzeugt
Ein Aufbewahrungsinventar beginnt mit der Betrachtung des technischen Lebenszyklus einer Nachricht. Die ursprüngliche Anfrage kann Kontodaten, Zugangsdaten oder Integrationskontext, Ziel, Absender, Nachrichteninhalt, Versandparameter sowie vom Kunden oder von der Plattform erzeugte Kennungen enthalten. Die technische Annahme kann eine Nachrichten-ID, einen Zeitstempel und ein Validierungs- oder Warteschlangenergebnis erzeugen.
Während Routing und Verarbeitung können operative Entscheidungen, Fehlercodes, Versuche, Statusänderungen, Referenzen des Anbieters oder Netzwerks sowie Zeitstempel entstehen. Danach können Callbacks oder DLRs eingehen. Die Abstimmung ergänzt Datensätze, die Anfragen, Status, Ergebnisse, Verbrauch und mögliche Streitfälle miteinander verknüpfen.
Nicht alle diese Elemente sollten zusammen oder über denselben Zeitraum gespeichert werden. Ein Support-Team kann eine Korrelationskennung und eine Statusfolge benötigen, ohne den vollständigen SMS-Text zu brauchen. Ein Finanzteam kann Nachweise über abrechenbare Ereignisse benötigen, während eine Qualitätsanalyse auf aggregierten oder pseudonymisierten Daten beruhen kann.
- Anfrage: Konto- oder Kundenkontext, Ziel, Absender, Parameter, Inhalt und gegebenenfalls Quell-ID.
- Annahme: Nachrichten-ID, Uhrzeit, Validierungen und Ergebnis der Annahme.
- Verarbeitung: Warteschlangen-, Routing- und Fehlerereignisse, Wiederholungsversuche und Statusänderungen.
- DLRs und Callbacks: gemeldeter Status, Empfangszeit, korrelierbare Referenz und technischer Ursprung des Ereignisses.
- Abstimmung: Verknüpfungen zwischen Anfrage, Ereignissen, Ergebnis und erforderlichen administrativen Datensätzen.
Was ein DLR bedeutet – und was es nicht belegt
Ein DLR sollte als ein von der SMS-Infrastruktur gemeldetes Statusereignis behandelt werden. Die Spezifikation 3GPP TS 23.040 beschreibt den SMS-STATUS-REPORT als einen vom Service Center ausgegebenen Bericht nach Abschluss des Nachrichtenstatus, mit Ergebnissen wie einer erfolgreichen Zustellung an das SME oder der Unmöglichkeit einer erneuten Weiterleitung aufgrund temporärer oder permanenter Fehler.
Dieser Datensatz ist für Betrieb und Abstimmung wertvoll, entspricht jedoch nicht zwangsläufig einem unabhängigen Nachweis dafür, dass eine Person die Nachricht gelesen, verstanden oder darauf reagiert hat. Die genaue Semantik des empfangenen Status sollte zusammen mit Quelle, Zeitpunkt, Nachrichtenreferenz und jeder intern angewandten Umwandlung gespeichert werden.
Zudem ist die Verfügbarkeit von Statusberichten im SMS-Dienst optional. Deshalb sollte das Fehlen eines DLR nicht automatisch als Schlussfolgerung über die endgültige Zustellung gewertet werden. Eine ausgereifte Richtlinie unterscheidet zwischen „kein DLR empfangen“, „gemeldeten Status empfangen“, „Status intern normalisiert“ und „zusätzliche unabhängige Nachweise vorhanden“, falls solche existieren.
- Erfassen Sie nach Möglichkeit den ursprünglichen Statuswert.
- Bewahren Sie die technische Quelle und den Empfangszeitstempel des DLR auf.
- Dokumentieren Sie Regeln zur Statusnormalisierung, um mehrdeutige Interpretationen zu vermeiden.
- Stellen Sie ein DLR nicht als Nachweis für Lesen, Verstehen, Einwilligung oder Konversion dar.
- Klassifizieren Sie das Fehlen eines DLR ohne den anwendbaren technischen Kontext nicht als eindeutigen Fehler oder Erfolg.
Erstellen Sie ein Minimalinventar und klassifizieren Sie die Daten
Das Inventar sollte detailliert genug sein, um Aufbewahrung und Zugriff festzulegen, aber praktisch genug, um aktuell gehalten werden zu können. Eine nützliche Klassifizierung trennt Nachrichteninhalte, personenbezogene oder potenziell identifizierbare Kennungen, Routing-Metadaten, technische Ereignisse, Kontodaten und Kontrolldaten.
Der Inhalt erfordert in der Regel eine besonders strenge Prüfung. Er kann OTPs, Transaktionsbenachrichtigungen, Bestellreferenzen, Marketinginformationen oder je nach Anwendungsfall andere sensible Daten enthalten. Ihn standardmäßig für eine breite Fehleranalyse aufzubewahren, erhöht die Exposition und sollte nicht allein mit operativer Bequemlichkeit begründet werden.
Korrelationskennungen verringern die Notwendigkeit, sensible Daten in Dashboards, Tickets oder Exporten anzuzeigen. TS 23.040 sieht Nachrichtenreferenzen vor, die zusammenhängende Vorgänge verknüpfen; dies bietet eine technische Grundlage, Anfrage und Status zu korrelieren, ohne den Inhalt in jeder Ansicht zu reproduzieren.
- Inhalt: SMS-Text, Vorlagen, Variablen und gegebenenfalls Kontextanhänge.
- Kennungen: Nachrichten-ID, Kunden-ID, Anbieterreferenz, Kampagnenreferenz oder Korrelation.
- Metadaten: Ursprung, Ziel, Absender, Route oder Routing-Kontext, Zeitstempel und technische Parameter.
- Technische Ereignisse: Annahme, Status, Fehlercodes, Callback, Wiederholungsversuch und Verarbeitungsergebnis.
- Konto- und Kontrolldaten: Nutzer, Rolle, Organisation, Konfigurationsänderungen, Abfragen und Exporte.
Ordnen Sie jeder Kategorie einen konkreten Zweck zu
Der Zweck bestimmt, was und wie lange aufbewahrt wird. Der Support muss möglicherweise einen bestimmten Vorfall rekonstruieren; Abrechnung und Abstimmung benötigen möglicherweise Nachweise relevanter Ereignisse; Betrugsprävention und Sicherheit benötigen möglicherweise Signale zur Untersuchung auffälligen Verhaltens; Qualität benötigt möglicherweise Statusreihen und Latenzen; Audits benötigen möglicherweise Zugriffs- und Änderungsprotokolle; und ein Anspruch kann die Sicherung eines abgegrenzten Nachweissatzes erfordern.
Entscheidend ist, allgemeine Zwecke wie „vorsorglich“ oder „für künftige Analysen“ zu vermeiden. Beschreiben Sie die operative Nutzung, den Eigentümer, die Datenpopulation, die vorgeschlagene Frist und den Grund, warum eine weniger identifizierbare Version nicht ausreicht. Ersetzen Sie Ereignisdaten, wo möglich, durch aggregierte Kennzahlen, Zählwerte oder pseudonymisierte Datensätze.
Auch Abmelde- oder Widerrufsanfragen verdienen eine eigene Kategorie. In den Vereinigten Staaten erkennt die FCC bestimmte SMS-Antworten, darunter „stop“, „quit“, „end“, „revoke“, „opt out“, „cancel“ und „unsubscribe“, in den von ihrer Entscheidung erfassten Fällen als angemessene Mittel zum Widerruf einer Einwilligung an. Ihre Organisation muss die geltenden Regeln bewerten, operativ ist es jedoch sinnvoll, Eingang, Verarbeitung und Ergebnis dieser Ereignisse kontrolliert zu protokollieren.
- Support: einen abgegrenzten Vorfall lösen und Ereignisfolgen prüfen.
- Abstimmung: Anfragen, Status und relevante administrative Datensätze verknüpfen.
- Betrugsprävention und Sicherheit: Anomalien mit verhältnismäßigem und nachvollziehbarem Zugriff untersuchen.
- Qualität: DLR-Konsistenz, Verfügbarkeit, Fehler und technisches Verhalten mit minimierten Daten analysieren.
- Audit: nachweisen, wer zugegriffen, eine Konfiguration geändert oder einen Export durchgeführt hat.
- Ansprüche und Pflichten: nur den erforderlichen Umfang und mit einem Überprüfungsdatum sichern.
Wenden Sie ein Phasenmodell an: aktiv, eingeschränktes Archiv und endgültige Bereinigung
Ein Phasenmodell hilft zu verhindern, dass alle Datensätze unbegrenzt in operativen Systemen verbleiben. Die aktive Phase enthält die Daten, die für Monitoring, täglichen Support, unmittelbare Untersuchungen und operative Prozesse erforderlich sind. Sie sollte nur die kleinste Daten- und Nutzergruppe umfassen, die mit diesen Aufgaben vereinbar ist.
Nach Ende des unmittelbaren operativen Bedarfs können bestimmte Datensätze in ein eingeschränktes Archiv überführt werden, wenn ein dokumentierter Zweck fortbesteht, etwa Abstimmung, eine geltende Verpflichtung, ein konkreter Streitfall oder eine offene Untersuchung. Das Archiv ist keine automatische Verlängerung der Produktionsumgebung: Es muss die Zugriffsrollen reduzieren, Abfragefunktionen begrenzen und verhindern, dass Informationen für neue, nicht genehmigte Zwecke verwendet werden.
Nach Ende des Zwecks und jeder gültigen Ausnahme sollten Sie je nach erforderlichem Ergebnis löschen, anonymisieren oder aggregieren. NIST beschreibt Log-Management als fortlaufenden organisatorischen Prozess, und seine Leitlinien zur Sanitization betonen, dass eine wirksame Löschung geeignete Maßnahmen entsprechend der Sensibilität sowie die Validierung der Bereinigung erfordert.
- Aktive Phase: Verfügbarkeit für den täglichen Betrieb mit rollenbasiertem Zugriff.
- Eingeschränktes Archiv: außergewöhnlicher, begründeter und protokollierter Zugriff.
- Endgültige Bereinigung: überprüfbare Löschung, gegebenenfalls irreversible Anonymisierung oder Aggregation ohne identifizierenden Bedarf.
- Überprüfung: prüfen Sie regelmäßig, dass Datensätze nicht aus Trägheit in einer Phase verbleiben.
- Ausnahme: wenden Sie eine begrenzte Aufbewahrung auf einen abgegrenzten Datensatz an, mit Eigentümer und Datum zur Neubewertung.
Wie Sie Fristen festlegen, ohne eine willkürliche Zahl zu übernehmen
Es gibt keine universelle, technisch gültige Aufbewahrungsfrist für Logs, DLRs oder SMS-Inhalte. Die Entscheidung muss vom konkreten Zweck ausgehen und mit geltenden rechtlichen, regulatorischen, steuerlichen, vertraglichen und prozessualen Pflichten abgeglichen werden. Dass eine Kategorie nützlich ist, rechtfertigt keine unbegrenzte Speicherung; auch eine branchenübliche Zahl ersetzt keine dokumentierte Analyse.
Formulieren Sie für jede Kategorie überprüfbare Fragen: Welche Entscheidung, welcher Vorfall oder welcher Prozess lässt sich mit diesen Daten lösen? Wann werden sie für diesen Zweck nicht mehr benötigt? Gibt es eine geltende Verpflichtung, die eine Aufbewahrung verlangt oder erlaubt? Kann der Zweck mit pseudonymisierten, aggregierten Daten oder weniger Feldern erreicht werden? Welcher Schaden entstünde durch eine vorzeitige Löschung im Vergleich zur zusätzlichen Exposition bei längerer Speicherung?
Dokumentieren Sie die Begründung, nicht nur das Ergebnis. Wenn die Frist je nach Kundentyp, Rechtsraum, Produkt, Vertrag oder Verkehrsart variiert, muss die Richtlinie diese Unterschiede und den technischen Mechanismus zu ihrer Umsetzung abbilden.
- Exakter Zweck und genaue Datenpopulation.
- Geltende Pflichten und Zusagen, geprüft durch die zuständigen Funktionen.
- Tatsächlicher betrieblicher Bedarf und zeitliches Nutzungsfenster.
- Weniger identifizierbare Alternativen wie Pseudonymisierung oder Aggregation.
- Risiken für Datenschutz, Sicherheit, Betrug, Ansprüche und Verlust von Nachweisen.
- Technische Fähigkeit, die Frist über Systeme, Replikate und Kopien hinweg einheitlich anzuwenden.
- Entscheidungseigentümer, Genehmigungsdatum und Überprüfungsdatum.
Kontrollieren Sie den Zugriff und verringern Sie die Exposition von Inhalten
Logs sind nicht automatisch unbedenklich. Eine Kombination aus Ziel, Uhrzeit, Absender, Kontokennung und Zustellergebnis kann Aktivitätsmuster offenlegen. Inhalte können das Risiko erheblich erhöhen. Deshalb sollte der Zugriff auf Rollen, Need-to-know und Funktionstrennung beruhen.
Ein Support-Mitarbeiter sollte nicht standardmäßig dieselben Möglichkeiten erhalten wie ein Sicherheitsadministrator, ein Verantwortlicher für Abstimmung oder eine Person, die zur Beantwortung einer rechtlichen Anfrage berechtigt ist. Gestalten Sie Ansichten mit minimierten Feldern: beispielsweise Korrelationskennungen, Status und Zeitstempel statt vollständiger Inhalte oder Massenexporte.
Protokollieren Sie sensible Abfragen, außergewöhnliche Zugriffe, Suchen nach personenbezogenen Kennungen, Änderungen der Aufbewahrung und Exporte. Die Nachvollziehbarkeit von Zugriffen dient sowohl der Sicherheit als auch der Rechenschaftspflicht. Überprüfen Sie regelmäßig Berechtigungen, privilegierte Konten und Zugriffsbegründungen.
- Verwenden Sie getrennte Rollen für Support, Betrieb, Sicherheit, Datenschutz, Finanzen und Administration.
- Zeigen Sie Inhalte nur an, wenn dies für einen autorisierten Fall erforderlich ist.
- Nutzen Sie, wo möglich, Maskierung oder Feldreduzierung in Dashboards und Tickets.
- Verlangen Sie eine Begründung und Protokollierung für außergewöhnlichen Zugriff auf sensible Daten.
- Beschränken Sie Exporte, protokollieren Sie ihre Ausführung und schützen Sie das Ziel exportierter Daten.
- Überprüfen Sie Berechtigungen und privilegierte Zugriffe regelmäßig.
Häufige Fragen
Gibt es eine Standardfrist für die Aufbewahrung von A2P-SMS-Logs und DLRs?
Nein. Die Frist sollte vom Zweck, den geltenden Verpflichtungen sowie der rechtlichen und operativen Bewertung jeder Organisation abhängen. Soweit die DSGVO gilt, dürfen identifizierbare personenbezogene Daten nur so lange gespeichert werden, wie es für die Zwecke der Verarbeitung erforderlich ist.
Bestätigt ein DLR, dass der Empfänger die SMS gelesen hat?
Nein. Ein DLR ist ein von der SMS-Infrastruktur gemeldetes Statusereignis. Es kann für Betrieb und Abstimmung nützlich sein, belegt aber nicht unabhängig, dass eine Person die Nachricht gelesen, verstanden oder darauf reagiert hat.
Beweist das Fehlen eines DLR, dass die Nachricht nicht zugestellt wurde?
Nicht unbedingt. Die Funktion für Statusberichte ist bei SMS optional. Das Fehlen eines DLR sollte als Fehlen dieses Ereignisses erfasst und nicht automatisch als schlüssiger Nachweis eines Zustellfehlers interpretiert werden.
Sollte der Inhalt einer SMS zur Lösung von Vorfällen aufbewahrt werden?
Nicht standardmäßig. Prüfen Sie, ob sich der Vorfall mit Korrelationskennungen, Statuswerten, Zeitstempeln, Fehlercodes und minimierten Metadaten lösen lässt. Inhalte sollten strengere Kontrollen und einen restriktiveren Zugriff haben, wenn sie tatsächlich erforderlich sind.
Garantiert das Löschen eines Datensatzes aus der Hauptdatenbank die vollständige Löschung?
Nein, nicht allein. Auch Replikate, Archive, Sicherungskopien, Exporte und andere Speichermedien müssen berücksichtigt werden. Die Löschung sollte geeigneten Sanitization-Kontrollen und Prüfungen folgen, die belegen, dass die Bereinigung gemäß Richtlinie ausgeführt wurde.
Was sollte eine Aufbewahrungsausnahme enthalten?
Mindestens den betroffenen Datensatz, den konkreten Zweck, den Eigentümer, die geltende Grundlage, die autorisierten Rollen, das Startdatum, das Überprüfungsdatum und das Ereignis, das den Abschluss der Ausnahme ermöglicht. Eine Ausnahme sollte nicht zu einer unbegrenzten und allgemeinen Aufbewahrung werden.
Verwendete Quellen
- GDPR — principios de limitación de finalidad, minimización y limitación del plazo de conservación (artículo 5)EUR-Lex / Unión Europea
- 3GPP TS 23.040 — capacidades de informes de estado SMS y relación con referencias de mensaje3GPP / ETSI
- NIST SP 800-92 — Guide to Computer Security Log ManagementNational Institute of Standards and Technology
- NIST SP 800-88 Rev. 2 — Guidelines for Media SanitizationNational Institute of Standards and Technology
- FCC 24-24 — revocación de consentimiento mediante respuesta por SMSFederal Communications Commission
- NIST Privacy FrameworkNational Institute of Standards and Technology
- NIST SP 800-63-4 — Digital Identity GuidelinesNational Institute of Standards and Technology