Berechtigungskonzept: Wie Sie Zugriffsrechte nachweisbar regeln – mit Vorlage und Muster

Was ist ein Berechtigungskonzept?

Ein Berechtigungskonzept ist ein dokumentiertes, verbindliches Regelwerk, das festlegt, welche Personen, Rollen oder technischen Identitäten auf welche IT-Systeme, Anwendungen und Daten zugreifen dürfen, in welchem Umfang (lesen, ändern, löschen, freigeben) und unter welchen Bedingungen. Es beschreibt zudem die Prozesse, über die Zugriffsrechte beantragt, genehmigt, vergeben, geändert, entzogen und regelmäßig überprüft werden.

Kurz gesagt: Das Berechtigungskonzept beantwortet vier Fragen – Wer darf was, wo, und warum? Die vierte Frage ist die entscheidende. Ein Zugriffsrecht ohne dokumentierte fachliche Begründung ist im Audit wertlos, selbst wenn es technisch korrekt vergeben wurde.

Im Unternehmensalltag umfasst ein Berechtigungskonzept typischerweise drei Ebenen:

• Die Regelebene: Grundsätze wie das Need-to-know-Prinzip, Least Privilege und Funktionstrennung, Verantwortlichkeiten und Freigabewege.

• Die Strukturebene: das Rollenmodell, also die Bündelung von Einzelrechten zu fachlichen Rollen, sowie die Berechtigungsmatrix, die Rollen und Systeme gegenüberstellt.

• Die Prozessebene: der Lebenszyklus jeder Berechtigung von der Beantragung über die Vergabe bis zum Entzug – eng verzahnt mit dem Joiner-Mover-Leaver-Prozess der Personalabteilung.

Abgrenzung: Berechtigungskonzept, Rollenkonzept, Berechtigungsmatrix und Berechtigungsmanagement

In Projekten werden diese Begriffe oft synonym verwendet. Das führt zu Missverständnissen zwischen IT, Fachbereich und Revision. Die folgende Übersicht schafft Klarheit:

Das Berechtigungskonzept ist also das Was und Warum, das Berechtigungsmanagement das Wie im Alltag, und Identity and Access Management das Womit. Eine ausführliche Einordnung von Identity Management, IAM, IGA und PAM finden Sie in unserem Beitrag Identity Management: Definition, Abgrenzung und Best Practices.

Die fünf Grundprinzipien jedes Berechtigungskonzepts

Unabhängig von Branche und Unternehmensgröße stützt sich ein belastbares Berechtigungskonzept auf fünf Prinzipien. Sie stammen aus der Informationssicherheit und finden sich nahezu wortgleich in Normen und Aufsichtsrecht wieder.

1. Need-to-know-Prinzip

Jede Person erhält nur Zugriff auf die Informationen, die sie für ihre konkrete Aufgabe kennen muss. Das Need-to-know-Prinzip bezieht sich primär auf Informationen und Daten. Eine Mitarbeiterin der Lohnbuchhaltung muss Gehaltsdaten sehen, eine Mitarbeiterin des Vertriebs nicht.

2. Least Privilege (Prinzip der minimalen Rechte)

Jede Identität erhält nur die minimal notwendigen Rechte, um ihre Funktion auszuführen. Das US-amerikanische NIST definiert Least Privilege als Prinzip, nach dem jede Entität nur die minimalen Systemressourcen und Autorisierungen erhält, die sie für ihre Funktion benötigt. Formuliert wurde das Prinzip bereits 1975 von Jerome Saltzer und Michael Schroeder in ihrem Grundlagenpapier zur Informationssicherheit.

Während Need-to-know das Was begrenzt, begrenzt Least Privilege das Wie viel: Leserechte statt Schreibrechte, zeitlich befristete Adminrechte statt dauerhafter.

3. Funktionstrennung (Segregation of Duties, SoD)

Kritische Tätigkeiten werden auf mehrere Personen verteilt, damit niemand allein einen Vorgang von Anfang bis Ende kontrolliert. Klassisches Beispiel: Wer einen Kreditor anlegt, darf keine Zahlung an diesen Kreditor freigeben. Die Funktionstrennung ist in der ISO/IEC 27001:2022 als eigenes Control (Anhang A 5.3) verankert.

4. Vier-Augen-Prinzip und Freigabeprozesse

Kritische Berechtigungen – etwa Administratorrechte oder Zugriff auf besonders schützenswerte personenbezogene Daten – werden nur nach Freigabe durch eine zweite, fachlich zuständige Person vergeben.

5. Nachvollziehbarkeit und Rechenschaft

Jede Vergabe, Änderung und jeder Entzug ist dokumentiert: wer, wann, auf wessen Antrag, mit welcher Begründung. Die DSGVO bezeichnet dies als Rechenschaftspflicht. Ohne diesen Nachweis ist das beste Berechtigungskonzept im Audit nicht verteidigbar.

Merksatz für das Management: Need-to-know regelt, was jemand sehen darf. Least Privilege regelt, wie viel jemand damit tun darf. Funktionstrennung regelt, was niemand allein tun darf.

Warum ist ein Berechtigungskonzept relevant? Fünf Kennzahlen, die jeder CISO kennen sollte

Die Diskussion über Zugriffsrechte wird häufig als Compliance-Pflicht geführt. Die Zahlen zeigen, dass es sich um ein handfestes Geschäftsrisiko handelt.

62 % aller Datenschutzverletzungen haben eine menschliche Komponente.
Der Verizon Data Breach Investigations Report 2026 analysiert mehr als 22.000 bestätigte Datenschutzverletzungen aus 145 Ländern. Der Faktor Mensch – Fehlbedienung, Social Engineering, Missbrauch von Zugangsdaten – war an 62 % der Fälle beteiligt, nach 60 % im Vorjahr. Missbrauchte Zugangsdaten waren in 13 % der Fälle der initiale Einstiegspunkt. Jedes überflüssige Recht vergrößert den Schaden, den ein kompromittiertes Konto anrichten kann.

4,25 Mio. Euro kostet ein Datenleck ein deutsches Unternehmen im Durchschnitt.
Das zeigt der IBM Cost of a Data Breach Report 2026. Im Vorjahr lag der Wert bei 3,87 Mio. Euro. Weltweit stiegen die durchschnittlichen Kosten auf rund 4,99 Mio. US-Dollar.

Nur 1 % der vergebenen Berechtigungen wird tatsächlich genutzt.
Microsoft hat für den 2023 State of Cloud Permissions Risks Report Berechtigungen in Multi-Cloud-Umgebungen ausgewertet. Ergebnis: Identitäten nutzen nur rund 1 % der ihnen eingeräumten Rechte; die Hälfte aller Identitäten verfügte über sogenannte Super-Identity-Rechte mit Zugriff auf alle Ressourcen. Die Zahl bezieht sich auf Cloud-Infrastrukturen, illustriert aber ein Muster, das CISOs aus On-Premises-Landschaften kennen: Rechte werden großzügig vergeben und selten entzogen.

Innentäter sind ein relevanter Teil des Täterkreises.
Die Bitkom-Studie Wirtschaftsschutz 2026 beziffert den Gesamtschaden für die deutsche Wirtschaft auf mindestens 211 Mrd. Euro pro Jahr (Korridor bis 270,8 Mrd. Euro). Unter den betroffenen Unternehmen nennen 23 % unabsichtlich handelnde und 19 % vorsätzlich handelnde aktuelle oder ehemalige Mitarbeitende als Verursacher. Ehemalige Mitarbeitende mit noch aktiven Konten sind exakt das Szenario, das ein funktionierendes Leaver-Verfahren verhindert.

92 % der Organisationen mit KI-bezogenen Sicherheitsvorfällen fehlten angemessene KI-Zugriffskontrollen.
Auch das ist ein Ergebnis des IBM-Reports 2026. Mit KI-Assistenten und Agenten entstehen neue, nicht-menschliche Identitäten, die auf Unternehmensdaten zugreifen. Ein Berechtigungskonzept, das nur Menschen kennt, ist 2026 unvollständig.

Regulatorischer Druck: Was DSGVO, NIS2, DORA und ISO 27001 verlangen

Neben dem wirtschaftlichen Risiko steigt der regulatorische Druck. Die folgende Übersicht zeigt, welche Anforderungen an ein Berechtigungskonzept sich aus den wichtigsten Regelwerken für Unternehmen in der DACH-Region ergeben:

Hinweis: Diese Übersicht dient der Orientierung und ersetzt keine Rechtsberatung. Welche Regelwerke für Ihr Unternehmen gelten, hängt von Sektor, Größe und Tätigkeit ab.

Bemerkenswert ist die Präzision, mit der DORA die Anforderungen formuliert. Die delegierte Verordnung zum IKT-Risikomanagement verlangt ausdrücklich, Zugriffsrechte nach den Prinzipien „need-to-know, need-to-use and least privilege” zu vergeben, generische und geteilte Benutzerkonten so weit wie möglich zu vermeiden und Rechte für IKT-Systeme, die kritische oder wichtige Funktionen unterstützen, mindestens alle sechs Monate zu überprüfen. Für Banken und Versicherer ist das Berechtigungskonzept damit kein Best-Practice-Thema mehr, sondern eine prüfbare Pflicht mit festem Takt.

Einen Überblick, wie diese Regelwerke strategisch zusammenspielen, bietet unser Leitfaden Die komplexe EU-Regulierungslandschaft meistern.

Was gehört in ein Berechtigungskonzept? Die Vorlage für Ihre Gliederung

Ein Berechtigungskonzept muss nicht hundert Seiten umfassen. Es muss aber vollständig sein. Die folgende Berechtigungskonzept-Vorlage zeigt die Gliederung, die sich in der Praxis bewährt hat und die Prüferinnen und Prüfer erwarten.

Berechtigungskonzept Vorlage – empfohlene Gliederung:

1. Zweck, Geltungsbereich und Ziele – Welche Organisationseinheiten, Standorte, Systeme und Identitätstypen (Mitarbeitende, Externe, Service-Accounts, KI-Agenten) sind erfasst?

2. Rechtliche und regulatorische Grundlagen – DSGVO, NIS2 bzw. nationale Umsetzung, DORA, branchenspezifische Vorgaben, interne Richtlinien.

3. Begriffe und Grundprinzipien – Need-to-know-Prinzip, Least Privilege, Funktionstrennung, Vier-Augen-Prinzip, Rechenschaftspflicht.

4. Rollen und Verantwortlichkeiten – Konzeptverantwortung (meist CISO), System- und Datenverantwortliche (Owner), Führungskräfte als Antragsteller und Rezertifizierer, IT als Umsetzer, Revision als Prüfer.

5. Identitätstypen und Kontenarten – persönliche Konten, privilegierte Konten, Notfallkonten, technische und nicht-menschliche Identitäten, externe Identitäten.

6. Rollenmodell – Systematik der Rollen (Basisrollen, Funktionsrollen, Projektrollen, Sonderrollen), Benennungskonventionen, Rollenbeschreibungen.

7. Berechtigungsmatrix – Zuordnung von Rollen zu Systemen, Datenobjekten und Rechtestufen.

8. Funktionstrennungsregeln (SoD-Matrix) – unvereinbare Rollen- und Rechtekombinationen.

9. Prozesse im Berechtigungslebenszyklus – Beantragung, Genehmigung, Vergabe, Änderung, befristete Rechte, Entzug; Verzahnung mit dem Joiner-Mover-Leaver-Prozess.

10. Privilegierte Zugriffe und Notfallzugriffe – Vergabe, Befristung, Protokollierung, „Break-Glass”-Verfahren.

11. Rezertifizierung und Kontrollen – Turnus, Verantwortliche, Umgang mit Abweichungen, Kennzahlen.

12. Protokollierung, Nachweis und Archivierung – Was wird wie lange aufbewahrt? Wie werden historische Berechtigungsstände rekonstruiert?

13. Ausnahmen und Eskalation – Wer darf Ausnahmen genehmigen, wie lange gelten sie, wie werden sie dokumentiert?

14. Pflege und Versionierung des Konzepts – Review-Zyklus, Änderungsverfahren, Freigabe durch Geschäftsleitung.

Die Gliederung macht eines deutlich: Rund die Hälfte der Kapitel betrifft nicht die IT-Technik, sondern Organisation, Verantwortung und Prozesse. Genau hier entscheidet sich, ob ein Berechtigungskonzept lebt oder im Dokumentenmanagementsystem verstaubt.

Die vier Wurzelursachen, an denen Berechtigungskonzepte scheitern

Kommt Ihnen dieser Satz bekannt vor? „Ein Berechtigungskonzept haben wir. Es stimmt nur nicht mehr.” Das Dokument existiert, die Realität in den Systemen sieht anders aus. Die Gründe lassen sich auf vier Wurzelursachen zurückführen.

Ursache Rechteakkumulation: Berechtigungen wachsen, aber schrumpfen nie

Eine Mitarbeiterin startet im Einkauf, wechselt nach drei Jahren in das Controlling und übernimmt später eine Projektleitung. Bei jedem Wechsel erhält sie neue Rechte. Die alten bleiben, weil niemand sie aktiv entzieht – schließlich könnte sie die Daten „noch brauchen”.

In der Fachliteratur heißt dieses Phänomen Privilege Creep oder Rechteakkumulation. Nach einigen Jahren verfügen langjährige Mitarbeitende über ein Rechteprofil, das keiner aktuellen Funktion mehr entspricht und das Prinzip der Funktionstrennung unterläuft. Unser Blogbeitrag zum Thema Rechteakkumulation beschreibt dieses Phänomen genauer.

Ursache Rollenwildwuchs: Das Rollenmodell spiegelt die Organisation nicht wider

Viele Rollenmodelle entstehen bottom-up: Die IT kopiert das Rechteprofil eines bestehenden Mitarbeiters („Bitte die gleichen Rechte wie Herr Müller”). Nach einigen Jahren existieren Hunderte Rollen, von denen viele nur einer einzigen Person zugeordnet sind. Das Gegenteil ist ebenso problematisch: wenige, sehr grobe Rollen, die zu viele Rechte bündeln. In beiden Fällen fehlt die Ableitung aus der tatsächlichen Organisationsstruktur – aus Stellen, Funktionen und Verantwortlichkeiten.

Ursache fehlende Datenbasis: Niemand weiß zuverlässig, wer welche Funktion hat

Ein Berechtigungskonzept setzt voraus, dass für jede Identität bekannt ist: Welche Stelle hat diese Person? Welcher Organisationseinheit gehört sie an? Wer ist die Führungskraft? Ist der Vertrag befristet? Ist die Person extern?

Diese Informationen liegen verteilt im HR-System, im Active Directory, in Projekt-Tools und in Excel-Listen des Fachbereichs – und widersprechen sich häufig. Ohne einen konsolidierten, aktuellen Datensatz pro Identität bleibt jede Rollenzuordnung eine Schätzung.

Ursache manuelle Prozesse: Vergabe und Entzug hängen an E-Mails und Tickets

Wird ein Austritt erst Tage später an die IT gemeldet, bleiben Konten aktiv. Werden Rechte per E-Mail beantragt und per Hand gesetzt, fehlt der revisionssichere Nachweis. Rezertifizierungen werden als Excel-Liste verschickt, abgehakt und abgelegt – oft ohne echte Prüfung. Manuelle Prozesse skalieren nicht und erzeugen genau die Lücken, die im Audit sichtbar werden.

Zwischenfazit: Keine dieser vier Ursachen ist primär ein Technologieproblem. Rechteakkumulation, Rollenwildwuchs und manuelle Prozesse sind Symptome. Die eigentliche Ursache liegt tiefer.

Ihr Berechtigungskonzept ist kein Dokument, sondern ein Datenmodell

Die meisten Unternehmen behandeln das Berechtigungskonzept als Dokument: Es wird erstellt, freigegeben, abgelegt und alle zwei Jahre aktualisiert. Diese Sichtweise ist der Kern des Problems.

Ein Berechtigungskonzept beschreibt eine Abbildung: Organisation → Rollen → Rechte. Die Organisation verändert sich jeden Tag – durch Eintritte, Austritte, Versetzungen, Umstrukturierungen, neue Projekte und Zukäufe. Ein Dokument kann diese Dynamik nicht abbilden. Ein Datenmodell kann es.

Der Perspektivwechsel lautet daher: Sie haben kein Berechtigungsproblem, sondern ein Stammdatenproblem. Wenn Identitäts- und Organisationsdaten sauber, aktuell und eindeutig sind, lassen sich Rollen regelbasiert ableiten und Rechte automatisch vergeben und entziehen. Wenn diese Daten fehlerhaft sind, hilft auch das ausgefeilteste Rollenmodell nicht.

Was das konkret bedeutet:

• Statt „Rolle X wird manuell Person Y zugewiesen” gilt „Jede Person mit Stelle Kreditorenbuchhaltung in der Organisationseinheit Finanzen DE erhält automatisch die Rolle FI-Kreditoren-Sachbearbeitung”.

• Statt „Die IT erfährt per E-Mail vom Austritt” gilt „Das Austrittsdatum im HR-Stammsatz löst den Entzug aller Rechte zum Stichtag aus”.

• Statt „Rezertifizierung per Excel-Liste” gilt „Abweichungen zwischen Soll-Rechten (aus dem Modell) und Ist-Rechten (in den Zielsystemen) werden täglich sichtbar”.

Diese Logik entspricht dem Prinzip des Golden Record: ein eindeutiger, konsolidierter und historisierter Datensatz pro Identität, aus dem alle nachgelagerten Systeme ihre Informationen beziehen. Erst auf dieser Grundlage wird aus dem Berechtigungskonzept ein Regelwerk, das sich selbst durchsetzt.

Für CISOs hat der Perspektivwechsel eine wichtige Konsequenz: Das Berechtigungskonzept ist nicht allein Aufgabe der IT-Sicherheit. Es braucht HR als Quelle der Identitätsdaten, die Fachbereiche als Eigentümer der Rollen und die Organisationsentwicklung als Eigentümerin der Strukturdaten. Wer das Projekt nur in der IT verankert, baut auf Sand.

Berechtigungskonzept erstellen: In acht Schritten zum belastbaren Regelwerk

Die folgenden acht Schritte bilden einen erprobten Weg, ein Berechtigungskonzept zu erstellen oder ein bestehendes Konzept grundlegend zu überarbeiten. Die Reihenfolge ist bewusst gewählt: Erst Klarheit über Daten und Verantwortung, dann Rollen, dann Technik.

Schritt 1: Geltungsbereich, Ziele und Verantwortliche festlegen

Definieren Sie zu Beginn, welche Systeme, Organisationseinheiten und Identitätstypen das Berechtigungskonzept umfasst. Starten Sie nicht mit allen 300 Anwendungen, sondern mit den Systemen, die das höchste Risiko tragen: ERP, HR-System, Finanzbuchhaltung, zentrale Verzeichnisdienste, Systeme mit besonders schützenswerten personenbezogenen Daten.

Benennen Sie gleichzeitig die Verantwortlichen:

• Konzeptverantwortung: in der Regel der CISO oder der Informationssicherheitsbeauftragte.

• System- und Daten-Owner: pro Anwendung eine fachlich verantwortliche Person, die über Rollen und Rechte entscheidet.

• Führungskräfte: beantragen Rechte für ihre Teams und bestätigen sie bei der Rezertifizierung.

• IT-Betrieb: setzt Rechte technisch um.

• Datenschutz und Revision: prüfen Konformität und Wirksamkeit.

Lassen Sie das Mandat von der Geschäftsleitung freigeben. NIS2 nimmt die Leitungsorgane ausdrücklich in die Verantwortung für Risikomanagementmaßnahmen; ohne dieses Mandat fehlt dem Projekt die Durchsetzungskraft gegenüber den Fachbereichen.

Schritt 2: Ist-Aufnahme von Identitäten, Konten und Rechten

Erheben Sie den Status quo: Welche Identitäten existieren, welche Konten haben sie in welchen Systemen, welche Rechte sind vergeben? Diese Bestandsaufnahme ist aufwendig, aber unverzichtbar. Sie liefert in der Regel drei unangenehme Erkenntnisse:

• Verwaiste Konten: Konten ohne zugehörige aktive Person, etwa von ausgeschiedenen Mitarbeitenden oder abgeschlossenen Projekten.

• Überberechtigungen: Rechte, die über die aktuelle Funktion hinausgehen.

• Unbekannte Identitäten: Service-Accounts, Testkonten und technische Benutzer ohne dokumentierten Verantwortlichen.

Gleichen Sie die Konten mit den HR-Stammdaten ab. Jedes Konto braucht eine eindeutig zugeordnete, verantwortliche Person – auch technische Konten.

Schritt 3: Identitäts- und Organisationsdaten konsolidieren

Dieser Schritt wird in den meisten Projekten übersprungen – und ist der wichtigste. Bevor Sie Rollen definieren, brauchen Sie einen verlässlichen Datensatz pro Person: Stelle, Funktion, Organisationseinheit, Kostenstelle, Standort, Führungskraft, Beschäftigungsart, Vertragsbeginn und -ende.

Führen Sie die Daten aus HR-System, Verzeichnisdienst, Projektmanagement und Fachbereichslisten zu einem konsolidierten Identitätsdatensatz zusammen. Bereinigen Sie Dubletten, klären Sie Widersprüche und dokumentieren Sie für jedes Attribut die führende Quelle. Ergänzen Sie die Organisationsstruktur mit ihren Hierarchien und Gültigkeitszeiträumen. Wie sich Organisationsdaten als Grundlage für Personalprozesse nutzen lassen, zeigt unser Beitrag Organisationsmanagement: die 360°-Sicht auf Ihre Organisationsstruktur.

Das Ergebnis ist die Datenbasis, aus der Rollen später automatisch abgeleitet werden können.

Schritt 4: Schutzbedarf und Datenklassen bestimmen

Nicht jede Information braucht denselben Schutz. Klassifizieren Sie Systeme und Datenobjekte nach Schutzbedarf – etwa in die Stufen öffentlich, intern, vertraulich und streng vertraulich. Kennzeichnen Sie Datenbestände mit personenbezogenen Daten und insbesondere mit besonderen Kategorien nach Art. 9 DSGVO.

Die Schutzbedarfsfeststellung bestimmt, wie streng die Regeln für ein System ausfallen: Für streng vertrauliche Daten gelten etwa Vier-Augen-Freigaben, kürzere Rezertifizierungszyklen und lückenlose Protokollierung.

Schritt 5: Rollenmodell entwerfen

Jetzt entsteht das eigentliche Rollen- und Berechtigungskonzept. Bewährt hat sich eine mehrstufige Rollensystematik:

• Basisrollen: Rechte, die jede Person im Unternehmen erhält (E-Mail, Intranet, Zeiterfassung).

• Organisationsrollen: Rechte, die sich aus der Zugehörigkeit zu einer Organisationseinheit ergeben (z. B. Laufwerk der Abteilung).

• Funktionsrollen: Rechte, die sich aus der konkreten Stelle oder Funktion ergeben (z. B. Kreditorenbuchhaltung, Personalreferent).

• Projektrollen: befristete Rechte für die Dauer eines Projekts.

• Sonderrollen: privilegierte oder seltene Rechte, die nur nach gesonderter Freigabe und meist befristet vergeben werden.

Definieren Sie Rollen top-down aus Stellen und Funktionen und gleichen Sie sie bottom-up mit den tatsächlich genutzten Rechten ab (Role Mining). Das Konzept der rollenbasierten Zugriffskontrolle (Role-Based Access Control, RBAC) wurde Anfang der 1990er-Jahre am NIST formalisiert und später als Standard ANSI INCITS 359 veröffentlicht. Wo Rollen allein nicht ausreichen, ergänzen Sie attributbasierte Regeln (ABAC) – etwa „Zugriff nur auf Kunden des eigenen Landes”.

Halten Sie das Rollenmodell schlank. Ein guter Richtwert aus der Praxis: Eine Rolle, die nur einer einzigen Person zugeordnet ist, ist meist keine Rolle, sondern eine Ausnahme.

Schritt 6: Berechtigungsmatrix und Funktionstrennungsregeln definieren

Überführen Sie das Rollenmodell in eine Berechtigungsmatrix: Welche Rolle erhält in welchem System welche Rechtestufe? Ein Muster finden Sie im nächsten Abschnitt.

Definieren Sie parallel die Funktionstrennungsregeln als SoD-Matrix: Welche Rollen oder Rechte dürfen niemals gemeinsam bei einer Person liegen? Typische unvereinbare Kombinationen sind:

• Kreditoren anlegen und Zahlungen freigeben

• Benutzerkonten anlegen und Berechtigungen genehmigen

• Buchungen erfassen und Buchungen prüfen bzw. freigeben

• Stammdaten ändern und Änderungsprotokolle löschen

Jede Ausnahme von einer SoD-Regel muss begründet, befristet, durch kompensierende Kontrollen abgesichert und dokumentiert sein.

Schritt 7: Prozesse für den Berechtigungslebenszyklus festlegen

Beschreiben Sie, wie Berechtigungen über ihren gesamten Lebenszyklus gesteuert werden – vom Eintritt bis zum Austritt. Im Zentrum steht der Joiner-Mover-Leaver-Prozess:

• Joiner (Eintritt): Mit Anlage des HR-Stammsatzes werden Basis-, Organisations- und Funktionsrollen automatisch vergeben – idealerweise zum ersten Arbeitstag.

• Mover (Wechsel): Bei Versetzung oder Funktionswechsel werden neue Rollen vergeben und nicht mehr benötigte Rollen entzogen, ggf. mit definierter Übergangsfrist.

• Leaver (Austritt): Zum Austrittsdatum werden alle Rechte entzogen und Konten deaktiviert. Für Sonderfälle wie Elternzeit oder Sabbatical regelt das Konzept die temporäre Deaktivierung.

Ergänzen Sie Prozesse für Einzelanträge außerhalb des Rollenmodells, für befristete Rechte, für privilegierte Zugriffe und für Notfälle.

Schritt 8: Rezertifizierung, Kontrollen und Kennzahlen etablieren

Ein Berechtigungskonzept ist nur so gut wie seine Kontrolle. Legen Sie fest, in welchem Turnus Rechte überprüft werden – risikoorientiert, etwa halbjährlich für kritische Systeme und jährlich für alle übrigen. Für Finanzunternehmen schreibt DORA genau diesen Takt vor.

Definieren Sie Kennzahlen, mit denen Sie die Wirksamkeit messen:

• Anteil der Rechte, die über Rollen statt über Einzelvergabe zugeordnet sind

• Anzahl verwaister Konten

• Durchschnittliche Zeit bis zum Rechteentzug nach Austritt

• Anzahl offener SoD-Konflikte und genehmigter Ausnahmen

• Abschlussquote und Abweichungsquote der Rezertifizierung

Berichten Sie diese Kennzahlen regelmäßig an Geschäftsleitung und Informationssicherheitsausschuss. Damit wird das Berechtigungskonzept vom Dokument zum Steuerungsinstrument.

Rollen und Berechtigungskonzept Muster: So sieht eine Berechtigungsmatrix aus

Die Berechtigungsmatrix ist das Herzstück jedes Rollen- und Berechtigungskonzepts. Sie zeigt auf einen Blick, welche Rolle in welchem System welche Rechte hat. Das folgende Muster zeigt eine vereinfachte Berechtigungsmatrix für ein mittelständisches Unternehmen. Es ist bewusst reduziert und dient als Ausgangspunkt für Ihre eigene Vorlage.

Legende: L = Lesen · Ä = Ändern/Anlegen · F = Freigeben · A = Administrieren · – = kein Zugriff

Zugehörige Funktionstrennungsregel (Auszug aus der SoD-Matrix):

Praxistipps zur Berechtigungsmatrix:

• Rechte statt Transaktionen beschreiben: In der Matrix für Management und Fachbereich genügen fachliche Rechtestufen. Die technische Abbildung (Transaktionscodes, Gruppen, Profile) gehört in eine systembezogene Detailmatrix.

• Datenumfang einschränken: Ergänzen Sie, auf welche Daten sich ein Recht bezieht – etwa „eigene Kunden” oder „zugeordnete Organisationseinheit”. Das ist die Umsetzung des Need-to-know-Prinzips.

• Befristungen kennzeichnen: Privilegierte Rechte sollten in der Matrix als befristet markiert sein.

• Owner ausweisen: Jede Spalte (System) braucht einen verantwortlichen System-Owner, jede Zeile (Rolle) einen Rollen-Owner.

• Versionieren: Halten Sie fest, welche Matrix zu welchem Zeitpunkt gültig war. Im Audit wird häufig nicht nach dem heutigen Stand gefragt, sondern nach dem Stand an einem bestimmten Stichtag.

RBAC, ABAC oder beides? Zugriffsmodelle im Rollen- und Berechtigungskonzept

Ein Berechtigungskonzept muss festlegen, nach welcher Logik Zugriffe entschieden werden. In der Praxis haben sich drei Modelle etabliert, die sich nicht ausschließen, sondern ergänzen.

Rollenbasierte Zugriffskontrolle (RBAC) bündelt Rechte zu Rollen und weist Personen diesen Rollen zu. Das Modell ist leicht verständlich, gut prüfbar und deshalb die Grundlage der meisten Rollen- und Berechtigungskonzepte. Seine Schwäche: Feine Unterscheidungen – etwa nach Land, Mandant oder Kundensegment – führen schnell zu einer Vielzahl ähnlicher Rollen.

Attributbasierte Zugriffskontrolle (ABAC) entscheidet anhand von Attributen der Person (z. B. Organisationseinheit, Standort, Beschäftigungsart), der Ressource (z. B. Datenklasse, Mandant) und des Kontexts (z. B. Uhrzeit, Gerät). Damit lassen sich Regeln wie „Personalreferentinnen sehen nur Mitarbeitende ihrer zugeordneten Organisationseinheiten” elegant abbilden. Die Voraussetzung: Die Attribute müssen korrekt und aktuell sein.

Richtlinienbasierte Zugriffskontrolle (PBAC) formuliert Zugriffsentscheidungen als zentral verwaltete Richtlinien, die Rollen und Attribute kombinieren. Sie eignet sich für komplexe, stark regulierte Umgebungen, erfordert aber eine hohe Reife in Datenqualität und Governance.

Für die meisten Unternehmen ist ein hybrider Ansatz sinnvoll: RBAC als stabiles Grundgerüst, ergänzt um wenige, klar dokumentierte Attributregeln. Entscheidend ist die gemeinsame Voraussetzung aller drei Modelle – korrekte Identitäts- und Organisationsattribute. Ein ABAC-Regelwerk, das auf veralteten Kostenstellen oder falschen Organisationszuordnungen basiert, vergibt Rechte mit hoher Präzision an die falschen Personen.

Privilegierte Zugriffe und Notfallkonten: Der sensibelste Teil des Berechtigungskonzepts

Privilegierte Konten – Domänenadministratoren, Datenbank-Superuser, Root-Zugänge, Cloud-Administratoren – sind für Angreifer das wertvollste Ziel. Wer sie kontrolliert, kontrolliert die Infrastruktur. Ein Berechtigungskonzept regelt deshalb privilegierte Zugriffe gesondert und strenger als alle anderen.

Trennung von Alltags- und Administrationskonten.
Administratorinnen und Administratoren arbeiten im Alltag mit einem normalen Benutzerkonto und nutzen ein separates privilegiertes Konto nur für administrative Tätigkeiten.

Befristung statt Dauerberechtigung.
Privilegierte Rechte werden nach Möglichkeit nur für den Zeitraum einer konkreten Aufgabe vergeben (Just-in-Time-Prinzip) und automatisch wieder entzogen.

Vier-Augen-Freigabe und Begründung.
Jede Vergabe privilegierter Rechte erfordert eine dokumentierte Begründung und die Freigabe durch eine zweite Person.

Lückenlose Protokollierung.
Aktivitäten privilegierter Konten werden protokolliert und regelmäßig ausgewertet. Die Protokolle sind vor Manipulation durch die Administratoren selbst geschützt – eine direkte Anwendung der Funktionstrennung.

Notfallzugriff („Break-Glass”).
Für Notfälle existieren gesondert gesicherte Konten, deren Nutzung eine sofortige Benachrichtigung auslöst und nachträglich begründet und geprüft wird. DORA nennt Notfallzugriffe ausdrücklich als Fall, für den die Grundsätze need-to-know, need-to-use und Least Privilege ebenfalls gelten.

Multi-Faktor-Authentifizierung.
NIS2 nennt die Verwendung von Lösungen zur Multi-Faktor-Authentifizierung als eigene Risikomanagementmaßnahme. Für privilegierte Konten sollte MFA ohne Ausnahme gelten.

Joiner-Mover-Leaver: Wo das Berechtigungskonzept im Alltag bewiesen wird

Das sorgfältigste Rollenmodell nützt nichts, wenn die Zuordnung von Personen zu Rollen nicht mit der Realität Schritt hält. Der Joiner-Mover-Leaver-Prozess (JML) ist die Schnittstelle zwischen Personalwirtschaft und Berechtigungsmanagement – und damit der Ort, an dem sich die Qualität eines Berechtigungskonzepts täglich zeigt.

Drei Grundsätze machen den Unterschied:

• HR-Daten als führende Quelle: Eintritte, Wechsel und Austritte werden im HR-System erfasst und lösen die Rechteänderung aus. Die IT reagiert nicht auf E-Mails, sondern auf Datenänderungen.

• Stichtagsbezug: Jede Änderung hat ein Gültigkeitsdatum. Rechte werden zum Eintrittstag vergeben und zum Austrittstag entzogen – nicht „irgendwann danach”.

• Mover ist der kritischste Fall: Bei Eintritt und Austritt ist die Richtung klar. Beim Wechsel müssen Rechte gleichzeitig vergeben und entzogen werden. Genau hier entsteht Rechteakkumulation, wenn der Entzug fehlt.

Die detaillierte Ausgestaltung des Identity Lifecycle beschreibt unser Beitrag Identity Management: Definition, Abgrenzung und Best Practices. Wie sich die Benutzerverwaltung in diesem Lebenszyklus automatisieren lässt, zeigt der Artikel Identitäts- und Zugriffsmanagement: So automatisieren Sie Ihre Benutzerverwaltung.

Berechtigungskonzept und DSGVO: Was der Datenschutz konkret verlangt

Die DSGVO verwendet den Begriff „Berechtigungskonzept” nicht. Dennoch ist ein dokumentiertes Berechtigungskonzept in der Praxis die zentrale technisch-organisatorische Maßnahme, mit der Unternehmen mehrere Pflichten der DSGVO gleichzeitig erfüllen und nachweisen.

Art. 5 Abs. 1 lit. f DSGVO – Integrität und Vertraulichkeit: Personenbezogene Daten müssen so verarbeitet werden, dass eine angemessene Sicherheit gewährleistet ist, einschließlich Schutz vor unbefugter Verarbeitung. Unbefugter Zugriff durch eigene Mitarbeitende ist eine unbefugte Verarbeitung.

Art. 5 Abs. 2 DSGVO – Rechenschaftspflicht: Der Verantwortliche muss die Einhaltung der Grundsätze nachweisen können. Ohne dokumentiertes Berechtigungskonzept und Protokolle ist dieser Nachweis kaum zu führen.

Art. 25 Abs. 2 DSGVO – Datenschutz durch datenschutzfreundliche Voreinstellungen: Durch Voreinstellung dürfen nur personenbezogene Daten verarbeitet werden, deren Verarbeitung für den jeweiligen Zweck erforderlich ist. Das gilt ausdrücklich auch für die Zugänglichkeit der Daten. Das ist das Need-to-know-Prinzip in Gesetzesform.

Art. 32 DSGVO – Sicherheit der Verarbeitung: Verantwortliche müssen die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme auf Dauer sicherstellen und Schritte unternehmen, damit ihnen unterstellte Personen mit Zugang zu personenbezogenen Daten diese nur auf Anweisung verarbeiten.

Art. 30 DSGVO – Verzeichnis von Verarbeitungstätigkeiten: Das Verzeichnis enthält, wo möglich, eine allgemeine Beschreibung der technischen und organisatorischen Maßnahmen. Das Berechtigungskonzept ist hier die naheliegende Referenz.

Checkliste: Berechtigungskonzept DSGVO-konform gestalten

• Personenbezogene Daten und besondere Kategorien (Art. 9 DSGVO) sind in der Datenklassifikation gekennzeichnet.

• Für jede Rolle ist dokumentiert, welche personenbezogenen Daten sie zu welchem Zweck benötigt.

• Zugriffe auf personenbezogene Daten sind auf den erforderlichen Umfang beschränkt (Datensatz-, Feld- oder Mandantenebene).

• Lesende Zugriffe für Auswertungen erfolgen, wo möglich, pseudonymisiert oder anonymisiert.

• Vergabe, Änderung und Entzug sind protokolliert und rekonstruierbar.

• Rechte werden regelmäßig rezertifiziert; das Ergebnis ist dokumentiert.

• Der Datenschutzbeauftragte ist in die Freigabe des Konzepts eingebunden.

• Auftragsverarbeiter und externe Dienstleister sind mit eigenen, befristeten Identitäten erfasst.

Wie zentrale Stammdaten dabei helfen, den Grundsatz der Datenminimierung umzusetzen, beschreibt unser Beitrag Datenminimierung gemäß DSGVO.

Berechtigungskonzept für KI-Agenten und nicht-menschliche Identitäten

Bis vor wenigen Jahren war ein Berechtigungskonzept im Kern ein Konzept für Menschen. Technische Benutzer für Schnittstellen und Batch-Jobs liefen als Randthema mit. Das ändert sich gerade grundlegend. KI-Assistenten, Copilot-Funktionen in Office- und ERP-Systemen sowie autonome KI-Agenten greifen auf Unternehmensdaten zu, lesen Dokumente, fassen Kundendaten zusammen und lösen zunehmend selbst Aktionen aus.

Damit entstehen drei neue Fragen, die ein zeitgemäßes Berechtigungskonzept beantworten muss:

Mit wessen Rechten handelt die KI?
Ein KI-Assistent, der im Namen einer Person arbeitet, darf grundsätzlich nicht mehr sehen als diese Person selbst. Ist das Berechtigungskonzept lückenhaft, macht die KI die Lücken sichtbar: Eine Suchanfrage an den Assistenten fördert plötzlich Gehaltslisten, Vorstandsprotokolle oder Personalakten zutage, auf die einzelne Mitarbeitende zwar technisch Zugriff hatten, die sie aber nie gefunden hätten. Überberechtigungen, die bisher durch „Security by Obscurity” verdeckt waren, werden durch KI unmittelbar wirksam.

Welche Rechte hat ein autonomer Agent?
Agenten, die eigenständig Aufgaben ausführen – etwa Bestellungen anlegen, Tickets bearbeiten oder Stammdaten pflegen –, sind eigene Identitäten. Sie brauchen ein eigenes Rollenprofil nach dem Prinzip Least Privilege, eine verantwortliche Person als Owner, eine Befristung und eine regelmäßige Rezertifizierung.

Wie wird KI-Handeln nachvollziehbar?
Jede Aktion eines Agenten muss einer identifizierbaren Identität und letztlich einer verantwortlichen Person zuordenbar sein. Die Anforderung, Benutzer jederzeit für ihre Handlungen in IKT-Systemen identifizierbar zu halten, formuliert DORA bereits heute ausdrücklich.

Die Dringlichkeit belegen die Zahlen: Laut IBM fehlten 92 % der Organisationen, die KI-bezogene Sicherheitsvorfälle erlitten, angemessene KI-Zugriffskontrollen. Microsoft stellte bereits 2023 fest, dass Workload-Identitäten menschliche Identitäten im Verhältnis 10 zu 1 übertreffen.

Konsequenz für Ihr Berechtigungskonzept: Ergänzen Sie den Geltungsbereich um nicht-menschliche Identitäten, legen Sie eigene Rollentypen für Service-Accounts und KI-Agenten an und verankern Sie, dass KI-Funktionen das Berechtigungskonzept der zugrunde liegenden Systeme respektieren. Ein sauberes Berechtigungskonzept ist damit nicht nur Voraussetzung für Compliance, sondern für einen sicheren KI-Einsatz. Warum KI ohne vertrauenswürdige Daten scheitert, beschreibt unser Beitrag Warum KI ohne vertrauenswürdige Daten versagt.

Best Practices: Was in Berechtigungsprojekten wirklich funktioniert

Aus Stammdaten- und Identity-Projekten in regulierten Branchen lassen sich sieben Praktiken ableiten, die den Unterschied zwischen einem Konzept auf Papier und einem gelebten Regelwerk ausmachen.

Mit den Daten beginnen, nicht mit den Rollen.
Ein Rollenmodell ist nur so gut wie die Identitäts- und Organisationsdaten, auf denen es aufsetzt. Investieren Sie die ersten Projektwochen in einen konsolidierten Identitätsdatensatz. Jede Stunde, die Sie hier sparen, kostet später ein Vielfaches in der Rollenpflege.

Rollen aus der Organisation ableiten.
Verknüpfen Sie Rollen mit Stellen, Funktionen und Organisationseinheiten statt mit Personen. Dann folgt die Berechtigung automatisch der Organisation: Wer die Stelle wechselt, wechselt die Rolle.

Fachbereiche zu Eigentümern machen.
Die IT kann nicht beurteilen, ob eine Controllerin Schreibrechte auf Kostenstellen braucht. Diese Entscheidung gehört zum Fachbereich. Benennen Sie für jede Rolle einen fachlichen Owner, der Inhalt und Zuordnung verantwortet.

Privilegierte Zugriffe gesondert behandeln.
Administratorrechte, Notfallkonten und Datenbankzugriffe sind das bevorzugte Ziel von Angreifern. Vergeben Sie sie nur befristet, nach Vier-Augen-Freigabe und mit lückenloser Protokollierung. ISO/IEC 27001 führt privilegierte Zugangsrechte als eigenes Control (Anhang A 8.2).

Nicht-menschliche Identitäten einbeziehen.
Service-Accounts, Schnittstellenbenutzer, Bots und KI-Agenten greifen auf dieselben Daten zu wie Menschen. Sie brauchen eine verantwortliche Person, einen dokumentierten Zweck und eine Rezertifizierung. Der Befund von IBM, dass 92 % der Organisationen mit KI-bezogenen Vorfällen angemessene KI-Zugriffskontrollen fehlten, zeigt die Dringlichkeit.

Rezertifizierung risikoorientiert und mit Kontext gestalten.
Eine Führungskraft, die 400 Einzelrechte bestätigen soll, klickt auf „Alle bestätigen”. Bündeln Sie die Rezertifizierung auf Rollenebene, heben Sie Abweichungen und kritische Rechte hervor und rezertifizieren Sie risikoreiche Systeme häufiger.

Historie revisionssicher vorhalten.
Prüfer fragen selten: „Wer hat heute Zugriff?” Sie fragen: „Wer hatte am 30. Juni Zugriff auf das Zahlungssystem – und auf welcher Grundlage?” Ein Berechtigungskonzept braucht daher eine lückenlose, zeitgestempelte Historie aller Identitäten, Rollen und Rechte. Welche Vorteile eine vollautomatische Versionsverwaltung bietet, beschreibt unser Beitrag Die sechs Vorteile der vollautomatischen Versionsverwaltung beim Identity & Access Management.

Reifegradmodell: Wo steht Ihr Berechtigungsmanagement?

Nicht jedes Unternehmen muss sofort die höchste Ausbaustufe erreichen. Entscheidend ist, den eigenen Standort ehrlich zu bestimmen und den nächsten sinnvollen Schritt zu planen. Das folgende vierstufige Reifegradmodell hilft bei der Einordnung.

Die meisten Unternehmen, die sich mit NIS2 oder DORA beschäftigen, befinden sich nach unserer Einschätzung auf Stufe 2 oder 3 (Branchenrichtwert). Der Sprung auf Stufe 4 gelingt selten durch ein weiteres Tool, sondern durch die Konsolidierung der Datenbasis. Genau dort setzt ein Stammdatenansatz an: Wie Unternehmen ihre Datenqualität systematisch verbessern, zeigt unser Leitfaden zur Verbesserung der Datenqualität.

RACI-Matrix: Wer macht was im Berechtigungskonzept?

Klare Verantwortlichkeiten sind die Voraussetzung dafür, dass ein Berechtigungskonzept gelebt wird. Die folgende RACI-Matrix zeigt eine bewährte Aufteilung (R = Responsible/Durchführung, A = Accountable/Verantwortung, C = Consulted/Beratung, I = Informed/Information).

Vergleich: Drei Wege, ein Berechtigungskonzept umzusetzen

Unternehmen setzen ihr Berechtigungskonzept auf sehr unterschiedliche Weise um. Die folgende Vergleichstabelle stellt die drei verbreitetsten Ansätze gegenüber.

Die Tabelle macht deutlich: Der Unterschied zwischen den Ansätzen liegt weniger in der Software als in der Datenbasis. Ein IAM-Werkzeug ohne saubere Identitäts- und Organisationsdaten automatisiert im Zweifel nur die Fehler. Ein datenzentrierter Ansatz verankert das Berechtigungskonzept dort, wo die Wahrheit über die Organisation liegt.

Berechtigungskonzept nach Branchen: Worauf es in regulierten Sektoren ankommt

Die Grundprinzipien eines Berechtigungskonzepts gelten branchenübergreifend. Die Schwerpunkte unterscheiden sich jedoch deutlich, je nachdem, welche Regelwerke greifen und welche Daten besonders schützenswert sind.

Banken und Versicherungen.
Für Finanzunternehmen ist DORA seit Januar 2025 der zentrale Maßstab. Das Berechtigungskonzept muss die Prinzipien need-to-know, need-to-use und Least Privilege umsetzen, Funktionstrennung sicherstellen, generische Konten begrenzen und feste Rezertifizierungsintervalle einhalten. Hinzu kommen bankfachliche Funktionstrennungen zwischen Markt und Marktfolge sowie zwischen Handel und Abwicklung. Warum Datenmanagement für Banken unverzichtbar ist, beschreibt unser Beitrag Warum gutes Datenmanagement für Banken unumgänglich ist.

Energieversorger und kritische Infrastrukturen.
NIS2 und die nationalen Umsetzungsgesetze rücken den Schutz betrieblicher Systeme in den Fokus. Das Berechtigungskonzept muss neben der Büro-IT auch Leitsysteme und Fernwartungszugänge externer Dienstleister erfassen. Gerade der Zugriff Dritter ist kritisch: Laut Verizon DBIR 2026 ist an 48 % der Datenschutzverletzungen ein Drittanbieter beteiligt.

Fertigungsindustrie.
In der Produktion treffen Office-IT, ERP, Produktionsplanungssysteme und Maschinensteuerung aufeinander. Häufige Schwachstellen sind geteilte Schichtkonten an Maschinenterminals und Zugriffe von Wartungsdienstleistern. Das Berechtigungskonzept sollte diese Konten personalisieren oder, wo nicht möglich, durch kompensierende Kontrollen absichern.

Unternehmen mit Konzernstrukturen.
In Unternehmensgruppen mit vielen Gesellschaften kommt eine weitere Dimension hinzu: Mitarbeitende arbeiten gesellschaftsübergreifend, Organisationsstrukturen ändern sich durch Zukäufe und Umstrukturierungen, und Rechte müssen mandantengenau vergeben werden. Ohne eine saubere Abbildung der Konzern- und Organisationsstruktur ist ein konsistentes Berechtigungskonzept hier nicht möglich.

Praxis-Szenario: Vom Papierkonzept zum gelebten Rollenmodell

Hinweis: Das folgende Szenario ist anonymisiert und fasst typische Konstellationen aus Identity-Management-Projekten zusammen. Es enthält bewusst keine Kennzahlen eines einzelnen Kunden.

Ausgangslage

Ein Finanzdienstleister mit mehreren Gesellschaften in Deutschland und Österreich verfügt über ein Berechtigungskonzept aus dem Jahr der letzten ISO-27001-Zertifizierung. Das Dokument beschreibt Grundsätze und ein Rollenmodell; die Berechtigungsmatrix wird als Excel-Datei gepflegt. Eintritte und Austritte meldet HR per E-Mail an die IT. Die jährliche Rezertifizierung erfolgt über Listen, die an Führungskräfte verschickt werden.

Auslöser

Mit DORA verlangt die Aufsicht eine halbjährliche Überprüfung der Rechte für Systeme mit kritischen Funktionen und den Nachweis, dass Rechte bei Austritt ohne unangemessene Verzögerung entzogen werden. Die Ist-Aufnahme zeigt: Ein Teil der aktiven Konten lässt sich keiner aktiven Person zuordnen, mehrere langjährige Mitarbeitende verfügen über Rechte aus früheren Funktionen, und das Rollenmodell enthält zahlreiche Rollen mit nur einem einzigen Mitglied.

Vorgehen

Statt das Dokument zu überarbeiten, beginnt das Projekt bei den Daten. Identitäts- und Organisationsdaten aus HR-System, Verzeichnisdienst und Fachbereichslisten werden zu einem eindeutigen Datensatz pro Person konsolidiert. Die Organisationsstruktur wird mit Stellen und Gültigkeitszeiträumen abgebildet.

Darauf aufbauend leiten Fachbereiche und IT gemeinsam Funktionsrollen aus den Stellen ab, die Rollen mit Einzelmitgliedern werden aufgelöst oder als Ausnahmen gekennzeichnet. Rechte werden über Schnittstellen automatisch provisioniert und zum Austrittsdatum entzogen. Die Rezertifizierung erfolgt auf Rollenebene mit Soll-Ist-Vergleich.

Ergebnis

Das Berechtigungskonzept ist kein separates Dokument mehr, sondern im Datenmodell abgebildet. Die schriftliche Richtlinie beschreibt Grundsätze und Verantwortlichkeiten; Rollen, Matrix und Historie liegen im System. Anfragen der Revision zum Berechtigungsstand an einem Stichtag lassen sich aus der Historie beantworten, statt sie aus Protokollen mehrerer Systeme zu rekonstruieren.

Lernen aus dem Szenario

Der größte Hebel lag nicht im Rollendesign, sondern in der Konsolidierung der Identitäts- und Organisationsdaten. Erst als klar war, wer welche Stelle innehat, ließen sich Rollen sinnvoll ableiten – und erst dann wurde die Automatisierung belastbar.

Der Audit-Test: Zehn Fragen, die Ihr Berechtigungskonzept beantworten muss

Ob ISO-27001-Rezertifizierung, NIS2-Prüfung, DORA-Aufsicht oder Jahresabschlussprüfung: Prüferinnen und Prüfer stellen zum Berechtigungskonzept erstaunlich ähnliche Fragen. Nutzen Sie die folgende Liste als Selbsttest. Jede Frage, die Sie nicht innerhalb weniger Minuten mit einem belastbaren Nachweis beantworten können, markiert eine Lücke.

1. Wer hat heute Zugriff auf das Zahlungssystem – und auf welcher fachlichen Grundlage?

2. Wer hatte an einem bestimmten Stichtag in der Vergangenheit Zugriff auf dieses System?

3. Wie viele aktive Konten gehören zu Personen, die das Unternehmen bereits verlassen haben?

4. Wie lange dauert es im Durchschnitt, bis Rechte nach einem Austritt entzogen sind?

5. Welche Mitarbeitenden verfügen über Rechte aus einer früheren Funktion?

6. Welche Funktionstrennungskonflikte bestehen, und wer hat welche Ausnahme mit welcher Begründung genehmigt?

7. Wer besitzt privilegierte Rechte, seit wann, und wann wurden diese zuletzt überprüft?

8. Welche Service-Accounts und technischen Identitäten existieren, und wer ist jeweils verantwortlich?

9. Wann fand die letzte Rezertifizierung statt, welche Rechte wurden dabei entzogen, und wie wurde das dokumentiert?

10. Wann wurde das Berechtigungskonzept zuletzt überarbeitet und von der Geschäftsleitung freigegeben?

Auffällig ist, dass mindestens vier dieser zehn Fragen einen Blick in die Vergangenheit erfordern. Hier scheitern viele Unternehmen, selbst wenn der aktuelle Stand sauber ist: Protokolle sind über mehrere Systeme verteilt, Excel-Matrizen wurden überschrieben, und die Organisationszuordnung zum damaligen Zeitpunkt ist nicht mehr bekannt.

Ein Berechtigungskonzept, das auf einer zeitgestempelten Historie von Identitäts-, Organisations- und Berechtigungsdaten aufsetzt, beantwortet diese Fragen mit einer Abfrage statt mit einer mehrwöchigen Rekonstruktion. Der Unterschied ist nicht nur eine Frage des Aufwands. Er entscheidet darüber, ob ein Prüfer eine Feststellung schreibt oder nicht.

Tipp für CISOs: Spielen Sie den Audit-Test einmal pro Jahr intern durch – idealerweise mit einer Person aus der Revision, die die Fragen unangekündigt stellt. Die Antwortzeiten sind eine aussagekräftige Kennzahl für die Reife Ihres Berechtigungsmanagements.

Fallstricke: Was Sie beim Berechtigungskonzept vermeiden sollten

Das Konzept als einmaliges Projekt behandeln.
Ein Berechtigungskonzept, das nach der Freigabe nicht mehr angefasst wird, ist nach wenigen Monaten veraltet. Planen Sie feste Review-Zyklen und eine klare Änderungsverantwortung ein.

Mit der Technik beginnen.
Wer zuerst ein IAM-Tool auswählt und dann das Konzept schreibt, passt das Konzept an das Werkzeug an statt umgekehrt. Klären Sie zuerst Datenbasis, Rollenlogik und Verantwortlichkeiten.

Rollen kopieren statt ableiten.
„Gleiche Rechte wie Kollege X” ist der schnellste Weg zur Rechteakkumulation. Jede Rolle braucht eine fachliche Begründung und einen Owner.

Den Mover-Prozess vernachlässigen.
Eintritt und Austritt sind meist geregelt, der interne Wechsel selten. Gerade langjährige Mitarbeitende sammeln so Rechte aus mehreren Funktionen.

Rezertifizierung als Formalie.
Wenn Führungskräfte Hunderte Einzelrechte ohne Kontext bestätigen sollen, ist das Ergebnis ein Haken in der Liste, aber keine Kontrolle. Rezertifizieren Sie Rollen, nicht Einzelrechte, und zeigen Sie Abweichungen.

Technische und externe Identitäten ignorieren.
Service-Accounts, Dienstleister und KI-Agenten tauchen in vielen Konzepten gar nicht auf – obwohl sie oft weitreichende Rechte haben. Laut Verizon DBIR 2026 ist an 48 % der Datenschutzverletzungen ein Drittanbieter beteiligt.

Die Historie vergessen.
Ein Konzept, das nur den aktuellen Stand kennt, kann die Fragen der Revision nach vergangenen Stichtagen nicht beantworten. Planen Sie Versionierung und Aufbewahrung von Anfang an ein.

Fazit: Ein Berechtigungskonzept ist so gut wie die Daten, auf denen es steht

Ein Berechtigungskonzept ist weit mehr als eine Compliance-Pflicht. Es ist die Antwort auf eine der wirtschaftlich relevantesten Fragen der Informationssicherheit: Wer darf in Ihrem Unternehmen was – und können Sie das jederzeit belegen? Bei durchschnittlich 4,25 Mio. Euro Schaden je Datenleck in Deutschland, einer menschlichen Komponente in 62 % aller Datenschutzverletzungen und Regelwerken wie DSGVO, NIS2 und DORA, die Zugriffskontrollen ausdrücklich verlangen, ist diese Frage auf Ebene der Geschäftsleitung angekommen.

Die gute Nachricht: Die Grundprinzipien sind seit Jahrzehnten bekannt. Need-to-know-Prinzip, Least Privilege und Funktionstrennung bilden ein stabiles Fundament. Die Herausforderung liegt in der Umsetzung. Berechtigungskonzepte scheitern selten an fehlenden Regeln, sondern daran, dass sie als Dokument behandelt werden, während sich die Organisation täglich verändert.

Wer ein Berechtigungskonzept erstellen will, das dauerhaft trägt, sollte deshalb bei den Daten beginnen: bei einem konsolidierten, aktuellen Datensatz pro Identität und einer sauber abgebildeten Organisationsstruktur. Darauf aufbauend lassen sich Rollen aus Stellen und Funktionen ableiten, Rechte über den Joiner-Mover-Leaver-Prozess automatisch vergeben und entziehen und Berechtigungsstände für jeden Stichtag revisionssicher nachweisen.

So wird aus dem Berechtigungskonzept, was es sein sollte: kein Ordner für das nächste Audit, sondern ein Steuerungsinstrument, das Sicherheit, Compliance und Effizienz verbindet. Wie Identity Management und Data Governance dabei zusammenwirken, beschreibt unser Data Governance Framework 2026.

Quellenverzeichnis

Verizon: 2026 Data Breach Investigations Report

IBM: Cost of a Data Breach Report 2026. Deutschland-Zahlen via Silicon Saxony, · globale Zahlen via eSecurity Planet

Bitkom e. V.: Wirtschaftsschutz 2026

Microsoft: 2023 State of Cloud Permissions Risks Report

Verordnung (EU) 2016/679 (DSGVO): Art. 5, Art. 25, Art. 30, Art. 32, Art. 83

Richtlinie (EU) 2022/2555 (NIS2): EUR-Lex

Heuking: Ab jetzt gilt’s: NIS2-Umsetzungsgesetz in Kraft

KPMG Austria: NISG 2026

Verordnung (EU) 2022/2554 (DORA): EUR-Lex

Delegierte Verordnung (EU) 2024/1774 (RTS IKT-Risikomanagement), Art. 21: Volltext

ISO/IEC 27001:2022: iso.org/standard/27001

BSI: IT-Grundschutz-Kompendium, Baustein ORP.4 Identitäts- und Berechtigungsmanagement

NIST Computer Security Resource Center: Glossary – Least Privilege

NIST: Role Based Access Control – FAQ

Saltzer, J. H.; Schroeder, M. D.: The Protection of Information in Computer Systems. Proceedings of the IEEE 63(9)