SaaS-Anbieter prüfen: Unterauftragsverarbeiter, Hosting und Exit-Klauseln

TL;DR (Quick Summary)

Wer SaaS nur nach Funktionsumfang einkauft, übersieht oft die eigentlichen Risiken: Datenflüsse, Unterauftragsverarbeiter, unklare Nachweise und schwache Exit-Regeln. Der richtige Weg ist eine feste interne Prüfung mit einheitlichen Unterlagen und klarer Freigabelogik.

• Prüfrahmen festlegen → erst Einsatz und Mindestkriterien bestimmen
• Unternehmens- und Hosting-Struktur des Anbieters nachvollziehen → Vertragspartner, Hosting und Länder offenlegen
• Unterauftragsverarbeiter systematisch prüfen → Liste gegen die Produktrealität abgleichen
• Zertifikate auf Geltungsbereich prüfen → Scope vor Siegeln
• Incident-Historie und Support-Zusagen abgleichen → Vertrag mit Praxis vergleichen
• Exit und Datenexport vor Vertragsabschluss prüfen → Wechselbarkeit vorab nachweisen lassen
• Ergebnisse in einer Freigabeakte bündeln → einheitlich dokumentieren und nachverfolgen

Takeaway: Eine gute SaaS-Prüfung ist kein Bauchgefühl und keine reine Datenschutzübung. Sie ist ein wiederholbarer Beschaffungsprozess, der Freigaben belastbar macht und spätere Überraschungen reduziert.

Das typische Problem in der Praxis: Der Fachbereich will ein Tool schnell live bringen, der Anbieter schickt ein paar Zertifikate und einen Mustervertrag, und intern fehlt ein belastbarer Prüfpfad. Genau so entstehen Freigaben mit blinden Flecken. SaaS-Anbieter sollten deshalb entlang eines festen Prüfprozesses (Due Diligence) bewertet werden – mit definiertem Einsatz, klaren Mindestkriterien, verbindlich angeforderten Unterlagen und einer Freigabeakte, die Einkauf, IT, Datenschutz und Fachbereich gemeinsam lesen können.

Diese vollständige Prüfung folgt auf die schnelle Vorauswahl. Während das Datenschutz-Screening vor dem Erstgespräch ungeeignete Anbieter früh aussortiert, geht es hier um die Kandidaten, die in die engere Wahl gekommen sind: Nachweise, Vertragsdetails, Incident-Historie und Exit.

Prüfrahmen festlegen: Einsatz, Datenklassen und Mindestkriterien vor der Anbieterprüfung definieren

Bevor Unterlagen angefordert werden, muss intern feststehen, wofür die Software eingesetzt werden soll. Sonst sammelt man Dokumente ohne Bezug zum Risiko. Für die Prüfung zählt nicht, was der Anbieter allgemein anbietet, sondern was Sie konkret nutzen wollen.

Dokumentieren Sie den geplanten Einsatz knapp: betroffene Fachbereiche, verarbeitete Datenarten, angebundene Systeme, Prozesse und regulatorische Berührungspunkte. Ein CRM für Vertriebsdaten ist anders zu prüfen als ein Tool für Bewerbermanagement, Support-Tickets oder Finanzfreigaben. Schon hier zeigt sich, ob es um einfache Stammdaten, besonders sensible Daten, große Dateimengen, Kundenkommunikation oder geschäftskritische Abläufe geht.

Danach legen Sie die internen Mindestanforderungen fest. Typische Punkte sind:

• Hosting-Regionen und zulässige Datenzugriffe aus anderen Ländern
• zulässige Arten von Unterauftragsverarbeitern und ein klarer Prozess bei deren Wechsel
• Nachweise und Zertifizierungen (z. B. ISO 27001, SOC 2, BSI C5)
• Support-Zusagen und Eskalationswege
• Vorgaben zu Datenexport, Löschung und Anbieterwechsel
• vertragliche Grenzen bei Haftung, Mitteilungspflichten oder Änderungsrechten
• internationale Datentransfers: Rechtsgrundlage des Transfers, bei Standardvertragsklauseln (SCC) ein Transfer Impact Assessment (TIA) und gegebenenfalls zusätzliche technische Maßnahmen

Beim letzten Punkt lohnt ein genauer Blick. Für US-Unternehmen, die unter dem EU-US Data Privacy Framework zertifiziert sind, gilt seit Juli 2023 ein Angemessenheitsbeschluss der EU-Kommission; dann sind Standardvertragsklauseln für diese Übermittlung nicht erforderlich. Ob ein konkreter Anbieter zertifiziert ist, lässt sich in der offiziellen DPF-Liste prüfen. Für Übermittlungen in Drittländer ohne Angemessenheitsbeschluss kommen je nach Fall insbesondere Standardvertragsklauseln mit Transfer Impact Assessment oder andere nach der DSGVO zulässige Garantien in Betracht.

Diese Mindestkriterien sollten nicht bei jeder Beschaffung neu erfunden werden. Ein kurzes Standardformular reicht oft, solange die Punkte verbindlich abgefragt und bewertet werden. Anbieter, die schon an Grundanforderungen scheitern, müssen nicht wochenlang weiter geprüft werden.

Im selben Schritt legen Sie fest, welche Unterlagen für jede SaaS-Prüfung eingesammelt werden:

Fehlt diese Basis, wird die restliche Prüfung unsauber. Dann diskutiert man über einzelne Risiken, ohne zu wissen, welcher interne Maßstab gilt.

Prüfliste zur SaaS-Anbieterwahl: Auftragsverarbeiter, Hosting, Ausstieg

Geben Sie Ihre E-Mail-Adresse ein, um eine umfassende Schritt-für-Schritt-Anleitung zu erhalten

Ich bestätige hiermit, dass ich die Bedingungen der Datenschutzpolitik von Bitrix24 vollständig gelesen und verstanden habe.

Unternehmens- und Hosting-Struktur des Anbieters nachvollziehen

Viele SaaS-Prüfungen bleiben bei der Produktdemo stehen. Zuerst zählt aber: Wer ist Ihr Vertragspartner, wer erbringt die Leistung tatsächlich, und über welche Länder oder Gesellschaften laufen Support und Datenzugriffe?

Beginnen Sie mit der rechtlichen Struktur. Klären Sie, welche Gesellschaft den Vertrag schließt und welche weiteren Konzerngesellschaften Leistungen erbringen. Gerade bei internationalen Anbietern ist das oft nicht deckungsgleich: Der Vertrag läuft über eine europäische Vertriebsgesellschaft, der Betrieb über eine andere Einheit, und der Support sitzt in mehreren Ländern.

Fragen Sie konkret nach:

• Vertragspartner und Sitz
• verantwortliche Gesellschaft für den SaaS-Betrieb
• Gesellschaften mit möglichem Zugriff auf Kundendaten
• Orte für Support, Administration und Incident-Bearbeitung
• mögliche Fernzugriffe aus weiteren Ländern

Danach kommt die Hosting-Kette. Gemeint ist nicht nur der primäre Cloud-Anbieter. Relevant sind auch Backup-Standorte, CDN-Dienste, E-Mail-Versand, Monitoring, Ticketing, Support-Plattformen oder Dateiübertragung. Alles, was Teil der Leistungserbringung ist oder mit Kundendaten in Kontakt kommt, gehört ins Bild.

Anbieter nennen gern den großen Cloud-Namen und lassen den Rest offen. Das reicht nicht. Landen Support-Tickets mit Screenshots auf einer externen Plattform oder laufen Systembenachrichtigungen über einen weiteren Dienst, ist das Teil der tatsächlichen Verarbeitung.

Als Ergebnis sollten Sie eine einfache Verantwortungsmatrix erstellen: keine Architekturzeichnung für ein Audit, sondern eine verständliche Übersicht für den Freigabeprozess.

Die Matrix zeigt Einkauf, IT und Datenschutz, ob die tatsächliche Leistungserbringung zum Vertragsbild passt oder weitere Prüfungen nötig sind.

Unterauftragsverarbeiter systematisch prüfen und Transparenzlücken markieren

Bei der Liste der Unterauftragsverarbeiter bleiben Anbieter gern allgemein. Für eine belastbare Freigabe brauchen Sie eine vollständige, verständliche und aktuelle Übersicht aller Unterauftragsverarbeiter, die in die Leistung eingebunden sind.

Prüfen Sie die Liste nicht isoliert, sondern gegen die Produktfunktionen. Bietet das Tool Dateiuploads, E-Mail-Benachrichtigungen, In-App-Support, Analysen, Chat, Signaturfunktionen oder Integrationen, sollte sich das in den genannten Diensten wiederfinden. Fehlt ein naheliegender Diensttyp, ist das eine Rückfrage wert.

Die Prüfung sollte mindestens diese Punkte erfassen:

• Name und konkreter Zweck des Unterauftragsverarbeiters
• betroffene Datenkategorien
• Verarbeitungsorte oder Länderbezug
• Rolle und Einbindung in die Leistung
• Prozess für neue oder ausgetauschte Unterauftragsverarbeiter
• Benachrichtigungsfristen sowie Informations- oder Widerspruchsrechte
• Versionsstand der Liste und ein vereinbarter Weg, über Änderungen informiert zu werden (z. B. E-Mail-Benachrichtigung oder Änderungsprotokoll)

In der Praxis sind weniger fehlende Namen das Problem als schlechte Transparenz. Typische Schwachstellen sind Sammelbezeichnungen wie „Cloud Services“, fehlende Länderangaben, eine unklare Trennung zwischen Konzernunternehmen und externen Dienstleistern oder Listen ohne Versionsstand.

Dokumentieren Sie solche Lücken als konkrete Freigaberisiken, zum Beispiel:

• „Support-Plattform im Produkt erkennbar, aber nicht in der Liste aufgeführt“
• „Verarbeitungsland für Monitoring-Dienst nicht angegeben“
• „Wechselprozess für neue Unterauftragsverarbeiter im Vertrag nicht geregelt“
• „Liste ohne Datum und Version“

Eine unpräzise Liste macht Änderungen unsichtbar. Und unsichtbare Änderungen sind im Freigabeprozess fast immer ein Problem.

"Nach der Einführung von Bitrix24 haben wir die Geschäftsprozesse in unserem Unternehmen maximal vereinfacht."

Geschäftsführer, Alexander Dortmann

DortmannKids

KOSTENFREI STARTEN

Zertifizierungen und Sicherheitsnachweise auf Geltungsbereich statt auf Logos prüfen

Viele Anbieter schicken in der ersten Runde eine Präsentation mit bekannten Siegeln. Das beantwortet die eigentliche Frage aber noch nicht: Decken die Nachweise genau das Produkt, die Betriebsumgebung und den Standort ab, den Sie kaufen wollen?

Prüfen Sie bei jedem Nachweis vier Dinge: Geltungsbereich, ausstellende Stelle, Laufzeit und Bezug zum konkreten Service. Ein ISO-27001-Zertifikat für eine Konzernholding oder ein allgemeines Informationssicherheitsmanagement sagt noch nichts darüber aus, ob die geprüfte Umgebung Ihr SaaS-Produkt tatsächlich umfasst. Dasselbe gilt für Prüfberichte einzelner Standorte, wenn Ihr Mandant in einer anderen Region betrieben wird.

Trennen Sie außerdem, was ein Nachweis tatsächlich belegt:

Bleiben Aussagen zu allgemein, fordern Sie ergänzende Unterlagen an: aktuelle TOM, eine Zusammenfassung des letzten Penetrationstests, Angaben zum Rollen- und Berechtigungskonzept, Beschreibungen zu Backup und Wiederherstellung oder ein Sicherheits-Whitepaper mit konkretem Produktbezug.

Ein häufiger Fehler: Ein Zertifikat wird intern als generelle Sicherheitsfreigabe verstanden. Das ist es nicht. Es ist ein Baustein unter mehreren. Sind Geltungsbereich oder Laufzeit unklar, sollte der Punkt nicht grün, sondern höchstens mit Auflage bewertet werden.

Incident-Historie, Reaktionsfähigkeit und Support-Zusagen gegeneinander prüfen

Ein Anbieter kann gute Nachweise haben und trotzdem operativ schwach sein. Deshalb gehört die Prüfung von Incidents und Support zur Substanzbewertung. Die Frage lautet: Wie reagiert der Anbieter, wenn etwas schiefläuft – und passt das zu seinen Vertragszusagen?

Fragen Sie nach Sicherheitsvorfällen, meldepflichtigen Datenschutzverletzungen, größeren Ausfällen und vorhandenen Nachanalysen (Post-Mortems) der letzten Jahre. Es geht nicht darum, einen Anbieter wegen jedes Vorfalls auszusortieren. Interessanter ist, wie offen, konkret und nachvollziehbar er damit umgeht.

Bei der Bewertung helfen drei Fragen:

• Wird die Ursache plausibel beschrieben?
• Sind Gegenmaßnahmen und operative Änderungen nachvollziehbar dokumentiert?
• Ist erkennbar, wie ähnliche Vorfälle künftig früher erkannt oder begrenzt werden?

Danach prüfen Sie die Reaktionsfähigkeit im laufenden Betrieb: Supportzeiten, Eskalationswege, Sprache, benannte Ansprechpartner, Reaktions- und Wiederherstellungsziele sowie Erreichbarkeit außerhalb der üblichen Geschäftszeiten. Gerade bei geschäftskritischen Prozessen fällt hier schnell auf, ob hinter „Enterprise Support“ mehr steckt als ein Ticketformular.

Vergleichen Sie Marketingaussagen, Vertriebsaussagen, Vertragsklauseln und den beschriebenen Incident-Prozess. Wirbt die Website mit hoher Verfügbarkeit und schneller Hilfe, stehen im Vertrag aber enge Servicegrenzen, unklare Eskalation oder eingeschränkte Supportzeiten, gehört diese Abweichung auf den Verhandlungstisch.

In der Freigabeakte sollten Unterschiede direkt benannt werden, zum Beispiel:

• „Statuskommunikation bei größeren Störungen nicht vertraglich geregelt“
• „Deutschsprachiger Support zugesagt, aber im SLA nicht festgehalten“
• „Wiederherstellungsziele vom Vertrieb genannt, im Vertrag nicht auffindbar“

Wenn es später brennt, zählt nur, was operativ erreichbar und vertraglich greifbar ist.

Exit, Datenexport und Anbieterwechsel vor Vertragsabschluss praktisch prüfen

Viele SaaS-Verträge sind beim Einstieg detailliert und beim Ausstieg vage. Das sollten Sie vor Vertragsabschluss klären. Exit bedeutet hier: Wie kommen Sie vollständig, lesbar und in brauchbarem Format wieder an Ihre Daten – und zu welchen Bedingungen?

Klären Sie zuerst den Exportumfang. Es reicht nicht, wenn ein Anbieter „CSV-Export möglich“ sagt. Sie müssen wissen, welche Datenarten tatsächlich exportiert werden können: Kundenstammdaten, Transaktionsdaten, Dateien, Anhänge, Audit-Daten, Konfigurationen, Berechtigungen, Historien und Metadaten. Ein Export auf dem Papier hilft wenig, wenn wichtige Referenzen, Dateibeziehungen oder Änderungsverläufe fehlen.

Ebenso wichtig sind Format und technischer Weg. Fragen Sie nach Dateiformaten, API-Möglichkeiten, Vollständigkeit je Datenobjekt und möglichen Grenzen. Werden bestimmte Informationen nur manuell, unvollständig oder gar nicht herausgegeben, ist das ein handfestes Lock-in-Risiko.

Verlangen Sie ausdrücklich Beispielexporte mit Datenschema oder Datenbeschreibung, um Struktur und Vollständigkeit nachvollziehen zu können.

Danach geht es um die Bedingungen des Ausstiegs. Prüfen Sie insbesondere:

• Fristen für die Datenbereitstellung nach der Kündigung
• ob und wie lange nach Vertragsende noch Zugriff besteht
• Kosten für Export, Support oder Migrationshilfe
• Übergangsregelungen für einen Parallelbetrieb
• eine Löschbestätigung, die mindestens den Zeitpunkt, die betroffenen Systeme oder Medien sowie den Umgang mit Backups dokumentiert
• API-Zugang während der Übergangsphase

Wenn möglich, verlangen Sie einen kleinen Exit-Nachweis. Das muss kein vollständiger Migrationstest sein. Schon eine Demo, echte Beispielexporte oder eine gemeinsame Durchsicht der API-Dokumentation mit Fachbereich und IT zeigen, ob ein realer Anbieterwechsel machbar wäre. Besonders bei dokumentenlastigen Tools, Workflow-Systemen oder Plattformen mit vielen Konfigurationen wird erst dann sichtbar, ob wirklich alles mitgenommen werden kann.

Ein Anbieter, der beim Exit ausweicht, nur Basistabellen exportieren kann oder Unterstützungsleistungen offenlässt, sollte nicht erst nach mehreren Jahren als Problem auffallen.

Die Ergebnisse in einer wiederholbaren Freigabeakte zusammenführen

Am Ende brauchen Sie kein loses Bündel aus PDFs und E-Mail-Antworten, sondern eine Freigabeakte, auf deren Grundlage intern entschieden werden kann. Sie bündelt die Prüfung so, dass Einkauf, IT, Datenschutz und Fachbereich denselben Stand sehen.

Die Akte sollte als Standardpaket aufgebaut sein:

• Anbieterdaten und geplanter Einsatz
• Risikoeinstufung für den konkreten Anwendungsfall
• Prüfergebnisse je Kernbereich
• offene Punkte und Rückfragen
• empfohlene Vertragsauflagen
• Empfehlung für oder gegen den Einsatz
• Verzeichnis aller gesammelten Unterlagen mit Versionsstand

Die abschließende Empfehlung ist eine interne Beschaffungsentscheidung, keine Rechtsprüfung. Die formale Freigabe durch Datenschutz und Rechtsabteilung ersetzt sie nicht, sondern bereitet sie vor.

Für die Entscheidung funktioniert ein Ampelschema gut, solange es nicht oberflächlich eingesetzt wird. Sinnvolle Kernbereiche sind: Unternehmensstruktur, Hosting, Unterauftragsverarbeiter, Nachweise, Incidents/Support und Exit. Grün heißt „Anforderungen erfüllt und ausreichend belegt“, Gelb steht für Auflagen oder verbleibende Einschränkungen, Rot bedeutet, dass ein Freigaberisiko offen ist oder Mindestkriterien verfehlt werden.

Legen Sie zum Schluss fest, wann eine Nachprüfung fällig ist. Typische Anlässe sind neue Unterauftragsverarbeiter, ein Wechsel des Hostings, auslaufende Zertifikate, schwere Vorfälle, Vertragsverlängerungen oder größere Produktänderungen mit neuen Datenflüssen.

Damit diese Termine nicht untergehen, gehören sie in ein System mit Verantwortlichen und Fristen. In Bitrix24 lässt sich die Anbieterprüfung zum Beispiel als Workflow mit festen Prüfschritten abbilden, und Nachprüfungen können als Aufgaben mit Fälligkeitsdatum und verantwortlicher Person angelegt werden.

Der eigentliche Nutzen dieses Vorgehens: Die Anbieterprüfung wird von einer einmaligen Hürde zu einem steuerbaren internen Verfahren. Spätere Änderungen werden sichtbar, bevor daraus ein Betriebs- oder Compliance-Problem wird.