# Lieferantenpaket der Plattform (DORA Art. 28–30)

Stand 2026-10-07 · Rolle: IKT-Drittdienstleister — Cloud: SaaS (ITS-Typ S19)

Compliance-/GRC-Plattform: Common Controls, Nachweise, Register, Freigaben, Prüfungspakete für ISO 27001, DORA, NIS2, MaRisk, MiCAR, GwG.

## Registerdatenblatt (ITS (EU) 2024/2956)

| Feld | Wert |
|---|---|
| B_05.01 c0050 Rechtlicher Name | siehe Impressum |
| B_05.01 c0010/c0020 Kennung | LEI auf Anfrage; Handelsregister siehe Impressum |
| B_05.01 c0070 Art der Person | juristische Person |
| B_05.01 c0080 Land des Hauptsitzes | DE |
| B_02.02 c0060 Art der IKT-Dienstleistung | S19 Cloud: SaaS |
| B_02.02 c0120 Anwendbares Recht | DE |
| B_02.02 c0130 Land der Leistungserbringung | DE |
| B_02.02 c0140 Datenspeicherung | Ja |
| B_02.02 c0150/c0160 Standort Speicherung/Verarbeitung | DE |
| B_02.02 c0170 Sensibilität der Daten | mittel/hoch (Compliance-Daten, personenbezogene Daten von Mitarbeitenden) |
| B_07.01 c0050 Substituierbarkeit | leicht — vollständiger Export in offenen Formaten (CSV, Markdown, ZIP) jederzeit |
| B_07.01 c0080 Ausstiegsplan | Ja — Export, Übergangsfrist, Löschbestätigung (siehe Exit) |

## Zusagen nach Art. 30

| Art. | Inhalt | Zusage |
|---|---|---|
| 30(2)(a) | **Leistungsbeschreibung** — Klare und vollständige Beschreibung aller Funktionen und IKT-Dienstleistungen; Angabe, ob Unterauftragsvergabe für kritische oder wichtige Funktionen zulässig ist und unter welchen Bedingungen. | Leistungsbeschreibung oben; Unterauftrag nur an die genannten Subunternehmer, Änderungen mit mindestens 30 Tagen Vorabmitteilung. |
| 30(2)(b) | **Standorte** — Standorte (Regionen oder Länder) der Leistungserbringung und der Datenverarbeitung inkl. Speicherort; Pflicht zur vorherigen Mitteilung bei Änderung. | Leistungserbringung und Datenverarbeitung ausschließlich in Deutschland; Standortwechsel nur nach vorheriger Mitteilung. |
| 30(2)(c) | **Schutz der Daten** — Verfügbarkeit, Authentizität, Integrität und Vertraulichkeit der Daten, einschließlich personenbezogener Daten. | Verschlüsselung je Mandant (XChaCha20-Poly1305, eigener Schlüssel), Mandantentrennung in der Datenbank (Row-Level-Security mit FORCE), MFA für alle Rollen, append-only Audit-Log mit Hash-Kette. |
| 30(2)(d) | **Datenzugang bei Beendigung** — Zugang, Wiederherstellung und Rückgabe der Daten in leicht zugänglichem Format bei Insolvenz, Abwicklung, Geschäftseinstellung oder Vertragsende. | Export aller Daten jederzeit durch den Kunden selbst (ZIP mit SHA-256-Manifest); bei Vertragsende Export, Übergangsfrist und Löschbestätigung. |
| 30(2)(e) | **Leistungsziele** — Leistungsbeschreibungen mit quantitativen und qualitativen Zielen (SLA), die eine wirksame Überwachung und Gegenmaßnahmen erlauben. | Verfügbarkeitsziel und Reaktionszeiten im SLA-Anhang; Health-/Ready-Endpunkte für die Überwachung durch den Kunden. |
| 30(2)(f) | **Unterstützung bei Vorfällen** — Unterstützung bei IKT-Vorfällen im Zusammenhang mit der Dienstleistung ohne Zusatzkosten oder zu vorab festgelegten Kosten. | Unterstützung bei IKT-Vorfällen ohne Zusatzkosten; Kontaktstelle laut security.txt. |
| 30(2)(g) | **Zusammenarbeit mit Behörden** — Uneingeschränkte Zusammenarbeit mit den zuständigen Behörden und Abwicklungsbehörden des Finanzunternehmens. | Zusammenarbeit mit BaFin, Bundesbank, BSI und Abwicklungsbehörden; Auskünfte innerhalb der gesetzten Frist. |
| 30(2)(h) | **Kündigung** — Kündigungsrechte und Mindestkündigungsfristen entsprechend den Erwartungen der Aufsicht. | Kündigung mit angemessener Mindestfrist laut Vertrag; außerordentliche Kündigungsrechte nach Art. 28(7) ausdrücklich eingeräumt. |
| 30(2)(i) | **Schulung** — Teilnahme an Schulungs- und Sensibilisierungsprogrammen des Finanzunternehmens zur digitalen operationalen Resilienz (Art. 13 Abs. 6). | Teilnahme an Sensibilisierungsmaßnahmen des Kunden auf Anfrage. |
| 30(3)(a) (kritisch) | **Vollständige SLA** — Vollständige Leistungsbeschreibung mit präzisen quantitativen und qualitativen Zielen, Aktualisierungsmechanismen und Überwachungsmöglichkeit. | Vollständige SLA mit quantitativen Zielen (Verfügbarkeit, RTO/RPO, Reaktionszeiten) und jährlicher Überprüfung. |
| 30(3)(b) (kritisch) | **Kündigungsfristen und Berichtspflichten** — Kündigungsfristen und Berichtspflichten des Dienstleisters, insbesondere Mitteilung über Entwicklungen, die seine Leistungsfähigkeit wesentlich beeinträchtigen könnten. | Unverzügliche Mitteilung wesentlicher Entwicklungen (Eigentümer-, Standort-, Subunternehmerwechsel, Sicherheitsvorfälle). |
| 30(3)(c) (kritisch) | **Notfallpläne und Sicherheit** — Umsetzung und Test von Notfallplänen; IKT-Sicherheitsmaßnahmen, Werkzeuge und Richtlinien, die ein angemessenes Schutzniveau sicherstellen. | Tägliche verschlüsselte Backups mit Offsite-Kopie, Restore-Test als wiederkehrender Pflicht-Lauf, Notfall- und Wiederanlaufplan nach Testprogramm. |
| 30(3)(d) (kritisch) | **Mitwirkung an TLPT** — Teilnahme und uneingeschränkte Zusammenarbeit bei bedrohungsorientierten Penetrationstests (TLPT) des Finanzunternehmens. | Mitwirkung an TLPT des Kunden nach Abstimmung von Umfang und Zeitfenster. |
| 30(3)(e) (kritisch) | **Zugangs-, Inspektions- und Auditrechte** — Uneingeschränkte Zugangs-, Inspektions- und Auditrechte für das Finanzunternehmen, seine Prüfer und die Behörden; Mitwirkungspflichten; Festlegung von Häufigkeit und Umfang. | Zugangs-, Inspektions- und Auditrechte für Kunde, Prüfer und Behörden; Prüfungspaket mit Manifest auf Anfrage, Vor-Ort-Prüfung nach Terminabstimmung; /baseline als laufender Nachweis. |
| 30(3)(f) (kritisch) | **Ausstiegsstrategie** — Ausstiegsstrategien mit angemessener Übergangsfrist, in der die Leistung weiter erbracht wird, und Unterstützung bei Migration zu einem anderen Anbieter oder bei Rückführung. | Ausstiegsstrategie: Weiterbetrieb während einer Übergangsfrist von mindestens sechs Monaten, Migrationsunterstützung, vollständiger Export, Löschbestätigung. |

## Subunternehmer (B_05.02, Rang 2)

| Name | Land | Leistung | Zweck | personenbezogene Daten |
|---|---|---|---|---|
| Hetzner Online GmbH | DE | S07 Hosting, Objektspeicher | Produktion, Datenbank, verschlüsselte Nachweise und Backups | ja |
| Brevo (Sendinblue SAS) | FR | S19 SaaS — transaktionale E-Mail | Anmelde-Links, Benachrichtigungen (E-Mail-Adresse, Name) | ja |
| GitHub, Inc. | US | S19 SaaS — Quellcode, CI/CD | Entwicklung und Build; kein Zugriff auf Kundendaten | nein |

## Vorfallmeldung an Kunden

Meldung an die benannte Kontaktstelle des Kunden spätestens 24 Stunden nach Kenntnis eines Vorfalls mit Auswirkung auf dessen Daten oder Dienste — mit Zeitpunkt, Umfang, betroffenen Diensten und Sofortmaßnahmen; Zwischen- und Abschlussbericht folgen. Der Kunde kann die Angaben in seine eigene DORA-Erstmeldung übernehmen.

## Exit

- Vollständiger Export jederzeit durch den Kunden selbst — ZIP mit SHA-256-Manifest, offene Formate (CSV, Markdown), Nachweise im Original.
- Übergangsfrist von mindestens sechs Monaten mit Weiterbetrieb nach Kündigung.
- Löschung durch Vernichtung des Mandantenschlüssels (Crypto-Shredding) und Löschung der Objekte; schriftliche Löschbestätigung mit Datum.

## Auftragsverarbeitung

Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ist Vertragsbestandteil; technische und organisatorische Maßnahmen entsprechen dem Stand auf /baseline; Subunternehmer wie oben, Änderungen mit Widerspruchsrecht.

## Technische und organisatorische Maßnahmen (Auszug aus /baseline)

### Identität & Zugang

- MFA-Pflicht für alle Rollen (TOTP, Passkeys/FIDO2), Enrolment beim ersten Login erzwungen
- Sitzungsregeln: Idle 30 min, absolut 12 h, Step-up ≤ 10 min für sensible Aktionen
- Rollenmodell owner/editor/consultant/viewer/auditor; Prüfer- und Berater-Zugänge laufen über accessUntil ab
- Plattform-Admin mit IP-Allowlist, jeder Plattform-Zugriff mit Begründung im Audit-Log
- Mandantentrennung in Postgres (RLS + FORCE auf jeder Org-Tabelle), App-Rolle ohne BYPASSRLS

### Kryptografie

- Per-Org-DEK, mit KEK umschlossen (Envelope, XChaCha20-Poly1305), Schlüsselversion ab Tag 1
- Feldverschlüsselung sensibler Spalten mit dem Org-Schlüssel
- TLS 1.2/1.3 mit HSTS-Preload, OCSP-Stapling (nginx)

### Betrieb, Protokollierung, Überwachung

- Append-only Audit-Log mit SHA-256-Hash-Kette je Org, tägliche Kettenprüfung mit Alarm
- Strukturiertes Logging (pino) mit Redaction von Tokens, URLs, PII; Fehler-Tracking nach GlitchTip gescrubbt (ohne SDK)
- KEK-Rotation ohne Re-Encrypt (pnpm kek:rotate), Rate-Limit je Organisation, optionaler clamd-Scan fail closed
- systemd-Sandbox (ProtectSystem=strict, NoNewPrivileges, SystemCallFilter), Secrets über LoadCredentialEncrypted
- Health-/Ready-Endpunkte, chrony, unattended-upgrades

### Entwicklung & Lieferkette

- CI mit Typecheck, Biome, Vitest, RLS-Integrationstests, pnpm audit, OSV, gitleaks, CodeQL, CycloneDX-SBOM
- pnpm minimumReleaseAge 7 Tage, Lifecycle-Skripte blockiert, Lockfile, Dependabot
- Threat Model (STRIDE light), SECURITY.md, security.txt
- Getrennte Datenbanken für Entwicklung, Test und Produktion

### Netz

- nftables: nur 22/80/443; nginx Rate-Limit-Zonen (/api/auth 10 r/min je IP)
- Postgres nur über localhost
- Vollständiger Security-Header-Satz (CSP, HSTS, COOP/CORP, Permissions-Policy, X-Frame-Options)

### Kontinuität

- Tägliche pg_dump-Backups, age-verschlüsselt, Offsite via rclone, 30 Tage
- Restore-Skript vorhanden

### Governance & Dokumentation

- Architektur-Entscheidungen als ADRs, Threat Model, Deploy-Runbook
- Kommunikationskanal für Sicherheitsmeldungen (security.txt, SECURITY.md)

### Dienstleister

- Hetzner (Hosting), Brevo/Resend (Mail), GitHub (Code) als Seed im Register
- Lieferantenpaket der Plattform mit Art.-30-Zusagen, Registerdatenblatt und Subunternehmern unter /vertrauen

_Öffentliche Zusammenfassung; verbindlich sind Vertrag, SLA-Anhang und AVV. Kein Rechtsrat._