Zwischen DSGVO und Geopolitik: die richtige Cloud für Ihre bAV‑Verwaltung

Zielgruppe: HR- und IT-Entscheider · Tiefe: fachlich vertieft · Lesezeit: ca. 12-15 Minuten

• EU-Hosting reduziert Rechts-/Governance-Risiken in der bAV.
• US-Cloud in der EU ist machbar, braucht HYOK/External KMS, DPF/SCC, TIA und getesteten Exit.
• bixie: spezialisierte bAV-SaaS, Hosting in Deutschland, auditierbar.

Die Verwaltung der betrieblichen Altersversorgung (bAV) berührt die sensibelsten Beschäftigtendaten eines Unternehmens. Entscheidend sind deshalb Rechtsraum, Auditierbarkeit und Betriebsratsfähigkeit – nicht die Zahl exotischer IT-Features. Im Markt stehen zwei unterschiedliche Ansätze zur Verfügung:

• (A) Cloud-Systeme deutscher/europäischer Anbieter mit Hosting in Deutschland
• (B) US-Cloud-Systeme, die in der EU hosten.

Beide sind nutzbar, unterscheiden sich aber beim strukturellen Risiko (Extraterritorialität, politische Volatilität, Transferregime) und beim operativen Aufwand (Nachweise, Mitbestimmung, laufende Governance).

Zusammenfassung
Die Entscheidung für eine bAV-Cloud ist vor allem eine Entscheidung für einen Rechtsraum und ein Betriebsmodell. Für Kernprozesse spricht vieles für EU-Anbieter mit Hosting in Deutschland: Es gibt keinen Drittlandtransfer und keine extraterritorialen US-Zugriffsrisiken, Nachweise für Datenschutz und Audits lassen sich schlanker erbringen, und – wo ein Betriebsrat besteht – ist die Mitbestimmung einfacher. US-Clouds mit EU-Hosting sind möglich, erfordern aber dauerhaften Zusatzaufwand: Schlüsselhoheit außerhalb des Providers (HYOK/External KMS), vertragliche Absicherungen (DPF/SCC, Art. 48 DSGVO), Transfer-Impact-Assessments, strenges RBAC/Logging sowie einen geübten Exit-Plan.

Regulatorisch setzt NIS2 höhere Anforderungen an Sicherheit und Lieferketten-Transparenz, der Data Act stärkt Wechselbarkeit (Interoperabilität, Export, sinkende Egress-Hürden), während das künftige EUCS-Label noch in Bewegung ist – verlässlicher bleiben heute ISAE 3402/SOC 1 (Typ II) und ISO 27001. Wirtschaftlich zählt der Gesamtaufwand: EU-Hosting reduziert wiederkehrende Governance-Kosten; Hyperscaler-PaaS wird gezielt für Analytics/BI ergänzt, nicht als Standard für die bAV-Verwaltung.

Empfehlung: bAV-Kernprozesse mit einem spezialisierten, in Deutschland gehosteten SaaS-Kern betreiben; optional punktuell an AWS, Microsoft Azure oder Google Cloud andocken – unter EU-Schlüsselhoheit und mit klarem Exit-Pfad. bixie erfüllt dieses Zielbild: bAV-Spezialisierung (Administration, Aktuariat, HR/Payroll-Schnittstellen, Self-Services), Hosting in Deutschland und Audit-Eignung – damit entsteht eine robuste Architektur für HR und IT, die fachlich überzeugt und regulatorisch trägt.

1) Begriffe und Ausgangslage – in zwei Ebenen

• Ebene A: Anwender-Ebene (SaaS)
  Auf dieser Ebene wird eine spezialisierte Fachanwendung als Dienst genutzt. Die Anwendung läuft im Browser; ein eigener Serverbetrieb ist nicht erforderlich. Updates, Sicherheitspatches und der technische Betrieb liegen beim Anbieter. Für die bAV bedeutet das: Eine Anwendung bildet die Durchführungswege und Zusagetypen ab, führt die versicherungsmathematischen Berechnungen aus, bindet Payroll/HR an und stellt Self-Services bereit. Audit-Nachweise (z. B. ISAE 3402/SOC 1) gehören zum Leistungsumfang. Das Ergebnis sind kurze Einführungszeiten, klare Verantwortlichkeiten und weniger laufender Betriebs- und Compliance-Aufwand. Individualentwicklungen sind möglich, erfolgen jedoch gezielt über standardisierte Schnittstellen (APIs) und Erweiterungen – nicht durch einen kompletten Eigenbetrieb.
  
  
• Ebene B: Plattform-Ebene (PaaS + IaaS)
  Diese Ebene stellt technische Bausteine und Infrastruktur bereit, auf deren Basis Anwendungen gebaut oder erweitert werden. Platform-as-a-Service (PaaS) umfasst etwa Datenbanken, Messaging-Dienste, KI-Module oder Integrationswerkzeuge; Infrastructure-as-a-Service (IaaS) liefert virtuelle Rechner, Speicher und Netzwerke. Diese Ebene ist dann sinnvoll, wenn spezielle Anforderungen über die Standardfunktionen einer bAV-SaaS hinausgehen – beispielsweise für Reporting/Business-Intelligence, die Anbindung an einen konzernweiten Data-Lake oder technische Automatisierungen. Die Plattform-Ebene bietet große Gestaltungsfreiheit und eine breite Tool-Auswahl, erhöht jedoch die Komplexität, den Governance-Aufwand (Rollen, Protokollierung, Datenschutz) und das Risiko eines Anbieter-Lock-ins.

Begriffe im Kontext
„Hyperscaler“ bezeichnet große Public-Cloud-Plattformen mit weltweiter Infrastruktur (z. B. AWS, Microsoft Azure, Google Cloud). Deren sehr umfangreiches PaaS-Angebot wird hier verkürzt als „Hyperscaler-PaaS-Spielwiese“ bezeichnet. Diese Vielfalt ist für Spezialfälle nützlich, führt in bAV-Kernprozessen jedoch oft zu unnötiger Komplexität, ohne einen proportionalen Mehrwert zu liefern.

Grundsatz
bAV-Kernaufgaben sind auf Ebene A (SaaS) am stabilsten aufgehoben. Ebene B (PaaS/IaaS) wird nur dort zugeschaltet, wo ein klarer fachlicher oder technischer Zusatznutzen besteht.

Architektur-Optionen im Rechtsraum

• Option A – EU-Anbieter mit Hosting in Deutschland
  Bei dieser Variante verbleiben die Daten im EU-Rechtsraum. Es findet kein Drittlandtransfer statt, und es greifen keine unmittelbaren Zugriffspflichten aus außereuropäischen Rechtsordnungen. Datenschutz- und Audit-Nachweise lassen sich in der Regel schlanker führen; wo ein Betriebsrat existiert, erleichtert diese Rechtslage die Mitbestimmung.
  
  
• Option B – US-Anbieter mit Hosting in der EU
  Hier liegen die Daten in europäischen Rechenzentren, der Anbieter unterliegt jedoch parallel dem US-Rechtsrahmen mit möglichen Zugriffspflichten. Die Variante ist umsetzbar, erfordert aber dauerhaft zusätzliche Sicherungen: Schlüsselhoheit (z. B. HYOK/External KMS), klare Transfer- und Vertragsmechanismen sowie eine laufende Governance für Dokumentation, Prüfungen und Anpassungen.

Konsequenz
Für bAV-Kernprozesse spricht vieles für eine SaaS-Lösung mit Hosting in Deutschland. Plattform-Dienste aus der Hyperscaler-Welt werden gezielt dort ergänzt, wo sie einen messbaren Mehrwert liefern – nicht als Selbstzweck.

2) Rechtsrahmen: Hosting ist nicht gleich Rechtsraum

• EU-US Data Privacy Framework (DPF)
  Seit 2023 besteht wieder eine tragfähige Grundlage für Datentransfers in die USA. Unternehmen, die dem DPF beigetreten sind, dürfen personenbezogene Daten aus der EU unter klar definierten Auflagen verarbeiten. Aufsichtsbehörden bewerten diesen Rahmen grundsätzlich positiv, behalten aber vor allem mögliche behördliche Zugriffe genau im Blick. Praktisch heißt das: Das DPF ist nutzbar, die Lage bleibt jedoch nicht endgültig stabil – Nachschärfungen sind möglich.
  
  
• US-Zugriffsrechte (FISA § 702, CLOUD Act)
  Unabhängig vom Serverstandort können US-Gesetze eine Rolle spielen, wenn ein Anbieter seinen Sitz in den USA hat. FISA § 702 erlaubt US-Diensten unter strengen Voraussetzungen den Zugriff auf Daten von Nicht-US-Personen im Ausland. Der CLOUD Act kann US-Anbieter verpflichten, rechtmäßigen Herausgabeverlangen nachzukommen – auch dann, wenn die Daten in der EU gespeichert sind und der Zugriff technisch nur über den Anbieter möglich wäre. Das bedeutet nicht, dass Behörden „frei zugreifen“ können; es zeigt aber: Ein rechtlicher Zugriffspfad existiert und muss mit technischen und vertraglichen Schutzmaßnahmen adressiert werden (z. B. Schlüsselhoheit, klare Vertragsklauseln, dokumentierte Prozesse).

EU-Gegengewicht (Art. 48 DSGVO)
Das EU-Recht setzt hier Grenzen: Anordnungen aus Drittstaaten sind innerhalb der EU grundsätzlich nicht direkt vollstreckbar, sofern keine völkerrechtliche Grundlage besteht. Dieser Schutz wirkt jedoch nur, wenn Anbieter und Kunden klare interne Abläufe etabliert haben – etwa zur Prüfung, formalen Zurückweisung und Eskalation externer Ersuchen sowie zur lückenlosen Dokumentation.

Implikation
Beide Varianten – EU-Anbieter mit Hosting in Deutschland und US-Anbieter mit EU-Hosting – sind rechtlich umsetzbar. Der Unterschied liegt im Restrisiko und im Folgeaufwand: Ein EU-Anbieter in Deutschland reduziert das strukturelle Risiko von vornherein (kein Drittlandtransfer, keine extraterritorialen Zugriffspflichten des Providers). Eine US-Cloud in der EU ist möglich, erfordert aber dauerhaft zusätzliche Sicherungen und Governance (Details siehe Abschnitt 6).

3) Regulatorik: was 2025 wirklich zählt (NIS2, Data Act, EUCS)

• NIS2 – der neue Sicherheitsmaßstab
  NIS2 ist die überarbeitete EU-Richtlinie für Cybersicherheit. Sie verpflichtet kritische und wichtige Dienste – dazu zählen in der Regel auch Cloud-Anbieter – zu belastbaren Sicherheitsmaßnahmen, klaren Meldewegen bei Vorfällen und mehr Transparenz in der Lieferkette. Praktisch bedeutet das für bAV-Cloudprojekte: Der Anbieter muss zeigen, wie Angriffe erkannt und gemeldet werden, wie Business-Continuity und Disaster-Recovery funktionieren und welche Unterauftragnehmer beteiligt sind. Für die Nachweisführung werden Protokolle, Prozessbeschreibungen und Zertifikate wichtiger. Je kürzer und EU-interner die Kette der Subdienstleister ist, desto einfacher lässt sich dieser Nachweis in Audits führen.
  
  
• Data Act – Wechselbarkeit statt Lock-in
  Der europäische Data Act schafft einen Rechtsrahmen, der das Wechseln zwischen Cloud-Diensten erleichtert. Im Vordergrund stehen Interoperabilität, klare Exportmöglichkeiten für Daten und technische Unterlagen sowie der schrittweise Abbau von Hürden beim Anbieterwechsel. Für die Praxis heißt das: Exit-Szenarien gehören bereits in den Vertrag – mit benannten Exportformaten, definierten APIs, realistischen Fristen und einem zugesagten Migrations-Support. Wer diese Punkte von Beginn an festschreibt und im Projekt mindestens einmal testet, reduziert das Lock-in-Risiko spürbar und gewinnt Verhandlungssicherheit über die gesamte Laufzeit.
  
  
• EUCS – das geplante EU-Cloud-Label
  Mit dem „EU Cloud Services Scheme“ (EUCS) arbeitet Europa an einem einheitlichen Zertifizierungsrahmen für Cloud-Sicherheit. Ziel ist ein verständliches Label, das Sicherheitsniveau und Prüftiefe transparent macht. Die politische Ausgestaltung – insbesondere Fragen der „digitalen Souveränität“ – befindet sich noch in Bewegung. Daher eignet sich EUCS aktuell eher als Orientierung denn als alleinige Entscheidungsgrundlage. Für bAV-Projekte ist heute belastbarer, auf etablierte Nachweise zu setzen: etwa ISAE 3402/SOC 1 (Typ II) für die Kontrollwirksamkeit über einen Zeitraum, ISO/IEC 27001 für das Informationssicherheits-Management und – wo verfügbar – nationale Kataloge wie BSI C5 für Cloud-Sicherheit.

Konsequenz für die Auswahl
Regulatorik macht die Beschaffung nicht komplizierter, sondern klarer:
Wer auf EU-Hosting und eine EU-interne Lieferkette setzt, vereinfacht NIS2-Nachweise und reduziert Abstimmungs- und Dokumentationsaufwand. Der Data Act stärkt die eigene Verhandlungsposition – vorausgesetzt, Export, Schnittstellen und Migration sind vertraglich präzise geregelt und einmal praktisch erprobt. Ein künftiges EUCS-Label kann die Entscheidung flankieren; bis zur finalen Ausgestaltung bleibt der Fokus auf konkreten Prüfberichten und prüfbaren Prozessen die verlässlichere Basis.

4) Geopolitik: Volatilität als Beschaffungsrisiko

Handelspolitik und Sanktionsregime beeinflussen IT-Abhängigkeiten zunehmend indirekt. Maßnahmenschaukeln (z. B. Zölle, Quoten, Exportkontrollen) stehen zwar nicht im unmittelbaren bAV-Pflichtenheft, erhöhen aber das strategische Risiko bei extraterritorialen Abhängigkeiten. In der Disziplin Kern-HR-Systeme zahlt sich ein stabiler Rechtsraum in Form geringerer Rechts- und Governance-Nebenkosten aus – insbesondere, wenn Mitbestimmung und Jahresabschluss eng getaktet sind.

5) Betriebsrat und Abschlussprüfung: Reibungsverluste minimieren

Mitbestimmung (§ 87 Abs. 1 Nr. 6 BetrVG). Software, die Leistungs-/Verhaltensdaten ermöglicht (oder hierfür genutzt werden kann), ist mitbestimmungspflichtig. bAV-Plattformen fallen praktisch immer darunter (Zugriffs-/Aktivitätslogs, Auswertungen). EU-Hosting und klare Zweckbindung beschleunigen Betriebsvereinbarungen, weil Drittlandthemen und potenzielle Extraterritorialität aus der Diskussion herausfallen.

Auditierbarkeit (SOC 1/ISAE 3402 Typ II). Für ausgelagerte Prozesse mit Relevanz für die Finanzberichterstattung gelten diese Prüfberichte als De-facto-Standard. Typ II bescheinigt die Wirksamkeit von Kontrollen über einen Prüfungszeitraum (nicht nur das Design am Stichtag). Verfügbare Typ-II-Berichte reduzieren Rückfragen und Prüfaufwand im Jahresabschluss signifikant.

Praktischer Effekt. EU-gehostete, prüfbare bAV-Plattformen führen erfahrungsgemäß zu schnelleren BV-Abschlüssen und ruhigeren Abschlussphasen, weil wiederkehrende Transfer- und Zugriffsdebatten entfallen.

6) Risikominderung bei US-Clouds mit EU-Hosting

Wo Hyperscaler wie AWS, Microsoft Azure oder Google Cloud zwingend sind (etwa wegen konzernweiter Data-/AI-Plattformen), lässt sich das Restrisiko mindern, nicht eliminieren. Wirksam wird eine Kombination aus technischen, vertraglichen und organisatorischen Maßnahmen – mit klaren Nachweisen im laufenden Betrieb.

Schlüsselhoheit & Verschlüsselung
Erster Hebel ist die Kontrolle über die Schlüssel. CMEK/BYOK (Customer-Managed/Bring Your Own Key) bedeutet: Verschlüsselungsschlüssel werden kundenseitig verwaltet, befinden sich aber im Key-Management-Dienst des Cloud-Anbieters. Stärker ist HYOK/External KMS: Die Schlüssel liegen außerhalb der Cloud (z. B. in einem EU-HSM); ohne externen Schlüssel ist kein Datenzugriff möglich („no-key-no-access“). Praxisbeispiele sind Microsoft Double Key Encryption, Google Cloud External Key Manager oder AWS KMS External Key Store. HYOK reduziert das technische Risiko deutlich – die rechtliche Pflicht eines US-Anbieters, auf gültige Anordnungen zu reagieren, entfällt dadurch jedoch nicht.

Zugriffs- und Rollenkonzepte
Feingranulares RBAC (Role-Based Access Control) mit Least-Privilege-Prinzip, zeitlich begrenzten Just-in-Time-Rechten und Vier-Augen-Freigaben verhindert unnötige Berechtigungen. Lückenloses Security-Logging (unveränderbare Protokolle, SIEM-Anbindung) schafft Belege für Audits und erleichtert Vorfallanalysen. Entscheidend ist die Betriebsreife dieser Kontrollen: Rollenmodelle, Rezertifizierungen und Notfallprozesse müssen dokumentiert und geübt sein.

Vertragliche Absicherung & Transfers
Juristische Pfade werden durch DPF (EU-US Data Privacy Framework) und/oder SCC (Standardvertragsklauseln) mit zusätzlichen Maßnahmen abgesichert. Art. 48 DSGVO wird vertraglich adressiert (Ablauf bei Drittstaats-Ersuchen, MLAT-Pfad). Ein Transfer Impact Assessment (TIA) bewertet das Restrisiko, legt technische/organisatorische Gegenmaßnahmen fest und wird bei Rechts-/Architekturänderungen aktualisiert. Diese Instrumente mindern die Risiken, ersetzen aber nicht die technische Schlüsselhoheit.

Betrieb & Nachweise
Gefordert ist ein belastbares GRC-Set-up (Governance, Risk, Compliance): Richtlinien, Runbooks, Schulungen, Audit-Trails und regelmäßige Evidenzpakete für NIS2/ISO sowie SOC 1/ISAE 3402 (Typ II). In die Lieferkette gehören ein Subprozessor-Register mit Vorab-Zustimmung bei Änderungen und klare Anforderungen an Pen-Tests, Schwachstellenmanagement und Patch-Zyklen. Für besonders risikogeneigte Daten empfiehlt sich eine DPIA (Datenschutz-Folgenabschätzung).

Notfall- und Exit-Plan
Für regulatorische Änderungen (z. B. Anpassungen am DPF) sind Trigger, Playbooks und Verantwortlichkeiten festgelegt: Datenre-Lokalisation innerhalb der EU-Region, Umschalten auf alternative Dienste, Kommunikations- und Freigabepfade. Der Data Act erleichtert den Anbieterwechsel; wirksam wird er erst mit konkret vereinbarten Exportformaten, API-Spezifikationen, Fristen und einem getesteten Migrationspfad. Probedurchläufe (Table-Top-/Live-Tests) senken das Ausfallrisiko; RTO/RPO-Ziele sind messbar zu hinterlegen.

Monitoring & Review
Zur laufenden Pflege gehören Key-Rotationen (inkl. HYOK-Tests), Auswertung von Audit-Logs, regelmäßige Re-Zertifizierungen der Rollen, Penetrationstests und ein Legal-Watch auf relevante US-/EU-Rechtsentwicklungen. Ergebnisse fließen in TIA, Verträge und technische Settings zurück.

Datenminimierung & Scope-Kontrolle
Je weniger Daten und je weniger PaaS-Dienste im Spiel, desto kleiner die Angriffs- und Angriffsfläche – daher: zweckgebundene Datennutzung, wo möglich Pseudonymisierung/Tokenisierung, klare Abgrenzung, welche bAV-Daten in welche Hyperscaler-Dienste dürfen und welche nicht.

Quintessenz
Mit HYOK/External KMS, strengen Zugriffskontrollen, belastbaren Vertrags- und Transfermechanismen sowie gelebter Governance lässt sich das Restrisiko bei US-Clouds mit EU-Hosting auf ein vertretbares Maß senken. Ein Rest bleibt – genau deshalb sollte der Einsatz von Hyperscaler-Diensten für bAV-Kernprozesse gezielt und begründet erfolgen, während die eigentliche bAV-Verwaltung vorzugsweise in einer EU-gehosteten, spezialisierten SaaS erfolgt.

7) Wirtschaftlichkeit, Lock-in, Exit

Wirtschaftlichkeit in Cloud-Projekten erschöpft sich nicht in Lizenz- oder Betriebspreisen. Relevant sind ebenso Folgekosten: Aufwand für Datenschutz und Compliance, Abstimmungen mit dem Betriebsrat (wo vorhanden), Nachweise für Prüfungen, Integration in HR/Payroll-Prozesse sowie künftige Wechsel- und Migrationskosten. Eine Lösung wirkt auf den ersten Blick günstig und erweist sich im Betrieb als teuer, wenn wiederkehrende Governance-Aufgaben unterschätzt werden.

Total Cost of Ownership (TCO)
Unter TCO fallen alle Kosten über den Lebenszyklus: Beschaffung, Einführung, laufender Betrieb, Support, Schulungen, Compliance-Evidenzen, Anpassungen nach Rechts- oder Produktänderungen sowie der spätere Exit. EU-gehostete, spezialisierte bAV-SaaS reduziert typischerweise den Anteil der nicht-funktionalen Kosten (weniger Transfer-/Rechtsdokumentation, schlankere Nachweise), weil Drittlandthemen und komplexe Plattformketten entfallen. US-Clouds mit EU-Hosting können im Einzelpreis punkten, erzeugen aber oft zusätzliche Daueraufgaben (z. B. Transfer Impact Assessments, Art-48-Prozesse, Schlüssel-Governance), die in die Kalkulation gehören.

Lock-in – was ihn erzeugt und wie er sich begrenzen lässt.
Lock-in entsteht auf drei Ebenen:

• Technisch durch proprietäre Dienste und Formate (spezielle Datenbanken, proprietäre Workflows, eng gekoppelte PaaS-Bausteine).
• Vertraglich durch lange Bindung, undurchsichtige Kündigungsfristen, unklare Egress-Konditionen oder fehlende Migrationszusagen.
• Organisatorisch durch gewachsene Abhängigkeiten im Betrieb (Skripte, Automatisierungen, Know-how, das nur auf einer Plattform existiert).

Gegenmaßnahmen sind entsprechend dreigleisig: offene Formate und standardisierte Schnittstellen (API-Spezifikationen, dokumentierte Datenmodelle), klare Vertragsregeln zum Export (Formate, Fristen, Supportumfang, Egress) sowie Betriebsdisziplin (Dokumentation, Code-Portabilität, regelmäßige Tests von Export und Import).

Der Data Act als Rückenwind – aber kein Selbstläufer
Der europäische Data Act stärkt die Wechselbarkeit: Interoperabilitätsanforderungen, klarere Exportpflichten und die schrittweise Reduktion von Wechsel-/Egress-Hürden sind vorgesehen. Wirksam wird das erst, wenn die Regelungen in konkrete Projektvereinbarungen übersetzt werden. Entscheidend sind:

• Benannte Exportformate (etwa CSV/Parquet für Daten, PDF/A für Dokumente, klar definierte Fach-IDs) und vollständige Metadaten.
• API-Spezifikationen inklusive Versionierung und Durchsatzvorgaben.
• Zeitpläne für einen geordneten Exit mit abgestimmten Fristen und Rollen (wer liefert was, bis wann, in welcher Qualität).
• Migrations-Support als Leistungsbestandteil (Datenmapping, Fachtests, Abnahme-Kriterien).

Exit-Fähigkeit entsteht nicht auf dem Papier, sondern im Test. Ein Exit gilt erst dann als belastbar, wenn er mindestens einmal in Teilmengen erprobt wurde. Sinnvoll ist ein abgestuftes Vorgehen:

• Datenlandkarte erstellen (Welche Datensätze? Welche Systeme? Welche Aufbewahrungsfristen?).
• Probedurchlauf mit einem realistischen Ausschnitt (Datenexport → neutraler Zwischenspeicher → Import in Staging).
• Fachliche Abnahme (stimmen Summen, Historien, Rechenlogiken, Verknüpfungen?).
• Korrekturschleife und Festschreiben der Lessons Learned im Vertrag und in den Runbooks.
  Wer diesen Zyklus regelmäßig wiederholt (z. B. jährlich), reduziert Wechselrisiken und gewinnt Argumente in Preis- und Vertragsgesprächen.

Preislogik realistisch bewerten
Preisvergleiche sollten Funktions- und Risikogleichheit herstellen. Ein bAV-SaaS-Preis, in dem Audits, rechtssichere Protokollierung, Hosting in Deutschland und fertige Payroll-Schnittstellen enthalten sind, ist nicht direkt mit einem günstigen Plattform-Preis pro Rechenstunde vergleichbar. In die Bewertung gehört eine Risikoprämie für Rechts- und Governance-Themen sowie die Personalkapazität, die zur Steuerung komplexer Plattform-Setups erforderlich ist.

Scope sauber halten – weniger ist oft mehr
Je enger der fachliche Scope im Kernsystem (bAV-Verwaltung, Aktuariat, Payroll-Prozesse, Self-Services) und je klarer die Abgrenzung zu optionalen Plattformdiensten (Reporting/BI, Data-Lake-Anbindung), desto geringer fallen Komplexität und Folgekosten aus. Eine spezialisierte bAV-SaaS bildet den Kern; Dienste der Hyperscaler-Plattformen (AWS, Microsoft Azure, Google Cloud) werden gezielt und zweckgebunden zugeschaltet – etwa für analytische Auswertungen –, nicht als Standard für sämtliche Prozessschritte.

Kennzahlen, die Wirtschaftlichkeit greifbar machen
Zur Steuerung eignen sich wenige, aber aussagekräftige KPIs, zum Beispiel:

• Einführungszeit bis Go-Live (inkl. BV-Abschluss, wo relevant)
• Aufwand für Prüfungen (Anzahl Rückfragen/Findings je Jahresabschluss)
• Anzahl TIA-/Vertrags-Updates pro Jahr (bei US-Clouds)
• Zeit bis zum vollständigen Datenexport (End-to-End, getestet)
• Egress-Quote (Kosten je GB, bis zur vollständigen Entlastung durch den Data Act)
• Change-Durchlaufzeit (von Fachanforderung bis produktiver Umsetzung)

Ergebnis
Wirtschaftlich vorn liegt in der bAV-Praxis meist ein EU-gehostetes, spezialisiertes SaaS-Kernsystem mit klar definiertem Exit – ergänzt um punktuelle Plattform-Dienste dort, wo sie messbaren Zusatznutzen bringen und ohne den Rechts- und Governance-Scope unnötig zu vergrößern.

8) Anforderungen an ein bAV-Cloudsystem – und wie bixie sie abdeckt

Fachliche Abdeckung
Ein taugliches bAV-System muss alle Durchführungswege und diverse Zusagetypen (Leistungszusagen, beitragsorientierte Leistungszusagen, wertpapierorientierte/wertgleiche Modelle etc.) abbilden, Rechtsstände und Tarife berücksichtigen sowie Leistungs- und Rentenberechnungen revisionsfest durchführen. bixie adressiert genau dieses Profil mit einer aktuariellen Engine für Bewertungen (HGB/EStG/IFRS/US-GAAP) und integrierter Administration über die Durchführungswege hinweg.

Integration & Prozesse
Notwendig sind Standardschnittstellen zu HR/Payroll (z. B. SAP HCM/SuccessFactors, Workday, Personio, DATEV) sowie Web-APIs für bidirektionale Datenflüsse. Vorgaben wie Zweckbindung, Datenminimierung und Löschkonzepte sind systemisch zu unterstützen. bixie stellt entsprechende Integrationspfade bereit (API-getrieben) und bringt Prozesslogik für Administration, Kommunikation und Dokumentation mit.

Self-Services
Ein Mitarbeiter-/Rentner-Portal erhöht Transparenz und entlastet HR. SSO (Single Sign-On) und 2FA (Zwei-Faktor-Authentifizierung) gelten als Mindeststandard. bixie bietet Employee Self Services für Auskünfte, Anträge und Dokumentzugriff.

Auditierbarkeit & Sicherheit
Für bAV-nahe Auslagerungen relevant: ISAE 3402/SOC 1 Typ II, ISO/IEC 27001, revisionsfeste Protokollierung, Nachvollziehbarkeit von Änderungen, Vier-Augen-Prinzip in kritischen Prozessen, Berechtigungs-/Rollenkonzepte. bixie ist auf jährliche Prüfungen und die Bereitstellung entsprechender Evidenzen ausgerichtet.

Hosting & Rechtsraum
bixie wird in Deutschland betrieben (Open Telekom Cloud). Damit entfällt der Drittlandtransfer, Betriebsvereinbarungen lassen sich schneller schließen, und der Nachweisaufwand rund um DPF/SCC/TIAs entfällt weitgehend. Die OTC erfüllt etablierte Sicherheitskataloge (u. a. BSI C5, ISO/IEC 27001), was der Nachweisführung zusätzlich hilft.

Modularität
Aufbau in Modulen (z. B. Administration Services, Actuarial Services, Employee Self Services, Payroll-/Order-Module). Dadurch lässt sich mit dem Kern starten und bei Bedarf schrittweise erweitern – ohne Architekturwechsel.

Positionierung
Die Kombination aus deutschem Hosting, bAV-Spezialisierung, aktuarieller Tiefe, Audit-Eignung und Integrationsfähigkeit positioniert bixie als Robust-Standard für bAV-Kernprozesse – mit der Möglichkeit, punktuell Analytics/BI-Dienste anzudocken, wo sinnvoll und mit EU-Schlüsselhoheit.

9) Entscheidungsszenarien – nach Anforderungen, nicht nach Größe

Entscheidend ist nicht, ob ein Unternehmen Mittelstand oder Konzern ist, sondern welche Anforderungen an Rechtsraum, Governance und Integration bestehen. Ein tragfähiges Grundmuster sieht bixie als EU-gehostetes bAV-Kernsystem vor, das Verwaltung und Aktuariat stabil abdeckt. Darum herum werden – nur wo sinnvoll – ergänzende Plattformdienste eingebunden. So bleibt die bAV fachlich sauber, auditierbar und unabhängig von unnötiger technischer Komplexität.

Wenn bAV-Kernprozesse zuerst stabilisiert und Abschlusssicherheit erhöht werden sollen, schafft bixie als spezialisierte SaaS die verlässliche Basis: Durchführungswege und Zusagetypen werden durchgängig verwaltet, versicherungsmathematische Bewertungen laufen revisionsfest, Schnittstellen zu HR/Payroll sind definiert. Das Hosting in Deutschland reduziert Rechts- und Transferfragen, erleichtert die Nachweisführung und – wo vorhanden – die Mitbestimmung. Ergebnisse sind kürzere Einführungszeiten und ruhigere Jahresabschlüsse.

Besteht die Pflicht, eine bestehende Data-/AI-Landschaft auf AWS, Microsoft Azure oder Google Cloud anzubinden, bleibt bixie dennoch der „Single Source of Truth“ für bAV-Daten. Analytics oder BI werden gezielt via APIs oder ETL angebunden; Datenminimierung, EU-Regionen und – falls Plattformdienste personenbezogene Daten verarbeiten – Schlüsselhoheit (z. B. HYOK/External KMS) bilden die Leitplanken. So lässt sich der Konzernstandard bedienen, ohne den bAV-Kern in eine breite PaaS-Abhängigkeit zu ziehen.

In Organisationen mit sensibler Datenschutz- und Mitbestimmungslage zahlt sich die klare EU-Verortung doppelt aus. Deutschland-Hosting, nachvollziehbare Protokollierung, schlanke Rollen-/Rechtekonzepte und eine transparente Zweckbindung bilden ein konsistentes Paket, auf dessen Grundlage Betriebsvereinbarungen zügig geschlossen und im Betrieb ohne Reibungsverluste gelebt werden können.

Viele Unternehmen arbeiten zudem mit heterogenen HR-/Payroll-Landschaften. Auch hier punktet bixie als integratives bAV-Kernsystem: Standardisierte Schnittstellen verhindern Punkt-zu-Punkt-Wildwuchs, eine saubere Datenlandkarte hält Verantwortlichkeiten klar, und Systemwechsel auf HR-/Payroll-Seite bleiben beherrschbar, ohne die bAV neu aufzusetzen.

Schließlich gewinnt die Exit-/M&A-Tauglichkeit an Bedeutung. Wer Exportformate, API-Spezifikationen, Fristen und Migrations-Support von Beginn an vertraglich fixiert und mindestens einmal praktisch testet, schafft echte Portabilität – nicht nur auf dem Papier. Der Data Act liefert Rückenwind, ersetzt aber keine geübten Prozesse.

Unterm Strich entsteht ein belastbares Zielbild: bixie bildet als spezialisierte, in Deutschland gehostete bAV-SaaS den Kern; Hyperscaler-Dienste werden punktuell und zweckgebunden ergänzt. So bleibt die Architektur in unterschiedlichen Unternehmensrealitäten konsistent – mit hoher Fachlichkeit, klarer Compliance und kontrollierter technischer Komplexität.

10) Einkaufs- und Implementierungscheckliste

Datenlokation & Subprozessoren

• Deutschland/EU verbindlich
• Subprozessorenliste, Vorab-Zustimmung bei Änderungen
• Transparente Datenflüsse/Verarbeitungszwecke

Schlüsselhoheit & Kryptobetrieb

• Mindestens CMEK/BYOK, bevorzugt HYOK/External KMS in EU-HSM
• „No-key-no-access“ technisch nachweisbar (Tests, Rotation, Entzug)
• Getrennter Schlüssel-Betriebsprozess, Audit-Evidenzen

Vertrag & Transfer

• Art. 28 DSGVO-AVV, ggf. DPF/SCC + Zusatzmaßnahmen
• Art-48-Klauseln (MLAT-Pfad), definierte Eskalations-/Response-Prozesse
• Haftung und Service Levels an bAV-Kritikalität ausrichten

NIS2/ISO/ISAE-Nachweise

• ISAE 3402/SOC 1 Typ II jährlich, ISO/IEC 27001
• Incident-/Meldeprozesse, Lieferketten-Risikoanalysen, BCM/DR-Tests
  Zugriff für Revision/Abschlussprüfer

Data-Act-Exit

• Exportformate, API-Spezifikationen, Migrationspfade
• Test-Migration (Probedurchlauf), Fristen, Supportumfang
• Egress-Regelung (auch wenn perspektivisch entfallend)

Betriebsvereinbarung

• Logging-Umfang, Rollen-/Rechte-Matrix, Zweckbindung
• Lösch-/Sperrkonzepte, Transparenz zu Dienstleistern und Schlüsselbetrieb
• Regelmäßige Review-Zyklen (Technik, Prozesse, Rechtslage)

Schatten-IT & Governance

• Klare Daten- und Integrationsrichtlinien
• Begrenzung der „PaaS-Spielwiese“ auf definierte, geprüfte Use-Cases
• Verantwortlichkeiten (Fach-/IT-/Datenschutz-Rollen) verbindlich festgelegt

Fazit

Für bAV-Kernprozesse überwiegt bei EU-Anbietern mit Hosting in Deutschland die Rechtssicherheit und Auditierbarkeit; US-Clouds mit EU-Hosting sind möglich, erfordern jedoch zusätzliche Sicherungen (u. a. HYOK/External KMS, DPF/SCC, TIA) und einen geübten Exit-Plan. Wirtschaftlich zählt der Gesamtaufwand (TCO) inklusive Governance-Betrieb.

Empfohlener Aufbau: bixie läuft als spezialisiertes SaaS in Deutschland und bildet das bAV-Kernsystem. Dienste von AWS, Microsoft Azure oder Google Cloud werden nur dort ergänzend genutzt, wo sie für Analysen und Berichte einen klaren Mehrwert bringen – abgesichert durch Schlüsselhoheit in der EU und einen definierten Exit-Plan.

Hinweis: Die Inhalte dienen ausschließlich allgemeinen Informationszwecken und ersetzen keine Rechts-, Steuer- oder sonstige Beratung. Eine Haftung für Richtigkeit, Vollständigkeit und Aktualität ist ausgeschlossen.