← Zurück zum Auftragsverarbeitungsvertrag

Anlage 2 zur AVV — Technische und organisatorische Maßnahmen (TOM)

Korrektur 2026-08-01: Region am laufenden System verifiziert (Railway x-railway-edge: ams1 = Amsterdam; Atlas-Replica-Set-Host löst nach Frankfurt am Main auf). Frühere Angaben "US-West (Oregon)" waren unzutreffend; eine Drittlandsübermittlung findet für diese beiden Dienste nicht statt.

Korrektur 2026-08-01 (2): Login-Rate-Limit §5.1 am Code verifiziert. Die frühere Angabe "5/h pro IP" beschrieb eine Maßnahme, die so nie implementiert war; tatsächlich gelten zwei Buckets (5/15 min pro E-Mail, 30/15 min pro IP). Redaktionelle Richtigstellung einer bestehenden Maßnahme — keine Änderung der Verarbeitung, daher keine Mitteilung nach Art. 28(2).

Stand: 2026-08-01 · Version 2.5 Bezug: Anlage zu AVV-template-DE.md §5 (Art. 32 DSGVO) Verantwortlicher / Auftragsverarbeiter: Oleksandr Chornous (Boncard), Drewerstraße 5, 59602 Rüthen

1. Zweck und Bezug zum Standard-Datenschutzmodell (DSK SDM 3.1a)

Diese Anlage konkretisiert die technischen und organisatorischen Maßnahmen gemäß Art. 32 DSGVO, die Boncard als Auftragsverarbeiter ergreift, um die Sicherheit der Verarbeitung im Auftrag des Verantwortlichen zu gewährleisten. Sie ist verbindlicher Bestandteil der AVV.

Die nachfolgenden Maßnahmen werden den sieben Gewährleistungszielen des Standard-Datenschutzmodells der Datenschutzkonferenz (DSK SDM 3.1a, aktuelle redaktionelle Fassung) zugeordnet, um die Prüfbarkeit gegenüber Aufsichtsbehörden zu erleichtern:

2. Vertraulichkeit (Art. 32(1)(b))

2.1 Zugangskontrolle (physisch)

• Hosting bei zertifizierten Cloud-Anbietern (Railway, MongoDB Atlas) mit ISO 27001 / SOC 2 Typ II
• Keine eigene Serverhardware; physischer Zugang über Cloud-Provider-Audits abgedeckt
• Inhaber-Notebook: Vollverschlüsselung (BitLocker / FileVault), Bildschirmsperre 5 min

2.2 Zugriffskontrolle (logisch)

• Rollenbasierte Zugriffskontrolle (RBAC): SUPERADMIN / OWNER (zweistufiges Modell, src/lib/rbac.ts und src/lib/db/types.ts). Die frühere STAFF-Rolle wurde am 2026-05-18 entfernt — geteilte Mitarbeiter-Accounts sind nicht mehr vorgesehen; jeder Login eines Tenant-Inhabers ist OWNER.
• bcrypt-Hashing der Passwörter mit Cost ≥ 12
• JWT-Sessions, HttpOnly + SameSite=strict + Secure in Production, 30 Tage TTL
• Session-Invalidierung bei Passwort-Änderung (passwordChangedAt > JWT.iat)
• Aktive Sitzungen pro Nutzer einsehbar + widerrufbar (/admin/settings → Security)
• 2FA für Cloud-Provider-Konten (Railway, Atlas, Cloudflare, Domain-Registrar)

2.3 Weitergabekontrolle

• TLS 1.2+ auf allen öffentlichen Endpunkten (Let's Encrypt / Railway-managed)
• Keine Übertragung personenbezogener Daten an Dritte außerhalb der Subprozessor-Liste (AVV §5 der Online-Fassung bzw. §6 der Offline-Vorlage und TOM §2.5)
• Daten-Exports signiert und nur für autorisierten Empfänger

2.4 Eingabekontrolle

• Audit-Log aller administrativen Aktionen (audit_logs, Retention 90 Tage)
• Aktor-ID + Zeitstempel + IP + User-Agent
• Rekursive Redaktion sensibler Felder (src/lib/audit.ts)
• Append-only-Protokoll

2.5 Auftragskontrolle und Subprozessor-Liste

• AVV mit jedem Tenant (Click-through bei Signup, IP/UA-Beleg)
• Versionierung der AVV via POLICY_VERSIONS; Bump-Notification 30 Tage Grace
• Mindestens 30 Tage Vorab-Notification bei Subprozessor-Wechsel (EDPB Opinion 22/2024); Notfall-Wechsel mind. 14 Tage
• Sub-Auftragsverarbeiter-Liste in AVV §5 (Online-Fassung; §6 der Offline-Vorlage) + öffentliche /subprocessors Seite — abschließende Aufzählung:

Due-Diligence wird jährlich wiederholt; Auffälligkeiten oder Zertifikatsverlust lösen Subprozessor-Review (siehe §2.5 Notfall-Wechsel) aus. Nachweisdokumente werden lokal archiviert (C:\Users\New\Documents\Boncard-Legal\subprocessor-due-diligence\).

TIA-Register: Die Transfer Impact Assessments für sämtliche Drittlandtransfers werden in docs/legal/TIA-Annex-DE.md geführt: TIA-001 Railway Corp. (verpflichtend, da SCC-only ohne DPF), TIA-002 MongoDB Atlas, TIA-003 Resend, TIA-004 Cloudflare R2, TIA-005 Google LLC (Google Wallet API). Die Liste muss jeden Subprozessor aus §2.5 abdecken — sie endete bei TIA-004, während Google bereits als #5 geführt wurde.

2.6 Personal-Vertraulichkeit (Art. 28(3)(b) i. V. m. Art. 29 DSGVO)

Inhaber Oleksandr Chornous als einzige verarbeitende Person verpflichtet sich gem. Art. 28(3)(b) DSGVO i. V. m. Art. 29 DSGVO auf die Vertraulichkeit der personenbezogenen Daten. Bei zukünftiger Einstellung von Mitarbeitern wird vor Zugriff eine schriftliche Vertraulichkeitsvereinbarung unterzeichnet.

• Diese Selbstverpflichtung ist datiert auf das Versionsdatum dieser TOM-Anlage und wird beim ersten zukünftigen Mitarbeiterzugang um eine schriftliche Vertraulichkeitsvereinbarung (Muster: berufliche Schweigepflicht + DSGVO-Schulungsnachweis) ergänzt.
• Bis dahin: keine Weitergabe von Zugangsdaten an Dritte; kein gemeinsam genutzter Admin-Account; alle Cloud-Provider-Konten 2FA-geschützt.
• Externe Dienstleister (Steuerberater, Rechtsbeistand) erhalten ausschließlich anonymisierte oder pseudonymisierte Auszüge auf Need-to-know-Basis und unter separater NDA.

3. Integrität (Art. 32(1)(b))

3.1 Übertragungskontrolle

• HMAC-timingSafeEqual für Resend-Webhooks + 5 min Replay-Schutz + fail-closed
• HTML-Escape in allen E-Mail-Templates
• CRLF-Strip in SMTP-Headern (Header-Injection-Schutz)
• XFF-Parsing: nur erste IP (proxy-spoof-resistent)
• SSRF-Schutz bei Puppeteer-Card-Export
• CSP connect-src 'self' blockiert sämtliche Drittquellen

3.2 Incident-Response Timeline (Art. 33 DSGVO)

Vorlagen und Referenzdokumente:

• Ausfüllvorlage für Meldung: docs/legal/Datenpannenmeldung-Template-DE.md (alle Pflichtangaben aus Art. 33(3) DSGVO + LDI-NRW-spezifische Felder)
• Internes Vorfall-Register: incident_register Collection (MongoDB) — Retention 5 Jahre gem. Art. 33(5) DSGVO
• Wiederherstellungs-Verfahren: docs/legal/BCP-DRP-DE.md §3
• Watchdog-Cron-Quelle: src/app/api/cron/incident-watchdog/route.ts (Schedule 0 */4 * * * UTC — alle 4 h; Schwellen 12 h Warnung / 48 h URGENT LDI, 4 h Prozessor-Leg)

4. Verfügbarkeit (Art. 32(1)(b))

4.1 Verfügbarkeitskontrolle

• Railway-Hosting EU (Amsterdam) mit automatischem Restart
• MongoDB Atlas Snapshots: Tier-abhängig. Atlas-Tiers M0/M2/M5 bieten

ausschließlich manuell ausgelöste On-Demand-Snapshots; Tier M10+ liefert kontinuierliche Cluster-Backups mit Point-in-Time-Recovery.

• Aktueller Tier wird im /superadmin/settings Storage-Banner angezeigt;

Beta-Phase: M0 (512 MB Hard-Limit, manuelle Snapshots).

• Tier-Upgrade auf M10+ vor kommerziellem Start geplant — verifiziert durch

Restore-Drill protokolliert in docs/legal/BCP-DRP-DE.md §3.

• Bis Upgrade: RPO 24h (manueller Snapshot), RTO 24h.

4.2 Wiederherstellbarkeit

• BCP/DRP siehe BCP-DRP-DE.md
• RTO 4h (Anwendung), 24h (DB-Restore)
• Restore-Tests quartalsweise ab Tier M10 (Upgrade vor kommerziellem Start geplant); derzeit (Tier M0, keine kontinuierlichen Backups) entfallen — Übergangsmaßnahme: Stichproben-Prüfung der JSON-Exporte
• Atlas Restore mit dokumentierter Begründung + Audit-Log

5. Belastbarkeit (Art. 32(1)(b))

5.1 Skalierungs- und Rate-Limit-Maßnahmen

• Stateless-Anwendung: Skalierung über Railway-Service-Replicas
• Rate-Limits:
• Login: 5 / 15 min pro E-Mail + 30 / 15 min pro IP (zwei Buckets: das Adress-Limit verhindert Credential-Stuffing gegen ein Konto, das IP-Limit die laute Quelle; ein erfolgreicher Login setzt das Adress-Limit zurück)
• Register: 5/h pro IP + 3/24h pro E-Mail
• Password-Reset: 3/15min pro E-Mail
• Card-Activation: 5/h + 20/Tag pro IP
• Marketing-Confirm: 3/Stunde pro E-Mail
• Upload: 20/Min pro Nutzer

5.2 Patch-Management

Schwachstellen in Third-Party-Abhängigkeiten werden über einen mehrstufigen Prozess erkannt und behoben:

• Dependabot — wöchentlich: Konfiguration in .github/dependabot.yml (zur Einführung vorgesehen; Status laufend zu pflegen). Wöchentliche Auto-PRs für npm-Direct- und Transitive-Dependencies, GitHub-Actions-Versionen und Docker-Base-Images. PRs durchlaufen den vollen CI-Lauf (tsc, Vitest, Build) vor Merge.
• `npm audit` — monatlich: Manueller Lauf durch den Inhaber; Funde mit Severity ≥ HIGH werden im selben Monat behoben oder mit dokumentierter Risiko-Akzeptanz (kein Exploit-Pfad in Boncard-Code) in docs/known-issues.md festgehalten.
• Critical-CVE-Reaktion ≤ 72 Stunden: Bei einer CVE mit CVSS ≥ 9.0 in einer aktiv genutzten Dependency erfolgt Patch-Deployment innerhalb von 72 Stunden nach öffentlicher Bekanntgabe. Bis zum Patch werden — falls möglich — kompensierende Maßnahmen (Feature-Flag-Abschaltung, WAF-Regel, IP-Block, temporärer Rate-Limit) angewandt und im Audit-Log dokumentiert.

6. Wirksamkeit & Überprüfung (Art. 32(1)(d))

• Quartalsweise Selbst-Audit der TOM gegen aktuellen Code-Stand
• Halbjährliche Schwellenwertanalyse DSB (DPO-Schwellenwertanalyse-DE.md)
• Tabletop-Übung Disaster Recovery alle 6 Monate
• LEGAL_NOTICE-E-Mail-Zustellungsnachweise (BGH 06.10.2022 / BGB §130) — 3 Jahre

7. Pseudonymisierung & Verschlüsselung (Art. 32(1)(a))

7.1 Verschlüsselung in Transit

• TLS 1.2+ auf allen öffentlichen Endpunkten

7.2 Verschlüsselung in Ruhe

• MongoDB Atlas Encryption-at-Rest (AES-256, anbieter-managed)

7.3 Pseudonymisierung

• anonymizeCustomer ersetzt alle PII-Felder; customerId bleibt als technischer Schlüssel (EuGH C-604/22)

7.4 Pseudonymisierung — Schlüsseltrennung (EDPB Guidelines 01/2025)

Pseudonymisierung im Sinne von Art. 4(5) DSGVO setzt nach den EDPB Guidelines 01/2025 on Pseudonymisation voraus, dass der „lookup key" (die Zuordnungstabelle zwischen Pseudonym und Klartext-Identität) separat und mit gesondertem Zugriffsschutz verwahrt wird. Boncard implementiert diese Schlüsseltrennung wie folgt:

• Aufbewahrungsort des Schlüssels: Der customerId (ULID-basiertes pseudonymes Identifikatorfeld) wird im selben Datenbank-Cluster wie der Klartext gehalten, ist aber durch die Mandantentrennung (Tenant-DB-Routing in src/lib/db/tenant-store.ts) und durch die RBAC-Sicherung (siehe §2.2) gegen direkten Zugriff abgeschirmt. Anonymisierte Klartext-Felder werden via anonymizeCustomer gelöscht, nicht maskiert — nach Pseudonymisierung existiert die Zuordnungstabelle nicht mehr.
• Wer kann re-identifizieren?
• Vor Anonymisierung: OWNER des betreffenden Tenants (über die /admin/cards/[id]-Detailansicht) und SUPERADMIN (über /superadmin/search); beide Zugriffe lösen einen data_access_log-Eintrag (Art. 5(2) DSGVO Rechenschaft, 90 Tage Retention) aus.
• Nach Anonymisierung: niemand, weil sämtliche identifizierenden Felder (Name, E-Mail, Telefon, Geburtsdatum, IP, User-Agent, unsubscribeToken) entfernt sind. Der verbleibende customerId ist ein reines Zähl-Pseudonym ohne Rückbezug zu einer natürlichen Person.
• Bedrohungsmodell — Datenleck ohne Mandantenkontext: Die Architektur ist eine gemeinsame Plattform-Datenbank mit logischer Mandantentrennung in der Abfrageschicht (barbershopId in jeder Query, erzwungen in src/lib/db/repositories/*) — nicht eine Datenbank je Mandant. Ein Datenbank-Leck legt daher Datensätze mehrerer Mandanten zugleich offen; die frühere Formulierung stützte sich auf ein Feld (Barbershop.mongoUri), das es nicht mehr gibt. Schutzwirkung entsteht hier durch Verschlüsselung at rest und Zugriffskontrolle, nicht durch Mandantenschlüssel.
• Backup-Spezifikum: Atlas-Snapshots (≤ 35 Tage Backup-Window; erst ab Tier M10 — derzeit Tier M0 ohne kontinuierliche Snapshots, vgl. §4.1) enthalten — bis sie ablaufen — die jeweils zu diesem Zeitpunkt gültige Klartext-Schicht. Restore aus Backups ist nur in Ausnahmefällen (Aufsichts-Anordnung, gerichtliche Aufforderung) und nur mit dokumentierter Begründung (TENANT_RESTORE_INITIATED, ≥ 10 Zeichen) zulässig; vgl. §9 und Loeschkonzept-DE.md §8.

7.5 Hashing

• SHA-256 für PasswordResetToken-IDs
• SHA-256 für customerIdHash in Archive-Consent-Logs
• bcrypt Cost ≥ 12 für Passwörter

8. Datenschutz durch Technikgestaltung & Voreinstellungen (Art. 25)

• Endkunden-Foto-Avatare: nicht gespeichert (Datenminimierung, entfernt 2026-05-14)
• Marketing-Einwilligungen: Double-Opt-in standardmäßig erforderlich
• Pflichtfelder minimiert (nur Vorname + GDPR-Einwilligung obligatorisch)
• Auto-Anonymisierung nach 24-60 Monaten Inaktivität (per-Tenant konfigurierbar)

9. Löschpflichten (BGH 11.11.2025)

• Nach Vertragsende oder Aufforderung des Verantwortlichen: vollständige Löschung aller personenbezogenen Daten innerhalb von 30 Tagen
• Löschbestätigung wird per LEGAL_NOTICE-E-Mail an den Verantwortlichen versandt (Art. 28(3)(g) DSGVO)
• Löschprotokoll wird 3 Jahre archiviert; auf Anfrage als PDF exportierbar (/superadmin/compliance/archives/loeschprotokoll)
• Atlas-Backup-Window (~35 Tage; gilt erst ab Tier M10 — derzeit Tier M0 ohne kontinuierliche Backups, vgl. §4.1) bleibt technisch zugänglich, wird aber nur in Ausnahmefällen (Aufsichts-Anordnung, gerichtliche Aufforderung) und mit dokumentierter Begründung wiederhergestellt

10. Aufzeichnungs- und Beweispflichten

• ROPA (ROPA.md) — Art. 30(1) Verzeichnis aller Verarbeitungstätigkeiten
• DPIA-Schwellenwertanalyse (DPIA-loyalty-processing.md) — Art. 35
• Löschkonzept (Loeschkonzept-DE.md) — Art. 5(1)(e)
• Aufbewahrungsmatrix (Aufbewahrungsmatrix.md) — Art. 5(1)(e)
• Vorfall-Register (incident_register Collection) — Art. 33(5), 5 Jahre
• Datenpannenmeldungs-Vorlage (Datenpannenmeldung-Template-DE.md) — Art. 33(3)
• BCP / DRP (BCP-DRP-DE.md) — Art. 32(1)(b) und (c)
• PII-Zugriffs-Log (data_access_log) — Art. 32 Rechenschaft, 90 Tage

11. NIS2- und DORA-Statement

NIS2 (Richtlinie (EU) 2022/2555): Boncard fällt nicht unter NIS2. Begründung:

• Schwellenwert nach Art. 2 NIS2 i. V. m. KMU-Definition (Empfehlung 2003/361/EG): Boncard hat in der Beta-Phase < 50 Mitarbeitende (faktisch: 1 — Einzelunternehmer) und einen Jahresumsatz < 10 Mio. € (faktisch: 0 €, kein Gewerbe). Die kumulativen KMU-Schwellen sind unterschritten, sodass selbst eine Einordnung als „important entity" gem. Anhang II NIS2 ausgeschlossen ist.
• Sektor-Zugehörigkeit: Boncard betreibt eine Loyalty-Card-SaaS-Plattform. Dieser Anwendungsbereich ist weder in Anhang I (essentielle Sektoren: Energie, Verkehr, Banken, Finanzmarktinfrastruktur, Gesundheit, Trinkwasser, Abwasser, Digitale Infrastruktur i. e. S., ICT-Service-Management B2B, öffentliche Verwaltung, Weltraum) noch in Anhang II (important sectors: Post, Abfallwirtschaft, Chemikalien, Lebensmittel, Hersteller bestimmter Produkte, digitale Anbieter wie Online-Marktplätze / Suchmaschinen / Social-Networking-Plattformen, Forschung) gelistet. Eine Loyalty-Card-Plattform fällt insbesondere nicht unter „Online-Marktplatz" (kein Vertragsschluss zwischen Dritten auf Boncard) und nicht unter „Cloud-Computing-Dienst" im Sinne der NIS2 (keine generische Infrastruktur, sondern fachspezifische Loyalty-Anwendung).
• Eine erneute Schwellenwertprüfung erfolgt verpflichtend bei: (a) Überschreiten von 50 Mitarbeitenden, (b) Überschreiten von 10 Mio. € Jahresumsatz, (c) Sektor-Wechsel oder substantieller Funktions­erweiterung.

DORA (Verordnung (EU) 2022/2554 — Digital Operational Resilience Act): Boncard fällt nicht unter DORA, mangels Status als Finanzdienstleister im Sinne von Art. 2 DORA. Boncard ist weder Kreditinstitut, Zahlungsdienstleister, E-Geld-Institut, Investmentfirma, Versicherer noch sonstige in Art. 2(1)(a)–(t) DORA aufgeführte Entität und fungiert auch nicht als „critical ICT third-party service provider" gem. Art. 31 DORA, da keine Finanzdienstleister auf Boncard als Kerninfrastruktur angewiesen sind.

Sollte Boncard zukünftig Zahlungsfunktionen integrieren (z. B. Stripe-Subscription-Billing nach Gewerbeanmeldung), ist eine erneute DORA-Subsumtion vorzunehmen; die wahrscheinliche Einordnung wäre dann jedoch erneut „kein Adressat", weil Stripe selbst der DORA-pflichtige Zahlungsdienstleister wäre und Boncard reiner Stripe-Customer bliebe.

12. Aktualisierungs-Historie

2.5 — 2026-08-01

• §2.5: Cloudflare-R2-Speicherort auf den jurisdiktionalen EU-Bucket (R2_JURISDICTION=eu) korrigiert — die Zeile sagte „USA / EU edge", während /avv §5 auf derselben Website EU nennt.
• §2.5: TIA-Register um TIA-005 (Google LLC / Google Wallet API) ergänzt; die Aufzählung endete bei TIA-004, obwohl Google seit 2026-08-01 als Subprozessor #5 geführt wird.
• Kopfzeile und Historie wieder in Deckung gebracht: der Kopf wies bereits Version 2.5 aus, während der jüngste Eintrag hier 2.4 lautete.

2.4 — 2026-08-01

• §2.5: Google LLC (Google Wallet API) als Subprozessor #5 ergänzt. Seit 2026-07-20 produktiv, war aber weder in dieser Anlage noch im AVV, ROPA oder TIA-Register geführt. Substanzielle Änderung der Subprozessor-Liste → Art. 28(2) Vorab-Notification (30 Tage) erforderlich.
• §2.5: Cloudflare-R2-Zeile korrigiert — der Bucket enthält nicht nur Logos, sondern die verschlüsselten täglichen Voll-Backups der Datenbank (14 Tage rollierend) und damit sämtliche Endkunden-Daten.
• Regionen am laufenden System verifiziert und korrigiert: Railway Amsterdam, MongoDB Atlas Frankfurt am Main — keine Drittlandsübermittlung für diese beiden Dienste.
• §7.4: Bedrohungsmodell auf die tatsächliche Architektur umgeschrieben (eine geteilte Plattform-Datenbank mit logischer Mandantentrennung); Verweis auf das gelöschte Feld Barbershop.mongoUri entfernt.

• 2026-06-12: Version 2.3
• §2.5: Drittlandbasis Railway Corp. korrigiert — Railway ist nicht DPF-zertifiziert; Transfergrundlage ausschließlich Art. 46 DSGVO i. V. m. EU-SCC 2021/914 (DPA des Anbieters), TIA-001 verpflichtend. Quelle der Wahrheit: src/lib/legal/subprocessors.ts.
• §2.5: Cloudflare-R2-Standort korrigiert — „Speicherregion EU (Frankfurt/Amsterdam) vertraglich konfiguriert" entfernt (nicht zutreffend); tatsächlich: „USA / EU edge (globales Cloudflare-Netz)"; DPF-Zertifizierung bleibt.
• §2.5 neu: TIA-Register-Verweis — TIA-001 (Railway), TIA-002 (MongoDB Atlas), TIA-003 (Resend), TIA-004 (Cloudflare R2) werden in docs/legal/TIA-Annex-DE.md geführt.
• §1 / §2.3 / §2.5: AVV-Querverweise für Subunternehmer präzisiert — in der Online-AVV (/avv) ist die Subunternehmer-Klausel §5, in der Offline-Vorlage AVV-template-DE.md §6; bisherige pauschale „AVV §6"-Verweise entsprechend aufgelöst.
• §4.2: Restore-Tests — Quartals-Rhythmus gilt ab Tier M10 (vor kommerziellem Start); derzeit (M0, keine kontinuierlichen Backups) entfallen, Stichproben-Prüfung der JSON-Exporte als Übergangsmaßnahme.
• §7.4 / §9: Atlas-35-Tage-Backup-Window mit M0-Vorbehalt versehen (kontinuierliche Snapshots erst ab Tier M10); Aussagen zur wirksamen Anonymisierung in §7.4 unverändert beibehalten (nach anonymizeCustomer keine Re-Identifikation möglich, vgl. EuGH C-413/23 P).
• §12 (v2.2-Eintrag): Sammelaussage „alle US, DPF-zertifiziert" als unzutreffend markiert *[korrigiert 2026-06-12]* — Korrektur ohne stillschweigende Umschreibung der Historie.
• 2026-05-27: Version 2.2
• Sentry entfernt (nicht mehr genutzt); Subprozessoren 5 → 4.
• §2.5: Subprozessor-Zeile #4 (Functional Software, Inc. / Sentry) entfernt; Cloudflare R2 auf #4 umnummeriert. Verbleibende Subprozessoren: Railway, MongoDB Atlas, Resend, Cloudflare R2 (alle US, DPF-zertifiziert). *[korrigiert 2026-06-12: Die Sammelaussage „alle US, DPF-zertifiziert" war unzutreffend — Railway Corp. ist nicht DPF-zertifiziert; Transfergrundlage dort ausschließlich Art. 46 DSGVO i. V. m. EU-SCC 2021/914. Siehe Version 2.3.]*
• §3.1: CSP-Maßnahme von „blockiert Drittquellen außer *.ingest.sentry.io" auf „connect-src 'self' blockiert sämtliche Drittquellen" aktualisiert.
• §5.2: Bullet „Sentry-driven Incident Detection" entfernt (Sentry-Alerting nicht mehr vorhanden).
• §6: Sentry-PII-Redaktions-Block (sendDefaultPii: false + src/lib/sentry-redact.ts-Hook) vollständig entfernt; LEGAL_NOTICE-Zustellnachweis-Bullet bleibt.
• 2026-05-26: Version 2.1
• §1: SDM-Zitierung auf DSK SDM 3.1a aktualisiert (aktuelle redaktionelle Fassung)
• §1 Intervenierbarkeit-Zeile: „Self-Erasure" entfernt; ersetzt durch Owner-vermittelte Anonymisierung via `/admin/customers/[id]` (Art. 17/18/19/20/21) — spiegelt Entfernung der Self-Service-Routen am 2026-05-26 wider
• §6 Sentry-Redact-Liste: Tote Routen /my-data/<token>, /self-export/<token>, /self-delete/<token> entfernt; PII-tragende Admin-Pfade (/admin/customers/[id], /admin/cards/[id], /api/admin/export, /api/upload) als generisch maskiert in src/lib/sentry-redact.ts:42 referenziert
• 2026-05-26: Version 2.0
• §2.2: STAFF-Rolle entfernt (RBAC nur noch SUPERADMIN | OWNER seit 2026-05-18)
• §1: explizites Mapping der TOM-Abschnitte auf die sieben DSK-SDM-3.1-Gewährleistungsziele (V/I/C, Datenminimierung, Transparenz, Intervenierbarkeit, Unverkettbarkeit)
• §2.5: Subprozessor-Liste auf alle vier (bzw. fünf inkl. Sentry-EU-Vertretung) Anbieter ausgedehnt, Due-Diligence-Methodik pro Subprozessor
• §2.6 neu: Personal-Vertraulichkeit gem. Art. 28(3)(b) i. V. m. Art. 29 DSGVO
• §3.2 neu: Incident-Response Timeline mit 4h-Prozessor-Leg + 12h/48h-Watchdog-Eskalation und 72h Art.33-Frist, Querverweis auf Datenpannenmeldung-Template-DE.md und cron-incident-watchdog
• §5.2 neu: Patch-Management (Dependabot wöchentlich, npm audit monatlich, Sentry-driven Detection, Critical-CVE ≤ 72h)
• §6: Sentry-PII-Redaktion präzisiert — sendDefaultPii: false plus beforeSend/beforeBreadcrumb-Hook in src/lib/sentry-redact.ts (Felder konkret aufgezählt)
• §7 in Unterabschnitte 7.1–7.5 strukturiert; §7.4 neu: Schlüsseltrennung gem. EDPB Guidelines 01/2025 (Speicherort, Re-Identifikationsberechtigte, Bedrohungsmodell)
• §10: Querverweise auf Datenpannenmeldung-Template-DE.md und BCP-DRP-DE.md ergänzt
• §11 neu: NIS2- und DORA-Statement (kein Adressat — KMU-Schwelle <50 MA und <10 Mio. €, kein Anhang-I/II-Sektor, kein Finanzdienstleister-Status)
• 2026-05-15: Version 1.0 — Auskopplung aus AVV §5 als eigenständige Anlage 2

*Wirksam: bei Annahme der AVV durch den Verantwortlichen · Letzte Überprüfung: 2026-06-12*

Diese Anlage ist verbindlicher Bestandteil des Auftragsverarbeitungsvertrags. Sie liegt nur auf Deutsch vor, da sie der deutschen Vertragsfassung folgt.