Security-Fragebogen vom Großkunden: So vermeiden Sie Chaos
Wer jeden Compliance-Standard als Einzelprojekt behandelt, verschwendet Zeit und riskiert Deals. Ein zentrales Fundament für Nachweise und Controls löst das Problem strukturell.
Der erste große Enterprise-Kunde steht kurz vor dem Vertragsabschluss. Dann landet ein Security-Fragebogen im Postfach: 200 Fragen zu Zugriffskontrollen, Datenschutz, Incident-Prozessen und Zertifizierungen. Das Team sucht Antworten aus fünf verschiedenen Tools und drei Ordnerstrukturen zusammen. Der Deal wartet. Solche Situationen sind kein Einzelfall, sie sind ein Strukturproblem.
Was Enterprise-Kunden wirklich wollen
Große Kunden prüfen keine Frameworks. Sie prüfen Kontrolle und Nachweis. Die Kernfragen ähneln sich bei fast jedem Fragebogen: Wer darf auf welche Systeme zugreifen? Welche Dienstleister verarbeiten Kundendaten? Wie werden Sicherheitsvorfälle behandelt? Welche technischen und organisatorischen Maßnahmen sind konkret umgesetzt?
Bei kleineren Aufträgen reicht oft eine Selbstauskunft. Bei Enterprise-Kunden kommen formale Zertifizierungen hinzu. ISO 27001 für allgemeine Informationssicherheit, TISAX für Automotive-Zulieferer, SOC 2 für den US-Markt. Dazu kommen regulatorische Vorgaben wie NIS2, DORA oder der EU AI Act, die bestimmte Branchen direkt betreffen.
Die inhaltlichen Anforderungen überschneiden sich dabei stark. Ein Berechtigungskonzept, das für ISO 27001 dokumentiert wurde, beantwortet auch Fragen in einem SOC-2-Audit. Ein Incident-Prozess gilt für NIS2 ebenso wie für TISAX.
Das eigentliche Problem heißt Doppelarbeit
Die meisten kleinen Unternehmen haben kein Compliance-Problem. Sie haben ein Wiederverwendungsproblem. Datenschutz liegt bei Legal, das Informationssicherheits-Managementsystem bei der IT, Richtlinien in SharePoint, technische Dokumentation bei den Entwicklern. Jedes neue Framework wird als separates Projekt behandelt. Controls werden neu beschrieben, Nachweise erneut gesucht, Verantwortlichkeiten mehrfach festgehalten.
Aus der Softwareentwicklung kennt man dieses Muster: Technical Debt. Gleiche Logik existiert mehrfach, ohne zentrale Quelle. Wird ein Prozess geändert, aber nur an einer Stelle aktualisiert, tauchen beim nächsten Audit widersprüchliche Versionen auf. Das kostet Zeit und gefährdet Zertifizierungen.
Ein zentrales Fundament statt Parallelstrukturen
Die Lösung ist eine einzige Quelle für alle Nachweise und Controls, in der Fachsprache auch Single Source of Truth genannt. Ein Control wird einmal beschrieben und einmal gepflegt. Dann wird festgehalten, welche Framework-Anforderungen damit abgedeckt sind. Kommt ein neues Framework hinzu, analysiert man nur noch die Lücken. Man beginnt nicht bei null.
Dieses Vorgehen verändert den Aufwand erheblich. Der erste Security-Fragebogen braucht viel Zeit, weil alles aufgebaut wird. Der zweite geht schneller, weil die Basis steht. Ab dem dritten wird es zur Routine.
Was Software übernehmen kann
Software-Tools eignen sich gut für das automatische Mapping zwischen Frameworks. Sie erkennen, welche Controls eine ISO-27001-Anforderung und gleichzeitig eine NIS2-Vorgabe abdecken. Sie helfen bei der Gap-Analyse: Was fehlt noch, um einen neuen Standard zu erfüllen? Und sie erzwingen eine einheitliche Dokumentationsstruktur, die Audits standhält.
Was Software nicht leistet: Sie ersetzt keine fachliche Bewertung. Ob NIS2 bei einer bestimmten Unternehmensstruktur greift oder wie der Scope einer ISO-Zertifizierung gezogen werden sollte, bleibt eine Entscheidung von Fachleuten. Tools schaffen Struktur und reduzieren Routinearbeit. Strategische Fragen bleiben Chefsache oder Aufgabe externer Berater.
Was das für kleine Unternehmen bedeutet
Für Unternehmen mit weniger als zwanzig Mitarbeitern gilt: Der Aufbau eines zentralen Compliance-Fundaments lohnt sich ab dem Moment, in dem regelmäßig Fragebögen von Kunden eintreffen oder eine erste Zertifizierung ansteht. Wer das verschleppt, zahlt später mit dem Mehrfachen an Aufwand.
Ein konkreter erster Schritt: Alle vorhandenen Dokumente zu Zugriffsrechten, Datenschutz, Incident-Handling und Lieferantenmanagement an einem Ort zusammenführen. Nicht in einem neuen Tool, notfalls in einem strukturierten Ordner. Dann prüfen, welche Kundenanfragen und Frameworks die eigene Situation tatsächlich betreffen, und erst dann entscheiden, ob spezialisierte Software sinnvoll ist.
Fazit
Compliance-Nachweise sind kein Selbstzweck. Sie entscheiden in Enterprise-Vertriebsprozessen darüber, ob ein Deal zustande kommt. Wer Doppelarbeit vermeiden will, braucht kein neues Projekt für jedes neue Framework, sondern eine Struktur, die einmal erarbeitete Controls mehrfach verwertbar macht. Das ist keine Frage der Unternehmensgröße, sondern der Organisation.
