Die fünf häufigsten Stolpersteine bei der ISMS-Einführung

In den letzten Jahren habe ich eine ganze Reihe ISMS-Projekte begleitet: Start-ups auf der grünen Wiese, gewachsene Mittelständler mit historisch wuchernder IT, KRITIS-Betreiber mit dem entsprechenden Druck von außen. Wenn ich zurückblicke, fällt mir vor allem eines auf: An der Technik ist kaum eines gescheitert.

Firewall, MFA, ein funktionierendes Backup – das bekommen die meisten IT-Abteilungen sauber hin. Schwierig wird es bei den Entscheidungen, die ganz am Anfang fallen und sich später nur noch mit Schmerzen korrigieren lassen. Genau diese Weichenstellungen kosten mich in der Praxis die meiste Zeit. Fünf davon sehe ich immer wieder.

Der Scope wird aus Angst zu groß gewählt

Die wichtigste Entscheidung im ganzen Projekt ist der Geltungsbereich, und sie wird erstaunlich oft falsch getroffen. Der Satz, den ich am häufigsten höre, lautet: „Dann zertifizieren wir lieber gleich das ganze Unternehmen, sicher ist sicher.“ Das klingt nach Gründlichkeit, wird aber schnell teuer. Jeder zusätzliche Standort, jede Tochtergesellschaft, jeder Prozess im Scope zieht eine eigene Risikobewertung nach sich, eigene Maßnahmen, eigene Nachweise und am Ende zusätzliche Auditzeit.

Auf dem Zertifikat steht später ein einziger Satz, das Scope Statement. Dieser Satz ist es, den Ihre Kunden lesen. In den allermeisten Fällen genügt es völlig, den Geschäftsbereich oder das Produkt zu zertifizieren, für das ein Kunde tatsächlich einen Nachweis verlangt – die SaaS-Plattform mit Entwicklung und Betrieb zum Beispiel, aber ohne Buchhaltung und Empfang.

Ein eng geschnittener Geltungsbereich lässt sich in sechs bis neun Monaten sauber zur Zertifizierung bringen und danach kontrolliert erweitern. Ein zu großer Scope bringt das Projekt zum Stehen, lange bevor das erste Audit überhaupt in Sicht kommt. Und erweitern können Sie immer noch – das ist deutlich angenehmer als der umgekehrte Weg.

Die Risikoanalyse versinkt im Asset-Inventar

Wir arbeiten in aller Regel mit einem asset-basierten Risikoansatz, und genau deshalb beginnt die zweite Sackgasse mit einer eigentlich guten Absicht: einem sauberen Inventar.

Vorweg, damit kein Missverständnis entsteht: Das Inventar selbst ist richtig und wichtig. Ohne eine vernünftige Erfassung erkennen Sie gar nicht, welche Assetgruppen Sie überhaupt bilden müssen. Und Sie haben keine Grundlage für das Lifecycle-Management – also dafür, was wann aktualisiert werden muss und wo Schwachstellen lauern. Gerade bei den technischen Assets ist das ein eigener, laufender Prozess und kein einmaliges Abhaken.

Der Fehler entsteht an einer anderen Stelle: dann, wenn dieses Inventar zur Risikoanalyse erklärt wird. Plötzlich wandert jeder einzelne Laptop, jeder Drucker, jede Anwendung in eine Tabelle, und am Ende stehen dort mehrere hundert Zeilen, die niemand mehr pflegt und aus denen keine einzige Entscheidung folgt.

In der Risikobewertung interessiert mich das Einzelgerät nämlich kaum. Ich arbeite mit Assetgruppen. Die einzige Ausnahme ist ein abweichender Schutzbedarf innerhalb einer Gruppe: Der Laptop der Geschäftsführung mit Zugriff auf Strategie- und M&A-Unterlagen hat einen anderen Schutzbedarf als ein Gerät aus dem Lager. Solche Ausreißer muss ich erkennen, und dafür brauche ich das saubere Inventar im Hintergrund – bewertet wird aber die Gruppe, nicht das einzelne Gerät.

Was das in der Praxis heißt:

• Fassen Sie Assets zu wenigen, sprechenden Gruppen zusammen und behalten Sie einzelne Assets mit höherem Schutzbedarf darin gezielt im Blick.
• Halten Sie das Inventar lebendig. Es trägt nicht nur die Risikoanalyse, sondern auch Patch- und Schwachstellenmanagement.
• Trennen Sie beides sauber: Das Inventar ist die Datengrundlage, die Risikobewertung ist das Steuerungsinstrument.

Dieser letzte Punkt ist der entscheidende. Die Risikobewertung ist kein lästiger Nebenschauplatz, sondern der Kern fast jedes Managementsystems und im ISMS ohnehin. Sie ist das Werkzeug, mit dem Sie steuern, wo Sie investieren und wo nicht. Drei oder vier gut durchdachte Szenarien, die diese Steuerung wirklich tragen, sind mehr wert als dreihundert Zeilen gepflegter Langeweile.

Das Statement of Applicability wird nur abgehakt

Das Statement of Applicability, kurz SoA, ist das Herzstück der Zertifizierung – die Brücke zwischen Ihren Risiken und den Maßnahmen aus Annex A. In der Praxis begegnet es mir trotzdem oft als reine Häkchenliste: 93 Controls, überall „anwendbar“, keine Begründung. Das ist Quatsch, und jede erfahrene Auditorin erkennt es in wenigen Minuten.

Worauf es ankommt, ist die umgekehrte Richtung. Sie sollten zu jeder Maßnahme sagen können, aus welchem Risiko sie sich ableitet. Erst dann haben Sie verstanden, warum dieses Control bei Ihnen überhaupt steht.

Ein verbreitetes Missverständnis betrifft die Ausschlüsse. In mancher Ratgeberliteratur klingt es so, als wäre ein ausgeschlossenes Control geradezu ein Gütesiegel. In der Praxis sehe ich Ausschlüsse aber selten, und zwar aus einem einfachen Grund: Die dahinterliegenden Risiken sind in nahezu jedem Unternehmen vorhanden. Wenn doch einmal ausgeschlossen wird – etwa die Controls zur sicheren Softwareentwicklung, weil schlicht keine Entwicklung stattfindet –, dann braucht das eine wirklich tragfähige Begründung. Mit einer solchen Begründung lässt der Auditor mit sich reden. Ohne sie wird der Ausschluss schnell zur Abweichung im Audit.

Der eigentliche Hebel liegt woanders, nämlich in der Umsetzungstiefe. Ein Control darf bei Ihnen schlanker ausfallen als beim Nachbarn, sofern Ihre Risikobewertung das hergibt. Wenn Sie begründet sagen, dass ein bestimmtes Risiko zwar existiert, für Sie aber nachrangig ist, dürfen Sie die zugehörige Maßnahme entsprechend leichter umsetzen. Auch das ist eine Entscheidung, die direkt aus der Risikobewertung folgt – und genau deshalb hängt am Ende fast alles wieder an ihr.

Dokumentiert wird für den Ordner, nicht für den Betrieb

Hier muss ein Berater auch mal unbequem sein: Viele Richtlinien entstehen, um vorgezeigt zu werden, nicht um gelesen zu werden. Eine vierzigseitige Informationssicherheitsleitlinie, die außer dem ISB niemand je öffnet, schützt kein einziges System. Wir brauchen gelebte Dokumente, keine Papierleichen im Netzlaufwerk.

Gleichzeitig möchte ich einem verbreiteten Kurzschluss widersprechen, der lautet: dann eben alles auf eine halbe Seite. So einfach ist es nicht. Informationssicherheit bildet eine echte Komplexität ab, und die müssen die Richtlinien auch tragen. Um diese Komplexität kommen wir nicht herum, und wer sie wegkürzt, verlagert sie nur ins Ungewisse.

Der Ausweg liegt nicht in dünneren Dokumenten, sondern in mehreren Ebenen. Bewährt hat sich diese Aufteilung:

• Die Richtlinien selbst dürfen vollständig und damit auch anspruchsvoll sein – aber sauber gegliedert, mit einem brauchbaren Inhaltsverzeichnis, damit man die relevante Stelle in Sekunden findet.
• Die wichtigsten Themen bereiten wir zusätzlich in Schulungen auf, in denen das Wesentliche erklärt und eingeordnet wird.
• Für den Arbeitsalltag erstellen wir Mitarbeiter-Handouts, die die Kerninformationen knapp und plakativ zusammenfassen.

Denn im Tagesgeschäft kann niemand jede Richtlinie im Detail präsent haben, und das ist auch gar nicht das Ziel. Ein gut sortiertes Regelwerk hilft demjenigen, der gezielt nachschlägt. Ein einseitiges, plakatives Handout hilft oft noch mehr – nämlich der Person, die morgens um neun schnell eine Entscheidung treffen muss und keine Zeit hat, sich durch das Handbuch zu arbeiten.

Die Leitung delegiert das ISMS „in die IT“

Nicht ohne Grund trägt Klausel 5 der ISO 27001 die Überschrift „Leadership“. Trotzdem ist das in meiner Erfahrung der Punkt, an dem es am häufigsten klemmt. Überall dort, wo es im Unternehmen nicht rund läuft, lässt sich das am Ende auf fehlende Leitungsverantwortung zurückführen.

Das Muster ist fast immer dasselbe: Es gibt engagierte Leute, einen ambitionierten ISB, eine motivierte IT, gute einzelne Initiativen. Aber dass das Thema im ganzen Unternehmen ankommt, von der Produktion bis zum Vertrieb, gelingt nur, wenn die Geschäftsführung mit gutem Beispiel vorangeht und die Organisation darauf einschwört. Ohne diesen Rückhalt fehlen Budget, Verbindlichkeit und die Autorität, Maßnahmen auch gegen Widerstände durchzusetzen. Dann wird jede einzelne Maßnahme zur Einzelverhandlung.

Das ISMS ist eben kein IT-Projekt, sondern eine Frage der Unternehmenssteuerung. Die oberste Leitung gibt den Geltungsbereich frei, sagt Ressourcen zu und übernimmt in den Management-Reviews sichtbar Verantwortung. Und sie sorgt dafür, dass Awareness kein Einmaltermin bleibt: Sicherheitsbewusstsein entsteht nicht durch eine Schulung im Jahr, sondern dadurch, dass das Thema regelmäßig vorkommt, vorgelebt wird und im Alltag sichtbar bleibt. Wo die Leitung das ernst nimmt, läuft erstaunlich vieles fast von selbst.

Worauf es wirklich ankommt

Ein Zertifikat ist ein Stichtag. Ein gelebtes Managementsystem ist ein Dauerzustand, und nur der zweite Teil schützt am Ende wirklich. Die fünf Stolpersteine haben eine gemeinsame Wurzel: Sie entstehen, wenn das ISMS als Bürokratie missverstanden wird statt als das, was es sein soll – ein Steuerungsinstrument.

Wer den Scope bewusst eng hält, das Inventar lebendig führt und die Risiken auf Gruppenebene bewertet, das SoA aus den Risiken heraus begründet, in Ebenen statt in dünnen Alibi-Dokumenten dokumentiert und die Leitung früh in die Verantwortung nimmt, hat den schwierigen Teil hinter sich. Was dann noch dazugehört – die kontinuierliche Verbesserung, die regelmäßige Awareness, das Lernen aus Vorfällen – fällt deutlich leichter, weil das Fundament trägt.

Vieles davon klingt nach gesundem Menschenverstand, und genau das ist es auch. Der Unterschied zwischen einem Projekt, das stockt, und einem, das trägt, liegt selten in der Technik. Er liegt in diesen frühen, unscheinbaren Entscheidungen.