Ich habe ein Unternehmen mit einem Palo-Alto-ausgestatteten SOC durch ein Audit fallen sehen, während ein Wettbewerber mit einfachen Firewalls glatt durchkam. Gleiche Branche, ähnliche Budgets, gegensätzliche Ergebnisse. Nach fünfzehn Jahren und Hunderten von Assessments — TISAX für Automobilzulieferer, PCI-DSS für Händler, ISO 27001 für Hersteller, NIS2-Readiness für fast jeden — überrascht mich das nicht mehr.
Die Lektionen, die das erklären, stehen in keinem Framework und in keinem Zertifizierungsleitfaden. Es geht darum, was wirklich zählt, was nicht, und warum manche Organisationen mühelos durch Audits gleiten, während andere kämpfen, obwohl sie mehr für Sicherheit ausgeben.
Das sind die Dinge, die mir am Anfang jemand hätte sagen sollen. Sie prägen, wie ich heute arbeite — und sie sind der Grund, warum ich schließlich Werkzeuge gebaut habe, um die Probleme zu beheben, die ich immer wieder sah.
Lektion 1: Dokumentation schlägt Technologie
Die kontraintuitivste Lektion: Starke Sicherheit fällt oft durch Audits, schwache Sicherheit besteht sie oft. Der Unterschied ist die Dokumentation.
Ich habe Palo-Alto-ausgestattete SOCs an TISAX-Assessments scheitern sehen, weil sie keine Änderungsnachweise vorlegen konnten. Ich habe Unternehmen mit einfachen pfSense-Firewalls ISO 27001 bestehen sehen, weil jede Entscheidung dokumentiert, begründet und nachvollziehbar war.
Auditoren können nicht bewerten, was sie nicht sehen. Ihre Kontrollen mögen exzellent sein — aber ohne Nachweise, um sie zu belegen, fallen Sie durch. Wie die BSI-Leitlinien klarmachen, zählt der Audit-Nachweis ebenso viel wie die Kontrollen selbst.
Das ist nicht Dokumentation statt Substanz. Es ist Dokumentation von Substanz. Bauen Sie gute Sicherheit und dokumentieren Sie sie. Das eine ohne das andere fällt durch.
Lektion 2: Compliance ist ein Boden, keine Decke
Früh in meiner Laufbahn dachte ich, Compliance bedeute Sicherheit. Audit bestanden, also sicher. Durchgefallen, also nicht.
Die Erfahrung lehrte mich etwas anderes. Frameworks setzen den minimal akzeptablen Standard. Sie zu erfüllen, macht Sie compliant, nicht sicher. Viele kompromittierte Organisationen waren am Tag der Verletzung vollständig compliant.
Compliance ist der Startpunkt, nicht das Ziel. Die besten Organisationen, mit denen ich gearbeitet habe, behandeln Frameworks als Fundament zum Daraufbauen, nicht als Checklisten zum Abhaken.
Compliance ohne Verständnis von Sicherheit zu jagen, schafft gefährliche Scheinsicherheit. Sie können jedes Kästchen ankreuzen und trotzdem exponiert sein. Die ENISA-Lageberichte sind voll von Organisationen, die compliant waren und trotzdem kompromittiert wurden.
Lektion 3: Prozesse vor Produkten
Anbieter verkaufen Produkte. Frameworks verlangen Prozesse. Die Lücke dazwischen verursacht die meisten Fehlschläge.
Ich habe Unternehmen jedes Tool aus dem Gartner Magic Quadrant kaufen und trotzdem scheitern sehen. Werkzeuge ohne Prozess sind nur teure Ausrüstung. Prozesse mit bescheidenen Werkzeugen bestehen oft.
Ein SIEM für 50.000 €, das niemand überwacht, ist weniger wert als ein Log-Aggregator für 5.000 € mit definierten Prüfverfahren. Das Werkzeug zählt nicht, wenn der Prozess fehlt.
Assessments konzentrieren sich auf Prozessnachweise: Wie erkennen Sie Bedrohungen, was passiert dann, wer ist verantwortlich, und woher wissen Sie, dass es funktioniert? Produkte unterstützen diese Prozesse; sie ersetzen sie nicht.
Lektion 4: Kontinuierlich schlägt jährlich
Das traditionelle Modell: hektisch aufs Jahresaudit vorbereiten, bestehen, elf Monate lang Sicherheit ignorieren, wiederholen. Dieses Modell stirbt.
Moderne Frameworks wie NIS2 setzen kontinuierliche Compliance voraus. Auditoren tauchen zunehmend unangekündigt auf. Meldepflichten für Vorfälle bedeuten, dass Sie Probleme nicht bis zum nächsten Zyklus verbergen können.
Organisationen, die Compliance in den Tagesbetrieb einfalten — Sicherheit als normale Arbeit, nicht als Sonderprojekt — fahren langfristig besser. Sie haben keine „Audit-Saison“, weil jeder Tag auditbereit ist.
Kontinuierliche Compliance kostet außerdem weniger. Der Vor-Audit-Wirbel aus Überstunden, Beratern und Notfall-Fixes entfällt. Laut Branchenuntersuchungen senkt das die Gesamt-Auditkosten um 30–40 %.
Lektion 5: Menschen sind der Engpass
Technische Kontrollen sind einfach. Menschen sind schwer. Jedes gescheiterte Audit, das ich untersucht habe, ließ sich auf menschliche Faktoren zurückführen: Schulungslücken, unklare Verantwortlichkeiten, Prozessbrüche oder schlichte Fehler.
Der Ingenieur, der das Change-Management „nur dieses eine Mal“ umging. Der Manager, der ohne Lesen freigab. Das Team, das vergaß, eine Notfalländerung zu dokumentieren. Menschen, nicht Technologie, verursachen Compliance-Fehler.
Programme, die gelingen, investieren stark in Menschen: klare Rollen, praxisnahe Schulung und Prozesse, die vernünftig genug sind, dass Menschen sie tatsächlich befolgen. Werkzeuge sollten Urteilsvermögen unterstützen, nicht ersetzen.
Ich entwerfe für die menschliche Natur, nicht gegen sie. Ein umständlicher Prozess wird umgangen. Machen Sie also das Richtige zum Einfachen.
Lektion 6: Risikobasiertes Denken gewinnt
Checklisten-Compliance — jede Anforderung als gleich zu behandeln — verschwendet Ressourcen und übersieht die echten Risiken. Die besten Programme sind risikobasiert: mehr Investition, wo das Risiko höher ist, weniger, wo es niedriger ist.
ISO 27001 verlangt ausdrücklich einen risikobasierten Ansatz, und NIS2 folgt demselben Prinzip. Auditoren erwarten, dass Sie erklären, warum Sie eine Kontrolle umgesetzt haben, nicht nur dass Sie es taten.
„Wir haben diese Kontrolle umgesetzt, weil unsere Risikobewertung Bedrohung X für Asset Y mit Auswirkung Z identifiziert hat“ ist eine bestehende Antwort. „Wir haben sie umgesetzt, weil das Framework es sagte“ ist es nicht.
Compliance sollte aus der Risikobewertung folgen, nicht umgekehrt. Verstehen Sie zuerst Ihre Risiken, dann wählen Sie Kontrollen, die sie adressieren. Das Framework ist ein Werkzeug, kein Ersatz fürs Denken.
Lektion 7: Die Führung gibt den Ton an
Sicherheitskultur kommt von oben. Wenn Führungskräfte Compliance als zu minimierenden Kostenfaktor behandeln, zieht die Organisation nach. Wenn sie Sicherheit als Geschäftsermöglicher behandeln, ändert sich alles.
Die stärksten Programme, die ich gesehen habe, hatten sichtbare Unterstützung der Führung: Berichterstattung auf Vorstandsebene, Sicherheit als ständiger Tagesordnungspunkt und Budgets, die zu den erklärten Prioritäten passten.
NIS2 macht das mit Haftungsbestimmungen für die Geschäftsleitung explizit. Aber das Prinzip galt schon immer: Ein Programm steht und fällt mit dem Engagement der Führung.
Wenn Sie mit der Sicherheitskultur ringen, schauen Sie zuerst auf das Verhalten der Führung. Lebt sie die Praktiken vor, die sie von anderen erwartet? Finanziert sie Sicherheit ordentlich? Nimmt sie Menschen in die Verantwortung?
Lektion 8: Perfekt ist der Feind von fertig
Ich habe Unternehmen Compliance jahrelang hinauszögern sehen, auf der Jagd nach der „perfekten“ Lösung. Derweil bleiben sie non-compliant und exponiert.
Gut genug und umgesetzt schlägt perfekt und geplant. Eine 80-%-Lösung, die heute live geht, gibt Ihnen mehr Sicherheit als eine 100-%-Lösung, die noch im Ausschuss steckt.
Das ist keine Ausrede für schlechte Sicherheit. Es ist pragmatische Priorisierung: die größten Risiken zuerst angehen, kontinuierlich verbessern und Perfektion den Fortschritt nicht lähmen lassen.
Compliance ist eine Reise, kein Ziel. Sie werden nie „fertig“ sein. Akzeptieren Sie das, beginnen Sie, wo Sie stehen, und verbessern Sie systematisch.
Lektion 9: Anbieter sind nicht Ihre Freunde
Anbieter verkaufen Produkte. Ihr Ziel ist Umsatz, nicht Ihre Compliance. Die „Komplettlösung“, die sie versprechen, braucht meist weitere Käufe, Professional Services und laufende Abonnements.
Ich habe Unternehmen Werkzeuge kaufen sehen, die sie nicht brauchten, weil ein Anbieter sie als Compliance-Anforderungen rahmte. Ich habe Budgets von Enterprise-Plattformen verschlungen sehen, wo Open-Source-Tools die Aufgabe erledigt hätten.
Seien Sie skeptisch gegenüber Compliance-Versprechen von Anbietern. Verlangen Sie eine konkrete Zuordnung zu Anforderungen. Prüfen Sie mit unabhängigen Quellen. Der IT-Grundschutz-Katalog des BSI bietet herstellerneutrale Orientierung.
Das prägte meine eigene Produktarbeit. Ich habe FwChange gebaut, um ein echtes Problem zu lösen, für Mittelstands-Budgets bepreist, ohne die Enterprise-Komplexität, die Kosten ohne Mehrwert hinzufügt.
Lektion 10: Compliance sollte ein Nebenprodukt sein
Die besten Programme konzentrieren sich überhaupt nicht auf Compliance. Sie konzentrieren sich auf gute Sicherheitspraxis, und Compliance folgt als Nebenprodukt davon, Sicherheit gut zu machen.
Wenn Sicherheit im Betrieb verankert ist — risikoinformierte Entscheidungen, dokumentierte Änderungen, geschultes Personal, getestete Verfahren — erzeugt sich der Audit-Nachweis von selbst. Sie bereiten sich nicht auf Audits vor; Sie arbeiten sicher, und Audits bestätigen schlicht, was ohnehin schon wahr ist.
Organisationen, die Compliance als Ziel jagen, erreichen oft weder Compliance noch Sicherheit. Die, die echte Sicherheit verfolgen, erreichen meist beides.
Das ist die Synthese von allem, was ich gelernt habe: Bauen Sie echte Sicherheit, dokumentieren Sie sie ordentlich, und Compliance folgt. Umgekehrt funktioniert es nicht.
Diese Lektionen anwenden
Nach 15 Jahren führe ich noch immer Assessments durch und helfe Organisationen zur Compliance. Aber jetzt baue ich auch Werkzeuge, die diese Lektionen in die Praxis umsetzen.
FwChange existiert, weil Dokumentation automatisch sein sollte — und weil mittelständische Unternehmen Compliance-Werkzeuge verdienen, die keine Enterprise-Budgets verlangen.
Wenn Sie vor TISAX, NIS2, ISO 27001 oder einer anderen Compliance-Herausforderung stehen, gelten diese Lektionen. Konzentrieren Sie sich auf Dokumentation. Bauen Sie Prozesse, nicht nur Produkte. Machen Sie es kontinuierlich. Investieren Sie in Menschen. Denken Sie risikobasiert.
Und wenn Sie Hilfe brauchen, melden Sie sich. Ich habe 15 Jahre gebraucht, um das auf die harte Tour zu lernen, damit Sie es nicht müssen.
Über den Autor
Nick Falshaw ist Sicherheitsberater mit über 15 Jahren Erfahrung in der Enterprise-Security-Compliance im DACH-Raum. Er ist Gründer von FwChange und baut Compliance-Werkzeuge für mittelständische Unternehmen. Vernetzen Sie sich auf LinkedIn.