Berechtigungskonzept-Vorlage: Seit dem 6. Dezember 2025 NIS2-Pflicht — 9 Kapitel und der Nachweis zu jedem

§ 30 Absatz 2 Nummer 9 BSIG verlangt wörtlich die „Erstellung von Konzepten für die Sicherheit des Personals, die Zugriffskontrolle und für die Verwaltung von IKT-Systemen“ [1]. Das Verb trägt die ganze Pflicht: Gefordert ist nicht nur, dass Ihre Zugriffskontrolle technisch funktioniert, sondern dass ein Konzept dazu existiert. Eine sauber gepflegte Active-Directory-Struktur ohne dazugehöriges Dokument erfüllt Nummer 9 nicht — ein Prüfer kann Gruppenrichtlinien nicht als Konzept lesen.

Diese Pflicht gilt seit dem 6. Dezember 2025, dem Tag nach der Verkündung des NIS-2-Umsetzungsgesetzes im Bundesgesetzblatt (BGBl. 2025 I Nr. 301) [12][13]. Eine Übergangsfrist für die Maßnahmen nach § 30 sieht das Gesetz nicht vor.

Dieser Leitfaden beschreibt neun Kapitel, aus denen ein prüfungsfestes Berechtigungskonzept besteht, und für jedes Kapitel den Nachweis, den eine Prüfung dazu tatsächlich anfordert.

Gilt die Pflicht für Ihr Unternehmen?

Kurz: Fällt Ihr Unternehmen als besonders wichtige oder wichtige Einrichtung unter das BSIG, gilt § 30 Absatz 2 Nummer 9 unmittelbar. Was sich unterscheidet, ist nicht die Pflicht, sondern die Rechtsgrundlage, auf der jemand das Dokument sehen will. Ob Sie überhaupt in den Anwendungsbereich fallen, klärt unsere Übersicht zu den betroffenen Unternehmen.

Einrichtungstyp	Grundlage für das Konzept	Wie die Aufsicht ansetzt
Besonders wichtige Einrichtung	§ 30 Abs. 2 Nr. 9 BSIG	Anlasslose Prüfung möglich; BSI kann Audits anordnen (§ 61 Abs. 1) und vor Ort Unterlagen verlangen (§ 61 Abs. 5) [4]
Wichtige Einrichtung	§ 30 Abs. 2 Nr. 9 BSIG	Nur anlassbezogen: erst wenn „Tatsachen die Annahme“ einer Pflichtverletzung rechtfertigen (§ 62) [5]
Betreiber kritischer Anlagen	§ 30 Abs. 2 Nr. 9 BSIG, zusätzlich § 39	Turnusmäßiger Nachweis gegenüber dem BSI, „anschließend alle drei Jahre“; BSI kann die zugrunde liegende Dokumentation anfordern [3]
Digitale Einrichtungen im Geltungsbereich der DVO (EU) 2024/2690	Zusätzlich Anhang Nr. 11 der Verordnung, unmittelbar geltend	Deutlich detailliertere Vorgaben je Teilaspekt (11.1 bis 11.7) [7][8][9][10]

Die letzte Zeile wird am häufigsten falsch gelesen. Die Durchführungsverordnung (EU) 2024/2690 gilt nicht für alle NIS2-Einrichtungen, sondern für elf digitale Einrichtungstypen — unter anderem DNS-Diensteanbieter, TLD-Namenregister, Cloud- und Rechenzentrumsdienste, CDN-Betreiber, verwaltete Dienste und Sicherheitsdienste, Online-Marktplätze, Suchmaschinen, soziale Netzwerke und Vertrauensdiensteanbieter [11]. Für einen Maschinenbauer oder ein Krankenhaus ist Anhang 11 damit kein unmittelbar geltendes Recht, sondern ein brauchbarer Prüfmaßstab — Systematik im Leitfaden zur NIS2-Durchführungsverordnung.

Warum das Dokument selbst die Pflicht ist

Drei Regelwerke verlangen dasselbe Dokument — mit drei unterschiedlichen Rechtsfolgen, die man nicht vermischen sollte.

Das BSIG ist die bindende Grundlage. § 30 Abs. 2 Nr. 9 nennt die Erstellung von Konzepten als eigenständige Maßnahme neben den neun übrigen Maßnahmenbereichen [1]; die Systematik der Aufzählung erklären wir in unserem Überblick zu den 10 Risikomanagementmaßnahmen.

Der BSI-IT-Grundschutz ist kein Gesetz, liefert aber den konkretesten deutschen Maßstab dafür, was in dem Konzept stehen muss. Der Baustein ORP.4 des IT-Grundschutz-Kompendiums enthält elf Basis-Anforderungen mit MUSS-Charakter; ORP.4.A3 formuliert die Dokumentationspflicht wörtlich: „Es MUSS dokumentiert werden, welche Benutzendenkennungen, angelegte Benutzendengruppen und Rechteprofile zugelassen und angelegt wurden.“ Und weiter: Die Dokumentation „MUSS regelmäßig daraufhin überprüft werden, ob sie den tatsächlichen Stand der Rechtevergabe widerspiegelt“ [6]. Wer ORP.4 als Gliederungsvorlage nimmt, argumentiert im Streitfall mit dem Maßstab der Behörde, die ihn prüft.

Die Durchführungsverordnung ist für die elf genannten Einrichtungstypen unmittelbar geltendes Recht und formuliert unter Nummer 11.1.1 den Dreiklang, der die Absicht am klarsten zeigt: Konzepte für die logische und physische Zugriffskontrolle sind festzulegen, zu dokumentieren und umzusetzen [7]. Dokumentieren steht als eigener Schritt neben dem Umsetzen, nicht als dessen Nebenprodukt.

Die neun Kapitel einer prüfungsfesten Vorlage

Die folgende Struktur ist keine gesetzliche Aufzählung, sondern eine Gliederung, die wir aus § 30 Abs. 2 Nr. 9 BSIG, den elf ORP.4-Basis-Anforderungen und Anhang Nr. 11 der DVO 2024/2690 abgeleitet haben. Ihr Zweck ist praktisch: Jedes Kapitel deckt genau einen Prüfpunkt ab, sodass eine Prüfung nicht quer durch das Dokument springen muss.

Kapitel	Inhalt	Verankerung
1. Zweck, Geltungsbereich, Rechtsgrundlage	Welche Systeme, Standorte und Personengruppen erfasst sind; benannte Ausnahmen	DVO 11.1.1, 11.1.2 (a)/(b) [7]
2. Rollen und Verantwortlichkeiten	Wer beantragt, wer genehmigt, wer setzt um, wer prüft, wer gibt frei	ORP.4 (ISB grundsätzlich zuständig) [6]; DVO 11.2.2 (c) [8]
3. Grundsätze	Least Privilege, Need-to-know, Need-to-use, Funktionstrennung	ORP.4.A2, ORP.4.A4 [6]; DVO 11.2.2 (a) [8]
4. Rollen- und Rechtemodell	Rollenkatalog, Berechtigungsmatrix, unvereinbare Rollenkombinationen	ORP.4.A3, ORP.4.A4 [6]
5. Vergabe, Änderung, Entzug	Joiner-Mover-Leaver mit Antrags-, Genehmigungs- und Fristenregeln; externe Dritte	ORP.4.A2, A5–A7 [6]; DVO 11.2.2 (b)/(d) [8]
6. Privilegierte Konten	Getrennte Adminkennungen, Systemverwaltungssysteme, Break-Glass-Verfahren	DVO 11.3.2, 11.4.2 [9][10]; ORP.4.A10 [6]
7. Identifizierung und Authentifizierung	Eindeutige Kennungen, Passwortregeln, MFA-Geltungsbereich	ORP.4.A1, A8, A9, A22, A23 [6]; § 30 Abs. 2 Nr. 10 [1]
8. Rezertifizierung	Intervalle, Umfang, Verantwortliche, Umgang mit Feststellungen	DVO 11.1.3, 11.2.3, 11.3.3 [7][8][9]; ORP.4.A3 [6]
9. Protokollierung, Lenkung, Freigabe	Register der Rechte, Protokollierung der Verwaltungsvorgänge, Versionierung, Managementfreigabe	DVO 11.2.2 (e)/(f) [8]; § 38 Abs. 1 BSIG [2]

Kapitel 3 hängt an den richtigen Begriffen. Die deutsche Fassung von DVO 11.2.2 (a) nennt drei Grundsätze: „Kenntnis nur, wenn nötig“ (Need-to-know), die „Nutzungsnotwendigkeit (Need-to-use)“ und die Aufgabentrennung. „Need-to-use“ ist dort die Übersetzung von „least privilege“ aus der englischen Fassung, kein vierter Grundsatz. Wie Sie beide Begriffe im Konzept nebeneinanderstellen und jede Berechtigung mit zwei Prüffragen testen, zeigt unser Leitfaden zum Need-to-know-Prinzip und Least Privilege.

Vier dieser Kapitel lassen sich nicht improvisieren — sie brauchen Daten, die erst über Monate entstehen.

Kapitel 4 ist der Kern und zugleich die häufigste Schwachstelle. Eine Berechtigungsmatrix, die Rollen auf Systeme abbildet, ohne die unvereinbaren Kombinationen zu benennen, erfüllt ORP.4.A4 nicht: Dort ist gefordert, dass die von der Institution definierten unvereinbaren Aufgaben und Funktionen „durch das Identitäts- und Berechtigungsmanagement getrennt werden“ MÜSSEN [6]. Ohne eine Liste dieser Kombinationen ist die Trennung nicht prüfbar.

Kapitel 5 muss den Leaver-Fall mit einer Frist versehen: Rechte sind „bei Beendigung oder Änderung des Beschäftigungsverhältnisses entsprechend“ zu ändern [8]. Der Mover-Fall — Abteilungswechsel ohne Entzug der alten Rechte — ist der teurere. Das BSI beschreibt in der Gefährdungslage zu ORP.4 ausdrücklich, dass Versetzte ihre alten Berechtigungen behalten und „mit der Zeit umfangreiche Gesamtberechtigungen ansammeln“ [6].

Kapitel 6 braucht eine harte Trennung. Die DVO verlangt spezielle Konten, die „ausschließlich für Systemverwaltungsvorgänge, wie Installation, Konfiguration, Verwaltung oder Wartung“ zu verwenden sind, und lässt sie nur zur Verbindung mit Systemverwaltungssystemen zu [9]; diese sind logisch von sonstiger Anwendungssoftware zu trennen und durch Authentifizierung und Verschlüsselung zu schützen [10]. Ein Administrator, der mit demselben Konto E-Mails liest und Domain-Controller konfiguriert, verstößt gegen beide Punkte.

Kapitel 7 verweist auf die MFA-Pflicht, wiederholt sie aber nicht: § 30 Abs. 2 Nr. 10 BSIG behandelt Multi-Faktor-Authentifizierung als eigenen Maßnahmenbereich [1], das Berechtigungskonzept legt nur fest, für welche Rollen und Systeme sie greift — Details im Leitfaden zu den MFA-Anforderungen.

Der Nachweis zu jedem Kapitel

Ein Konzept, das seine eigenen Regeln nicht belegt, ist im Audit eine Absichtserklärung. Die folgende Zuordnung zeigt, welchen Beleg eine Prüfung typischerweise zu welchem Kapitel anfordert — und woher er im laufenden Betrieb stammt. Den übergeordneten Rahmen, welche Nachweise das BSIG insgesamt verlangt, behandelt unser Leitfaden zu den NIS2-Dokumentationspflichten.

Kapitel	Angeforderter Nachweis	Quelle im Betrieb
1 Geltungsbereich	Systemliste mit Zuordnung „im Konzept erfasst / bewusst ausgenommen“	Asset-Inventar
2 Rollen	Namentliche Benennung der Genehmigenden je System	Organigramm, Vertretungsregelung
3 Grundsätze	Zwei bis drei abgelehnte Berechtigungsanträge mit Begründung	Ticketsystem
4 Rechtemodell	Aktueller Export der Berechtigungsmatrix, Liste unvereinbarer Kombinationen	IAM- oder Verzeichnisdienst
5 Vergabe und Entzug	Drei Leaver-Fälle des letzten Quartals mit Zeitstempel Austritt zu Sperrung	HR-Meldung plus Ticket
6 Privilegierte Konten	Liste aller Adminkonten mit Personenzuordnung; Break-Glass-Protokolle	Verzeichnisdienst, PAM-Lösung
7 Authentifizierung	MFA-Abdeckungsgrad je Rollengruppe	Identitätsprovider-Report
8 Rezertifizierung	Letzter Rezertifizierungslauf inklusive Feststellungen und Erledigungsstand	Rezertifizierungsprotokoll
9 Lenkung und Freigabe	Versionshistorie und datierte Freigabe der Geschäftsleitung	Dokumentenlenkung

Erfahrungsgemäß fehlen zwei Nachweise besonders häufig: die Liste der bewusst ausgenommenen Systeme aus Kapitel 1 und die abgelehnten Anträge aus Kapitel 3. Beide belegen, dass Grenzen tatsächlich gezogen wurden — ein Konzept ohne eine einzige dokumentierte Ablehnung liest sich, als sei es nie angewendet worden. Eine Ausnahme ist dabei kein Mangel; sie wird erst zu einem, wenn sie undokumentiert bleibt.

Wer darf das Konzept wann verlangen?

Hier liegt der folgenreichste Irrtum. Aus § 61 Abs. 3 BSIG wird gelegentlich abgeleitet, das BSI könne bis Dezember 2028 ohnehin nichts anfordern. Das trifft nur auf eine von vier Konstellationen zu.

Rechtsgrundlage	Was das BSI verlangen kann	Ab wann
§ 61 Abs. 1	Anordnung von Audits, Prüfungen oder Zertifizierungen durch unabhängige Stellen	Sofort — keine Wartefrist im Text [4]
§ 61 Abs. 5	Überprüfung vor Ort; Betretensrecht und Pflicht, „Aufzeichnungen, Schriftstücke und sonstigen Unterlagen in geeigneter Weise“ vorzulegen	Sofort — keine Wartefrist im Text [4]
§ 61 Abs. 3	Anordnung, Nachweise über die Erfüllung der Pflichten vorzulegen	„Frühestens drei Jahre nach Inkrafttreten“ — also frühestens 6. Dezember 2028; für zugelassene Krankenhäuser nach § 108 SGB V frühestens fünf Jahre, also 6. Dezember 2030 [4]
§ 62	Überprüfung wichtiger Einrichtungen und Maßnahmen nach § 61	Sobald „Tatsachen die Annahme“ einer Pflichtverletzung rechtfertigen [5]

Die Dreijahresfrist begrenzt also die routinemäßige Nachweisanordnung — nicht die Aufsicht als solche. Ein Sicherheitsvorfall, eine Beschwerde oder ein Hinweis genügt, damit § 61 Abs. 5 oder § 62 greifen, und dann ist das Berechtigungskonzept eine der ersten Unterlagen, die auf dem Tisch liegen muss. Bei wichtigen Einrichtungen ist die Aufsicht ohnehin rein anlassbezogen ausgestaltet: § 62 setzt voraus, dass Tatsachen die Annahme rechtfertigen, Pflichten würden nicht oder nicht richtig umgesetzt [5].

Für Betreiber kritischer Anlagen gilt zusätzlich der eigene Turnus aus § 39 BSIG: Nachweis gegenüber dem Bundesamt und „anschließend alle drei Jahre“, wobei das BSI die Vorlage der Dokumentation verlangen kann, die der Überprüfung zugrunde lag [3]. Wie sich eine solche Prüfung praktisch vorbereiten lässt, beschreibt unser Leitfaden zur NIS2-Audit-Vorbereitung.

Nach § 61 Abs. 4 wählt das BSI zudem nicht zufällig aus, sondern nach Risikoexposition, Größe der Einrichtung sowie Eintrittswahrscheinlichkeit und Schwere möglicher Sicherheitsvorfälle [4]. Wer in einem exponierten Sektor arbeitet, sollte die Dreijahresfrist nicht als Planungsgrundlage behandeln.

Rezertifizierung: „in geplanten Zeitabständen“ statt „einmal im Jahr“

Nahezu jede frei verfügbare Vorlage schreibt eine jährliche Rezertifizierung vor. Der Verordnungstext tut das nicht. Er verlangt an drei Stellen eine Überprüfung „in geplanten Zeitabständen“ — für das Zugriffskontrollkonzept insgesamt (11.1.3), für gewöhnliche Zugangs- und Zugriffsrechte (11.2.3) und gesondert für privilegierte Konten (11.3.3) [7][8][9]. Zusätzlich ist anzupassen bei organisatorischen Änderungen sowie nach erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen von Betrieb oder Risiken [7][8].

Der Unterschied ist kein Formalismus. „Geplant“ heißt: Sie legen das Intervall fest, begründen es risikobasiert und dürfen es je Gruppe unterschiedlich setzen. Privilegierte Konten deutlich häufiger zu prüfen als Standardrollen bewährt sich in der Praxis — die Verordnung behandelt sie nicht ohne Grund in einer eigenen Ziffer. Ein jährlicher Turnus für alles ist zulässig, aber eine begründungspflichtige Wahl und kein Rechtssatz, den Sie zitieren können. In Kapitel 8 gehört deshalb nicht nur das Intervall, sondern der Grund dafür.

Beide Regelwerke verlangen außerdem, die Ergebnisse festzuhalten [6][8][9]. Ein Rezertifizierungslauf ohne schriftliche Feststellungen erzeugt keinen Nachweis.

Wer schreibt, wer gibt frei, wer haftet

Der IT-Grundschutz benennt für ORP.4 die grundsätzlich zuständige Rolle eindeutig: die oder der Informationssicherheitsbeauftragte, mit IT-Betrieb und Benutzenden als weiteren Zuständigkeiten [6]. Die Freigabe liegt jedoch eine Ebene höher.

§ 38 Abs. 1 BSIG verpflichtet Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen, die nach § 30 zu ergreifenden Risikomanagementmaßnahmen „umzusetzen und ihre Umsetzung zu überwachen“ [2]. Da das Berechtigungskonzept selbst eine solche Maßnahme ist, gehört eine datierte Freigabe durch die Geschäftsleitung in Kapitel 9 — sie ist der einzige Beleg dafür, dass die Überwachungspflicht wahrgenommen wurde. § 38 Abs. 2 knüpft daran eine Haftung für schuldhaft verursachte Schäden nach den gesellschaftsrechtlichen Regeln der jeweiligen Rechtsform [2]; die Einzelheiten behandeln wir unter Managementhaftung nach NIS2.

Praktisch: Das Konzept wird vom ISB erstellt, mit dem IT-Betrieb abgestimmt, von den Systemverantwortlichen inhaltlich getragen — und von der Geschäftsleitung schriftlich in Kraft gesetzt. Fehlt der letzte Schritt, fehlt nicht nur eine Unterschrift, sondern der Nachweis zu § 38.

Fünf Fehler, die das Konzept im Audit entwerten

Fehler	Warum er auffällt	Korrektur
Sammelkennungen ohne Personenzuordnung	ORP.4.A1: Jede Benutzendenkennung MUSS eindeutig einer Person zugeordnet werden können [6]	Funktionskonten mit benannter verantwortlicher Person und Zweckbindung dokumentieren
Standard- und Gastkonten aktiv gelassen	ORP.4.A1 verlangt Deaktivierung oder Löschung nicht benötigter Kennungen [6]	Einmalige Bereinigung, danach als Prüfpunkt in die Rezertifizierung
Berechtigungen „auf Zuruf“	Das BSI führt genau dies als Gefährdung: verstreute Zuständigkeiten und Wildwuchs in der Rechtevergabe [6]	Ein Antragsweg, benannte Genehmigende, Ticketpflicht ohne Ausnahme
Externe Dritte nicht erfasst	DVO 11.2.2 (d) verlangt Regelungen für Besucher, Lieferanten und Dienstleister mit Begrenzung von Umfang und Dauer [8]	Eigener Abschnitt in Kapitel 5 mit befristeten Konten und Verlängerungsregel
Keine zentrale Sperrmöglichkeit	Ohne sie lassen sich bei Verdacht nicht alle Konten in einem Schritt sperren — vom BSI als eigene Gefährdung beschrieben [6]	Kennungsschema vereinheitlichen, Konten pro Person nachweisbar zusammenführen

Ein sechster Fehler ist ein Reihenfolgeproblem: Wer das Konzept schreibt, bevor das Asset-Inventar steht, definiert Rechte für eine Systemlandschaft, die er nicht vollständig kennt. Kapitel 1 setzt die Bestandsaufnahme voraus — Grundlagen im Leitfaden zum NIS2-Asset-Management.

Häufig gestellte Fragen

Reicht eine kostenlose Berechtigungskonzept-Vorlage aus dem Internet?
Als Gliederung ja, als Nachweis nein. Die gängigen frei verfügbaren Muster sind auf DSGVO und ISO 27001 ausgerichtet und referenzieren § 30 BSIG in der Regel nicht. Prüffähig wird ein Dokument erst durch Ihre konkreten Rollen, Systeme, Fristen und Belege — die Vorlage liefert nur das Gefäß.

Genügt unser bestehendes ISO-27001-Zugangssteuerungsdokument?
Meist als Basis, nicht als Ganzes. Ein ISO-konformes Access-Control-Dokument deckt Kapitel 3 bis 5 in der Regel gut ab. Ergänzen müssen Sie typischerweise Kapitel 1 (ausdrücklicher Bezug auf § 30 Abs. 2 Nr. 9), Kapitel 8 (begründetes Intervall statt Standardformulierung) und Kapitel 9 (Freigabe der Geschäftsleitung nach § 38 Abs. 1) [1][2].

Wie lang sollte das Dokument sein?
Das Gesetz macht keine Vorgabe. In der Praxis sind bei mittelständischen Betrieben 12 bis 20 Seiten üblich, wenn Matrix und Rollenkatalog als Anlagen geführt werden. Entscheidend ist nicht der Umfang, sondern ob zu jedem Kapitel ein Beleg existiert.

Muss das Konzept auch physische Zutrittsrechte abdecken?
Für Einrichtungen im Geltungsbereich der DVO ausdrücklich ja: Nummer 11.1.1 nennt die logische und die physische Zugriffskontrolle [7]. Der IT-Grundschutz behandelt Zutritt, Zugang und Zugriff ohnehin in drei eigenen Basis-Anforderungen (ORP.4.A5 bis A7) [6]. Für alle anderen Einrichtungen ist die gemeinsame Behandlung eine Empfehlung — aber eine, die eine Prüfung erwartet.

Was passiert, wenn wir das Konzept schlicht nicht haben?
Das Konzept ist der Gegenstand von § 30 Abs. 2 Nr. 9 und damit Teil der Umsetzungspflicht aus § 30 Abs. 1 [1]. Wird sein Fehlen in einer Prüfung festgestellt, kann das BSI einen Mängelbeseitigungsplan und einen Nachweis über die erfolgte Beseitigung verlangen [4][5]. Der praktisch teurere Effekt ist ein anderer: Ohne Konzept lässt sich zu keiner der übrigen Zugriffsanforderungen ein geordneter Nachweis führen.

Was Sie in dieser Woche tun können

Der schnellste Weg zu einem prüfbaren Zwischenstand führt über die drei Kapitel, die am wenigsten von fremden Zuarbeiten abhängen: Kapitel 1 aus dem vorhandenen Asset-Inventar ableiten, Kapitel 2 mit den namentlich Genehmigenden je System füllen, Kapitel 9 mit Versionsstand und einem Termin für die Freigabe der Geschäftsleitung anlegen. Damit steht das Gerüst, in das Rollenmodell und Rezertifizierung später einziehen.

Was den Unterschied macht, ist nicht die Vorlage, sondern die Nachweisspur: Wer zu jedem Kapitel sagen kann, welcher Export, welches Ticket und welches Protokoll es belegt, hat § 30 Abs. 2 Nr. 9 erfüllt — unabhängig davon, ob die Aufsicht 2026 oder 2028 fragt. Wer nur ein schönes Dokument hat, hat eine Absichtserklärung.

Die zugrunde liegenden Anforderungen an Zugangssteuerung und Personalsicherheit — einschließlich der CIR-Ziffern 10.1 bis 11.4 und des Joiner-Mover-Leaver-Prozesses — behandelt unser Hub-Leitfaden zur NIS2-Zugangssteuerung und Personalsicherheit.

Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechts- oder Compliance-Beratung dar. Anforderungen können je nach Rechtsform, Sektor und Einzelfall abweichen. Konsultieren Sie für eine auf Ihr Unternehmen zugeschnittene Bewertung eine qualifizierte Rechts- oder Compliance-Fachkraft.

Quellen

• [1] § 30 BSIG — Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen (gesetze-im-internet.de; im Text verlinkt)
• [2] § 38 BSIG — Umsetzungs-, Überwachungs- und Schulungspflicht für Geschäftsleitungen (gesetze-im-internet.de)
• [3] § 39 BSIG — Nachweispflichten für Betreiber kritischer Anlagen (gesetze-im-internet.de)
• [4] § 61 BSIG — Aufsichts- und Durchsetzungsmaßnahmen für besonders wichtige Einrichtungen (buzer.de; im Text verlinkt)
• [5] § 62 BSIG — Aufsichts- und Durchsetzungsmaßnahmen für wichtige Einrichtungen (buzer.de)
• [6] BSI, IT-Grundschutz-Baustein ORP.4 — Identitäts- und Berechtigungsmanagement, Edition 2023 (bsi.bund.de; im Text verlinkt)
• [7] DVO (EU) 2024/2690, Anhang Nr. 11.1 — Konzept für die Zugriffskontrolle (nis2-umsetzung.com)
• [8] DVO (EU) 2024/2690, Anhang Nr. 11.2 — Management von Zugangs- und Zugriffsrechten (nis2-umsetzung.com)
• [9] DVO (EU) 2024/2690, Anhang Nr. 11.3 — Privilegierte Konten und Systemverwaltungskonten (nis2-umsetzung.com)
• [10] DVO (EU) 2024/2690, Anhang Nr. 11.4 — Systemverwaltungssysteme (nis2-umsetzung.com)
• [11] Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 — Geltungsbereich (gesetze.legal; amtlicher Text: EUR-Lex CELEX 32024R2690)
• [12] Gesetz zur Umsetzung der NIS-2-Richtlinie … — BGBl. 2025 I Nr. 301, verkündet am 5. Dezember 2025 (recht.bund.de)
• [13] DNV, Umsetzungsgesetz der NIS-2-Richtlinie in Kraft getreten (dnv.de)