Lösch- und Aufbewahrungsinformationen.

Lösch- und Aufbewahrungsinformationen zum Auftragsverarbeitungsvertrag gemäß Art. 28 DSGVO Version 1 – Stand: 04. September 2026 1. Zweck und Grundprinzip Diese Anlage beschreibt den zum Stand dieser Fassung belegten Umgang mit Löschung, Sperrung, Wiederherstellung und Aufbewahrung von personenbezogenen Auftragsdaten in CollabPoint. Dabei wird ausdrücklich unterschieden zwischen: 1. fachlicher Entfernung bzw. Soft Delete innerhalb von CollabPoint, 2. Löschung eines Base44 Data Records, 3. physischer Löschung eines Datei- oder Media-Storage-Objekts, 4. Auslauf aus Backups oder sonstigen Providerkopien. Diese Ebenen sind technisch nicht identisch. CollabPoint bestätigt eine physische Löschung oder Backup-Löschung nur, soweit sie für den konkreten Datenbereich belastbar nachgewiesen ist. 2. Aktuell belegter Base44-Löschstand Nach der dokumentierten Base44-Support-Evidence gilt für gelöschte Data Records: - gelöschte Data Records verbleiben zunächst für 30 Tage in „Recently Deleted“, - danach werden sie laut Base44 dauerhaft gelöscht. Diese 30-Tage-Aussage bezieht sich auf Base44 Data Records. Sie ist kein Nachweis dafür, dass zugehörige physische Datei- oder Media-Objekte, Backups, Logs oder externe Empfängerkopien im selben Zeitpunkt physisch gelöscht werden. Für die individuelle physische Löschung einzelner Base44-Datei- oder Blob-Objekte ist im aktuell verifizierten SDK- und API-Stand von CollabPoint keine allgemein verfügbare und getestete Delete-Capability nachgewiesen. CollabPoint stellt eine physische Storage-Löschung daher nicht als abgeschlossen dar, solange hierfür kein belastbarer Nachweis vorliegt. 3. Löschung während der laufenden Nutzung 3.1 Normale Fachdatensätze Werden fachliche Datensätze über eine zulässige CollabPoint-Löschfunktion gelöscht, wird der jeweilige Base44-Record aus der aktiven Anwendung entfernt. Soweit Base44 diesen Record in „Recently Deleted“ führt, gilt anschließend der dokumentierte 30-Tage-Providerzeitraum. Die Wirkung auf abhängige Datensätze wird durch den jeweiligen Produktflow bestimmt. Ein einzelner Delete-Aufruf bedeutet nicht automatisch, dass sämtliche abhängigen Inhalte, Dateien, Vorschaudaten, Kommentare oder Logs mitgelöscht werden. 3.2 Dokumenten-Papierkorb Das Verschieben einer Dokumentbibliothek, eines Ordners oder eines Dokuments in den CollabPoint-Papierkorb ist Soft Delete. Dabei werden im aktuellen Produkt unter anderem: - Ordner oder Dokumente als „trashed“ markiert, - zugehörige Preview-Sheets soweit erfasst ebenfalls als „trashed“ markiert, - aktive öffentliche Bibliotheks- oder Ordnerlinks im betroffenen Bereich widerrufen, - neue Zugriffe auf getrashte private Dokumente über die normalen Read-Model- und Signed-URL-Pfade verhindert. Beim Papierkorb werden die zugrunde liegenden Storage-Dateien nicht allein durch die Papierkorbverschiebung physisch gelöscht. Eine Wiederherstellung ist vorgesehen, solange die betreffenden Records noch vorhanden sind. 3.3 Dauerhaftes Löschen leerer Ordnerstrukturen Für vollständig leere, bereits getrashte Ordnerbäume besteht ein Hard-Delete-Pfad für die betreffenden Folder-Records. Dieser Pfad ist auf Strukturen ohne verbleibende Storage-Referenzen beschränkt. Damit wird nicht behauptet, dass beliebige Dokumentbibliotheken einschließlich ihrer physischen Dateien bereits vollständig physisch löschbar sind. 4. Dateien, Medien und Storage-Orphans CollabPoint verwendet private und öffentliche Base44-Dateispeicherpfade. Wenn eine Datei fachlich ersetzt, entfernt oder nach einem fehlgeschlagenen Verarbeitungsschritt nicht mehr sicher referenziert wird, kann CollabPoint einen StorageOrphanRecord anlegen. Dieser dokumentiert, dass ein Storage-Objekt möglicherweise ohne aktive fachliche Referenz zurückgeblieben ist. Dieser Orphan-Nachweis ist keine physische Löschung. Solange keine verifizierte Plattformfunktion zur individuellen physischen Blob-Löschung vorliegt: - wird die physische Einzeldateilöschung nicht als durchgeführt bestätigt, - werden bekannte Orphan-Fälle operativ nachverfolgt, - wird der physische Storage-Status in Löschbestätigungen transparent ausgewiesen. 5. Öffentliche Freigaben und Links Bei Löschung, Papierkorbverschiebung oder Kontoschließung werden kontrollierbare öffentliche Freigaben soweit vom jeweiligen Produktflow vorgesehen deaktiviert oder widerrufen. Hierzu können insbesondere gehören: - Space-Freigabetokens, - Document-Library-Public-Links, - veröffentlichte Website- oder Page-Layouts, - öffentliche Profile. Das Widerrufen eines CollabPoint-Links kann keine Kopien zurückholen, die ein Empfänger bereits heruntergeladen, exportiert, weitergeleitet oder außerhalb der Plattform gespeichert hat. Gleiches gilt für außerhalb der CollabPoint-Kontrolle liegende Caches. 6. Kontoschließung Für die Kontoschließung besteht ein kontrollierter Prozess. Bei einer Self-Service-Kontoschließungsanfrage wird im aktuell verifizierten Stand insbesondere: - der Accountzugriff geschlossen, - das öffentliche Profil deaktiviert, - veröffentlichte eigene Page-Layouts soweit möglich deaktiviert, - öffentliche Space-Freigaben widerrufen, - aktive Document-Library-Public-Links widerrufen, - öffentliche Dokumentbibliotheken gegen weiteren öffentlichen Zugriff gesperrt, - ein AccountClosureRequest angelegt, - eine Auditspur erzeugt, - ein Review gemeinsam genutzter geschäftlicher Daten vorgesehen. Gemeinsam genutzte Geschäftsdaten werden bei Kontoschließung nicht blind gelöscht. Vor einer endgültigen Bereinigung wird geprüft, ob Daten weiterhin zu einem geschäftlichen Mandantenkontext, Kundenprojekt, einer Rechnung, einem gemeinsamen Chat oder einer anderen legitimen gemeinsamen Verarbeitung gehören. Soweit die physische Storage-Löschung technisch nicht belastbar verfügbar und verifiziert ist, wird sie nicht als abgeschlossen bestätigt. 7. Vertragsende und Löschweisung eines Plattformkunden Nach Ende der Auftragsverarbeitung bzw. einer wirksamen Löschweisung werden die betroffenen Auftragsdaten nach Maßgabe des AVV und dieser Anlage zurückgegeben, gesperrt, anonymisiert oder gelöscht, soweit keine gesetzliche Pflicht oder ein zulässiger dokumentierter Hold entgegensteht. Der operative Ablauf umfasst, soweit für den konkreten Mandanten relevant und technisch verfügbar, insbesondere: 1. Identitäts-, Rollen- und Mandantenprüfung, 2. Prüfung von Aufbewahrungspflichten, Rechts- oder Security-Holds und gemeinsam genutzten Daten, 3. Sperrung von Zugängen und öffentlichen Freigaben, 4. Export bzw. Rückgabe unterstützter Daten, soweit vereinbart, 5. Löschung kontrollierbarer aktiver Data Records, 6. Dokumentation bekannter Storage-Orphans und nicht sofort physisch löschbarer Objekte, 7. Dokumentation des 30-Tage-„Recently Deleted“-Auslaufs für gelöschte Data Records, 8. Dokumentation verbleibender Provider- oder Backup-Ausläufe, soweit bekannt, 9. Löschbestätigung mit ausgewiesenen Ausnahmen bzw. noch offenen technischen Ausläufen. 8. Datenbereichsmatrix Projekte, Orders, Tasks und ähnliche Fachrecords: aktiv solange benötigt; kontrollierter Record-Delete nach Berechtigung; nach Record-Delete laut Base44 30 Tage „Recently Deleted“, danach dauerhafte Record-Löschung. Chats und Kommentare: aktiv solange benötigt; Löschung je nach Produktflow; nach Record-Delete gilt der Base44-Record-Löschzyklus, abhängige Daten sind separat zu prüfen. Dokument- und Ordner-Metadaten: aktiv oder im Papierkorb; Papierkorb zunächst Soft Delete; Restore möglich; bei echtem Record-Delete gilt der Base44-30-Tage-Zyklus. Private Dateiobjekte: Storage-Objekt plus private Referenz; Referenz kann entzogen bzw. der Fachrecord gelöscht werden; individuelle physische Blob-Löschung ist derzeit nicht allgemein belastbar verifiziert. Öffentliche Dateiobjekte: öffentliche Storage-URL je nach Funktion möglich; kontrollierbare Links und Referenzen können gesperrt werden; bereits externe Downloads und Kopien sind nicht rückholbar; physische Einzelobjekt-Löschung ist nicht allgemein belastbar verifiziert. Preview-Sheets, Thumbnails und Storyboards: abhängig vom jeweiligen Dokumentflow; Trash- und Metadatenlogik vorhanden; keine pauschale physische Löschfrist zugesichert. Share- und Public-Link-Records: aktiv bis Widerruf oder Ablauf; Tokenentzug bzw. flow-spezifische Sperre möglich; externe Kopien werden nicht erfasst. Organisationen und Mitgliedschaften: solange für Zusammenarbeit erforderlich; Löschung nur nach Rollen- und Tenantprüfung; gemeinsam genutzte Geschäftsdaten werden nicht blind mit einem Nutzeraccount gelöscht. Angebote, Rechnungen und Ausgaben: solange fachlich oder rechtlich erforderlich; Löschung nur nach Prüfung; gesetzliche oder kundenseitige Aufbewahrung kann Löschung überlagern; Storageanhänge sind separat zu behandeln. Account- und Vertragsdaten von CollabPoint selbst: liegen außerhalb bzw. teilweise außerhalb des AVV und richten sich nach Datenschutzerklärung, Vertrags- und gesetzlichen Pflichten. Audit- und Security-Evidence: zweckgebunden; Löschung oder Anonymisierung nach Security-, Nachweis- und gesetzlichen Erfordernissen; keine pauschale feste technische Retention zugesichert. KI-Konversationen und vorgelagerte LLM- oder Provider-Logs: produktseitige Records und vorgelagerte Providerketten sind getrennt zu betrachten; exakte vorgelagerte Retention ist derzeit nicht einheitlich belastbar bestätigt. Backups: Provider- und Disaster-Recovery-Ebene; kein normaler Nutzer-Direktzugriff; konkrete Backup-Retention und Backup-Region sind derzeit nicht belastbar bestätigt. 9. Gesetzliche oder sonstige zulässige Zurückbehaltung Soweit Daten trotz Löschweisung aufgrund einer gesetzlichen Aufbewahrungspflicht, eines dokumentierten Rechtsstreits, einer Sicherheitsuntersuchung oder eines anderen rechtlich zulässigen Zwecks vorübergehend aufbewahrt werden müssen, werden sie soweit technisch und organisatorisch möglich für den ursprünglichen operativen Zweck gesperrt bzw. in ihrer Verwendung beschränkt. Die Zurückbehaltung ist auf die jeweils erforderlichen Daten und den erforderlichen Zeitraum zu begrenzen. 10. Backups Für Base44-Backups ist im aktuellen CollabPoint-Stand keine belastbare konkrete Aufbewahrungs- oder Überschreibungsfrist und keine bestätigte Backup-Speicherregion dokumentiert. CollabPoint verpflichtet sich deshalb in dieser Fassung auf keine bestimmte Frist oder Region. Soweit gelöschte Daten noch in nicht produktiv zugänglichen Backups enthalten sein können, dürfen sie bei einer Wiederherstellung nicht erneut dauerhaft in den aktiven Betrieb übernommen werden; erforderliche Nachbereinigungen sind im Wiederherstellungsprozess zu berücksichtigen. 11. KI-, LLM- und Logging-Retention Für vorgelagerte KI-, LLM- und bestimmte Logging-Komponenten ist derzeit keine einheitliche konkrete Aufbewahrungsfrist belegt, die CollabPoint gegenüber Plattformkunden pauschal zusichern könnte. Daher wird keine pauschale Zusage einer bestimmten LLM-, Prompt-, Output- oder Logging-Retention gegeben, solange diese für die tatsächlich verwendete Verarbeitungskette nicht belastbar dokumentiert ist. 12. Löschbestätigung Auf angemessene Anfrage kann CollabPoint eine Löschbestätigung für eine mandantenbezogene Bereinigung bereitstellen. Sie soll, soweit einschlägig, insbesondere enthalten: - Vertrags- oder Mandantenreferenz, - Datum und Umfang der Weisung, - deaktivierte Zugänge, öffentliche Links und Tokens, - gelöschte oder gesperrte Data-Record-Bereiche, - Beginn bzw. voraussichtliches Ende des 30-Tage-„Recently Deleted“-Auslaufs, - bekannte noch offene Storage-Orphans bzw. physische Storage-Einschränkungen, - gesetzlich oder aus zulässigem Hold zurückbehaltene Daten, - bekannte noch offene Backup- oder Provider-Ausläufe, - Datum und Prüfreferenz des Abschlusses. Eine Löschbestätigung bestätigt keine vollständige physische Löschung sämtlicher Kopien, solange dies für Storage, Backups und Providerketten nicht belastbar belegt ist. 13. Aktuell nicht zugesicherte Parameter Derzeit werden insbesondere keine weitergehenden festen Zusagen gemacht zu: - individueller physischer Löschung sämtlicher Base44 Media- oder Blob-Objekte, - konkreter Backup-Region und Backup-Retention, - vollständiger End-to-End-Mandantenlöschung über sämtliche DB-, Storage-, Preview-, Public-Link-, Log- und Backup-Ebenen, - konkreter Retention der tatsächlich verwendeten KI-, LLM- und Logging-Anbieter. 14. Einbezogene Fassung In AVV Version 1 einbezogene Fassung: Lösch- und Aufbewahrungsinformationen, Version 1 vom 04.09.2026.