Berechtigungskonzept erstellen: Rollen, Rechte und Genehmigungsworkflow

Warum du ein Berechtigungskonzept brauchst

In einem Unternehmen mit 80 Mitarbeitern hat der Geschäftsführer eines Tages eine unangenehme Entdeckung gemacht: Ein Werkstudent aus dem Marketing hatte vollen Zugriff auf die Finanzbuchhaltung im ERP-System. Nicht weil jemand das bewusst so eingerichtet hatte, sondern weil bei der Anlage seines Accounts einfach das Profil eines Kollegen kopiert wurde, der zufällig auch in der Buchhaltung arbeitete. Der Werkstudent hatte die Rechte nie genutzt, aber sie waren da. Drei Jahre lang.

Solche Situationen sind kein Einzelfall. Sie sind der Normalzustand in Unternehmen, die kein Berechtigungskonzept haben. Rechte werden vergeben, weil jemand sie anfordert. Sie werden kopiert, weil es schneller geht als sie neu zusammenzustellen. Und sie werden so gut wie nie entzogen, weil sich niemand zuständig fühlt.

Ein Berechtigungskonzept löst dieses Problem systematisch. Es definiert, wer auf welche Systeme, Anwendungen und Daten zugreifen darf, auf welcher Grundlage diese Entscheidung getroffen wird und wer sie genehmigt. Es ist kein technisches Dokument für die IT-Abteilung, sondern ein organisatorisches Steuerungsinstrument, das Verantwortlichkeiten klärt und Nachvollziehbarkeit schafft.

Regulatorische Anforderungen

Falls du dich fragst, ob ein Berechtigungskonzept wirklich nötig ist: Die Antwort hängt nicht nur von guter Praxis ab, sondern auch von handfesten regulatorischen Anforderungen.

ISO 27001 fordert in Annex A.5.15 bis A.5.18 eine systematische Zugriffskontrolle. Zugriff auf Informationen und informationsverarbeitende Einrichtungen muss eingeschränkt, formalisiert und regelmäßig überprüft werden.

NIS2 verlangt in Artikel 21 explizit Personalsicherheit und Zugriffskontrolle als eine der zehn Mindestmaßnahmen. Dazu gehört ein Zugriffskonzept nach dem Least-Privilege-Prinzip.

DSGVO Artikel 32 schreibt vor, dass technische und organisatorische Maßnahmen die Vertraulichkeit personenbezogener Daten sicherstellen müssen. Ein unkontrollierter Zugriff auf Personaldaten oder Kundendaten ist ein klarer Verstoß.

BSI-Grundschutz widmet dem Thema einen eigenen Baustein (ORP.4 Identitäts- und Berechtigungsmanagement) mit detaillierten Anforderungen an Vergabe, Dokumentation und Überprüfung von Zugriffsrechten.

Kurz gesagt: Egal welches Framework du nutzt, du kommst am Berechtigungskonzept nicht vorbei.

Das Least-Privilege-Prinzip als Fundament

Bevor du anfängst, Rollen zu definieren und Rechte zuzuordnen, brauchst du ein klares Leitprinzip. Das Least-Privilege-Prinzip (auch Prinzip der minimalen Rechtevergabe) ist dieses Fundament, und es lässt sich in einem Satz zusammenfassen: Jeder Mitarbeiter erhält genau die Berechtigungen, die er für seine aktuelle Aufgabe benötigt. Nicht mehr, nicht weniger.

Das klingt offensichtlich, wird in der Praxis aber erstaunlich selten konsequent umgesetzt. Die Gründe dafür sind menschlich nachvollziehbar: Wenn ein Mitarbeiter eine neue Berechtigung anfordert, ist der schnellste Weg, sie einfach zu gewähren. Den Aufwand zu prüfen, ob sie wirklich nötig ist, scheut man gern. Und wenn der Mitarbeiter die Aufgabe abschließt, denkt niemand daran, die Berechtigung wieder zu entziehen.

Das Ergebnis ist ein Phänomen, das in der Fachliteratur als Privilege Creep bezeichnet wird: Über die Zeit sammeln Mitarbeiter immer mehr Rechte an, ohne dass alte Rechte entfernt werden. Nach ein paar Jahren hat ein langjähriger Mitarbeiter, der verschiedene Abteilungen durchlaufen hat, Zugriff auf praktisch alles.

Warum Least Privilege so wichtig ist

Der Nutzen von Least Privilege geht weit über Compliance hinaus:

Schadensbegrenzung bei Kompromittierung. Wenn ein Account gehackt wird, kann der Angreifer nur auf das zugreifen, wozu der Account berechtigt ist. Bei einem Account mit minimalen Rechten ist der Schaden begrenzt. Bei einem Account mit Vollzugriff auf alle Systeme ist der Schaden potenziell katastrophal.

Reduziertes Risiko durch Insider. Nicht jede Bedrohung kommt von außen. Mitarbeiter, die Zugriff auf Daten haben, die sie nicht benötigen, stellen ein unnötiges Risiko dar. Das muss nicht böswillig sein; ein versehentliches Löschen oder eine unbedachte Weiterleitung reicht aus.

Nachvollziehbarkeit. Wenn jeder nur die Rechte hat, die zu seiner Rolle gehören, lässt sich bei einem Vorfall deutlich schneller eingrenzen, wer was getan haben könnte.

Vereinfachte Verwaltung. Paradoxerweise ist ein striktes Least-Privilege-Modell langfristig einfacher zu verwalten als ein gewachsenes System ohne Regeln. Wenn du klare Rollen hast, musst du bei einem neuen Mitarbeiter nicht jedes Recht einzeln zusammensuchen, sondern weist einfach die passende Rolle zu.

Rollenbasierte Zugriffskontrolle (RBAC) aufbauen

Die praktische Umsetzung von Least Privilege erfolgt über ein rollenbasiertes Zugriffskontrollmodell, kurz RBAC (Role-Based Access Control). Das Prinzip: Berechtigungen werden nicht einzelnen Personen zugewiesen, sondern Rollen. Mitarbeiter erhalten Rollen, und über die Rolle erhalten sie automatisch die zugehörigen Berechtigungen.

Rollen von Funktionen ableiten

Der erste Schritt ist die Identifikation der Rollen in deinem Unternehmen. Rollen leiten sich nicht aus dem Organigramm ab, sondern aus den tatsächlichen Funktionen und Aufgaben, die Mitarbeiter ausüben.

Nimm als Beispiel ein mittelständisches Unternehmen mit 100 Mitarbeitern. Dort gibt es vielleicht folgende Funktionsbereiche: Geschäftsführung, Vertrieb, Einkauf, Buchhaltung, Personalwesen, Produktion, Qualitätssicherung, IT-Administration, Marketing und Support. Das ergibt schon einmal zehn Basisrollen.

Aber eine Rolle ist oft nicht genug. Innerhalb des Vertriebs gibt es vielleicht den Innendienst, der Angebote erstellt und Aufträge anlegt, und den Außendienst, der nur Kundendaten einsehen, aber keine Preise ändern darf. Das sind zwei verschiedene Rollen, obwohl beide im Vertrieb arbeiten.

Ein bewährter Ansatz: Arbeite mit zwei Ebenen von Rollen.

Basisrollen bilden die Grundberechtigungen ab, die jeder Mitarbeiter einer Abteilung braucht. Zugang zum Intranet, E-Mail, gemeinsame Laufwerke der Abteilung, relevante Standardanwendungen.

Funktionsrollen ergänzen spezifische Berechtigungen für bestimmte Aufgaben. Der Vertriebsmitarbeiter mit Preisänderungsrecht, der Buchhalter mit Zugang zum Zahlungsverkehr, der Teamleiter mit Einsicht in die Zeiterfassung seiner Mitarbeiter.

Rollen dokumentieren

Jede Rolle braucht eine saubere Dokumentation. Ohne diese Dokumentation weißt du in sechs Monaten nicht mehr, warum eine Rolle bestimmte Rechte enthält, und der Auditor wird genau danach fragen. Mit ISMS Lite findest du die passenden Controls für Zugriffskontrolle und Identitätsmanagement und generierst daraus per KI eine dokumentierte Berechtigungsrichtlinie — inklusive Versionierung und Freigabe-Workflow.

Eine Rollendokumentation sollte mindestens folgende Informationen enthalten:

Die Rollenmatrix

Ein zentrales Dokument in jedem Berechtigungskonzept ist die Rollenmatrix. Sie zeigt auf einen Blick, welche Rolle auf welches System mit welchem Berechtigungslevel zugreifen darf.

R = Lesen, RW = Lesen/Schreiben, Admin = Vollzugriff, - = kein Zugriff

Diese Matrix ist das Herzstück deines Berechtigungskonzepts. Sie macht auf einen Blick sichtbar, wo Zugriff besteht und wo nicht. Und sie macht sofort sichtbar, wenn etwas nicht stimmt: Warum hat die Buchhaltung Schreibzugriff auf die Produktionssteuerung? Das kann kein gewollter Zustand sein.

Vermeidung typischer Fehler bei der Rollenmodellierung

Zu viele Rollen. Wenn du für jeden Mitarbeiter eine eigene Rolle anlegst, hast du kein RBAC, sondern individuelle Rechtevergabe mit Extra-Schritten. Ziel sind 15 bis 30 Rollen für ein Unternehmen mit 100 Mitarbeitern, nicht 100.

Zu wenige Rollen. Eine einzige Rolle "Mitarbeiter" mit Zugriff auf alles ist kein Berechtigungskonzept. Die Rollen müssen fein genug sein, um tatsächlich unterschiedliche Berechtigungsprofile abzubilden.

Rollen nach Personen benennen. "Max-Müller-Rolle" ist keine Rolle, sondern ein Workaround. Rollen beschreiben Funktionen, nicht Personen.

Keine Trennung von Pflichten (Segregation of Duties). Bestimmte Kombinationen von Rechten sind kritisch. Der Mitarbeiter, der Rechnungen anlegt, sollte nicht gleichzeitig Zahlungen freigeben können. Die Rollenmatrix muss solche Konflikte erkennbar machen und verhindern.

Berechtigungsprofile definieren

Berechtigungsprofile sind die Verbindung zwischen der abstrakten Rollendefinition und der technischen Umsetzung im jeweiligen System. Während die Rolle beschreibt, was ein Mitarbeiter funktional tun darf, definiert das Berechtigungsprofil, wie das in jedem einzelnen System umgesetzt wird.

Vom Profil zur technischen Umsetzung

Nehmen wir die Rolle "Buchhaltung-Sachbearbeiter" als Beispiel. Diese Rolle braucht Zugriff auf drei Systeme: das ERP, das DMS und die Banking-Software.

ERP-System (SAP Business One):

• Modul Finanzbuchhaltung: Buchungen erfassen, Konten einsehen, Mahnlauf starten
• Modul Controlling: Nur Lesezugriff auf Kostenstellenberichte
• Modul Einkauf: Kein Zugriff
• Modul Vertrieb: Kein Zugriff

Dokumentenmanagementsystem:

• Ordner "Buchhaltung": Lesen und Schreiben
• Ordner "Verträge": Nur Lesen
• Ordner "Personal": Kein Zugriff
• Ordner "Allgemein": Lesen

Banking-Software:

• Kontostand einsehen: Ja
• Überweisungen vorbereiten: Ja
• Überweisungen freigeben: Nein (nur Abteilungsleitung)

Dieses Detailniveau ist notwendig, weil die IT-Abteilung bei der technischen Umsetzung genau wissen muss, welche Berechtigungen in welchem System konfiguriert werden sollen. Eine Angabe wie "Zugriff auf das ERP" ist zu vage; sie führt unweigerlich dazu, dass zu viele Rechte vergeben werden.

Privilegierte Accounts gesondert behandeln

Administratoren-Accounts verdienen besondere Aufmerksamkeit. Ein IT-Administrator, der Domain-Admin-Rechte hat, kann im schlimmsten Fall das gesamte Netzwerk kompromittieren. Privileged Access Management adressiert genau dieses Risiko. Für privilegierte Accounts gelten deshalb strengere Regeln:

Separate Accounts. Jeder Administrator hat einen normalen Benutzeraccount für die tägliche Arbeit (E-Mail, Intranet, Dokumentenablage) und einen separaten Admin-Account für administrative Tätigkeiten. Die Admin-Accounts werden nur dann verwendet, wenn administrative Aufgaben anstehen.

Vier-Augen-Prinzip bei kritischen Aktionen. Änderungen an der Firewall-Konfiguration, das Anlegen neuer Admin-Accounts oder Änderungen an Sicherheitsrichtlinien sollten von einer zweiten Person bestätigt werden.

Protokollierung. Alle Aktivitäten privilegierter Accounts werden lückenlos protokolliert. Im Idealfall werden die Logs an ein zentrales System gesendet, auf das die Administratoren selbst keinen Schreibzugriff haben.

Zeitlich begrenzte Rechte. Für bestimmte administrative Aufgaben (etwa Wartungsarbeiten an einem Server) werden temporäre Berechtigungen vergeben, die nach einem definierten Zeitfenster automatisch ablaufen.

Der Genehmigungsworkflow

Eine der wichtigsten Fragen im Berechtigungskonzept lautet: Wer darf Berechtigungen vergeben? Wenn die Antwort "jeder, der eine E-Mail an die IT schickt" lautet, hast du ein Problem. Ein definierter Genehmigungsworkflow stellt sicher, dass Berechtigungen bewusst und nachvollziehbar vergeben werden.

Rollen im Genehmigungsprozess

Antragsteller. Der Mitarbeiter selbst oder sein Vorgesetzter stellt den Antrag auf eine Berechtigung. Der Antrag muss mindestens enthalten: Welches System, welche Berechtigung, welcher Grund.

Fachlicher Genehmiger. Der fachlich Verantwortliche für das betreffende System oder den betreffenden Datenbestand genehmigt oder lehnt den Antrag ab. Das ist nicht die IT, sondern die Fachabteilung. Wer besser als der Leiter der Buchhaltung kann beurteilen, ob ein Mitarbeiter Zugriff auf die Finanzdaten braucht?

IT-Umsetzer. Nach der fachlichen Genehmigung setzt die IT-Abteilung die Berechtigung technisch um. Die IT prüft dabei, ob die angeforderte Berechtigung technisch möglich ist und ob sie im Einklang mit den definierten Rollen steht.

Informationssicherheitsbeauftragter (bei kritischen Systemen). Für Zugriff auf besonders schützenswerte Systeme oder Daten kann eine zusätzliche Genehmigung durch den ISB erforderlich sein. Das betrifft etwa Admin-Rechte, Zugriff auf Personaldaten oder Zugang zu Produktionssteuerungssystemen.

Der Workflow im Detail

Ein sauberer Genehmigungsworkflow durchläuft folgende Schritte:

Schritt 1: Antragstellung. Der Antragsteller füllt ein standardisiertes Formular aus. Darin steht: Welches System, welche Berechtigung, ab wann, befristet oder unbefristet, Begründung. Wichtig ist die Begründung. "Brauche ich für meine Arbeit" reicht nicht. "Bearbeite ab sofort die Debitorenbuchhaltung und brauche dafür Zugriff auf das ERP-Modul Finanzbuchhaltung" ist eine brauchbare Begründung.

Schritt 2: Fachliche Genehmigung. Der zuständige fachliche Genehmiger prüft den Antrag. Braucht der Mitarbeiter diese Berechtigung wirklich? Gibt es eine bestehende Rolle, die passt? Oder ist eine individuelle Berechtigung nötig? Der Genehmiger bestätigt oder lehnt ab. Bei Ablehnung bekommt der Antragsteller eine Begründung.

Schritt 3: Prüfung auf Konflikte. Vor der Umsetzung wird geprüft, ob die neue Berechtigung zu Konflikten führt. Entstehen durch die Kombination mit bestehenden Rechten kritische Berechtigungskombinationen? Verletzt die neue Berechtigung das Prinzip der Funktionstrennung?

Schritt 4: Technische Umsetzung. Die IT setzt die Berechtigung im System um und dokumentiert die Änderung.

Schritt 5: Bestätigung. Der Antragsteller und der Genehmiger werden über die Umsetzung informiert. Der Antragsteller bestätigt, dass die Berechtigung funktioniert.

Wer genehmigt was?

Damit der Genehmigungsworkflow funktioniert, muss für jedes System klar definiert sein, wer der fachliche Genehmiger ist. Das klingt trivial, ist aber ein Punkt, an dem viele Unternehmen scheitern, weil diese Zuordnung nie explizit getroffen wurde.

Die Eskalationsstufe greift, wenn der reguläre Genehmiger nicht verfügbar ist oder wenn es Uneinigkeit gibt.

Sonderfälle im Genehmigungsprozess

Notfallzugriff. Manchmal braucht jemand dringend Zugang zu einem System, und der Genehmiger ist im Urlaub. Für diesen Fall brauchst du einen Notfallprozess: Ein definierter Vertreter kann temporären Zugriff gewähren. Die reguläre Genehmigung wird nachgeholt. Der Notfallzugriff wird besonders dokumentiert und ist standardmäßig auf 48 Stunden befristet.

Temporäre Berechtigungen. Für Projekte, Vertretungen oder befristete Aufgaben sollten Berechtigungen grundsätzlich mit einem Ablaufdatum versehen werden. Nichts ist beständiger als ein Provisorium, und temporäre Berechtigungen, die nie ablaufen, sind eine der häufigsten Ursachen für Privilege Creep.

Externe Dienstleister. Für externe Berater, Auditoren oder IT-Dienstleister gelten verschärfte Regeln: Berechtigungen sind immer befristet, der Zugriff wird protokolliert, und nach Abschluss der Tätigkeit werden die Accounts sofort deaktiviert. Die zugehörigen Geheimhaltungsvereinbarungen sollten vor der Rechtevergabe abgeschlossen sein.

Regelmäßige Rezertifizierung

Ein Berechtigungskonzept ist kein Dokument, das du einmal erstellst und dann in die Schublade legst. Ohne regelmäßige Überprüfung veraltet es innerhalb weniger Monate, weil sich Zuständigkeiten ändern, Mitarbeiter die Abteilung wechseln oder neue Systeme eingeführt werden.

Rezertifizierung bedeutet: In definierten Abständen überprüfst du systematisch, ob die vergebenen Berechtigungen noch gerechtfertigt sind. Jeder fachliche Genehmiger bestätigt (oder widerruft) die Berechtigungen in seinem Verantwortungsbereich.

Rezertifizierungszyklus

So läuft eine Rezertifizierung ab

Vorbereitung. Die IT erstellt für jeden fachlichen Genehmiger eine Liste aller Berechtigungen in seinem Verantwortungsbereich. Für jede Berechtigung wird angezeigt: Welcher Mitarbeiter, welche Rolle, welche konkreten Rechte, seit wann.

Überprüfung. Der fachliche Genehmiger geht die Liste durch und entscheidet für jede Berechtigung: Bestätigen (Mitarbeiter braucht die Berechtigung weiterhin) oder Entziehen (Berechtigung ist nicht mehr erforderlich). Bei der Überprüfung sollten folgende Fragen beantwortet werden: Ist der Mitarbeiter noch in der Funktion, für die die Berechtigung vergeben wurde? Hat er die Berechtigung in den letzten Monaten tatsächlich genutzt? Gibt es eine Rolle, die besser passt?

Umsetzung. Die IT entzieht alle Berechtigungen, die nicht bestätigt wurden. Dieser Schritt darf nicht optional sein. Wenn ein Genehmiger eine Berechtigung nicht aktiv bestätigt, wird sie entzogen. Das Prinzip heißt: Im Zweifel entziehen, nicht im Zweifel behalten.

Dokumentation. Die Ergebnisse der Rezertifizierung werden dokumentiert: Wer hat wann welche Berechtigungen überprüft, welche wurden bestätigt, welche entzogen?

Was die Rezertifizierung regelmäßig aufdeckt

Aus der Praxis zeigt sich, dass bei der ersten Rezertifizierung oft 15 bis 25 Prozent aller Berechtigungen als nicht mehr erforderlich identifiziert werden. Typische Funde:

• Mitarbeiter, die die Abteilung gewechselt haben, aber noch die Rechte der alten Abteilung besitzen
• Accounts von ehemaligen Mitarbeitern, die noch aktiv sind (besonders bei Freelancern und externen Beratern)
• Testaccounts aus Projektphasen, die nie deaktiviert wurden
• Einzelberechtigungen, die für ein längst abgeschlossenes Projekt vergeben wurden
• Mitarbeiter, die Rechte haben, von denen sie selbst nicht wissen

Dokumentation für den Auditor

Bei einem ISO-27001-Audit oder einer NIS2-Prüfung wird der Auditor nicht in dein Active Directory schauen und die technische Konfiguration prüfen. Der Auditor prüft, ob du ein dokumentiertes, nachvollziehbares Berechtigungskonzept hast und ob du es auch lebst.

Welche Dokumente du brauchst

Das Berechtigungskonzept selbst. Ein übergreifendes Dokument, das die Grundsätze beschreibt: Least-Privilege-Prinzip, RBAC-Ansatz, Genehmigungsworkflow, Rezertifizierungszyklus. Dieses Dokument beantwortet die Frage: Wie geht ihr grundsätzlich mit Berechtigungen um?

Die Rollenmatrix. Die tabellarische Übersicht aller Rollen und ihrer Berechtigungen pro System. Der Auditor will sehen, dass es definierte Standardrollen gibt und nicht jeder Mitarbeiter individuelle Rechte hat.

Berechtigungsanträge. Nachweise, dass Berechtigungen über einen definierten Prozess beantragt und genehmigt werden. Das kann ein Ticket-System sein, ein Formular in SharePoint oder eine E-Mail-Kette mit dokumentierter Genehmigung. Entscheidend ist, dass der Antrag, die Genehmigung und die Umsetzung nachvollziehbar sind.

Rezertifizierungsprotokolle. Nachweise, dass die vergebenen Berechtigungen regelmäßig überprüft werden. Datum, Prüfer, Ergebnis, umgesetzte Änderungen.

Änderungshistorie. Wenn sich am Berechtigungskonzept oder an den Rollen etwas ändert, muss das dokumentiert sein: Was wurde wann von wem geändert und warum?

Typische Auditorfragen und wie du sie beantwortest

Praxisbeispiel: Berechtigungskonzept für einen Maschinenbauer

Zum Abschluss ein durchgängiges Beispiel, das zeigt, wie ein Berechtigungskonzept in der Praxis aussehen kann. Das Beispielunternehmen: Ein Maschinenbauer mit 95 Mitarbeitern, einem ERP-System (SAP Business One), einem DMS, einer Produktionssteuerung, einer CRM-Lösung und einem Standard-Office-Umfeld mit Active Directory.

Schritt 1: Rollen identifizieren

Auf Basis der Organisationsstruktur und der tatsächlichen Aufgaben werden folgende Rollen definiert:

14 Rollen für 95 Mitarbeiter. Das ist ein gutes Verhältnis. Die Teamleitungs-Rolle ist als Zusatzrolle konzipiert, die zur Basisrolle der jeweiligen Abteilung hinzukommt.

Schritt 2: Kritische Berechtigungskombinationen identifizieren

Bevor die Rechte zugewiesen werden, definiert das Unternehmen, welche Rollenkombinationen verboten sind:

Schritt 3: Genehmiger festlegen und Rezertifizierung planen

Das Unternehmen definiert für jedes System den fachlichen Genehmiger und den Rezertifizierungszyklus. Alle Berechtigungsanträge werden über das bestehende Ticket-System abgewickelt, wobei der Workflow eine verpflichtende Genehmigung durch den fachlichen Verantwortlichen enthält.

Die erste vollständige Rezertifizierung wird für sechs Monate nach Einführung des Konzepts geplant, danach jährlich. Admin-Accounts werden alle drei Monate überprüft.

Schritt 4: Bestehendes aufräumen

Bei der Einführung des Berechtigungskonzepts wird ein einmaliger Abgleich durchgeführt: Welche Ist-Berechtigungen existieren, und stimmen sie mit den Soll-Berechtigungen aus der Rollenmatrix überein?

In unserem Beispiel ergab dieser Abgleich: 23 Mitarbeiter hatten Berechtigungen, die über ihre Rolle hinausgingen. 4 Accounts von ehemaligen Mitarbeitern waren noch aktiv. 7 Testaccounts aus einer ERP-Einführung vor zwei Jahren existierten noch. 12 Mitarbeiter hatten Zugriff auf Netzlaufwerke anderer Abteilungen ohne erkennbare Notwendigkeit.

All das wurde in der Einführungsphase bereinigt. Der Aufwand: etwa drei Wochen für IT und Fachabteilungen gemeinsam. Kein übermäßiger Aufwand, aber ein erheblicher Sicherheitsgewinn.

Von der Theorie zur Umsetzung

Ein Berechtigungskonzept aufzubauen ist kein Mammutprojekt, das Monate dauert und externe Berater erfordert. Für ein Unternehmen mit 100 Mitarbeitern ist folgende Zeitplanung realistisch:

Insgesamt also etwa acht Wochen, wenn du nebenbei noch deinen regulären Job machst. Die technische Umsetzung in den einzelnen Systemen (Active Directory, ERP, DMS) kommt noch dazu, hängt aber stark von den konkreten Systemen ab und kann parallel zur konzeptionellen Arbeit laufen.

Das Ergebnis: Du weißt, wer auf welche Systeme zugreifen darf und warum. Du hast einen Prozess, der verhindert, dass unkontrolliert Rechte vergeben werden. Du überprüfst regelmäßig, ob die Berechtigungen noch stimmen. Und wenn der Auditor kommt, legst du ihm eine Rollenmatrix, den Genehmigungsworkflow und die Rezertifizierungsprotokolle auf den Tisch.

Weiterführende Artikel

• User Lifecycle: Eintritt, Austritt und Rollenwechsel sauber abbilden
• Zugangs- und Zutrittskontrollrichtlinie: Physisch und logisch
• Die wichtigsten ISMS-Rollen: ISB, CISO, Risikoeigner – wer macht was?
• Passwort-Richtlinie erstellen: Anforderungen, Beispiel und Durchsetzung
• IT-Asset-Management für das ISMS: Inventar, Kritikalität und Klassifizierung

Das ist kein bürokratischer Overhead. Das ist professionelles Berechtigungsmanagement, und es schützt dein Unternehmen vor Risiken, die du ohne dieses Konzept nicht einmal sehen würdest.