ISMS im Jahr 2026 - Pflichten nach KSC und KRI und die freiwillige ISO/IEC 27001

System, Richtlinie und Dokumentation

System, Leitlinie und Dokumentation sind keine Synonyme. Ein Managementsystem umfasst Menschen, Rollen, Prozesse, Ressourcen, Technologie, Dokumentation sowie Mechanismen zur Bewertung und Verbesserung. Die Leitlinie zur Informationssicherheit ist das übergeordnete Dokument, das die Richtung und die Verpflichtungen der Leitung vorgibt. Themenbezogene Richtlinien konkretisieren diese Grundsätze für einzelne Bereiche.

In einem ISO/IEC-27001-konformen System gehört die Festlegung einer Leitlinie zur Informationssicherheit zu den Anforderungen der Norm ^[1]. Das KSC folgt einer anderen Logik: Art. 8 verlangt unter anderem Richtlinien zur Risikobewertung und zur Sicherheit des Informationssystems, einschließlich themenbezogener Richtlinien, schreibt jedoch kein einheitliches amtliches Dokumentationsmuster vor ^[13].

Themenbezogene Richtlinien können sich beispielsweise auf Zugriffskontrolle, Kryptografie, Backups, Business Continuity, Remote-Arbeit, Lieferantensicherheit, Schwachstellenmanagement oder die Behandlung von Sicherheitsvorfällen beziehen. Eine Verfahrensbeschreibung definiert den Ablauf einer Tätigkeit, eine Arbeitsanweisung die konkrete Ausführung einer Aufgabe, und ein Register oder Nachweis dokumentiert das Ergebnis. Das übergeordnete Dokument sollte möglichst dauerhafte Grundsätze festlegen, während technische Details in Dokumenten verbleiben, die ohne grundlegende Überarbeitung der gesamten Richtlinie aktualisiert werden können. Dieses Thema wird im 4crypto-Beitrag zur Leitlinie zur Informationssicherheit vertieft.

Der Nachweis eines funktionierenden ISMS besteht nicht ausschließlich aus unterzeichneten Dokumenten. Ein Auditor kann auch technische Konfigurationen, Logs, Incident-Tickets, Stichproben vergebener Berechtigungen, Ergebnisse von Schwachstellenscans, Wiederherstellungstests, Sicherheitsprüfungen, Review-Protokolle und Interviews mit Beschäftigten bewerten. Ein IT-Sicherheitsaudit, Schwachstellenscans, Penetrationstests oder eine Härtungsprüfung können wichtige technische Nachweise liefern, ersetzen jedoch nicht die Bewertung des gesamten Managementsystems.

ISO/IEC 27001:2022 - was sich gegenüber der Ausgabe von 2013 tatsächlich geändert hat

ISO/IEC 27001:2022 hat die Ausgabe von 2013 ersetzt ^[1]. Die sichtbarste Änderung betrifft die Struktur des Referenzkatalogs der Sicherheitsmaßnahmen in Anhang A. Die aktuelle Ausgabe enthält 93 Maßnahmen in vier Gruppen: organisatorische, personenbezogene, physische und technologische Maßnahmen. Offizielle Materialien des ISO/IEC JTC 1/SC 27 nennen hierfür 37, 8, 14 beziehungsweise 34 Maßnahmen ^[3][4]. In der Ausgabe von 2013 war der Katalog anders strukturiert und umfasste 114 Einträge.

Aus dem bloßen Vergleich dieser Zahlen folgt jedoch nicht, dass das Anforderungsniveau gesunken wäre. Ein Teil der früheren Maßnahmen wurde zusammengeführt, neu geordnet oder anders beschrieben. In der Ausgabe von 2022 treten unter anderem Themen wie Bedrohungsinformationen, Cloud-Dienste, Konfigurationsmanagement, Datenmaskierung und die Überwachung von Aktivitäten deutlicher hervor ^[3][4]. ISO/IEC 27002:2022 enthält Leitlinien zu Sicherheitsmaßnahmen und ihrer Anwendung ^[3].

Im Jahr 2024 wurde außerdem Amendment 1 zu ISO/IEC 27001:2022 veröffentlicht, das die Berücksichtigung des Klimawandels bei der Analyse des Organisationskontexts betrifft ^[2]. Dadurch wird das ISMS nicht zu einem technischen System zur Reaktion auf Wetterereignisse. Zu beurteilen ist vielmehr, ob klimabezogene Aspekte für den Kontext der Organisation und die Erwartungen interessierter Parteien relevant sind, ebenso wie andere Faktoren, die das Managementsystem beeinflussen können.

In der Praxis ist daher nicht die Anzahl der Einträge in Anhang A entscheidend, sondern die Konsistenz zwischen Geltungsbereich, Risikobewertung, Entscheidungen zur Risikobehandlung, implementierten Sicherheitsmaßnahmen und den Nachweisen ihrer Wirksamkeit.

Kontinuierlicher Managementzyklus statt jährlicher Dokumentationsaktion

Ein ISMS sollte kontinuierlich betrieben werden. Die Organisation plant das System, implementiert Maßnahmen, überwacht deren Funktion, führt Bewertungen und Audits durch, reagiert auf Nichtkonformitäten und verbessert das System. Ein Zwölfmonatskalender kann organisatorisch sinnvoll sein, bedeutet jedoch nicht, dass jede Tätigkeit exakt einmal pro Jahr auszuführen ist.

Die Häufigkeit sollte sich aus der jeweiligen Tätigkeit, dem Risiko, Änderungen und den einschlägigen rechtlichen Anforderungen ergeben. Benutzerberechtigungen sind zu entziehen, sobald der Zugriffsbedarf entfällt, nicht erst im Rahmen eines jährlichen Reviews. Eine kritische Schwachstelle erfordert eine dem Risiko angemessene Reaktion und darf nicht bis zum nächsten Audit liegen bleiben. Die Häufigkeit von Backup-Wiederherstellungstests sollte sich aus der Kritikalität des Systems und den festgelegten Kontinuitätszielen ergeben.

Das Recht kann eigene Fristen vorgeben. Die geltende KRI-Verordnung verlangt mindestens einmal jährlich ein periodisches internes Audit der Informationssicherheit ^[11]. Das KSC verlangt einmal pro Kalenderjahr eine Schulung der Leitung einer wesentlichen oder wichtigen Einrichtung sowie der Person, der Leitungsaufgaben im Bereich Cybersicherheit übertragen wurden ^[13]. Das gesetzlich vorgeschriebene Audit nach Art. 15 KSC betrifft dagegen wesentliche Einrichtungen und ist mindestens alle drei Jahre, gerechnet ab dem letzten Audit, durchzuführen ^[13]. Es handelt sich um drei unterschiedliche Mechanismen, die nicht durch einen einzigen Eintrag im Jahresplan ersetzt werden können.

Für Messungen bietet ISO/IEC 27004:2016 ergänzende Leitlinien ^[6]. Dabei ist zu beachten, dass diese Ausgabe am 24. August 2026 weiterhin veröffentlicht ist, ISO jedoch an einer Nachfolgefassung arbeitet und die bestehende Ausgabe auf ISO/IEC 27001:2013 Bezug nimmt ^[6]. Dies zeigt, weshalb bei einer Implementierung nicht nur die Nummer einer Norm, sondern auch ihr Status und ihr Verhältnis zur aktuellen Ausgabe der Bezugsnorm geprüft werden müssen.

Anhang A und Erklärung zur Anwendbarkeit

Anhang A der ISO/IEC 27001 enthält einen Referenzkatalog von Sicherheitsmaßnahmen. Er ist jedoch keine Checkliste, die mechanisch vollständig abzuhaken wäre. Ausgangspunkt bleiben die Risiken, rechtlichen, vertraglichen und geschäftlichen Anforderungen sowie die Bedürfnisse der Organisation. ISO/IEC 27002:2022 unterstützt bei der Interpretation und Umsetzung der Maßnahmen ^[3], während ISO/IEC 27005:2022 Leitlinien zum Management von Informationssicherheitsrisiken enthält ^[5].

Erklärt eine Organisation die Konformität ihres ISMS mit ISO/IEC 27001, erstellt sie eine Erklärung zur Anwendbarkeit (Statement of Applicability, SoA). Dieses Dokument verknüpft Entscheidungen über Sicherheitsmaßnahmen mit der Risikobehandlung und zeigt, welche Maßnahmen angewendet werden und wie Entscheidungen zum Referenzkatalog begründet wurden ^[1]. Die SoA ist jedoch nicht als eigenständige Anforderung des KSC oder der KRI-Verordnung zu verstehen. Hat eine Organisation ISO/IEC 27001 nicht als Modell zum Nachweis ihrer Konformität gewählt, schaffen diese Rechtsvorschriften keine gesonderte Pflicht, ein Dokument mit der Bezeichnung "Erklärung zur Anwendbarkeit" zu führen.

Outsourcing entfernt ein Thema nicht aus dem Geltungsbereich des ISMS. Werden Backups, E-Mail, Monitoring, Cloud-Infrastruktur oder Incident Handling durch einen Dienstleister erbracht, ändern sich die Art der Umsetzung einer Maßnahme und die Verteilung der Verantwortlichkeiten. Die Organisation muss weiterhin die Risiken, vertraglichen Anforderungen, das Verantwortungsmodell, die Aufsicht und die Nachweise der Leistungserbringung kennen. Ein eigener oder externer SOC 24/7 kann wesentliche Nachweise für Monitoring und Incident Handling liefern. Die Nutzung eines SOC allein belegt jedoch nicht die Konformität des gesamten ISMS.

KRI im Jahr 2026 - ISMS-Pflicht ohne verpflichtendes ISO-Zertifikat

Am 24. August 2026 gilt die Verordnung des polnischen Ministerrats vom 21. Mai 2024 über den Nationalen Interoperabilitätsrahmen (KRI) ^[11]. Nach § 19 Abs. 1 muss eine Stelle, die öffentliche Aufgaben wahrnimmt, ein Informationssicherheitsmanagementsystem entwickeln, festlegen, implementieren und betreiben, überwachen und überprüfen sowie aufrechterhalten und verbessern.

§ 19 Abs. 2 enthält einen Katalog von Maßnahmen, die von der Leitung sicherzustellen sind. Dazu gehören unter anderem die Aktualisierung interner Regelungen, die Inventarisierung von Hard- und Software, Risikoanalysen, Berechtigungsmanagement, Schulungen, Informationsschutz, die Sicherheit von Remote- und mobiler Arbeit, Anforderungen an Wartungs- und Serviceverträge, Softwareaktualisierungen, Schwachstellenmanagement, die Meldung von Sicherheitsvorfällen sowie ein periodisches internes Audit mindestens einmal jährlich ^[11].

§ 19 Abs. 3 führt einen wichtigen Mechanismus ein. Die Anforderungen der Abs. 1 und 2 gelten als erfüllt, wenn das ISMS auf der Grundlage von PN-ISO/IEC 27001 entwickelt wurde und die Festlegung von Sicherheitsmaßnahmen sowie das Risikomanagement auf den dort genannten Polnischen Normen beruhen, darunter PN-ISO/IEC 27002 und PN-ISO/IEC 27005 ^[11]. Dies ist keine Pflicht zur Zertifizierung nach ISO/IEC 27001. Es handelt sich um einen rechtlich vorgesehenen Weg, die Erfüllung der KRI-Anforderungen durch Anwendung eines bestimmten normativen Modells nachzuweisen.

Eine Organisation kann die KRI-Anforderungen daher ohne ISO/IEC-27001-Zertifikat erfüllen. Sie muss die Anforderungen der Verordnung jedoch tatsächlich umsetzen und deren Erfüllung nachweisen können. In der Praxis sollte ein KRI-Audit anhand der Kriterien der Verordnung erfolgen, selbst wenn die Organisation parallel ein ISO/IEC-27001-konformes System betreibt.

Für das Jahr 2027 ist eine wichtige Einschränkung zu beachten. ELI weist aus, dass die derzeitige KRI-Verordnung am 23. Februar 2027 außer Kraft tritt ^[11]. Im Juli 2026 wurde der Entwurf einer neuen KRI-Verordnung unter der Kennzeichnung RD313 veröffentlicht ^[12]. Zum Bezugsdatum dieses Artikels handelt es sich um einen Entwurf und nicht um geltendes Recht. Die Beschreibung des § 19 der Verordnung von 2024 darf daher nicht automatisch auf die Rechtslage nach dem 23. Februar 2027 übertragen werden.

KSC nach dem 3. April 2026 - das ISMS als Pflicht wesentlicher und wichtiger Einrichtungen

Die KSC-Novelle zur Umsetzung von NIS2 trat am 3. April 2026 in Kraft ^[14][15]. Die aktuelle, von der Kanzlei des Sejm zum Stand vom 18. August 2026 konsolidierte Fassung des KSC berücksichtigt Dz.U. 2026 Pos. 20, 252, 815 und 1003 ^[13]. Dies ist insbesondere bei älteren Darstellungen relevant, die nur die Novelle unter Pos. 252 berücksichtigen.

Art. 8 Abs. 1 KSC verpflichtet eine wesentliche oder wichtige Einrichtung, ein ISMS in dem Informationssystem einzuführen, das in Prozessen eingesetzt wird, die die Erbringung ihrer Dienste beeinflussen ^[13]. Das Gesetz verknüpft dieses System mit einer systematischen Risikobewertung sowie mit angemessenen und verhältnismäßigen technischen und organisatorischen Maßnahmen.

Der gesetzliche Katalog ist umfangreich. Er umfasst unter anderem die Sicherheit bei Beschaffung, Entwicklung und Wartung von Systemen, physische Sicherheit und Personalsicherheit, Lieferkettensicherheit, Business Continuity und Wiederherstellung, kontinuierliches Monitoring des Informationssystems, die Bewertung der Wirksamkeit von Sicherheitsmaßnahmen, Schulung und Cyberhygiene, Kryptografie, sichere Kommunikation, Multi-Faktor-Authentisierung in geeigneten Fällen, Asset Management, Zugriffskontrolle, Informationen über Cyberbedrohungen und Schwachstellen, Incident Management sowie Softwareaktualisierungen ^[13].

Daran zeigt sich der Unterschied zwischen dem bloßen "Vorhandensein einer Richtlinie" und der tatsächlichen Erfüllung des KSC. Die Dokumentation muss den realen organisatorischen und technischen Maßnahmen entsprechen. Verlangt eine Richtlinie beispielsweise kontinuierliches Monitoring, erzeugen kritische Systeme aber keine geeigneten Logs oder analysiert niemand die Alarme, liegt kein redaktionelles Problem vor. Es handelt sich um eine Lücke in der Funktionsweise des Systems.

Das KSC enthält außerdem Sonderregelungen. Wichtige Einrichtungen des öffentlichen Sektors sowie bestimmte in Art. 8 Abs. 3 genannte Hochschulen wenden Art. 8 Abs. 1 nicht in seiner regulären Form an, sondern betreiben ein ISMS, das die Anforderungen des Anhangs 4 erfüllt ^[13]. Eine öffentliche Stelle muss in ihrem ISMS außerdem ein von einer anderen öffentlichen Stelle bereitgestelltes Informationssystem in dem Umfang berücksichtigen, der sich aus der Sicherheitsleitlinie dieses Systems oder aus den für seinen Betrieb geltenden Vorschriften ergibt ^[13].

Zusätzliche Anforderungen können unmittelbar aus dem Unionsrecht folgen. Art. 8b KSC nennt unter anderem Anbieter von DNS-Diensten, Cloud-Computing-Diensten, Rechenzentrumsdiensten, Inhaltszustellnetzen, verwalteten Diensten und verwalteten Sicherheitsdiensten, die die in der Durchführungsverordnung (EU) 2024/2690 der Kommission festgelegten Maßnahmen zum Management von Cybersicherheitsrisiken anwenden ^[13][16]. Für diese Einrichtungen reicht eine bloße Zuordnung der ISO/IEC 27001 zum KSC nicht aus, weil zusätzlich die detaillierten unionsrechtlichen Anforderungen berücksichtigt werden müssen.

Verantwortung der Leitung nach dem KSC

Das KSC weist die Verantwortung ausdrücklich der Leitung einer wesentlichen oder wichtigen Einrichtung zu. Nach Art. 8c verbleibt die Verantwortung bei der Leitung, auch wenn einzelne oder sämtliche Pflichten einer anderen Person übertragen wurden ^[13]. Art. 8d verbindet die Leitungsverantwortung unter anderem mit Entscheidungen über Vorbereitung, Einführung, Anwendung, Überprüfung und Aufsicht des ISMS, mit der Finanzplanung und mit der Aufgabenzuweisung ^[13].

Dies hat eine praktische Konsequenz: Ein externer Berater, Administrator, Sicherheitskoordinator oder SOC-Dienstleister kann operative Aufgaben übernehmen, aber nicht die gesetzliche Verantwortung der Leitung für das KSC. Ebenso sollte die Gesamtverantwortung für das ISMS nicht automatisch dem Datenschutzbeauftragten übertragen werden. Die DSGVO gestattet dem Datenschutzbeauftragten weitere Aufgaben, der Verantwortliche oder Auftragsverarbeiter muss jedoch sicherstellen, dass daraus kein Interessenkonflikt entsteht ^[18].

Das KSC sieht außerdem eine jährliche Schulung der Leitung und der Person vor, der Leitungsaufgaben im Bereich Cybersicherheit übertragen wurden; die Teilnahme ist zu dokumentieren ^[13]. Schulungen der Beschäftigten und Security Awareness sind davon zu unterscheiden. Sie sollten sich aus Risiko und Funktion der jeweiligen Person ergeben und sich nicht auf die einmalige Unterschrift unter einer Teilnehmerliste beschränken.

Fristen des KSC für Einrichtungen, die von der Reform 2026 erfasst werden

Für Einrichtungen, die bereits am 3. April 2026 die Voraussetzungen für die Einstufung als wesentliche oder wichtige Einrichtung erfüllten, sieht Art. 33 des Änderungsgesetzes zwölf Monate für die Umsetzung der Pflichten aus Kapitel 3 KSC vor ^[14]. Daraus ergibt sich der 3. April 2027 als Frist.

Einrichtungen, die am Tag des Inkrafttretens der Novelle die Voraussetzungen einer wesentlichen Einrichtung erfüllten, haben 24 Monate für das erste Audit nach Art. 15 Abs. 1 KSC, also bis zum 3. April 2028 ^[14]. Die Übergangsvorschriften enthalten jedoch Sonderregelungen für Einrichtungen, die zuvor Betreiber wesentlicher Dienste waren. Bei einer konkreten Einrichtung müssen daher ihr früherer Status und ihre Audithistorie berücksichtigt werden.

Erfüllt eine Einrichtung die Voraussetzungen erst zu einem späteren Zeitpunkt, werden die Fristen nach dem im KSC selbst vorgesehenen Mechanismus berechnet. Art. 16 sieht zwölf Monate für die Umsetzung der Pflichten aus Kapitel 3 und für wesentliche Einrichtungen 24 Monate bis zum ersten Audit vor, jeweils gerechnet ab dem Tag, an dem die Voraussetzungen erfüllt sind ^[13].

Der 3. April 2027 ist deshalb keine universelle Frist für jede Organisation, die irgendwann in den Anwendungsbereich des KSC fällt.

KSC-Audit, KRI-Audit und ISO-Audit sind unterschiedliche Prüfungen

Ein häufiger Fehler besteht darin, den Begriff "Audit" zu verwenden, ohne die zugrunde liegenden Kriterien zu benennen. Ein KRI-Audit prüft die Anforderungen der einschlägigen Verordnung. Das gesetzliche KSC-Audit nach Art. 15 besitzt eine eigene Rechtsgrundlage, einen eigenen Umfang, eine eigene Häufigkeit und besondere Anforderungen an die Auditoren ^[13]. Ein internes Audit eines ISO/IEC-27001-konformen Systems dient dagegen der Bewertung von Konformität und Wirksamkeit anhand der Kriterien des festgelegten Auditprogramms ^[1][8].

Art. 15 Abs. 2a KSC schließt darüber hinaus aus, dass das gesetzlich vorgeschriebene Audit von einer Person durchgeführt wird, die in der geprüften Einrichtung Aufgaben nach Art. 8 sowie Art. 9-13 wahrnimmt oder innerhalb eines Jahres vor Beginn des Audits wahrgenommen hat ^[13]. Diese Vorgabe ist konkreter als die allgemeine Anforderung an die Objektivität eines Managementsystemaudits.

Für Auditprogramme von Managementsystemen ist ISO 19011:2026 die aktuelle allgemeine Norm. Sie wurde im Mai 2026 veröffentlicht und ersetzte die Ausgabe von 2018 ^[7]. Ergänzende Leitlinien für Audits von Informationssicherheitsmanagementsystemen enthält ISO/IEC 27007:2020 ^[8]. Am 24. August 2026 ist ISO/IEC 27007:2020 weiterhin veröffentlicht, befindet sich jedoch in Revision ^[8].

Beauftragt eine Organisation ein externes KRI-Audit, ein KSC- und NIS2-Audit oder ein IT-Sicherheitsaudit, sollten die Prüfkriterien daher bereits im Vertrag und später im Bericht eindeutig benannt werden. Aus der Bezeichnung der Dienstleistung sollte hervorgehen, ob Rechtsvorschriften, eine Norm, der technische Zustand der Infrastruktur oder mehrere dieser Bereiche in klar getrennten Prüfungsumfängen bewertet werden.

Konformität mit ISO/IEC 27001 und Zertifizierung

Gesetzliche Verpflichtung, Normkonformität und Zertifizierung sind unterschiedliche Begriffe. Nach dem polnischen Normungsgesetz ist die Anwendung Polnischer Normen grundsätzlich freiwillig ^[17]. Eine Organisation kann ein auf ISO/IEC 27001 basierendes ISMS daher aus eigener Entscheidung, aufgrund einer Kunden- oder Vertragsanforderung, zur Strukturierung ihres Managements oder mit dem Ziel einer Zertifizierung einführen.

Konformität mit der Norm ohne Zertifizierung bedeutet, dass die Organisation die Anforderungen umgesetzt hat und ihr System bewertet, jedoch keine Zertifizierungsentscheidung einer externen Zertifizierungsstelle besitzt. Die Zertifizierung ist ein eigenständiger Konformitätsbewertungsprozess. Die Akkreditierung betrifft die Kompetenz der Konformitätsbewertungsstelle und nicht die Organisation, die das ISMS betreibt.

Weder § 19 KRI noch Art. 8 KSC begründen eine allgemeine Pflicht zum Besitz eines ISO/IEC-27001-Zertifikats ^[11][13]. Ein Zertifikat kann allerdings durch einen konkreten Vertrag oder ein Vergabeverfahren verlangt werden. Seine Bedeutung ergibt sich dann aus dieser konkreten Verpflichtung und nicht allein aus der Existenz der Norm.

Ein Zertifikat ist außerdem kein automatischer Nachweis dafür, dass sämtliche Pflichten aus KSC oder KRI erfüllt sind. Der Geltungsbereich des zertifizierten ISMS kann von dem Umfang der gesetzlich erfassten Systeme abweichen. Das Recht kann zudem Maßnahmen verlangen, die in der Norm nicht in gleicher Weise formuliert sind, beispielsweise gesetzliche Incident-Meldungen, ein bestimmtes KSC-Audit oder Pflichten im Zusammenhang mit dem Verzeichnis der erfassten Einrichtungen.

Wie aufwendig ist die Einführung eines ISMS?

Es gibt keinen belastbaren universellen Schlüssel nach dem Muster "eine Woche je 50 Beschäftigte". Die Zahl der Beschäftigten beeinflusst das Projekt, ist jedoch häufig nicht die wichtigste Variable. Ein kleines Unternehmen kann mehrere Cloud-Umgebungen, eigene Software, eine komplexe Lieferkette und einen 24/7-Dienst betreiben. Eine große Organisation kann dagegen eine vergleichsweise einfache Architektur und gut etablierte Prozesse besitzen.

Der Aufwand hängt vor allem vom Geltungsbereich des ISMS, der Zahl der Dienste und Standorte, der Systemarchitektur, den Abhängigkeiten von Lieferanten, den rechtlichen und vertraglichen Anforderungen, der Qualität der Asset-Inventarisierung, der Reife des Risikomanagements, dem Zustand der Dokumentation und der Verfügbarkeit der Prozesseigner ab.

ISO/IEC 27003:2017 ist am 24. August 2026 weiterhin als Norm mit Implementierungsleitlinien veröffentlicht. Die offizielle Beschreibung bezieht sie jedoch auf ISO/IEC 27001:2013, und ISO arbeitet an einer Revision ^[9]. Sie kann deshalb weiterhin methodisch hilfreich sein, sollte aber nicht ohne Einschränkung als aktueller Leitfaden für jedes Detail einer Implementierung nach ISO/IEC 27001:2022 dargestellt werden.

Bei Einführungsprojekten ist eine sinnvolle Reihenfolge: zunächst die rechtliche Einordnung und die Festlegung des Geltungsbereichs, anschließend eine Gap-Analyse und erst danach Zeitplan und Aufwandsschätzung. So lassen sich gesetzlich erforderliche Arbeiten von freiwilligen Zertifizierungszielen trennen. Externe Unterstützung bei einem ISMS kann die Methodik strukturieren und eine unabhängige Perspektive bieten, ersetzt jedoch weder Entscheidungen der Leitung noch das Wissen der Prozesseigner.

Wie organisatorische Anforderungen mit Technik verbunden werden

Ein ISMS darf nicht auf Regelwerke beschränkt bleiben. Eine Anforderung zum Zugriffsmanagement muss sich im Prozess zur Einrichtung, Änderung und Entziehung von Konten sowie in periodischen Berechtigungsreviews wiederfinden. Eine Anforderung zum Schwachstellenmanagement muss zu definierten Informationsquellen, einem Prozess zur Bewertung und Priorisierung, zur Behebung sowie zur anschließenden Verifikation führen. Anforderungen an Business Continuity müssen mit realen Backups, Wiederherstellungszielen und Tests verknüpft sein.

Dasselbe gilt für Monitoring. Die zentrale Sammlung von Logs ist kein Selbstzweck. Es ist festzulegen, welche Ereignisse relevant sind, welche Quellen überwacht werden müssen, welche Alarme eine Reaktion erfordern, wer reagiert und wie Nachweise aufbewahrt werden. Ein SOC 24/7 kann einen Teil dieser operativen Funktion übernehmen, muss jedoch in die Incident-Prozesse und das Verantwortungsmodell der Organisation eingebettet sein.

Schwachstellenscans und Penetrationstests erfüllen ebenfalls unterschiedliche Aufgaben. Ein Scan unterstützt die systematische Erkennung bestimmter Klassen bekannter Schwachstellen. Ein Penetrationstest untersucht, ob ausgewählte Schwachstellen in einem definierten Szenario ausnutzbar sind und welche Auswirkungen daraus entstehen können. Härtung reduziert die Angriffsfläche durch eine sicherere Konfiguration. Keine dieser Maßnahmen stellt für sich allein "Konformität" her. Jede kann jedoch Bestandteil der Risikobehandlung sein und Nachweise für die Wirksamkeit konkreter Sicherheitsmaßnahmen liefern.

Häufige Fehler

1. Reduktion des Systems auf Dokumentation. Weiß ein Beschäftigter nicht, wie Informationen zu klassifizieren sind, kennt der Administrator den Prozess zur Behandlung von Schwachstellen nicht und kann der Systemeigner nicht benennen, welches Risiko er akzeptiert hat, dann belegen unterschriebene Richtlinien keine funktionierende Umsetzung. Sie sind allenfalls eine Erklärung, dass ein Prozess existieren soll.
2. Unklare Verantwortlichkeiten. Die Leitung sollte Prozesseigner, Risikoeigner und Verantwortliche für Sicherheitsmaßnahmen sowie deren Entscheidungsbefugnisse festlegen. Im KSC ist die Verantwortung der Leitung zusätzlich ausdrücklich gesetzlich geregelt ^[13].
3. Vermischung der Prüfkriterien. KSC-, KRI- und ISO/IEC-27001-Audits sind nicht austauschbar. Ein ISO-Zertifikat ersetzt kein gesetzliches KSC-Audit, und ein technischer Penetrationstest ersetzt kein ISMS-Audit.
4. Zu schwache Verknüpfung von Risiken und Entscheidungen. Ein Risikoregister ist dann wertvoll, wenn daraus Entscheidungen folgen: Risiko vermeiden, reduzieren, übertragen, bewusst akzeptieren oder auf andere begründete Weise behandeln. Eine einmalige Bewertung, die nach einer Architekturänderung nicht aktualisiert wird, verliert schnell ihre Aussagekraft.
5. Fehlende aussagekräftige Messgrößen. Es geht nicht darum, Kennzahlen nur für einen Bericht zu erzeugen. Eine Messung sollte dabei helfen zu beantworten, ob eine Sicherheitsmaßnahme oder ein Prozess das beabsichtigte Ziel erreicht. Beispielsweise können die Zeit bis zum Entzug von Berechtigungen nach Beendigung einer Zusammenarbeit, der Anteil durchgeführter Wiederherstellungstests, die Bearbeitungszeit kritischer Schwachstellen oder die Abdeckung relevanter Systeme durch das geforderte Monitoring gemessen werden. Eine Kennzahl ist nur dann sinnvoll, wenn sie mit einer Entscheidung verknüpft ist.
6. Audit der eigenen Arbeit. Objektivität verlangt eine Aufgabenverteilung, bei der eine Person Lösungen, für deren Entwurf und Umsetzung sie selbst verantwortlich ist, nicht unkritisch bewertet. Beim gesetzlichen KSC-Audit ist diese Einschränkung noch präziser und ergibt sich aus Art. 15 Abs. 2a ^[13]. Hinweise zu Objektivität und Auditprogrammen von Managementsystemen enthalten ISO 19011:2026 und ISO/IEC 27007:2020 ^[7][8].
7. Managementbewertung als bloße Unterschrift. Eine Managementbewertung sollte zu Entscheidungen über Änderungen, Ressourcen, Risiken und Verbesserungsmaßnahmen führen. Ein Protokoll ohne Entscheidungen und ohne Nachverfolgung ihrer Umsetzung besitzt nur begrenzten Wert.
8. GRC-Werkzeuge als vermeintliches Managementsystem. Software kann Teile der Nachweiserhebung, Erinnerungen, Anforderungsmappings und Konfigurationsüberwachung automatisieren. Sie entscheidet jedoch nicht automatisch, ob der Geltungsbereich korrekt festgelegt wurde, ob Risiken angemessen bewertet sind oder ob eine konkrete Sicherheitsmaßnahme im jeweiligen Kontext wirksam ist.
9. Sprachmodelle ohne Verifikation. Sie können beim ersten Entwurf eines Dokuments, bei Auditfragen oder bei einer vorläufigen Zuordnung von Anforderungen unterstützen. Das Ergebnis muss jedoch anhand der tatsächlich gelebten Prozesse und der Primärquellen verifiziert werden. Ein Dokument, das einen in der Organisation nicht existierenden Prozess beschreibt, verschlechtert die Qualität des Systems, weil es einen falschen Konformitätsnachweis erzeugt.

Integrationsmöglichkeiten

Managementsysteme können integriert werden, wenn dies für die Organisation sinnvoll ist. Informationssicherheit lässt sich mit Datenschutzmanagement und Business Continuity Management verbinden. Im Bereich Datenschutz ist ISO/IEC 27701:2025 die aktuelle Ausgabe; sie hat die Ausgabe von 2019 ersetzt ^[10]. Für Business Continuity bleibt ISO 22301:2019 mit Amendment 1:2024 ein Bezugspunkt, wobei ISO bereits an einer neuen Ausgabe arbeitet ^[19].

Integration bedeutet jedoch nicht, dass ein einziger Dokumentensatz automatisch sämtliche Rechtsvorschriften erfüllt. Die DSGVO enthält eigene rechtliche Anforderungen für die Verarbeitung personenbezogener Daten ^[18]. Das KSC besitzt einen eigenen persönlichen und sachlichen Anwendungsbereich sowie eigene Pflichten ^[13]. Die KRI-Verordnung enthält eigene Kriterien ^[11]. Gemeinsame Prozesse können Doppelarbeit reduzieren, die Konformitätsbewertung muss jedoch weiterhin anhand des jeweils einschlägigen Regelwerks erfolgen. Siehe auch das DSGVO-Audit.