Was NIS2 tatsächlich verlangt und was nicht

NIS2 enthält keine allgemeingültige Einkaufsliste für Technologie. Die Richtlinie sagt nicht, dass jede Organisation eine Plattform für Identity Governance kaufen, ein bestimmtes Sicherheits-Framework übernehmen, einen vorgeschriebenen Satz an Protokollfeldern führen oder dieselben Kontrollen auf dieselbe Weise einsetzen muss. Sie verlangt, dass wesentliche und wichtige Einrichtungen Cybersicherheitsrisiken mit geeigneten und verhältnismäßigen technischen, operativen und organisatorischen Maßnahmen beherrschen, und sie macht die Leitungsorgane dafür verantwortlich, diese Maßnahmen zu billigen und ihre Umsetzung zu überwachen.

Dieser Unterschied ist entscheidend. Ein Unternehmen kann moderne Sicherheitsprodukte einsetzen und trotzdem nicht belegen, dass seine Risiken verstanden sind, seine Kontrollen wirken, Sicherheitsvorfälle fristgerecht gemeldet und Korrekturmaßnahmen abgeschlossen werden. Eine andere Organisation kann einfachere Kontrollen nutzen und dennoch ein belastbares Programm aufbauen, wenn diese Kontrollen ihren Risiken angemessen sind, konsequent betrieben werden und durch Nachweise belegt sind.

Dieser Leitfaden trennt den Text der Richtlinie (EU) 2022/2555 von der detaillierteren Durchführungsverordnung (EU) 2024/2690 der Kommission, erläutert, wo Identity- und Access-Governance ihren Platz hat, und gibt Leitung und Sicherheitsteams einen praktischen Plan für Nachweise an die Hand. Der Leitfaden beruht auf den geltenden EU-Vorschriften und offiziellen Leitlinien, geprüft am 12. September 2026. Da NIS2 eine Richtlinie ist, die durch nationales Recht umgesetzt wird, muss eine Organisation außerdem das Recht und die Leitlinien der zuständigen Behörden in jedem Mitgliedstaat prüfen, der für ihre Tätigkeit relevant ist.

Die kürzeste zutreffende Antwort: NIS2 verlangt risikobasierte Steuerung, zehn Mindestbereiche des Cybersicherheitsrisikomanagements, eine gestufte Meldung erheblicher Sicherheitsvorfälle, Aufsicht durch die Leitungsorgane und Nachweise, dass die Maßnahmen umgesetzt sind. Sie nennt Konzepte für die Zugriffskontrolle sowie Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung. Sie schreibt kein bestimmtes Produkt, kein bestimmtes Rollenmodell und kein allgemeingültiges Protokollierungsschema vor.

Zuerst die Anwendbarkeit, nicht die Compliance-Checkliste

Die erste Frage ist, ob die Organisation in den Anwendungsbereich fällt. Die Europäische Kommission beschreibt NIS2 als Rahmen, der 18 kritische Sektoren abdeckt. Grundsätzlich gilt die Richtlinie für mittlere und große öffentliche oder private Einrichtungen einer in Anhang I oder Anhang II genannten Art, die ihre Dienste in der Union erbringen oder ihre Tätigkeiten dort ausüben. Zu den erfassten Bereichen gehören Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheitswesen, Trinkwasser, Abwasser, digitale Infrastruktur, Verwaltung von IKT-Diensten, öffentliche Verwaltung, Weltraum, Post- und Kurierdienste, Abfallbewirtschaftung, Chemie, Lebensmittel, verarbeitendes Gewerbe, Anbieter digitaler Dienste und Forschung.

Die Größe ist nur die Ausgangsregel. Artikel 2 enthält Fälle, die unabhängig von der Größe gelten, darunter bestimmte Anbieter elektronischer Kommunikation, Vertrauensdiensteanbieter, TLD-Namenregister und DNS-Diensteanbieter. Erfasst sind außerdem einzige Anbieter bestimmter wesentlicher Dienste, Einrichtungen, bei denen eine Störung wesentliche Auswirkungen auf die öffentliche Sicherheit, die öffentliche Ordnung oder die öffentliche Gesundheit haben könnte, Einrichtungen mit erheblichen Systemrisiken sowie Einrichtungen, die wegen ihrer nationalen oder regionalen Bedeutung benannt werden. Kritische Einrichtungen, die nach der Richtlinie (EU) 2022/2557 ermittelt wurden, sind unabhängig von ihrer Größe erfasst. Die Mitgliedstaaten können den Anwendungsbereich zum Teil auch ausweiten, unter anderem auf Einrichtungen der öffentlichen Verwaltung auf lokaler Ebene und bestimmte Bildungseinrichtungen.

Eine Entscheidung über die Anwendbarkeit braucht deshalb Nachweise, keine schnelle Zuordnung zu einem Sektor. Dokumentieren Sie:

1. die beteiligten juristischen Personen und Mitgliedstaaten;
2. die Dienste, die jede Einrichtung in der Union erbringt;
3. die Kategorie aus Anhang I oder Anhang II, die zutreffen könnte;
4. die Beschäftigten- und Finanzdaten für die Größenprüfung;
5. jede Benennung, Registrierung oder Mitteilung, die Sie von einer Behörde erhalten haben;
6. jeden sektorspezifischen Rechtsakt der Union, der gleichwertige Bestimmungen von NIS2 nach Artikel 4 ersetzen kann; und
7. das nationale Recht und die Leitlinien der Aufsicht, auf die sich die Schlussfolgerung stützt.

Diese Dokumentation sollte eine verantwortliche Person aus dem Rechtsbereich und ein Überprüfungsdatum haben. Unternehmensstrukturen, Dienste und nationale Umsetzung können sich ändern. Im Januar 2026 hat die Europäische Kommission gezielte Änderungen vorgeschlagen, die Teile des Rahmens für Cybersicherheit vereinfachen und NIS2 präzisieren sollen. Ein Vorschlag ist kein verabschiedetes Recht. Teams sollten das Gesetzgebungsverfahren beobachten, ohne vorgeschlagene Formulierungen als geltende Pflicht zu behandeln.

Wesentlich oder wichtig heißt weder konform noch ausgenommen

NIS2 unterscheidet bei den erfassten Organisationen zwischen wesentlichen Einrichtungen und wichtigen Einrichtungen. Artikel 3 legt die Regeln für die Einstufung fest. Der praktische Unterschied zeigt sich vor allem in der Aufsicht. Die zuständigen Behörden können wesentliche Einrichtungen proaktiven und reaktiven Maßnahmen unterziehen, darunter Vor-Ort-Kontrollen, regelmäßige oder gezielte Sicherheitsprüfungen, Sicherheitsscans und Anforderungen von Nachweisen. Artikel 33 beschreibt die Aufsicht über wichtige Einrichtungen als nachträglich (ex post): Die Behörde wird tätig, wenn ihr Nachweise, Hinweise oder Informationen vorliegen, die auf einen Verstoß hindeuten.

Beide Kategorien müssen die zentralen Pflichten zum Risikomanagement und zur Meldung von Sicherheitsvorfällen nach den Artikeln 21 und 23 erfüllen. „Wichtig“ ist also keine mildere Einstufung, die Kontrollen überflüssig macht. Die Einstufung ändert das Aufsichtsmodell und einige Details der Durchsetzung.

Das Leitungsorgan verantwortet Entscheidung und Aufsicht

Artikel 20 holt NIS2 aus der Sicherheitsabteilung heraus. Die Mitgliedstaaten müssen sicherstellen, dass die Leitungsorgane wesentlicher und wichtiger Einrichtungen die Risikomanagementmaßnahmen im Bereich der Cybersicherheit billigen, die zur Einhaltung von Artikel 21 ergriffen werden, ihre Umsetzung überwachen und für Verstöße der Einrichtung verantwortlich gemacht werden können, vorbehaltlich der nationalen Haftungsvorschriften. Die Mitglieder dieser Leitungsorgane müssen an Schulungen teilnehmen. Die Mitgliedstaaten müssen Organisationen außerdem dazu ermutigen, ihren Mitarbeitenden regelmäßig entsprechende Schulungen anzubieten.

Für die Leitung sollte Billigung mehr bedeuten als die Unterschrift unter eine Richtlinie. Eine aussagekräftige Dokumentation des Leitungsorgans beantwortet fünf Fragen:

• Welche wesentlichen Cyberrisiken bedrohen die Dienste, durch die wir in den Anwendungsbereich fallen?
• Welche Maßnahmen verringern jedes Risiko, und warum sind sie verhältnismäßig?
• Wer ist für die Maßnahmen und das verbleibende Risiko verantwortlich?
• Woran erkennen wir, dass die Maßnahmen wirksam sind?
• Welche Lücken, Ausnahmen und überfälligen Maßnahmen hat die Leitung akzeptiert?

Ein Dashboard, das nur die Zahl abgewehrter Angriffe meldet, kann diese Fragen nicht beantworten. Das Leitungsorgan braucht Kennzahlen, die sich am Risiko für die Dienste orientieren: abgeschlossene Wiederherstellungstests, kritische Schwachstellen außerhalb ihrer Fristen, privilegierte Konten ohne aktuelle verantwortliche Person, ausgeschiedene Mitarbeitende, deren Zugriffsrechte nicht rechtzeitig entzogen wurden, Dienstleister ohne vereinbarte Sicherheitspflichten, überfällige Zugriffsüberprüfungen, Übungen zu Sicherheitsvorfällen und offene Prüfungsfeststellungen. Die Organisation muss die Entscheidungen hinter Ausnahmen ebenso aufbewahren wie die Ausnahmen selbst.

Artikel 21. Die zehn Mindestbereiche und ihre Nachweise.

Artikel 21 beginnt mit einem Grundsatz: Die Maßnahmen müssen dem Risiko angemessen und verhältnismäßig sein. Sie müssen den Stand der Technik, gegebenenfalls einschlägige Normen, die Umsetzungskosten, das Ausmaß der Risikoexposition, die Größe, die Wahrscheinlichkeit und Schwere von Sicherheitsvorfällen sowie deren mögliche gesellschaftliche und wirtschaftliche Auswirkungen berücksichtigen. Die Maßnahmen beruhen auf einem gefahrenübergreifenden Ansatz und schützen sowohl die Netz- und Informationssysteme als auch deren physische Umwelt.

Die Richtlinie nennt anschließend zehn Mindestbereiche. Die folgende Tabelle hält die rechtlichen Kategorien von praktischen Nachweisen getrennt. Die Beispiele für Nachweise sind Umsetzungshinweise, kein zusätzlicher Rechtstext.

Entscheidend ist das Wort „zumindest“ in Artikel 21 Absatz 2. Die Liste setzt dem Programm keine Obergrenze. Eine Risikobewertung kann zusätzliche Maßnahmen rechtfertigen. Ebenso wichtig ist das Wort „verhältnismäßig“: Es verhindert, dass Teams eine generische Checkliste übernehmen, ohne ihre Dienste und ihre Risikoexposition zu berücksichtigen. Ein Kontrollkatalog wird belastbar, wenn jede Kontrolle einen Zweck, eine verantwortliche Person, einen Geltungsbereich, ein Betriebsverfahren, einen Test und ein aufbewahrtes Ergebnis hat.

Was NIS2 nicht verlangt

Unterlagen von Anbietern machen aus guter Sicherheitspraxis oft vermeintlichen Gesetzeswortlaut. Dadurch lässt sich die Anforderung leichter verkaufen und schwerer verteidigen. Die folgenden Behauptungen müssen richtiggestellt werden.

„NIS2 schreibt vor, welche Felder jedes Sicherheitsprotokoll enthalten muss“

Die Richtlinie schreibt keinen allgemeingültigen Satz von Protokollfeldern für jede erfasste Organisation vor. Artikel 21 Absatz 2 legt Bereiche des Risikomanagements fest, kein gemeinsames Schema für Ereignisprotokolle. Die Richtlinie verlangt allerdings die Bewältigung von Sicherheitsvorfällen und die Bewertung der Wirksamkeit von Maßnahmen, was bei einem risikobasierten Konzept in der Praxis eine Protokollierung erforderlich machen kann. Das ist eine Schlussfolgerung auf Ebene der Kontrollen, kein allgemeingültiges Protokollierungsschema im Text der Richtlinie.

Detaillierte Anforderungen an die Protokollierung stehen im Anhang der Durchführungsverordnung (EU) 2024/2690. Diese Verordnung verlangt von den betreffenden Einrichtungen, Verfahren festzulegen und Werkzeuge einzusetzen, um Aktivitäten in ihren Netz- und Informationssystemen zu überwachen und zu protokollieren, und sie nennt Elemente, die Protokolle gegebenenfalls enthalten sollten. Ihr Artikel 1 bindet jedoch nur einen festgelegten Kreis: DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten und Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste und verwalteter Sicherheitsdienste, Online-Marktplätze, Online-Suchmaschinen, Plattformen für Dienste sozialer Netzwerke und Vertrauensdiensteanbieter.

Dieser Kreis umfasst nicht jedes Krankenhaus, jeden Hersteller, jedes Energieunternehmen oder jede Organisation des öffentlichen Sektors, die unter NIS2 fällt. Für andere Einrichtungen können detaillierte nationale oder sektorale Vorschriften gelten, und eine gute Erkennung von Sicherheitsvorfällen braucht in der Regel geeignete Protokolle. Die zutreffende Aussage lautet: Die Richtlinie legt das Ergebnis fest; die Durchführungsverordnung von 2024 liefert verbindliche technische Details für die dort aufgeführten digitalen Einrichtungen; nationales Recht und Risikoanalyse bestimmen den Rest.

„NIS2 schreibt eine IGA-Plattform vor“

Das tut sie nicht. Artikel 21 Absatz 2 Buchstabe i nennt ausdrücklich die Sicherheit des Personals, Konzepte für die Zugriffskontrolle und das Management von Anlagen. Artikel 21 Absatz 2 Buchstabe j nennt Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung und gesicherte Kommunikation, soweit angemessen. Keine der beiden Bestimmungen nennt ein Produkt für Identity Governance and Administration.

Eine IGA-Plattform kann einer Organisation helfen, Ergebnisse der Zugriffskontrolle über viele Systeme hinweg umzusetzen und nachzuweisen. Ihr bloßes Vorhandensein macht die Organisation nicht konform. Die Organisation braucht weiterhin korrekte Quelldaten, verantwortliche Personen, verhältnismäßige Richtlinien, funktionierende Konnektoren, getesteten Entzug von Zugriffsrechten, eine Behandlung von Ausnahmen und die Prüfung der Nachweise.

„MFA überall ist die vollständige Identitätsanforderung von NIS2“

MFA wird in Artikel 21 Absatz 2 Buchstabe j ausdrücklich genannt. Sie ist wertvoll, besonders für privilegierte Zugriffe, Fernzugriffe und sensible Zugriffe, beantwortet aber nicht, wer ein Konto haben sollte, welche Berechtigungen diese Person haben sollte, wer sie genehmigt hat, ob konfliktbehaftete Zugriffsrechte bestehen oder ob Zugriffsrechte nach einem Rollenwechsel entzogen wurden. Authentifizierung belegt etwas über die aktuelle Anmeldung. Governance entscheidet, ob das Konto und die Berechtigungen bestehen sollten.

„Eine Zertifizierung beweist automatisch die Einhaltung von NIS2“

NIS2 verweist auf den Stand der Technik und auf einschlägige europäische und internationale Normen. Artikel 24 erlaubt den Mitgliedstaaten außerdem, unter bestimmten Umständen die Verwendung zertifizierter IKT-Produkte, -Dienste oder -Prozesse vorzuschreiben. Die Richtlinie schafft kein allgemeingültiges Zertifikat, das Risikoanalyse, Meldung von Sicherheitsvorfällen, Aufsicht durch die Leitungsorgane oder nationale Pflichten ersetzt. Normen können eine starke Kontrollstruktur liefern; die Organisation muss trotzdem Geltungsbereich, Umsetzung und Wirksamkeit belegen.

„Die Höchstgeldbuße ist die übliche Geldbuße“

Artikel 34 verpflichtet die Mitgliedstaaten, für wesentliche Einrichtungen, die gegen Artikel 21 oder 23 verstoßen, Geldbußen mit einem Höchstbetrag von mindestens 10 Millionen € oder 2 % des weltweiten Jahresumsatzes vorzusehen, je nachdem, welcher Betrag höher ist. Für wichtige Einrichtungen liegen die entsprechenden Werte bei 7 Millionen € oder 1,4 %. Das sind Mindestwerte für die Höchstbeträge der Sanktionen, die in den nationalen Regelungen verfügbar sind. Sie sind keine Beträge, die bei einem Sicherheitsvorfall automatisch fällig werden. Die Behörden müssen die Umstände des Einzelfalls berücksichtigen, und das tatsächliche Verfahren richtet sich nach nationalem Recht.

Auf die Meldefristen für Vorfälle vorbereiten

Artikel 23 gilt, wenn ein Sicherheitsvorfall erhebliche Auswirkungen auf die Erbringung der Dienste hat. Ein Sicherheitsvorfall ist erheblich, wenn er schwerwiegende Betriebsstörungen der Dienste oder finanzielle Verluste für die betreffende Einrichtung verursacht hat oder verursachen kann oder wenn er andere natürliche oder juristische Personen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann.

Die Meldefolge beginnt, sobald die Einrichtung Kenntnis von einem erheblichen Sicherheitsvorfall erlangt:

Für Vertrauensdiensteanbieter gilt bei der Meldung über den Sicherheitsvorfall nach Artikel 23 Absatz 4 Buchstabe b eine besondere 24-Stunden-Regel. Nationale Verfahren können praktische Anforderungen, Portale und Ansprechstellen ergänzen. Gegebenenfalls müssen Organisationen außerdem die Empfänger ihrer Dienste über erhebliche Sicherheitsvorfälle informieren, die die Erbringung des Dienstes beeinträchtigen könnten, und ihnen Maßnahmen mitteilen, die sie als Reaktion auf eine erhebliche Cyberbedrohung ergreifen können.

Die betriebliche Folge ist einfach: Ein Team kann den Meldeprozess nicht während des Sicherheitsvorfalls entwerfen. Es braucht abgestimmte Kriterien für die Erheblichkeit, eine Entscheidungsbefugnis, Quellen für Nachweise, Kontakte zur Aufsicht, einen Weg zur rechtlichen Prüfung und eine Eskalation außerhalb der Geschäftszeiten. Üben Sie die ersten 24 Stunden. Wenn die Personen, die den Sicherheitsvorfall erkennen, die zur Meldung befugten Personen nicht erreichen, versagt die schriftliche Richtlinie genau an der Stelle, auf die es ankommt.

Wo Identity Governance Nachweise für NIS2 liefert

Identity Governance ist ein Teil des Programms nach Artikel 21. Im Mittelpunkt steht die Zugriffskontrolle, verbunden mit der Sicherheit des Personals, dem Management von Anlagen, der Bewältigung von Sicherheitsvorfällen, der Sicherheit der Lieferkette und Wirksamkeitstests. Identity Governance verknüpft ein geschäftliches Ereignis mit einem geprüften Zugriffszustand und den Einträgen, die nötig sind, um diese Änderung zu erklären.

Für jedes wesentliche System sollte eine Organisation beantworten können:

• Welche Identitäten können darauf zugreifen, darunter Mitarbeitende, externe Mitarbeitende, Dienstleister, Servicekonten und andere nicht-menschliche Identitäten?
• Welche Berechtigungen hat jede Identität, und welcher geschäftliche Zweck begründet sie?
• Wer hat den Zugriff beantragt und genehmigt, nach welcher Richtlinie und für wie lange?
• Was hat sich geändert, als die Person eingetreten ist, die Rolle gewechselt hat, einen anderen Vertrag erhalten hat oder ausgeschieden ist?
• Wer ist für die Definitionen von Anwendung, Rolle und Berechtigungen verantwortlich?
• Welche Zugriffe sind privilegiert, als Ausnahme gewährt, ruhend, verwaist oder konfliktbehaftet?
• Wann wurde der Zugriff zuletzt überprüft, wie hat die prüfende Person entschieden, und wurde die Entscheidung umgesetzt?
• Kann die Organisation den beabsichtigten Zustand mit dem tatsächlichen Zustand im Zielsystem abgleichen?

Eine Tabelle kann einige dieser Fragen für eine kleine, stabile Umgebung beantworten. Sie wird anfällig, wenn Anwendungen, Identitäten, Berechtigungen und Änderungen zunehmen. Automatisierung wird nützlich, wenn sie unkontrollierte Verzögerungen verringert und eine durchgängige Nachweiskette erhält. Die Kontrolle braucht weiterhin menschliche Verantwortung und Tests.

Belastbare Nachweise zur Zugriffskontrolle

Stellen Sie das Nachweispaket zusammen, bevor eine Prüfung angefordert wird. Es sollte mindestens Folgendes enthalten:

1. Richtlinie und Geltungsbereich: Richtlinie zur Zugriffskontrolle, Identitätsgruppen, kritische Anwendungen, Abgrenzung privilegierter Zugriffe und Regeln für Ausnahmen.
2. Befugnisse: verantwortliche Personen für Anwendungen und Rollen, genehmigende und prüfende Personen sowie Eskalationswege.
3. Nachweis des Lebenszyklus: Stichproben und Kennzahlen zu Eintritten, Wechseln, Austritten, externen Mitarbeitenden und inaktiven Identitäten, einschließlich des abgeschlossenen Entzugs in den Zielsystemen.
4. Nachweis der Entscheidungen: Zugriffsanfragen, Kontext der Genehmigung, Ablaufdaten, Richtlinienprüfungen und abgelehnte Anfragen.
5. Nachweis der Überprüfungen: Umfang der Überprüfung, Unabhängigkeit der prüfenden Personen (wo erforderlich), Entscheidungen, Umsetzung und überfällige Maßnahmen.
6. Technischer Nachweis: Status der Konnektoren, Ergebnisse des Abgleichs, fehlgeschlagene Vorgänge, Wiederholung oder manuelle Korrektur und Überwachung.
7. Privilegierte und nicht-menschliche Zugriffe: Inventar, Zuständigkeit, Authentifizierungskontrollen, Umgang mit Anmeldedaten, Nutzung und regelmäßige Überprüfung.
8. Ausnahmen und Wirksamkeit: Risikoakzeptanz, kompensierende Kontrollen, Testergebnisse, Sicherheitsvorfälle, Feststellungen und Behebung.

Wählen Sie nicht nur perfekte Stichproben aus. Nutzen Sie eine wiederholbare Stichprobenmethode und bewahren Sie Fehler zusammen mit ihrer Behebung auf. Nachweise, die zeigen, wie die Kontrolle Mängel erkennt und korrigiert, überzeugen mehr als eine Präsentation, die behauptet, dass es nie Mängel gibt.

Ein 90-Tage-Praxisplan für Identitäten unter NIS2

Die Umsetzung von NIS2 geht über Identity Governance hinaus, aber die Zugriffskontrolle ist ein abgegrenztes Arbeitspaket, das schnell messbare Nachweise liefern kann.

Tage 1 bis 30. Die tatsächliche Ausgangslage erheben.

Bestätigen Sie die Dokumentation zur rechtlichen Anwendbarkeit mit der Rechtsberatung oder der zuständigen Compliance-Funktion. Benennen Sie die verantwortliche Person aus der Leitung und die operativ verantwortlichen Personen. Definieren Sie kritische Dienste und die Systeme, die sie unterstützen. Inventarisieren Sie maßgebliche Identitätsquellen, Identitätsgruppen, Anwendungen, privilegierte Konten und nicht-menschliche Identitäten. Erfassen Sie die aktuellen Prozesse für Eintritt, Wechsel und Austritt vom Quellereignis bis zum Ergebnis im Zielsystem.

Messen Sie, was sich bereits messen lässt: Konten ohne verantwortliche Person, aktive Konten ausgeschiedener Beschäftigter, ruhende privilegierte Konten, überfällige Überprüfungen, fehlgeschlagene Provisionierungsänderungen, manuelle Warteschlangen und Anwendungen ohne benannte fachlich verantwortliche Person. Schätzen Sie diese Zahlen nicht, wenn Systemdaten verfügbar sind.

Tage 31 bis 60. Kontrollen nach Dienstrisiko priorisieren.

Wählen Sie die Systeme aus, bei denen unangemessene Zugriffe schwerwiegende Störungen der Dienste, Auswirkungen auf die Sicherheit von Menschen, erhebliche Verluste oder wesentliche Schäden verursachen könnten. Legen Sie für diese Systeme Anforderungen an Genehmigung, Ablauf, Funktionstrennung, privilegierte Zugriffe und Überprüfung fest. Setzen Sie Ziele für Entzug und Umsetzung, die dem betrieblichen Risiko entsprechen. Führen Sie einen Ausnahmeprozess mit einer benannten risikoverantwortlichen Person und einem Ablaufdatum ein.

Verknüpfen Sie Zugriffsereignisse mit der Bewältigung von Sicherheitsvorfällen. Das Sicherheitsteam sollte wissen, wie es während einer Untersuchung die Identitätshistorie, Genehmigungsnachweise und Nachweise zum Zustand im Zielsystem erhält. Das Identitätsteam sollte wissen, wann ein verdächtiges Konto, ein fehlgeschlagener Massenentzug oder eine kompromittierte privilegierte Identität in die Bewältigung von Sicherheitsvorfällen einfließt.

Tage 61 bis 90. Den Betrieb nachweisen.

Führen Sie eine vollständige Zugriffsüberprüfung für den priorisierten Umfang durch. Testen Sie mindestens einen Ablauf für Eintritt, Wechsel und Austritt durchgängig. Gleichen Sie die beantragten Änderungen mit den Zielsystemen ab. Testen Sie die Fehlerbehandlung, nicht nur den erfolgreichen Ablauf. Prüfen Sie die Zuständigkeiten für privilegierte Konten und Servicekonten. Legen Sie der Leitung die Ergebnisse, Ausnahmen und das Restrisiko in einer Form vor, die eine Entscheidung über Billigung oder Behebung unterstützt.

Das Ergebnis nach 90 Tagen ist nicht „NIS2 erledigt“. Es ist ein geprüfter Ausschnitt der Kontrollen und ein Umsetzungsmuster, das sich ausweiten lässt. Das ist nützlicher als eine umfangreiche Sammlung von Richtlinien ohne Nachweise aus dem Betrieb.

Wo easyIGA passt und wo nicht

easyIGA ist dafür entwickelt, Organisationen bei der Steuerung von Zugriffen über angebundene Systeme hinweg zu unterstützen: mit strukturierten Anfragen, Genehmigungen, Änderungen im Lebenszyklus, Überprüfungen und aufbewahrten Entscheidungsnachweisen. Das unterstützt direkt die praktische Arbeit hinter Konzepten für die Zugriffskontrolle und Nachweisen zur Wirksamkeit der Kontrollen.

easyIGA sollte anhand der realen Anwendungslandschaft und der Kontrollanforderungen der Organisation bewertet werden. Eine glaubwürdige Bewertung weist Anlegen, Ändern, Deaktivieren und Entfernen nach, außerdem Abgleich, Behandlung von Ausnahmen, Verantwortung der zuständigen Personen, Abschluss von Überprüfungen und exportierbare Nachweise. Sie testet auch Systeme, die schwer zu steuern sind, darunter Altanwendungen und Nicht-Microsoft-Umgebungen, statt nur das einfachste Verzeichniskonto vorzuführen.

easyIGA entscheidet nicht, ob eine juristische Person in den Anwendungsbereich fällt, ersetzt keine Beratung zum nationalen Recht, führt nicht das gesamte Cybersicherheitsprogramm und garantiert keine Compliance. easyIGA kann einen abgegrenzten Teil der Nachweiskette unterstützen. Die Organisation bleibt verantwortlich für Risikoentscheidungen, Systemsicherheit, Meldung von Sicherheitsvorfällen, Aufrechterhaltung des Betriebs, Kontrollen der Lieferkette und Aufsicht durch die Leitung.

Wenn sich Ihre Richtlinie zur Zugriffskontrolle über die Systeme, die kritische Dienste unterstützen, noch nicht nachweisen lässt, besprechen Sie die Lücke mit uns. Wir können mit einer begrenzten technischen Bewertung beginnen: Identitätsquellen, priorisierte Anwendungen, Lebenszyklusereignisse, Genehmigungen, Überprüfungen, Abgleich und Nachweise. Am Ende sollte eine testbare Übersicht der Kontrollen stehen, unabhängig davon, ob Sie sich für easyIGA entscheiden.

Was die Leitung vor der Genehmigung des Programms fragen sollte

Nutzen Sie diese Fragen in der Genehmigungssitzung:

• Haben wir dokumentiert, warum jede juristische Person nach dem einschlägigen nationalen Recht in den Anwendungsbereich fällt oder nicht?
• Welche kritischen Dienste und Abhängigkeiten bestimmen unsere Risikobewertung?
• Decken unsere Maßnahmen alle zehn Bereiche aus Artikel 21 Absatz 2 ab, mit verantwortlichen Personen und Wirksamkeitstests?
• Welche detaillierten Durchführungsvorschriften gelten für unsere Art von Einrichtung, und welche nicht?
• Können wir innerhalb des 24-Stunden-Fensters eine Entscheidung über einen erheblichen Sicherheitsvorfall treffen und begründen?
• Können wir nachweisen, dass Zugriffe ausgeschiedener Personen, privilegierte Zugriffe und Zugriffe von Dienstleistern in den Zielsystemen entzogen oder überprüft werden?
• Haben Ausnahmen verantwortliche Personen, kompensierende Maßnahmen und Ablaufdaten?
• Hat die Leitung genug Nachweise erhalten, um die Maßnahmen zu billigen und die Behebung zu überwachen?

Ein ehrliches „Nein“ ist nützlich, wenn daraus eine Maßnahme mit verantwortlicher Person entsteht. Gefährlich ist ein unbelegtes „Ja“, das sich auf einen Richtlinientitel, eine Produktlizenz oder eine generische Checkliste stützt.

Vor der Wahl einer Plattform den Produktumfang prüfen

Nutzen Sie die Nachweisübersicht von easyIGA, um verfügbare Einträge Ihren Anforderungen an die Zugriffskontrolle zuzuordnen. Sie erläutert erfasste Genehmigungsstufen, außerhalb von easyIGA erteilte Zugriffsrechte und fehlende historische Informationen. Richtlinienprüfungen zum Entscheidungszeitpunkt sind verfügbar; das Erstellen von Regeln in easyIGA ist geplant. Unser Team hat mindestens 14 midPoint-Einführungen umgesetzt. Diese Projekte liefern praktische Erfahrung für Entwurf und Betrieb von Zugriffskontrollen.

Weiter mit der Umsetzung

Nutzen Sie den IGA-Leitfaden für das Betriebsmodell der Access Governance und das Offboarding-Playbook, um den Entzug von Zugriffsrechten durchgängig zu testen. Für Teams aus dem Finanzsektor lohnt sich zusätzlich ein Blick auf das DORA-Rahmenwerk für die Zugriffskontrolle.

Quellen und Prüfvermerk

Produktumfang und redaktionelle Formulierungen aktualisiert am 24. September 2026. Die unten genannten Datumsangaben beziehen sich weiterhin auf die ursprüngliche Prüfung der Quellen.

Die Prüfung aller Quellen erfolgte am 12. September 2026.

1. Richtlinie (EU) 2022/2555, amtlicher Text, EUR-Lex
2. Durchführungsverordnung (EU) 2024/2690 der Kommission, amtlicher Text, EUR-Lex
3. Europäische Kommission: NIS2-Richtlinie, Überblick und Stand der Umsetzung
4. Europäische Kommission: Vorschlag für gezielte Änderungen von 2026
5. ENISA: NIS2 Technical Implementation Guidance
6. ENISA: Supporting NIS2 implementation through actionable guidance
7. ENISA: Cybersecurity of Critical Sectors