¶ Berechtigungsreviews
Beispieldokument: Diese Seite beschreibt einen Review- und Nachweisprozess für die fiktive „Muster GmbH“. Die Musterwerte bestätigen weder einen vollständigen Kontenbestand noch durchgeführte Reviews, angemessene Berechtigungen, technische Korrekturen oder eine wirksame Zugriffskontrolle.
Abschlussregel: Eine fachliche Bestätigung allein schließt einen Berechtigungsreview nicht ab. Erkannte Überrechte, verwaiste Konten, abgelaufene Zugänge und unzulässige Rollenkombinationen müssen technisch korrigiert oder als befristete Ausnahme formal behandelt und anschließend nachkontrolliert werden.
Schutzregel: Benutzer-, Rollen-, Gruppen-, Rechte-, Anmelde- und Systemexporte können personenbezogene und sicherheitskritische Informationen enthalten. Originale werden nicht im öffentlich lesbaren Muster-Wiki gespeichert, sondern ausschließlich kontrolliert referenziert.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-NW-07-04 |
| Dokumentenart | Nachweisverfahren für Berechtigungsreviews und Rezertifizierungen |
| Wiki.js-Pfad | /ISMS/07-Nachweise/Berechtigungsreviews |
| Verantwortlich | IT-/IAM-Verantwortung und jeweilige System-/Information Owner |
| Fachlich geprüft durch | ISMS-Beauftragte/r, Personalwesen, Datenschutz, Compliance, interne Revision/Audit, TISAX-Koordination und betroffene Fachbereiche |
| Freigabe durch | Geschäftsführung beziehungsweise festgelegte befugte Rolle |
| Status | Entwurf – keine realen Berechtigungsreviews oder technischen Korrekturen nachgewiesen |
| Version | 0.1 |
| Stand | 08.08.2026 |
| Gültig ab | Nach fachlicher Prüfung und Freigabe |
| Nächste Prüfung | Nach freigegebenem risikobasiertem Turnus sowie bei kritischen Änderungen, Vorfällen oder Rollenwechseln |
| Schutzklasse | Vertraulich; Detailbestände und privilegierte Rechte regelmäßig streng vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 7.5, 8.1 und 9.1 sowie Annex A 5.15 bis 5.18, 8.2, 8.3, 8.5 und 8.15 |
| TISAX-Bezug | Maßgebliche ISA-Fassung und zugeordnete Kontrollfragen zu Identitäts-, Authentisierungs-, Zugriffs- und Berechtigungsmanagement |
| Weitere Bezüge | DSGVO, NIS2-Umsetzung, Funktionstrennung, Kunden-, Vertrags- und Prototypenschutzanforderungen, soweit anwendbar |
Berechtigungsreview von Scope und vollständigem Ist-Bestand über fachliche Bedarfsentscheidung und technische Korrektur bis zur Nachkontrolle. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Zweck
Dieses Verfahren steuert regelmäßige und anlassbezogene Berechtigungsreviews. Es soll sicherstellen, dass:
- Review-Scope, Systeme, Kontenarten und Stichtag eindeutig sind,
- die Grundgesamtheit vollständig und reproduzierbar ermittelt wird,
- tatsächliche Rechte gegen Rolle, Aufgabe und genehmigten Bedarf geprüft werden,
- privilegierte, externe, technische, inaktive und verwaiste Konten sichtbar bleiben,
- Funktionstrennungs- und Rollenkonflikte bewertet werden,
- Abweichungen fristgerecht technisch korrigiert werden,
- Ausnahmen befristet, risikobewertet und genehmigt sind,
- Nachkontrolle und Abschluss auf belastbaren Originalnachweisen beruhen.
Die Seite ersetzt weder das Identitäts- und Zugriffsmanagementsystem noch die führenden Personal-, Vertrags-, System-, Rollen- und Berechtigungsquellen.
¶ 2. Geltungsbereich
Der reale Review-Scope wird risikobasiert festgelegt und kann umfassen:
- zentrale Verzeichnis- und Identitätsdienste,
- lokale, Cloud-, SaaS-, Kunden- und Partnerkonten,
- Anwendungen, Datenbanken, Netzwerk-, Sicherheits- und Administrationssysteme,
- IT-, OT-, Produktions- und Entwicklungssysteme,
- privilegierte, Notfall- und Break-Glass-Konten,
- Dienst-, Funktions-, Sammel-, API-, Bot- und technische Konten,
- externe, Gast-, Lieferanten- und Fernwartungszugänge,
- Rollen, Gruppen, Einzelrechte, Tokens, Schlüssel und Zertifikatsberechtigungen,
- physische Zutrittsrechte, soweit im jeweiligen Review ausdrücklich einbezogen.
Nicht erfasste Systeme oder Kontenarten werden als Scope-Lücke dokumentiert und nicht stillschweigend als geprüft dargestellt.
¶ 3. Reviewarten
| Reviewart | Anlass | Schwerpunkt |
|---|---|---|
| turnusmäßiger Review | freigegebener risikobasierter Termin | vollständiger Soll-Ist-Abgleich im festgelegten Scope |
| Eintritts-/Wechsel-/Austrittskontrolle | Personal- oder Vertragsereignis | zeitgerechte Vergabe, Anpassung und Entzug |
| privilegierter Review | häufigerer oder anlassbezogener Termin | administrative, Notfall- und Hochrisikorechte |
| externer Zugriffsreview | Auftrags-, Vertrags- oder Projekttermin | Person, Auftrag, Laufzeit, System und Fernzugriff |
| technischer Identitätenreview | Ablauf, Rotation oder Systemänderung | Owner, Zweck, Rechte, Geheimnis, Abhängigkeit und Nutzung |
| Funktionstrennungsreview | Rollenänderung oder Konfliktmeldung | kritische Rechtekombinationen und kompensierende Kontrollen |
| Ereignisreview | Vorfall, Verdacht oder auffällige Nutzung | betroffene Identitäten, Rechte, Nutzung und Sofortmaßnahmen |
| Systemänderungsreview | Migration, Release, Mandanten- oder Rollenumbau | Vollständigkeit und Berechtigungskonsistenz vor/nach Änderung |
Ein anlassbezogener Teilreview ersetzt den vollständigen turnusmäßigen Review nur, wenn Scope und Kriterien tatsächlich gleichwertig sind und dies dokumentiert wurde.
¶ 4. Risikobasierter Turnus
Reviewintervalle werden anhand von Schutzbedarf, Kritikalität, Berechtigungsumfang, Externenzugriff, Änderungsrate, Automatisierungsgrad, Protokollierung, Vorfällen und Kundenanforderungen festgelegt.
| Reviewklasse | Beispielhafter Entwurfsturnus | Status |
|---|---|---|
| privilegierte und Notfallkonten | vierteljährlich | Nicht freigegeben; kein Review nachgewiesen |
| externe und Fernzugriffe | vierteljährlich oder zum Auftragsende | Nicht freigegeben; kein Review nachgewiesen |
| kritische Fach-, Entwicklungs- und Produktionsrollen | halbjährlich | Nicht freigegeben; kein Review nachgewiesen |
| sonstige Benutzerrollen | mindestens jährlich | Nicht freigegeben; kein Review nachgewiesen |
| technische Identitäten | risikobasiert, mindestens jährlich | Nicht freigegeben; kein Review nachgewiesen |
Diese Werte sind Muster und keine pauschalen Normfristen. Reale Intervalle müssen organisations-, risiko- und anforderungsbezogen freigegeben werden.
¶ 5. Voraussetzungen
Vor Reviewbeginn müssen mindestens vorliegen:
- eindeutige Review-ID, Scope, Stichtag und Verantwortliche,
- aktuelles System-, Anwendungs- und Informationsinventar,
- führende Identitäts- und Beschäftigungs-/Vertragsquelle,
- Rollen- und Berechtigungsmodell oder dokumentierte Soll-Kriterien,
- vollständiger Ist-Export aller einbezogenen Konten, Rollen und Rechte,
- Liste privilegierter, externer, technischer und Notfallidentitäten,
- genehmigte Ausnahmen und Befristungen,
- Verfahren für Korrektur, Eskalation und Nachkontrolle,
- geschützte Reviewablage und geregelte Zugriffsrollen.
Fehlt eine vollständige Grundgesamtheit, lautet der Status Nicht vollständig oder Nicht bewertbar, nicht Ohne Abweichung.
¶ 6. Rollen und Unabhängigkeit
| Rolle | Verantwortung |
|---|---|
| Review-Owner | Scope, Termin, Fortschritt, Eskalation und Abschluss koordinieren |
| System-/Service Owner | Systembestand, Rollenmodell und technische Umsetzung verantworten |
| Information-/Process Owner | geschäftlichen Bedarf und angemessenen Informationszugriff bestätigen |
| Führungskraft | aktuelle Rolle, Aufgabe und organisatorischen Bedarf bestätigen |
| Personalwesen | Eintritt, Wechsel, Austritt und Organisationszugehörigkeit kontrolliert abgleichen |
| IAM-/IT-Administration | vollständige Exporte erzeugen und genehmigte Korrekturen umsetzen |
| Datenschutz | Personenbezug, Zweckbindung, Datenminimierung, Zugriff und Löschung prüfen |
| ISMS/Compliance | Kriterien, Risiken, Funktionstrennung, Ausnahmen und Nachweise prüfen |
| Audit/QM | Grundgesamtheit, Stichproben, Abschluss und Wirksamkeitsaussagen unabhängig prüfen |
| Geschäftsführung/befugte Rolle | wesentliche Ausnahmen, Restrisiken und Eskalationen entscheiden |
Niemand bestätigt allein die Angemessenheit eigener privilegierter Rechte. Unvermeidbare Interessenkonflikte werden offengelegt und durch eine befugte zweite Prüfung behandelt.
¶ 7. Reviewplanung
Der Reviewauftrag enthält mindestens:
| Feld | Mindestinhalt |
|---|---|
| Review-ID | dauerhaft eindeutige Referenz, zum Beispiel BER-REV-JJJJ-NNN |
| Anlass | Turnus, Personalereignis, Änderung, Vorfall, Vertrag oder Audit |
| Scope | Systeme, Mandanten, Standorte, Konten- und Rechtearten |
| Stichtag/Zeitraum | Zeitpunkt des Ist-Bestands und Betrachtungszeitraum |
| Kriterien | Rollen, Minimalprinzip, Funktionstrennung, Befristung, MFA und weitere Anforderungen |
| Grundgesamtheit | erwartete Quellen und Vollständigkeitskontrollen |
| Reviewer | fachlich und technisch beteiligte Rollen sowie Vertretungen |
| Fristen | Entscheidung, Korrektur, Eskalation und Nachkontrolle |
| Schutz | Klassifizierung, Ablage, Zugriff, Übertragung und Löschung |
| Abschlusskriterium | erforderliche Entscheidungen, Korrekturen und Qualitätsprüfung |
¶ 8. Vollständige Grundgesamtheit
Die Grundgesamtheit wird nicht aus einer beliebigen Ansicht oder gefilterten Oberfläche abgeleitet. Für jeden Export werden dokumentiert:
- Quellsystem und Mandant,
- Exportdatum, Uhrzeit und Zeitzone,
- ausführende Rolle oder automatisierter Job,
- verwendete Abfrage, Filter und ausgeschlossene Objekte,
- enthaltene Konten-, Gruppen-, Rollen- und Rechtefelder,
- Gesamtanzahl und Abgleich mit Kontrollsummen,
- Dateiname, Version und geschützte Ablage,
- Integritätsmerkmal, soweit angemessen,
- bekannte technische Grenzen und nicht exportierbare Rechte.
Bei mehreren Berechtigungsebenen werden direkte Rechte, Gruppenmitgliedschaften, Rollenvererbung, verschachtelte Gruppen und lokale Sonderrechte nachvollziehbar zusammengeführt.
¶ 9. Mindestfelder des Ist-Bestands
Der geschützte Originalbestand enthält abhängig vom System mindestens:
| Feldgruppe | Beispiele |
|---|---|
| Identität | eindeutige ID, Kontotyp, Status und führende Identitätsquelle |
| Zuordnung | Person, Owner, Organisation, Rolle, Auftrag oder technischer Zweck |
| Rechte | Rollen, Gruppen, Einzelrechte, Privilegien und Zielressourcen |
| Gültigkeit | Erstellung, Aktivierung, Ablauf, letzte Änderung und Befristung |
| Nutzung | letzte Anmeldung oder Nutzung, soweit verfügbar und zulässig |
| Authentisierung | MFA-/Authentisierungsstatus ohne Offenlegung von Geheimnissen |
| Genehmigung | Antrag, Genehmigungs-ID und freigebende Rolle |
| Risiko | Kritikalität, Funktionstrennung, Ausnahme und Kompensationskontrolle |
Passwörter, private Schlüssel, Tokens oder andere Geheimnisse werden nicht in den Reviewexport übernommen.
¶ 10. Prüfkriterien
Für jedes Konto und Recht werden, soweit im Scope relevant, geprüft:
- Existiert die zugeordnete Person, Rolle, Organisation oder technische Identität noch?
- Besteht ein aktueller geschäftlicher oder technischer Bedarf?
- Stimmen tatsächliche Rechte mit genehmigter Rolle und Aufgabe überein?
- Sind Rechte auf das erforderliche Mindestmaß begrenzt?
- Sind privilegierte Rechte getrennt, besonders geschützt und nachvollziehbar?
- Bestehen unzulässige Funktionstrennungs- oder Interessenkonflikte?
- Sind externe, Gast- und Fernzugriffe befristet und vertraglich gedeckt?
- Haben Funktions-, Sammel- und technische Konten einen Owner und dokumentierten Zweck?
- Sind inaktive, gesperrte, abgelaufene oder verwaiste Konten angemessen behandelt?
- Sind Notfallkonten geschützt, getestet, überwacht und nur für den Notfall vorgesehen?
- Sind MFA, Authentisierung und Protokollierung entsprechend den Anforderungen umgesetzt?
- Sind Ausnahmen gültig, befristet und mit Restrisiko sowie Kompensationsmaßnahmen versehen?
¶ 11. Soll-Ist-Abgleich
| Sollquelle | Abgleich gegen Ist-Bestand |
|---|---|
| Beschäftigungs-/Vertragsstatus | aktive, ruhende, ausgeschiedene und externe Identitäten |
| Rollen- und Stellenprofil | erwartete fachliche Rollen und Grundrechte |
| genehmigter Berechtigungsantrag | tatsächlich eingerichtete Systeme, Rollen und Einzelrechte |
| Asset-/Systeminventar | vollständige einbezogene Systeme und Owner |
| Lieferanten-/Projektregister | aktuelle externe Personen, Laufzeiten und Zwecke |
| Ausnahmenregister | gültige Abweichungen, Befristungen und Kompensationskontrollen |
| technische Richtlinie | MFA, privilegierte Trennung, Logging und Zugriffsbeschränkungen |
Fehlt eine geeignete Sollquelle, wird dies als Governance- oder Rollenmodelllücke behandelt. Der aktuelle Ist-Zustand wird nicht allein deshalb zum genehmigten Soll erklärt.
¶ 12. Privilegierte Rechte
Privilegierte Rechte werden getrennt ausgewiesen und mindestens geprüft auf:
- persönliche Zuordenbarkeit und separate Administrationsidentität,
- dokumentierten Bedarf und befugte Genehmigung,
- zeitliche oder aufgabenbezogene Begrenzung,
- MFA und angemessenen Geheimnisschutz,
- Trennung von Alltags- und Administrationsnutzung,
- Protokollierung, Alarmierung und unabhängige Nachprüfung,
- Notwendigkeit direkter Rechte gegenüber Rollen- oder Gruppenvergabe,
- letzte Nutzung, inaktive Rechte und verwaiste Owner,
- Break-Glass- und Wiederherstellungsverfahren.
Ein vorhandenes PAM-Werkzeug beweist ohne Nutzungs-, Konfigurations- und Kontrollnachweise keine wirksame Steuerung privilegierter Rechte.
¶ 13. Externe und Gastzugänge
Externe Zugänge benötigen mindestens:
- identifizierte Person oder nachvollziehbare technische Identität,
- internen Owner und aktuellen geschäftlichen Auftrag,
- gültige Vertrags- und Vertraulichkeitsgrundlage,
- festgelegte Systeme, Rechte und zulässige Nutzung,
- Beginn, Ende und automatische oder kontrollierte Befristung,
- angemessene Authentisierung und MFA,
- Protokollierung und Überwachung,
- Entzug bei Auftrags-, Projekt- oder Vertragsende.
Dauerhaft offene Fernwartungs-, Hersteller- oder Gastkonten ohne aktuelle Bestätigung werden als Abweichung behandelt.
¶ 14. Technische, Dienst- und Funktionskonten
Für nicht-personengebundene Identitäten werden geprüft:
- eindeutiger Owner und Stellvertretung,
- konkreter Zweck und technische Abhängigkeit,
- kleinstmögliche Rechte und zulässige Zielsysteme,
- sichere Speicherung und Rotation der Geheimnisse,
- Ablauf, Zertifikats- oder Tokenlaufzeit,
- Protokollierung und Erkennung ungewöhnlicher Nutzung,
- Auswirkung und Verfahren bei Sperrung oder Rotation,
- Stilllegung bei entfallenem Zweck.
Ein Konto ohne natürliche Person ist nicht automatisch ein verwaistes Konto. Ohne aktuellen Owner und belegten Zweck gilt es jedoch als ungeklärt und wird eskaliert.
¶ 15. Funktionstrennung
Konflikte werden anhand freigegebener Regeln oder risikobasierter Prüfkriterien ermittelt. Beispiele sind:
- Antrag und Genehmigung derselben Berechtigung,
- Entwicklung, Freigabe und unkontrollierte Produktivsetzung,
- Bestellung, Wareneingang und Zahlungsfreigabe,
- Benutzeradministration und alleinige Kontrolle der eigenen Aktivitäten,
- Erstellung und abschließende Prüfung sicherheitsrelevanter Nachweise.
Nicht vermeidbare Konflikte benötigen dokumentierte Begründung, Restrisiko, befugte Genehmigung, wirksame Kompensationskontrolle, Befristung und Review.
¶ 16. Reviewentscheidung
| Entscheidung | Bedeutung | erforderliche Folge |
|---|---|---|
| Bestätigt | Recht ist für Rolle, Scope und Zeitraum angemessen | Entscheidung dokumentieren |
| Anpassen | Recht ist grundsätzlich erforderlich, aber Umfang oder Zuordnung ist falsch | technische Korrektur und Nachkontrolle |
| Entziehen | Bedarf besteht nicht oder ist abgelaufen | zeitnaher technischer Entzug und Nachweis |
| Sperren/Untersuchen | kritischer oder ungeklärter Zugriff | Sofortmaßnahme, Eskalation und gegebenenfalls Incident-Prüfung |
| Ausnahme beantragen | Abweichung ist vorübergehend erforderlich | Risikoentscheidung, Befristung und Kompensationskontrolle |
| Nicht bewertbar | Daten, Owner, Rolle oder Sollkriterium fehlen | Lücke eskalieren; keine positive Bestätigung |
Schweigen oder ausbleibende Rückmeldung gilt nicht als Bestätigung.
¶ 17. Technische Korrektur
Jede Korrektur erhält mindestens:
- Review- und Befund-ID,
- betroffene Identität, Rolle, Gruppe oder Ressource in geschützter Ablage,
- genehmigte Zielentscheidung,
- verantwortliche technische Rolle,
- Priorität und Frist,
- Ticket-, Workflow- oder Änderungsreferenz,
- tatsächliches Umsetzungsdatum,
- technisches Ergebnis und Fehlerbehandlung,
- Nachkontrolle durch befugte Rolle.
Ein geschlossenes Ticket ohne Nachweis des erreichten Zielzustands beendet den Befund nicht.
¶ 18. Ausnahmen
Ausnahmen werden über Ausnahmen und Risikoakzeptanzen gesteuert und enthalten mindestens:
- konkrete Abweichung und betroffenen Scope,
- geschäftliche oder technische Begründung,
- Risiko und mögliche Auswirkungen,
- kompensierende Kontrollen,
- befugte Genehmigung,
- Ablaufdatum und Reviewtermin,
- geplante dauerhafte Behandlung.
Abgelaufene Ausnahmen gelten nicht stillschweigend weiter. Gesetzliche, vertragliche und Kundenanforderungen können nicht durch eine interne Ausnahme aufgehoben werden.
¶ 19. Nachkontrolle und Abschluss
Der Review wird erst abgeschlossen, wenn:
- Scope und Grundgesamtheit vollständig dokumentiert sind,
- alle Konten und Rechte einer Entscheidung oder transparenten Lücke zugeordnet sind,
- kritische Abweichungen behandelt oder befugt eskaliert wurden,
- technische Korrekturen anhand eines aktuellen Ist-Nachweises kontrolliert wurden,
- Ausnahmen vollständig, genehmigt und befristet sind,
- verbleibende Restrisiken und offene Maßnahmen sichtbar sind,
- Reviewbericht und Originale geschützt abgelegt wurden,
- eine befugte Qualitäts- oder Abschlussprüfung dokumentiert ist.
Offene Befunde dürfen nicht durch einen pauschalen Gesamtstatus Abgeschlossen verdeckt werden.
¶ 20. Nachweispaket
| Nachweis | Mindestinhalt | Schutz |
|---|---|---|
| Reviewauftrag | ID, Scope, Stichtag, Kriterien, Rollen und Fristen | Vertraulich |
| Grundgesamtheit | Quellsysteme, Exporte, Filter, Zählungen und Grenzen | Streng vertraulich |
| Sollquellen | Rollen, Genehmigungen, Verträge und Ausnahmen | Vertraulich bis streng vertraulich |
| Entscheidungen | Reviewer, Datum, Entscheidung und Begründung | Streng vertraulich |
| Befundliste | Abweichung, Risiko, Priorität, Owner und Frist | Streng vertraulich |
| Umsetzungsnachweis | Ticket, Änderung, technisches Ergebnis und Datum | Streng vertraulich |
| Nachkontrolle | aktueller Ist-Stand und bestätigtes Zielergebnis | Streng vertraulich |
| Abschlussbericht | Scope, Kennzahlen, Grenzen, offene Punkte und Freigabe | Vertraulich |
Die kontrollierten Referenzen werden im Nachweisregister geführt. Originale verbleiben in der freigegebenen geschützten Ablage.
¶ 21. Musterregister ohne positive Nachweisbehauptung
| Review-ID | Systemklasse | Kontenart | Stichtag | Grundgesamtheit | Entscheidungen | Korrekturen | Nachkontrolle | Status |
|---|---|---|---|---|---|---|---|---|
| BER-REV-2026-001 | zentrales Identitätsverzeichnis | Benutzer und Gruppen | [Datum] |
Nicht ermittelt | Nicht durchgeführt | Nicht durchgeführt | Nicht durchgeführt | Benötigt |
| BER-REV-2026-002 | privilegierte Administration | Admin- und Notfallkonten | [Datum] |
Nicht ermittelt | Nicht durchgeführt | Nicht durchgeführt | Nicht durchgeführt | Benötigt |
| BER-REV-2026-003 | Cloud-/SaaS-Dienste | Benutzer, Gäste und Rollen | [Datum] |
Nicht ermittelt | Nicht durchgeführt | Nicht durchgeführt | Nicht durchgeführt | Benötigt |
| BER-REV-2026-004 | technische Plattformen | Dienstkonten, APIs und Tokens | [Datum] |
Nicht ermittelt | Nicht durchgeführt | Nicht durchgeführt | Nicht durchgeführt | Benötigt |
Die Zeilen sind offene Musterbedarfe und keine realen Reviewdaten.
¶ 22. Kennzahlen und Aussagegrenzen
| Kennzahl | Berechnung | Aussagegrenze |
|---|---|---|
| Reviewabdeckung | geprüfte / im freigegebenen Scope erwartete Konten oder Rechte | nur belastbar bei vollständiger Grundgesamtheit |
| fristgerechte Entscheidungen | fristgerechte / erforderliche Entscheidungen | misst noch keine technische Korrektur |
| erkannte Überrechte | bestätigte Überrechte nach Kritikalität | abhängig von Sollmodell und Prüftiefe |
| fristgerechte Korrekturen | fristgerecht umgesetzte / fällige Korrekturen | Ticketstatus allein genügt nicht |
| technisch nachkontrolliert | nachkontrollierte / umgesetzte Korrekturen | misst Zielzustandsprüfung |
| verwaiste Konten | ungeklärte Konten ohne gültigen Owner oder Bezug | Qualität hängt von Identitätsquellen ab |
| gültige Ausnahmen | gültige / offene Ausnahmen | keine positive Aussage über Angemessenheit |
| überfällige Reviews | überfällige / fällige Reviews | Scope und Risikoklasse mitberichten |
Ein niedriger Befundwert kann auch auf unvollständige Daten oder schwache Prüfkriterien zurückzuführen sein und wird nicht isoliert positiv bewertet.
¶ 23. Datenschutz, Protokollierung und Aufbewahrung
Reviewdaten werden zweckgebunden, datensparsam und rollenbasiert verarbeitet. Insbesondere werden geregelt:
- zulässiger Zweck und Empfängerkreis,
- Zugriff auf personenbezogene und privilegierte Detaildaten,
- sichere Übertragung und lokale Arbeitskopien,
- Protokollierung von Einsicht, Export und Änderung, soweit angemessen,
- Aufbewahrung von Reviewbericht, Entscheidungen, Befunden und Originalexporten,
- Löschung oder kontrollierte Archivierung nach Fristablauf,
- Bereitstellung minimierter Stichproben an Auditoren oder Prüfdienstleister.
Reviewdaten werden nicht zur allgemeinen Leistungs- oder Verhaltensüberwachung zweckentfremdet.
¶ 24. Audit- und Assessmentprüfung
Vor Bereitstellung wird geprüft:
- Ist der Review-Scope mit ISMS- oder Assessment-Scope konsistent?
- Ist die Grundgesamtheit vollständig und reproduzierbar?
- Sind Reviewer, Owner und technische Umsetzer nachvollziehbar?
- Stimmen Sollquelle, Ist-Rechte und Entscheidungen überein?
- Sind kritische Konten und Rechte gesondert geprüft?
- Sind Korrekturen technisch nachgewiesen und nachkontrolliert?
- Bleiben Ausnahmen, offene Punkte und Aussagegrenzen sichtbar?
- Wurden personenbezogene und technische Daten angemessen minimiert und geschützt?
Eine Präsentation oder zusammengefasste Quote ersetzt nicht die prüfbare Auditspur.
¶ 25. Aktueller Entwurfsstatus
| Prüffrage | Status |
|---|---|
| Sind reale Systeme, Kontenarten und Reviewklassen vollständig erfasst? | Nein |
| Sind Rollen- und Berechtigungsmodelle freigegeben? | Nein |
| Ist ein vollständiger Ist-Export je System nachgewiesen? | Nein |
| Wurden Berechtigungsreviews durchgeführt? | Nein |
| Sind technische Korrekturen und Nachkontrollen belegt? | Nein |
| Sind Ausnahmen, Datenschutz und Aufbewahrung operationalisiert? | Nein |
| Wurde der Reviewprozess intern auditiert? | Nein |
Der Musterbestand erlaubt keine positive Aussage über angemessene Berechtigungen oder wirksame Zugriffskontrollen.
¶ 26. Mitgeltende Seiten
| Thema | Führende Seite |
|---|---|
| Identitäts- und Zugriffsmanagement | Zugriff und Berechtigungen |
| Personalereignisse und Rollenwechsel | Personal und Schulungen |
| Rollen und Befugnisse | Rollen und Verantwortlichkeiten |
| Systeme und Owner | Asset-Inventar |
| Informationsschutz | Informationsklassifizierung |
| externe Zugänge | Lieferanten und Dienstleister |
| Protokollnachweise | Protokollierung und Überwachung |
| Ausnahmen | Ausnahmen und Risikoakzeptanzen |
| führendes Nachweisregister | Nachweisregister |
| Maßnahmensteuerung | Maßnahmen- und Umsetzungsregister |
| Auditprüfung | Interne Audits |
¶ 27. Weiterführende Informationen von SMCT MANAGEMENT
Unterstützung bei ISO 27001, TISAX, Zugriffskontrollen, internen Audits und belastbarer Nachweisführung
- ISO-27001-Beratung und Auditvorbereitung
- SMCT MANAGEMENT – Managementberatung mit System
- Erstgespräch unter info@smct-management.de vereinbaren
¶ 28. Offene Punkte vor Freigabe
- reale Systeme, Mandanten, Konten- und Rechtearten vollständig erfassen,
- führende Identitäts-, Rollen-, Personal- und Vertragsquellen festlegen,
- Reviewklassen, risikobasierte Intervalle und Eskalationsfristen freigeben,
- vollständige, reproduzierbare Exporte technisch testen,
- Rollen-, Minimalrechte- und Funktionstrennungskriterien bestätigen,
- Reviewer, Owner, technische Umsetzer und Vertretungen benennen,
- geschützte Reviewablage sowie Datenschutz-, Aufbewahrungs- und Löschregeln freigeben,
- Korrektur-, Ausnahme- und Nachkontrollworkflow operationalisieren,
- Pilotreview mit unabhängiger Qualitätsprüfung durchführen,
- fachliche Prüfung und formale Freigabe dokumentieren.
¶ 29. Änderungshistorie und Freigabe
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 08.08.2026 | Erste Fassung für Scope, vollständige Grundgesamtheit, Soll-Ist-Abgleich, Owner-Entscheidung, technische Korrektur, Ausnahme und Nachkontrolle | IT-/IAM-Verantwortung / ISMS-Beauftragte/r | Ausstehend | – |
¶ 30. Quellen und fachliche Grundlagen
- ISO – ISO/IEC 27001 Information security management systems
- ENX – TISAX Downloads und ISA
- SMCT MANAGEMENT – ISO-27001-Beratung
Vor der betrieblichen Nutzung sind die tatsächlich anwendbaren Norm-, ISA-, Rechts-, Vertrags-, Kunden- und Beteiligungsanforderungen sowie die realen Rollen- und Systemmodelle zu bestätigen. Lizenzierte Norm- und ISA-Texte bleiben die führenden Quellen und werden nicht in dieser Wiki-Seite reproduziert.