Was B2B-SaaS-Gründer beim ersten Enterprise-Sicherheitsreview lernen

Ein B2B-SaaS-Gründer schließt seinen ersten Enterprise-Deal mündlich ab. Der Champagner wird geöffnet. Zwei Wochen später kommt der Sicherheitsfragebogen, drei Wochen danach das Legal-Review — und irgendwo in Woche sechs wird der dem Geiste nach abgeschlossene Deal neu verhandelt, verschoben oder stillschweigend verloren. Der Gründer verbringt das nächste Quartal damit, die Dinge nachzurüsten, die der Fragebogen zutage gefördert hat.

Das ist so vorhersehbar, dass es zu einer Phase im Leben eines SaaS-Unternehmens geworden ist. Die Gründer, die es überleben, lernen dieselben Lektionen. Die, die es nicht überleben, lernen sie trotzdem — nur teurer.

Was der Fragebogen wirklich fragt

Ein vierzigseitiger Sicherheitsfragebogen von einem Fortune-500-Käufer fühlt sich wie ein erschöpfendes technisches Audit an. Das ist er nicht. Er stellt eine viel einfachere Frage: Wenn unser Sicherheitsteam diesen Kauf vor unserem CISO verteidigen muss — kann es das?

Die Fragen drehen sich nicht wirklich um die Antworten. Sie drehen sich darum, ob ihr nachgedacht habt, ob die Antworten konsistent sind und ob eure Haltung der Ernsthaftigkeit der Daten entspricht, die ihr halten würdet. Ein Fragebogen mit leeren Feldern fällt durch. Ein Fragebogen mit selbstsicheren, spezifischen, intern konsistenten Antworten besteht — auch wenn manche Antworten lauten: "Wir tun das derzeit nicht, und hier ist unsere Roadmap dazu."

Das bedeutet: Der Gründer, der den Fragebogen als Test behandelt, der bestanden werden muss, verpasst den Punkt. Der Fragebogen ist ein Gespräch. Der Käufer fragt, ob er euch seine Daten anvertrauen kann und ob sein Sicherheitsteam die Entscheidung verteidigen kann, euch zu vertrauen.

Die fünf Punkte, die immer auftauchen

Über genug Enterprise-Deals hinweg tauchen dieselben fünf Punkte in fast jedem Fragebogen auf — und das sind dieselben fünf, auf die SaaS-Gründer normalerweise nicht vorbereitet sind.

SSO via SAML oder OIDC, mit SCIM-Provisionierung. Das IT-Team des Käufers möchte keine einzelnen Accounts in eurem Produkt verwalten. Es will Benutzer über seinen Identity Provider provisionieren und den Zugriff darüber steuern. Ohne SSO gibt es kein Enterprise-Tier. SCIM — automatisches Deprovisionieren, wenn ein Mitarbeiter das Unternehmen verlässt — ist die nächste Anforderung, und sie ist nicht verhandelbar für jeden Käufer mit einer nennenswerten Belegschaft.

Audit-Logs, auf die der Kunde zugreifen kann. Nicht "wir haben Audit-Logs auf unserer Seite." Der Kunde will seine Audit-Logs, in seinem SIEM, abfragbar durch sein Team. Das wird meist als Anforderung formuliert: "Events an unser Security-Tool senden." Ohne das kann der Käufer keine eigene Incident-Untersuchung gegen euer Produkt durchführen — was bedeutet, er kann euch für nichts Sensibles nutzen.

Eine vertretbare Antwort zur Multi-Tenancy. "Sind unsere Daten von denen eurer anderen Kunden getrennt?" Die ehrlichen Antworten lauten meist: "Ja, logisch, in einer gemeinsamen Datenbank mit Tenant-Scoping auf Anwendungsebene." Das ist in Ordnung — wenn ihr es selbstbewusst erklären und die Controls belegen könnt. Was durchfällt: der Gründer, der in Panik gerät, die Isolierung übertreibt und auf Folgefragen inkonsistente Antworten liefert. Selbstbewusstsein bei einer moderaten Haltung schlägt Handwaving über eine starke.

Datenresidenz und -export. Wo liegen die Daten? Kann der Kunde sie herausbekommen? Was passiert bei Kündigung damit? Diese Fragen sind im Fragebogen kurz und in der Praxis groß. Viele SaaS-Architekturen gehen davon aus, dass die Daten für immer in einer Cloud-Region liegen und der Kunde nie wechselt. Beide Annahmen scheitern im Enterprise-Deal.

Transparenz über Unterauftragsverarbeiter. Jeder Anbieter, den ihr nutzt und der Kundendaten berührt, muss offengelegt werden. Stripe, Twilio, OpenAI, Datadog, jeder KI-Anbieter. Der Kunde liest diese Liste, und einer davon wird aus kundespezifischen Gründen inakzeptabel sein. Ihr müsst bereit sein, Alternativen zu diskutieren, oder ihr braucht eine glaubwürdige Antwort, warum die Abhängigkeit nicht entfernt werden kann.

Die Reihenfolge, in der man sie aufbaut

Wenn ihr noch vor dem Enterprise-Markt steht und euch vorbereiten wollt, kommt es auf die Reihenfolge an. Alle fünf gleichzeitig zu bauen ist für die meisten Teams unrealistisch; in der falschen Reihenfolge zu bauen hinterlässt euch mit unangenehm unvollständiger Abdeckung.

Die Reihenfolge, die in unseren SaaS-Projekten funktioniert hat:

Zuerst Audit-Logs, weil sie leicht nachzurüsten, aber unmöglich rückwirkend aufzufüllen sind, wenn man wartet. Jede Aktion im System sollte von Anfang an mit Akteur, Ziel, Aktion, Zeitstempel und IP geloggt werden. Das werdet ihr euch später danken.

Zweitens SSO, weil es die Frage ist, die in Enterprise-Gesprächen am häufigsten zuerst auftaucht — und die am längsten braucht, um sauber nachgerüstet zu werden. Mit SAML und OIDC bauen. SCIM kann warten, bis zwei Enterprise-Kunden danach fragen, aber das SSO-Fundament muss stehen.

Drittens Rigorosität im Multi-Tenant-Datenmodell, weil das später am schwersten zu ändern ist. Wenn eure Tenant-Isolierung unsauber ist, jetzt beheben. Wenn sie sauber ist, klar dokumentieren, damit ihr sie im Fragebogen verteidigen könnt.

Viertens das Unterauftragsverarbeiter-Inventar, weil es leicht zusammenzustellen und fast immer gefragt ist. Als lebendiges Dokument pflegen. Neuer Anbieter? Kommt auf die Liste und wird geprüft.

Fünftens Datenresidenz und -export, weil das am ehesten aufgeschoben wird. Selbst ein manuelles, betreutes "Exportiert eure Daten auf Anfrage innerhalb von 30 Tagen"-Verfahren reicht für viele Käufer — und ist weit besser als die stillschweigende Antwort "Wir haben eigentlich keinen Prozess dafür."

Die tiefere Lektion

Der Fragebogen ist nicht das Hindernis. Das Hindernis ist, dass Enterprise-Kunden nicht nur euer Produkt kaufen, sondern eine vertretbare Entscheidung, euer Produkt zu nutzen. Die oben genannten Features existieren, um diese Entscheidung vertretbar zu machen.

Ein Gründer, der das verinnerlicht, hört auf, Enterprise-Procurement zu fürchten, und beginnt, es als Design-Constraint zu nutzen, der das Produkt auf gesunde Weise formt. SSO ist sowieso das Richtige zu bauen. Audit-Logs machen euer Support-Team besser. Datenexport ist das Richtige für Kunden. Das Procurement-Gate tut euch in gewissem Sinne einen Gefallen, indem es die Frage erzwingt.

Es fühlt sich nur selten wie ein Gefallen an, während man den Fragebogen ausfüllt.