Technische und organisatorische Maßnahmen (TOM)

1. Geltungsbereich und Zweck

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen (TOM), mit denen MousePlayer ein dem Risiko angemessenes Schutzniveau nach Art. 32 DSGVO sicherstellt. Es gilt für jede Verarbeitung von Endnutzerdaten im Auftrag eines Verantwortlichen (Kunden).

Betreiber des Dienstes: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82 lok. 301, 90-437 Łódź, Polen · NIP PL7252266190.

2. Vertraulichkeit – Zutritt, Zugang, Zugriff

2.1 Zutrittskontrolle

Der Dienst läuft auf eigener Hardware in Łódź, Polen. Ein Rechenzentrums-, Cloud- oder Hostinganbieter ist am Betrieb selbst nicht beteiligt. Die Server werden im Eigenbetrieb in geschlossenen Räumlichkeiten innerhalb Polens betrieben. Zutritt hat ausschließlich der Verantwortliche selbst. Der Raum ist mit Schlüssel abgesperrt und videoüberwacht; weitere Personen — auch Vermieter oder Reinigungsdienste — haben keinen Zutritt (Angabe des Verantwortlichen, 17.08.2026). Die genaue Anschrift ist hier bewusst nicht genannt.

2.2 Zugangskontrolle

• Der Zugang zur Anwendung setzt ein persönliches Benutzerkonto mit Passwort voraus; Passwörter werden als gesalzene Hashwerte gespeichert, niemals im Klartext.
• Administrative Oberflächen sind von der Kundenanwendung getrennt und nur Superadministratoren zugänglich; die Berechtigung wird auf dem Server geprüft.
• Zustandsändernde Anfragen der angemeldeten Weboberfläche sind durch CSRF-Merkmale geschützt; Programmierschnittstellen authentifizieren sich mit eigenen Schlüsseln.
• Die Serververwaltung erfolgt per SSH mit Schlüsselauthentifizierung.
• Die Anmeldung lässt sich auf Wunsch mit einem zweiten Faktor schützen (zeitbasierte Einmalcodes nach RFC 6238). Das Geheimnis wird verschlüsselt gespeichert, Wiederherstellungscodes nur als Hashwerte; ein bereits verwendeter Code wird kein zweites Mal angenommen, und wiederholte Fehlversuche sperren den zweiten Faktor des Kontos zeitweise.
• Jede Anmeldung wird einzeln geführt (login_sessions). Der Kontoinhaber sieht die Liste in den Einstellungen und kann einzelne oder alle anderen Anmeldungen widerrufen; der Widerruf beendet auch eine laufende Sitzung und ein gespeichertes Anmeldemerkmal. Eine Passwortänderung beendet alle übrigen Anmeldungen. Meldet sich ein Konto von einem unbekannten Gerät an (Abdruck aus Browser, Betriebssystem, Geräteart und Netzbereich /24 bzw. /48 der IP-Adresse), erhält der Inhaber eine E-Mail.

2.3 Zugriffskontrolle (Berechtigungen)

• Ein Rollenmodell (owner, admin, viewer) bestimmt, was ein Nutzer innerhalb eines Workspace sehen und tun darf. Löschen und Teilen sind auf owner und admin beschränkt; die Beschränkung wirkt auf dem Server, nicht nur in der Oberfläche.
• Jede Abfrage von Sitzungsdaten ist an den Workspace des anfragenden Kontos gebunden. Eine fremde Aufzeichnung ist auch mit bekannter Kennung nicht adressierbar.
• Freigabe-Links (siehe 4.3) sind der einzige Weg zu einer Aufzeichnung ohne Anmeldung. Sie werden von einem berechtigten Nutzer bewusst erzeugt, sind widerrufbar und können ein Ablaufdatum tragen.

2.4 Trennungskontrolle

• Kundendaten sind logisch nach Workspace und Projekt (Kanal) getrennt. Jeder Lese- und Schreibweg führt diese Einschränkung mit.
• Entwicklung und Produktion laufen in getrennten Installationen mit getrennten Datenbanken.

3. Pseudonymisierung und Datenminimierung

• Keine Verarbeitung vor der Einwilligung. Das Aufzeichnungsskript identifiziert nicht, speichert nicht, setzt kein Cookie und baut keine Verbindung auf, solange kein Einwilligungssignal vorliegt. Ein fehlendes Signal gilt als Ablehnung, nicht als Erlaubnis.
• Global Privacy Control. Ein GPC-Signal des Browsers wird weltweit beachtet und geht jedem anderen Signal vor.
• Pseudonyme Kennungen. Besucher werden über zufällig erzeugte Merkmale unterschieden. Namen, E-Mail-Adressen oder Telefonnummern erhebt der Dienst selbst nicht.
• IP-Adressen. Die vollständige IP-Adresse eines Besuchers wird im Arbeitsspeicher des Aufzeichnungsservers für Verbindungsaufbau, Bestimmung von Land, Stadt und Netzbetreiber und Missbrauchsabwehr verwendet; in die Datenbank wird sie nur gekürzt geschrieben (bei IPv4 a.b.c.xxx), und im Dashboard erscheint niemals eine vollständige Besucher-IP. Ausnahmen: Zur Erkennung von Verbindungsfluten wird eine Adresse zehn Sekunden lang in Redis gezählt; löst sie die automatische Sperre aus, liegt sie vollständig bis zu 24 Std. als Sperreintrag in Redis (mp_autoban:), und diese Redis-Instanz schreibt per AOF auf die Platte. Abrufe von Freigabe-Links werden mit vollständiger IP-Adresse protokolliert (share_views) und fallen mit dem Link.
• URL-Bereinigung. Die Werte von Parametern, die typischerweise personenbezogene Daten oder Zugangsdaten tragen (etwa ?email=, ?token=, ?code=), werden vor der Speicherung entfernt – in der Query ebenso wie hinter dem #, wo Anmeldedienste Zugangsdaten ablegen (etwa #access_token=). Routen von Single-Page-Anwendungen und Sprungmarken bleiben dabei erhalten.
• Formulareingaben – drei Stufen, die strengste als Vorgabe. Die Vollmaskierung (Vorgabe) ersetzt jedes Zeichen jeder Eingabe, bevor es den Browser verlässt. Die selektive Maskierung hält Namen, Anschriften, E-Mail, Telefon, Zahlungsfelder und Freitextfelder vollständig maskiert und ersetzt sonst nur die Ziffern, damit Suchbegriffe auswertbar bleiben. Keine Maskierung zeichnet Eingaben auf, wie sie eingegeben wurden. Die beiden schwächeren Stufen sind nicht selbst schaltbar: jede braucht unsere schriftliche Freigabe für genau diese Property, festgehalten mit Zeitpunkt und Erteiler. Durchgesetzt wird serverseitig – liegt die gespeicherte Stufe über der Freigabe, wird sie auf die Freigabe gedeckelt, bevor der Wert den Browser erreicht. Das Feld direkt zu setzen bewirkt daher nichts.
• Die Grenze, die keine Freigabe anhebt. Als Passwort oder Zahlungsdaten erkannte Felder bleiben auf jeder Stufe vollständig maskiert. Die Erkennung liest Name, Id, Typ und das Attribut autocomplete und deckt englische, deutsche und polnische Bezeichner ab. Nichts davon reicht in das hinein, was die Website selbst in die Seite schreibt; mit data-mp-mask gekennzeichnete Bereiche bleiben vollständig aus der Aufzeichnung.
• Ausschlussliste. Der Verantwortliche kann ganze Pfade (etwa Bezahlvorgang oder Kontobereich) von der Aufzeichnung ausnehmen. Der Ausschluss wirkt auf dem Server und greift auch dann, wenn eine Single-Page-Anwendung ohne neuen Verbindungsaufbau in einen ausgeschlossenen Pfad wechselt.

4. Integrität – Weitergabe und Eingabe

4.1 Transport

• Verbindungen aus dem Internet sind TLS-verschlüsselt; TLS endet in nginx auf dem Server. Unverschlüsselte Aufrufe über Port 80 werden auf HTTPS umgeleitet. Das Aufzeichnungsskript verbindet sich standardmäßig über WSS (/mp_wss/). Kommt der WebSocket nie zustande, weicht es auf einen HTTP-Tunnel über HTTPS aus (/mp_wst), der dieselben serverseitigen Prüfungen durchläuft; sehr große Seitenabbilder lädt es über HTTPS mit einem signierten, befristeten Zugang hoch (/mp_dom), und fehlgeschlagene WebSocket-Verbindungen zählt ein Messpunkt ohne Besucherkennung (/mp_wsfail). Hinter nginx lauscht der WebSocket-Server nur auf dem Loopback des Servers, ohne TLS.
• Innerhalb des eigenen lokalen Netzes am selben Ort laufen die Verbindungen zur Datenbank (MariaDB) und zum Zwischenspeicher (Redis) unverschlüsselt; eine Transportverschlüsselung dieser Verbindungen ist nicht eingerichtet. Beide sind zugangsbeschränkt und nur aus dem eigenen lokalen Netz erreichbar (keine Portweiterleitung); die Redis-Instanz der Anwendung lauscht nur auf dem Loopback.
• Zertifikate werden automatisch erneuert. Ein abgelaufenes Zertifikat der Anwendung fiele der minütlichen Prüfung von einem zweiten Rechner auf (siehe Abschnitt 5), die über HTTPS mit Zertifikatsprüfung abfragt; eine eigene Überwachung der Zertifikatslaufzeit gibt es nicht.

4.2 Eingabekontrolle

• Administrative Vorgänge werden mit Konto, Zeit und Handlung protokolliert.
• Jeder Wechsel des Einwilligungszustands wird als eigener Satz festgehalten, zusammen mit seiner Quelle (ausdrückliche API, Consent Mode, TCF, CMP-Adapter, GPC). Der Zustand zum Zeitpunkt der Aufzeichnung bleibt dadurch nachweisbar.

4.3 Weitergabe

• Das Aufzeichnungsskript sendet ausschließlich an die eigene Infrastruktur von MousePlayer. Im normalen Aufzeichnungsbetrieb wird kein Dritter kontaktiert.
• Optionale Schnittstellen (Webhooks, BigQuery, Kundenverwaltungs-, E-Mail-Marketing- und Ticketsysteme, Tabellen und Objektspeicher, Konversionsschnittstellen von Werbenetzen) richtet der Verantwortliche selbst ein; sie laufen in von ihm gewählte Systeme, sind ohne seine Freischaltung nicht aktiv und übermitteln einzelne Angaben; nur der BigQuery-Export kann im Enterprise-Tarif auf Wunsch auch die Rohereignisse der Aufzeichnung (mouse_events) umfassen. Schaltet er eine Brücke zu einem Werkzeug ein, das er selbst auf seiner Seite eingebunden hat (etwa Chat, Fehlerverfolgung oder Webanalyse), übergibt das Skript diesem Werkzeug im Browser einzelne Angaben wie den Verweis auf die Aufzeichnung; an dessen Anbieter überträgt sie das eigene Skript des Werkzeugs. Die Empfänger sind keine Unterauftragsverarbeiter von MousePlayer.
• Erzeugte Texte formuliert ein Sprachmodell auf eigenen Rechnern mit Grafikkarte im selben lokalen Netz und am selben Ort wie der Server. Sie holen die gerechneten Befunde über HTTPS ab, jede Anfrage mit einem eigenen Geheimnis signiert; die Aufzeichnung selbst erreicht sie nicht, und an einen externen KI-Dienst geht nichts – auch nicht, während ein solcher Rechner zur Wartung außer Betrieb ist: dann warten die Aufträge, und die Oberfläche zeigt die gerechnete Fassung.
• Freigabe-Links geben Daten nur an denjenigen weiter, der den Link besitzt. Ob ein solcher Link entsteht, entscheidet der Verantwortliche.

5. Verfügbarkeit und Belastbarkeit

• Täglich um 03:00 Uhr wird eine vollständige Sicherung der Datenbank, des Anwendungsverzeichnisses und – seit dem 06.10.2026 – des Aufzeichnungsarchivs erstellt; bis zum 11.08.2026 lief sie um 02:00 Uhr.
• Lokale Aufbewahrung der Sicherungen: 7 Tage. Die örtliche Kopie liegt unverschlüsselt auf einem angeschlossenen Datenträger; verschlüsselt wird beim Auslagern. Die unverschlüsselten Auszüge aus der Zeit vor der Umstellung wurden dort am 12.08.2026 entfernt, sodass der örtliche Ordner nur noch die Auszüge seit der Umstellung trägt und diese Frist auf ihn greift. Zusätzlich zur lokalen Kopie wird die tägliche Sicherung ausgelagert; Ziel ist seit dem 05.09.2026 ein Bucket bei Google Cloud Storage in der Region europe-central2 (Warschau); bis dahin war es ein privates Google-Drive-Konto; die dort abgelegten Kopien wurden am 06.09.2026 gelöscht, nachdem eine Wiederherstellung aus dem neuen Ziel gegengeprüft war. Aufbewahrung dort: tägliche Kopien 7 Tage, wöchentliche Kopien (sonntags) 364 Tage. Beide Zahlen sind eine Einstellung und keine Konstante im Skript: Die Sicherung liest sie aus derselben Zeile der Konfiguration, die dieser Satz zitiert, damit veröffentlichte Aussage und tatsächliches Verhalten nicht auseinanderlaufen können. Die Kopie enthält die vollständige Datenbank. Nach 7 Tagen werden die Ereignisse einer Aufzeichnung aus der Datenbank in ein Archiv ausgelagert. Seit dem 06.10.2026 ist dieses Archiv Teil der täglichen Sicherung; bis dahin war es nicht gesichert, und für Aufzeichnungen, die älter als 7 Tage waren, bestand keine Sicherungskopie. Das Archiv liegt auf derselben Platte wie das System; gegen den Ausfall dieser Platte schützen die örtliche Kopie auf einem getrennten Datenträger und die ausgelagerte Kopie. Seit dem 11.08.2026 wird sie vor der Übertragung auf unserem eigenen Server verschlüsselt (rclone crypt); verschlüsselt sind auch die Datei- und Verzeichnisnamen, sodass beim Anbieter nur Blöcke ohne erkennbare Bedeutung liegen. Die Schlüssel liegen in zwei Dateien auf unserem eigenen Server, nur für ihren Eigentümer les- und schreibbar (Dateirechte 600); der Anbieter hat sie nicht und kann den Inhalt nicht lesen. Die Entschlüsselung einer solchen Kopie wurde geprüft. Der bisherige, unverschlüsselte Zielordner mit den vollständigen Kopien aus der Zeit vor dem 11.08.2026 wurde am 12.08.2026 gelöscht. Seit dem 19.08.2026 wird der Erfolg der Übertragung automatisch überwacht. Die Sicherung schreibt ihren Ausgang in eine Statusdatei, und der Wächter fragt nach dem letzten gelungenen Lauf, nicht nach dem letzten Lauf – ein Skript, das jede Nacht startet und jede Nacht abbricht, hat einen frischen Zeitstempel und keine Sicherung. Liegt länger als die eingestellte Frist kein gelungener Lauf vor (Vorgabe 36 Stunden, was genau einen ausgefallenen Tageslauf zulässt), geht eine Warnung per E-Mail hinaus, höchstens einmal am Tag.
• Im laufenden Betrieb gelöschte Daten sind in Sicherungen so lange noch vorhanden, bis die jeweilige Sicherung abläuft – höchstens 364 Tage nach der endgültigen Löschung; danach ist er auch in keiner Sicherung mehr enthalten. Das ist die unvermeidliche Kehrseite davon, überhaupt Sicherungen zu haben; Löschverlangen, die über die Verwaltung ausgeführt werden, nehmen die Daten sofort aus der Verarbeitung (archiviert, ausgeblendet, nicht mehr aufgezeichnet) und löschen sie spätestens nach 30 Tagen endgültig, auf ausdrückliches Verlangen ohne Wartezeit; ein auf der Datenseite /meine-daten gestelltes Verlangen wird ohne Archivierung ausgeführt, im Regelfall binnen Minuten. Eine gezielte Löschung innerhalb einer Sicherung findet nicht statt: Eine Kopie ist ein einziges versiegeltes Archiv, dessen Zweck darin besteht, ein getreues Abbild eines Zeitpunkts zu sein; sie zu öffnen, zu verändern und wieder zu versiegeln, zerstörte diese Eigenschaft und die Möglichkeit zu zeigen, dass niemand daran manipuliert hat. Sicherungen dienen keinem anderen Zweck als der Wiederherstellung nach einem Verlust; sie werden nicht durchsucht, nicht ausgewertet und nicht offengelegt. Wird eine Sicherung zurückgespielt, werden die für Endnutzer verzeichneten Löschverlangen erneut ausgeführt, bevor das System wieder in Betrieb geht – der Nachweis des Verlangens überdauert die Löschung genau deshalb, damit sie sich wiederholen lässt. Für ein gelöschtes Kundenkonto liegt es anders: Seine Löschung hinterlässt bewusst keinen Datensatz, der es bezeichnet, sodass eine zurückgespielte Kopie ein Konto enthielte, das nach dem Datum dieser Kopie gelöscht wurde.
• Überwachung. Ein Wächterprozess prüft im Minutentakt die Datenbank samt Ereignisverarbeitung, den WebSocket-Server, die Weboberfläche, die Aktualität der Geodatenbank, den täglichen Löschlauf, den Erfolg der Sicherung sowie den freien Plattenplatz auf der Systemplatte und dem Sicherungsträger. Jedes Ergebnis wird im gemeinsamen Zustand abgelegt und im Administrationsbereich angezeigt; jede fehlgeschlagene Prüfung wird höchstens einmal am Tag per E-Mail gemeldet – ein Wächter, der im Minutentakt mailt, wird abgeschaltet und meldet dann auch den echten Ausfall an niemanden mehr. Vor dem 19.08.2026 wurden nur die ersten fünf dieser Punkte geprüft und nur der Löschlauf löste eine Meldung aus; der Rest war manuell, und dieses Dokument sagte das auch.
• Was diese Überwachung nicht leisten kann, ausdrücklich statt stillschweigend: Sie läuft auf dem Rechner, den sie überwacht, und kann dessen Totalausfall deshalb nicht melden. Seit dem 2. Oktober 2026 prüft ein zweiter Rechner am selben Ort jede Minute, ob die Anwendung Aufzeichnungen annimmt – Datenbank, Zwischenspeicher, WebSocket-Server, Hintergrundprozesse, Warteschlange und das Tracking-Skript – und meldet sich per Telegram nach zwei Fehlschlägen in Folge. Er erreicht den Server über das lokale Netz: Ein Ausfall der Internetanbindung, des Routers oder von DNS fällt ihm nicht auf und wird weiterhin von einem Menschen bemerkt, nicht von einem Melder. Angestrebte Wiederherstellungszeit (RTO): höchstens 24 Stunden. Wiederherstellungstests: Die Wiederherstellung aus der ausgelagerten Sicherung wurde am 05. und 06.09.2026 sowie am 07.10.2026 (vollständige Wiederherstellung der Daten) erprobt; ein fester Turnus ist nicht vereinbart.
• Überlast und Angriffe. nginx begrenzt Anfragen und gleichzeitige Verbindungen je Adresse; wer die Grenze anhaltend überschreitet, wird von fail2ban für eine Stunde an der Firewall abgewiesen. Der WebSocket-Server sperrt Adressen, die Verbindungsfluten erzeugen, automatisch für 24 Std.; Sperren, die der Betreiber von Hand setzt, stehen in der Datenbank.

6. Verfahren zur regelmäßigen Überprüfung

• Die Maßnahmen dieses Dokuments werden überprüft, sobald sich die Verarbeitung ändert, im Übrigen in dem in Abschnitt 10 genannten Abstand.
• Eine Einbauprüfung stellt je Kundenprojekt fest, ob das Skript richtig eingebunden ist und ob Aufzeichnungen mit Einwilligungsnachweis eintreffen. Projekte ohne solchen Nachweis werden im Dashboard gekennzeichnet.
• Externe Penetrationstests sind derzeit nicht beauftragt, und es bestehen keine Sicherheitszertifizierungen. Das steht hier ausdrücklich statt gar nicht: ein TOM-Dokument, das dazu schweigt, liest sich, als gäbe es solche Prüfungen.
• Die Zahl der über alle Kunden hinweg beobachteten Endnutzer wird täglich gemessen und gegen die Schwelle gehalten, ab der die Beurteilung nach Art. 37 DSGVO zu wiederholen ist (100000 im Monat; siehe Abschnitt 9 des Verzeichnisses von Verarbeitungstätigkeiten). Diese Größe bestimmt der Verkehr auf den Kundenwebsites und nicht wir; sie unbeobachtet zu lassen hieße, die Beurteilung still veralten zu lassen. Die jährliche Wiederholung überwacht derselbe Prozess.

7. Unterauftragsverarbeiter

MousePlayer zieht Unterauftragsverarbeiter nur auf Grundlage der allgemeinen schriftlichen Genehmigung nach dem AVV hinzu. Die aktuelle Liste mit Zweck, Datenkategorien und Verarbeitungsort wird gesondert veröffentlicht:

• Liste der Unterauftragsverarbeiter

An der Aufzeichnung selbst ist kein Dritter beteiligt: das Aufzeichnungsskript sendet ausschließlich an die eigene Infrastruktur. Für die Daten der Endnutzer besteht daneben ein Empfänger: eine tägliche ausgelagerte Kopie der vollständigen Datenbank und des Aufzeichnungsarchivs — einschließlich der Sitzungsaufzeichnungen — liegt bei Google (Google Cloud Storage, Bucket in Warschau). Seit dem 11.08.2026 liegt sie dort verschlüsselt: verschlüsselt wird vor der Übertragung auf unserem eigenen Server (rclone crypt), einschließlich der Datei- und Verzeichnisnamen; die Schlüssel liegen bei MousePlayer. Google erhält sie nicht und kann den Inhalt nicht lesen, bleibt aber Unterauftragsverarbeiter — die Verschlüsselung ist eine technische Maßnahme, keine Änderung der Rolle. Der bisherige, unverschlüsselte Zielordner mit den Kopien aus der Zeit vor dem 11.08.2026 wurde am 12.08.2026 gelöscht.

8. Aufbewahrung und Löschung

Die Aufbewahrung von Sitzungsaufzeichnungen richtet sich nach dem Tarif des Kunden:

• Free: 7 Tage · Small: 30 Tage · Business: 90 Tage · Enterprise: nach individueller Vereinbarung.
• Nach einem Wechsel in einen kleineren Tarif gilt eine Schonfrist von mindestens 30 Tagen, in der die längere Aufbewahrung des bisherigen Tarifs weiterläuft. Ein Wechsel nach oben verkürzt die Aufbewahrung nie.
• Das Anwendungsprotokoll wird nach 60 Tagen gelöscht, die Protokolle des Webservers nach 14 Tagen, Sicherheitsprotokolle nach 72 Stunden.
• Bei Sitzungen, die als automatisierter Zugriff erkannt wurden, wird die Aufzeichnung nach 1 Tag geleert und die Sitzung nach 14 Tagen gelöscht. Bei einem als missbrauchsverdächtig markierten Konto im Free-Tarif wird nur ein Teil der Besuche aufgezeichnet, und Aufzeichnungen werden nach 1 Tag gelöscht.
• Das Zustellprotokoll der Integrationen wird nach 30 Tagen gelöscht. Es liegt in Redis, nicht in der Datenbank, und läuft dort von selbst ab; die Liste ist zusätzlich auf 25 Einträge je Projekt begrenzt. Es ist damit auch nicht Teil der täglichen Sicherung.
• Die fristgebundene Löschung läuft automatisch und unbeaufsichtigt; sie muss nicht von Hand angestoßen werden.

Mit Beendigung des Kundenkontos werden alle zugehörigen personenbezogenen Daten innerhalb von 30 Tagen gelöscht, soweit nicht Unionsrecht oder mitgliedstaatliches Recht eine längere Speicherung verlangt. Ausgelöst wird die Löschung vom Kunden selbst in den Kontoeinstellungen; eine Anfrage per E-Mail ist nicht nötig. Zuerst wird das Konto archiviert: Der Zugang endet sofort, es wird nichts mehr aufgezeichnet und nichts mehr angezeigt, und 30 Tage lang können wir es auf Anfrage wiederherstellen, falls die Löschung ein Versehen war. Danach wird es endgültig gelöscht; beim Auslösen kann der Kunde auch die sofortige endgültige Löschung wählen. Ein Projekt oder ein Workspace, die der Kunde löscht, werden ebenso zunächst 30 Tage archiviert und lassen sich in dieser Zeit im Dashboard wiederherstellen. Drei Dinge bleiben bewusst erhalten, weil das Recht es verlangt oder weil sie eine Entscheidung belegen und keine Person: der Nachweis der Annahme dieser Dokumente, das Sicherheits- und Änderungsprotokoll (ohne den Bezug zur Person) und Supportanfragen. Abweichend davon wird ein Konto im Free-Tarif, das 24 Monate lang nicht benutzt wurde, 30 Tage nach einem zugestellten Hinweis ohne vorherige Archivierung endgültig gelöscht.

Einwilligungsnachweise bleiben über die Löschung der Aufzeichnung hinaus bestehen. Sie enthalten keine Verhaltensdaten, sondern nur Tatsache, Zeitpunkt und Quelle der Einwilligungsentscheidung, und dienen der Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO.

9. Verletzung des Schutzes personenbezogener Daten

MousePlayer benachrichtigt den Verantwortlichen unverzüglich, spätestens jedoch innerhalb von 48 Stunden, nachdem eine Verletzung des Schutzes personenbezogener Daten bekannt geworden ist, die dessen Daten betrifft. Die Meldung enthält die Angaben, die der Verantwortliche für seine eigene Pflicht nach Art. 33 DSGVO benötigt.

Meldeadresse für Sicherheitsvorfälle: office@mouseplayer.com

10. Stand und Fassung

• Fassung: 1.5 · Gültig ab: 16.10.2026 · Nächste Überprüfung: 19.08.2027 · ersetzt die Fassung 1.4 vom 07.10.2026. Geändert: Abschnitt 2.2 nennt die Zwei-Faktor-Anmeldung, die Liste aktiver Anmeldungen mit Widerruf und die Anmeldemeldung; Abschnitt 2.3 nennt die Rollen owner, admin und viewer; Abschnitt 3 nennt die Ausnahmen bei vollständigen IP-Adressen; Abschnitt 4.1 beschreibt die Transportwege des Skripts und die unverschlüsselten Verbindungen im lokalen Netz statt der Aussage, es gebe keinen unverschlüsselten Weg; Abschnitt 4.3 nennt die übrigen Schnittstellen; Abschnitt 5 hält fest, dass das Aufzeichnungsarchiv seit dem 06.10.2026 gesichert wird, und nennt die durchgeführten Wiederherstellungstests und die Begrenzung von Überlast; Abschnitt 8 ergänzt Fristen und die Löschung untätiger Konten. Außerdem nennt Abschnitt 2.2 den Stand der SSH-Anmeldung, und die Dauer der selbsttätigen Sperre steht als Einstellung. Die Fassung 1.4 ersetzte die Fassung 1.3 vom 17.09.2026. Geändert: Abschnitte 5 und 8 sagen, dass eine Löschung die Daten zuerst archiviert – sofort aus der Verarbeitung genommen – und spätestens nach 30 Tagen endgültig löscht. Die Fassung 1.3 ersetzte die Fassung 1.2 vom 19.08.2026. Geändert: Abschnitt 4.3 nennt die Rechner, auf denen das Sprachmodell für erzeugte Texte läuft, wie die Befunde dorthin gelangen und was während einer Wartung geschieht. Die Fassung 1.2 ersetzte die Fassung 1.1 vom 11.08.2026. Geändert: Abschnitt 5 nennt die Aufbewahrung der Sicherungen als Einstellung statt als Konstante, beschreibt, was beim Zurückspielen mit Löschungen geschieht, und hält fest, dass Erfolg der Sicherung und Plattenplatz nun automatisch überwacht werden; Abschnitt 6 ergänzt die Messung der Art.-37-Schwelle.
• Bei Abweichungen zwischen den Sprachfassungen ist die englische Fassung maßgeblich.