NIS2 Maßnahme 9 — Personalsicherheit und Zugangskontrolle

NIS2 Personalsicherheit und Zugangskontrolle

Die NIS2-Maßnahme 9 gemäß Art. 21(2)(i) verpflichtet Unternehmen, Personalsicherheit, Zugangskontrollrichtlinien und ein Asset-Management für ihre IT-Systeme zu implementieren. Für die Praxis heißt das: NIS2 Personalsicherheit ist ohne saubere Rollenmodelle, dokumentierte Berechtigungsprozesse, abgesicherte Admin-Konten und regelmäßige Schulungen nicht erfüllt. Inhaltlich entspricht die Maßnahme grob den klassischen ISO-27001-Bausteinen Annex A.7, A.8 und A.9, also Personalsicherheit, Asset Management und Zugriffskontrolle.

Letzte Aktualisierung: 21. März 2026

Die kurze Antwort lautet: Wenn Sie Art. 21(2)(i) ernsthaft umsetzen wollen, müssen Sie den gesamten Lebenszyklus von Identitäten, Rechten und Assets steuern. Dazu gehören risikobasierte Prüfungen vor oder bei Eintritt, ein dokumentiertes Rollen- und Berechtigungsmodell, konsequentes Onboarding und Offboarding, besondere Kontrollen für privilegierte Zugänge sowie eine wiederkehrende Schulungslogik nach Art. 20(2). Als Einstieg in die Gesamtarchitektur helfen Ihnen auch unsere Beiträge zu NIS2 Maßnahme 10 MFA, zur NIS2 Risikoanalyse und zur NIS2 Checkliste.

Was verlangt Art. 21(2)(i) NIS2 zur Personalsicherheit?

Art. 21(2)(i) der Richtlinie (EU) 2022/2555 bündelt drei Themen, die Unternehmen in der Praxis oft fälschlich getrennt behandeln: Personalsicherheit, Konzepte für die Zugriffskontrolle und Management von Anlagen. Genau diese Kombination ist entscheidend. Wer nur HR-Screenings einführt, aber keine sauberen Berechtigungsprozesse hat, verfehlt die Norm ebenso wie ein Unternehmen mit moderner IAM-Lösung, das Offboarding und Schulungsnachweise vernachlässigt.

Personalsicherheit beginnt vor dem ersten Login. Für sensible Funktionen müssen Sie festlegen, welche Vorprüfungen rechtlich zulässig, risikobasiert und angemessen sind. Dazu können Identitätsprüfung, Referenzprüfung, Nachweis relevanter Qualifikationen und in eng begrenzten Fällen weitergehende Prüfungen gehören, soweit deutsches Arbeitsrecht, Datenschutzrecht und betriebsverfassungsrechtliche Vorgaben das tragen. Die operative Frage lautet nicht, ob jede Rolle gleich behandelt wird, sondern welche Rolle Zugriff auf kritische Systeme, sensible Informationen oder weitreichende Berechtigungen erhält.

NIS2 verlangt außerdem, dass Beschäftigte über ihre Sicherheitsverpflichtungen informiert werden und diese einhalten. Damit wird Personalsicherheit zu einer Governance-Frage. Personalabteilung, Fachbereich, IT und Informationssicherheit müssen gemeinsam festlegen, welche Verpflichtungen für welche Rolle gelten, wie diese Verpflichtungen bestätigt werden und welche Nachweise im Audit vorliegen sollen. Ohne dokumentierte Prozesse bleibt die Umsetzung angreifbar, selbst wenn sie faktisch teilweise existiert.

Der dritte Bestandteil, das Management von Anlagen, wird häufig unterschätzt. Berechtigungen lassen sich nur dann steuern, wenn klar ist, welche Systeme, Anwendungen, Endgeräte, Datenbestände und privilegierten Schnittstellen überhaupt existieren. Ein veraltetes Asset-Inventar führt fast zwangsläufig zu verwaisten Konten, zu vielen Rechten und unklaren Verantwortlichkeiten. Deshalb gehört das Asset-Management in dieselbe NIS2-Maßnahme wie Personalsicherheit und Zugriffskontrolle.

Für deutsche Unternehmen entsteht zusätzlich ein Bezug zum nationalen Umsetzungsrahmen. Im NIS2-Umsetzungsgesetz wird die Maßnahme im Entwurf regelmäßig über § 30 Abs. 2 Nr. 9 BSIG-E gespiegelt. Für die tägliche Praxis ist aber weniger die nationale Nummerierung entscheidend als die materielle Aussage: Zugriffsdisziplin und Personalsicherheit müssen Teil Ihres Cyber-Risikomanagements sein, nicht bloß Nebenregelungen in Personalakten oder IT-Richtlinien.

Die folgende Mapping-Tabelle hilft, Maßnahme 9 sauber in bestehende Managementsysteme einzuordnen:

Die Tabelle zeigt den Kernpunkt: NIS2 Personalsicherheit ist kein reines HR-Thema, sondern ein Steuerungsmodell über Menschen, Identitäten, Systeme und Verantwortlichkeiten. Wenn Sie diese Bereiche zusammen denken, schaffen Sie zugleich eine belastbare Grundlage für Audits, Kundenanforderungen und interne Governance.

Zugriffskontrolle — RBAC, ABAC und Least Privilege

NIS2 Zugangskontrolle ist nur wirksam, wenn Rechte nicht individuell improvisiert, sondern systematisch vergeben werden. In der Praxis führt das fast immer zu drei Grundprinzipien: Rollenbasierung, Attributsteuerung dort, wo sie nötig ist, und das Least-Privilege-Prinzip als verbindliche Obergrenze. Ohne diese Logik wachsen Berechtigungen mit jedem Sonderfall und werden mit jeder Ausnahme schwerer beherrschbar.

RBAC, also Role-Based Access Control, ist für die meisten mittelständischen Organisationen der tragfähigste Einstieg. Sie definieren Rollen wie Buchhaltung, HR-Sachbearbeitung, IT-Administration, Vertrieb oder Informationssicherheitsbeauftragte und ordnen jeder Rolle klar definierte Rechte zu. Der Vorteil ist nicht nur technische Einfachheit, sondern vor allem Nachvollziehbarkeit. Auditoren, Fachbereiche und Führungskräfte können nachvollziehen, warum eine Rolle bestimmte Zugriffe benötigt und welche Rechte gerade nicht dazugehören.

ABAC, also Attribute-Based Access Control, wird relevant, wenn starre Rollen allein nicht ausreichen. Attribute können zum Beispiel Standort, Mandant, Sicherheitsstufe, Beschäftigungsstatus, Tageszeit, Gerätetyp oder Projektzugehörigkeit sein. Damit lassen sich feinere Regeln umsetzen, etwa dass ein externer Dienstleister zwar dieselbe Anwendung wie interne Mitarbeitende nutzt, aber nur aus dem Unternehmensnetz, nur zu definierten Zeiten und nur für bestimmte Datensichten. ABAC ist mächtiger, aber auch pflegeintensiver. Ohne saubere Datenqualität und Verantwortlichkeiten wird das Modell schnell intransparent.

Das Least-Privilege-Prinzip ist der Maßstab für beide Modelle. Jede Identität soll nur die Rechte erhalten, die für die aktuelle Aufgabe tatsächlich erforderlich sind. In der Praxis scheitert dieses Prinzip oft nicht an fehlender Technik, sondern an Bequemlichkeit: alte Projektberechtigungen bleiben bestehen, Teamleitungen genehmigen großzügig, Admin-Rechte werden als Problemlöser verteilt, und niemand fühlt sich für die spätere Bereinigung verantwortlich. Genau deshalb muss Least Privilege als Prozesspflicht definiert werden und nicht nur als allgemeiner Sicherheitswunsch.

Für die operative Umsetzung hat sich eine einfache Entscheidungslogik bewährt:

1. Jede Berechtigung wird einer Rolle, einem Attribut oder einer dokumentierten Ausnahme zugeordnet.
2. Jede Ausnahme bekommt einen Zweck, einen Genehmiger und ein Ablaufdatum.
3. Jede privilegierte Berechtigung wird gesondert freigegeben, protokolliert und regelmäßig überprüft.
4. Jeder Remote- und Admin-Zugang wird mit starker Authentisierung abgesichert.

In vielen Unternehmen ist der Übergang zwischen RBAC und ABAC kein Entweder-oder. Ein realistisches Zielbild ist oft ein hybrides Modell: RBAC für die breite Masse, ABAC für besonders sensible oder dynamische Kontexte. Ein Beispiel: Die Rolle "HR" erhält Grundrechte auf das HR-System, während Attribute wie Standort, Betriebszugehörigkeit oder Fallzuständigkeit bestimmen, welche Datensätze konkret sichtbar sind. So bleibt das Grundmodell verständlich, ohne sensible Grenzen aufzuweichen.

Für NIS2 ist außerdem wichtig, dass Zugriffskontrolle nicht nur logische, sondern auch organisatorische Grenzen kennt. Geteilte Konten, generische Administrator-Logins, pauschale Sammelpostfächer oder gemeinsam genutzte Servicekennungen ohne Verantwortungszuordnung sind mit einer reifen Zugriffskontrolle schwer vereinbar. Wenn mehrere Personen denselben Zugang verwenden, leidet nicht nur die Sicherheit, sondern auch die Nachweisbarkeit. Sie können dann weder sauber prüfen noch sauber zuordnen, wer welche Handlung veranlasst hat.

Die Verbindung zu NIS2 Maßnahme 10 MFA ist an dieser Stelle unmittelbar. Selbst ein gutes Rollenmodell bleibt zu schwach, wenn kritische Zugänge nur mit Passwort geschützt sind. MFA ist deshalb kein Ersatz für Rollen- und Rechtekonzepte, sondern deren notwendige Verstärkung.

Berechtigungsmanagement — Vergabe, Entzug, Rezertifizierung

Berechtigungsmanagement entscheidet darüber, ob NIS2 Zugangskontrolle im Alltag funktioniert oder nur auf Papier existiert. Die zentrale Management-Frage lautet: Wer darf welcher Person welchen Zugriff aus welchem Grund geben, ändern, verlängern und entziehen? Wenn diese Frage nicht über einen klaren Prozess beantwortet wird, entstehen mit jeder Einstellung, jedem Projektwechsel und jeder Ausnahme zusätzliche Risiken.

Ein belastbarer Vergabeprozess beginnt mit einem Antrag, der den geschäftlichen Zweck benennt. Rechte sollten nicht "für alle Fälle" beantragt werden, sondern für eine Rolle, eine Aufgabe oder einen konkreten Zeitraum. Danach folgt eine Genehmigungskette, in der mindestens die fachliche Verantwortung und bei sensiblen Zugängen zusätzlich die IT- oder Sicherheitsfunktion eingebunden sind. Besonders bei Finanzsystemen, HR-Anwendungen, Administrationsrechten, Cloud-Konsolen und produktionsnahen Umgebungen muss klar erkennbar sein, wer die Freigabe erteilt hat und auf welcher Grundlage.

Der Entzug von Rechten ist mindestens ebenso wichtig wie die Vergabe. In Audits fällt regelmäßig auf, dass Unternehmen Rechte zuverlässig einräumen, aber zu spät oder gar nicht wieder entziehen. Das betrifft Projektenden, Elternzeit, Rollenwechsel, Wechsel von internen zu externen Tätigkeiten, Ende von Dienstleisterverträgen und klassische Austritte. NIS2-konformes Berechtigungsmanagement behandelt Entzug deshalb als Standardprozess mit Fristen, Verantwortlichkeiten und Nachweisen, nicht als Sonderfall.

Die Rezertifizierung schließt die Lücke zwischen Vergabe und Entzug. Gemeint ist die regelmäßige Prüfung, ob bestehende Rechte noch erforderlich, angemessen und aktuell sind. Für kritische Systeme ist ein quartalsweiser Review häufig der sachgerechte Mindeststandard. Dabei prüft die verantwortliche Führungskraft oder Systemverantwortung, ob Mitarbeitende, Dienstleister und privilegierte Konten weiterhin genau die Zugriffe benötigen, die im System hinterlegt sind. Rezertifizierung ist kein bloßes Abhaken, sondern eine echte Kontrollhandlung.

Eine praxistaugliche Review-Struktur sieht typischerweise so aus:

Ein häufiger Fehler besteht darin, Rezertifizierung nur für Benutzerkonten, nicht aber für technische Konten, API-Schlüssel, Servicekonten oder Gruppenmitgliedschaften durchzuführen. Gerade dort verbergen sich oft stille Risiken. Dienstkonten haben breite Rechte, werden selten betrachtet und bleiben über Jahre aktiv. Aus NIS2-Sicht ist das problematisch, weil die Maßnahme nicht nur menschliche Benutzer, sondern den gesamten Zugriffskontrollrahmen adressiert.

Ebenso kritisch ist die fehlende Trennung zwischen Beantragung und Genehmigung. Wenn dieselbe Person Zugriff anfordert, fachlich begründet, technisch einrichtet und abschließend kontrolliert, fehlen wirksame Gegenkontrollen. Auch in kleineren Organisationen lässt sich dieses Risiko mindern, etwa durch Vier-Augen-Freigaben für kritische Rollen, durch automatisierte Workflows oder durch nachgelagerte Stichproben.

Wenn Sie Berechtigungen strukturiert aufbauen möchten, beginnen Sie nicht bei jedem System einzeln, sondern mit einer unternehmensweiten Mindestlogik: definierte Rollen, definierte Freigabestufen, definierte Review-Zyklen und definierte Sonderprozesse für privilegierte Rechte. Genau diese Basiskontrollen werden auch in einer NIS2 Checkliste regelmäßig als frühe Prioritäten sichtbar.

Onboarding und Offboarding sicher gestalten

Onboarding und Offboarding sind die sichtbarsten Schnittstellen zwischen HR, Fachbereich und IT-Sicherheit. Genau dort entscheidet sich, ob NIS2 Personalsicherheit im Alltag kontrolliert umgesetzt wird oder ob organisatorische Lücken entstehen. Der Grundsatz ist einfach: Niemand erhält produktiven Zugriff ohne definierte Rolle, dokumentierte Freigabe und Kenntnis seiner Sicherheitsverpflichtungen. Und niemand verlässt das Unternehmen oder wechselt in eine neue Rolle, ohne dass alte Zugänge nachweisbar angepasst oder entzogen werden.

Ein sicheres Onboarding beginnt deshalb vor dem ersten Arbeitstag. Für sensible Rollen sollten notwendige Prüfungen abgeschlossen, Vertraulichkeits- und Sicherheitsverpflichtungen dokumentiert, die Zielrolle festgelegt und der Berechtigungsbedarf vorab definiert sein. So vermeiden Sie die in der Praxis häufige Situation, dass am ersten Tag großzügige Übergangsrechte vergeben werden, weil das eigentliche Rollenmodell noch nicht vorbereitet ist.

In der ersten Woche müssen dann vier Dinge sauber zusammenlaufen: Identität anlegen, Rechte rollenbasiert vergeben, MFA aktivieren und Pflichteinweisung durchführen. Die Schulung muss nicht vollständig am ersten Tag abgeschlossen sein, aber die Grundregeln zu Meldewegen, Umgang mit Zugangsdaten, Datenverarbeitung, mobilen Geräten und Verdachtsfällen müssen vor produktiver Nutzung klar sein. Genau hier entsteht die Verbindung zu Art. 20(2) NIS2, der Schulung und Förderung durch die Leitungsorgane ausdrücklich adressiert.

Ein sauberes Offboarding ist noch kritischer, weil es unter Zeitdruck, bei Konflikten oder bei ungeplanten Austritten stattfinden kann. Der Mindeststandard lautet: Alle relevanten Zugänge werden am letzten Arbeitstag oder zum festgelegten Austrittszeitpunkt gesperrt, physische Zutritte entzogen, Geräte zurückgegeben oder technisch kontrolliert, offene Datenübergaben dokumentiert und eventuell bestehende Sonderrechte sofort beendet. Besonders bei privilegierten Konten, Cloud-Konfigurationen, Passwort-Tresoren und Drittanbietersystemen sind manuelle Restzugriffe häufige Schwachstellen.

Folgende Checkliste ist für viele Organisationen ein praxistauglicher Mindeststandard:

Ein weiterer Praxispunkt betrifft externe Personen. Dienstleister, Freelancer, Leiharbeit und projektbezogene Spezialisten werden im Alltag oft außerhalb der klassischen HR-Prozesse geführt, erhalten aber dennoch Zugänge. Für NIS2 ist diese Trennung künstlich. Sobald eine externe Person mit Ihren Systemen, Daten oder Assets arbeitet, brauchen Sie denselben Sicherheitsrahmen: klare Identität, definierter Zweck, zeitliche Begrenzung, Pflichteinweisung und sauberes Offboarding.

Schwache Onboarding- und Offboarding-Prozesse lassen sich selten allein technisch heilen. Die Ursache liegt meist in fehlender Rollenklärung, mangelnder Abstimmung oder unklaren Fristen. Deshalb gehört das Thema auch unmittelbar in die NIS2 Risikoanalyse: Wo entstehen die häufigsten Ausnahmen, Medienbrüche und verspäteten Entzüge? Genau dort sitzt das reale Risiko.

Privilegierte Zugänge (PAM) und Admin-Konten

Privilegierte Zugänge sind das schärfste Risiko im gesamten Berechtigungsmodell. Wenn ein Angreifer oder ein unbefugter Insider Zugriff auf Admin-Konten, Cloud-Root-Rechte, Domain-Admin-Gruppen, Passwort-Tresore oder kritische Servicekonten erhält, versagen nachgelagerte Schutzmaßnahmen oft sehr schnell. Deshalb behandelt eine reife NIS2 Zugangskontrolle privilegierte Zugänge nicht als normalen Spezialfall, sondern als eigene Kontrollklasse.

Der erste Grundsatz lautet: Keine gemeinsamen Admin-Konten ohne eindeutige Verantwortungszuordnung. Shared Accounts zerstören die Nachvollziehbarkeit und erschweren jede forensische Rekonstruktion. Der zweite Grundsatz lautet: Administrative Tätigkeiten werden mit separaten Konten ausgeführt. Wer tagsüber mit einem Standardkonto arbeitet und nur für klar definierte Aufgaben in ein privilegiertes Konto wechselt, reduziert unnötige Exposition. Der dritte Grundsatz lautet: Privilegierte Zugänge brauchen stärkere Authentisierung, engere Reviews und bessere Protokollierung als gewöhnliche Benutzerkonten.

PAM, also Privileged Access Management, ist dabei weniger ein einzelnes Produkt als ein Steuerungskonzept. Typische Elemente sind ein Tresor für privilegierte Zugangsdaten, Just-in-Time-Vergabe statt dauerhafter Admin-Rechte, Genehmigungsworkflows für temporäre Erhöhungen, Sitzungsprotokollierung, Passwortrotation und technische Trennung von Standard- und Administrationskontexten. Für kleinere Umgebungen kann der Einstieg pragmatisch sein: separate Admin-Konten, MFA, dokumentierte Freigaben und monatliche Reviews. Für komplexere Infrastrukturen wird ein dediziertes PAM-Werkzeug schnell sinnvoll.

Besondere Aufmerksamkeit verdienen auch nicht-menschliche privilegierte Identitäten. Dazu gehören Servicekonten, API-Keys, Automatisierungs-Accounts, Secrets in CI/CD-Umgebungen und Integrationsnutzer für Cloud-Dienste. Solche Identitäten werden häufig mit sehr hohen Rechten eingerichtet und danach kaum noch betrachtet. Aus NIS2-Sicht ist das riskant, weil sie praktisch denselben Schaden anrichten können wie ein kompromittiertes Admin-Konto, aber oft außerhalb klassischer HR- und IAM-Prozesse laufen.

Ein belastbares Mindestmodell für privilegierte Zugänge umfasst:

1. Trennung von Standard- und Admin-Konten.
2. MFA für alle privilegierten und entfernten Zugriffe.
3. Zeitlich begrenzte Rechteerhöhung statt Dauergenehmigung.
4. Monatliche oder mindestens quartalsweise Prüfung aller privilegierten Gruppen.
5. Protokollierung von Vergabe, Nutzung, Änderung und Entzug.
6. Regelmäßige Kontrolle von Servicekonten, Secrets und Integrationen.

Privilegierte Konten sind außerdem eng mit Asset-Management verknüpft. Sie können nur dann priorisieren und absichern, wenn bekannt ist, auf welche Systeme diese Konten wirken, welche Geschäftsprozesse betroffen sind und wer die Eigentümer der zugrunde liegenden Assets sind. Damit schließt sich der Kreis zu Art. 21(2)(i): Personalsicherheit, Zugriffskontrolle und Management von Anlagen sind gerade bei Admin-Rechten untrennbar.

Wenn Sie an dieser Stelle nur eine Maßnahme priorisieren möchten, kombinieren Sie Admin-Konten immer mit MFA und strikter Überprüfung. Der fachliche Hintergrund dazu wird im Detail auch in unserem Beitrag zu NIS2 Maßnahme 10 MFA erläutert.

Schulungspflichten nach NIS2 Art. 20(2)

NIS2 Personalsicherheit endet nicht bei Screening und Berechtigungen. Art. 20(2) verlangt ausdrücklich, dass Mitglieder der Leitungsorgane Schulungen absolvieren und die Schulung der Mitarbeitenden fördern. Das ist für Maßnahme 9 entscheidend, weil Zugangskontrolle nur dann funktioniert, wenn Leitung, HR, Fachbereich und IT dieselben Regeln verstehen und durchsetzen.

Die Pflicht betrifft nicht nur die Geschäftsleitung im engeren Sinn, sondern mittelbar die gesamte Organisation. Mitarbeitende müssen wissen, warum Rechte knapp gehalten werden, weshalb Ausnahmen begrenzt sind, wann Vorfälle oder Auffälligkeiten gemeldet werden müssen und warum der Entzug von Rechten bei Rollenwechseln oder Austritten keine Schikane, sondern Sicherheitsgrundlage ist. Ohne dieses Verständnis werden Sicherheitsprozesse intern als Bremsfaktor behandelt und systematisch umgangen.

Eine belastbare Schulungsarchitektur für Maßnahme 9 sollte mindestens fünf Themen abdecken:

1. Sicherheitsverpflichtungen je Rolle und Umgang mit sensiblen Informationen.
2. Regeln für Zugangsdaten, MFA und die Nutzung privilegierter Konten.
3. Meldewege bei verdächtigen Zugriffsereignissen, Missbrauch oder Fehlfreigaben.
4. Verantwortlichkeiten bei Onboarding, Rollenwechsel und Offboarding.
5. Besondere Verantwortung der Leitung für Freigaben, Aufsicht und Nachweise.

Für die Geschäftsleitung ist die Perspektive dabei anders als für operative Nutzer. Dort geht es um Governance: Welche Risiken entstehen durch Überberechtigung? Wie werden Reviews kontrolliert? Welche Kennzahlen zeigen Reife oder Schwächen? Wo liegen Haftungs- und Aufsichtsrisiken, wenn privilegierte Zugänge unkontrolliert bleiben? Diese Managementsicht macht Art. 20(2) zu mehr als einer bloßen Schulungspflicht.

Für Fachbereiche und operative Rollen zählt dagegen die Prozessnähe. Schulung muss konkret beantworten, wie Berechtigungen beantragt, warum Rechte entzogen, wie Ausnahmen dokumentiert und wann Unregelmäßigkeiten eskaliert werden. Reine Theorie zu Normen hilft hier wenig. Wirksam sind kurze, wiederkehrende Formate mit klaren Beispielen aus dem Alltag, etwa zu Projektzugriffen, Vertreterregelungen, Austritten oder verdächtigen Administrator-Aktivitäten.

Die Nachweislogik sollte mindestens Zielgruppe, Datum, Inhalte, Version, Teilnahme und Abschlussstatus enthalten. Für Management-Schulungen sind zusätzlich Agenda, Teilnehmerkreis und Bezug zu Governance-Maßnahmen sinnvoll. Wenn Sie Personalsicherheit und NIS2-Schulung pragmatisch bündeln wollen, ist eine dokumentierbare NIS2 Schulung der sinnvolle nächste Schritt, weil sie Verantwortlichkeiten, Pflichten und Nachweise in ein einheitliches Format bringt.

Häufig gestellte Fragen (FAQ)

Was fordert NIS2 zur Personalsicherheit?

NIS2 fordert nach Art. 21(2)(i) Maßnahmen zur Personalsicherheit, zur Zugriffskontrolle und zum Management von Anlagen. Praktisch müssen Sie also sensible Rollen risikobasiert betrachten, Berechtigungen steuern, Assets aktuell inventarisieren, privilegierte Zugänge besonders absichern und Beschäftigte über ihre Sicherheitsverpflichtungen unterweisen.

Wie setze ich NIS2-Zugangskontrolle um?

Der pragmatische Startpunkt ist ein Rollen- und Rechtekonzept mit klaren Genehmigungswegen, MFA für kritische Zugänge und wiederkehrenden Reviews. Danach folgen Sonderprozesse für privilegierte Konten, technische Identitäten und zeitlich begrenzte Ausnahmen. Entscheidend ist nicht die perfekte Tool-Landschaft, sondern ein konsistenter, dokumentierter Prozess.

Brauche ich ein Asset-Management für NIS2?

Ja. Ohne Asset-Inventar wissen Sie weder, welche Systeme kritisch sind, noch welche Zugriffe besonders geschützt oder regelmäßig überprüft werden müssen. Asset-Management ist deshalb keine Nebenmaßnahme, sondern Voraussetzung für wirksame Zugangskontrolle und nachvollziehbare Priorisierung.

Welche ISO-27001-Kontrollen decken NIS2 Maßnahme 9 ab?

Für die grobe Einordnung passt die Zuordnung zu Annex A.7 Personalsicherheit, A.8 Asset Management und A.9 Zugriffskontrolle. In der aktuellen ISO-27001-Systematik lassen sich die Inhalte darüber hinaus auf Controls zu Screening, Verantwortlichkeiten, Informations- und Asset-Nutzung, Identitätsmanagement, Authentifizierungsinformationen und Zugriffsrechten abbilden.

Muss ich jeden Mitarbeiter sicherheitsüberprüfen?

Nein. Maßgeblich ist die Risikoorientierung. Systemadministratoren, Finanzfunktionen, HR-Leitung oder andere Rollen mit Zugriff auf kritische Informationen oder weitreichende Rechte erfordern regelmäßig mehr Sorgfalt als gering exponierte Tätigkeiten. Wichtig ist, dass Sie Ihre Entscheidung dokumentieren und begründen.

Wie oft müssen Berechtigungen rezertifiziert werden?

Für kritische Systeme und privilegierte Zugänge ist ein quartalsweiser Review ein guter Mindeststandard. Zusätzlich sollten Sie bei jedem Rollenwechsel, Projektende und Austritt prüfen, ob Rechte angepasst oder sofort entzogen werden müssen. Weniger kritische Kontexte können unter Umständen in längeren Zyklen geprüft werden, wenn das sauber begründet ist.

Fazit: Maßnahme 9 verbindet HR, IAM und Governance

NIS2 Maßnahme 9 ist keine Einzeldisziplin, sondern ein Zusammenspiel aus Personalsicherheit, Berechtigungsmanagement, Asset-Transparenz und Schulung. Unternehmen scheitern hier selten an fehlender Theorie, sondern an gebrochenen Übergaben zwischen HR, Fachbereichen, IT und Geschäftsleitung. Genau deshalb ist die beste Umsetzung selten die aufwendigste, sondern die mit klaren Rollen, eindeutigen Freigaben, sauberen Reviews und belastbaren Nachweisen.

Wenn Sie NIS2 Personalsicherheit, Zugriffskontrolle und Management-Verantwortung in ein dokumentierbares Schulungs- und Umsetzungsmodell überführen möchten, ist die NIS2 Schulung der passende nächste Schritt. Sie schaffen damit ein gemeinsames Verständnis für Fachbereiche, Administratoren und Leitungsebene und reduzieren gleichzeitig typische Schwachstellen bei Rechten, Offboarding und privilegierten Konten.