Vendor-Management für SaaS: Vertragsklauseln, die IT und Einkauf früh prüfen sollten

Der Moment ist unangenehm vertraut: Der Fachbereich hat eine SaaS-Lösung getestet, der Pilot war „eigentlich gut“, die Geschäftsseite will Tempo – und im Postfach landet ein Vertragspaket mit dem Hinweis, man müsse „nur noch unterschreiben“, damit der Rollout startet. Spätestens jetzt entscheidet sich, ob Vendor-Management für SaaS bei Ihnen ein gelebter Prozess ist oder ob Einkauf und IT unter Zeitdruck Dinge akzeptieren, die später den Betrieb dominieren: ungeklärte Datenflüsse, Support ohne echte Eskalation, Integrationen ohne verlässliche Änderungsregeln – und ein Exit, der nur auf dem Papier existiert.

Die entscheidende Weichenstellung passiert dabei nicht im Kleingedruckten, sondern in der Reihenfolge: Welche Klauseln müssen früh auf den Tisch, weil sie Daten, Compliance, Betriebsfähigkeit und Abhängigkeiten prägen? Und welche Details dürfen nachrangig bleiben, ohne dass Sie Kontrolle und Planbarkeit verlieren?

Vendor-Management für SaaS in der Praxis

In der Praxis stehen Unternehmen bei SaaS-Verträgen selten vor „gut oder schlecht“, sondern vor drei Optionen:

• Option A: Standardvertrag akzeptieren und hoffen, dass es schon passt. Das ist schnell, aber die Risiken landen später im Betrieb und in der Auditvorbereitung.
• Option B: alles verhandeln und den Vertrag als Grundsatzdebatte führen. Das blockiert oft – ohne garantiert bessere Ergebnisse.
• Option C: priorisiert verhandeln: wenige Klauselblöcke konsequent absichern, den Rest pragmatisch behandeln. Das ist meist der beste Kompromiss für IT, Einkauf und Fachbereich.

Der Zielkonflikt ist klar: Beschaffungstempo versus belastbare Betriebs- und Exit-Fähigkeit. Wer ihn nicht offen adressiert, entscheidet implizit – meistens zugunsten des Tempos. Die Rechnung kommt später als Zusatzaufwand in Integrationen, Support und Migration.

Entscheidungspfad: In welcher Reihenfolge IT und Einkauf prüfen sollten

Ein funktionierender Prüfpfad ist kurz genug, um im Alltag genutzt zu werden – und konkret genug, um Streit über Grundannahmen zu vermeiden. Die folgende Reihenfolge ist robust, weil sie erst das Betriebsbild klärt und dann verhandlungsfähige Risiken priorisiert.

1. Schutzbedarf & Datenarten festlegen: Welche Daten landen in der SaaS (personenbezogen, vertraulich, Geschäftsgeheimnisse)? Welche Prozesse hängen daran, welche Ausfallfolgen wären akzeptabel?
2. Rollen und Verantwortlichkeiten klären: Sind Sie „Verantwortlicher“ (Controller) und der Anbieter „Auftragsverarbeiter“ (Processor)? Oder gibt es eine Konstellation gemeinsamer Verantwortlichkeit?
3. Betriebsbild skizzieren (ohne Architekturroman): SSO (Single Sign-on), Provisioning, API/Exports, Logging, Monitoring, Supportwege, Admin-Zugriffe.
4. Top-Klauseln prüfen: DPA/DSGVO, Subunternehmer, Security/Incidents, SLA/Support, Datenlokation/Transfers, Exit/Portabilität.
5. Kommerzielle Mechaniken prüfen: Preisänderungen, True-ups, Nutzungsmetriken, Limits, Laufzeiten, Kündigungs- und Verlängerungslogik.
6. Nachweispaket und Rhythmus definieren: Attestate, Fragebögen, Change-Kommunikation, Ansprechpartner, Review-Termine.

Für die Zusammenarbeit hilft eine klare Aufgabentrennung: Einkauf führt Verhandlung und Fristen, IT liefert betriebliche Mindestkriterien, Datenschutz/Compliance bestätigt Muss-Anforderungen. Sobald diese Rollen verschwimmen, werden Entscheidungen zäh – oder rutschen in den „wir unterschreiben erst mal“-Modus.

Die Klauseln, die zuerst auf den Tisch gehören

Viele Verträge wirken formal vollständig und scheitern trotzdem an der Realität im Betrieb. Die Tabelle übersetzt typische Klauselbereiche in konkrete Folgen. Sie eignet sich als Priorisierungshilfe, wenn „wir müssen heute entscheiden“ auf „wir müssen morgen betreiben“ trifft.

DPA, DSGVO und „Return or Delete“: warum das kein Anhang-Thema ist

Sobald personenbezogene Daten in der SaaS verarbeitet werden (Nutzerdaten, Kundendaten, HR-Daten, Protokolle), ist der Datenschutzteil nicht „ein Dokument für die Ablage“, sondern Teil Ihrer Betriebsfähigkeit. Die EDPB-Leitlinien konkretisieren, dass bei Ende der Verarbeitung personenbezogene Daten nach Wahl des Verantwortlichen zu löschen oder zurückzugeben sind und vorhandene Kopien zu löschen sind.^[Quelle] Die praktische Konsequenz: Exit heißt nicht nur „Export“, sondern Löschungskette – inklusive Backups und beteiligter Subunternehmer.

Die Grenze liegt im Detail: Ein DPA kann formal korrekt sein und trotzdem offenlassen, wie Löschung im Backup-Kontext funktioniert, wie lange Wiederherstellungspunkte vorgehalten werden oder wie „Löschbestätigung“ konkret aussieht. Diese Lücke verschwindet nicht durch juristische Begriffe. Sie verschwindet erst, wenn Sie ein Szenario durchspielen: „Wir kündigen zum Datum X. Welche Daten liegen wann wo, wer kann sie noch sehen, und wann ist endgültig Schluss?“

Subunternehmer-Ketten: Transparenz ist gut, Steuerbarkeit ist besser

Bei SaaS sind Subunternehmer normal: Hosting, Monitoring, Support-Tools, E-Mail-Zustellung, Analytics, Ticketing. Entscheidend ist nicht, ob Subunternehmer existieren, sondern ob Sie deren Einsatz steuern können. Die ICO-Leitlinien betonen, dass eine Genehmigung (spezifisch oder allgemein) sowie ein Informationsmechanismus für Änderungen nötig sind, damit Verantwortliche reagieren können.^[Quelle] Praktisch heißt das: Eine Subunternehmerliste als PDF ist erst der Anfang. Ohne Vorlauf, Benachrichtigungskanal und Widerspruchslogik bleibt sie ein Archivdokument.

Für IT und Einkauf lohnt sich eine Prüffrage, die über „Liste vorhanden?“ hinausgeht: Welche neue Fähigkeit entsteht durch den Subunternehmer? Ein CDN ist anders zu bewerten als ein Support-Tool, das Admin-Sitzungen ermöglicht. Und ein Observability-Dienst für Telemetrie kann in Regionen laufen, die nicht zum Primärhosting passen.

Was häufig verhandelbar ist, ohne das SaaS-Modell zu sprengen:

• Vorlaufzeiten für Subunternehmer-Änderungen (damit Sie intern prüfen können).
• Widerspruchs- oder Sonderkündigungsrechte bei nicht akzeptablen Änderungen.
• Klassifizierung nach Datenkategorien: Für besonders kritische Daten gelten strengere Regeln.

SLA und Support: Messen statt behaupten

Viele SLAs lesen sich gut, weil eine Prozentzahl prominent steht. Im Störungsfall zeigt sich dann, dass Messmethode, Ausnahmen und Wartungsfenster so flexibel formuliert sind, dass die Zahl wenig bedeutet. Der WorldCC SaaS Contracting Guide beschreibt SLAs als zentrale Verhandlungspunkte – inklusive Abhilfen wie Service Credits und Konsequenzen bei wiederholter Nichterfüllung.^[Quelle] Für den Betrieb folgt daraus: IT sollte vor Vertragsabschluss definieren, welche Verfügbarkeit im eigenen Prozess wirklich zählt (UI, API, Region, Kerntransaktionen) und wie sie im Zweifel belegt werden kann.

Drei SLA-Bausteine machen den Unterschied zwischen „Papier“ und „Betriebswerkzeug“:

• Messmethode: Wer misst, an welchem Punkt (UI, API-Endpunkt, Region)? Wie werden Teilausfälle, Performance-Degeneration oder Login-Probleme gewertet?
• Wartungsfenster: planbar, begrenzt, mit sauberer Ankündigung. „Jederzeit möglich“ ist praktisch kein Wartungsfenster, sondern ein Risiko.
• Supportmechanik: Prioritäten (P1–P4), Reaktions- und Update-Zyklen, Eskalationsstufen und Kommunikationskanal.

Aus Einkaufssicht gehört dazu der Hebel, der im Alltag wirkt: Rechtsfolgen bei Wiederholung. Service Credits können Budgets entlasten, lösen aber keine Prozessabhängigkeit. Wenn die SaaS für einen kritischen Ablauf gebraucht wird, ist ein Sonderkündigungsrecht bei wiederholtem SLA-Verfehlen oft die entscheidendere Absicherung.

Security-Klauseln: Mindeststandards, Incident-Prozess und Nachweise

Security-Klauseln scheitern selten daran, dass niemand „Sicherheit“ will, sondern daran, dass Formulierungen unprüfbar bleiben. Das Canadian Centre for Cyber Security empfiehlt, Sicherheitsanforderungen in Cloud-Verträgen explizit zu verankern, unter anderem Incident-Response- und Benachrichtigungspflichten sowie sichere Datenentsorgung.^[Quelle] Das ist für IT im Alltag nützlich, weil es die Diskussion von „Best Effort“ auf konkrete Pflichten verschiebt: Wer meldet was, wie schnell, und über welchen Kanal?

Ein praxistauglicher Security-Block muss nicht jedes Detail ausbuchstabieren, aber er braucht klare Mindestpunkte:

• Authentisierung und Zugriff: MFA für privilegierte Konten, Rollenmodell, Least Privilege (minimale Rechtevergabe) als Prinzip.
• Verschlüsselung: bei Transport und Speicherung; zusätzlich der Umgang mit Schlüsseln (Rotation, Zugriffsbeschränkung).
• Incident/Breach-Prozess: Meldefristen, Mindestinformationen (betroffene Datenarten, Zeitraum, erste Maßnahmen), regelmäßige Updates.
• Logging und forensische Unterstützung: Welche Protokolle existieren, wie lange, und wie erhalten Sie im Vorfall relevante Daten?
• Nachweise: welche Attestate oder standardisierten Berichte regelmäßig bereitgestellt werden.

Die typische Hürde: Viele Anbieter akzeptieren kein unbegrenztes Onsite-Auditrecht. Statt daran festzubeißen, ist ein abgestuftes Assurance-Modell oft zielführender: regelmäßige Attestate, standardisierte Fragebögen/Portale und ein Eskalationsrecht für Rückfragen. Damit gewinnen Sie Nachweise, ohne den Vertrag an einem Punkt zu verlieren, der für den Anbieter strukturell nicht leistbar ist.

Datenlokation und internationale Datentransfers: nicht bei „EU-Hosting“ stehen bleiben

„Daten liegen in der EU“ klingt eindeutig, ist es aber selten. Für Verträge zählen mindestens vier Datenorte: Primärdaten, Backups, Telemetrie/Logs und Supportzugriffe (Remote-Administration). Sobald einer dieser Pfade in Drittländer führt, wird das Thema internationale Datentransfers praktisch relevant. Der EDPB erläutert, wann internationale Datentransfers vorliegen und welche Mechanismen typischerweise genutzt werden, um sie rechtlich abzusichern.^[Quelle] Die Konsequenz für Einkauf und IT: Datenflüsse gehören in den Leistungsumfang – nicht in ein isoliertes Datenschutzkapitel.

Für die Praxis hilft ein kurzer Vertragsanhang mit klaren Aussagen statt allgemeiner Versprechen:

• Regionen für Verarbeitung und Speicherung (inkl. Backups).
• Regeln für Verlagerungen: wer darf ändern, mit welchem Vorlauf, mit welcher Information.
• Supportzugriffe: nur ticketbasiert, zeitlich begrenzt, protokolliert; bei Bedarf zusätzlich Maskierung oder restriktive Rollen.

Exit, Portabilität und Löschung: der unterschätzte Kosten- und Risikotreiber

Vendor Lock-in entsteht selten durch eine einzelne Klausel. Er entsteht durch fehlende Exit-Mechanik in Kombination mit Integrationen und Zeitdruck. Exit heißt dabei nicht nur „Daten exportieren“, sondern auch „Daten und Kopien löschen lassen“. Die EDPB-Leitlinien unterstreichen für Auftragsverarbeitung den Grundsatz „delete or return“ am Ende der Verarbeitung.^[Quelle] Für die Projektplanung ist das entscheidend: Ohne klare Regeln können Sie Migration und Stilllegung nicht belastbar takten.

Gute Exit-Regeln sind nicht lang, sondern konkret nutzbar:

• Exportformate: maschinenlesbar (z. B. CSV/JSON), vollständig (inkl. Metadaten und Referenzen), dokumentiert.
• Zugriffsfenster: wie lange ist der Zugang nach Vertragsende verfügbar, wie lange sind Exporte abrufbar?
• Unterstützung: definiertes Kontingent oder klar beschriebene Leistungen (z. B. Exportlauf, Validierung, Beratung zur Datenabbildung).
• Löschprozess: Umgang mit Backups, Fristen, Nachweis (Löschbestätigung), Einbezug der Subunternehmerkette.

Ein zusätzlicher interner Hebel: Exit-Fähigkeit nicht erst bei Kündigung testen. Ein jährlicher „Export-Realitätscheck“ für kritische SaaS ist oft der Unterschied zwischen planbarer Migration und Überraschung im Projekt.

Änderungsklauseln: wenn sich API, Preislogik oder Limits verschieben

SaaS verändert sich kontinuierlich. Das ist funktional oft erwünscht – vertraglich aber riskant, wenn Änderungen einseitig möglich sind, ohne dass Sie Rechte oder Vorlaufzeiten haben. Kritisch sind insbesondere Änderungen an Integrationspunkten (APIs, Webhooks, SSO), an Lizenzmetriken (True-ups, neue Pflicht-Add-ons) und an Datenfunktionen (Export, Aufbewahrung, Logging).

Für Einkauf zählt hier weniger der Listenpreis als die Änderungsmechanik: Welche Änderungen gelten als „wesentlich“, wie früh werden sie angekündigt, und welche Rechte entstehen daraus (Widerspruch, Sonderkündigung, Übergangsfristen)? Für IT ist zusätzlich wichtig, dass Breaking Changes nicht „irgendwann“ passieren, sondern mit Deprecation-Fristen und Testmöglichkeiten planbar werden. Sonst wird aus SaaS-Wartung ein wiederkehrender Feuerwehreinsatz.

Vendor-Management ist laufende Steuerung, nicht die Unterschrift

Ein unterschriebener Vertrag stoppt Risiken nicht automatisch. NIST beschreibt Cybersecurity Supply Chain Risk Management als fortlaufende Praxis: bewerten, überwachen, auf Abweichungen reagieren und Transition/Beendigung mitdenken.^[Quelle] Für Unternehmen folgt daraus ein einfacher Grundsatz: Wenn Sie Risiken nur beim Vertragsabschluss betrachten, bewerten Sie ein bewegliches Ziel mit einem Standbild.

Ein schlanker Rhythmus reicht meist aus, wenn er verbindlich ist:

• Quartalsweise: SLA- und Supportauswertung (Tickets, Eskalationen, Ausfälle) plus Review größerer Änderungen/Deprecations.
• Halbjährlich: Subunternehmeränderungen und relevante Nachweise (Attestate/Reports) prüfen, Abweichungen dokumentieren.
• Jährlich: Exit-Prüfung (Exports), Berechtigungs- und Rollenreview, Aktualisierung von Schutzbedarf und Abhängigkeiten.

Wichtig ist weniger die Frequenz als das Artefakt: Ein kurzer Decision Log oder ein Risikoregister, das zeigt, was entschieden wurde, warum, und welche Folgeaufgaben entstehen. Ohne diese Spur wird Vendor-Management zur E-Mail-Suche.

Der erste Schritt, der sofort Wirkung hat: ein „Klausel-Intake“ vor dem Angebot

Wenn Sie nur eine Prozessänderung einführen wollen, dann diese: Starten Sie Vendor-Management für SaaS vor dem konkreten Angebot. Sobald ein Fachbereich eine SaaS shortlistet, reicht oft ein 30–45-Minuten-Termin mit Einkauf und IT, um Leitplanken zu setzen: Schutzbedarf, Integrationen, Mindestanforderungen an DPA/Incident/SLA und ein Minimal-Exit.

Der Nutzen ist unmittelbar: Sie vermeiden Piloten, die später an nicht verhandelbaren Vertragsbedingungen hängen bleiben. Und Sie geben dem Anbieter früh ein klares Bild, welche Punkte nicht „nice to have“, sondern Beschaffungsvoraussetzung sind.

Schlussgedanke: Ein SaaS-Vertrag ist Betriebsdesign in Textform

Die meisten Probleme mit SaaS entstehen nicht, weil ein Produkt fachlich ungeeignet ist, sondern weil der Vertrag die spätere Realität nicht abbildet: Datenflüsse, Supportzugriffe, Subunternehmerwechsel, Messmethoden und Exit. Wer diese Punkte früh priorisiert, macht die Einführung nicht langsamer – sondern verhindert, dass Betrieb und Compliance später zum Dauerprojekt werden.

Wenn Sie für kritische SaaS einen kurzen, wiederholbaren Prüfpfad aufsetzen oder Exit- und Portabilitätsregeln für bestehende Verträge nachschärfen möchten, ist ein strukturierter Blick auf Daten, Schnittstellen und Betriebsprozesse ein sinnvoller Startpunkt.

Für dieses Thema sind auch Saas Vertrag und Vendor Lock-In Vermeiden wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.