Rezertifizierung von Berechtigungen: Prozess, Intervalle und Vorlage

Eine Rezertifizierung von Berechtigungen, auch Zugriffsüberprüfung oder Access Review genannt, ist eine dokumentierte Prüfung durch eine verantwortliche Person, ob jedes Konto und jede Berechtigung in einem System noch einem aktuellen Bedarf entspricht. Wird ein Zugriff nicht mehr benötigt, endet die Überprüfung mit einem Entzug, der im Zielsystem bestätigt wurde. Eine Überprüfung, die Häkchen bei „genehmigt“ sammelt, aber nicht benötigte Zugriffe bestehen lässt, bietet im Audit keine verlässliche Grundlage.

Dieser Leitfaden behandelt den Prozess Schritt für Schritt, die Prüfintervalle, die Regelwerke und Standards tatsächlich vorgeben, die Arten, wie Überprüfungen in Audits scheitern, eine Checkliste und eine kostenlose Tabellenvorlage für Ihre nächste Kampagne. Jedes Intervall unten stammt aus einem Primärtext, geprüft am 21. Oktober 2026, mit der daneben verlinkten Quelle. Wo ein Regelwerk keine Zahl nennt, sagen wir das, statt eine zu erfinden.

Kurze Antwort zur Häufigkeit: Der technische Standard zu DORA verlangt, Zugriffsrechte zu aktualisieren, wenn Änderungen notwendig sind, mindestens aber alle 6 Monate bei IKT-Systemen, die kritische oder wichtige Funktionen unterstützen, und mindestens einmal jährlich bei anderen IKT-Systemen. PCI DSS v4.0.1 legt für Benutzerkonten im Geltungsbereich mindestens alle sechs Monate fest. Die slowakische Verordnung des Nationalen Sicherheitsamts (NBÚ) Nr. 227/2025 Slg. legt für Betreiber wesentlicher Dienste mindestens einmal jährlich fest. NIST SP 800-53 und die NIS2-Durchführungsverordnung überlassen das Intervall der Organisation, und der Maßnahmentext der ISO/IEC 27001 ist nicht öffentlich, deshalb zitieren wir daraus keine Zahl. Unabhängig vom Intervall sollte ein Austritt den Zugriff dann ändern, wenn er eintritt; der technische Standard zu DORA verlangt den umgehenden Entzug der Zugriffsrechte bei Beendigung des Beschäftigungsverhältnisses oder wenn der Zugriff nicht mehr erforderlich ist.

Was eine Rezertifizierung von Berechtigungen ist

Die Überprüfung stellt pro Zeile eine Frage: Soll dieses Konto, das diese Person oder dieses System innehat, diese Berechtigung weiterhin haben? Eine Berechtigung (Entitlement) ist eine einzelne Zugriffseinheit, etwa eine Gruppenmitgliedschaft, eine Anwendungsrolle oder ein Datenbankprivileg. Die prüfende Person antwortet mit behalten, entziehen oder ändern und gibt einen Grund an.

Drei Dinge machen eine Überprüfung als Nachweis brauchbar. Die prüfende Person muss den geschäftlichen Bedarf tatsächlich beurteilen können; in der Regel ist das die direkte Führungskraft oder die für die Anwendung oder die Daten verantwortliche Person. Die Grundgesamtheit muss vollständig sein, damit die Liste abbildet, was das System tatsächlich gewährt, einschließlich der über Gruppen vererbten Zugriffe. Und jede Entscheidung zum Entzug muss umgesetzt und geprüft werden, denn eine in einer Tabelle festgehaltene Entscheidung ändert keine einzige Berechtigung.

Überprüfung, Zertifizierung und Rezertifizierung

Die Begriffe überschneiden sich. „Access Certification“ und „Recertification“, auf Deutsch Zertifizierung und Rezertifizierung, sind in Identity-Governance-Produkten gängige Bezeichnungen für dieselbe Tätigkeit, die oft als Kampagne durchgeführt wird: ein festgelegter Umfang, eine Gruppe von Prüfenden und eine Frist. midPoint, die Plattform, auf der easyIGA läuft, ist open source. Die Funktion heißt dort Rezertifizierung (englisch „access certification“) und ist als Zertifizierungskampagnen mit einem Schritt zur Umsetzung der Entscheidungen (Remediation) implementiert. Dieser Leitfaden verwendet „Rezertifizierung von Berechtigungen“ für den gesamten Prozess und „Kampagne“ für einen einzelnen Durchlauf. Das Glossar definiert die zugehörigen Begriffe.

Privilegierte und nicht-menschliche Konten gehören in eine eigene Kampagne

Administratorrechte, Notfallkonten (Break-Glass-Konten) und Servicekonten bergen andere Risiken als die Gruppenmitgliedschaften gewöhnlicher Benutzerkonten. Mehrere Regelwerke behandeln sie gesondert. Die NIS2-Durchführungsverordnung enthält eine eigene Überprüfungspflicht für privilegierte Konten und Systemverwaltungskonten, und PCI DSS führt Anwendungs- und Systemkonten in der Anforderung 7.2.5.1 mit einem risikobasierten Intervall gesondert auf. Überprüfen Sie diese Konten in einer eigenen Kampagne, mit Prüfenden, die verstehen, was die Rechte erlauben.

Ein Servicekonto hat keine Führungskraft im HR-Sinne. Es braucht eine namentlich benannte verantwortliche Person, einen dokumentierten Zweck und, soweit verfügbar, Daten zur letzten Nutzung. Fragt man eine Führungskraft, ob svc_batch_07 „noch benötigt wird“, erhält man selten eine verlässliche Antwort. Unsere Seite zu verwaisten Konten und nicht-menschlichen Identitäten beschreibt, wie die Verantwortung vor einer Rezertifizierung geklärt wird.

Wer macht was

Eine Rezertifizierung berührt mehrere Rollen. Wer sie vor der ersten Kampagne schriftlich festhält, sorgt dafür, dass jede Zeile die Frage beantworten kann, die im Audit zu ihr gestellt wird: Wer war für diese Entscheidung verantwortlich?

Zwei Prüfende für dieselbe Zeile sind eine Designentscheidung. Eine Führungskraft kennt vielleicht die Tätigkeit der Person, aber nicht, was eine kryptische ERP-Rolle erlaubt. Eine für die Anwendung verantwortliche Person kennt die Rolle, aber nicht, ob die Person letzten Monat das Team gewechselt hat. Bei sensiblen Systemen führt die Kombination beider Sichten, oder die Weiterleitung privilegierter Rechte an die anwendungsverantwortliche Person, zu einer besseren Entscheidung.

Der technische Standard zu DORA macht dies für Finanzunternehmen ausdrücklich: Die Kontoverwaltungsverfahren müssen „die Zuweisung der Aufgaben und Zuständigkeiten für die Gewährung, Überprüfung und Entziehung von Zugangsrechten“ beinhalten (Delegierte Verordnung (EU) 2024/1774, Artikel 21 Buchstabe e Ziffer i).

Der Rezertifizierungsprozess Schritt für Schritt

Die sieben Schritte unten begleiten eine Kampagne vom Umfang bis zum aufbewahrten Nachweis. Die Schritte 5 und 6 finden außerhalb der Prüfdatei statt, weshalb sie am leichtesten übersprungen werden.

1. Umfang festlegen

Benennen Sie die Systeme der Kampagne, die Kontotypen (Mitarbeitende, externe Mitarbeitende, Personal von Dritten, Servicekonten, privilegierte Konten) und die Berechtigungstypen (Rollen, Gruppen, direkte Berechtigungen). Halten Sie fest, warum ein System im Geltungsbereich ausgelassen wurde. Eine Überprüfung, die ein System stillschweigend auslässt, ist später schwer zu verteidigen.

Knüpfen Sie den Umfang an Ihre Pflichten. Ein von DORA reguliertes Unternehmen muss wissen, welche IKT-Systeme kritische oder wichtige Funktionen unterstützen, weil für sie ein kürzeres Intervall gilt. DORA definiert eine kritische oder wichtige Funktion, neben weiteren Bedingungen, als eine Funktion, deren Ausfall „die finanzielle Leistungsfähigkeit eines Finanzunternehmens oder die Solidität oder Fortführung seiner Geschäftstätigkeiten und Dienstleistungen erheblich beeinträchtigen würde“ (Verordnung (EU) 2022/2554, Artikel 3 Nummer 22). Ein Unternehmen im Geltungsbereich von PCI DSS überprüft die Konten innerhalb seines PCI-DSS-Geltungsbereichs.

2. Verlässliche Zugriffsdaten abziehen

Ziehen Sie die aktuellen Konten und Berechtigungen aus jedem System zu einem festen Stichtag ab und bewahren Sie den Abzug auf. Verwenden Sie nach Möglichkeit die effektiven Berechtigungen: die Berechtigungen, die eine Person tatsächlich ausüben kann, einschließlich der über verschachtelte Gruppen oder Rollen vererbten. Eine Liste der direkten Zuweisungen allein übersieht Zugriffe, die über Gruppen und Rollen gewährt werden.

Ordnen Sie jedes Konto einer Person oder einer Dienstidentität mit verantwortlicher Person zu. Konten, die zu niemandem passen, sind eine Feststellung, noch bevor die Überprüfung beginnt. Ergänzen Sie den Kontext, der eine Entscheidung erleichtert: Abteilung, Stellenbezeichnung, Erstellungsdatum des Kontos, wer den Zugriff wann vergeben hat und die letzte Nutzung. Kann ein System die letzte Nutzung nicht liefern, lassen Sie das Feld leer und sagen Sie das. Ein geratener Wert ist schlimmer als eine bekannte Lücke.

3. Prüfende zuweisen und ihnen Kontext geben

Leiten Sie jede Zeile an die Person weiter, die sie beurteilen kann. Geben Sie der prüfenden Person zu jeder Berechtigung eine Beschreibung in Alltagssprache, nicht nur den technischen Namen. „FI_AP_POST“ sagt einer Führungskraft wenig; „Kann Lieferantenrechnungen im Finanzsystem buchen“ ist eine Entscheidung, die sie treffen kann.

Setzen Sie eine Frist und legen Sie im Voraus fest, was passiert, wenn eine prüfende Person nicht reagiert. Wir empfehlen die Eskalation an die Führungskraft der prüfenden Person oder an die kontrollverantwortliche Person. Schweigen als Zustimmung zu werten, macht die Überprüfung zur Formsache; falls Ihre Richtlinie das überhaupt zulässt, halten Sie schriftlich fest, warum und für welche Kontengruppe mit geringem Risiko.

4. Entscheidungen mit Begründung festhalten

Jede Zeile endet mit einer von drei Entscheidungen:

• Behalten: Der Zugriff entspricht weiterhin der aktuellen Arbeit der Person.
• Entziehen: Der Zugriff wird nicht mehr benötigt.
• Ändern: Der Bedarf besteht, aber die Stufe ist falsch, zum Beispiel Schreibzugriff, wo Lesezugriff genügen würde.

Verlangen Sie bei jeder Entscheidung, privilegierten oder sensiblen Zugriff zu behalten, und bei jeder Ausnahme eine kurze Begründung. Erfassen Sie die Identität der prüfenden Person und das Entscheidungsdatum. Delegiert die prüfende Person, erfassen Sie auch die Person, an die delegiert wurde. Wer die Kontrolle prüft, zieht aus diesen Feldern Stichproben.

5. Entzüge und Änderungen umsetzen

Eine Entscheidung zum Entzug ändert nichts, bis jemand sie umsetzt. Erstellen Sie für jede ein Ticket oder eine automatisierte Änderung, verknüpft mit der Zeile der Überprüfung. Der technische Standard zu DORA verlangt „den umgehenden Entzug der Zugangsrechte bei Beendigung des Beschäftigungsverhältnisses oder wenn der Zugang nicht länger erforderlich ist“ (Artikel 21 Buchstabe e Ziffer iii). Nach unserer Lesart ist die Entzugsentscheidung der prüfenden Person der Zeitpunkt, ab dem bekannt ist, dass der Zugriff nicht länger erforderlich ist; der Entzug sollte deshalb ab diesem Datum laufen.

Legen Sie eine Zielzeit für den Abschluss der Entzüge fest, kürzer für privilegierte Rechte. Verfolgen Sie offene Entzüge in der Kampagne, damit die Kampagne nicht geschlossen werden kann, solange sie ohne dokumentierte Ausnahme noch ausstehen.

6. Ergebnis im Zielsystem verifizieren

Prüfen Sie, ob jeder Entzug tatsächlich stattgefunden hat. Ziehen Sie die Zugriffe nach der Änderung erneut aus dem Zielsystem ab oder nutzen Sie einen Abgleichsbericht, und vergleichen Sie das Ergebnis mit den Entscheidungen. Halten Sie fest, wer wann verifiziert hat. Ein deaktiviertes Verzeichniskonto kann ein lokales Anwendungskonto, ein API-Token oder eine aktive Sitzung zurücklassen; die Verifizierung muss deshalb dort stattfinden, wo der Zugriff liegt. Unser Leitfaden zum Offboarding von Mitarbeitenden erklärt, an welchen Stellen Zugriffe eine Änderung im Verzeichnis überdauern.

Halten Sie in Ihren Aufzeichnungen vier Zustände auseinander: Entzug beantragt, versucht, fehlgeschlagen und verifiziert. Eine fehlgeschlagene Änderung, die als abgeschlossen gezählt wird, ist ein schwerer Fehler in einem Prüfnachweis, denn sie sieht aus wie eine funktionierende Kontrolle.

7. Nachweis aufbewahren und Ergebnis berichten

Schließen Sie die Kampagne mit einer Zusammenfassung ab: Umfang, Stichtag des Abzugs, Anzahl der Zeilen, Entscheidungen nach Art, verifizierte Entzüge, noch offene Entzüge, Ausnahmen mit Verantwortlichen und Fälligkeitsdaten sowie Prüfende, die nicht geantwortet haben. Bewahren Sie den Abzug, die Entscheidungsdatei und die Verifizierungsnachweise zusammen auf.

Manche Regeln legen die Aufbewahrungsfrist fest. Die slowakische NBÚ-Verordnung Nr. 227/2025 Slg. verlangt, den Nachweis der Überprüfung mindestens vom Ende des letzten Audits bis zum Ende des nächsten Audits oder der nächsten Selbstbewertung aufzubewahren (Anlage 1, Nummer 80). Die NIS2-Durchführungsverordnung verlangt von den Einrichtungen, „die Ergebnisse der Überprüfung, einschließlich der erforderlichen Änderungen der Zugangs- und Zugriffsrechte“ zu dokumentieren (Anhang, Nummer 11.2.3). Wo keine Regel eine Frist setzt, bewahren Sie die Nachweise mindestens so lange auf, bis das Audit, in dem sie geprüft werden, abgeschlossen ist, und vereinbaren Sie die Frist mit Ihrer kontrollverantwortlichen Person.

Prüfintervalle laut den Primärtexten

Antworten im Internet wiederholen Prüfintervalle oft ohne Quelle. Die Tabelle nennt nur, was jeder Primärtext sagt, geprüft am 21. Oktober 2026.

Der technische Standard zu DORA legt sechs und zwölf Monate fest, dazu ereignisgesteuerte Aktualisierungen

Artikel 21 Buchstabe e Ziffer iv des technischen Standards zu DORA verlangt „die Aktualisierung der Zugangsrechte, wenn Änderungen notwendig sind, mindestens aber einmal jährlich bei allen IKT-Systemen mit Ausnahme derjenigen, die kritische oder wichtige Funktionen unterstützen, und mindestens alle sechs Monate bei IKT-Systemen, die kritische oder wichtige Funktionen unterstützen“. Die Worte „wenn Änderungen notwendig sind“ wiegen so schwer wie die Intervalle. Nach unserer Lesart ist eine Versetzung oder ein Austritt eine solche Änderung; die Aktualisierung folgt also dem Ereignis, und die regelmäßige Aktualisierung fängt auf, was der ereignisgesteuerte Prozess übersehen hat. Der Standard selbst nennt ein Ereignis: den umgehenden Entzug der Zugangsrechte bei Beendigung des Beschäftigungsverhältnisses oder wenn der Zugang nicht länger erforderlich ist (Buchstabe e Ziffer iii).

Diese Intervalle gelten für Unternehmen unter Titel II des Standards. Unternehmen, die nach Artikel 16 Absatz 1 DORA für den vereinfachten IKT-Risikomanagementrahmen in Frage kommen, folgen stattdessen Artikel 33, der eine regelmäßige Überprüfung und den Entzug verlangt, aber kein Intervall festlegt. Klären Sie, welches Regime gilt, bevor Sie einen Kalender auf der Sechsmonatszahl aufbauen. Unser Leitfaden zur Zugangskontrolle nach DORA behandelt die umliegenden Anforderungen ausführlicher.

PCI DSS v4.0.1 legt sechs Monate für Benutzerkonten fest

Anforderung 7.2.4 verlangt: „All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows: At least once every six months“ (alle Benutzerkonten und zugehörigen Zugriffsprivilegien, einschließlich der Konten Dritter und von Anbietern, werden mindestens alle sechs Monate überprüft); außerdem muss unangemessener Zugriff behoben werden, und das Management muss bestätigen, dass der Zugriff weiterhin angemessen ist. Anforderung 7.2.5.1 erfasst Anwendungs- und Systemkonten in einer Häufigkeit, die die gezielte Risikoanalyse des Unternehmens festlegt. PCI SSC kündigte im Juni 2024 an, dass v4.0 am 31. Dezember 2024 zurückgezogen wird und v4.0.1 danach die einzige aktive Version des Standards ist.

Ein Hinweis zu unserer Quelle: Das PCI-DSS-Dokument wird über die Dokumentenbibliothek des PCI SSC nach Annahme einer Lizenz verteilt, die wir mit unseren Prüfwerkzeugen nicht abschließen konnten; den Text der Version 4.0.1 selbst haben wir deshalb nicht gelesen. Der obige Wortlaut ist so zitiert, wie ihn die Seite von Microsoft zu PCI-DSS-Anforderung 7wiedergibt, eine Sekundärquelle; Microsofts Leitfadenreihe beschreibt sich selbst als auf PCI DSS v4.0 basierend, und PCI SSC erklärt, dass v4.0.1 keine Anforderungen hinzugefügt oder gestrichen hat. Prüfen Sie den Wortlaut anhand Ihrer lizenzierten Kopie von v4.0.1.

Die NIS2-Durchführungsverordnung arbeitet mit geplanten Intervallen

Die Durchführungsverordnung (EU) 2024/2690 der Kommission gilt für einen festgelegten Kreis digitaler Einrichtungen, darunter DNS-Diensteanbieter, Anbieter von Cloud-Computing-Diensten, Rechenzentrumsdiensten und verwalteten Diensten, Online-Marktplätze und Vertrauensdiensteanbieter. Nummer 11.2.3 ihres Anhangs lautet: „Die betreffenden Einrichtungen überprüfen die Zugangs- und Zugriffsrechte in geplanten Zeitabständen und ändern sie bei organisatorischen Änderungen.“ Nummer 11.3.3 wendet dieselbe Regel auf privilegierte Konten und Systemverwaltungskonten an. Beide verlangen, die Ergebnisse zu dokumentieren.

Die technische Umsetzungsleitlinie der ENISA (Juni 2025, Version 1.0) gibt zu Nummer 11.2.3 folgende Orientierung: „Perform access control reviews of assets to verify that all privileges are authorised on a recurring schedule at least annually.“ (Zugriffskontrollen der Assets wiederkehrend, mindestens jährlich, daraufhin überprüfen, dass alle Privilegien autorisiert sind.) Zu Nummer 11.5.4, die von den Einrichtungen verlangt, Identitäten regelmäßig zu überprüfen und nicht mehr benötigte zu deaktivieren, schlägt dasselbe ENISA-Dokument für die Überprüfung aktiver Identitäten einen wiederkehrenden Rhythmus vor, „as a minimum quarterly, or more frequently“ (mindestens vierteljährlich oder häufiger), bei Kleinstunternehmen jährlich. Beide Zahlen sind Orientierungshilfen und kein gesetzliches Minimum, aber ein vernünftiger Bezugspunkt, wenn Sie Ihren eigenen Plan festlegen. Für andere NIS2-Einrichtungen entscheidet die nationale Umsetzung, wie das slowakische Beispiel unten zeigt.

NIST SP 800-53 überlässt Ihnen die Häufigkeit

Der Maßnahmenkatalog von NIST lässt das Intervall als organisationsdefinierten Parameter offen. AC-2 j. verlangt von der Organisation: „Review accounts for compliance with account management requirements [Assignment: organization-defined frequency]“ (Konten in einer von der Organisation festgelegten Häufigkeit auf Einhaltung der Anforderungen an die Kontoverwaltung überprüfen). AC-6(7) verlangt, in einer von der Organisation festgelegten Häufigkeit „the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges“ zu überprüfen, also die den festgelegten Rollen oder Nutzerklassen zugewiesenen Privilegien auf ihre Notwendigkeit, und sie bei Bedarf neu zuzuweisen oder zu entfernen. In SP 800-53B gehört AC-6(7) zu den Baselines „moderate“ und „high“. Der Katalog liegt als Release 5.2.0vor, herausgegeben am 27. August 2025. Programme, die auf NIST aufbauen, etwa Autorisierungen von US-Bundesbehörden, können den Parameter mit einer Zahl füllen; prüfen Sie das Programm, nach dem Sie bewertet werden.

ISO/IEC 27001:2022 Anhang A 5.18 und Ihre eigene Richtlinie

ISO/IEC 27001:2022 (Ausgabe 3, veröffentlicht im Oktober 2022) wird von der ISO verkauft, und wir zitieren den Text der Maßnahmen in Anhang A hier nicht. Der öffentliche Beleg dafür, wo die Überprüfung von Zugriffsrechten in Anhang A verortet ist, ist die Zuordnungstabelle der ENISA (Version 1.2). Sie ordnet die NIS2-Anforderung zum Management von Zugriffsrechten (Nummer 11.2) den Maßnahmen A.5.3 und A.5.18 der ISO/IEC 27001:2022 zu und die Anforderung zu privilegierten Konten (Nummer 11.3) den Maßnahmen A.8.2 und A.8.18, warnt aber zugleich, die Zuordnung „should not be interpreted as a measure of equivalency among different standards or frameworks“ (sei nicht als Maß für die Gleichwertigkeit verschiedener Standards oder Rahmenwerke zu verstehen).

Wir empfehlen, das Intervall in Ihrer eigenen Risikobehandlung festzulegen, es mit Begründung in Ihre Richtlinie zur Zugriffskontrolle zu schreiben und Nachweise aufzubewahren, dass jede Kampagne ihm gefolgt ist. Im Audit lässt sich die Kampagne dann an Ihrer eigenen dokumentierten Regel messen. Lesen Sie die Maßnahme und die Orientierung der ISO/IEC 27002:2022 in Ihrer lizenzierten Kopie.

SOX-Überprüfungen folgen der Prüfungspraxis, nicht einem gesetzlichen Intervall

Section 404 des Sarbanes-Oxley Act (15 U.S.C. § 7262) verlangt, dass der Jahresbericht eines Emittenten einen Bericht über das interne Kontrollsystem enthält, der die Verantwortung des Managements für die interne Kontrolle der Finanzberichterstattung festhält und der eine Bewertung enthalten muss, im Gesetzeswortlaut: „contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting“. Das Gesetz erwähnt Rezertifizierungen nicht. In SOX-Programmen werden Rezertifizierungen für finanzrelevante Systeme üblicherweise als allgemeine IT-Kontrollen (IT General Controls, ITGCs) ausgestaltet und geprüft. Der Prüfungsstandard AS 2201 des PCAOB nennt unter den Faktoren, die das mit einer Kontrolle verbundene Risiko beeinflussen, „the degree to which the control relies on the effectiveness of other controls (e.g., the control environment or information technology general controls)“ (Absatz .47), also den Grad, in dem die Kontrolle von der Wirksamkeit anderer Kontrollen abhängt; ein Intervall für Rezertifizierungen legt er nicht fest. Das Intervall ist eine Entscheidung des Kontrolldesigns, die das Management trifft und die externe Abschlussprüfung testet.

Die slowakische NBÚ-Verordnung Nr. 227/2025 Slg. verlangt mindestens einmal jährlich

Für slowakische Betreiber wesentlicher Dienste verlangt Nummer 80 der Anlage 1 zur NBÚ-Verordnung Nr. 227/2025 Slg., die seit dem 1. September 2025 in Kraft ist, eine Überprüfung „v pravidelných intervaloch, najmenej raz ročne“ (in regelmäßigen Abständen, mindestens einmal jährlich). Die Überprüfung vergleicht die genehmigten Berechtigungen mit dem Ist-Zustand, umfasst die Erkennung und Ungültigerklärung ungenutzter Konten und erzeugt einen Nachweis, der mindestens vom Ende des letzten Audits bis zum Ende des nächsten Audits oder der nächsten Selbstbewertung aufbewahrt wird. Unser Leitfaden zur NBÚ-Verordnung Nr. 227/2025 Slg. erklärt die Nummern 76 bis 87 und wie die jährliche Überprüfung durchgeführt wird.

Die deutschen MaRisk legen keine Prüfintervalle mehr fest

Manche Leitfäden zitieren noch die MaRisk-Intervalle der BaFin: mindestens jährliche Überprüfung für Zeichnungsberechtigungen für Zahlungsverkehrskonten und wesentliche IT-Berechtigungen, mindestens halbjährlich für besonders kritische IT-Berechtigungen wie Administratorzugriffe und mindestens alle drei Jahre für alle übrigen. Diese Intervalle standen in der Fassung von 2024 in einer Erläuterung zu AT 4.3.1. Die aktuelle Fassung, Rundschreiben 06/2026 (BA) vom 30. Juni 2026, enthält sie nicht mehr. Das Übersendungsschreiben der BaFin erklärt, die Streichung von Erläuterungen bedeute nicht, dass die Aufsicht darauf aufbauende Lösungen nicht mehr anerkennen würde. Stellen Sie die alten Zahlen nicht als aktuelle MaRisk-Anforderung dar. Institute im Anwendungsbereich von DORA wenden die oben genannten Intervalle des technischen Standards zu DORA an. Für Institute außerhalb des DORA-Anwendungsbereichs haben wir im aktuellen MaRisk-Text kein Prüfintervall gefunden; wir empfehlen, das Intervall risikoorientiert festzulegen und die Begründung zu dokumentieren.

Das eigene Intervall festlegen

Wo Ihr Regelwerk keine Zahl nennt oder nur ein Maximum setzt, legen Sie das Intervall risikoorientiert fest und halten Sie die Begründung schriftlich fest:

Die Intervallspalte ist unsere Empfehlung, abgeleitet aus den Regeln oben, keine gesetzliche Anforderung. Jede dieser Kontengruppen braucht zusätzlich eine ereignisgesteuerte Überprüfung: Eintritte, Wechsel und Austritte sollten den Zugriff ändern, wenn das Ereignis eintritt.

Warum Rezertifizierungen scheitern

Jede der folgenden Schwächen führt dazu, dass ein Rezertifizierungsnachweis die Stichprobenfragen im Audit nicht beantworten kann. Für jede gibt es eine praktische Abhilfe, die Sie in die nächste Kampagne einbauen können.

Durchwinken. Eine prüfende Person genehmigt jede Zeile in Sekunden, weil die Liste lang ist, die Berechtigungsnamen kryptisch sind und nichts passiert, wenn sie Ja sagt. Anzeichen in den Daten: 100 Prozent Behalten-Entscheidungen, viele Zeilen in derselben Minute entschieden und keine Begründungstexte. Kürzere Listen, verständliche Beschreibungen, das Hervorheben dessen, was sich seit der letzten Überprüfung geändert hat, und eine Begründungspflicht für das Behalten privilegierter Rechte verringern das Durchwinken.

Fehlender Kontext. Die prüfende Person sieht einen Benutzernamen und einen Gruppennamen und sonst nichts. Ohne die aktuelle Tätigkeit der Person, die Bedeutung der Berechtigung, wer sie vergeben hat und ob sie genutzt wird, hat auch eine sorgfältige prüfende Person nichts, womit sie urteilen könnte. Ergänzen Sie den Kontext in der Liste, sonst wird die Überprüfung zum Raten.

Unvollständige Grundgesamtheit. Der Abzug erfasst Konten in einer lokalen Anwendung, vererbte Berechtigungen oder ein zweites Verzeichnis nicht. Die Überprüfung zertifiziert dann eine Liste, die kleiner ist als die Wirklichkeit. Gleichen Sie den Abzug mit dem System ab, bevor Sie ihn verschicken.

Kein Nachweis des Entzugs. Die Kampagne hält Entscheidungen „entziehen“ fest, aber niemand kann zeigen, dass der Zugriff entzogen wurde. In manchen Fällen wurde der Zugriff entzogen und tauchte wieder auf, weil ein automatisierter Prozess oder eine Rollenzuweisung ihn erneut gewährt hat. Die Verifizierung im Zielsystem und eine Prüfung in der nächsten Kampagne, ob entzogene Zugriffe entzogen blieben, schließen diese Lücke.

Falsche prüfende Person. Eine Führungskraft überprüft eine privilegierte Datenbankrolle, die sie nicht versteht, oder das Team einer ausscheidenden Führungskraft wird nie neu zugewiesen. Leiten Sie technische und privilegierte Rechte an die für das System verantwortliche Person, und weisen Sie Überprüfungen neu zu, wenn Prüfende wechseln.

Keine Aufzeichnung von Ausnahmen. Jemand behält einen Zugriff, der der Richtlinie widerspricht, aus einem guten Grund, der nur in einer E-Mail existiert. Halten Sie die Ausnahme, ihre verantwortliche Person und ihr Ablaufdatum in der Kampagne fest.

Checkliste für die Rezertifizierung

Nutzen Sie diese Liste vor, während und nach jeder Kampagne.

Vor der Kampagne

• Umfang schriftlich festgehalten: Systeme, Kontotypen, Berechtigungstypen, Ausschlüsse mit Begründung
• Intervall für jede Kontengruppe festgelegt und auf Ihre Regel oder Risikoentscheidung zurückgeführt
• Zugriffe aus jedem System mit Stichtag abgezogen, nach Möglichkeit als effektive Berechtigungen
• Jedes Konto einer Person oder einer Dienstidentität mit verantwortlicher Person zugeordnet; nicht zugeordnete Konten als Feststellungen erfasst
• Berechtigungen in Alltagssprache beschrieben
• Prüfende zugewiesen, privilegierte Rechte an Systemverantwortliche geleitet
• Frist, Eskalationsweg und Regel bei Nichtreaktion vereinbart

Während der Kampagne

• Jede Zeile hat eine Entscheidung: behalten, entziehen oder ändern
• Begründung erfasst für das Behalten privilegierter und sensibler Zugriffe und für jede Ausnahme
• Identität der prüfenden Person und Entscheidungsdatum erfasst, auch bei Delegation
• Nichtreaktionen eskaliert, nicht automatisch genehmigt

Nach der Kampagne

• Für jede Entscheidung zum Entziehen oder Ändern ein Ticket oder eine Änderung erstellt
• Jeder Entzug im Zielsystem verifiziert, mit Angabe, wer und wann
• Fehlgeschlagene oder ausstehende Entzüge bis zum Abschluss oder bis zu einer dokumentierten Ausnahme nachverfolgt
• Zusammenfassung geschrieben: Anzahl je Entscheidung, verifizierte Entzüge, offene Punkte, Ausnahmen
• Abzug, Entscheidungen und Verifizierungsnachweise für die erforderliche Aufbewahrungsfrist zusammen aufbewahrt
• Termin der nächsten Kampagne festgelegt; entzogene Zugriffe im nächsten Durchlauf erneut geprüft

Die kostenlose Vorlage für die Rezertifizierung

Die Vorlage für die Rezertifizierung von Berechtigungen (XLSX) ist eine einzelne Arbeitsmappe mit drei Blättern. Sie ist kostenlos nutzbar und erfordert keine Registrierung. Sie verwendet Standardfunktionen (COUNTA, COUNTIF, COUNTIFS, SUMPRODUCT, IF, AND, MAX, LEN und TRIM) und Datenüberprüfung mit Dropdown-Listen; ihre Formeln haben wir in LibreOffice Calc getestet.

• Anleitung (Instructions) erklärt, wie die Blätter auszufüllen sind, was jede Entscheidung bedeutet und wie die Verifizierungsregel lautet.
• Überprüfung (Review) enthält eine Zeile je Konto und Berechtigung, mit Dropdown-Listen für die Entscheidung und die Verifizierungsfelder.
• Zusammenfassung (Summary) zählt Entscheidungen und Verifizierungsstatus per Formel, sodass sich die Summen während der Arbeit der Prüfenden aktualisieren.

Spalten im Blatt „Review“

Was das Blatt „Summary“ zählt

Das Blatt „Summary“ zählt die Zeilen der Überprüfung, jede Entscheidungsart, Zeilen ohne Entscheidung und den Anteil der entschiedenen Zeilen. Danach zählt es die Entzüge und Änderungen, die eine Umsetzung erfordern, wie viele davon im Zielsystem verifiziert sind und wie viele mit „No“ markiert sind. Zwei Qualitätsprüfungen zählen Entscheidungen „Keep“ ohne Begründung und Entscheidungen ohne Datum. Eine Statuszelle zeigt erst dann „Complete“, wenn jede Zeile entschieden und jede Änderung verifiziert ist. Im Blatt „Review“ wird eine Zeile mit „Remove“ oder „Modify“, die noch nicht verifiziert ist, orange hinterlegt, und eine Entscheidung „Keep“ ohne Begründung gelb.

Eine Tabelle funktioniert für eine erste Kampagne oder einen kleinen Umfang. Schützen Sie die Datei, bewahren Sie den ursprünglichen Abzug daneben auf und speichern Sie beim Abschluss der Kampagne eine datierte Kopie, denn eine gemeinsam genutzte Tabelle hält nicht verlässlich fest, wer eine Entscheidung geändert hat.

Wenn eine Tabelle nicht mehr ausreicht

Tabellen scheitern an vorhersehbaren Stellen: viele Systeme und Prüfende, Abzüge, die während der laufenden Kampagne veralten, manuelles Übertragen von Entscheidungen in Tickets und keine Verbindung zwischen einer Entscheidung und der Änderung, die ihr folgte. Ein System für Identity Governance and Administration (IGA) verbindet sich mit den Quellsystemen, erzeugt die Überprüfung aus aktuellen Daten, hält Entscheidungen mit der Identität der prüfenden Person fest und kann den Entzug anstoßen oder nachverfolgen. Das reduziert das Übertragen. Ihr Team legt weiterhin Umfang und Prüfende fest und prüft weiterhin, ob die Entzüge die Zielsysteme erreicht haben.

Wenn Sie ein Werkzeug bewerten, testen Sie die Teile, die in Audits scheitern: Kann es zeigen, woher jede Berechtigung stammt, hält es einen fehlenden Wert sichtbar fehlend, und trennt es eine festgehaltene Entzugsentscheidung von einer bestätigten Änderung im Zielsystem?

Wo easyIGA ins Bild passt

easyIGA ist Identity-Governance-Software auf Basis von midPoint. Für Rezertifizierungen führt es die Person, die Berechtigung und die verfügbare Historie zusammen, damit die prüfende Person eine Grundlage für die Entscheidung hat. Letzte Nutzung, Angaben zur Vergabe und erfasste Genehmigungen erscheinen dort, wo die angebundenen Quellen sie liefern; fehlende Informationen werden deutlich gekennzeichnet.

easyIGA protokolliert bei Anfragen, die über das Produkt gestellt werden, die antragstellende Person und die erfassten Genehmigungsschritte. Außerhalb von easyIGA vergebene Zugriffsrechte werden gesondert ausgewiesen, und zwar anhand der von midPoint protokollierten Erstellungsdaten. Das Behalten und das Entziehen von Zugriffen sind festgehaltene Entscheidungen, und eine ausstehende oder fehlgeschlagene Änderung bleibt von einem verifizierten Entzug getrennt. Exporte der Nachweise aus Rezertifizierungen enthalten die verfügbare Anfrage- und Genehmigungshistorie. Bei Zugriffsanfragen sieht die genehmigende Person zum Zeitpunkt der Entscheidung Konflikte aus den in midPoint konfigurierten Ausschlussrichtlinien (Funktionstrennung). Das Erstellen und Simulieren von Regeln in easyIGA ist geplant und noch nicht verfügbar.

Welche Kontengruppen Sie wie oft rezertifizieren, leiten Sie, wie oben beschrieben, aus Ihren Risiken und Pflichten ab. Die Seite zu Rezertifizierungen beschreibt den Ablauf, und die Seite zu Audit-Nachweisen erklärt, welche Einträge eine Entscheidung stützen und was sie allein nicht beweisen können.

Häufige Fragen

Wie oft sollten Berechtigungen rezertifiziert werden?

Das hängt von der Regel ab, der Sie unterliegen. Der technische Standard zu DORA verlangt, Zugriffsrechte zu aktualisieren, wenn Änderungen notwendig sind, mindestens aber alle 6 Monate bei IKT-Systemen, die kritische oder wichtige Funktionen unterstützen, und mindestens einmal jährlich bei anderen IKT-Systemen. PCI DSS v4.0.1 Anforderung 7.2.4 legt für Benutzerkonten mindestens alle sechs Monate fest. Die NBÚ-Verordnung Nr. 227/2025 Slg. legt für slowakische Betreiber wesentlicher Dienste mindestens einmal jährlich fest. NIST SP 800-53 und die NIS2-Durchführungsverordnung überlassen Ihnen das Intervall. Für ISO/IEC 27001 empfehlen wir, das Intervall in Ihrer eigenen Richtlinie festzulegen und zu dokumentieren. Für privilegierte Zugriffe empfehlen wir eine Überprüfung mindestens so oft, wie es Ihre strengste anwendbare Regel verlangt.

Ist eine vierteljährliche Rezertifizierung vorgeschrieben?

Keiner der für diesen Leitfaden geprüften Primärtexte legt ein vierteljährliches Intervall fest. Die nächstliegende Zahl ist unverbindlich: Die technische Umsetzungsleitlinie der ENISA zu Nummer 11.5.4 der NIS2-Durchführungsverordnung (Überprüfung von Identitäten) schlägt einen wiederkehrenden Rhythmus „as a minimum quarterly, or more frequently“ (mindestens vierteljährlich oder häufiger) vor, bei Kleinstunternehmen jährlich. Eine Organisation kann für Kontengruppen mit hohem Risiko trotzdem vierteljährliche Überprüfungen wählen oder sie mit der prüfenden Stelle vereinbaren. Halten Sie schriftlich fest, warum Sie das Intervall gewählt haben.

Was ist der Unterschied zwischen einer Zugriffsüberprüfung und einer Rezertifizierung?

In der Praxis bezeichnen beide dieselbe Prüfung. „Zertifizierung“ und „Rezertifizierung“ sind Begriffe, die IGA-Produkte für eine Überprüfungskampagne verwenden. midPoint nennt die Funktion Access Certification.

Wer sollte Berechtigungen rezertifizieren?

Die Person, die den geschäftlichen Bedarf beurteilen kann: in der Regel die direkte Führungskraft für die Passung zur Tätigkeit und die für die Anwendung oder die Daten verantwortliche Person für das, was eine technische oder privilegierte Berechtigung erlaubt. Die kontrollverantwortliche Person definiert den Prozess und zeichnet das Ergebnis ab.

Welche Nachweise werden im Audit von einer Rezertifizierung erwartet?

Rechnen Sie damit, Folgendes vorzulegen: Umfang und Stichtag des Abzugs, die geprüfte Liste, jede Entscheidung mit prüfender Person und Datum, Begründungen für beibehaltene privilegierte Zugriffe und Ausnahmen, die Tickets für Entzüge und den Nachweis, dass die Entzüge im Zielsystem abgeschlossen wurden. Manche Regeln ergänzen Aufbewahrungspflichten, etwa NBÚ-Nummer 80.

Ersetzt eine Rezertifizierung die Prozesse für Austritte und Wechsel?

Nein. Eine Rezertifizierung fängt auf, was die ereignisgesteuerten Prozesse übersehen haben. Der technische Standard zu DORA verlangt den umgehenden Entzug der Zugriffsrechte bei Beendigung des Beschäftigungsverhältnisses oder wenn der Zugriff nicht mehr erforderlich ist, und verlangt gesondert die oben beschriebene regelmäßige Aktualisierung; nach unserer Lesart laufen die beiden Pflichten unabhängig voneinander.

Kann ich die Vorlage als Nachweis für ISO 27001 oder SOC 2 verwenden?

Die Vorlage erfasst die Felder, deren Aufbewahrung dieser Leitfaden empfiehlt: prüfende Person, Entscheidung, Begründung, Daten, Entzugsticket und Verifizierung. Ob sie ausreicht, hängt von der Ausgestaltung Ihrer Kontrolle und von Ihrer prüfenden Stelle ab. Für sich allein belegt sie keine Compliance.

Quellen und Prüfvermerk

Alle Quellen, URLs und die Bildlizenz wurden am 21. Oktober 2026geprüft, und die Aussagen zu Rechtstexten und Standards wurden am selben Tag in einem separaten Prüfdurchgang erneut mit den Primärtexten abgeglichen. EUR-Lex, iso.org, pcaobus.org und unsplash.com blockieren einfache automatisierte Statusprüfungen; ihre Seiten wurden an diesem Tag mit einem Seitenabruf-Werkzeug gelesen.

1. Europäische Kommission, Delegierte Verordnung (EU) 2024/1774 der Kommission vom 13. März 2024 (DORA-RTS zum IKT-Risikomanagement), Amtsblatt vom 25. Juni 2024, Artikel 21 und 33
2. Europäisches Parlament und Rat, Verordnung (EU) 2022/2554 (DORA), Artikel 3 Nummer 22
3. Europäische Kommission, Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024, Anhang Nummern 11.2.3 und 11.3.3
4. ENISA, Technical implementation guidance on Implementing Regulation (EU) 2024/2690, Version 1.0, veröffentlicht am 26. Juni 2025 (Orientierung zu den Nummern 11.2.3 und 11.5.4), und Zuordnungstabelle Version 1.2, 21. August 2025
5. PCI Security Standards Council, Document Library (PCI DSS v4.0.1, Lizenzannahme erforderlich; Text für diesen Artikel nicht gelesen), und Just Published: PCI DSS v4.0.1, 11. Juni 2024
6. Microsoft, Microsoft Entra ID and PCI-DSS Requirement 7, aktualisiert am 23. August 2024 (Sekundärquelle für den zitierten Wortlaut der Anforderung; Microsofts Reihe gibt an, auf PCI DSS v4.0 zu basieren)
7. NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, Release 5.2.0, 27. August 2025, Controls AC-2 und AC-6(7)
8. ISO, ISO/IEC 27001:2022, Ausgabe 3, Oktober 2022
9. Legal Information Institute, 15 U.S. Code § 7262, Management assessment of internal controls
10. PCAOB, AS 2201: An Audit of Internal Control Over Financial Reporting
11. Nationales Sicherheitsamt der Slowakischen Republik (NBÚ), Verordnung Nr. 227/2025 Slg. über Sicherheitsmaßnahmen, Slov-Lex, in Kraft seit 1. September 2025, und Anlage 1 (PDF)
12. BaFin, Rundschreiben 06/2026 (BA), MaRisk, 30. Juni 2026, das zugehörige Übersendungsschreiben und die Vergleichsfassung
13. Evolveum, midPoint Access Certification (Konfigurationsreferenz für midPoint 4.10; die versionslose Adresse docs.evolveum.com/midpoint/reference/roles-policies/certification/ leitet hierher weiter)
14. Foto von Jakub Żerdzicki, Unsplash, frei nutzbar gemäß der Unsplash License

Dieser Artikel ist eine praktische Orientierung und eine Lesart der zitierten Texte. Er ist keine Rechtsberatung. Klären Sie mit qualifizierten Rechts- und Compliance-Fachleuten, welche Regeln für Ihre Organisation gelten und welche Intervalle Ihre Aufsichtsbehörde oder Ihre prüfende Stelle erwartet.