Technische und organisatorische Maßnahmen (TOM)

Diese Anlage 2 ist integraler Bestandteil des zwischen dem Verantwortlichen (Brand-Org/Kunde, nachfolgend „Auftraggeber" oder „Verantwortlicher") und dem Auftragsverarbeiter geschlossenen Auftragsverarbeitungsvertrags (AVV) gemäß Art. 28 DSGVO. Sie beschreibt die vom Auftragsverarbeiter getroffenen technischen und organisatorischen Maßnahmen (TOM) zur Gewährleistung eines dem Risiko angemessenen Schutzniveaus im Sinne von Art. 32 DSGVO.

Geltungsbereich / Rollenabgrenzung: Vertragsgegenstand dieser Anlage ist die Auftragsverarbeitung der im Auftrag der Brand-Org verarbeiteten Daten (Kampagnen-/Creator-/Asset-Daten). Soweit nachfolgend Maßnahmen für Verarbeitungen dargestellt werden, für die Collavo eigener Verantwortlicher ist (insbesondere Account-/Login-Daten, DAC7-Steuerdaten `CreatorTaxData`, BZSt-Meldung), geschieht dies zur Transparenz über das einheitliche Sicherheitsniveau der Plattform; diese Verarbeitungen werden nicht von der Brand-Org „bestellt" und unterliegen nicht ihrer Weisung. Die betreffenden Maßnahmen sind im Text als Eigenverarbeitung Collavos kenntlich gemacht (vgl. § 7.3); die abschließende Rollenabgrenzung ist mit dem AVV-Hauptdokument und der Datenschutzerklärung konsistent zu halten.

Auftragsverarbeiter

[PLATZHALTER: Firmierung/Rechtsform der Betreibergesellschaft (z. B. nojoma GmbH)]

[PLATZHALTER: Ladungsfähige Anschrift]

Vertreten durch: [PLATZHALTER: Vertretungsberechtigte:r / Geschäftsführer:in]

Handelsregister: [PLATZHALTER: Registergericht und Registernummer]

USt-IdNr.: [PLATZHALTER: USt-IdNr.]

Datenschutzbeauftragte:r / Datenschutzkontakt: [PLATZHALTER: Name und Kontakt, falls bestellt]

Zuständige Aufsichtsbehörde: [PLATZHALTER: zuständige Landes-Datenschutzbehörde nach Firmensitz]

Produkt / Verarbeitungsumgebung: Collavo (collavo.ai) — Creator-Operations-Plattform und Marktplatz für Brands (B2B-Organisationen, mehrmandantenfähig) und Creator. Web-Frontend (Next.js, gehostet bei Vercel), API-Backend (NestJS, gehostet bei Railway), Mobile-Apps (Expo/React Native).

Prüfturnus: mindestens jährlich sowie unverzüglich bei jeder wesentlichen Änderung der Verarbeitung, der eingesetzten Infrastruktur oder der Risikolage. Stand der vorliegenden Fassung: [PLATZHALTER: Datum/Version].

Hinweis zur Belegbarkeit: Mit „(aus Architektur abgeleitet — vom Betreiber zu verifizieren)" gekennzeichnete Maßnahmen sind aus der technischen Architektur von Collavo abgeleitet, aber noch nicht offiziell bestätigt; sie sind vor Veröffentlichung der Anlage durch den Betreiber zu verifizieren oder zu korrigieren. Als [PLATZHALTER] markierte Angaben sind ausschließlich vom Betreiber einzusetzen und dürfen nicht erfunden werden.

1.1 Maßgebende Faktoren

Die nachfolgenden Maßnahmen wurden unter Berücksichtigung

• des Stands der Technik,
• der Implementierungskosten,
• der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie
• der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen

festgelegt (Art. 32 Abs. 1 DSGVO). Sie setzen zugleich die Grundsätze von Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO) um.

1.2 Verarbeitete Datenkategorien (Risikoprofil)

Im Auftrag des Verantwortlichen sowie im Rahmen des Plattformbetriebs werden insbesondere folgende Kategorien personenbezogener Daten verarbeitet:

Besondere Kategorien personenbezogener Daten i. S. d. Art. 9 DSGVO werden nicht systematisch und nicht bestimmungsgemäß verarbeitet; nutzergenerierte Inhalte können solche Daten jedoch unbeabsichtigt enthalten. Steuer- und Finanzdaten erfordern aufgrund ihres Missbrauchspotenzials ein erhöhtes Schutzniveau (vgl. §§ 5, 7).

1.3 Gliederung nach Schutzzielen

Die Darstellung folgt den Schutzzielen des Art. 32 DSGVO i. V. m. der etablierten Kontrollsystematik (Vertraulichkeit, Integrität, Verfügbarkeit/Belastbarkeit, Pseudonymisierung/Verschlüsselung, Verfahren regelmäßiger Überprüfung sowie Auftrags- und Trennungskontrolle):

• § 2 Vertraulichkeit (Zutritts-, Zugangs-, Zugriffs-, Trennungskontrolle)
• § 3 Integrität (Eingabe-, Weitergabekontrolle, Audit-Logs)

2.1 Zutrittskontrolle (physischer Schutz)

Collavo betreibt keine eigenen Rechenzentren; die Verarbeitung erfolgt vollständig auf Cloud-Infrastruktur spezialisierter Anbieter. Der physische Zutrittsschutz wird daher über die eingesetzten Dienstleister sichergestellt (zur datenschutzrechtlichen Rolle — Auftragsverarbeiter vs. eigenständig Verantwortlicher, u. a. Stripe — vgl. § 8.2):

• Neon (Postgres-Datenbank, inkl. Schema `better_auth` mit Sessions): Betrieb in zertifizierten Rechenzentren; EU-Region wählbar — die Auswahl einer EU-Region ist vom Betreiber zu konfigurieren und zu bestätigen (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Vercel (Web-Hosting Next.js): Rechenzentren mit Zutrittskontrolle; Hostingstandort USA, Transfergrundlage je Dienst — vorrangig DPF (falls zertifiziert), sonst SCC/TIA (vgl. § 8.3 und Anlage „Subauftragsverarbeiter").
• Railway (API-Hosting NestJS, Redis): Zutrittskontrolle über den Provider; Standort/Region zu verifizieren (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Cloudflare R2 (Asset-Speicher): global verteilte, zutrittsgesicherte Rechenzentren.
• Stripe (Zahlungen/Escrow/Auszahlungen): PCI-DSS-zertifizierte Umgebung mit physischem Zutrittsschutz.

Die jeweils maßgeblichen Zertifizierungen der Subauftragsverarbeiter (z. B. ISO 27001, SOC 2, PCI-DSS) werden auf Verlangen des Verantwortlichen nachgewiesen (§ 8, § 11).

2.2 Zugangskontrolle (Schutz gegen unbefugte Systemnutzung)

• Authentifizierung über self-hosted Better Auth. Collavo betreibt ein eigengehostetes Authentifizierungssystem (Better Auth) — nicht Auth0 oder einen vergleichbaren Fremddienst. Sitzungen (Sessions) werden im Postgres-Schema `better_auth` bei Neon gespeichert.
• Token-Verfahren: Ausstellung von JWTs mit EdDSA-Signatur (asymmetrisches Signaturverfahren). Sitzungs- und Token-Gültigkeit sind serverseitig kontrollierbar; Sessions sind in der Datenbank revozierbar (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Föderierte Anmeldung: Google-OAuth als alternativer Anmeldeweg; die Passwortprüfung liegt insoweit beim Identity-Provider.
• Passwortsicherheit: Speicherung ausschließlich als kryptografischer Hash (kein Klartext); Hash-Verfahren und Parameter gemäß Better-Auth-Standard (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Mehr-Faktor-Authentifizierung (MFA): für administrative/privilegierte Zugänge zur Infrastruktur (Cloud-Konsolen von Neon, Vercel, Railway, Cloudflare, Stripe) — [PLATZHALTER: MFA-Pflicht für alle Betreiber-Admin-Konten bestätigen]. Verpflichtende MFA für finanz-/auszahlungsrelevante Endnutzerrollen (Creator-Konten mit Stripe-Auszahlungen, Brand-Konten mit Finanz-Scope FINANCE): MFA ist für diese Rollen im Sinne des „Stands der Technik" (Art. 32 Abs. 1 DSGVO) zwingend vorzusehen, nicht nur optional verfügbar zu halten — [PLATZHALTER: verpflichtende MFA für finanzrelevante Endnutzerrollen technisch bestätigen]. Für übrige Endnutzer-Konten ist MFA mindestens als Option bereitzustellen (aus Architektur abgeleitet — vom Betreiber zu verifizieren).

3.1 Eingabekontrolle

• Protokollierung von schreibenden Vorgängen (Audit-Logs). Sicherheits- und datenschutzrelevante Schreibvorgänge werden nachvollziehbar protokolliert und der auslösenden authentifizierten Identität zugeordnet (aus Architektur abgeleitet — vom Betreiber zu verifizieren). Dies betrifft insbesondere:
  • finanzbezogene Vorgänge (Stripe: Charges, Transfers, Releases, Refunds);
  • Vorgänge im Rechte-Modul (Einräumung/Änderung von Nutzungsrechten);
  • Consent-Vorgänge (append-only `ConsentRecord`, vgl. § 3.4);
  • Werbekennzeichnungs-Overrides (`acknowledgedUWG5a`, vgl. § 3.5).
• Append-only-Datenstrukturen für Einwilligungs- und ggf. Audit-Records: nachträgliche Änderung/Löschung einzelner Einträge ist nicht vorgesehen; Statusänderungen erfolgen durch Neu-Eintrag (z. B. Widerruf einer Einwilligung durch neuen `ConsentRecord`).
• Validierung von Eingaben server- und clientseitig zur Wahrung der Datenintegrität (aus Architektur abgeleitet — vom Betreiber zu verifizieren).

3.2 Weitergabekontrolle

• Transportverschlüsselung (TLS) für sämtliche Datenübertragungen zwischen Client, Web (Vercel), API (Railway), Datenbank (Neon), Objektspeicher (Cloudflare R2) sowie zu externen Schnittstellen (vgl. § 5.1).
• Signierte, zeitlich begrenzte URLs für jeden Asset-Zugriff (Cloudflare R2); dadurch wird unkontrollierte Weitergabe von Mediendaten technisch eingeschränkt.
• Dokumentierte Schnittstellen (APIs). Datenflüsse zu externen Diensten erfolgen über definierte, autorisierte Schnittstellen. Soweit die Schnittstelle zu einer Plattform führt, die für die dortige Verarbeitung eigenständig (bzw. gemeinsam) verantwortlich ist (Publishing/Insights zu Meta/Instagram, TikTok, YouTube; Google-OAuth-Login), handelt es sich um eine Übermittlung an einen eigenständig Verantwortlichen/Empfänger, nicht um eine Auftragsverarbeitung (vgl. § 8.2):
  • Publishing/Insights zu Meta/Instagram (Graph API), TikTok, YouTube via OAuth (nutzerautorisierte Tokens, scope-begrenzt) — die jeweilige Plattform verarbeitet die Daten ihres eigenen Dienstes als eigenständig Verantwortliche;
  • Zahlungen via Stripe (Connected Accounts Express, separate charges und transfers);
  • Transaktions-E-Mail via SendGrid;
  • KI-Verarbeitung via OpenAI (vgl. § 10);
  • DAC7-Meldung an das BZSt (Bundeszentralamt für Steuern).
• Audit-Logging von Datenexporten sicherheitsrelevanter Art (aus Architektur abgeleitet — vom Betreiber zu verifizieren).

4.1 Verfügbarkeit der Infrastruktur

• Managed-Cloud-Dienste mit Provider-SLA: Datenbank (Neon), Web (Vercel), API (Railway), Objektspeicher (Cloudflare R2), Zahlungen (Stripe). Die jeweiligen Verfügbarkeits-SLAs ergeben sich aus den Verträgen mit den Subauftragsverarbeitern — [PLATZHALTER: konkrete SLA-Werte / Verfügbarkeitszusagen je Provider dokumentieren].
• Skalierung/Lastverteilung über die Managed-Plattformen (u. a. Vercel-Edge/Serverless, Railway) (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• DDoS-Schutz auf Netzwerkebene über Cloudflare/Provider-Ebene (aus Architektur abgeleitet — vom Betreiber zu verifizieren).

4.2 Backup und Wiederherstellbarkeit

• Datenbank-Backups (Neon): automatisierte Backups bzw. Point-in-Time-Recovery gemäß Provider-Funktionalität — [PLATZHALTER: konkrete Backup-Frequenz, Aufbewahrungsdauer und PITR-Fenster bestätigen].
• RPO/RTO: [PLATZHALTER: Recovery Point Objective und Recovery Time Objective festlegen und dokumentieren] (Empfehlung: RPO ≤ 24 h, RTO ≤ 8 h für kritische Verarbeitungen).
• Objektspeicher-Redundanz (Cloudflare R2): providerseitige Redundanz der Assets.
• Wiederherstellungstests: dokumentierte und regelmäßig erprobte Wiederherstellungsverfahren — [PLATZHALTER: Turnus der Restore-Tests festlegen, Empfehlung mindestens halbjährlich].

4.3 Monitoring und Belastbarkeit

• Fehler-/Performance-Monitoring via Sentry: zentrale Erfassung von Laufzeitfehlern und Ausnahmen zur frühzeitigen Erkennung von Störungen — Region/Standort und ggf. Datenminimierung (Scrubbing personenbezogener Daten in Fehlerberichten) zu verifizieren (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Mobile-Build/Update- und Push-Infrastruktur via Expo für die iOS-/Android-Apps; Bereitstellungs- und Update-Prozesse über Expo (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Alerting bei sicherheits-/verfügbarkeitsrelevanten Ereignissen — [PLATZHALTER: Alerting-/Eskalationswege dokumentieren].

5.1 Verschlüsselung in der Übertragung (in transit)

• TLS für sämtliche Verbindungen (Client ↔ Web ↔ API ↔ Datenbank ↔ Objektspeicher sowie zu externen Schnittstellen). Empfohlene Konfiguration: TLS 1.2/1.3 mit Forward Secrecy gemäß BSI TR-02102 — [PLATZHALTER: eingesetzte TLS-Version/Cipher-Konfiguration bestätigen].

5.2 Verschlüsselung im Ruhezustand (at rest) und Feldverschlüsselung

• Feldverschlüsselung sensibler Steuerdaten: Steuer-ID (TIN) und USt-IdNr. werden in der isolierten Tabelle `CreatorTaxData` feldweise mit AES-256-GCM verschlüsselt gespeichert (authentifizierte Verschlüsselung mit Integritätsschutz).
• HMAC-Pepper: Zur sicheren, suchbaren bzw. abgleichbaren Verarbeitung der Steuerdaten wird ein HMAC mit serverseitigem Pepper eingesetzt; der Pepper ist getrennt von den verschlüsselten Daten zu verwahren (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Schlüsselverwaltung: Verschlüsselungs- und HMAC-Schlüssel/Pepper werden außerhalb der Datenbank verwaltet; Zugriff streng begrenzt; Rotation — [PLATZHALTER: Schlüsselverwaltung (KMS/Secret-Manager), Rotationsturnus und Trennung der Schlüsselverwahrung dokumentieren].
• Verschlüsselung der Datenbank/Backups at rest: providerseitige Verschlüsselung bei Neon — [PLATZHALTER: Encryption-at-rest des Datenbank-Providers und der Backups bestätigen].
• Verschlüsselung des Objektspeichers at rest: providerseitige Verschlüsselung bei Cloudflare R2 (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Krypto-Erase / Crypto-Shredding: Für die feldverschlüsselten Steuerdaten (`CreatorTaxData`) ist die Löschung auch durch gesicherte Vernichtung des zugehörigen Schlüssel-/Pepper-Materials zu gewährleisten (Krypto-Erase), sodass verschlüsselte Restbestände — auch in Backups — nicht mehr entschlüsselbar sind — [PLATZHALTER: Krypto-Erase- und Schlüssellöschkonzept dokumentieren] (vgl. § 9.1).

5.3 Pseudonymisierung

• Consent-Cookie (HMAC-gesichert): für nicht angemeldete Besucher:innen ohne unmittelbaren Personenbezug; bei angemeldeten Nutzer:innen ist der Einwilligungsstatus kontobezogen und damit personenbezogen (keine Anonymisierung; die HMAC-Sicherung dient der Integrität, vgl. § 3.4).
• Trennung der Zuordnung sensibler Steuerdaten von den übrigen Profildaten durch die isolierte Tabelle `CreatorTaxData`.
• Test-/Entwicklungsumgebungen: Verarbeitung personenbezogener Daten in Test-/Entwicklungsumgebungen ausschließlich pseudonymisiert/anonymisiert oder mit synthetischen Daten — [PLATZHALTER: Vorgehen zu Test-/Entwicklungsdaten verbindlich festlegen].

• Regelmäßige Überprüfung der Wirksamkeit der TOM: mindestens jährlich sowie anlassbezogen (Änderung der Verarbeitung, sicherheitsrelevante Vorfälle) — [PLATZHALTER: konkreten Prüfprozess und Verantwortliche benennen].
• Schwachstellen-/Sicherheitsmanagement:
  • Abhängigkeits-/Schwachstellen-Scanning der Software-Komponenten (aus Architektur abgeleitet — vom Betreiber zu verifizieren);
  • kontinuierliches Fehler-/Anomalie-Monitoring (Sentry);
  • [PLATZHALTER: Penetrationstests durch unabhängige Dritte — Turnus festlegen, Empfehlung mindestens jährlich].
• Patch-Management: zeitnahes Einspielen sicherheitsrelevanter Updates der Plattformen und Bibliotheken — [PLATZHALTER: Patch-/Update-Prozess dokumentieren].
• Überprüfung der Subauftragsverarbeiter: Bewertung der bei den Subauftragsverarbeitern vorgehaltenen Zertifizierungen/Berichte (ISO 27001, SOC 2, PCI-DSS) (vgl. § 8, § 11).
• Dokumentation und Rechenschaftspflicht: Ergebnisse der Überprüfungen werden dokumentiert (Art. 5 Abs. 2 DSGVO).
• Aktualisierung dieser Anlage: mindestens jährliche Prüfung auf Aktualität (vgl. § 12).

7.1 Mandantentrennung der Brand-Organisationen

• Collavo ist mehrmandantenfähig; jede Brand-Organisation bildet einen eigenen Tenant.
• Sämtliche tenant-bezogenen Daten sind über `organizationId` logisch getrennt; jede Datenabfrage ist serverseitig auf die `organizationId` des authentifizierten Kontexts begrenzt. Ein Querzugriff zwischen Mandanten ist technisch ausgeschlossen (aus Architektur abgeleitet — vom Betreiber zu verifizieren).
• Das Insights-Rollenkonzept (`insights-roles`) begrenzt zusätzlich den Zugriff auf Reichweiten-/Analysedaten innerhalb eines Mandanten.

7.2 Agentur-Konstellation (Stellvertretung)

Im Agentur-Modul handeln Agenturen über `AgencyCreatorRoster`-Mandate im Namen des Creators, begrenzt durch definierte Scopes (`CONTENT` / `FINANCE`) und mit Provisionsabbildung (`commissionBps`). Die Zugriffstrennung folgt dem jeweiligen Mandatsumfang; finanzbezogener Zugriff (`FINANCE`) ist von inhaltlichem Zugriff (`CONTENT`) getrennt steuerbar (aus Architektur abgeleitet — vom Betreiber zu verifizieren). Die datenschutzrechtliche Rollenzuordnung in dieser Konstellation ist gesondert zu bewerten — [PLATZHALTER: datenschutzrechtliche Einordnung der Agentur-Stellvertretung (Auftragsverarbeitung vs. eigene Verantwortlichkeit) anwaltlich klären].

7.3 Trennung von Verarbeitungszwecken

• Rollentrennung Verantwortlicher/Auftragsverarbeiter: Collavo ist hinsichtlich eigener Plattformnutzer (Account, Login, Profil) Verantwortlicher und hinsichtlich der im Auftrag der Brands verarbeiteten Kampagnen-/Creator-/Asset-Daten Auftragsverarbeiter. Die Verarbeitungszwecke und Zugriffe sind entsprechend getrennt.
• Trennung sensibler Steuerdaten in eigener Tabelle (`CreatorTaxData`) mit eigener Verschlüsselung und engem Zugriff (§ 5.2).
• Umgebungstrennung: getrennte Produktions-, Test- und Entwicklungsumgebungen — [PLATZHALTER: Umgebungstrennung und Datenflussbeschränkungen bestätigen].

8.1 Weisungsgebundenheit

Der Auftragsverarbeiter verarbeitet die im Auftrag der Brand-Org überlassenen personenbezogenen Daten ausschließlich auf dokumentierte Weisung des Verantwortlichen (Art. 28 Abs. 3 lit. a, Art. 29 DSGVO), soweit nicht eine gesetzliche Verpflichtung besteht (z. B. DAC7-Meldepflicht gegenüber dem BZSt). Weisungswege und -dokumentation ergeben sich aus dem AVV-Hauptdokument.

8.2 Subauftragsverarbeiter und sonstige Datenempfänger

Bei den eingesetzten Dienstleistern ist datenschutzrechtlich zwischen (A) echten Subauftragsverarbeitern (weisungsgebunden, Art. 28 DSGVO) und (B) eigenständig (bzw. gemeinsam) Verantwortlichen/Empfängern zu unterscheiden, an die Daten übermittelt werden, ohne dass eine Auftragsverarbeitung vorliegt. Diese Unterscheidung ist für Pflichtenkette und Transfermechanismus maßgeblich und mit dem AVV-Hauptdokument sowie der Datenschutzerklärung konsistent zu halten. Die endgültige Rollenzuordnung steht unter anwaltlichem Vorbehalt.

Hinweis zu Transfergrundlagen: Für US-Anbieter ist seit dem Angemessenheitsbeschluss vom 10.07.2023 die DPF-Zertifizierung (EU-US Data Privacy Framework) — soweit vorhanden — die vorrangige Transfergrundlage (Angemessenheitsbeschluss); SCC + TIA dienen nur als Fallback für nicht zertifizierte Anbieter. Der DPF-Status ist je Dienst zu prüfen (nicht eigenmächtig festzulegen).

(A) Echte Subauftragsverarbeiter (Art. 28 Abs. 4 DSGVO). Diese halten mindestens gleichwertige technische und organisatorische Maßnahmen vor; die vertragliche Durchleitung der Pflichten erfolgt nach Art. 28 Abs. 4 DSGVO. Übersicht (vor Veröffentlichung zu verifizieren):

• Datenschutzbeauftragte:r / Datenschutzkontakt: [PLATZHALTER: Benennung und Kontakt, falls bestellungspflichtig/bestellt].
• Verpflichtung auf Vertraulichkeit aller mit der Verarbeitung befassten Personen (Art. 28 Abs. 3 lit. b, Art. 29, Art. 32 Abs. 4 DSGVO) — [PLATZHALTER: Verschwiegenheitsverpflichtungen dokumentieren].
• Datenschutz-/Security-Schulungen: regelmäßige Sensibilisierung der Mitarbeitenden — [PLATZHALTER: Schulungsturnus und Nachweisführung].
• Berechtigungsmanagement / Joiner-Mover-Leaver-Prozess: umgehender Entzug von Zugriffsrechten bei Rollenwechsel/Austritt — [PLATZHALTER: Prozess dokumentieren].
• Incident-Response- und Meldeprozess: Verfahren zur Erkennung, Bewertung und Meldung von Datenschutzverletzungen; Meldung an den Verantwortlichen unverzüglich, spätestens binnen 24 Stunden nach Kenntnis einer Datenpanne (Art. 33 Abs. 2 DSGVO i. V. m. AVV). Maßgeblich ist die unverzügliche Meldung; die 24-Stunden-Grenze trägt der eigenen 72-Stunden-Frist des Verantwortlichen (Art. 33 Abs. 1 DSGVO) Rechnung — [PLATZHALTER: konkrete Meldewege/Fristen mit AVV-Hauptdokument abstimmen].
• Richtlinienwerk: IT-Sicherheits-/Datenschutzrichtlinien, Passwort-/Zugriffsrichtlinie — [PLATZHALTER: Richtliniendokumente referenzieren].
• Verzeichnis von Verarbeitungstätigkeiten (Art. 30 Abs. 2 DSGVO) als Auftragsverarbeiter wird geführt — [PLATZHALTER: Verweis/Stand bestätigen].

9.1 Datenlöschung und Aufbewahrung

• Selbstbedienungs-Löschflow: Nutzer können die Löschung ihres Kontos anstoßen. Ablauf: 24-Stunden-Verifizierungslink, anschließend 14-Tage-Karenzzeit (Grace Period), danach Hard-Delete mit Kaskadierung über die abhängigen Datensätze.
• Behandlung verschlüsselter Sonderdaten und Backups: Für die feldverschlüsselten Steuerdaten (`CreatorTaxData`) erfolgt die Löschung — soweit keine gesetzlichen Aufbewahrungspflichten entgegenstehen — auch durch Krypto-Erase (Vernichtung des zugehörigen Schlüssel-/Pepper-Materials), sodass etwaige Restbestände nicht mehr entschlüsselbar sind (vgl. § 5.2). In Backups verbleibende Daten werden spätestens mit Ablauf des regulären Backup-Aufbewahrungsfensters bereinigt — [PLATZHALTER: Backup-Bereinigungsfristen und Krypto-Erase-Verfahren dokumentieren].
• Datenträgerkontrolle: Da kein eigener Betrieb von Datenträgern erfolgt, wird die sichere Datenträgervernichtung/-bereinigung über die zertifizierten Verfahren der Cloud-Provider (Neon, Cloudflare R2 u. a.) sichergestellt (vgl. § 11).
• Gesetzliche Aufbewahrungspflichten (insb. steuer-/handelsrechtlich, DAC7-Meldedaten) bleiben unberührt; betroffene Daten werden gesperrt statt gelöscht, soweit Aufbewahrungspflichten entgegenstehen — [PLATZHALTER: konkrete Aufbewahrungsfristen je Datenkategorie festlegen].

• Eingesetzte KI-Funktionen: Caption-/Hashtag-/Brief-Generierung sowie ein RAG-Chat-Assistent auf Basis von OpenAI.
• Keine ausschließlich automatisierte Entscheidung im Sinne von Art. 22 DSGVO: schreibende Assistenten-Tools sind mit `requiresConfirmation` ausgestaltet — vor Wirksamwerden ist eine menschliche Freigabe erforderlich.
• Datenminimierung gegenüber dem KI-Dienst: Übermittlung nur der für den jeweiligen Zweck erforderlichen Daten an OpenAI; keine Übermittlung der feldverschlüsselten Steuerdaten (`CreatorTaxData`) — [PLATZHALTER: Umfang der an OpenAI übermittelten Daten und etwaige No-Training-/Zero-Retention-Vereinbarung bestätigen].
• Transfergrundlage: USA → vorrangig DPF-Angemessenheitsbeschluss (falls OpenAI zertifiziert), sonst SCC/TIA; je Dienst zu prüfen (vgl. § 8.3).
• Transparenz (Art. 50 KI-VO): Die einschlägigen Transparenzpflichten werden nach Absätzen differenziert:
  • Chat-Assistent (direkte Interaktion): Hinweis, dass mit einem KI-System interagiert wird (Art. 50 Abs. 1 KI-VO — Anbieterpflicht; Collavo stellt diesen Hinweis als Betreiber im Interface sicher).
  • Synthetische Inhalte (Caption-/Hashtag-/Brief-Generierung): maschinenlesbare Kennzeichnung der Ausgaben als künstlich erzeugt/manipuliert (Art. 50 Abs. 2 KI-VO) ist primär Anbieterpflicht (OpenAI); Collavo bestätigt/aktiviert die entsprechende Kennzeichnung und stellt zusätzlich die wahrnehmbare Transparenz gegenüber Endnutzer:innen sicher.
  • Die Kennzeichnungspflicht wird nicht allein auf die Nutzer:innen abgewälzt: Collavo gewährleistet die KI-Kennzeichnung plattformseitig; eine etwaige Eigen-Kennzeichnungspflicht der veröffentlichenden Creator (z. B. nach Plattform-/Werberecht) tritt ergänzend hinzu.
  • Betreiberpflichten nach Art. 50 Abs. 3 (Emotionserkennung/biometrische Kategorisierung) und Abs. 4 (Deepfakes/Texte zu Angelegenheiten öffentlichen Interesses) sind nach derzeitiger Funktionseinschätzung nicht einschlägig; abschließende Bewertung im KI-VO-Risikoeinstufungsdokument. Geltung der Art.-50-Transparenzpflichten ab 02.08.2026.
  • KI-Risikoeinstufung gesondert dokumentiert (voraussichtlich begrenztes Risiko, primär Transparenzpflichten) — [PLATZHALTER: Verweis auf KI-VO-Risikoeinstufung/Transparenzkonzept].

• Eigene Zertifizierungen des Auftragsverarbeiters: [PLATZHALTER: ISO/IEC 27001, SOC 2, BSI C5 o. Ä. — nur eintragen, falls tatsächlich vorhanden; andernfalls als „nicht vorhanden / in Vorbereitung" kennzeichnen]. Es dürfen keine Zertifizierungen behauptet werden, die nicht bestehen.
• Zertifizierungen der Subauftragsverarbeiter (Nachweise auf Verlangen): Stripe (PCI-DSS), sowie die jeweils einschlägigen ISO-27001-/SOC-2-Nachweise der weiteren Provider — [PLATZHALTER: konkrete Zertifikatsstände je Provider verifizieren].
• Orientierung an Standards: BSI TR-02102 (kryptografische Verfahren), ISO/IEC 27001:2022, BSI C5:2020 als Bewertungsmaßstab.
• Nachweisführung gegenüber dem Verantwortlichen (Audit-/Kontrollrechte) nach Maßgabe des AVV-Hauptdokuments (Art. 28 Abs. 3 lit. h DSGVO).

• Diese Anlage wird mindestens jährlich sowie unverzüglich bei wesentlichen Änderungen der Verarbeitung, der Infrastruktur, der Subauftragsverarbeiter oder der Risikolage überprüft und fortgeschrieben.
• Maßnahmen dürfen im Zuge technischer Weiterentwicklung angepasst werden, sofern das Schutzniveau nicht unterschritten wird (Art. 32 DSGVO).
• Maßgeblich ist die jeweils gültige, datierte und versionierte Fassung dieser Anlage.

Stand: [PLATZHALTER: Datum] · Version: [PLATZHALTER: vX]