Corporate-Startup-Deals ohne IT-Exit

Startups liefern Tempo. Fachbereiche wollen genau dieses Tempo in Pilot und Scale. Ohne Exit- und Integrationsplan bleibt die IT an Schatten-Stacks, unklaren Datenflüssen und Verträgen hängen, die im Ernstfall kaum greifen.

VerwandtCorporate Venture Building: Startups im Konzern  /  Warum Startups trotz Milliarden Kunden verlieren

Typische Deal-Motive und typische IT-Blindstellen

Die Motive hinter Corporate-Startup-Deals sind meist nachvollziehbar. Fachbereiche suchen Speed-to-Value, Zugang zu einer Nischenfähigkeit oder einen Proof of Concept, der intern monatelang dauern würde. Laut der Bitkom-Studie „Digitalisierung der Wirtschaft“ (2025) kooperieren nur 31 Prozent der Unternehmen in irgendeiner Form mit Startups; zwei Drittel (67 Prozent) tun es nicht. Wo es läuft, steuern Procurement und Innovation oft über Rahmenverträge, Innovationsbudgets oder Corporate-Venture-Formate und bewerten vor allem Lieferfähigkeit und Preis. Der Nesta-Leitfaden „Winning Together“ (mit Startup Europe Partnership) weist darauf hin, dass Einkauf bei Startups ein anderes Prozess- und Risikodenken verlangt als der klassische Lieferanteneinkauf – und dass starre Supplier-Registration und Zahlungsbedingungen Kooperationen oft blockieren.

Die IT-Blindstellen entstehen selten aus böser Absicht. Sie entstehen, weil Security, Architektur und Betriebsmodell erst nach dem Pilot aufgerufen werden. Dann ist das Startup bereits in Fachprozessen verankert, Nutzerkonten existieren parallel und Daten liegen in Cloud-Regionen, die der Konzern nicht freigegeben hat. Ein nachträglicher Umbau kostet mehr als eine saubere Freigabe vor dem Go-Live.

Typische Blindstellen betreffen Identitäten, Logging, Backup und die Frage, wer den Stack im Störfall wirklich bedienen kann. Ebenso oft fehlen klare Aussagen zu Subprozessoren, zur Datenresidenz und zur Anbindung an bestehende Systeme. Was als isolierter Pilot startet, wird so zur Neben-IT mit eigener Governance.

Security, Identitäten und Datenresidenz vor dem Pilot

Security-Due-Diligence gehört vor den Pilot, nicht hinter den ersten Produktivnutzer. Orientiert am BSI-Kriterienkatalog C5:2026 – dem Cloud Computing Compliance Criteria Catalogue des Bundesamts für Sicherheit in der Informationstechnik – umfasst ein Mindeststand Rollen- und Rechtekonzept, Verschlüsselung in Transit und at Rest, Logging mit nachvollziehbaren Aufbewahrungsfristen sowie die Klärung, welche personenbezogenen und welche Geschäftsdaten das Startup verarbeitet. Der C5 liefert Cloud-Kunden eine prüfbare Basis für das eigene Risikomanagement und fordert Transparenz zu Standorten, Subdienstleistern und geteilten Verantwortlichkeiten.

Identitäten sind der häufigste Hebel und der häufigste Fehler. Ohne Anbindung an das Konzern-IAM (Identity and Access Management, also die zentrale Verwaltung von Identitäten und Zugriffsrechten) entstehen lokale Accounts, geteilte Passwörter und Orphan-User nach Personalwechseln. Single Sign-On, verpflichtende MFA und ein dokumentierter Offboarding-Pfad sollten im Vertrag und im Betriebskonzept stehen, bevor echte Kundendaten oder Produktionsdaten fließen.

Datenresidenz und Auftragsverarbeitung sind in DACH kein Nachsatz. Die EU-Kommission hat mit dem Durchführungsbeschluss (EU) 2021/915 Standardvertragsklauseln zwischen Verantwortlichen und Auftragsverarbeitern nach Art. 28 DSGVO vorgelegt; sie regeln unter anderem Weisungsbindung, Subprozessoren und den Umgang mit den Daten am Vertragsende. Verarbeitungsorte, Subprozessoren, Speicherort von Backups und die Frage, ob Support-Zugriffe aus Drittstaaten möglich sind, müssen vor dem Pilot schriftlich fixiert sein. Wer das erst im Scale klären will, verhandelt unter Zeitdruck und mit laufendem Fachbetrieb.

API-, Lizenz- und Support-Fallen im Scale

Im Scale scheitern viele Deals an der Schnittstelle. Die Idee bleibt oft tragfähig, die Integration bricht zuerst. Fehlende oder instabile APIs erzwingen manuelle Exporte, Schattenintegrationen und doppelte Datenhaltung. Rate Limits, undokumentierte Felder und Breaking Changes ohne Versionsstrategie machen den Betrieb teuer und das Reporting unzuverlässig. Eine API- und Integrationsprüfung gehört deshalb in die technische Due Diligence vor der Skalierungsfreigabe.

Lizenzfallen zeigen sich oft erst bei Nutzerwachstum. Seat-Modelle, Modul-Bündel, metrikbasierte Preise und Gebühren für Zusatzumgebungen können die ursprünglich kalkulierten Kosten deutlich überschreiten. In SaaS- und Softwareverträgen sind True-up-Klauseln üblich: Der Anbieter stimmt die tatsächliche Nutzung periodisch mit der lizenzierten Menge ab und rechnet Übernutzung nach. Audit-Rechte ergänzen das oft mit Ankündigungsfristen und Kostenübernahme, wenn die Unterlizenzierung eine Schwelle (häufig um 5 bis 10 Prozent) überschreitet. Ebenso kritisch sind Einschränkungen bei der Weitergabe von Nutzungsrechten an Konzerngesellschaften.

Support ist im Scale ein Betriebsrisiko. Reaktionszeiten, Eskalationswege, On-Call-Verfügbarkeit und die Frage, ob der Support nur in Englisch und nur in bestimmten Zeitzonen greift, müssen vor dem Hochfahren geklärt sein. Ohne SLA mit messbaren Zielen und ohne klaren Ansprechpartner bleibt der Fachbereich im Störfall auf dem CIO sitzen, obwohl der Vertrag „Support inklusive“ verspricht.

Exit-Klauseln die wirklich greifen

Ein IT-Exit ist nur so gut wie die operative Umsetzbarkeit. Kündigungsfristen allein reichen nicht. Art. 28 Abs. 3 Buchst. g DSGVO verlangt, dass der Auftragsverarbeiter nach Ende der Verarbeitung personenbezogene Daten nach Wahl des Verantwortlichen löscht oder zurückgibt und bestehende Kopien löscht, soweit keine Aufbewahrungspflicht entgegensteht. Die Standardvertragsklauseln der EU-Kommission (2021/915) greifen das operativ auf. Nötig sind deshalb Fristen und Formate für Datenexport, Vollständigkeit der Datenrückgabe, Löschnachweise und der Umgang mit abgeleiteten Daten sowie mit Logs.

Escrow und Source-Code-Zugriff sind kein Allheilmittel, aber in kritischen Abhängigkeiten ein sinnvolles Instrument. Sinnvoll ist Escrow nur, wenn Auslöser klar definiert sind, der hinterlegte Stand aktuell gehalten wird und die IT intern die Fähigkeit hat, den Code überhaupt zu betreiben. Ohne Build- und Betriebsdokumentation ist Escrow teure Beruhigung.

Übergangsleistungen nach Kündigung entscheiden über den realen Exit. Dazu gehören befristeter Parallelbetrieb, Mitwirkungspflichten des Startups bei der Migration und ein Verbot, den Export künstlich zu erschweren. Ebenso relevant ist die Klärung, wer Schnittstellen und Connectoren nach dem Exit noch warten darf. Wer das nicht vorab regelt, kauft sich einen zweiten Projektfall zur ohnehin laufenden Ablösung.

Scorecard für den CIO-Freigabepunkt

Eine CIO-Scorecard übersetzt die genannten Punkte in eine Freigabelogik vor Pilot und vor Scale. ISO/IEC 27001:2022 verlangt in den Annex-A-Kontrollen A.5.19 bis A.5.22 Prozesse für Informationssicherheit in Lieferantenbeziehungen, Sicherheitsanforderungen in Verträgen, Lieferkettenkontrolle und laufendes Monitoring. Der BSI-C5 gibt Cloud-Kunden ergänzend eine prüfbare Orientierung für Auswahl und Risikosteuerung. Mindestens zu bewerten sind: IAM-Anbindung, Datenklassifikation und Residenz, Security-Basisnachweise, API- und Integrationsreife, Lizenz- und Kostenmodell im Hochlauf, Support- und Betriebsmodell sowie Exit-Fähigkeit inklusive Export und Löschung.

Jeder Punkt braucht einen Owner und einen klaren Status: freigegeben, freigegeben mit Auflagen oder blockiert. Auflagen ohne Termin und ohne Nachweispflicht sind keine Steuerung. Für den Scale-Schritt sollte die Scorecard härter sein als für den isolierten Pilot, weil Nutzerzahl, Datenvolumen und Prozessabhängigkeit steigen.

Die Scorecard bremst Innovation nicht. Sie verhindert, dass Innovationsrhetorik der Fachbereiche IT-Risiken als später lösbar abtut. Der Freigabepunkt des CIO ist der Moment, in dem Tempo und Steuerbarkeit zusammengeführt werden. Fehlt dieser Punkt, entsteht Corporate-Startup-IT ohne belastbare Startup-Due-Diligence und ohne greifende IT-Exit-Klauseln.

Wer Startup-Deals ohne IT-Exit freigibt, kauft Geschwindigkeit auf Kredit. Der Preis zeigt sich später in Schatten-Stacks, Lizenzüberraschungen und Migrationsprojekten unter Druck. Die brauchbare Konsequenz für CIO und CDO ist einfach formuliert: jeder Pilot braucht Security- und Identitätsbasis, jeder Scale braucht API-, Lizenz- und Support-Klarheit, jeder Vertrag braucht einen operativ testbaren Exit.

Häufig gestellte Fragen

Weiterlesen auf Digital Chiefs

Digital ChiefsStandort Deutschland braucht ProduktivitätDigital ChiefsSupply-Chain-IT ohne DatenhoheitDigital ChiefsWAN-Modernisierung: Bandbreite löst nichts

Mehr aus dem MBF Media Netzwerk

cloudmagazin

Wenn GPUs den SaaS-Etat auffressen

mybusinessfuture

KI im Mittelstand vom Pilot zur Skalierung

securitytoday

Der AI Act ist in Wahrheit ein Security-Gesetz

Bildquelle: KI-generiert (Juli 2026)