NIS2 angewandt: Was ein neues Benutzerkonto über Compliance im Betrieb zeigt
Ein neuer Mitarbeiter startet. HR meldet den Eintritt, der Fachbereich nennt Rolle und benötigte Systeme, die IT legt Konto, Gerät und Zugriffe an. Für viele Unternehmen ist das Routine. Aus NIS2-Sicht entsteht hier ein sicherheitsrelevanter Arbeitsstand.
NIS2 wird nicht erst im Audit oder Sicherheitsvorfall relevant. NIS2 wird im Tagesgeschäft sichtbar: dort, wo Zugriffe, Rollen, Geräte, Ausnahmen und Wiedervorlagen entstehen.
Viele Unternehmen haben bereits Prozesse, in denen sicherheitsrelevante Entscheidungen zu Rolle, Zugriff, MFA und Ausnahme täglich getroffen werden. Das Problem liegt oft nicht darin, dass diese Prozesse fehlen. Das Problem liegt darin, dass sie den entstehenden Arbeitsstand nicht sauber genug erzeugen.
Der Nachweis entsteht nicht erst kurz vor Audit oder Kundenfrage. Er entsteht im Prozess — oder er muss später mühsam rekonstruiert werden.
Ausgangspunkt
Die Benutzeranlage ist ein sicherheitsrelevanter Prozess
Die Benutzeranlage wirkt zunächst wie Verwaltung: Formular, IT-Ticket, Zugangsdaten. Tatsächlich entstehen dort mehrere sicherheitsrelevante Entscheidungen gleichzeitig: Wer darf auf welche Systeme zugreifen? Welche Rolle begründet diese Rechte? Welche Geräte werden ausgegeben? Ist MFA aktiv? Gibt es Sonderrechte? Wann werden Rechte wieder geprüft?
Jede Benutzeranlage erzeugt automatisch Entscheidungen zu Rolle, Zugriff, MFA und Fachsystemen — auch dann, wenn niemand sie ausdrücklich dokumentiert. Ein Benutzerkonto ist kein Sicherheitsvorfall. Ein unzureichend geführter Kontoanlage-Prozess kann später erklären, warum ein Sicherheitsvorfall möglich wurde.
Prüfpunkt
Bei NIS2 geht es nicht nur darum, ob eine Richtlinie existiert. Entscheidend ist, ob der Ablauf nachvollziehbar geführt wird — und ob die richtigen Daten dabei entstehen.
Acht Felder
IT-Onboarding Checkliste: acht NIS2-Prüfpunkte bei der Benutzeranlage
Ein Ticket „Bitte Nutzerkonto anlegen" erzeugt mehr als Zugangsdaten. Für NIS2-relevante Nachweisführung sind acht Prüfpunkte besonders wichtig: Gerät, Rolle, Konto, MFA, Fachsysteme, Awareness, Ausnahme und Wiedervorlage.
01
Gerät
Laptop, Smartphone, Zugangskarte, Token
Ist das Gerät im Asset-Register zugeordnet, geschützt und verschlüsselt?
02
Rolle
Funktion, Bereich, Standort, Kritikalität
Passt die Berechtigung zur tatsächlichen Aufgabe?
03
Konto
AD / Entra ID, lokale Konten, Fachsysteme, SaaS
Gibt es manuelle, doppelte oder verwaiste Konten?
04
MFA
Aktiv, offen, ausgenommen
Sind MFA-Ausnahmen genehmigt, begründet und befristet?
05
Fachsysteme
ERP, CRM, Fileshare, Reporting, OT-nahe Systeme
Hat der Nutzer nur Zugriff auf Systeme, die seine Rolle erfordert?
06
Awareness
Einweisung, Richtlinien, Meldewege, Nachweis
Wurde Sicherheit vor produktivem Zugriff vermittelt?
Die acht Felder sind keine zusätzliche Compliance-Schicht. Es sind Prozessdaten, die ohnehin entstehen sollten — nur häufig nicht sauber genug geführt werden.
Joiner · Mover · Leaver
Joiner, Mover, Leaver: Warum Rollenwechsel und Offboarding kritisch sind
Der Eintritt ist sichtbar und wird meistens organisiert. Die größeren Risiken entstehen häufig später: bei Rollenwechsel, Projektende, temporären Rechten, externen Nutzern und Austritt.
Mover — typische Risiken
Wechsel Produktion → Vertrieb, alte Produktionsrechte bleiben
Projektzugriff besteht nach Projektende weiter
Temporäre Adminrechte werden nicht zurückgebaut
Externe & Sonderfälle
Externer Nutzer bleibt im VPN aktiv
OT-naher Zugriff eingerichtet, nie erneut geprüft
Dienstleister-Konto nach Vertragsende offen
Leaver — typische Lücken
Konto im Hauptsystem deaktiviert, SaaS-Zugänge offen
Zugangskarte entzogen, Fachsystemzugriffe bleiben
Kein vollständiges Offboarding-Protokoll
Sicherheitsrelevant ist nicht nur die Benutzeranlage. Sicherheitsrelevant ist der gesamte Joiner-/Mover-/Leaver-Zyklus.
NIS2-Prüfpunkte
Wo §30, §32 und §38 beim Benutzerkonto andocken
§30 BSIG
Sicherheitsmaßnahmen im Alltag
Zugriff, Rollen, MFA, Geräteschutz, Awareness und Schutz kritischer Systeme — das sind keine abstrakten Anforderungen. Sie entstehen oder entstehen nicht bei jeder Benutzeranlage.
Sind Berechtigungen angemessen, abgesichert und nachvollziehbar freigegeben?
§32 BSIG
Nachvollziehbarkeit im Vorfall
Im Vorfall muss rekonstruiert werden können, welche Identität wann auf welches System zugreifen konnte. Diese Daten müssen vorher geführt worden sein — sie können nicht im Ereignisfall erst entstehen.
Kann das Unternehmen Benutzer, Rechte, Geräte und Systemzugriffe sauber erklären?
§38 BSIG
Geschäftsführung bei kritischen Ausnahmen einbinden
Nicht jede Benutzeranlage gehört zur Geschäftsführung. Aber privilegierte Rechte, fehlende MFA, externe Zugriffe auf kritische Systeme oder dauerhaft offene Ausnahmen brauchen klare Steuerung und nachweisbare Genehmigung.
Welche Ausnahmen sind wesentlich genug, um eskaliert, genehmigt und überwacht zu werden?
Wirksamkeit
Access Review / Berechtigungsreview — Rechte müssen passen, nicht nur vergeben sein
Rechte müssen nicht nur einmal korrekt vergeben werden. Sie müssen bei Rollenwechsel, Projektende und Austritt erneut bewertet werden. Ein regelmäßiger Access Review nach Least-Privilege-Prinzip ist der Mechanismus dafür. Identity & Access Management und das Rollenmodell entscheiden, wie belastbar dieser Nachweis ist.
Gibt es einen regelmäßigen Access Review für Rollenwechsel, Projektende und Austritt?
Prozess statt Parallelwelt
Der Nachweis ist das Ergebnis einer sauber geführten Arbeit
Nachweise sind wichtig. Aber sie dürfen nicht erst nachträglich zusammengesucht werden. Beim Benutzerkonto bedeutet das: Der Prozess erzeugt einen Arbeitsstand zu Rolle, Zugriff, MFA, Ausnahme, Owner und Review — wenn er so geführt wird, dass diese Informationen im Ablauf entstehen müssen.
Antrag liegt vor und ist nachvollziehbar
Rolle ist definiert und begründet
Freigabe durch Systemowner dokumentiert
Asset ist zugeordnet und im Register erfasst
MFA-Status ist sichtbar und Ausnahmen sind begründet
Schulung ist erfolgt und nachweisbar
Ausnahme ist befristet und hat einen Owner
Review-Datum ist gesetzt
Entzug beim Austritt ist nachvollziehbar protokolliert
Damit entsteht Nachweisfähigkeit nicht nachträglich. Der Prozess erzeugt einen Arbeitsstand, der später erklärt, freigegeben und überprüft werden kann.
Konsequenz
Wer diese Spuren im Prozess nicht erzeugt, muss sie später rekonstruieren. Genau dort wird Compliance teuer, langsam und unhandlich.
Regime-Blick
Ein Prozess kann mehrere Anforderungen bedienen
Nicht jedes Regime gilt für jedes Unternehmen. Aber derselbe Prozess kann je nach Branche, Technologie und Kundenanforderung mehrere regulatorische Perspektiven berühren — wenn er die richtigen Daten erzeugt.
Je nach Branche, Produkt, ICT-Kritikalität, KI-System, OT-Umgebung oder Kundenanforderung können weitere Perspektiven hinzukommen: DORA, CRA, AI Act oder BCM.
Die Regime unterscheiden sich in Sprache, Fristen und Nachweistiefe. Der Prozess bleibt derselbe. Deshalb sollte er die Daten so erzeugen, dass sie später für unterschiedliche Perspektiven nutzbar sind.
Kleine Schritte
Wie Unternehmen pragmatisch starten
Kein Großprojekt. Mit einem Prozess beginnen, der ohnehin läuft.
1
Joiner-/Mover-/Leaver-Prozess auswählen
HR, IT und Fachbereich sind ohnehin beteiligt. Der Prozess existiert bereits — er muss nur schärfer geführt werden.
2
Sicherheitsrelevante Entscheidungen markieren
Rolle, Systembedarf, Freigabe, MFA-Status, Ausnahme, Review-Termin, Offboarding — diese Punkte explizit machen.
3
Wenige Pflichtfelder ergänzen
Rolle/Profil, Systemowner-Freigabe, MFA-Status, Ausnahme ja/nein mit Ablaufdatum, Schulung erfolgt, Review-Datum — das reicht als Einstieg.
4
Mover und Leaver ernst nehmen
Rollenwechsel und Austritt brauchen eigene Trigger. Hier entstehen viele dauerhaft offene Rechte, die selten auffallen, bis ein Vorfall eintritt.
5
Monatlich zehn Fälle prüfen
5 neue Benutzer, 3 Rollenwechsel, 2 Austritte. Fragen: Sind alle Rechte erklärbar? Gibt es offene Ausnahmen? Wurde MFA aktiviert? Gibt es verwaiste Konten? Ist der Review terminiert?
Ziel
Nicht vollständige Compliance am ersten Tag. Ein Prozess, der jeden Monat belastbarere Compliance-Daten erzeugt.
Ausblick
IT-Compliance wird Teil der Prozessqualität
NIS2 ist für viele Unternehmen der aktuelle Anlass. Es wird aber nicht bei einmaliger Nachweiserstellung bleiben. Ein Blick in stärker regulierte Bereiche zeigt, dass die Erwartung an dokumentierte Steuerung, Nachvollziehbarkeit und laufende Kontrollfähigkeit eher zunimmt als abnimmt.
Compliance sollte deshalb nicht als vorübergehende Sonderaufgabe verstanden werden. Sie wird Teil der Prozessqualität — auf einer Ebene mit Kosten, Geschwindigkeit und Servicequalität. Unternehmen, die das frühzeitig in ihre Prozessgestaltung einbauen, erzeugen nicht nur bessere Arbeitsstände. Sie reagieren schneller auf Kundenfragen, Lieferantenanforderungen und neue Regime.
Compliance entsteht nicht zusätzlich neben dem Prozess. Der Prozess erzeugt einen Arbeitsstand: Rolle, Freigabe, Zugriff, MFA, Ausnahme, Review und Wiedervorlage.
Häufige Fragen
Weil mit der Benutzeranlage Zugriffe, Geräte, Rollen, MFA, Awareness, Ausnahmen und Wiedervorlagen entstehen. Diese Informationen können später für Risikomanagement, Vorfallanalyse, Audit oder Kundenanfragen relevant werden.
Nein. Die Geschäftsführung muss nicht jede Kontoanlage prüfen. Relevant wird eine Vorlage an die Geschäftsführung bei kritischen Ausnahmen, privilegierten Rechten, fehlender MFA, externen Zugriffen oder dauerhaft offenen Risiken.
Beim Rollenwechsel bleiben alte Rechte häufig bestehen. Dadurch entstehen über die Zeit überhöhte Berechtigungen, Projektreste, Fachsystemzugriffe oder lokale Konten, die nicht mehr zur aktuellen Aufgabe passen.
Antrag, Rolle, Freigabe, Asset-Zuordnung, MFA-Status, Schulungsnachweis, Ausnahmeentscheidung, Review-Termin und Entzug beim Austritt.
Ein Access Review ist die regelmäßige Prüfung, ob Benutzerrechte noch zur aktuellen Aufgabe passen. Besonders relevant sind Rollenwechsel, Projektende, externe Nutzer und Offboarding.
Mit einem bestehenden Prozess. Der Joiner-/Mover-/Leaver-Prozess eignet sich besonders, weil HR, IT und Fachbereich ohnehin beteiligt sind. Wenige zusätzliche Pflichtfelder und ein monatlicher Stichprobenreview reichen als Einstieg.
Beginnen Sie dort, wo bereits Entscheidungen getroffen werden: Benutzeranlage, Rollenwechsel, Ausnahme und Offboarding. Wer diesen Prozess sauber führt, hält Rolle, Freigabe, MFA, Ausnahme und Review später erklärbar.