Der entscheidende Gedanke hinter einem ISMS ist der Perspektivwechsel: weg von der Vorstellung, Sicherheit sei ein technisches Produkt, das man einmal kauft und installiert, hin zu der Einsicht, dass Sicherheit ein fortlaufender Managementprozess ist. Technik ist dabei wichtig, aber nur ein Teil. Ebenso zählen organisatorische Regeln, die Sensibilisierung der Mitarbeitenden, klare Zuständigkeiten und die Fähigkeit, auf Vorfälle geordnet zu reagieren. Ein ISMS bündelt all das in einer nachvollziehbaren Struktur und stellt sicher, dass Sicherheit nicht vom Zufall oder vom Engagement einzelner Personen abhängt.
Der Begriff „Managementsystem“ ist dabei wörtlich zu nehmen. Genau wie ein Qualitätsmanagementsystem die Qualität steuert, steuert ein ISMS die Informationssicherheit – mit Zielen, Verantwortlichkeiten, dokumentierten Abläufen, Messgrößen und regelmäßiger Überprüfung. Es beantwortet nicht die Frage „Welche Technik brauche ich?“, sondern die übergeordnete Frage „Wie stelle ich sicher, dass die richtigen Maßnahmen ausgewählt, umgesetzt, überprüft und verbessert werden?“.
Im Zentrum jedes ISMS stehen drei Schutzziele, die als CIA-Triade bekannt sind – benannt nach den englischen Begriffen Confidentiality, Integrity und Availability. Sie bilden den Maßstab, an dem sich jede Sicherheitsmaßnahme messen lassen muss:
Diese drei Ziele stehen bewusst gleichrangig nebeneinander, auch wenn ihr relatives Gewicht je nach Information unterschiedlich ist. Für ein Backup zählt vor allem die Verfügbarkeit, für eine Kundenliste die Vertraulichkeit, für ein Buchhaltungssystem die Integrität. Ein ISMS zwingt eine Organisation dazu, für ihre schützenswerten Werte bewusst zu bestimmen, welches Schutzziel wie wichtig ist – und die Maßnahmen daran auszurichten. Häufig werden die drei Grundziele um weitere Aspekte wie Authentizität, Nachvollziehbarkeit und Verbindlichkeit ergänzt, die in der Praxis eng mit den Kernzielen verbunden sind.
Ein verbreitetes Missverständnis besteht darin, Informationssicherheit mit IT-Sicherheit gleichzusetzen. Tatsächlich ist der Blick eines ISMS breiter: Es schützt Informationen unabhängig von ihrer Form. Das umfasst digitale Daten ebenso wie ausgedruckte Dokumente, Wissen in den Köpfen der Mitarbeitenden, Gespräche und Vertragsunterlagen. IT-Sicherheit ist die – heute besonders wichtige – Teilmenge, die sich um die technischen Systeme kümmert. Informationssicherheit als übergeordnetes Konzept schließt organisatorische, personelle und physische Aspekte mit ein.
Diese Weite ist kein akademisches Detail, sondern praxisrelevant. Der teuerste Vorfall entsteht oft nicht durch eine Lücke in der Firewall, sondern durch eine unbedachte Handlung, eine unklare Zuständigkeit oder eine fehlende Regel. Ein ISMS adressiert genau diese Schnittstelle zwischen Technik, Organisation und Mensch – und das ist der Grund, warum es sich nicht auf die IT-Abteilung abschieben lässt, sondern eine Aufgabe der gesamten Organisation und ihrer Leitung ist.
ISO/IEC 27001 ist die international führende Norm für Informationssicherheits-Managementsysteme und die einzige aus dieser Familie, gegen die sich eine Organisation zertifizieren lassen kann. Die Norm beschreibt die Anforderungen an ein ISMS – also das, was eine Organisation nachweislich erfüllen muss: den Kontext der Organisation verstehen, Führung und Verpflichtung der Leitung sicherstellen, Sicherheitsziele planen, Ressourcen bereitstellen, den Betrieb steuern, die Wirksamkeit bewerten und kontinuierlich verbessern. Diese Anforderungen sind bewusst technologieneutral formuliert, damit sie für Organisationen jeder Größe und Branche gelten.
Ein zentrales Merkmal von ISO/IEC 27001 ist der risikobasierte Ansatz: Die Norm schreibt keine feste Liste umzusetzender Technik vor, sondern verlangt, dass eine Organisation ihre Risiken bewertet und daraus ableitet, welche Maßnahmen angemessen sind. Ergänzt wird der Hauptteil durch den Anhang A (Annex A), der einen strukturierten Katalog von Referenzmaßnahmen – sogenannte Controls – enthält, an denen sich die Auswahl orientiert. Diese Kombination aus verpflichtendem Management-Rahmen und einem Referenzkatalog macht die Norm zugleich verbindlich und flexibel.
Um ISO/IEC 27001 herum gruppiert sich die Normenreihe ISO/IEC 27000, deren einzelne Teile jeweils bestimmte Aspekte vertiefen. Für die Praxis besonders wichtig sind:
Darüber hinaus gibt es zahlreiche weitere, spezialisiertere Normen der Reihe – etwa zu Cloud-Sicherheit, zum Datenschutz-Informationsmanagement als Erweiterung eines ISMS oder zu branchenspezifischen Anforderungen. Für den Einstieg genügt es zu wissen, dass ISO 27001 den zertifizierbaren Rahmen setzt, ISO 27002 die Maßnahmen erläutert und ISO 27005 die Risikomethodik unterstützt. Die übrigen Normen ergänzen dieses Fundament bei Bedarf.
Im deutschsprachigen Raum kommt neben ISO/IEC 27001 dem IT-Grundschutz des Bundesamts für Sicherheit in der Informationstechnik (BSI) eine besondere Bedeutung zu. Der IT-Grundschutz verfolgt dasselbe Ziel wie ISO 27001 – ein funktionierendes ISMS –, geht aber einen konkreteren Weg: Statt Maßnahmen nur risikobasiert abzuleiten, stellt er umfangreiche Bausteine mit konkreten Anforderungen für typische Bereiche bereit, von der Netzwerkarchitektur über den Serverbetrieb bis zu organisatorischen Themen. Für viele Anwender ist das ein Vorteil, weil es die Frage „Was genau muss ich tun?“ deutlich handfester beantwortet.
Wichtig ist: Der BSI-IT-Grundschutz ist mit ISO/IEC 27001 kompatibel. Es gibt einen etablierten Weg zu einer ISO-27001-Zertifizierung auf Basis von IT-Grundschutz, der die internationale Anerkennung des ISO-Zertifikats mit der konkreten Methodik des Grundschutzes verbindet. Für Behörden, öffentliche Auftraggeber und deren Zulieferer ist der IT-Grundschutz häufig der naheliegende oder sogar vorgegebene Weg, während privatwirtschaftliche Unternehmen mit internationalem Kundenkreis oft direkt die reine ISO-27001-Zertifizierung anstreben. Beide Wege führen zu einem tragfähigen ISMS – die Wahl hängt vom Umfeld, den Anforderungen und den Vorlieben der Organisation ab.
Am Anfang steht die Festlegung des Geltungsbereichs – des Scope. Er bestimmt, welche Teile der Organisation, welche Standorte, welche Prozesse und welche Informationswerte das ISMS umfasst. Diese Entscheidung ist folgenreich: Ein zu weit gefasster Scope überfordert gerade kleinere Organisationen, ein zu eng gefasster Scope lässt wesentliche Risiken außen vor und untergräbt die Glaubwürdigkeit. Der Scope muss deshalb bewusst und begründet gewählt werden – oft beginnt eine Organisation mit einem klar abgegrenzten Bereich, etwa einem bestimmten Dienst oder Standort, und weitet ihn später aus.
Auf dem Scope baut die Informationssicherheitsleitlinie auf – ein von der obersten Leitung verabschiedetes Grundsatzdokument, das die Bedeutung der Informationssicherheit für die Organisation, die übergeordneten Ziele und die Verpflichtung des Managements festhält. Die Leitlinie ist bewusst kurz und grundsätzlich gehalten; sie ist das sichtbare Bekenntnis der Leitung und der Rahmen, aus dem sich detailliertere Richtlinien und Anweisungen ableiten. Ohne diese sichtbare Verankerung an der Spitze bleibt ein ISMS ein Papiertiger ohne Durchsetzungskraft.
Das methodische Herz eines ISMS ist das Risikomanagement. Es beantwortet die Frage, wovor die Organisation ihre Informationen eigentlich schützt und wie ernst die einzelnen Bedrohungen zu nehmen sind. Der Ablauf folgt einer wiederkehrenden Logik: Zunächst werden die schützenswerten Werte und die auf sie wirkenden Risiken identifiziert, dann werden diese Risiken hinsichtlich Eintrittswahrscheinlichkeit und Schadensausmaß analysiert und bewertet, und schließlich wird für jedes Risiko eine Behandlungsentscheidung getroffen.
Für die Risikobehandlung stehen grundsätzlich vier Wege offen: das Risiko durch Maßnahmen reduzieren, es durch eine Versicherung oder einen Dienstleister teilen, es durch Verzicht auf die risikoträchtige Tätigkeit vermeiden oder es bewusst und dokumentiert akzeptieren. Entscheidend ist, dass diese Wahl begründet und nachvollziehbar getroffen wird. Ein ISMS verlangt nicht, jedes denkbare Risiko auf null zu senken – das wäre weder möglich noch wirtschaftlich –, sondern einen bewussten, dokumentierten Umgang mit Risiken auf einem von der Leitung akzeptierten Niveau. Genau diese Nachvollziehbarkeit unterscheidet ein ISMS von zufälliger Sicherheit.
Aus der Risikobehandlung ergibt sich, welche Maßnahmen die Organisation umsetzt. Als Referenz dient der Maßnahmenkatalog im Annex A der ISO/IEC 27001. Dieser Katalog gliedert die Controls in thematische Gruppen – im Wesentlichen organisatorische, personenbezogene, physische und technologische Maßnahmen. Er reicht von Regelungen zu Zugriffsrechten, Kryptografie und Netzwerksicherheit über die Sensibilisierung der Mitarbeitenden und den Umgang mit Lieferanten bis zu physischer Sicherheit, Vorfallbehandlung und dem Management der Geschäftskontinuität.
Das Bindeglied zwischen Risikomanagement und Maßnahmen ist die Erklärung zur Anwendbarkeit (englisch Statement of Applicability, kurz SoA). In diesem zentralen Dokument hält die Organisation für jede Referenzmaßnahme fest, ob sie anwendbar ist, ob sie umgesetzt wird und – falls nicht – aus welchem Grund sie ausgeschlossen wurde. Die SoA ist damit das Scharnier des gesamten ISMS: Sie verbindet die bewertete Risikolage mit den konkret gewählten Maßnahmen und macht beides für Auditoren und die eigene Leitung transparent. Kein anderes Dokument zeigt so kompakt, ob ein ISMS durchdacht ist oder ob Maßnahmen willkürlich gewählt wurden.
Der PDCA-Zyklus stammt ursprünglich aus dem Qualitätsmanagement und liegt allen modernen Managementsystemen zugrunde. Für ein ISMS bedeutet er, dass Informationssicherheit nicht einmalig aufgebaut und dann sich selbst überlassen wird, sondern in wiederkehrenden Runden geplant, umgesetzt, geprüft und angepasst wird. Jede Runde hebt das Sicherheitsniveau ein Stück und reagiert auf neue Erkenntnisse, veränderte Risiken und die Erfahrungen aus dem laufenden Betrieb.
Die Bedrohungslage in der Informationssicherheit verändert sich schneller als in fast jedem anderen Bereich. Neue Angriffsmethoden, neue Technologien, neue Geschäftsprozesse und neue rechtliche Anforderungen entstehen laufend. Ein Sicherheitsniveau, das heute angemessen ist, kann in einem Jahr überholt sein. Genau deshalb ist der Kreislaufgedanke des PDCA-Zyklus kein bürokratisches Beiwerk, sondern die Kernidee eines ISMS: Sicherheit ist kein Zustand, der einmal erreicht und dann konserviert wird, sondern eine Fähigkeit, die gepflegt werden muss.
Für die Praxis bedeutet das, dass die scheinbar unspektakulären Routinen – interne Audits, die Nachverfolgung von Maßnahmen, das regelmäßige Management-Review – den eigentlichen Unterschied machen. Sie verhindern, dass ein ISMS nach der ersten Zertifizierung erstarrt und zur reinen Fassade verkommt. Ein lebendiges ISMS erkennt man daran, dass es sich verändert: dass Risikobewertungen aktualisiert werden, dass aus Vorfällen gelernt wird und dass Maßnahmen an neue Gegebenheiten angepasst werden.
Zwei Instrumente verdienen in der Check- und Act-Phase besondere Aufmerksamkeit. Das interne Audit überprüft in regelmäßigen Abständen, ob das ISMS wie dokumentiert funktioniert und ob es die Anforderungen erfüllt. Es wird von Personen durchgeführt, die die geprüften Bereiche nicht selbst verantworten, um Unabhängigkeit zu wahren, und deckt Abweichungen auf, bevor es ein externer Auditor tut. Das interne Audit ist damit ein wertvolles Frühwarnsystem der Organisation selbst.
Das Management-Review ist die regelmäßige Bewertung des ISMS durch die oberste Leitung. Hier prüft das Management anhand von Kennzahlen, Auditergebnissen, Vorfällen und dem Stand der Ziele, ob das ISMS wirksam ist und wo nachgesteuert werden muss. Dieses Review ist nicht delegierbar – es ist der Moment, in dem die Leitung ihre Verantwortung für die Informationssicherheit sichtbar und dokumentiert wahrnimmt. Ohne ein ernsthaftes Management-Review fehlt dem PDCA-Zyklus die entscheidende Steuerungsinstanz.
Die vielleicht wichtigste und am häufigsten unterschätzte Aussage über ein ISMS lautet: Die Verantwortung für die Informationssicherheit liegt bei der obersten Leitung – bei der Geschäftsführung oder dem Vorstand. Diese Verantwortung ist nicht delegierbar. Zwar kann und muss die Leitung operative Aufgaben übertragen, doch die grundsätzliche Verpflichtung, angemessene Sicherheit sicherzustellen, ausreichende Ressourcen bereitzustellen und die strategische Richtung vorzugeben, verbleibt an der Spitze. ISO/IEC 27001 macht diese Führungsverantwortung ausdrücklich zu einer eigenen Anforderung.
In der Praxis zeigt sich der Unterschied zwischen einem wirksamen und einem wirkungslosen ISMS oft genau hier. Trägt die Leitung das System sichtbar mit – durch eine verabschiedete Leitlinie, durch bereitgestellte Ressourcen, durch ihre aktive Rolle im Management-Review –, dann nehmen es auch die Mitarbeitenden ernst. Delegiert die Leitung Informationssicherheit dagegen vollständig „nach unten“ und interessiert sich nicht weiter dafür, verkommt das ISMS zur Pflichtübung einiger Spezialisten ohne Rückhalt in der Organisation. Die zunehmende regulatorische Betonung der Leitungsverantwortung, etwa im Rahmen von NIS2, verschärft diesen Punkt zusätzlich.
Die zentrale operative Rolle im ISMS ist der Informationssicherheitsbeauftragte (ISB), im internationalen und größeren Umfeld oft als Chief Information Security Officer (CISO) bezeichnet. Diese Rolle koordiniert das ISMS, treibt die Risikobewertung voran, überwacht die Umsetzung der Maßnahmen, bereitet interne Audits und das Management-Review vor und ist Ansprechpartner für alle Fragen der Informationssicherheit. Der ISB ist gewissermaßen der Motor des Systems, der die vielen Fäden zusammenhält.
Wichtig ist die richtige Aufhängung dieser Rolle. Der ISB sollte eine ausreichende Unabhängigkeit von der operativen IT besitzen, um Interessenkonflikte zu vermeiden – wer die IT betreibt, sollte nicht allein darüber urteilen, ob sie sicher genug ist. In größeren Organisationen ist der CISO deshalb häufig direkt bei der Leitung angesiedelt. Im Mittelstand wird die Rolle oft von einer Person mit mehreren Hüten wahrgenommen oder an einen externen ISB vergeben; entscheidend ist dann, dass die nötige Unabhängigkeit, das Mandat und die Ressourcen trotzdem gegeben sind. Der ISB entscheidet in der Regel nicht allein über die Behandlung von Risiken – er bereitet die Entscheidungen vor, die von der Leitung getragen werden.
Rund um Leitung und ISB gibt es weitere Rollen, die je nach Größe und Struktur der Organisation unterschiedlich stark ausgeprägt sind. Häufig anzutreffen sind:
Das Zusammenspiel dieser Rollen sollte dokumentiert und den Beteiligten bekannt sein. Ein bewährtes Hilfsmittel ist eine klare Zuordnung, wer für welche Aufgabe verantwortlich, mitwirkend, zu informieren oder zu konsultieren ist. Diese Klarheit verhindert das häufigste organisatorische Sicherheitsproblem: dass eine wichtige Aufgabe unerledigt bleibt, weil jeder annimmt, jemand anderes kümmere sich darum. Nicht die Zahl der Rollen entscheidet über die Wirksamkeit, sondern die Eindeutigkeit der Zuständigkeiten.
Viele Organisationen starten ihr ISMS mit den Werkzeugen, die sie ohnehin haben: Das Verzeichnis der Werte liegt als Tabelle vor, die Risikobewertung als weitere Tabelle, die Richtlinien als Textdokumente, die Nachweise verteilt in Ordnern. Für ein kleines, klar abgegrenztes ISMS ist das ein legitimer Einstieg, und niemand sollte sich vor der Werkzeugfrage vom Start abhalten lassen. Der Wert eines ISMS entsteht durch die Systematik, nicht durch die Software.
Mit wachsendem Geltungsbereich, mehr Beteiligten und der Notwendigkeit, Aktualität und Nachweisführung dauerhaft sicherzustellen, zeigt der Bordmittel-Ansatz jedoch typische Schwächen: Versionen laufen auseinander, Verknüpfungen zwischen Risiken, Maßnahmen und Nachweisen gehen verloren, Fristen werden übersehen und die Vorbereitung eines Audits wird zum manuellen Kraftakt. An diesem Punkt beginnt sich eine spezialisierte ISMS-Software zu rechnen, weil sie genau diese Schwächen adressiert.
Spezialisierte ISMS-Werkzeuge decken – in unterschiedlicher Tiefe und mit unterschiedlichen Schwerpunkten – ein wiederkehrendes Leistungsspektrum ab. Typische Funktionsbereiche sind:
Der Markt reicht dabei von schlanken, dokumentenzentrierten Lösungen über umfassende GRC-Plattformen, die neben dem ISMS auch weitere Compliance-Domänen abdecken, bis zu Werkzeugen, die stark auf die automatisierte Nachweisführung und die Vorbereitung von Zertifizierungen ausgerichtet sind. In der INAGRO-Wissensdatenbank finden sich zu einzelnen Vertretern dieser Kategorien eigene, herstellerneutrale Beiträge, an denen sich eine engere Auswahl orientieren kann.
Ein wachsender Teil der ISMS-Werkzeuge setzt auf Automatisierung: das automatische Sammeln von Nachweisen aus angebundenen Systemen, kontinuierliche Kontrollen des Ist-Zustands, Erinnerungen an fällige Überprüfungen und die Generierung von Berichten auf Knopfdruck. Der Nutzen ist erheblich, weil er die aufwendige und fehleranfällige Handarbeit reduziert, die sonst einen großen Teil des ISMS-Betriebs ausmacht – gerade die kontinuierliche Überwachung profitiert stark von der Automatisierung.
Zugleich ist Augenmaß geboten. Automatisierung ersetzt nicht das fachliche Urteil: Ob ein Risiko angemessen behandelt ist, ob eine Maßnahme wirksam greift und ob der Scope noch passt, sind Bewertungen, die Menschen treffen. Ein Werkzeug, das viele grüne Häkchen anzeigt, garantiert kein sicheres Unternehmen – es garantiert bestenfalls, dass die konfigurierten Prüfungen bestanden sind. Die Auswahl eines ISMS-Tools sollte deshalb nicht von der Zahl der Automatisierungen getrieben sein, sondern von der Frage, wie gut das Werkzeug die eigene Methodik, den gewählten Standard und die reale Systemlandschaft abbildet. Unsere Empfehlung lautet, das Tool als Verstärker einer soliden Methodik zu wählen – nicht als deren Ersatz.
Die Einführung eines ISMS ist ein strukturiertes Vorhaben, das typischerweise mehrere Monate in Anspruch nimmt – je nach Größe, Reifegrad und gewähltem Scope. Ein bewährtes Vorgehen führt von der Standortbestimmung über den Aufbau der tragenden Elemente bis zum eingespielten Betrieb. Entscheidend ist, dass am Ende ein gelebtes System steht und nicht nur ein Aktenordner voller Dokumente.
Strebt eine Organisation ein ISO-27001-Zertifikat an, prüft eine unabhängige, akkreditierte Zertifizierungsstelle das ISMS. Dieses externe Zertifizierungsaudit läuft in zwei Stufen ab:
Das Zertifikat ist anschließend in der Regel für einen mehrjährigen Zeitraum gültig, typischerweise drei Jahre. Während dieser Zeit finden jährliche Überwachungsaudits statt, die stichprobenartig prüfen, ob das ISMS weiterhin wirksam betrieben und kontinuierlich verbessert wird. Vor Ablauf des Gültigkeitszeitraums steht die Re-Zertifizierung an – ein erneutes, umfassenderes Audit, das den gesamten Zyklus wieder aufgreift. Dieser Rhythmus aus erstmaliger Zertifizierung, jährlicher Überwachung und regelmäßiger Re-Zertifizierung ist der äußere Ausdruck des PDCA-Gedankens.
Ein häufiges Missverständnis besteht darin, die Zertifizierung als das eigentliche Ziel zu betrachten. Sinnvoller ist es, das Zertifikat als externe Bestätigung eines ohnehin gelebten Systems zu verstehen. Wer ein ISMS allein für das Zertifikat aufbaut und die Substanz vernachlässigt, riskiert nicht nur Abweichungen im Audit, sondern verschenkt den eigentlichen Nutzen: die reale Verbesserung der Sicherheitslage. Umgekehrt gilt: Ein Unternehmen, das seine Informationssicherheit ernsthaft managt, wird das Audit ohne dramatische Überraschungen bestehen, weil das Zertifikat dann nur festhält, was ohnehin gelebt wird.
Für viele Organisationen ist das Zertifikat dennoch aus gutem Grund attraktiv: Es schafft Vertrauen bei Kunden, ist zunehmend eine Voraussetzung in Ausschreibungen und Lieferketten und liefert einen anerkannten Nachweis gegenüber Aufsichtsbehörden. Die Entscheidung, ob und wann eine Zertifizierung angestrebt wird, sollte jedoch bewusst getroffen werden – manche Organisationen betreiben ein wirksames ISMS ganz ohne Zertifikat, weil ihr Umfeld es nicht verlangt, und das ist ein legitimer Weg.
Der wichtigste Hebel für den Mittelstand liegt im bewussten Zuschnitt. ISO/IEC 27001 ist skalierbar: Die Norm verlangt ein angemessenes ISMS, nicht ein maximales. Ein kleineres Unternehmen mit klar abgegrenztem Scope, einer schlanken Dokumentation und wenigen, aber wirksamen Maßnahmen erfüllt die Anforderungen genauso wie ein Konzern mit umfangreichem Apparat – solange die Substanz stimmt. Der Schlüssel ist, nicht in vorauseilende Bürokratie zu verfallen, sondern nur so viel Dokumentation und Formalismus aufzubauen, wie die eigenen Risiken und die eigene Größe rechtfertigen.
In der Praxis bewährt sich ein schrittweises Vorgehen: mit einem überschaubaren Scope beginnen, die tragenden Elemente sauber aufsetzen und das System dann mit steigendem Reifegrad ausweiten. Der Versuch, von Beginn an das gesamte Unternehmen mit maximaler Tiefe abzubilden, überfordert kleine Teams regelmäßig und führt dazu, dass das ISMS zur ungeliebten Pflichtübung wird. Ein pragmatisch zugeschnittenes ISMS, das wirklich gelebt wird, ist jedem umfassenden System überlegen, das nur auf dem Papier existiert.
Ehrlicherweise verursacht ein ISMS Aufwand – vor allem in der Einführung und dann fortlaufend im Betrieb. Dieser Aufwand betrifft nicht nur die IT, sondern auch die Leitung, die Fachbereiche und die Sensibilisierung aller Mitarbeitenden. Der größte Hebel für den Mittelstand liegt darin, diesen Aufwand auf das Wesentliche zu konzentrieren: die Risiken zu adressieren, die den größten Schaden anrichten könnten, und die Maßnahmen mit dem besten Verhältnis von Wirkung zu Aufwand zuerst umzusetzen. Ein risikobasiertes ISMS ist genau darauf ausgelegt, Ressourcen dorthin zu lenken, wo sie am meisten bewirken.
Einen zusätzlichen Schub erhält das Thema durch die NIS2-Richtlinie der EU und ihre nationale Umsetzung. NIS2 weitet den Kreis der Unternehmen, die verpflichtende Anforderungen an ihre Cybersicherheit und ihr Risikomanagement erfüllen müssen, deutlich aus und betont die Verantwortung der Leitung. Für viele mittelständische Unternehmen, die bisher außerhalb solcher Regelungen standen, wird ein strukturiertes Informationssicherheits-Management damit von der Kür zur Pflicht. Ein ISMS nach ISO/IEC 27001 ist zwar nicht automatisch mit der Erfüllung von NIS2 gleichzusetzen, liefert aber einen etablierten, weithin anerkannten Rahmen, in dem sich die geforderten Maßnahmen strukturiert umsetzen und nachweisen lassen. Ob und in welchem Umfang ein Unternehmen konkret von NIS2 betroffen ist, ist eine Frage des Einzelfalls und sollte fachkundig geklärt werden.
Die NIS2-Richtlinie ist der derzeit prägende regulatorische Treiber für die Informationssicherheit in der EU. Sie verpflichtet einen deutlich erweiterten Kreis von Unternehmen und Einrichtungen zu einem angemessenen Risikomanagement in der Cybersicherheit, zu Meldepflichten bei Sicherheitsvorfällen und zu einer stärkeren Einbindung der Leitung. Die nationale Umsetzung konkretisiert, wer betroffen ist und welche Pflichten im Einzelnen gelten. Ein ISMS nach ISO/IEC 27001 ist zwar keine formale Voraussetzung von NIS2, bietet aber einen anerkannten Rahmen, in dem sich die geforderten Maßnahmen ordnen und belegen lassen – von der Risikoanalyse über die Vorfallbehandlung bis zur Kontinuitätsplanung.
Für Organisationen, die von NIS2 erfasst sind oder in der Lieferkette betroffener Unternehmen stehen, ist der Aufbau eines strukturierten Informationssicherheits-Managements deshalb ein naheliegender Schritt. Wichtig ist die Einordnung: Ein ISMS liefert die Struktur und die Nachweisfähigkeit, ersetzt aber nicht die rechtliche Prüfung der konkreten Pflichten. Die Frage, ob ein Unternehmen unter NIS2 fällt und welche Anforderungen im Detail gelten, gehört in fachkundige, juristische Hände.
Auch jenseits von NIS2 berühren mehrere Regelwerke die Informationssicherheit, und ein ISMS zahlt auf sie alle ein:
Der gemeinsame Nenner all dieser Regelwerke ist, dass sie ein strukturiertes, risikobasiertes und nachweisbares Management der Informationssicherheit voraussetzen oder belohnen. Wer ein wirksames ISMS betreibt, hat für keine dieser Anforderungen eine fertige Antwort in der Schublade – wohl aber ein Fundament, das die Erfüllung erheblich erleichtert und Doppelarbeit vermeidet. Statt für jede Vorgabe ein eigenes Silo aufzubauen, lohnt es sich, das ISMS als integrierende Klammer zu nutzen.
Die Ausführungen in diesem Kapitel und im gesamten Beitrag sind eine allgemeine fachliche Einordnung aus IT- und Projektsicht und keine Rechtsberatung. Ob und in welchem Umfang NIS2, DSGVO, TISAX, DORA oder andere Vorgaben auf eine konkrete Organisation anwendbar sind, welche Pflichten daraus im Einzelnen folgen und wie sie rechtssicher zu erfüllen sind, ist eine Frage des Einzelfalls. Diese Bewertung gehört in die Hände fachkundiger juristischer Beratung sowie – im Datenschutz – des Datenschutzbeauftragten.
Ein ISMS strukturiert, dokumentiert und macht die Informationssicherheit nachweisbar. Es nimmt der Organisation aber weder die Verantwortung noch die rechtliche Bewertung ab. Der Aufbau eines ISMS und die Klärung der regulatorischen Pflichten sollten deshalb Hand in Hand gehen – die Methodik liefert das eine, die fachkundige rechtliche Begleitung das andere.
