Der Enterprise-Security-Fragebogen: 50 Kontrollen, die B2B-SaaS-Käufer wirklich prüfen
Irgendwo zwischen der erfolgreichen Demo und dem unterschriebenen Vertrag liegt eine Tabelle mit 200 Zeilen und einer Deadline. Der B2B-SaaS-Security-Fragebogen ist das unglamouröseste Artefakt im Enterprise-Vertrieb und zugleich eines der entscheidendsten. Gründer füllen ihn routinemäßig aus dem Gedächtnis aus, raten bei Antworten, die sie nicht belegen können, und verlieren Deals wegen Widersprüchen, die das Security-Team des Käufers in Minuten findet.
Die gute Nachricht: Fragebögen variieren stark in der Länge, aber nicht in der Substanz. Egal ob der Käufer ein 20-Fragen-Einstiegsblatt, einen CAIQ, ein SIG Lite oder ein 500-zeiliges Eigenmonster schickt: Immer dieselben 50 Kontrollen entscheiden über das Ergebnis. Wenn du diese 50 mit Nachweisen beantworten kannst, beantwortest du fast jeden Fragebogen in Stunden statt in Wochen.
Dieser Beitrag kartiert alle 50, gruppiert so, wie Security-Reviewer sie gruppieren, mit drei Dingen pro Bereich: was der Käufer wirklich prüft, wie ein akzeptabler Mindestnachweis aussieht, und wo eine schriftliche Richtlinie reicht gegenüber den Stellen, an denen du funktionierende Infrastruktur brauchst. Er ergänzt unsere frühere Checkliste mit 20 Kontrollen, die tiefer in die Umsetzung geht; hier geht es darum, den Fragebogen selbst zu überstehen.
So liest du einen B2B-SaaS-Security-Fragebogen
Jede Frage in einem B2B-SaaS-Security-Fragebogen ist ein Stellvertreter für eine einzige zugrunde liegende Frage: Erhöht oder senkt dein Produkt unser Risiko, wenn wir es in unsere Umgebung holen? Reviewer bewerten dich nicht gegen Perfektion. Sie prüfen, ob deine Antworten untereinander konsistent sind, ob sie zu deiner öffentlichen Dokumentation passen, und ob du sie auf Nachfrage mit Nachweisen unterlegen kannst.
Der letzte Punkt wiegt am schwersten. Ein "Ja" ohne Nachweis wird als "unbekannt" gewertet. Ein ehrliches "teilweise, mit Behebungstermin" schneidet besser ab als ein selbstbewusstes "Ja", das im Folgetelefonat auseinanderfällt. Behalte das für alle 50 Kontrollen im Hinterkopf.
Zugriffskontrolle und Identität (Kontrollen 1-10)
Hier fangen Reviewer an, weil Fehler bei Zugriffen die direktesten Folgen haben.
| # | Kontrolle | Was der Käufer wirklich prüft |
|---|---|---|
| 1 | SSO-Unterstützung (SAML/OIDC) | Ob sie deine App über ihren Identity Provider steuern können |
| 2 | MFA für alle Mitarbeitenden erzwungen | Ob ein gephishtes Passwort ihre Daten kompromittiert |
| 3 | Rollenbasierte Zugriffskontrolle im Produkt | Least Privilege für ihre eigenen Nutzer |
| 4 | RBAC für deine internen Systeme | Least Privilege für deine Entwickler |
| 5 | Dokumentierter Joiner/Mover/Leaver-Prozess | Behalten Ex-Mitarbeitende Zugriff |
| 6 | Quartalsweise Zugriffsprüfungen | Ob Berechtigungen still auseinanderdriften |
| 7 | Privileged Access Management | Wer Produktion anfassen darf und wie das protokolliert wird |
| 8 | Keine geteilten Accounts | Zuordnung jeder Aktion zu einer Person |
| 9 | Session-Management (Timeouts, Widerruf) | Schadensradius gestohlener Sessions |
| 10 | SCIM oder Deprovisioning-API | Automatisiertes Offboarding ihrer Nutzer |
Mindestnachweis: eine Zugriffskontroll-Richtlinie, ein Screenshot oder Export deiner letzten Zugriffsprüfung und eine IdP-Konfiguration, die erzwungene MFA zeigt. Die Kontrollen 1, 2, 5 und 6 müssen tatsächlich umgesetzt sein; ein Richtliniendokument allein übersteht die Nachfrage nicht. SCIM (Kontrolle 10) lässt sich bei mittelgroßen Deals häufig auf eine Roadmap-Antwort verhandeln.
Datenhandhabung und Verschlüsselung (Kontrollen 11-19)
| # | Kontrolle | Was der Käufer wirklich prüft |
|---|---|---|
| 11 | Verschlüsselung während der Übertragung (TLS 1.2+) | Grundvoraussetzung; ein "Nein" beendet die Prüfung |
| 12 | Verschlüsselung ruhender Daten | Risiko bei kompromittiertem Speicher |
| 13 | Key-Management und Rotation | Ob Verschlüsselung echt oder dekorativ ist |
| 14 | Datenklassifizierungs-Richtlinie | Weißt du, welche Daten du hältst |
| 15 | Optionen zur Datenresidenz | DSGVO und Branchenregeln, besonders in der EU |
| 16 | Modell der Mandantentrennung | Kann ein anderer Kunde ihre Daten sehen |
| 17 | Aufbewahrungs- und Löschfristen | Wie lange ihre Daten den Vertrag überleben |
| 18 | Verifizierte Löschung beim Offboarding | Ob "gelöscht" auch Backups einschließt |
| 19 | Produktivdaten in Nicht-Produktivumgebungen | Ob Staging echte Datensätze preisgibt |
Mindestnachweis: Deine TLS-Konfiguration ist von außen prüfbar, erwarte also, dass sie sie kontrollieren, bevor sie fragen. Für den Rest: eine Richtlinie zur Datenhandhabung, eine Architekturnotiz zur Mandantentrennung und ein Lösch-Runbook. Kontrolle 18 ist die, bei der die meisten Anbieter auffliegen, weil Löschen aus Backups Engineering-Arbeit erfordert und keine Richtlinie. Wenn deine Löschgeschichte schwach ist, deckt unser Beitrag zum Recht auf Löschung in der Praxis die Muster ab, die standhalten.
Sichere Entwicklung und Change Management (Kontrollen 20-27)
| # | Kontrolle | Was der Käufer wirklich prüft |
|---|---|---|
| 20 | Code Review vor dem Merge verpflichtend | Ob ein einzelner Entwickler ungeprüften Code ausliefern kann |
| 21 | CI-Pipeline mit automatisierten Tests | Wiederholbarkeit von Releases |
| 22 | Statische Analyse / SAST in der Pipeline | Systematische Fehlerklassen vor Produktion abfangen |
| 23 | Dependency-Scanning und Patch-SLAs | Log4j-artige Exposition |
| 24 | Secrets-Management (keine Secrets im Code) | Der häufigste reale Angriffsvektor |
| 25 | Trennung von Dev- und Prod-Umgebungen | Schadensradius von Entwicklerfehlern |
| 26 | Dokumentiertes Change Management | Sind Änderungen nachvollziehbar und rücknehmbar |
| 27 | Jährlicher Penetrationstest | Unabhängige Validierung, Bericht jünger als 12 Monate |
Mindestnachweis: Branch-Protection-Einstellungen, eine CI-Konfiguration, ein Dependency-Scanning-Report und die Management Summary deines letzten Pentests. Reviewer akzeptieren eine geschwärzte Pentest-Zusammenfassung plus Status der Behebung; den vollständigen Bericht brauchen sie nicht. Die Kontrollen 20-25 müssen echte Infrastruktur sein. Das ist auch der Bereich, in dem eine schnell gewachsene oder weitgehend KI-generierte Codebasis still durchfällt: Der Fragebogen sagt "ja, Code Review", die Git-Historie sagt etwas anderes. Ein unabhängiges Code-Quality-Audit, bevor der Fragebogen eintrifft, ist deutlich günstiger als ein unangenehmes Folgegespräch danach.
Incident Response und Logging (Kontrollen 28-34)
| # | Kontrolle | Was der Käufer wirklich prüft |
|---|---|---|
| 28 | Schriftlicher Incident-Response-Plan | Improvisierst du während eines Vorfalls |
| 29 | SLA für Breach-Meldung an Kunden | Erfahren sie es von dir oder aus der Presse |
| 30 | Zentrales Anwendungs- und Audit-Logging | Lassen sich Vorfälle rekonstruieren |
| 31 | Log-Aufbewahrungsdauer (typisch 12 Monate) | Forensische Tiefe |
| 32 | Alarmierung bei auffälligen Zugriffen | Erkennung, nicht nur Aufzeichnung |
| 33 | Jährliche IR-Übung oder Tabletop | Ob der Plan je erprobt wurde |
| 34 | Statusseite oder Verfügbarkeitskommunikation | Operative Transparenz |
Mindestnachweis: der IR-Plan selbst, eine Meldeklausel in deinem AV-Vertrag (72 Stunden sind die übliche Forderung; versprich nicht weniger, als du halten kannst) und ein Auszug aus deinem Logging-Dashboard. Kontrolle 33 lässt sich mit einer einseitigen Tabletop-Zusammenfassung erfüllen; führe eine in diesem Quartal durch, falls noch nie geschehen. Die Kontrollen 28, 29 und 34 sind als Dokumente akzeptabel. Die Kontrollen 30-32 erfordern Tooling.
Business Continuity, Backup und Recovery (Kontrollen 35-40)
| # | Kontrolle | Was der Käufer wirklich prüft |
|---|---|---|
| 35 | Automatisierte Backups mit definierter Frequenz | Fenster für Datenverlust |
| 36 | Getestete Wiederherstellung | Ob Backups sich wirklich zurückspielen lassen |
| 37 | Dokumentierte RTO und RPO | Ehrliche Erwartungen an die Wiederherstellung |
| 38 | Disaster-Recovery-Plan | Überleben eines regionalen Ausfalls |
| 39 | Uptime-SLA und historische Verfügbarkeit | Bilanz gegenüber Versprechen |
| 40 | Bewertung von Single Points of Failure | Bus-Faktor in Infrastruktur und Team |
Mindestnachweis: Backup-Konfiguration, Datum und Ergebnis deines letzten Restore-Tests und eine einseitige DR-Zusammenfassung mit RTO/RPO-Zahlen. Kontrolle 36 ist die Falle: "Wir haben Backups" ohne getestete Wiederherstellung wird von erfahrenen Reviewern als "keine Backups" gewertet. Wähle realistische RTO/RPO-Werte; ein kleines Team, das 15 Minuten RTO behauptet, wirkt unseriös.
Drittparteien- und Subprozessor-Risiko (Kontrollen 41-46)
| # | Kontrolle | Was der Käufer wirklich prüft |
|---|---|---|
| 41 | Veröffentlichte Subprozessor-Liste | Wohin ihre Daten tatsächlich fließen |
| 42 | Prozess zur Lieferanten-Sicherheitsprüfung | Ob du deine eigenen Dienstleister prüfst |
| 43 | AV-Verträge mit allen Subprozessoren | Die rechtliche Kette der Datenverantwortung |
| 44 | Benachrichtigung bei Subprozessor-Wechsel | Vertragliches Widerspruchsrecht |
| 45 | Bewusstsein für Konzentrationsrisiko | Was passiert, wenn dein Cloud-Anbieter ausfällt |
| 46 | Open-Source-Lizenz- und SBOM-Hygiene | Rechtliche und Lieferketten-Exposition |
Mindestnachweis: die Subprozessor-Seite auf deiner Website, eine einfache Checkliste zur Lieferantenprüfung und ein SBOM-Export aus deinem Build-Tooling. Dieser gesamte Abschnitt lässt sich mit Dokumenten und einer Tabelle abdecken; er bringt pro investierter Stunde die meisten Punkte. EU-Käufer fragen wegen der Lieferkettenregeln zunehmend nach SBOMs, ein SBOM jetzt aus der CI zu generieren erspart später Hektik.
Compliance und organisatorische Sicherheit (Kontrollen 47-50)
| # | Kontrolle | Was der Käufer wirklich prüft |
|---|---|---|
| 47 | SOC 2 Type II oder ISO 27001 | Unabhängige Bestätigung oder ein glaubwürdiger Weg dorthin |
| 48 | Security-Awareness-Schulungen für alle | Die menschliche Ebene |
| 49 | Hintergrundprüfungen, wo rechtlich zulässig | Grundlagen des Insider-Risikos |
| 50 | Benannte Sicherheitsverantwortung | Jemand ist zuständig, wenn es darauf ankommt |
Mindestnachweis: Zertifizierungsbericht oder eine datierte Roadmap dorthin, Nachweise über abgeschlossene Schulungen und eine Organisationsnotiz, die deine Sicherheitsverantwortung benennt. Ein fehlendes SOC 2 killt Mid-Market-Deals nicht automatisch, wenn die anderen 49 Kontrollen stark sind und du einen Audit-Zeitplan zeigen kannst. "Wir sind in unserem Observation Window, das Audit ist für Q1 terminiert" ist eine echte Antwort; "wir schauen uns das an" ist keine.
Baue das Evidence Pack einmal und beantworte jeden Fragebogen schnell
Teams, die Fragebögen in Stunden drehen, machen alle dasselbe: Sie pflegen ein lebendes Evidence Pack, statt die Antworten pro Deal neu zusammenzusuchen. Die Struktur ist simpel:
- Ein Ordner pro Kontrollbereich (die sieben Abschnitte oben), jeweils mit aktueller Richtlinie, neuestem Nachweis und dessen Prüfdatum.
- Ein zentrales Antwortblatt, das die 50 Kontrollen auf deine kanonischen Antworten abbildet, mit Links zu den Nachweisen. Neue Fragebögen werden auf dieses Blatt gemappt, nicht von Grund auf beantwortet.
- Ein vierteljährliches Auffrischungsritual: Zugriffsprüfung erneut durchführen, Zertifikats- und Pentest-Daten kontrollieren, Subprozessor-Liste aktualisieren, SBOM neu exportieren. Ein Nachmittag pro Quartal.
- Ein Lückenregister, das jede "teilweise"-Antwort mit Verantwortlichem und Zieldatum führt. Käufer reagieren gut auf ehrlich benannte Lücken mit Terminen; sie reagieren schlecht darauf, Lücken selbst zu entdecken.
Versioniere das Pack nach Möglichkeit in Git neben deinem Code. Nachweise mit Commit-Historie überzeugen mehr als ein Ordner undatierter PDFs.
Wo du anfängst, wenn gerade ein Fragebogen vor dir liegt
Triagiere in dieser Reihenfolge: Beantworte zuerst die von außen prüfbaren Kontrollen (TLS, Statusseite, Subprozessor-Liste), weil Käufer diese unabhängig kontrollieren. Dann die Abschnitte zu Zugriff und Verschlüsselung, die am schwersten wiegen. Markiere alles, was du nicht belegen kannst, als "teilweise, Behebung geplant", statt ein Ja zu dehnen.
Wenn der Fragebogen tiefere Probleme offengelegt hat, etwa fehlende Code-Review-Kultur, Secrets im Repository oder eine Codebasis, die niemand vollständig versteht, ist das kein Papierproblem. Wolf-Tech führt Code-Quality- und Security-Audits durch, die genau die unabhängigen Nachweise erzeugen, die Enterprise-Reviewer sehen wollen, und wir schließen im Rahmen von Custom Software Development die Engineering-Lücken hinter den Antworten.
Steht dir eine Sicherheitsprüfung bevor, bei der du dir nicht sicher bist? Schreib an hello@wolf-tech.io oder besuche wolf-tech.io, und wir helfen dir herauszufinden, welche der 50 Kontrollen echte Arbeit brauchen und welche nur bessere Nachweise.