NIS2 Zugangssteuerung und Personalsicherheit: Ein vollständiger Leitfaden zu Artikel 21 Absatz 2 Buchstabe i

NIS2 Zugangssteuerung und Personalsicherheit: Ein vollständiger Leitfaden zu Artikel 21(2)(i)

Artikel 21(2)(i) der NIS2-Richtlinie verpflichtet betroffene Einrichtungen zu Maßnahmen, die „Sicherheit des Personals, Konzepte für die Zugriffskontrolle und Management von Anlagen“ umfassen. Auf den ersten Blick erscheinen dies drei voneinander getrennte Themenbereiche. In der Praxis handelt es sich jedoch um eine der weitreichendsten Maßnahmen der gesamten Richtlinie — die Durchführungsverordnung (EU) 2024/2690 (CIR) konkretisiert sie in den Abschnitten 10 (Sicherheit des Personals), 11 (Zugriffskontrolle) und 12 (Anlagen- und Wertemanagement) ihres Anhangs. Abschnitt 11 setzt zugleich Artikel 21(2)(j) um, also die Multi-Faktor-Authentifizierung.

Dieser Leitfaden konzentriert sich auf Zugangssteuerung und Personalsicherheit — die beiden Kontrollen, die unmittelbar regeln, wie Personen mit Ihren Systemen interagieren. Das Asset-Management wird als Teil derselben gesetzlichen Anforderung behandelt, verdient jedoch eine gesonderte Betrachtung (siehe unseren Leitfaden zum Asset-Management unter NIS2). Die hier behandelten Kontrollen adressieren gemeinsam das, was Sicherheitsexperten als das „Menschenproblem“ bezeichnen: Mitarbeitende, Auftragnehmer und Administratoren sind gleichzeitig das wertvollste Gut einer Organisation und ein häufiger Ausgangspunkt von Angriffen — etwa über gestohlene Zugangsdaten, Phishing oder überzählige Berechtigungen. Eine ordnungsgemäße Zugangssteuerung beantwortet eine scheinbar einfache Frage: Verfügt die richtige Person über den richtigen Zugang zu der richtigen Ressource — und nicht mehr?

Dieser Artikel erläutert, was CIR 2024/2690 technisch vorschreibt, wie es proportional für eine mittelgroße Organisation implementiert werden kann und an welchen Anforderungen sich unsere NIS2-Vorlagen orientieren. Er richtet sich an IT-Manager und HR-Direktoren, die rechtliche Verpflichtungen in operative Verfahren überführen müssen.

Rechtliche Grundlage: § 30 Abs. 2 Nr. 9 und Nr. 10 BSIG

In Deutschland ist Artikel 21 NIS2 durch das NIS2UmsuCG in § 30 BSIG umgesetzt, der seit dem 6. Dezember 2025 gilt. Die Maßnahmen besonders wichtiger und wichtiger Einrichtungen müssen danach zumindest die „Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen, -Produkten und -Prozessen“ (§ 30 Abs. 2 Nr. 9 BSIG, entspricht Art. 21(2)(i) NIS2) sowie die „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung“ (§ 30 Abs. 2 Nr. 10 BSIG, entspricht Art. 21(2)(j) NIS2) umfassen. Wie weit die Maßnahmen gehen müssen, richtet sich nach § 30 Abs. 1 BSIG: Zu berücksichtigen sind unter anderem das Ausmaß der Risikoexposition, die Größe der Einrichtung und die Umsetzungskosten. Die Einhaltung ist zu dokumentieren.

Wichtig für die Einordnung der folgenden Abschnitte: Die CIR 2024/2690 ist nur für die elf in ihrem Art. 1 genannten Einrichtungsarten verbindlich — DNS-Diensteanbieter, TLD-Namenregister, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Betreiber von Inhaltszustellnetzen, Anbieter verwalteter Dienste (MSP), Anbieter verwalteter Sicherheitsdienste (MSSP), Anbieter von Online-Marktplätzen, Online-Suchmaschinen und Plattformen für Dienste sozialer Netzwerke sowie Vertrauensdiensteanbieter. Für diese Einrichtungsarten hat sie nach § 30 Abs. 3 BSIG Vorrang. Für alle anderen Einrichtungen ergeben sich die Pflichten aus § 30 BSIG selbst. Ihnen dienen die CIR-Nummern als Orientierung dafür, wie ein geeignetes, verhältnismäßiges und wirksames Konzept aussehen kann — nicht als verbindliche Checkliste.

CIR Anhang 11: Anforderungen an die Zugangssteuerung

Abschnitt 11 des CIR-Anhangs („Zugriffskontrolle“, Art. 21 Abs. 2 Buchst. i und j NIS2) überführt die NIS2-Verpflichtung zur Zugangssteuerung in spezifische technische und organisatorische Anforderungen. Er umfasst sieben Unterabschnitte: 11.1 bis 11.4 regeln das Konzept, die Zugriffsrechte, privilegierte Konten und Systemverwaltungssysteme, 11.5 bis 11.7 die Identifizierung, die Authentifizierung und die Multifaktor-Authentifizierung.

11.1 Konzept für die Zugriffskontrolle

Die betreffenden Einrichtungen legen auf Grundlage geschäftlicher und sicherheitsbezogener Anforderungen Konzepte für die logische und physische Kontrolle des Zugangs zu ihren Netz- und Informationssystemen fest, dokumentieren sie und setzen sie um (11.1.1). Nach 11.1.2 müssen diese Konzepte:

• für den Zugang von Personen gelten — einschließlich Personal, Besuchern und externen Einrichtungen wie Anbietern und Diensteanbietern
• auch für den Zugang von Netz- und Informationssystemen gelten, also für Zugriffe von System zu System (etwa über Dienstkonten und Schnittstellen)
• sicherstellen, dass der Zugang nur Nutzern gewährt wird, die angemessen authentifiziert wurden

Überprüft werden die Konzepte in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder Risiken (11.1.3). Die ENISA-Umsetzungsleitlinie empfiehlt hierfür eine Überprüfung mindestens einmal jährlich. In der Praxis legt die Richtlinie auch die Grundsätze fest, nach denen Rechte vergeben werden. Die CIR nennt in 11.2.2 Buchst. a „Kenntnis nur, wenn nötig“ (Need-to-know), Nutzungsnotwendigkeit (Need-to-use — in der Praxis meist als Prinzip der geringsten Berechtigungen (Least Privilege) bezeichnet) und Aufgabentrennung. Dazu kommen Regeln für Benutzerkategorien wie Mitarbeitende, Auftragnehmer, Drittanbieter-Partner und privilegierte Administratoren.

Die Richtlinie muss kein umfangreiches Dokument sein. Eine klare, 5–10 Seiten umfassende Richtlinie, die tatsächlich angewendet wird, ist mehr wert als ein umfassendes 40-seitiges Dokument, das unbeachtet in einem Ordner liegt. Die Zugangssteuerungs-Richtlinie im NIS2-Vorlagenpaket bietet einen anpassungsfähigen Rahmen, der sich an CIR Abschnitt 11 orientiert.

11.2 Management von Zugangs- und Zugriffsrechten

Zugangs- und Zugriffsrechte werden im Einklang mit dem Konzept gewährt, geändert, gelöscht und dokumentiert (11.2.1). Nach 11.2.2 müssen die Einrichtungen:

• Rechte nach den Grundsätzen Need-to-know, Need-to-use und Aufgabentrennung gewähren und entziehen
• sicherstellen, dass Rechte bei Beendigung oder Änderung des Beschäftigungsverhältnisses entsprechend geändert werden
• sicherstellen, dass der Zugang von den einschlägigen Personen genehmigt wird — in der Praxis über einen definierten Workflow: Zugriffsantrag → Genehmigung durch den Asset-Verantwortlichen → Implementierung → Überprüfung (keine Ad-hoc-Anfragen per E-Mail)
• Zugänge Dritter wie Besucher, Anbieter und Diensteanbieter angemessen berücksichtigen, insbesondere durch Beschränkung nach Umfang und Dauer
• ein Register der gewährten Zugangs- und Zugriffsrechte führen
• das Management der Zugangs- und Zugriffsrechte protokollieren

Zur Häufigkeit verlangt 11.2.3, die Rechte „in geplanten Zeitabständen“ zu überprüfen und bei organisatorischen Änderungen anzupassen. Die Ergebnisse, einschließlich der erforderlichen Änderungen, sind zu dokumentieren. Einen festen Rhythmus schreibt die CIR nicht vor. Die ENISA-Umsetzungsleitlinie (Juni 2025) empfiehlt, Zugriffsrechte mindestens jährlich zu überprüfen, und für die Überprüfung aktiver Kennungen nach 11.5.4 mindestens vierteljährlich (Kleinstunternehmen: jährlich). Der folgende Plan baut darauf auf. Die vierteljährliche Prüfung privilegierter Konten ist eine verbreitete Praxisempfehlung, keine Vorgabe der CIR:

11.3 Privilegierte Konten und Systemverwaltungskonten

Privilegierte Konten — solche mit Administratorrechten, erhöhten Systemberechtigungen oder Zugang zu sensiblen Konfigurationen — stellen ein überproportionales Risiko dar. Ein kompromittiertes Administratorkonto kann sich lateral bewegen, Daten exfiltrieren und Kontrollen schneller deaktivieren als ein kompromittiertes Standardbenutzerkonto. Die Konzepte für diese Konten müssen nach CIR 11.3.2:

• starke Verfahren zur Identifizierung, Authentifizierung (z. B. Multi-Faktor-Authentifizierung) und Genehmigung vorsehen
• spezielle Konten einrichten, die ausschließlich für Systemverwaltungsvorgänge wie Installation, Konfiguration, Verwaltung oder Wartung verwendet werden — IT-Administratoren sollten also ein Standardkonto für die tägliche Arbeit und ein dediziertes Administratorkonto für administrative Aufgaben haben. Keine Konten mit doppelter Funktion.
• Systemverwaltungsrechte so weit wie möglich individuell zuschneiden und einschränken
• festlegen, dass Systemverwaltungskonten ausschließlich zur Verbindung mit Systemverwaltungssystemen verwendet werden

Nach 11.3.3 sind die Rechte privilegierter Konten und Systemverwaltungskonten in geplanten Zeitabständen zu überprüfen, bei organisatorischen Änderungen anzupassen und die Ergebnisse zu dokumentieren. Bewährte Ergänzungen, die die CIR nicht ausdrücklich vorschreibt:

• Führen Sie ein Inventar aller privilegierten Konten (lokale Administratoren, Domain-Administratoren, Dienstkonten, Cloud-Root-Konten) — als Teil des Rechte-Registers nach 11.2.2 Buchst. e
• Begrenzen Sie die Dauer des privilegierten Zugangs — Just-in-Time-Zugang (JIT), bei dem Administratoren erhöhte Berechtigungen für ein definiertes Zeitfenster anfordern, ist der empfohlene Ansatz, sofern die Werkzeuge dies erlauben
• Protokollieren und überwachen Sie alle privilegierten Zugriffsaktivitäten und bewahren Sie Protokolle für Prüfzwecke auf
• Überprüfen Sie privilegierte Konten häufiger als Standardkonten (z. B. vierteljährlich)
• Beschränken Sie, soweit praktikabel, den privilegierten Zugang auf dedizierte Administrator-Workstations, die nicht zum Surfen oder für E-Mails genutzt werden

11.4 Systemverwaltungssysteme

Administrationsschnittstellen — Management-Konsolen, Fernzugriffswerkzeuge und Konfigurationsportale zur Verwaltung der Infrastruktur — müssen mit stärkeren Kontrollen als benutzerseitige Systeme geschützt werden. Die Einrichtungen beschränken und kontrollieren die Nutzung von Systemverwaltungskonten im Einklang mit dem Zugriffskonzept (11.4.1). Nach 11.4.2 müssen sie:

• Systemverwaltungssysteme ausschließlich für die Zwecke der Systemverwaltung und nicht für andere Vorgänge verwenden
• solche Systeme logisch von Anwendungssoftware trennen, die nicht der Systemverwaltung dient — etwa über separate Verwaltungsnetzwerke, wo dies umsetzbar ist (Out-of-Band-Management)
• den Zugang zu Systemverwaltungssystemen durch Authentifizierung und Verschlüsselung schützen — in der Praxis etwa Fernverwaltung nur über VPN mit MFA oder Zero-Trust-Netzwerkzugang

Ergänzend empfiehlt es sich, Administrationswerkzeuge zu härten und nicht benötigte Funktionen zu deaktivieren.

11.5 Identifizierung

Die Einrichtungen verwalten den gesamten Lebenszyklus der Identitäten (Kennungen) ihrer Netz- und Informationssysteme und ihrer Nutzer (11.5.1). Dazu gehören nach 11.5.2 eindeutige Kennungen, die Verknüpfung jeder Nutzerkennung mit einer einzigen Person, die Überwachung der Kennungen und die Protokollierung des Identitätsmanagements. Kennungen, die mehreren Personen zugewiesen sind (z. B. gemeinsame Konten), sind nur zulässig, wenn sie aus geschäftlichen oder operativen Gründen erforderlich sind, einem ausdrücklichen Genehmigungsverfahren unterliegen und dokumentiert werden. Zudem sind sie im Risikomanagement zu berücksichtigen (11.5.3). Kennungen sind regelmäßig zu überprüfen und unverzüglich zu deaktivieren, wenn sie nicht mehr benötigt werden (11.5.4) — das ist die direkte Verbindung zum Leaver-Prozess weiter unten.

11.6 Authentifizierung

Nach 11.6 verwenden die Einrichtungen sichere Authentifizierungsverfahren auf Grundlage von Zugangsbeschränkungen und des Zugriffskonzepts. 11.6.2 verlangt im Einzelnen:

• Die Stärke der Authentifizierung entspricht der Klassifizierung des Werts, auf den zugegriffen wird.
• Geheime Authentifizierungsinformationen werden über ein Verfahren zugewiesen, das ihre Vertraulichkeit gewährleistet, einschließlich Anweisungen an das Personal zum Umgang damit.
• Authentifizierungsdaten werden zu Beginn, in vorab festgelegten Zeitabständen und bei Verdacht auf Kompromittierung geändert.
• Nach einer festgelegten Zahl erfolgloser Anmeldeversuche werden die Authentifizierungsdaten zurückgesetzt und die Nutzer gesperrt.
• Inaktive Sitzungen werden nach einer festgelegten Zeit beendet.
• Für privilegierte Konten und Verwaltungskonten gelten gesonderte Authentifizierungsdaten.

Nach 11.6.3 sind – soweit durchführbar – modernste Authentifizierungsmethoden einzusetzen. Die Verfahren sind in geplanten Zeitabständen zu überprüfen (11.6.4). Wie sich der Wechsel „in vorab festgelegten Zeitabständen“ nach Nr. 11.6.2 Buchst. c mit der BSI-Empfehlung gegen feste Wechselintervalle vereinbaren lässt und welche Mindestlängen gelten, zeigt unser Leitfaden zur Passwortrichtlinie nach NIS2 und BSI.

11.7 Multifaktor-Authentifizierung

Nach 11.7.1 stellen die Einrichtungen sicher, dass Nutzer „– soweit angemessen – durch mehrere Authentifizierungsfaktoren oder kontinuierliche Authentifizierungsmechanismen“ authentifiziert werden, und zwar im Einklang mit der Klassifizierung des Werts, auf den zugegriffen werden soll. 11.7.2 wiederholt, dass die Stärke der Authentifizierung zu dieser Klassifizierung passen muss. Die CIR verlangt MFA also nicht pauschal für jeden Zugriff. Für privilegierte und Systemverwaltungskonten nennt sie MFA jedoch ausdrücklich als Beispiel starker Authentifizierung (11.3.2 Buchst. a). Für alle NIS2-Einrichtungen in Deutschland zählt § 30 Abs. 2 Nr. 10 BSIG die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung zu den Mindestmaßnahmen. ENISA rät, MFA-Verfahren zu wählen, die Phishing-Angriffen standhalten. Welche Verfahren in Frage kommen und wie Sie MFA risikobasiert einführen, zeigt unser Leitfaden zu den MFA-Anforderungen nach NIS2.

Least Privilege und Need-to-know: Die Grundprinzipien

Die beiden grundlegenden Prinzipien der NIS2-Zugangssteuerung sind es wert, in praktischen Begriffen erläutert zu werden, da sie zwar häufig zitiert, aber selten konsequent umgesetzt werden.

Least Privilege bedeutet, die für die Ausführung einer bestimmten Aufgabe erforderlichen Mindestberechtigungen zu gewähren — nicht mehr. Ein Marketing-Analyst, der Kundendaten aus dem CRM lesen muss, benötigt keinen Schreibzugang auf Finanzsysteme. Ein Anwendungssupport-Techniker, der einen Dienst neu starten muss, benötigt keine vollständigen Domain-Administratorrechte.

Die praktische Konsequenz ist eine Änderung der Denkweise: Beginnen Sie mit keinem Zugang und fügen Sie Berechtigungen hinzu, sobald diese begründet sind, anstatt mit umfangreichen Berechtigungen zu beginnen und das Nicht-Benötigte zu entfernen. Letzterer Ansatz — in vielen Organisationen gelebte Praxis — führt erfahrungsgemäß zu einer Anhäufung übermäßiger Zugriffsrechte im Laufe der Zeit.

Need-to-know erweitert das Prinzip von Berechtigungen auf Informationen. Selbst wenn eine Benutzerin oder ein Benutzer technisch Zugang zu einem System hat, sollte der Zugang zu bestimmten Daten innerhalb dieses Systems auf Personen mit einem aktuellen, legitimen geschäftlichen Bedarf beschränkt sein. Dies gilt für Dokumente, Datenbanken, Berichte, E-Mail-Verteilerlisten und physische Bereiche.

Der praktische Treiber für Need-to-know ist die Informationsklassifizierung: Klassifizieren Sie zunächst Ihre Informationen und definieren Sie dann, wer Zugang zu welcher Klassifizierungsstufe benötigt. Dies verhindert das häufige Versagen, bei dem sensible Informationen in gemeinsam genutzten Ordnern gespeichert werden, auf die alle zugreifen können, weil es „einfacher ist“.

Rollenbasierte Zugangssteuerung (RBAC)

Für die meisten Organisationen ist die rollenbasierte Zugangssteuerung (RBAC) die praktischste Umsetzung dieser Prinzipien. Anstatt Berechtigungen einzelnen Benutzenden zuzuweisen, definieren Sie Rollen mit spezifischen Berechtigungssätzen und weisen Benutzende dann den Rollen zu. Dies ist skalierbar, lässt sich einfach prüfen und macht den JML-Prozess (weiter unten beschrieben) erheblich handhabbarer.

Eine typische RBAC-Struktur für eine mittelgroße Organisation könnte folgendermaßen aussehen:

Die entscheidende Disziplin besteht darin, die Rollendefinitionen regelmäßig zu überprüfen — Rollen häufen im Laufe der Zeit Berechtigungen an, wenn Ausnahmen gewährt und nie überprüft werden.

Der Joiner-Mover-Leaver-Prozess (JML)

Der Joiner-Mover-Leaver-Prozess ist das operative Rückgrat der Personalsicherheit für die Zugangssteuerung. Er definiert genau, welche Maßnahmen ergriffen werden, wenn eine Person der Organisation beitritt, die Rolle wechselt oder sie verlässt, und verbindet damit die CIR-Nummern 11.2.2 Buchst. b, 11.5.4 und 12.5. Ohne einen dokumentierten JML-Prozess wird die Zugangssteuerung reaktiv und inkonsistent — eine typische Ursache für die Anhäufung übermäßiger Zugriffsrechte und ein häufiger Befund in Prüfungen der Zugangssteuerung.

Joiner-Prozess (Neue Mitarbeitende oder Auftragnehmer)

1. HR informiert IT/Sicherheit über den neuen Mitarbeitenden mit Rollendetails und Eintrittsdatum — idealerweise 5–10 Werktage im Voraus
2. Basisanfrage für den Zugang wird auf Grundlage des vordefinierten Berechtigungssatzes der Rolle erhoben (RBAC-Rollenzuweisung)
3. Vorgesetzte genehmigen jeden zusätzlichen Zugang über die Rollenbasislinie hinaus
4. Konten werden vor dem Eintrittsdatum erstellt und konfiguriert
5. Schulung zum Sicherheitsbewusstsein wird innerhalb der ersten Woche durchgeführt
6. Zugangsdaten werden über einen sicheren Kanal bereitgestellt — nicht per unverschlüsselter E-Mail
7. Dokumentierte Bestätigung der Richtlinie zur akzeptablen Nutzung (und der HR-Sicherheitsrichtlinie) wird vom neuen Mitarbeitenden eingeholt

Mover-Prozess (Rollenwechsel, Versetzung oder Beförderung)

1. Vorgesetzte oder HR informieren IT/Sicherheit über den Rollenwechsel, das Wirksamkeitsdatum und die Details der neuen Rolle
2. Aktuelle Zugriffsrechte werden mit den Anforderungen der neuen Rolle abgeglichen
3. Zugang entziehen, der für die neue Rolle nicht mehr erforderlich ist — dies ist der Schritt, der in der Praxis am häufigsten versäumt wird, was im Laufe der Zeit zu einer Anhäufung von Berechtigungen führt
4. Zugang gewähren, der für die neue Rolle erforderlich ist
5. Zugangsdatensätze und RBAC-Rollenzuweisung aktualisieren
6. Den Mitarbeitenden über etwaige neue Sicherheitsverantwortlichkeiten im Zusammenhang mit der neuen Rolle informieren

Leaver-Prozess (Kündigung, Beendigung des Arbeitsverhältnisses oder Vertragsende)

Die CIR nennt keine Stundenfristen. Sie verlangt, dass Rechte bei Beendigung des Beschäftigungsverhältnisses entsprechend geändert (11.2.2 Buchst. b) und nicht mehr benötigte Kennungen unverzüglich deaktiviert werden (11.5.4). Die Zeitangaben in der folgenden Tabelle sind Praxisempfehlungen:

Ein kritischer Punkt: Deaktivieren Sie Konten, anstatt sie sofort zu löschen. Gelöschte Konten vernichten Prüfpfad-Nachweise, die für die Untersuchung von Vorfällen oder behördliche Inspektionen benötigt werden könnten. Bewahren Sie deaktivierte Konten für die Dauer Ihrer Protokollaufbewahrungsfrist auf und löschen Sie sie anschließend.

Eine Lücke, die diese Tabelle nicht abdeckt: Unternehmensdaten auf privaten Geräten. „Rückgabe von Unternehmenseigentum“ greift dort nicht, weil das Gerät den Beschäftigten gehört. Anhang Nr. 12.5 der Durchführungsverordnung (EU) 2024/2690 verlangt trotzdem, dass Anlagen und Werte der Einrichtung beim Ausscheiden abgegeben, zurückgegeben oder gelöscht werden und dass dies dokumentiert wird. Wie Sie die selektive Löschung im Austrittsprozess und vorab in einer Regelung für private Geräte verankern, zeigt unser Leitfaden zu den BYOD-Vorgaben unter NIS2.

CIR Anhang 10: Personalsicherheit

Abschnitt 10 der CIR („Sicherheit des Personals“) befasst sich mit der personenbezogenen Seite der Sicherheit — er stellt sicher, dass Mitarbeitende und Auftragnehmer angemessen überprüft werden, über ihre Verantwortlichkeiten informiert sind und sicher aus dem Unternehmen ausscheiden. Er gliedert sich in vier Unterabschnitte: 10.1 Sicherheit des Personals, 10.2 Zuverlässigkeitsüberprüfung, 10.3 Verfahren zur Beendigung oder Änderung des Beschäftigungsverhältnisses und 10.4 Disziplinarverfahren.

10.1 Sicherheit des Personals

Nach 10.1.1 stellen die Einrichtungen sicher, dass ihre Mitarbeitenden und gegebenenfalls ihre direkten Anbieter und Diensteanbieter ihre Verantwortlichkeiten im Bereich der Sicherheit verstehen und sich zu ihrer Einhaltung verpflichten. 10.1.2 verlangt dafür Mechanismen, mit denen

• alle Mitarbeitenden, direkten Anbieter und Diensteanbieter die Standardverfahren der Cyberhygiene nach Nr. 8.1 verstehen und befolgen,
• alle Nutzer mit administrativem oder privilegiertem Zugang sich ihrer Rollen, Verantwortlichkeiten und Weisungsbefugnisse bewusst sind und entsprechend handeln,
• die Mitglieder der Leitungsorgane ihre Rollen und Verantwortlichkeiten für die Sicherheit von Netz- und Informationssystemen verstehen und entsprechend handeln, und
• Personal eingestellt wird, das für die jeweilige Rolle qualifiziert ist — etwa durch Überprüfung der Referenzen, Validierung von Zeugnissen oder schriftliche Prüfungen.

Sicherheitsverantwortlichkeiten sollten deshalb in Stellenbeschreibungen und Arbeitsverträgen definiert sein, nicht nur in Richtliniendokumenten, die Mitarbeitende möglicherweise nie lesen. Bewährte Umsetzungsschritte:

• Sicherheitsverantwortlichkeiten in den Stellenbeschreibungen aller Rollen mit Systemzugang dokumentieren
• Sicherheitsklauseln in Arbeitsverträge aufnehmen (Vertraulichkeit, akzeptable Nutzung, Meldepflicht bei Vorfällen)
• Schulung zum Sicherheitsbewusstsein während des Onboardings durchführen — nicht optional, nicht auf „wenn Zeit ist“ verschieben
• Laufendes Sicherheitsbewusstseinsprogramm, das auf die Schulungsanforderungen gemäß Artikel 21(2)(g) (§ 30 Abs. 2 Nr. 7 BSIG) abgestimmt ist
• Richtlinie zur akzeptablen Nutzung von allen Mitarbeitenden unterzeichnen lassen

Eine Anforderung, die in vielen bestehenden HR-Prozessen fehlt, steht in 10.1.3: Die Zuweisung von Personal zu bestimmten Rollen nach Nr. 1.2 (Rollen, Verantwortlichkeiten und Befugnisse) sowie die dafür eingesetzten personellen Mittel sind „in geplanten Zeitabständen und mindestens einmal jährlich“ zu überprüfen und bei Bedarf zu aktualisieren. Dokumentieren Sie diese jährliche Überprüfung, etwa als festen Punkt im Management-Review.

10.2 Zuverlässigkeitsüberprüfung

Nach 10.2.1 stellen die Einrichtungen – soweit durchführbar – sicher, dass ihre Mitarbeitenden und, soweit anwendbar, direkte Anbieter und Diensteanbieter einer Zuverlässigkeitsüberprüfung unterzogen werden, wenn ihre Rollen, Verantwortlichkeiten und Weisungsbefugnisse dies erfordern. 10.2.2 verlangt dafür zweierlei: Kriterien, welche Rollen nur von überprüften Personen wahrgenommen werden dürfen, und die Durchführung der Überprüfung, bevor die Person die Rolle aufnimmt. Dabei sind die geltenden Gesetze, Vorschriften und ethischen Normen im Verhältnis zu den geschäftlichen Anforderungen, der Klassifizierung der Anlagen und Werte und den wahrgenommenen Risiken zu berücksichtigen. Die CIR schreibt also kein einheitliches Überprüfungsniveau für alle Rollen vor — das Verhältnismäßigkeitsprinzip bestimmt die Entscheidung. Die Kriterien selbst sind in geplanten Zeitabständen zu überprüfen (10.2.3).

Ein praktischer Rahmen für die meisten Organisationen:

• Standardrollen (kein privilegierter Zugang): Identitätsverifizierung, Referenzprüfung, Überprüfung der Arbeitsberechtigung
• Rollen mit Zugang zu sensiblen Daten: Wie oben, zusätzlich Überprüfung des beruflichen Werdegangs und der Qualifikationen
• IT-Administratoren und Rollen mit privilegiertem Zugang: Erweiterte Prüfung (lückenloser Werdegang, berufliche Referenzen, Nachweise zu Qualifikationen); weitergehende Prüfungen wie ein Führungszeugnis nur, soweit sie für die konkrete Tätigkeit erforderlich und arbeits- sowie datenschutzrechtlich zulässig sind

Dokumentieren Sie das erforderliche Überprüfungsniveau für jede Rollenkategorie und halten Sie die durchgeführten Prüfungen fest. Verhältnismäßigkeit ist entscheidend: Die Forderung nach einem polizeilichen Führungszeugnis für eine administrative Juniorrolle ohne Systemzugang ist unverhältnismäßig; keine Prüfung für einen Cloud-Infrastruktur-Administrator durchzuführen, ist unzureichend. Auch die ENISA-Umsetzungsleitlinie weist darauf hin, dass Abfragen von Strafregistern mit dem nationalen (Arbeits-)Recht und der DSGVO vereinbar sein müssen. Stimmen Sie die Kriterien daher vorab mit Datenschutz und, falls vorhanden, Betriebsrat ab.

10.3 Verfahren zur Beendigung oder Änderung des Beschäftigungsverhältnisses

10.3 verlangt, dass Verantwortlichkeiten und Pflichten in Bezug auf die Sicherheit, die nach Beendigung oder Änderung des Beschäftigungsverhältnisses fortgelten, vertraglich festgelegt und durchgesetzt werden (10.3.1). Sie gehören in die Arbeits- und Beschäftigungsbedingungen, den Vertrag oder die Vereinbarung, zum Beispiel als Vertraulichkeitsklauseln (10.3.2). Die übrigen Elemente eines sicheren Austritts ergeben sich aus anderen Nummern des Anhangs oder sind gute Praxis — die HR-seitige Komponente des oben beschriebenen JML-Prozesses:

• Dokumentierte Verfahren zum Entzug von Zugriffsrechten (11.2.2 Buchst. b und 11.5.4; der oben beschriebene Leaver-Prozess)
• Verfahren zur Rückgabe physischer Gegenstände — Laptop, Mobilgerät, Zugangskarten, Hardware-Token (12.5)
• Nachvertragliche Vertraulichkeitspflichten beim Ausscheiden einschärfen — Mitarbeitende müssen verstehen, dass NDA-Verpflichtungen nach ihrem letzten Arbeitstag fortbestehen (10.3)
• Wissenstransferverfahren für Mitarbeitende in kritischen Sicherheitsrollen — Sicherheitswissen, Zugangsdaten und Verantwortlichkeiten sollten vor dem Ausscheiden dokumentiert und übergeben werden (Praxisempfehlung)

Wie Sie diese nachwirkenden Pflichten so formulieren, dass sie arbeitsrechtlich halten — das Bundesarbeitsgericht hat am 17.10.2024 (8 AZR 172/23) eine formularmäßige Klausel, die zeitlich unbegrenzt zum Stillschweigen über alle internen Vorgänge verpflichtet (sog. Catch-all-Klausel), für unwirksam erklärt —, zeigt unser Leitfaden zur Verschwiegenheitserklärung für Mitarbeiter unter NIS2.

10.4 Disziplinarverfahren

Nach 10.4.1 führen die Einrichtungen ein Disziplinarverfahren für den Umgang mit Verstößen gegen die Sicherheitskonzepte ein, machen es bekannt und erhalten es aufrecht. Dabei sind die einschlägigen rechtlichen, gesetzlichen, vertraglichen und geschäftlichen Anforderungen zu berücksichtigen. 10.4.2 verlangt eine Überprüfung in geplanten Zeitabständen sowie bei rechtlichen Änderungen oder wesentlichen Änderungen der Betriebsabläufe oder Risiken. Wie die Sanktionen aussehen, regelt die CIR nicht. Entscheidend ist, dass das Verfahren verhältnismäßig zur Schwere des Verstoßes ist und konsequent angewendet wird.

In Deutschland stützt sich ein solches Verfahren in der Regel auf das arbeitsrechtliche Instrumentarium (Ermahnung, Abmahnung, Kündigung). Wo ein Betriebsrat besteht, ist bei Regeln zum Verhalten der Arbeitnehmer im Betrieb sein Mitbestimmungsrecht nach § 87 Abs. 1 Nr. 1 BetrVG zu beachten. Bei technischen Einrichtungen, die das Verhalten oder die Leistung der Beschäftigten überwachen können — etwa die Protokollierung von Nutzeraktivitäten —, gilt § 87 Abs. 1 Nr. 6 BetrVG.

Praktische Umsetzung für KMU: Drei Phasen

Die vollständigen Anforderungen können als einzelnes Projekt überwältigend wirken. Ein phasenweiser Ansatz macht die Umsetzung handhabbar. Diese Phasen orientieren sich an der Methodik der NIS2-Compliance-Checkliste.

Phase 1 — Grundlage (Wochen 1–4)

Die Zugangssteuerungsrichtlinie aus dem ersten Schritt unten entspricht dem Konzept für die Zugriffskontrolle, das § 30 Abs. 2 Nr. 9 BSIG ausdrücklich nennt — die „Erstellung von Konzepten“ ist dort eine eigenständige Maßnahme. Wie es aufgebaut sein kann und welcher Nachweis zu jedem Kapitel gehört, zeigt unsere Berechtigungskonzept-Vorlage mit neun Kapiteln.

• Dokumentieren Sie eine Zugangssteuerungsrichtlinie, die die wesentlichen Grundsätze definiert (Least Privilege, Need-to-know, RBAC-Struktur, Überprüfungsrhythmus)
• Erstellen Sie eine Zugriffsrechtsmatrix, die Ihre wichtigsten Rollen den Systemen und Berechtigungsstufen zuordnet
• Implementieren Sie MFA für alle administrativen und Fernzugänge umgehend
• Etablieren Sie einen formellen HR–IT-Benachrichtigungsprozess für Eintritte, Rollenwechsel und Austritte
• Führen Sie eine erste Zugriffsüberprüfung durch, um offensichtlich übermäßige Berechtigungen zu identifizieren (achten Sie insbesondere auf ehemalige Mitarbeitende mit aktiven Konten und Benutzende, die die Rolle gewechselt haben)

Phase 2 — Ausbau (Wochen 4–8)

• Implementieren Sie einen formellen Workflow für Zugriffsanträge und -genehmigungen (ein einfaches Ticketformular ist für die meisten KMU ausreichend)
• Legen Sie einen regelmäßigen Zugriffsüberprüfungsplan fest und weisen Sie die Verantwortung zu
• Erstellen Sie separate Administratorkonten für IT-Mitarbeitende mit privilegiertem Zugang
• Aktivieren Sie die Protokollierung des Zugangs auf kritischen Systemen (Active Directory, Cloud-Konsolen, Finanzanwendungen)
• Fügen Sie Sicherheitsklauseln in Arbeitsverträge ein und aktualisieren Sie die Richtlinie zur akzeptablen Nutzung
• Definieren Sie rollenbasierte Überprüfungsanforderungen und dokumentieren Sie, welche Prüfungen durchgeführt werden

Phase 3 — Reife (Fortlaufend)

• Implementieren Sie eine Lösung für die Verwaltung privilegierter Zugänge (PAM), sofern Budget und Umfang dies rechtfertigen
• Automatisieren Sie die JML-Bereitstellung und -Aufhebung, wo HR- und Identitätsmanagementsysteme eine Integration ermöglichen
• Etablieren Sie Zugriffsanalysen zur Erkennung von Anomalien (Konten, deren Zugriffsmuster nicht zu ihrer Rolle passen)
• Binden Sie die Zugangssteuerung an einen Identitätsanbieter mit Single Sign-on an — das vereinfacht sowohl die Bereitstellung als auch den Entzug von Zugängen
• Stellen Sie privilegierte und Fernzugänge schrittweise auf phishing-resistente MFA-Verfahren um, etwa FIDO2-Sicherheitsschlüssel oder Passkeys

Weiterführende Leitfäden

Ob eine Zero-Trust-Architektur die hier beschriebenen Pflichten aus § 30 Abs. 2 Nr. 9 und Nr. 10 BSIG tatsächlich bedient — und warum der Begriff im einzigen verbindlichen Verordnungstext nicht „Zero Trust“, sondern „Null-Vertrauen-Architekturen“ heißt — klärt unser Leitfaden Zero Trust und NIS2: Braucht Ihr Unternehmen eine neue Zugangsarchitektur?. Dort finden Sie auch eine Zuordnung, welche der zehn Maßnahmenbereiche des § 30 Abs. 2 BSIG eine Zero-Trust-Architektur abdeckt — und welche sie offen lässt.

Passende Vorlagen

Folgende Dokumente aus dem NIS2-Vorlagenpaket orientieren sich an den in diesem Leitfaden behandelten Anforderungen:

Zugangssteuerungs-Richtlinie
Grundsätze der Zugriffskontrolle, Rollenstruktur, Überprüfung von Zugriffsrechten und Regeln für privilegierte Zugänge — orientiert an CIR Abschnitt 11 und § 30 Abs. 2 Nr. 9 BSIG. Auf dieses Grundlagendokument verweisen alle weiteren Verfahren der Zugangsverwaltung.

Authentifizierungsrichtlinie inkl. MFA und Passwortrichtlinie
Regeln für Authentifizierungsverfahren, Multi-Faktor-Authentifizierung und den Umgang mit Zugangsdaten — orientiert an CIR 11.6 und 11.7 sowie § 30 Abs. 2 Nr. 10 BSIG.

HR-Sicherheitsrichtlinie
Die personenbezogene Seite: Sicherheitspflichten während der Beschäftigung, Überprüfungen und Austrittsprozess — orientiert an CIR Abschnitt 10. Sie schließt die Lücke zwischen HR-Prozessen und Sicherheitsanforderungen.

Die Vorlagen sind allgemeine Muster und müssen an Ihre Organisation, Ihre Systeme und Ihre arbeitsrechtliche Situation angepasst werden.

Häufig gestellte Fragen

Schreibt NIS2 eine bestimmte Technologie für die Zugangssteuerung vor?

Nein. Weder § 30 BSIG noch die Durchführungsverordnung (EU) 2024/2690 schreiben bestimmte Produkte vor. Active Directory, Entra ID oder ein Cloud-Identitätsanbieter können die Anforderungen gleichermaßen erfüllen. Entscheidend ist, dass die Grundsätze – Need-to-know, Need-to-use bzw. Least Privilege, Aufgabentrennung, Überprüfungen in geplanten Zeitabständen und starke Authentifizierung für privilegierte Zugänge – umgesetzt und dokumentiert sind.

Wie oft müssen Zugriffsrechte unter NIS2 überprüft werden?

Die CIR verlangt Überprüfungen „in geplanten Zeitabständen“ (Nr. 11.2.3, für privilegierte Konten Nr. 11.3.3) und eine regelmäßige Überprüfung der Kennungen (Nr. 11.5.4), nennt aber kein festes Intervall. Die ENISA-Umsetzungsleitlinie empfiehlt, Zugriffsrechte mindestens jährlich und aktive Kennungen mindestens vierteljährlich zu überprüfen (Kleinstunternehmen: jährlich). Verbreitete Praxis sind vierteljährliche Prüfungen privilegierter Konten, jährliche Prüfungen von Standardkonten und anlassbezogene Prüfungen nach Rollenwechsel, Austritt oder Vorfall. Legen Sie den Rhythmus in Ihrer Richtlinie fest und dokumentieren Sie die Ergebnisse.

Gelten die Anforderungen auch für Auftragnehmer und Dienstleister?

Ja, soweit sie Zugang zu Ihren Systemen haben. Die CIR bezieht direkte Anbieter und Diensteanbieter gegebenenfalls in die Sicherheitsverpflichtung (Nr. 10.1.1) und die Zuverlässigkeitsüberprüfung (Nr. 10.2.1) ein. Das Zugriffskonzept muss für Personal, Besucher und externe Einrichtungen gelten (Nr. 11.1.2), und Zugänge Dritter sind nach Umfang und Dauer zu beschränken (Nr. 11.2.2 Buchst. d). Verknüpfen Sie Dienstleisterzugänge mit der Vertragslaufzeit und prüfen Sie sie bei jeder Verlängerung.

Ist MFA unter NIS2 Pflicht?

§ 30 Abs. 2 Nr. 10 BSIG nennt die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung als Mindestmaßnahme; wie weit sie reichen muss, richtet sich nach der Verhältnismäßigkeit (§ 30 Abs. 1 BSIG). Für die elf von der CIR erfassten Einrichtungsarten verlangt Nr. 11.7.1 MFA oder kontinuierliche Authentifizierung „soweit angemessen“ entsprechend der Klassifizierung der Werte; für privilegierte Konten nennt Nr. 11.3.2 Buchst. a MFA ausdrücklich als Beispiel starker Authentifizierung. Einzelheiten finden Sie im Leitfaden zu den MFA-Anforderungen nach NIS2.

Ist Single Sign-on (SSO) unter NIS2 vorgeschrieben?

Nein, weder NIS2 noch die CIR verlangen SSO ausdrücklich. SSO erleichtert jedoch die einheitliche Durchsetzung von MFA über alle Anwendungen und macht den Entzug von Zugängen zuverlässiger: Die Deaktivierung eines Kontos beim Identitätsanbieter beendet den Zugang zu allen angebundenen Systemen. Für Organisationen mit vielen Anwendungen ist SSO deshalb eine sinnvolle, verhältnismäßige Maßnahme.

Was gilt für gemeinsam genutzte Konten?

Vermeiden Sie sie, wo immer möglich: Sie untergraben die Nachvollziehbarkeit und erschweren die Untersuchung von Vorfällen sowie den Entzug von Zugängen. Die CIR lässt Kennungen, die mehreren Personen zugewiesen sind, nur zu, wenn sie aus geschäftlichen oder operativen Gründen erforderlich sind, einem ausdrücklichen Genehmigungsverfahren unterliegen, dokumentiert und im Risikomanagement berücksichtigt werden (Nr. 11.5.3). Protokollieren Sie die Nutzung und ändern Sie die Passwörter, sobald jemand mit Kenntnis der Zugangsdaten ausscheidet oder die Rolle wechselt.

Welche Zuverlässigkeitsüberprüfungen verlangt NIS2?

Die CIR verlangt Kriterien, welche Rollen nur von überprüften Personen wahrgenommen werden dürfen, und die Überprüfung vor Aufnahme der Rolle (Nr. 10.2.2) – unter Berücksichtigung der geltenden Gesetze und im Verhältnis zu Risiko und Klassifizierung der Werte. Ein bestimmtes Prüfniveau oder eine behördliche Sicherheitsüberprüfung schreibt sie nicht vor. In Deutschland begrenzen Arbeits- und Datenschutzrecht, welche Auskünfte, etwa ein Führungszeugnis, verlangt werden dürfen.

Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechtsberatung dar. Ziehen Sie für eine auf Ihre Situation zugeschnittene Beurteilung einen qualifizierten Rechts- oder Compliance-Spezialisten hinzu.

Quellen

• Richtlinie (EU) 2022/2555 (NIS2-Richtlinie), Art. 21 Abs. 2 Buchst. i und j — Volltext (ELI/EUR-Lex)
• Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024, Art. 1 und Anhang Abschnitte 10, 11 und 12 — Volltext (ELI/EUR-Lex)
• BSI-Gesetz (BSIG) in der Fassung des NIS2UmsuCG, § 30 (Risikomanagementmaßnahmen) — gesetze-im-internet.de
• ENISA: NIS2 Technical Implementation Guidance, Version 1.0, Juni 2025 (Abschnitte 10 und 11) — ENISA-Publikationen
• Bundesarbeitsgericht, Urteil vom 17.10.2024 – 8 AZR 172/23 — bundesarbeitsgericht.de
• Betriebsverfassungsgesetz (BetrVG), § 87 Abs. 1 Nr. 1 und Nr. 6 — gesetze-im-internet.de
• ISO/IEC 27001:2022, Anhang A, Controls A.5.15–A.5.18 (Zugriffssteuerung) und A.6 (Personenbezogene Maßnahmen)