Skip to main content

​
Domänenbezogene Datenaufbewahrungsrichtlinie

Die Datenaufbewahrungsrichtlinie bestimmt, wie lange drei Klassen von Datensätzen in Ihrem Workspace intakt bleiben, bevor geplante Bereinigungen sie maskieren oder löschen. Es sind drei unabhängige Domänen hinter einem Endpunktpaar – Maskierung von Nachrichteninhalten, hartes Löschen geschlossener Konversationen und Bereinigung des Audit-Logs – jede mit ihrem eigenen Fenster und ihren eigenen erlaubten Mindest- und Höchstwerten. Alle drei Domänen sind standardmäßig deaktiviert: Ein Workspace, der diese Oberfläche nie berührt, hat kein automatisches Aufbewahrungsverhalten.
Diese Seite beschreibt die Plattformsteuerungen von Orbit. Sie ist keine Rechtsberatung. Wie lange Sie Nachrichten, Konversationen und Audit-Nachweise aufbewahren dürfen oder müssen, hängt von Ihren Aufsichtsbehörden, Ihren Verträgen und der Auslegung derselben durch Ihren Rechtsbeistand ab. Klären Sie die Einzelheiten mit qualifiziertem Rechtsbeistand.

​
Die drei Domänen

Jede Domäne beantwortet eine Frage der Speicherbegrenzung, und Sie können jede beliebige Kombination von ihnen aktivieren.

​
Maskierung von Nachrichteninhalten (messages)

Nach der von Ihnen konfigurierten Anzahl von Tagen ersetzt eine geplante Bereinigung den Nachrichtentext und die Empfänger-/Absenderkennungen durch einen Maskierungsmarker. Abrechnungsrelevante Metadaten – Status, Segmentanzahl, Preis, Carrier-Fehler – sowie der Zustellbeleg und der Audit-Trail bleiben intakt, sodass Finanz- und Streitfälle auch auf maskierten Zeilen weiter prüfbar sind. Setzen Sie das Fenster auf 0, um die Bereinigung zu deaktivieren; jeder aktivierte Wert muss innerhalb der erlaubten Grenzen liegen.
  • Erlaubtes Fenster: 7 bis 3650 Tage (oder 0 zum Deaktivieren).

​
Hartes Löschen geschlossener Konversationen (conversations)

Wenn aktiviert, löscht eine geplante Bereinigung eine Konversationszeile endgültig, sobald sie länger als Ihr Fenster geschlossen ist. Die mit der Konversation verbundenen Nachrichtenzeilen werden nicht mitgelöscht, sodass Abrechnungs- und Audit-Metadaten die Bereinigung überleben. Nur geschlossene Konversationen kommen in Frage; ein offener Thread wird nie bereinigt.
  • Erlaubtes Fenster: 30 bis 3650 Tage. Die 30-Tage-Untergrenze verhindert eine Bereinigung einer Konversation, die erst vor Stunden geschlossen wurde.
  • Wenn Sie diese Domäne ohne Fenster aktivieren, gilt der Plattformstandard von 180 Tagen.

​
Bereinigung des Audit-Logs (audit_logs)

Wenn aktiviert, löscht eine geplante Bereinigung Audit-Log-Einträge, die älter als Ihr Fenster sind. Audit-Logs sind die Nachweiskette für jede Konfigurationsänderung in Ihrem Workspace, daher trägt diese Domäne eine regulatorische Untergrenze.
  • Erlaubtes Fenster: 365 bis 3650 Tage. Die 365-Tage-Untergrenze schützt das SOC-2-Prüfungsfenster – Sie können Audit-Nachweise, die jünger als ein Jahr sind, nie bereinigen.
  • Wenn Sie diese Domäne ohne Fenster aktivieren, gilt der Plattformstandard von 2190 Tagen (sechs Jahre), ausgerichtet auf die Aufbewahrungserwartung von HIPAA.
Die DSAR-Löschung ist von dieser altersbasierten Richtlinie getrennt. Eine Betroffenenanfrage auf Kontaktebene durchläuft ihren eigenen Workflow unabhängig von diesen organisationsweiten Fenstern – siehe Betroffenenrechte-Anfragen.

​
Die aufgelöste Richtlinie lesen

Die Antwort gibt stets den aufgelösten Wert für jede Domäne zurück, plus einem bounds-Objekt mit dem erlaubten Min-/Max-Fenster für jede – dieselben Werte, mit denen das Dashboard Eingaben begrenzt. Lesen erfordert eine beliebige authentifizierte Rolle; ein frischer Workspace liefert die obigen Standards mit allen drei Domänen deaktiviert zurück.

​
Die Richtlinie schreiben

Schreibvorgänge erfordern einen **Owner- oder Admin-**API-Schlüssel oder eine entsprechende Dashboard-Rolle – Aufbewahrung ist eine regulatorische Steuerung, daher spiegelt das Gate die übrige Compliance-Schreiboberfläche. Jede andere Rolle erhält 403. Der Schreibvorgang ist merge-on-write: Jeder Domänenblock ist optional, und ein Block, den Sie auslassen, behält seinen gespeicherten Wert. Senden Sie nur die Domänen, die Sie ändern möchten.
Regeln, gegen die Sie bauen:
  • Mindestens eine Domäne angeben – ein leerer Body liefert 422 VALIDATION_ERROR.
  • Werte im Bereich werden strikt validiert. Ein aktivierter redact_body_after_days-Wert außerhalb der Grenzen oder ein Fenster außerhalb seines Min/Max liefert 422 mit einem Feldfehler.
  • Die Auflösung ist tolerant bei Aktivieren ohne Fenster. Bei conversations und audit_logs führt das Senden von enabled: true ohne Fenster zum Plattformstandard (bzw. 180 und 2190 Tage); die aufgelösten Werte sind die, welche die Bereinigungen verwenden, und die Antwort eines Schreibvorgangs ist dieselbe aufgelöste Ansicht wie GET.
  • Jede Änderung wird aufgezeichnet. Jeder Schreibvorgang landet in Ihrem Audit-Log mit den geänderten Domänen und dem Akteur, und erhält so die Governance-Spur für die Richtlinie selbst.

​
Ausführungsmodell: Bereinigungen, keine sofortige Löschung

Der Endpunkt speichert nur die Richtlinie. Das Schreiben eines 90-Tage-Fensters maskiert nichts in dem Moment, in dem Sie es speichern – die Durchsetzung läuft in geplanten Hintergrundbereinigungen, die Ihre aufgelöste Richtlinie im eigenen Rhythmus anwenden. Planen Sie Ihre Runbücher entsprechend:
  • Ein Datensatz, der älter als sein Fenster ist, wird für die Bereinigung berechtigt und wird bei der nächsten Bereinigung maskiert oder gelöscht – nicht in dem Moment, in dem er das Fenster überschreitet.
  • Das Verschärfen eines Fensters (z. B. von 365 auf 90 Tage) stellt die neu über dem Fenster liegenden Datensätze für die nächste Bereinigung in die Warteschlange. Es ist keine synchrone Löschung.
  • Das Lockern oder Deaktivieren eines Fensters stoppt künftige Bereinigungen daran, über das neue Richtlinienmaß hinaus zu maskieren oder zu löschen; bereits maskierte oder gelöschte Datensätze werden nicht wiederhergestellt.
Lesen Sie die Richtlinie mit GET zurück, um die aufgelösten Werte zu bestätigen, bevor Sie sie in einem internen Verfahren nutzen.

​
DSGVO Art. 5 Abs. 1 lit. e: Warum die Richtlinie existiert

Artikel 5(1)(e) der DSGVO rahmt die Speicherbegrenzung: Personenbezogene Daten müssen in einer Form aufbewahrt werden, die die Identifizierung der betroffenen Personen nicht länger zulässt, als nötig für die Zwecke, für die sie erhoben wurden. Für einen CPaaS-Betreiber sind die Datensätze, die dieses Prinzip anziehen, genau die drei Domänen auf dieser Seite – Nachrichtentexte tragen Kundeninhalte, Konversationen tragen den Thread-Verlauf und Audit-Logs tragen die Workspace-Spur. Die domänenbezogene Richtlinie existiert, damit Sie eine Speicherbegrenzungshaltung als Konfiguration ausdrücken können: kurze Fenster, wo Minimierung zählt (Nachrichtentexte), längere Fenster, wo eine regulatorische Untergrenze dagegen spricht (Audit-Logs), und jede Domäne unabhängig erreichbar, weil eine einzelne globale TTL nie für alle drei passt. Die 365-Tage-Audit-Untergrenze ist ein Beispiel dafür, dass die Plattform ein regulatorisches Minimum für Sie hält – sie verhindert, dass ein falsch gesetztes Fenster SOC-2-Nachweise zerstört, und begrenzt nicht, wie aggressiv Ihre Haltung anderswo sein kann. Ihr Rechtsbeistand entscheidet die Fenster. Die Plattform setzt sie durch und zeichnet jede Änderung an der Richtlinie selbst auf.

​
Wechselwirkung mit rechtlichen Sperren und Archiv-Export

Aufbewahrungsbereinigungen sind Löschmaschinen und teilen sich daher den Raum mit zwei Erhaltungssteuerungen:
  • Rechtliche Sperren. Eine Sperre auf einer Konversation nimmt diesen Thread von der Aufbewahrungsmaschine aus, solange die Sperre besteht – die Bereinigung überspringt sie. Eine Sperre ist die Haltung zur Prozessbewahrung; die Aufbewahrungsrichtlinie ist die Haltung des Normalbetriebs, und die Sperre gewinnt, solange sie steht. Setzen Sie die Richtlinie für den Workspace-Standard und nutzen Sie Sperren für die Ausnahmen.
  • Unveränderbarer Archiv-Export. Das Archiv kopiert Nachrichten und Anrufaufzeichnungen in ein manipulationssich eres Bündel in Ihrem eigenen WORM- oder S3-Speicher. Wenn Ihre Verpflichtungen Ihre Aufbewahrungsfenster überdauern, archivieren Sie vor Beginn der Löschungen – Aufbewahrung beantwortet „wie lange hält Orbit dies vor”, Archiv beantwortet „wie halte ich meine eigene Kopie”.
  • Löschanfragen. DSAR-Löschung läuft kontaktbezogen und unabhängig von dieser altersbasierten Richtlinie; gleichen Sie offene Löschanfragen mit Sperren im Rahmen Ihres DSAR-Prozesses ab, statt zu erwarten, dass die Aufbewahrungsfenster sie erfüllen.

​
Ihre Aufbewahrungshaltung bleibt Ihre

Die domänenbezogene Aufbewahrungsrichtlinie ist eine mandanteneigene Steuerung: Orbit stellt die Fenster, die Bereinigungen und den Audit-Trail bereit – was die Fenster sind und welche Domänen auf Ihre Haltung zutreffen, ist Ihre Entscheidung. Alle drei Domänen bleiben deaktiviert, bis Sie sie aktivieren, und jede Aktivierung, Änderung und Deaktivierung ist eine Entscheidung Ihrer Owner und Admins, aufgezeichnet in Ihrem Audit-Log. Für die breitere Zusammenstellung – Consent-Aufzeichnungen, DSAR-Eingang, das Register, das Evidenzheft – gehen Sie den DSGVO-Haltungs-Leitfaden.

​
Verwandtes

Aufbewahrungsfenster und Löschung

Die store-übergreifende Lebenszykluskarte, die diese Haltungsseite voraussetzt – Fenster jedes Speichers, Ablaufverhalten und die Erhaltungssteuerungen.

Rechtliche Sperren

Eine Konversation für die Prozessbewahrung von Aufbewahrungsbereinigungen ausnehmen.

Unveränderbarer Archiv-Export

Datensätze in ein manipulationssicheres Bündel kopieren, bevor die Bereinigungen sie löschen.

DSGVO-Haltungs-Leitfaden

Die vollständige DSGVO-Haltung zusammenstellen – Consent, DSAR, das Register und das Heft.

Betroffenenrechte-Anfragen

Kontaktbezogener Zugriff und Löschung und wie man sie mit Sperren abstimmt.