Auftragsverarbeitungsvertrag (AVV)

Version 2026-10-11Zuletzt aktualisiert 16. Oktober 2026

Diese Übersetzung dient deiner Information. Verbindlich ist die englische Fassung.

Dieser Vertrag über die Verarbeitung personenbezogener Daten im Auftrag eines Verantwortlichen (AVV) gilt zwischen der Cloo GmbH als Auftragsverarbeiter („wir“) und dem Kunden, der MIRA FIVE nach unseren Nutzungsbedingungen (die Nutzungsbedingungen) nutzt, als Verantwortlichem.

Cloo GmbH
Reumtengrüner Str. 32B
08209 Auerbach
Deutschland
Geschäftsführer: Yannick Seeger, Paul Otto
Registergericht: Amtsgericht Chemnitz, HRB 38181
info@cloo-gmbh.de

Abschluss dieses AVV

Dieser AVV ist Teil des Vertrags nach den Nutzungsbedingungen. Er gilt ab der ersten Verarbeitung von Kundendaten, auch bevor ein Owner ihn in der App angenommen hat.

Ein Owner einer Organisation kann die Annahme dieses AVV für die ganze Organisation in MIRA FIVE dokumentieren, in den Einstellungen oder im Chat. Nur ein Owner kann das tun. Der Owner sichert zu, dass er für die Organisation handeln darf. Die elektronische Form genügt (Art. 28 Abs. 9 DSGVO). MIRA FIVE erfasst die Organisation, die Version des AVV, die Person, die ihn angenommen hat, die Art der Annahme und den Zeitpunkt.

Wenn wir eine neue Version dieses AVV veröffentlichen, zeigt MIRA FIVE die neue Version als nicht angenommen an, bis ein Owner sie annimmt. Die neue Version ersetzt die alte ab diesem Zeitpunkt. Bis dahin gilt weiter die Version, die die Organisation zuletzt angenommen hat.

Auf Anfrage senden wir eine gegengezeichnete Fassung als PDF. Eine Nachricht an hello@mirafive.io genügt. Die Begriffe Organisation, Projekt, Quelle, Owner, Admin und Member haben die Bedeutung, die ihnen die Nutzungsbedingungen geben.

1. Gegenstand und Dauer

(1) Wir verarbeiten personenbezogene Daten, die in Kundendaten enthalten sind, um MIRA FIVE nach den Nutzungsbedingungen bereitzustellen. Kundendaten sind, wie in den Nutzungsbedingungen, alle Daten, die der Kunde oder seine Websites, Apps, Server und verbundenen Plattformen an MIRA FIVE übermitteln, und die Daten, die MIRA FIVE daraus erzeugt, etwa Ereignisse, Besuche, Personen und Importe. Dazu gehört auch der Inhalt der Unterhaltungen mit Mira (dem Agenten in MIRA FIVE), soweit er solche Daten enthält. Anlage 1 beschreibt Gegenstand, Art und Zweck der Verarbeitung, die Arten personenbezogener Daten und die Kategorien betroffener Personen.

(2) Der Kunde ist Verantwortlicher, wir sind Auftragsverarbeiter (Art. 28 DSGVO). Wenn der Kunde die Daten selbst im Auftrag eines Dritten verarbeitet, gilt zusätzlich Abschnitt 10.

(3) Kontodaten fallen nicht unter diesen AVV. Kontodaten sind Daten über die Mitglieder einer Organisation und über das Konto des Kunden, etwa Namen und E-Mail-Adressen der Mitglieder, Anmeldungen und Abrechnung. Hierfür sind wir Verantwortlicher; es gilt unsere Datenschutzerklärung.

(4) Dieser AVV gilt für die Laufzeit des Vertrags nach den Nutzungsbedingungen und danach, bis wir die Kundendaten nach Abschnitt 9 gelöscht haben.

2. Weisungen

(1) Wir verarbeiten Kundendaten nur auf dokumentierte Weisung des Kunden. Dokumentierte Weisungen sind:

dieser AVV,
die Nutzungsbedingungen,
die Einstellungen und Handlungen des Kunden und seiner Mitglieder im Dienst, also in der App, im Chat mit Mira, über die REST-API, über den MCP-Server und in der Konfiguration des Tracking-Skripts und der Events-API. Dazu gehören der gewählte Tracking-Modus, verbundene Plattformen, Löschungen und Anfragen betroffener Personen. Die Aufbewahrungsfrist richtet sich nach dem Tarif, den der Kunde gebucht hat.

(2) Der Owner oder ein Admin der betroffenen Organisation erteilt weitere Weisungen in Textform, zum Beispiel per E-Mail an hello@mirafive.io. Gehen sie über den vereinbarten Umfang des Dienstes hinaus, dürfen wir den angemessenen Mehraufwand nach vorheriger Ankündigung in Rechnung stellen. Wenn wir eine Weisung nicht ausführen können, teilen wir das dem Kunden unverzüglich mit.

(3) Wenn wir der Ansicht sind, dass eine Weisung gegen Datenschutzrecht verstößt, informieren wir den Kunden unverzüglich. Wir dürfen die Ausführung der Weisung aussetzen, bis der Kunde sie bestätigt oder ändert.

(4) Wenn das Recht der Union oder eines Mitgliedstaats uns zu einer Verarbeitung verpflichtet, teilen wir dem Kunden diese rechtliche Anforderung vor der Verarbeitung mit, es sei denn, dieses Recht verbietet eine solche Mitteilung wegen eines wichtigen öffentlichen Interesses.

3. Pflichten von Cloo

(1) Wir verarbeiten Kundendaten nur im Rahmen der Weisungen. Wir verkaufen sie nicht, trainieren keine KI-Modelle damit und nutzen sie nicht für eigene Zwecke. Ausgenommen sind aggregierte Zahlen ohne Personenbezug, etwa die Zahl der Ereignisse je Organisation für Abrechnung, Kapazitätsplanung und Betrieb, sowie die Protokolle, die der Abwehr von Angriffen und dem Betrieb des Dienstes dienen (Anlage 1, IP-Adresse). Wir verwenden die personenbezogenen Daten eines Kunden nicht für einen anderen Kunden. Wir geben Kundendaten nur an Unterauftragsverarbeiter nach Abschnitt 5 und an Empfänger weiter, die der Kunde selbst wählt.

(2) Personen, die wir zur Verarbeitung von Kundendaten befugen, haben sich zur Vertraulichkeit verpflichtet oder unterliegen einer angemessenen gesetzlichen Verschwiegenheitspflicht. Nur die Geschäftsführer haben persönlichen administrativen Zugriff auf die Produktionssysteme. Automatisierte Systeme (Deployment, Datenbankmigrationen) nutzen eigene Schlüssel mit eingeschränkten Rechten. Die Geschäftsführer vergeben und entziehen Zugriffe über unser Konfigurationsmanagement.

(3) Wir treffen die technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO, die in Anlage 2 beschrieben sind. Wir dürfen sie an den technischen Fortschritt anpassen, solange das Schutzniveau nicht sinkt. Wesentliche Änderungen ergänzen wir in Anlage 2.

(4) Der Dienst enthält Werkzeuge, mit denen der Kunde Anfragen betroffener Personen selbst erfüllen kann: Export aller Daten zu einer Person, Löschung einer Person und Widerspruch nach Art. 21 DSGVO. Wenn der Kunde eine Anfrage mit diesen Werkzeugen nicht erfüllen kann, unterstützen wir auf Anfrage mit geeigneten technischen und organisatorischen Maßnahmen. Wenn sich eine betroffene Person direkt an uns wendet, leiten wir die Anfrage an den Kunden weiter, soweit wir den Kunden ermitteln können, und beantworten sie nicht selbst.

(5) Unter Berücksichtigung der Art der Verarbeitung und der uns zur Verfügung stehenden Informationen unterstützen wir den Kunden bei seinen Pflichten nach Art. 32 bis 36 DSGVO: Sicherheit der Verarbeitung, Meldung und Benachrichtigung bei Verletzungen des Schutzes personenbezogener Daten, Datenschutz-Folgenabschätzungen und vorherige Konsultation der Aufsichtsbehörde.

(6) Wir führen ein Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 Abs. 2 DSGVO.

(7) Wir informieren den Kunden unverzüglich über Kontrollen, Maßnahmen und Auskunftsersuchen von Behörden, soweit sie Kundendaten betreffen und die Information des Kunden rechtlich zulässig ist.

(8) Mitglieder des Kunden können Mira Fragen zu den Daten des Kunden stellen. Um zu antworten, sendet MIRA FIVE die Frage des Mitglieds, die Anweisungen des Agenten, einen kurzen Hinweis zum Projekt (seinen Namen, die Domains der Websites und die Namen seiner Apps und Server) und die Ergebnisse der Abfragen, die Mira ausführt, an ein Claude-Sprachmodell (von Anthropic). Amazon Web Services EMEA SARL betreibt dieses Modell für uns in Amazon Bedrock, in AWS-Rechenzentren in der Europäischen Union (Anlage 3). Die Ergebnisse der Abfragen sind kompakte Aggregate, etwa Zahlen, Rangfolgen und Bezeichnungen. Jeder Text, der aus getrackten Daten stammt, etwa ein Seitenpfad, ein Seitentitel, ein Referrer, ein Kampagnenname, ein Ereignisname oder eine Suchanfrage, ist als Daten markiert, sodass das Modell ihn nicht als Anweisung liest. Wenn ein Mitglied nach Personen fragt, können die Ergebnisse die Nutzer-IDs des Kunden, die von ihm gespeicherten Merkmale (Kontaktmerkmale als Hashes mit Schlüssel, sofern der Kunde nichts anderes gewählt hat), Besuchszeiten und Umsatz enthalten. Wenn ein Mitglied nach Werbe- oder Suchdaten fragt, können die Ergebnisse Ausgaben, Klicks, Kampagnen- und Keyword-Namen und Suchanfragen enthalten. Wir senden niemals Passwörter, Token oder Schlüssel verbundener Plattformen, Links zu Exportdateien oder rohe importierte Zeilen an das Modell. Wir konfigurieren Amazon Bedrock so, dass AWS keinen Prompt und keine Antwort dauerhaft speichert (Zero Data Retention). Anthropic, der Hersteller des Modells, hat keinen Zugriff auf die Prompts und Antworten und erhält sie nicht, weil Amazon Bedrock die Modelle in Konten betreibt, die nur AWS betreibt. Wir trainieren keine KI-Modelle mit den Daten und lassen das auch von niemand anderem zu. Die Verarbeitung für die KI bleibt in der Europäischen Union. Eine Änderung an der Einrichtung des Kunden, die Mira vorschlägt, wird erst wirksam, nachdem ein Mitglied sie mit einem Klick bestätigt hat, und sie läuft mit den Rechten dieses Mitglieds.

(9) Wenn der Kunde Google Ads oder die Google Search Console verbindet, behandeln wir die Daten von Google so, wie es die Google API Services User Data Policy verlangt. Die Nutzung von Informationen, die MIRA FIVE aus Google-APIs erhält, hält die Google API Services User Data Policy ein, einschließlich der Limited-Use-Anforderungen. Wir nutzen diese Daten nur, um dem Kunden seine eigenen Berichte zu zeigen und seine Fragen im Chat zu beantworten. Um zu antworten, können sie nur für diese Antwort das KI-Modell von Mira erreichen, mit Zero Data Retention (Absatz 8). Wir verwenden Google-Nutzerdaten niemals, um ein KI- oder Machine-Learning-Modell zu erstellen, zu trainieren oder zu verbessern, und sie werden bei keinem Modell gespeichert. Wir verkaufen sie niemals und nutzen sie niemals für Werbung.

4. Pflichten des Kunden

(1) Der Kunde ist für die Rechtmäßigkeit der Verarbeitung verantwortlich. Er stellt insbesondere sicher,

dass es für die Erhebung eine Rechtsgrundlage gibt und dass jede erforderliche Einwilligung eingeholt wurde, auch nach § 25 TDDDG für den Zugriff auf das Endgerät,
dass er für jedes Projekt einen Tracking-Modus wählt, der zu Rechtsgrundlage und Einwilligung passt (Anlage 1), und dass er die Einwilligung seiner Besucher dem Tracking-Skript richtig meldet,
dass er die betroffenen Personen nach Art. 13 und 14 DSGVO informiert,
dass er nur die personenbezogenen Daten übermittelt, die er für seine Zwecke braucht.

(2) Der Kunde übermittelt keine besonderen Kategorien personenbezogener Daten (Art. 9 DSGVO) und keine Daten über strafrechtliche Verurteilungen und Straftaten (Art. 10 DSGVO) an MIRA FIVE. Direkte Kennungen wie Namen und E-Mail-Adressen übermittelt er nur, wenn er eine Rechtsgrundlage hat und sie braucht, und nur als Merkmale bei der Identifizierung einer Person (identify). Er übermittelt sie niemals in URLs, Seitentiteln, Ereignisnamen oder frei gewählten Ereigniseigenschaften. Der Kunde gibt solche Daten im Chat mit Mira nicht ein, sofern er sie nicht braucht.

(3) Der Kunde beantwortet Anfragen betroffener Personen selbst. Vor einem Export oder einer Löschung prüft er die Identität der anfragenden Person; die App fragt nach dieser Bestätigung. Daten, die ohne Einwilligung erhoben wurden, enthalten keine Kennung, die zu einer Person gehört, und sie lassen sich keiner namentlich bekannten Person zuordnen.

(4) Der Kunde ist für die Handlungen seiner Mitglieder und für die API-Schlüssel, MCP-Verbindungen und Plattformverbindungen verantwortlich, die er einrichtet.

(5) Wenn der Kunde Fehler oder Unregelmäßigkeiten bei der Verarbeitung bemerkt, informiert er uns unverzüglich.

5. Unterauftragsverarbeiter

(1) Der Kunde erteilt uns die allgemeine schriftliche Genehmigung, Unterauftragsverarbeiter einzusetzen (Art. 28 Abs. 2 DSGVO). Die in Anlage 3 genannten Unterauftragsverarbeiter gelten als genehmigt. Die aktuelle Liste steht unter Unterauftragsverarbeiter.

(2) Bevor wir einen Unterauftragsverarbeiter hinzufügen oder ersetzen, informieren wir den Kunden mindestens 30 Tage im Voraus. Die Mitteilung nennt Name, Adresse, Leistung und Ort der Verarbeitung. Wir senden sie per E-Mail an den Owner jeder Organisation des Kunden und aktualisieren die Liste. Wenn wir einen Unterauftragsverarbeiter kurzfristig ersetzen müssen, um den Dienst oder seine Sicherheit zu erhalten, informieren wir den Kunden unverzüglich; das Widerspruchsrecht nach Absatz 3 bleibt bestehen.

(3) Der Kunde kann einer Änderung innerhalb von 14 Tagen nach Erhalt der Mitteilung in Textform aus berechtigten datenschutzrechtlichen Gründen widersprechen. Wir suchen dann gemeinsam mit dem Kunden eine Lösung. Finden wir keine, kann der Kunde den Vertrag für die betroffenen Organisationen mit Wirkung vor dem Einsatz des neuen Unterauftragsverarbeiters kündigen. Wir erstatten anteilig jede Gebühr, die für die Zeit nach dem Ende des Vertrags bereits gezahlt wurde. Wenn der Kunde nicht rechtzeitig widerspricht, gilt die Änderung als genehmigt.

(4) Wir verpflichten jeden Unterauftragsverarbeiter vertraglich zu Datenschutzpflichten, die denen dieses AVV gleichwertig sind, insbesondere zu hinreichenden Garantien für geeignete technische und organisatorische Maßnahmen (Art. 28 Abs. 4 DSGVO). Wir haften gegenüber dem Kunden dafür, dass unsere Unterauftragsverarbeiter ihre Pflichten einhalten, wie für eigenes Verhalten.

(5) Keine Unterauftragsverarbeitung sind:

Nebenleistungen, bei denen der Dienstleister keinen Zugriff auf Kundendaten hat,
Empfänger, die der Kunde selbst wählt: Programme und KI-Assistenten, die er über die REST-API oder den MCP-Server verbindet, und Plattformen wie Google, Meta, Microsoft oder Stripe, die er mit MIRA FIVE verbindet. Daten, die zu ihnen fließen, verlassen MIRA FIVE auf Weisung des Kunden. Der Kunde ist für diese Empfänger verantwortlich.

6. Ort der Verarbeitung und Übermittlungen in Drittländer

(1) Vorbehaltlich der Absätze 2 und 3 verarbeiten wir Kundendaten in der Europäischen Union: den Dienst auf einem Server der Hetzner Online GmbH in Nürnberg, Deutschland, die verschlüsselten Backups und die gespeicherten Dateien bei AWS in Frankfurt, Deutschland, und die KI-Modelle in Amazon Bedrock in AWS-Regionen in der Europäischen Union. Unser eigener Tool-Server in Falkenstein, Deutschland, hält Fehlerberichte und Monitoring-Daten, die keine Nutzerdaten enthalten.

(2) Einige Unterauftragsverarbeiter verarbeiten Daten außerhalb der Europäischen Union. Cloudflare, Inc. verarbeitet den gesamten Datenverkehr zu unseren Hosts in seinem Edge-Netzwerk, einschließlich der IP-Adressen der Besucher. Die Übermittlungsgrundlage ist das EU-U.S. Data Privacy Framework (EU-US-Datenschutzrahmen), mit den Standardvertragsklauseln des Data Processing Addendum von Cloudflare als Rückfall. AWS speichert Daten nur in der Europäischen Union. Ein Zugriff aus den USA für Support und Betrieb lässt sich nicht ausschließen; die Übermittlungsgrundlage sind das EU-U.S. Data Privacy Framework und die Standardvertragsklauseln des AWS Data Processing Addendum. Die Verarbeitung für die KI bleibt in der Europäischen Union (Abschnitt 3 Abs. 8). Eine Übermittlung in ein Drittland findet nur statt, wenn die Voraussetzungen der Art. 44 ff. DSGVO erfüllt sind, zum Beispiel durch einen Angemessenheitsbeschluss der Europäischen Kommission, einschließlich des EU-U.S. Data Privacy Framework, oder durch Standardvertragsklauseln. Neue Übermittlungen kündigen wir nach Abschnitt 5 an.

(3) Wenn der Kunde uns personenbezogene Daten aus Kundendaten per E-Mail sendet, werden sie in unseren Postfächern bei Google Workspace gespeichert, und Google LLC in den USA kann sie verarbeiten (Anlage 3). Der Kunde vermeidet das, indem er solche Daten nur sendet, wenn eine Anfrage sie erfordert.

7. Meldung von Verletzungen

(1) Wir melden dem Kunden eine Verletzung des Schutzes personenbezogener Daten, die Kundendaten betrifft, unverzüglich, spätestens innerhalb von 48 Stunden, nachdem sie uns bekannt wurde. Die Meldung geht per E-Mail an den Owner der betroffenen Organisation und, wenn nötig, auch an ihre Admins.

(2) Soweit bekannt, enthält die Meldung die Angaben nach Art. 33 Abs. 3 DSGVO:

die Art der Verletzung, wenn möglich mit den Kategorien und der ungefähren Zahl der betroffenen Personen und Datensätze,
eine Anlaufstelle für weitere Informationen,
die wahrscheinlichen Folgen,
die ergriffenen oder vorgeschlagenen Maßnahmen, einschließlich Maßnahmen zur Abmilderung nachteiliger Auswirkungen.

Fehlende Informationen liefern wir nach, sobald sie verfügbar sind.

(3) Wir ergreifen unverzüglich die notwendigen Maßnahmen, um die Daten zu sichern und nachteilige Auswirkungen für die betroffenen Personen abzumildern.

(4) Die Meldung an die Aufsichtsbehörde und die Benachrichtigung betroffener Personen liegen in der Verantwortung des Kunden; wir unterstützen nach Abschnitt 3 Abs. 5. Eine Meldung oder Unterstützung ist kein Anerkenntnis eines Fehlers oder einer Haftung.

8. Nachweise und Audits

(1) Wir stellen dem Kunden die Informationen zur Verfügung, die er braucht, um die Einhaltung der Pflichten nach Art. 28 DSGVO nachzuweisen: diesen AVV, die Maßnahmen in Anlage 2, die Liste der Unterauftragsverarbeiter und Antworten auf Fragebögen in angemessenem Umfang.

(2) Der Kunde darf die Einhaltung dieses AVV überprüfen, auch vor Ort. Er darf das Audit selbst durchführen oder einen Prüfer beauftragen, der zur Vertraulichkeit verpflichtet und nicht unser Wettbewerber ist. Er kündigt das Audit mindestens 30 Tage im Voraus in Textform an. Audits finden während unserer Geschäftszeiten statt, ohne den Betrieb zu stören. In der Regel ist ein Audit je Kalenderjahr zulässig. Weitere Audits sind zulässig, wenn es einen konkreten Anlass gibt, etwa eine Verletzung nach Abschnitt 7, oder wenn eine Aufsichtsbehörde es verlangt; bei einem konkreten Anlass genügt eine angemessene kürzere Frist.

(3) Wir betreiben keine eigenen Serverräume. Audits vor Ort finden in unseren Geschäftsräumen statt. Für die Rechenzentren verweisen wir auf die Nachweise, die der Hosting-Anbieter und die anderen Unterauftragsverarbeiter veröffentlichen, etwa ihre Zertifizierungen. Die Hetzner Online GmbH ist für ihre Hosting-Dienste und Rechenzentren, einschließlich Nürnberg und Falkenstein, nach ISO/IEC 27001:2022 zertifiziert. Cloudflare hält Zertifizierungen nach ISO/IEC 27001 und SOC 2 Type II. AWS hält Zertifizierungen nach ISO/IEC 27001 und SOC 2.

(4) Jede Partei trägt ihre eigenen Kosten. Wir tragen unseren eigenen Aufwand für Audits bis zu einem Arbeitstag je Kalenderjahr. Darüber hinaus dürfen wir ihn nach vorheriger Ankündigung angemessen in Rechnung stellen, es sei denn, das Audit zeigt einen wesentlichen Verstoß von uns gegen diesen AVV.

9. Berichtigung, Einschränkung und Löschung; Rückgabe

(1) Während der Laufzeit löscht der Kunde Kundendaten selbst über den Dienst: einzelne Personen, Websites, Apps, Server, Projekte oder ganze Organisationen. Er kann die Merkmale einer Person aktualisieren, indem er die Person mit neuen Werten erneut identifiziert. Wenn eine Berichtigung oder Einschränkung der Verarbeitung mit dem Dienst nicht möglich ist, unterstützen wir nach Abschnitt 3 Abs. 4.

(2) Die Löschung läuft so ab:

Anlass	Löschung
Aufbewahrungsfrist des Tarifs abgelaufen (Rohereignisse: Free 30 Tage, Pro 90 Tage, Enterprise nach Vertrag, bis zu einer anderen Vereinbarung 90 Tage; andere Fristen in Anlage 1)	Löschung in Stapeln durch Löschjobs, die regelmäßig laufen. Ein Rohereignis wird gelöscht, nachdem sein Tag in Tageszahlen zusammengefasst wurde.
Wechsel zu einem Tarif mit kürzerer Aufbewahrungsfrist	Der Löschjob liest die Aufbewahrungsfrist des aktuellen Tarifs, sodass er die älteren Daten bei seinen nächsten Läufen löscht.
Löschung einer Person durch den Kunden	Sofort, mit weiteren Löschläufen nach 1 und 31 Tagen für verspätet eintreffende Ereignisse.
Entfernen einer Website, App oder eines Servers oder Löschen eines Projekts oder einer Organisation	Die Erhebung endet sofort. Ein Löschjob entfernt die Daten danach in Stapeln.
Exportdatei für eine Person	Gelöscht 24 Stunden nach ihrer Erstellung. Der Download-Link ist 15 Minuten gültig.
Ende des Vertrags	Verbleibende Kundendaten innerhalb von 30 Tagen.

Daten, die der Kunde oder eine Person löscht, werden innerhalb von 7 Tagen aus der Live-Datenbank entfernt. Die Löschjobs sind in der Regel innerhalb von Minuten fertig. Für Backups gilt Absatz 5.

(3) Die Rückgabe von Kundendaten (Art. 28 Abs. 3 lit. g DSGVO) erfolgt, indem der Kunde sie vor dem Ende des Vertrags selbst abruft: über die App, die schreibgeschützte REST-API, den MCP-Server und den Export je Person. Einen Gesamtexport aller Analysedaten in einem Standardformat schulden wir nicht.

(4) Nach dem Ende des Vertrags löschen wir die verbleibenden Kundendaten innerhalb von 30 Tagen, es sei denn, das Recht der Union oder eines Mitgliedstaats verpflichtet uns zur Speicherung. Wenn der Kunde eine Organisation oder sein Konto selbst löscht, gelten die Fristen in Absatz 2.

(5) Unsere verschlüsselten Backups halten Daten nur kurz vor: Eine Wiederherstellung zu einem bestimmten Zeitpunkt ist für 7 bis 14 Tage möglich, und ältere Versionen von Backup-Dateien werden nach weiteren 21 Tagen entfernt. Gelöschte Daten können also bis zu 35 Tage in Backups bleiben. Die Backups sind versioniert und schreibgeschützt. Wir nutzen Backups nur, um den Dienst nach einem Ausfall oder Datenverlust wiederherzustellen. Wenn wir ein Backup wiederherstellen, löschen wir zuvor gelöschte Daten erneut.

(6) Auf Anfrage bestätigen wir dem Kunden die Löschung in Textform.

10. Der Kunde als Auftragsverarbeiter

(1) Wenn der Kunde die Daten selbst im Auftrag eines Dritten verarbeitet, zum Beispiel als Agentur für ihre Auftraggeber, sind wir weiterer Auftragsverarbeiter des Kunden. Der Kunde sichert zu, dass sein Vertrag mit dem Verantwortlichen es ihm erlaubt, uns zu den Bedingungen dieses AVV einzusetzen.

(2) Der Kunde gibt die Weisungen des Verantwortlichen an uns weiter. Wir handeln nur auf Weisung des Kunden. Die Rechte des Verantwortlichen, etwa Auskunfts- und Kontrollrechte, werden über den Kunden ausgeübt.

(3) Der Kunde informiert den Verantwortlichen darüber, dass er uns als weiteren Auftragsverarbeiter einsetzt, und holt jede erforderliche Genehmigung ein.

11. Haftung

(1) Die Haftung gegenüber betroffenen Personen richtet sich nach Art. 82 DSGVO.

(2) Zwischen den Parteien gelten die Haftungsregelungen der Nutzungsbedingungen, auch für den Rückgriff nach Art. 82 Abs. 5 DSGVO, soweit rechtlich zulässig.

12. Schlussbestimmungen

(1) Wenn dieser AVV und die Nutzungsbedingungen sich widersprechen, geht dieser AVV in Fragen des Datenschutzes vor.

(2) Änderungen dieses AVV folgen der Änderungsklausel der Nutzungsbedingungen. Der Kunde stimmt einer geänderten Fassung in MIRA FIVE zu, wie im Abschnitt „Abschluss dieses AVV“ beschrieben. Änderungen bei Unterauftragsverarbeitern folgen Abschnitt 5, Anpassungen der Maßnahmen folgen Abschnitt 3 Abs. 3.

(3) Es gilt deutsches Recht. Der Gerichtsstand richtet sich nach den Nutzungsbedingungen.

(4) Wenn eine Bestimmung unwirksam ist, bleiben die übrigen Bestimmungen wirksam. Sie wird durch eine Bestimmung ersetzt, die die Anforderungen des Art. 28 DSGVO erfüllt.

Anlage 1: Einzelheiten der Verarbeitung

Gegenstand und Zwecke

MIRA FIVE misst und analysiert für den Kunden die Nutzung seiner Websites, Apps und Server. Die Verarbeitung dient dazu,

Seitenaufrufe, Ereignisse, Besuche und Pfade durch die Website oder App zu erheben und zu analysieren,
Kanäle, Kampagnen und Werbeklicks zuzuordnen,
Personen, Ziele und Umsatz anzuzeigen,
Werbe-, Such- und Umsatzdaten von Plattformen zu importieren, die der Kunde verbindet,
die Fragen der Mitglieder des Kunden im Chat mit Mira zu beantworten und die Ergebnisse als Diagramme, Tabellen und Kennzahlen anzuzeigen,
dem Kunden die Daten über die App, die REST-API und den MCP-Server bereitzustellen,
Anfragen betroffener Personen zu bearbeiten.

Art der Verarbeitung

Erheben und Empfangen, Anreichern (Land, Region und Stadt aus dem Standort der Anfrage; Gerätetyp, Browser und Betriebssystem aus dem User-Agent), Speichern, Aggregieren, Analysieren, Anzeigen, Weitergabe an ein Sprachmodell zur Beantwortung einer Frage (Abschnitt 3 Abs. 8), Übermittlung an Empfänger, die der Kunde wählt, und Löschen.

Daten erreichen MIRA FIVE über das Skript auf der Website des Kunden, über die Events-API für Apps und Server, über Importe von Plattformen, die der Kunde verbindet (Google Ads, Google Search Console, Meta Ads, Microsoft Advertising, Bing Webmaster Tools, Stripe), und über die Nachrichten, die Mitglieder im Chat schreiben.

Kategorien betroffener Personen

Besucher und Nutzer der Websites, Apps und anderen Online-Dienste des Kunden,
die Kunden und Nutzer des Kunden, soweit der Kunde sie identifiziert (identify) oder sie in importierten Zahlungen vorkommen,
Personen, deren Suchanfragen in den Importen aus der Google Search Console und den Bing Webmaster Tools erscheinen (die Importe enthalten keine Kennung einer Person).

Mitglieder der Organisation des Kunden sind betroffene Personen von Kontodaten, nicht dieses AVV (Abschnitt 1 Abs. 3).

Tracking-Modi

Der Kunde wählt den Tracking-Modus für jedes Projekt. Die Voreinstellung ist hybrid.

Modus	Skript	Speicherung auf dem Endgerät	Kennungen
`hybrid` (Voreinstellung)	Vollständiges Skript (`s.js`)	Nichts vor und ohne Einwilligung in Statistiken. Mit Einwilligung: eine Kennung (`mira_id`) im lokalen Speicher (localStorage) der Domain des Kunden.	Ohne Einwilligung: eine tägliche Besucherkennung, die auf unserem Server abgeleitet wird (siehe unten). Mit Einwilligung: zusätzlich die Kennung `mira_id`.
`cookieless`	Skript ohne Speicher- und Einwilligungscode (`c.js`)	Keine.	Eine tägliche Besucherkennung, die auf unserem Server abgeleitet wird.
`persistent`	Vollständiges Skript (`s.js`)	Die Kennung `mira_id` ab dem ersten Besuch, solange der Besucher nicht abgelehnt hat. Eine Ablehnung oder ein Global-Privacy-Control-Signal beendet sie.	Die Kennung `mira_id` und die tägliche Besucherkennung.

Kein Modus setzt ein Cookie. Die Kennung mira_id ist ein Zufallswert. Sie wird nicht aus Geräteeigenschaften abgeleitet. Sie wird 395 Tage nach ihrer Erstellung erneuert, und Besuche verlängern sie nicht. Es gibt keine Sitzungskennung auf dem Gerät; MIRA FIVE bildet Besuche auf dem Server. Auch der Modus persistent nutzt den lokalen Speicher (localStorage), kein Cookie.

Ohne Einwilligung ist die Besucherkennung ein Tageswert. Sie besteht aus den ersten 16 Zeichen eines Hashes aus einem zufälligen Salt, der Projekt-ID und einem Digest mit Schlüssel aus IP-Adresse und User-Agent. Der Salt ist für jedes Projekt und jeden Tag zufällig, und wir löschen ihn am Ende dieses Tages. So zählt dieselbe Person innerhalb dieses Tages und eines Projekts als ein Besucher, und MIRA FIVE kann die Person am nächsten Tag nicht wiedererkennen. Daten ohne Einwilligung werden nie einer namentlich bekannten Person zugeordnet, auch nicht über den Tageswert.

Wenn der Browser ein Global-Privacy-Control-Signal sendet, gibt das vollständige Skript es weiter. Der Collector behandelt den Besuch dann als abgelehnt, es sei denn, die Website meldet eine ausdrückliche Einwilligung, und er zählt einen Seitenaufruf ohne Kennungen und ohne Marketingwerte. Ein Do-Not-Track-Signal wird nicht gelesen. Das Skript liest keine Formularfelder. Anfragen von Bots werden verworfen. Der Kunde kann die automatischen Ereignisse (aktive Zeit, Scrolltiefe, Web Vitals, ausgehende Links, Downloads, Formularübermittlungen) mit data-auto="false" abschalten.

Arten personenbezogener Daten

Kategorie	Inhalt
Pseudonyme Kennungen	Die tägliche Besucherkennung (ohne Einwilligung); die Kennung `mira_id` (mit Einwilligung in Statistiken); die Nutzer-ID des Kunden und die Verknüpfung zwischen Browser und Nutzer-ID (nur mit Einwilligung in Statistiken)
Nutzungsdaten	Ereignisname und -zeit; Seitenpfad mit durch `:id` ersetzten Kennungen, Seitentitel und Host; Referrer nur als Host; benutzerdefinierte Ereigniseigenschaften (höchstens 30 Schlüssel und 1 KiB, Zeichenketten bis 256 Zeichen); daraus abgeleitete Besuche mit Einstiegskanal, Kampagne, Einstiegs- und Ausstiegsseite, Zahl der Aufrufe und Umsatz; aktive Zeit, Scrolltiefe und Web Vitals; Host des ausgehenden Links, Download-Pfad, Formular-ID und -Name, nicht gefundene Seiten
Kampagnen- und Klickdaten	UTM-Parameter, `ref`- und `via`-Werte, die Google-Kampagnen-ID; Klick-Kennungen (`gclid`, `fbclid`, `msclkid` und ähnliche): ohne Marketing-Einwilligung nur die Tatsache, dass eine vorhanden war, mit Marketing-Einwilligung der Wert
Geräte- und Browserdaten	Gerätetyp, Browser und Version, Betriebssystem und Version, Sprache, Zeitzone und Bildschirmklasse. Der User-Agent selbst wird nicht gespeichert.
Ungefährer Standort	Land und, wenn die Anfrage sie enthält, Region und Stadt
Umsatzdaten	Betrag und Währung von Umsatzereignissen, die das Skript oder ein Server meldet (nicht geprüft); aus einem verbundenen Stripe-Konto je Zahlung: IDs, Zeit, Währung, Betrag, erstattete und bestrittene Beträge und wie der Besucher gefunden wurde. Keine Namen, Adressen oder Kartendaten.
Merkmale	Nutzer-ID und Merkmale, die der Kunde sendet, wenn er eine Person identifiziert, nur mit Einwilligung in Statistiken. Kontaktdaten (E-Mail-Adresse, Telefonnummer) werden als Hash mit Schlüssel gespeichert, sofern der Kunde nicht wählt, sie unverändert zu speichern.
Suchbegriffe	Begriffe aus der Websitesuche; ein Begriff mit einem @-Zeichen oder sechs Ziffern in Folge wird durch „(hidden)“ ersetzt. Formularbezeichnungen, die persönlich aussehen, werden durch „(no name)“ ersetzt.
Werbe- und Suchdaten	Aus verbundenen Plattformen, je Konto und Tag: Werbeausgaben und Klicks nach Kampagne, Anzeigengruppe und Keyword; Suchanfragen, Seiten, Länder und Geräte aus der Google Search Console und den Bing Webmaster Tools. Wir behalten auch die Zeilen genau so, wie die Plattform sie gesendet hat, damit wir die Zahlen neu aufbauen können.
Chat-Inhalte	Die Nachrichten der Mitglieder, die Antworten von Mira und die Ergebnisse der Abfragen, die Mira ausführt, einschließlich der angezeigten Karten
IP-Adresse	Nur vorübergehend, siehe unten

IP-Adresse

MIRA FIVE speichert die IP-Adressen der Besucher nie in seiner Datenbank, und seine Programme schreiben sie nie in ein Protokoll. Die IP-Adresse wird nur verwendet:

im Arbeitsspeicher, um den Digest mit Schlüssel für die tägliche Besucherkennung abzuleiten und um das Land zu finden (aus dem IP-Netz, mit der DB-IP-Lite-Länderdatenbank im Arbeitsspeicher, nie mit der vollständigen Adresse),
von Cloudflare, das alle Anfragen an unsere Hosts erhält, die Besucher-IP an den Collector weitergibt und der Anfrage Region und Stadt hinzufügt, und dessen Sicherheitsregeln IP-Adressen sperren, die zu viele ungültige Anfragen senden (Anlage 3),
in Protokollen des Servers. Der Reverse Proxy auf unserem Server kann Zugriffsprotokolle schreiben (IP-Adresse, Zeit, Anfrage, Statuscode). Sie bleiben in den Container-Protokollen, die nach Größe rotiert und höchstens wenige Tage aufbewahrt werden. Systemprotokolle, die IP-Adressen enthalten (SSH-Anmeldungen, blockierte Firewall-Pakete), werden bis zu fünf Wochen aufbewahrt. Die Anwendung selbst protokolliert keine IP-Adressen.

Ein Kunde, der Ereignisse über seinen eigenen Proxy sendet, übergibt uns die IP-Adresse des Besuchers in einem Header; wir verwenden sie auf dieselbe Weise.

Besondere Kategorien

Die Verarbeitung besonderer Kategorien personenbezogener Daten ist nicht vorgesehen und nach Abschnitt 4 nicht erlaubt.

Aufbewahrung

Daten	Aufbewahrung
Rohereignisse	Free 30 Tage, Pro 90 Tage, Enterprise nach Vertrag (90 Tage, bis etwas anderes vereinbart ist)
Besuche	180 Tage
Tageszahlen ohne Person (einschließlich eindeutiger Besucher als Sketches täglicher Kennungen)	25 Monate
Personen und die Verknüpfungen zwischen Browsern und Personen	25 Monate nach dem letzten Ereignis
Zielerreichungen, Attributionszeilen und importierte Zahlungen	25 Monate
Importierte Werbe- und Suchdaten, einschließlich der Rohzeilen	25 Monate
Täglicher Salt für Besucherkennungen	Bis zum Ende des Tages, zu dem er gehört
Ablehnungsstichproben (Host, Bundle-ID)	14 Tage
Chat-Verlauf	Bis das Mitglied den Thread löscht oder die Organisation oder das Projekt gelöscht wird; private Chats eines Mitglieds, das die Organisation verlässt, werden gelöscht. Es gibt keine feste Höchstdauer.
Chat-Stream-Daten, beendete Chat-Läufe	15 Minuten nach einem Lauf, 30 Tage
Exportdatei für eine Person	24 Stunden
Aufzeichnungen zu Anfragen betroffener Personen	Der Schlüssel der Person (ein Hash), solange er gebraucht wird, um nachzuweisen, wie die Anfrage behandelt wurde; die Widerspruchsliste, solange das Projekt besteht
Audit der Aufrufe über API, MCP und Chat (wer, was, Ergebnis, Dauer; nie die Eingabe oder das Ergebnis)	90 Tage
Audit der Handlungen unserer Mitarbeiter	365 Tage
Fehlerberichte	14 Tage, in unserem eigenen Fehler-Monitoring (Sentry) auf unserem eigenen Server in Falkenstein, Deutschland
Verschlüsselte Backups	Wiederherstellung zu einem bestimmten Zeitpunkt für 7 bis 14 Tage, ältere Versionen von Backup-Dateien nach weiteren 21 Tagen entfernt (insgesamt bis zu 35 Tage)

Ort der Verarbeitung

Deutschland: der Dienst auf einem Server der Hetzner Online GmbH in Nürnberg; verschlüsselte Backups und gespeicherte Dateien bei AWS in Frankfurt; KI-Modelle in Amazon Bedrock in AWS-Regionen in der Europäischen Union. Verarbeitung außerhalb der Europäischen Union wie in Abschnitt 6 beschrieben. Einzelheiten in Abschnitt 6 und Anlage 3.

Anlage 2: Technische und organisatorische Maßnahmen

Diese Maßnahmen nach Art. 32 DSGVO gelten für den gesamten Dienst. Sie sind nach Schutzziel gegliedert: Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit sowie das Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Maßnahmen.

Zutrittskontrolle (Vertraulichkeit)

Wir betreiben keine eigenen Serverräume. Der Produktionsserver steht im Rechenzentrum der Hetzner Online GmbH in Nürnberg, unser Tool-Server steht im Rechenzentrum der Hetzner Online GmbH in Falkenstein, und die Backups liegen in den Rechenzentren von AWS in Frankfurt. Die Anbieter sichern den physischen Zutritt. Die Hosting-Dienste und Rechenzentren von Hetzner sind nach ISO/IEC 27001:2022 zertifiziert.
Ruhende Daten auf den Servern sind durch die physischen Kontrollen und Zugangskontrollen des Rechenzentrums geschützt. Die Festplatten der Server sind nicht auf Betriebssystemebene verschlüsselt. Backups werden verschlüsselt, bevor sie den Server verlassen.

Zugangskontrolle (Vertraulichkeit)

Cloudflare erhält alle Anfragen an die App, die API und den Collector und leitet sie durch einen Tunnel an unseren Server weiter. Der Server nimmt nur Datenverkehr aus dem Tunnel an. Kein Dienst veröffentlicht einen Port ins Internet.
Die Container laufen mit schreibgeschütztem Root-Dateisystem, ohne zusätzliche Linux-Capabilities, ohne das Recht, neue Privilegien zu erlangen, mit Speicherlimits und als Benutzer ohne Administratorrechte.
Die Datenbank ist aus dem Internet nicht erreichbar; die Dienste kommunizieren über ein privates Netzwerk.
Cloudflare-Regeln sperren IP-Adressen, die viele abgelehnte Anfragen an den Collector senden, und lassen nur die erlaubten Methoden und den erlaubten Pfad durch.
Die Anmeldung erfolgt mit Google, einem sechsstelligen Code per E-Mail (5 Minuten gültig und nur als Hash gespeichert) oder einem Passkey. Es gibt keine Passwörter.
Sitzungen dauern höchstens 30 Tage und werden bei Nutzung erneuert. Das Sitzungs-Cookie ist für Skripte nicht lesbar. Aufrufe aus dem Browser an die Anwendung brauchen die Sitzung und einen Schutz-Header gegen Cross-Site-Request-Forgery. Die REST-API und der MCP-Server akzeptieren nie ein Cookie.
Anfragen unterliegen Ratenbegrenzungen. Die Grenzen für die Anmeldung nutzen Hashes mit Schlüssel aus IP-Adresse und E-Mail-Adresse, mit höchstens fünf Codes je Adresse in 15 Minuten.
Die Server akzeptieren SSH nur mit Schlüsseln, auf einem nicht standardmäßigen Port. Anmeldung mit Passwort und direkte Root-Anmeldung aus dem Internet sind nicht möglich. Eine Firewall verwirft allen eingehenden Datenverkehr außer den Web-Ports und SSH. Ein Intrusion-Prevention-System (CrowdSec) sperrt angreifende IP-Adressen.
Sicherheitsupdates des Betriebssystems werden jeden Tag automatisch installiert. Container-Images sind auf Versionen festgelegt und werden jede Woche auf bekannte Schwachstellen geprüft.
Administrationsoberflächen liegen hinter Cloudflare Access. Nur die Geschäftsführer können sich anmelden.
Nur die Geschäftsführer haben persönlichen administrativen Zugriff auf die Produktionssysteme. Automatisierte Systeme (Deployment, Datenbankmigrationen) nutzen eigene Schlüssel mit eingeschränkten Rechten. Die Geschäftsführer vergeben und entziehen Zugriffe über unser Konfigurationsmanagement.

Zugriffskontrolle (Vertraulichkeit)

Rollen je Organisation: Owner, Admin und Member mit abgestuften Rechten. Der Dienst liest die Mitgliedschaft bei jeder Anfrage aus der Datenbank. Die Rolle stammt nie aus dem Cookie.
API-Schlüssel gehören zur Organisation, und nur Owner und Admins erstellen sie in der App. Ein Schlüssel wird nur als Hash oder Fingerabdruck gespeichert und einmal angezeigt. Zugriffstoken für KI-Clients sind eine Stunde gültig, Refresh-Token 30 Tage.
Eine Verbindung eines KI-Clients über den MCP-Server kann standardmäßig lesen. Eine Verbindung kann Schreibrechte nur bekommen, wenn der Kunde das wählt, und zerstörerische Handlungen brauchen eine ausdrückliche Bestätigung.
Eine Änderung, die Mira im Chat vorschlägt, wird erst wirksam, nachdem ein Mitglied sie mit einem Klick bestätigt hat. Sie läuft mit den Rechten dieses Mitglieds.
Zugriff von Mitarbeitern: Mitarbeiter der Plattform (die Gründer) nutzen einen Admin-Bereich, der kundenübergreifend lesen kann. Jeder Lese- und Schreibzugriff von Mitarbeitern wird in einem Audit-Protokoll erfasst. Es gibt keine Funktion, mit der sich Mitarbeiter als Kunde anmelden können.

Trennungskontrolle (Vertraulichkeit)

Jede Abfrage ist auf das Projekt des Kunden beschränkt. Das Projekt stammt aus dem authentifizierten Kontext, nie aus der Eingabe. Ein Projekt eines anderen Kunden antwortet mit „nicht gefunden“.
Die tägliche Besucherkennung gilt nur für ein Projekt.
Jede Quelle hat einen eigenen Schlüssel zum Senden von Daten.
Zugangsdaten für verbundene Plattformen (OAuth-Token und Schlüssel) werden je Projekt mit AES-256-GCM verschlüsselt und sind an dieses Projekt und diese Verbindung gebunden.

Pseudonymisierung und Datenminimierung (Vertraulichkeit)

Die IP-Adresse eines Besuchers wird nie in der Datenbank gespeichert, und die Anwendung schreibt sie nie in ein Protokoll. Der User-Agent wird auf Gerätetyp, Browser und Betriebssystem reduziert; der User-Agent selbst wird nicht gespeichert.
Von Seitenadressen werden nur der Pfad (mit durch :id ersetzten Kennungen), UTM-Parameter und Klick-Kennungen behalten. Ein Referrer wird auf seinen Host reduziert. Klick-Kennungen werden nur mit Marketing-Einwilligung als Werte gespeichert.
Ohne Einwilligung ist die Besucherkennung ein Tageswert, und der tägliche Salt wird am Ende des Tages gelöscht. Besuche ohne Einwilligung werden nie einer namentlich bekannten Person zugeordnet.
Kontaktmerkmale (E-Mail-Adresse, Telefonnummer) werden standardmäßig als Hashes mit Schlüssel gespeichert.
Suchbegriffe und Formularbezeichnungen, die persönlich aussehen, werden ersetzt.
Das Tracking-Skript liest keine Formularfelder.
Texte, die aus getrackten Daten stammen, sind als Daten markiert, wenn Mira sie liest, sodass das Modell sie nicht als Anweisungen behandelt.
Das Fehler-Monitoring läuft als selbst gehostetes Sentry auf unserem eigenen Server in Falkenstein, Deutschland. Fehlerberichte werden 14 Tage aufbewahrt. Die Anwendung entfernt Nutzerdaten, Cookies, Header, Anfragekörper und Query-Strings, bevor sie einen Bericht sendet.

Weitergabekontrolle (Integrität)

Cloudflare beendet die verschlüsselte Verbindung (TLS) für die App, die API und den Collector in dem Modus, der das Zertifikat unseres Servers prüft. Die Anwendung und die Website setzen HSTS.
Zugangsdaten für verbundene Plattformen (OAuth-Token und Stripe-Schlüssel) werden mit AES-256-GCM verschlüsselt gespeichert. Stripe-Schlüssel, die ein Kunde eingibt, müssen schreibgeschützte Schlüssel sein. Ein geheimer Schlüssel wird abgelehnt.
Backups werden auf unserem Server mit AES-256 verschlüsselt, bevor sie ihn verlassen. Der Schlüssel liegt außerhalb des Backup-Speichers. Der Backup-Bucket sperrt öffentlichen Zugriff, akzeptiert nur verschlüsselte Verbindungen, verschlüsselt seine Objekte auch bei AWS und ist versioniert und schreibgeschützt.
Exportdateien sind 24 Stunden verfügbar und werden dann gelöscht. Der Download-Link ist 15 Minuten gültig.
Kundendaten gehen nur an Unterauftragsverarbeiter und an Empfänger, die der Kunde selbst wählt. Wir senden keine Besucherdaten an die Plattformen, die der Kunde verbindet.

Eingabekontrolle (Integrität)

Ein Audit-Protokoll erfasst jeden Aufruf über die REST-API, den MCP-Server und den Chat mit Akteur, Handlung, Ergebnis und Dauer, aber nie mit der Eingabe oder dem Ergebnis, für 90 Tage.
Handlungen unserer Mitarbeiter werden in einem eigenen Audit-Protokoll für 365 Tage erfasst.
Die Annahme dieses AVV und jede Anfrage einer betroffenen Person werden mit der Person, dem Zeitpunkt und dem Ergebnis erfasst.

Verfügbarkeit und Belastbarkeit

Fortlaufende Archivierung des Datenbankprotokolls, jede Woche ein vollständiges Backup und jeden Tag ein differenzielles Backup, in ein verschlüsseltes Repository bei AWS in Frankfurt. Die beiden neuesten vollständigen Backups werden aufbewahrt, sodass die Daten zu einem Zeitpunkt innerhalb der letzten 7 bis 14 Tage wiederhergestellt werden können.
Die Dienste haben Health-Checks und Speicherlimits. Prometheus, Alertmanager und Grafana auf unserem eigenen Server in Deutschland überwachen Verfügbarkeit, Last und Fehler. Alarme erreichen die Geschäftsführer als Push-Benachrichtigung und per E-Mail.
Cloudflare-Regeln, Ratenbegrenzungen und Grenzen für die Zahl der Ereignisse je Besucher und Stunde schützen vor Überlastung und Angriffen. Anfragen von Bots werden verworfen.

Datenschutzmanagement (Überprüfung)

Wir überprüfen diese Maßnahmen mindestens einmal im Jahr und immer, wenn sich der Dienst oder die Infrastruktur wesentlich ändert.
Personen mit Zugriff auf Kundendaten haben sich zur Vertraulichkeit verpflichtet.

Reaktion auf Vorfälle (Überprüfung)

Fehlerberichte, Metriken und die Cloudflare-Regeln melden Auffälligkeiten. Wir bewerten sie und melden Verletzungen nach Abschnitt 7.

Datenschutz durch Voreinstellungen (Überprüfung)

Ein neues Projekt startet im Modus hybrid: Ohne Einwilligung wird nichts auf dem Gerät eines Besuchers gespeichert.
Das Global-Privacy-Control-Signal wird beachtet.
Die REST-API und der MCP-Server geben standardmäßig Lesezugriff.
Die Aufbewahrung wird automatisch durch regelmäßige Löschjobs durchgesetzt.

Auftragskontrolle (Überprüfung)

Wir setzen Unterauftragsverarbeiter nur mit einem Vertrag nach Art. 28 DSGVO ein (Abschnitt 5).
Wir verarbeiten Kundendaten nur auf Weisung des Kunden (Abschnitt 2). Jede Handlung unserer Mitarbeiter im Admin-Bereich wird protokolliert.

Anlage 3: Unterauftragsverarbeiter

Die Unterauftragsverarbeiter, ihre Leistungen, ihre Verarbeitungsorte und die Übermittlungsgrundlagen stehen auf der Seite Unterauftragsverarbeiter. Diese Liste ist Teil dieses AVV. Abschnitt 5 regelt Änderungen daran.