Die B2B-SaaS-Security-Checkliste, die Enterprise-Kunden wirklich prüfen

Der erste Enterprise-Deal ändert die Spielregeln. Plötzlich ist nicht mehr die Feature-Roadmap der Engpass, sondern ein 40-seitiger Security-Fragebogen. Der Einkauf will SOC-2-Nachweise. Die InfoSec-Abteilung will einen Penetrationstest-Bericht, der weniger als zwölf Monate alt ist. Die Rechtsabteilung will einen unterschriebenen AVV mit einer Liste der Unterauftragsverarbeiter. Der Fürsprecher, mit dem du seit drei Monaten arbeitest, kann den Deal nicht abschließen, bis jede Antwort in einem akzeptablen Bereich landet.

Das ist der Moment, in dem die meisten B2B-SaaS-Startups feststellen, dass ihre Security-Aufstellung nie mit Blick auf Enterprise-Audits gebaut wurde. Die Authentifizierung funktioniert. Daten sind bei der Übertragung verschlüsselt. Aber die zwanzig Controls, nach denen Enterprise-Kunden immer wieder fragen - die, die in SOC 2 Type II, ISO 27001 Annex A und jedem Lieferanten-Security-Fragebogen auftauchen - wurden nie als Infrastruktur behandelt. Sie wurden aufgeschoben.

Dieser Beitrag ist die B2B-SaaS-Security-Checkliste, die Enterprise-Kunden wirklich prüfen. Sie ist um die Kategorien herum aufgebaut, die in echten Security-Fragebögen auftauchen, mit konkreten Hinweisen dazu, wie "umgesetzt" aussieht und wie du es belegst, ohne einen Vollzeit-Security-Engineer auf der Gehaltsliste zu haben.

Warum es die B2B-SaaS-Security-Checkliste überhaupt gibt

Enterprise-Security-Fragebögen sind kein Test, ob dein Produkt im absoluten Sinne sicher ist. Sie sind eine strukturierte Methode für das Security-Team eines Käufers, um zu entscheiden, ob das Hinzufügen deines Produkts zu seiner Umgebung das Gesamtrisiko erhöht oder senkt. Ein SaaS-Anbieter, der Kundendaten speichert, ist per Definition eine neue Angriffsfläche für den Käufer. Der Fragebogen ist der Mechanismus, mit dem der Käufer entscheidet, ob diese Angriffsfläche akzeptabel ist.

Diese Einordnung ist wichtig, weil sie dir sagt, worauf du optimieren solltest. Du versuchst nicht zu beweisen, dass dein Produkt unverwundbar ist - nichts ist das. Du versuchst zu zeigen, dass du einen wiederholbaren, dokumentierten, auditierbaren Satz von Controls hast, der die Wahrscheinlichkeit und die Auswirkung gängiger Fehlerszenarien reduziert. Die folgenden Controls sind die, die Enterprise-Einkaufsteams immer wieder als Stellvertreter für operative Reife heranziehen.

Zugriffsverwaltung (Controls 1-4)

Die Zugriffsverwaltung ist der Ort, an dem die meisten Audits beginnen, weil es die Control-Kategorie mit den gravierendsten Folgen ist, wenn sie versagt. Vier Controls tauchen immer wieder in Fragebögen auf.

1. Rollenbasierte Zugriffskontrolle (RBAC) für interne Admins. Jede SaaS-Anwendung hat eine Control Plane - das Werkzeug, mit dem Engineers Kunden unterstützen, Bugs untersuchen und den Dienst betreiben. Enterprise-Kunden wollen wissen, dass der Zugriff auf diese Ebene rollenbasiert eingeschränkt ist. Ein Support-Engineer sollte nicht in der Lage sein, die gesamte Datenbank irgendeines Mandanten zu exportieren. Eine Entwicklerin im Billing-Team sollte nicht die Nachrichten im Posteingang eines Kunden lesen können. Dokumentiere deine internen Rollen, setze sie auf Anwendungsebene durch und bewahre Logs darüber auf, welche Mitarbeitenden auf die Daten welches Mandanten zugegriffen haben. Setze das nicht mit "Admin" als einzelnem Bit um.

2. Single Sign-On (SSO) für Kundenkonten. Enterprise-Kunden führen kein SaaS-Produkt ein, das ihre Mitarbeitenden zwingt, noch ein weiteres Passwort zu verwalten. Unterstützung für SAML 2.0 und OIDC - angebunden an Azure AD, Okta oder Google Workspace - ist oberhalb des Mid-Markets Pflicht. Unterstütze SSO-Erzwingung auf Mandantenebene (wenn ein Mandant SSO aktiviert, ist die Passwort-Anmeldung für alle Nutzenden deaktiviert) und Just-in-time-Provisionierung von Nutzenden. SCIM-Unterstützung für automatisiertes Deprovisioning wird zunehmend nachgefragt; setze es um, wenn ein Kunde zum ersten Mal danach fragt, und dann erneut, wenn der zweite Kunde fragt.

3. Multi-Faktor-Authentifizierung (MFA) für alle Nutzenden, erzwingbar durch den Mandanten-Admin. Selbst wenn kein SSO im Spiel ist, muss MFA verfügbar sein, und Mandanten-Admins müssen sie verpflichtend machen können. TOTP (Authenticator-Apps) ist akzeptabel; SMS ist es nicht, und ein Auditor wird das als Feststellung vermerken. Unterstützung für WebAuthn / Passkeys ist ein Differenzierungsmerkmal, keine Anforderung.

4. Session-Verwaltung. Sessions müssen widerrufbar sein. Wenn ein Mandanten-Admin einem Mitarbeitenden kündigt, erwartet er, dass aktive Sessions dieses Mitarbeitenden innerhalb von Minuten gekappt werden, nicht erst beim nächsten Token-Ablauf. Setze einen Session-Store ein, der sofortigen Widerruf unterstützt - eine reine JWT-Architektur ohne Sperrliste scheitert an diesem Control.

Audit-Logging und Monitoring (Controls 5-7)

Die Muster für Audit-Logging auf API-Ebene aus unserem B2B-API-Security-Leitfaden decken einen Teil dieser Kategorie ab. Enterprise-Audits erwarten drei verwandte Fähigkeiten.

5. Für Mandanten zugängliche Audit-Logs. Mandanten müssen sehen können, wer in ihrer Organisation was wann getan hat - Anmeldungen, Berechtigungsänderungen, Datenexporte, Konfigurationsänderungen und Integrationsaktivität. Eine Aufbewahrung von zwölf Monaten ist die Standarderwartung; manche regulierten Branchen verlangen länger. Ein Audit-Log, das nur im Datadog-Account deines Infrastrukturteams existiert, erfüllt dieses Control nicht. Mandanten brauchen eine UI oder API, um ihre eigenen Audit-Ereignisse abzurufen.

6. Unveränderlichkeit der Audit-Datensätze. Audit-Logs müssen append-only sein. Wenn der Datenbank-Nutzer der Anwendung DELETE- oder UPDATE-Rechte auf der Audit-Tabelle hat, werden Auditoren das beanstanden. Erzwinge die Unveränderlichkeit entweder auf Datenbankebene mit eingeschränkten Berechtigungen oder leite Audit-Ereignisse an ein Log-Aggregationssystem weiter, in dem die Anwendung vergangene Datensätze nicht verändern kann.

7. Monitoring von Security-Ereignissen. Du musst sicherheitsrelevante Ereignisse erkennen und darauf reagieren können: gehäufte fehlgeschlagene Authentifizierungen, ungewöhnliche Datenexport-Muster, Berechtigungseskalationen, API-Missbrauch. Du brauchst kein vollständiges SOC - du brauchst dokumentierte Erkennungsregeln, ein Runbook für jede Erkennung und den Nachweis, dass Alarme gesichtet werden. Ein Slack-Channel mit Alarmen aus deiner Logging-Plattform, eine gemeinsame Rotation für das Triaging und ein wöchentliches Review-Meeting reichen für frühe Enterprise-Deals aus.

Datenschutz (Controls 8-11)

8. Verschlüsselung bei der Übertragung. TLS 1.2+ überall, mit modernen Cipher-Suites. Enterprise-Kunden scannen deine Endpunkte mit SSL Labs oder einem gleichwertigen Werkzeug; ein A-Rating wird erwartet. HSTS sollte mit einer Preload-Einreichung für deine primäre Domain aktiviert sein.

9. Verschlüsselung im Ruhezustand. Verschlüsselung auf Datenbankebene (zum Beispiel Transparent Data Encryption auf verwaltetem Postgres) ist das Minimum. Verschlüsselung auf Feldebene für besonders sensible Daten - API-Schlüssel, OAuth-Token, personenbezogene Kennungen in regulierten Branchen - wird zunehmend erwartet. Dokumentiere, welche Felder verschlüsselt sind und wie Schlüssel verwaltet werden. "Wir nutzen AWS RDS" ist eine Antwort; "wir verlassen uns auf den zugrunde liegenden Cloud-Anbieter" ist für sich genommen keine Antwort.

10. Schlüsselverwaltung. Verschlüsselungsschlüssel müssen dokumentierte Lebenszyklen haben: Erzeugung, Rotation, Widerruf und Vernichtung. Nutze einen verwalteten Key-Management-Dienst (AWS KMS, GCP KMS, Azure Key Vault), statt Schlüssel in der Anwendungskonfiguration zu speichern. Der auditierbare Nachweis, nach dem Enterprise-Kunden suchen, ist die Rotationshistorie der Schlüssel und die Zugriffslogs des Key-Management-Dienstes selbst.

11. Datentrennung und Mandantenisolation. In einer Multi-Tenant-Architektur müssen Mandantendaten logisch getrennt sein, mit erzwungener Isolation auf Anwendungs- und Datenebene. Die architektonischen Optionen haben wir in Multi-Tenant-SaaS-Architekturmustern, die 2026 skalieren behandelt. Für das Audit kommt es darauf an, dass du das Isolationsmodell präzise beschreiben kannst, zeigst, dass es durch Tests und Code-Reviews durchgesetzt wird, und erklärst, wie ein mandantenübergreifender Zugriff selbst bei Vorliegen eines Anwendungsfehlers verhindert würde.

Schwachstellenmanagement (Controls 12-14)

12. Jährlicher Penetrationstest durch einen unabhängigen Dritten. Ein Penetrationstest, der älter als zwölf Monate ist, ist aus Audit-Sicht veraltet. Der Bericht muss keine null Probleme finden - Auditoren bevorzugen sogar Berichte, die Probleme gefunden und dokumentiert haben, wie diese behoben wurden, weil das ein Beleg dafür ist, dass der Prozess funktioniert. Plane 8.000 bis 25.000 Euro für einen abgegrenzten Pentest einer mittelkomplexen SaaS-Anwendung durch eine seriöse europäische Firma ein.

13. Scanning von Abhängigkeiten auf Schwachstellen. Deine CI-Pipeline muss Abhängigkeiten gegen bekannte CVE-Datenbanken prüfen. Für PHP bedeutet das Werkzeuge wie den audit-Befehl von Composer oder Symfonys security:check. Für JavaScript npm audit oder Snyk. Der audit-würdige Teil ist nicht das Scanning - es ist der dokumentierte Triage-Prozess: Wie schnell behebst du kritische CVEs, und was ist der Nachweis, dass du das tust?

# Minimaler CI-Security-Check für ein Symfony- + Next.js-Projekt
composer audit --locked
npm audit --production --audit-level=high

14. Static Application Security Testing (SAST) und Secret-Scanning. Insbesondere Secret-Scanning ist in Enterprise-Fragebögen mittlerweile nahezu universell, weil die Folge geleakter Zugangsdaten in einem öffentlichen Repository so gravierend ist. GitHub Advanced Security, GitLeaks oder TruffleHog in deiner CI-Pipeline adressieren das. Dokumentiere das Werkzeug, die Scan-Frequenz und den Behebungs-Workflow.

Incident Response und Business Continuity (Controls 15-17)

15. Dokumentierter Incident-Response-Plan. Du musst einen schriftlichen Plan haben, der beschreibt, wie Vorfälle erkannt, eingeordnet, eskaliert, kommuniziert und nachbereitet werden. Der Plan muss nicht lang sein - zwei Seiten können für ein kleines Team ausreichen - aber er muss existieren, er muss Rollen benennen (Incident Commander, Kommunikationsverantwortliche, technische Leitung), und er muss mindestens jährlich durch eine Tabletop-Übung getestet werden. Enterprise-Kunden werden um Einsicht in eine geschwärzte Nachbetrachtung als Nachweis bitten, dass der Plan genutzt wurde.

16. Verfahren zur Meldung von Datenpannen. Nach der DSGVO bist du verpflichtet, betroffene Parteien innerhalb von 72 Stunden nach Kenntniserlangung über eine Verletzung des Schutzes personenbezogener Daten zu informieren. Dein Auftragsverarbeitungsvertrag (AVV) mit Enterprise-Kunden enthält eine Meldeklausel - üblicherweise 24 oder 48 Stunden. Dokumentiere, wie diese Meldung ausgelöst wird, wer sie autorisiert und wie die Kommunikationsvorlage aussieht. Eine unter Zeitdruck während eines laufenden Vorfalls verfasste Meldung ist ein Dokument, das im nächsten Audit Probleme bereitet.

17. Backup und Disaster Recovery. Ziele für die Wiederherstellungszeit (RTO) und den Wiederherstellungspunkt (RPO) müssen dokumentiert und getestet sein. "Wir haben Backups" ist kein Control; "wir führen vierteljährliche Wiederherstellungstests aus externen Backups mit einem dokumentierten RTO von 4 Stunden und einem RPO von 15 Minuten durch" ist ein Control. Teste Wiederherstellungen, halte die Ergebnisse fest und bewahre die Aufzeichnungen für den Auditor auf.

Lieferanten- und Lieferkettenmanagement (Controls 18-19)

18. Liste und Verwaltung der Unterauftragsverarbeiter. Enterprise-Kunden wollen eine Liste jedes Drittdienstes, der ihre Daten verarbeitet: Infrastrukturanbieter, E-Mail-Versender, Analytics-Werkzeuge, Support-Plattformen. Die Liste muss öffentlich zugänglich sein (üblicherweise unter /subprocessors auf deiner Website), und Kunden müssen über Änderungen informiert werden. AVVs enthalten häufig ein Widerspruchsrecht für neue Unterauftragsverarbeiter.

19. Prozess zur Sicherheitsprüfung von Lieferanten. Für jeden Lieferanten, der Kundendaten verarbeitet, musst du vor dessen Onboarding deine eigene Sicherheitsprüfung durchführen - das Einholen des SOC-2-Berichts, des AVV, der Antworten auf den Security-Fragebogen. Dokumentiere den Prüfprozess. Auditoren, die deine Controls prüfen, schauen, ob du auf deine Lieferanten dieselbe Sorgfalt anwendest, die deine Enterprise-Kunden auf dich anwenden.

Governance (Control 20)

20. Informationssicherheits-Managementsystem (ISMS). Das ist das Control, das alle anderen zum Funktionieren bringt. Ein ISMS ist ein dokumentiertes System aus Richtlinien, Verfahren, Rollen und Review-Zyklen, das sicherstellt, dass Security-Controls über die Zeit gepflegt werden. Für ein kleines Team, das SOC 2 oder ISO 27001 anstrebt, liefern Werkzeuge wie Drata, Vanta oder Sprinto das Gerüst für die ISMS-Dokumentation und automatisieren die Beweissammlung aus deinen Cloud- und SaaS-Integrationen. Der Auditor sucht nach Richtlinien zu akzeptabler Nutzung, Zugriffsverwaltung, Change-Management, Incident Response und Business Continuity - mindestens jährlich überprüft und freigegeben, mit Nachweisen über laufenden Betrieb statt einmaliger Erstellung.

Wie du diese B2B-SaaS-Security-Checkliste nutzt

Versuche nicht, alle zwanzig Controls vor deinem ersten Enterprise-Gespräch umzusetzen. Dieser Ansatz verzögert Umsatz und führt oft zu überkonstruierten Controls für ein Unternehmen, dessen Risikoprofil sie noch nicht rechtfertigt. Nutze die Checkliste stattdessen als Werkzeug zur Reihenfolgenbildung.

Beginne mit den Controls, die architektonisch und schwer nachzurüsten sind: Mandantenisolation, Audit-Logging, SSO-Bereitschaft, Session-Verwaltung. Diese werden exponentiell teurer in der Nachrüstung, sobald du zahlende Kunden hast, deren Daten auf der Datenebene vermischt sind. Das Legacy-Code-Optimierungs-Playbook, das wir für Kunden mit ererbter Security-Schuld nutzen, ist genau um diese Reihenfolge herum aufgebaut - zuerst architektonische Controls, dann operative Controls, dann Dokumentations-Controls.

Füge die operativen Controls - Schwachstellen-Scanning, Monitoring, Incident Response, Backup-Tests - hinzu, während du in deine ersten Enterprise-Verkaufszyklen eintrittst. Diese erfordern keine architektonischen Änderungen, aber sie erfordern Teamdisziplin und dokumentierte Nachweise über laufenden Betrieb.

Strebe eine formale Zertifizierung (SOC 2 Type II oder ISO 27001) erst dann an, wenn deine Enterprise-Pipeline die jährlichen Kosten von 25.000 bis 60.000 Euro für Audits und Werkzeuge rechtfertigt. Viele Mid-Market-Deals werden auf Basis einer gut organisierten Antwort auf den Security-Fragebogen plus Nachweisen der obigen Controls abgeschlossen, ohne ein formales Zertifikat. Das Zertifikat wird zur Pflicht, wenn du an Finanzdienstleister, das Gesundheitswesen oder an Käufer ab einer bestimmten Größe verkaufst - nicht vorher.

Security ist eine Umsatzfunktion

Die Teams, die Enterprise-Security-Fragebögen am wirksamsten meistern, sind die, die aufgehört haben, Security als Kostenstelle zu behandeln, und angefangen haben, sie als Umsatzfunktion zu behandeln. Jedes Control auf dieser Liste, sauber umgesetzt und dokumentiert, verkürzt den Verkaufszyklus beim nächsten Enterprise-Deal. Jedes, das fehlt oder halb umgesetzt ist, verlängert ihn.

Käufer in Berlin und im weiteren Europa bringen eine zusätzliche Dimension mit: DSGVO-Konformität, Präferenzen zur Datenresidenz und die kulturelle Erwartung, dass Anbieter Datenschutz ernst nehmen. Die gute Nachricht ist, dass die Umsetzung der obigen Controls die meisten technischen DSGVO-Anforderungen als natürlichen Nebeneffekt abdeckt. Die schlechte Nachricht ist, dass europäische Enterprise-Käufer den Unterschied bemerken zwischen einem Anbieter, der über diese Themen nachgedacht hat, und einem, der improvisiert.

Wenn du dich auf deine erste Enterprise-Security-Prüfung vorbereitest oder gerade jetzt einen Fragebogen abarbeitest, bietet Wolf-Tech fokussierte B2B-SaaS-Security-Reviews als Teil unserer Praxisfelder Code-Quality-Consulting und Tech-Stack-Strategie an - wir gleichen deine aktuelle Umsetzung mit den Controls ab, die Enterprise-Kunden prüfen, identifizieren die Lücken, die am meisten zählen, und ordnen die Arbeit so, dass Umsatz nicht blockiert wird. Kontaktiere uns unter hello@wolf-tech.io oder besuche wolf-tech.io, um zu besprechen, wie ein Review für deinen spezifischen Stack und deine Pipeline aussehen würde.