Lessons Learned aus ISMS-Projekten: Was immer schiefgeht

TL;DR

Fehler Nr. 1: Fehlende Unterstützung der Geschäftsführung. Ein ISMS ohne sichtbares Management-Commitment wird zum Soloprojekt des ISB und scheitert an mangelnder Ressourcenfreigabe.
Fehler Nr. 2: Die Risikobewertung wird als Formalität betrieben statt als echtes Steuerungsinstrument. Unrealistische Bewertungen führen zu falschen Prioritäten und nutzlosen Maßnahmen.
Fehler Nr. 3: Dokumentation wird für den Auditor geschrieben, nicht für die Organisation. Die Folge: Niemand liest die Richtlinien, und die Praxis weicht massiv vom Papier ab.
Fehler Nr. 4: Technik wird über Organisation gestellt. Die neueste Security-Appliance hilft nicht, wenn Mitarbeiter Passwörter auf Post-its schreiben und der Incident-Response-Prozess nicht existiert.
Fehler Nr. 5: Nach der Zertifizierung hört die Arbeit auf. Das ISMS veraltet, und beim Überwachungsaudit steht das Unternehmen vor der Wahl zwischen hektischer Nacharbeit und Zertifikatsverlust.

Warum die gleichen Fehler immer wieder passieren

ISMS-Projekte im Mittelstand scheitern nicht an exotischen Problemen. Sie scheitern an denselben Fehlern, die andere Unternehmen vor ihnen gemacht haben. Das ist frustrierend, weil die Fehler bekannt und vermeidbar sind. Und es ist gleichzeitig tröstlich, weil es bedeutet, dass du von den Erfahrungen anderer profitieren kannst.

Die folgenden Lessons Learned stammen nicht aus Lehrbüchern, sondern aus der Praxis. Sie beschreiben Situationen, die in ISMS-Projekten mit schöner Regelmäßigkeit auftreten, und geben dir konkrete Hinweise, wie du sie vermeidest oder frühzeitig erkennst.

Lesson 1: Management-Commitment ist kein Lippenbekenntnis

Was schiefgeht: Die Geschäftsführung gibt grünes Licht für das ISMS-Projekt, stellt ein Budget bereit und erwartet, dass der ISB den Rest erledigt. Auf dem Papier ist das Commitment vorhanden. In der Praxis zeigt sich schnell, dass die Geschäftsführung andere Prioritäten hat. Wenn der ISB Ressourcen aus Fachabteilungen braucht, muss er betteln. Wenn er eine Entscheidung braucht, landet sein Antrag im Postfach und bleibt dort. Wenn er ein Management Review ansetzen will, wird es dreimal verschoben, weil immer etwas Wichtigeres dazwischenkommt.

Das Signal an die Organisation ist klar: Informationssicherheit ist kein echtes Anliegen der Führung. Es ist ein Projekt, das man irgendwann machen muss, aber das keine Priorität hat. Die Fachabteilungen richten ihr Verhalten danach aus und behandeln ISMS-Anfragen entsprechend.

Was du dagegen tun kannst: Management-Commitment bedeutet nicht nur, "Ja" zu sagen und ein Budget freizugeben. Es bedeutet, dass die Geschäftsführung aktiv und sichtbar hinter dem Projekt steht. Konkret heißt das: Die Geschäftsführung kommuniziert das Projekt selbst an die Organisation (nicht per E-Mail vom ISB), nimmt an den Management Reviews teil (persönlich, nicht per Vertreter), fragt regelmäßig nach dem Status (nicht weil sie kontrollieren will, sondern weil es sie interessiert), und interveniert, wenn Ressourcen nicht bereitgestellt werden.

Ein bewährter Mechanismus: Vereinbare mit der Geschäftsführung einen monatlichen Kurz-Slot von 15 Minuten, in dem der ISB den Status berichtet und offene Entscheidungen einholt. Dieser regelmäßige Kontakt hält das Thema auf dem Radar und gibt dem ISB eine direkte Eskalationsmöglichkeit.

Lesson 2: Die Risikobewertung als Pflichtübung

Was schiefgeht: Die Risikobewertung wird durchgeführt, weil die Norm es verlangt. Die Risikoeigner sitzen im Workshop, nicken die vorbereiteten Einschätzungen des ISB ab und gehen zurück an ihre Arbeit. Die Bewertungen sind oft unrealistisch optimistisch ("Unsere Risiken sind alle niedrig bis mittel") oder unrealistisch pessimistisch ("Alles ist kritisch"). In beiden Fällen taugt die Risikobewertung nicht als Steuerungsinstrument.

Das Ergebnis: Die Maßnahmen, die aus der Risikobewertung abgeleitet werden, passen nicht zu den tatsächlichen Risiken. Ressourcen werden in Bereiche investiert, die gar nicht die höchste Priorität haben, während echte Schwachstellen unbehandelt bleiben.

Was du dagegen tun kannst: Mach die Risikobewertung zu einem echten Gespräch, nicht zu einem Formular, das ausgefüllt werden muss. Stelle den Risikoeigentümern konkrete Fragen: "Was passiert, wenn euer CRM für eine Woche nicht verfügbar ist? Wie reagiert ihr, wenn ein Mitarbeiter vertrauliche Kundendaten an einen privaten E-Mail-Account weiterleitet? Was wäre die Konsequenz, wenn ein Angreifer Zugriff auf eure Entwicklungsumgebung bekommt?"

Nutze konkrete Szenarien statt abstrakter Bewertungsmatrizen. Wenn ein Risikoeigner sagt, dass das Risiko eines Ransomware-Angriffs auf seinen Bereich "niedrig" ist, frag nach: "Wie ist eure Backup-Strategie? Habt ihr schon mal einen Restore getestet? Wie lange könnt ihr ohne eure Systeme arbeiten?" Oft ändert sich die Bewertung, wenn man die Fragen konkret stellt.

Lesson 3: Dokumentation für den Auditor statt für die Organisation

Was schiefgeht: Die Richtlinien werden in einem Schreibstil verfasst, der dem Auditor gefällt: formell, umfassend, mit Verweisen auf Normanforderungen und einer Detailtiefe, die jeden Sonderfall abdeckt. Das Ergebnis sind 20-seitige Dokumente, die kein Mitarbeiter liest und die keinen Bezug zum Arbeitsalltag haben.

Der ISB weiß, dass die Richtlinien nicht gelesen werden. Der Auditor weiß es auch. Aber solange sie existieren und formal korrekt sind, wird das Audit bestanden. Das Problem zeigt sich erst, wenn ein Sicherheitsvorfall eintritt und die Mitarbeiter nicht wissen, was sie tun sollen, weil sie die Richtlinie nie gelesen haben und die Richtlinie auch nicht beschreibt, was sie im konkreten Fall tun sollen.

Was du dagegen tun kannst: Schreibe Richtlinien für die Nutzer, nicht für den Auditor. Das bedeutet: kurze, verständliche Sätze, konkreter Bezug zu den tatsächlichen Arbeitsprozessen, Verzicht auf Normjargon, und eine klare Antwort auf die Frage "Was muss ich konkret tun?".

Eine gute Informationssicherheitsrichtlinie hat maximal fünf bis zehn Seiten. Wenn sie länger wird, zerlege sie in mehrere Dokumente. Ergänze die Richtlinie um eine einseitige Zusammenfassung (ein "Cheat Sheet"), das die wichtigsten Punkte auf einen Blick zeigt.

Teste die Richtlinie, bevor du sie veröffentlichst. Gib sie einem Mitarbeiter aus der Zielgruppe und frag: "Was musst du laut dieser Richtlinie tun, wenn X passiert?" Wenn die Antwort nicht auf Anhieb kommt, ist die Richtlinie nicht verständlich genug.

Lesson 4: Die Technik-Falle

Was schiefgeht: Das ISMS-Projekt wird zum IT-Security-Projekt. Der Fokus liegt auf technischen Maßnahmen: neue Firewall, EDR-Lösung, SIEM-System, Netzwerksegmentierung, Vulnerability Scanner. Die organisatorischen Aspekte (Richtlinien, Schulungen, Prozesse, Rollen) werden als notwendiges Übel betrachtet und mit minimalem Aufwand abgehandelt.

Das Ergebnis ist ein Unternehmen mit beeindruckender Sicherheitstechnik und katastrophaler Sicherheitskultur. Die Firewall blockiert alles, aber die Mitarbeiter teilen Passwörter, weil die Zugangskontrollen zu restriktiv sind. Das SIEM produziert Tausende von Alerts, aber niemand hat einen Prozess definiert, wie auf diese Alerts reagiert werden soll. Die EDR-Lösung erkennt Malware, aber die Incident Response besteht darin, dass der IT-Admin den Rechner neu installiert und hofft, dass es nicht wieder passiert.

Was du dagegen tun kannst: Erinnere dich regelmäßig daran, dass ein ISMS ein Managementsystem ist, kein Technologieprojekt. Technische Maßnahmen sind ein wichtiger Teil, aber eben nur ein Teil. Die ISO 27001 widmet sich der Technik in wenigen Annex-A-Controls. Der Rest handelt von Organisation, Prozessen, Menschen und Führung.

Stelle sicher, dass die Zeitverteilung im Projekt die Balance widerspiegelt. Wenn 80 Prozent der Projektzeit in technische Implementierungen fließen und 20 Prozent in alles andere, stimmt das Verhältnis nicht. Plane bewusst Zeit für Workshops mit Fachabteilungen, für die Erstellung und Abstimmung von Richtlinien, für Schulungen und für die organisatorische Verankerung ein.

Lesson 5: Der Scope-Albtraum

Was schiefgeht: Der ISMS-Scope wird entweder zu groß oder zu klein definiert. Beide Extreme führen zu Problemen.

Ein zu großer Scope: Ein Unternehmen mit 200 Mitarbeitern, fünf Standorten und drei Geschäftsbereichen definiert das gesamte Unternehmen als Scope, obwohl die Zertifizierung eigentlich nur für einen Geschäftsbereich gefordert wird. Der Aufwand vervielfacht sich, weil jeder Standort und jeder Geschäftsbereich eigene Risiken, Prozesse und Ansprechpartner hat. Das Projekt wird zum Dauerbrenner.

Ein zu kleiner Scope: Ein Unternehmen definiert den Scope als "IT-Abteilung" oder "Rechenzentrum". Das klingt handhabbar, führt aber zu ständigen Abgrenzungsproblemen. Die IT-Abteilung nutzt HR-Prozesse (Onboarding, Offboarding), der Vertrieb verarbeitet vertrauliche Kundendaten auf Laptops, die Produktion steuert Maschinen über das gleiche Netzwerk. All diese Schnittstellen müssen sauber definiert und abgegrenzt werden, was oft aufwändiger ist als ein breiterer Scope.

Was du dagegen tun kannst: Wähle einen Scope, der sinnvoll abgegrenzt ist und den du mit den verfügbaren Ressourcen bewältigen kannst. Für die meisten mittelständischen Unternehmen mit einem Standort und einer überschaubaren Struktur ist das gesamte Unternehmen der pragmatischste Scope. Für größere oder komplexere Organisationen kann ein Teilscope sinnvoll sein, wenn die Abgrenzung klar und nachvollziehbar ist.

Teste den Scope gedanklich: Kannst du die Grenzen erklären, ohne zehn Minuten dafür zu brauchen? Gibt es Schnittstellen zum Bereich außerhalb des Scopes, die schwer zu managen sind? Werden die Kunden oder Aufsichtsbehörden den Scope als ausreichend akzeptieren?

Lesson 6: Richtlinien kopieren statt adaptieren

Was schiefgeht: Der ISB beschafft sich Richtlinienvorlagen, sei es von einem Berater, aus dem Internet oder von einem befreundeten Unternehmen, und übernimmt sie mit minimalen Anpassungen. Die Passwort-Richtlinie beschreibt Anforderungen, die das Active Directory gar nicht erzwingen kann. Die Remote-Work-Richtlinie regelt die Nutzung eines VPN, das das Unternehmen nicht einsetzt. Die Klassifizierungsschemata passen nicht zu den tatsächlichen Informationsflüssen.

Der Auditor erkennt Copy-Paste-Richtlinien sofort. Er fragt den ISB, warum die Richtlinie eine bestimmte Anforderung enthält, und der ISB kann nicht erklären, was damit gemeint ist. Oder er fragt einen Mitarbeiter, wie er eine bestimmte Richtlinienanforderung im Alltag umsetzt, und der Mitarbeiter hat noch nie davon gehört.

Was du dagegen tun kannst: Vorlagen sind ein guter Startpunkt, aber kein Endprodukt. Jede Richtlinie muss an die tatsächlichen Prozesse, Systeme und Strukturen deines Unternehmens angepasst werden. Wenn du eine Vorlage verwendest, gehe sie Punkt für Punkt durch und frage dich: "Ist das bei uns so? Setzen wir das um? Können wir das umsetzen? Macht das für unser Unternehmen Sinn?"

Streiche Punkte, die nicht passen, und ergänze Punkte, die fehlen. Das dauert länger als ein reines Copy-Paste, aber es produziert Richtlinien, die funktionieren und die der Auditor nicht durchschaut.

Lesson 7: Schulungen als Einmal-Event

Was schiefgeht: Im Zertifizierungsjahr werden alle Mitarbeiter geschult. Eine Stunde Frontalvortrag, eine Unterschrift auf der Teilnehmerliste, fertig. Im Jahr danach passiert nichts. Im übernächsten Jahr gibt es eine Wiederholung der gleichen Schulung. Die Teilnehmer langweilen sich, weil sie alles schon gehört haben, und nehmen nichts mit.

Das zeigt sich in den Phishing-Simulationen: Die Klickrate sinkt nach der Schulung kurz ab und steigt dann wieder auf das Ausgangsniveau. Die Mitarbeiter haben die Inhalte gehört, aber nicht verinnerlicht.

Was du dagegen tun kannst: Security Awareness ist ein Programm, kein Event. Plane über das Jahr verteilt verschiedene Formate und Inhalte. Nutze kurze, fokussierte Impulse (zehn Minuten statt einer Stunde), aktuelle Bezüge (ein konkreter Vorfall aus der Branche, nicht abstrakte Bedrohungsszenarien), und interaktive Elemente (Quiz, Phishing-Simulation, Live-Demo eines Angriffs).

Die wichtigste Kennzahl für die Wirksamkeit ist nicht die Teilnahmequote an Schulungen, sondern die Veränderung im Verhalten. Melde-Raten für verdächtige E-Mails, Ergebnisse von Phishing-Simulationen, Einhaltung von Clean-Desk-Vorgaben: Diese Indikatoren zeigen, ob die Awareness wirklich ankommt.

Lesson 8: Lieferanten ignorieren

Was schiefgeht: Das Unternehmen baut ein solides ISMS auf, übersieht aber die Lieferkette. Kritische IT-Dienstleister haben keinen Vertrag mit Sicherheitsanforderungen. Cloud-Dienste werden ohne Sicherheitsbewertung eingesetzt. Subunternehmer haben Zugriff auf vertrauliche Daten, ohne dass eine Vertraulichkeitsvereinbarung existiert.

Der Auditor fragt nach der Lieferantenbewertung und erhält eine leere Liste. Oder er fragt, wie sichergestellt wird, dass der Hosting-Provider die Daten angemessen schützt, und erfährt, dass niemand den Provider je danach gefragt hat.

Was du dagegen tun kannst: Erstelle eine Liste aller Dienstleister und Lieferanten, die Zugang zu deinen Informationen haben oder deine IT-Infrastruktur betreffen. Klassifiziere sie nach Kritikalität: Welche Dienstleister könnten bei einem Ausfall oder einer Kompromittierung den größten Schaden verursachen? Ein strukturierter Sicherheitsfragebogen hilft dir, die Bewertung systematisch durchzuführen.

Für die kritischen Dienstleister brauchst du: vertragliche Sicherheitsanforderungen (Auftragsverarbeitungsvertrag, Vertraulichkeitsvereinbarung, SLA mit Sicherheitskennzahlen), eine regelmäßige Bewertung (jährlich für die kritischsten, alle zwei bis drei Jahre für weniger kritische) und einen Prozess für die Bewertung neuer Dienstleister, bevor sie beauftragt werden.

Lesson 9: Kein Incident-Response-Prozess in der Praxis

Was schiefgeht: Der Incident-Response-Plan existiert auf dem Papier. Darin steht, wer bei einem Vorfall informiert werden muss, welche Schritte durchzuführen sind und wie die Kommunikation ablaufen soll. Aber der Plan wurde nie getestet. Die Telefonnummern sind veraltet. Die Mitarbeiter wissen nicht, dass der Plan existiert. Und als ein echter Vorfall eintritt, ist es Freitagabend, der ISB ist im Urlaub, und niemand weiß, wer jetzt was tun soll.

Was du dagegen tun kannst: Teste den Incident-Response-Plan mindestens einmal pro Jahr in einer Tabletop-Übung. Simuliere ein realistisches Szenario (Ransomware-Angriff, Datenpanne, Ausfall eines kritischen Systems) und spiele es mit den beteiligten Personen durch. Die Übung zeigt sofort, ob der Plan funktioniert, ob die Kontaktdaten stimmen, ob die Rollen klar sind und ob die Beteiligten wissen, was von ihnen erwartet wird.

Stelle sicher, dass der Plan nicht nur beim ISB liegt, sondern allen relevanten Personen bekannt und zugänglich ist. Eine ausgedruckte Kurzversion im Serverraum, in der Zentrale und beim Bereitschaftsdienst ist keine schlechte Idee, denn im Ernstfall ist das Netzwerk möglicherweise nicht verfügbar.

Lesson 10: Das ISMS als Insel

Was schiefgeht: Das ISMS existiert als separates System neben den anderen Managementsystemen und Geschäftsprozessen. Es hat eigene Dokumentationen, eigene Meetings, eigene Prozesse, die parallel zu den bestehenden laufen. Das ISMS-Risikomanagement ist nicht mit dem Unternehmensrisikomanagement integriert. Die ISMS-Dokumentation lebt in einem anderen System als die restliche Unternehmensdokumentation. Die ISMS-Audits laufen getrennt von den Qualitätsaudits.

Die Folge: Doppelarbeit, Inkonsistenzen und die Wahrnehmung, dass das ISMS ein Paralleluniversum ist, das mit dem echten Geschäftsbetrieb nichts zu tun hat.

Was du dagegen tun kannst: Integriere das ISMS so weit wie möglich in die bestehenden Managementstrukturen und Geschäftsprozesse. Das ISMS-Risikomanagement sollte Teil des Unternehmensrisikomanagements sein (oder es zumindest informieren). In ISMS Lite (500 Euro pro Jahr) kannst du die Verbindung zwischen Risiken, Maßnahmen und Controls über alle Bereiche hinweg abbilden und so Doppelarbeit vermeiden. Die ISMS-Richtlinien sollten im gleichen Dokumentenmanagementsystem liegen wie alle anderen Unternehmensdokumente. Die internen Audits können mit Qualitätsaudits kombiniert werden. Das Management Review kann als Tagesordnungspunkt im regulären Führungsmeeting stattfinden.

Je weniger das ISMS als separates Konstrukt wahrgenommen wird und je mehr es in die normale Arbeitsweise integriert ist, desto höher sind Akzeptanz und Wirksamkeit.

Die Meta-Lesson: Perfektionismus ist der Feind

Über all diesen einzelnen Lessons steht eine übergreifende Erkenntnis: Perfektionismus ist der häufigste Grund für Verzögerungen und Frustrationen in ISMS-Projekten. Die Informationssicherheitsleitlinie muss nicht perfekt sein, bevor du sie veröffentlichst. Die Risikobewertung muss nicht jedes denkbare Szenario abdecken. Die Richtlinien müssen nicht jeden Sonderfall regeln.

Ein ISMS ist von Natur aus ein iteratives System. Der PDCA-Zyklus sieht ausdrücklich vor, dass du mit einer guten-genug-Version startest, sie in der Praxis testest, die Ergebnisse prüfst und dann verbesserst. Wer versucht, im ersten Durchlauf alles perfekt zu machen, wird nie fertig.

Die Devise lautet: Starte mit dem Wesentlichen, mache es richtig (nicht perfekt), und verbessere kontinuierlich. Das ist nicht nur pragmatisch, sondern genau das, was die Norm fordert.

Weiterführende Artikel

ISMS ISO 27001 Lessons Learned Projektmanagement Fehler Best Practices KMU