Beispieldokument: Diese Regelung beschreibt den Sollprozess für die fiktive „Muster GmbH“. Reale Identitätsquellen, Konten, Rollenmodelle, MFA-Abdeckung, privilegierte Rechte, Fernzugriffe, Berechtigungsreviews, Protokolle und Wirksamkeitsnachweise sind noch nicht vollständig erfasst oder bestätigt. Die Seite allein belegt keine wirksame Zugriffskontrolle.
TISAX-Hinweis: Die Kontrollfragen zu Identitäts- und Zugriffsmanagement sind Bestandteil der 46 Informationssicherheitsfragen. Alle 46 Fragen werden umgesetzt und bewertet; eine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der Statement of Applicability ist nicht vorgesehen.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-04-02 |
| Dokumentenart | Regelung / Identitäts- und Berechtigungsmanagement |
| Wiki.js-Pfad | /ISMS/04-Sicherheitsregelungen/Zugriff-und-Berechtigungen |
| Verantwortlich | IT-Leitung |
| Fachlich geprüft durch | ISMS-Beauftragte/r, Personalwesen, Datenschutz, Informations- und Systemverantwortliche |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Kontenbestand, MFA und Reviews nicht bestätigt |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe |
| Nächste Prüfung | Spätestens zwölf Monate nach Freigabe sowie anlassbezogen |
| Schutzklasse | Intern; Konten-, Rollen- und Administrationsdetails Vertraulich |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Annex A 5.15 bis 5.18, A 6.5, A 8.2 bis 8.5 und A 8.18 |
| VDA-ISA-Bezug | ISA 6.0.3, Kapitel 4.1 Identitätsmanagement und 4.2 Zugriffsmanagement |
Diese Regelung legt fest, wie digitale Identitäten und Zugriffsrechte beantragt, geprüft, genehmigt, eingerichtet, genutzt, überwacht, regelmäßig überprüft, geändert und entzogen werden.
Sie soll insbesondere sicherstellen, dass:
Die Regelung gilt für:
Der konkrete System- und Assetumfang wird mit dem Asset-Inventar und Geltungsbereich und Standorte abgeglichen.
| Ziel | Beitrag des Berechtigungsmanagements |
|---|---|
| Vertraulichkeit | Zugriff nur für berechtigte Identitäten und erforderliche Informationen |
| Integrität | Änderungen nur durch autorisierte Rollen und nachvollziehbare Verfahren |
| Verfügbarkeit | Kontrollierte Administration und funktionsfähige Notfallzugänge |
| Authentizität | Verlässliche Zuordnung von Konto, Person, Dienst oder Gerät |
| Nachvollziehbarkeit | Protokollierte Genehmigung, Änderung und sicherheitsrelevante Nutzung |
| Funktionstrennung | Kritische Beantragung, Genehmigung, Umsetzung und Kontrolle angemessen trennen |
| Datenschutz | Personenbezogene Zugriffs- und Protokolldaten zweckgebunden und verhältnismäßig behandeln |
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Grundsätze, Ressourcen, wesentliche Ausnahmen und Restrisiken freigeben |
| IT-Leitung | Verfahren, zentrale Identitätsdienste, technische Kontrollen und Nachweise verantworten |
| Personalwesen | Eintritt, Rollenwechsel, Abwesenheit und Austritt rechtzeitig und verlässlich melden |
| Führungskraft | Geschäftlichen Bedarf beantragen, bestätigen und regelmäßig überprüfen |
| Information Owner | Zugriff auf Informationen nach Schutzbedarf und Need-to-know genehmigen |
| System-/Application Owner | Systemrollen, technische Umsetzung, Funktionstrennung und Review verantworten |
| Daten-/Prozessverantwortliche/r | Fachrollen, Datenzugriff und geschäftliche Angemessenheit bewerten |
| Administration | Genehmigte Änderungen umsetzen und protokollieren, keine Eigenfreigabe kritischer Rechte |
| ISMS-Beauftragte/r | Anforderungen, Risiken, Ausnahmen, Vorfälle, Kennzahlen und Audits koordinieren |
| Datenschutz | Verhältnismäßigkeit von Identitäts-, Zugriffs- und Protokolldaten beraten |
| Einkauf/Lieferantenmanagement | Externe Zugriffe vertraglich und über den Dienstleisterlebenszyklus steuern |
| Kontoinhaber/in | Authentisierungsinformationen schützen, Rechte nur bestimmungsgemäß nutzen und Auffälligkeiten melden |
| Prüfer/in | Reviews und Wirksamkeitsprüfungen mit angemessener Unabhängigkeit durchführen |
Niemand genehmigt sich selbst eine besonders kritische Berechtigung. Technische Administration begründet keine automatische fachliche Leseberechtigung.
Für jede Identitätsart wird eine führende Quelle festgelegt:
| Identitätsart | Führende Quelle | Auslöser | Verantwortliche Rolle | Status |
|---|---|---|---|---|
| Beschäftigte | Personalstammdaten/HR-Prozess | Eintritt, Wechsel, Austritt | Personalwesen | System und Schnittstelle zu bestätigen |
| Externe Personen | Vertrags-/Auftragsregister | Auftrag, Verlängerung, Ende | Auftraggeber/in / Einkauf | Register zu bestätigen |
| Kunden-/Partnerkonten | Kunden-/Partnerverwaltung | Freigabe, Änderung, Ende | Fachbereich/System-Owner | Verfahren zu bestätigen |
| Technische Identitäten | Service-/Anwendungsregister | Einführung, Änderung, Stilllegung | System-/Application Owner | Register zu erstellen |
| Notfallkonten | Notfallzugangsregister | Einrichtung, Test, Nutzung | IT-Leitung | Bestand zu bestätigen |
Abweichungen zwischen Personal-, Vertrags-, Identitäts- und Zielsystemdaten werden untersucht und korrigiert.
Das Register enthält mindestens:
| Feld | Mindestinhalt |
|---|---|
| Identitäts-ID | Eindeutige technische und organisatorische Referenz |
| Identitätsart | Person, Funktion, Dienst, Gerät oder Notfall |
| Zugeordnete Person/Owner | Verantwortliche natürliche Person beziehungsweise Rolle |
| Organisation/Arbeitgeber | Interne oder externe Zugehörigkeit |
| Status | Beantragt, aktiv, gesperrt, abgelaufen oder beendet |
| Gültigkeitszeitraum | Beginn und gegebenenfalls Ende |
| Führende Quelle | HR-, Vertrags-, System- oder Servicebezug |
| Zugeordnete Konten | Systeme und Kontoreferenzen |
| Authentisierungsniveau | MFA, Token, Zertifikat oder anderes Verfahren |
| Letzter Review | Datum, Prüfer/in und Ergebnis |
| Sperr-/Beendigungsnachweis | Datum und Referenz |
| Identitäts-ID | Art | Owner/Person | Organisation | Beginn | Ende | Status | MFA | Letzter Review |
|---|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch zuzuordnen | Noch zu erfassen | – | – | Nicht bewertet | Nicht geprüft | Nicht durchgeführt |
Das Wiki enthält keine vollständigen Kontonamen, geheimen Kennungen oder Authentisierungsinformationen.
Vor Aktivierung werden:
Bei Wechsel werden:
Spätestens zum wirksamen Austritts- oder Auftragsende werden risikobasiert:
Bei sofortigem oder risikoreichem Austritt erfolgt die Sperrung vor oder zeitgleich mit der Mitteilung nach einem abgestimmten vertraulichen Verfahren.
| Feld | Mindestinhalt |
|---|---|
| Antrag-ID | Eindeutige Referenz |
| Identität | Person oder technische Identität |
| System/Asset | Betroffener Dienst, Anwendung oder Bereich |
| Rolle/Recht | Konkret beantragter Umfang |
| Geschäftlicher Bedarf | Aufgabe, Prozess oder Auftrag |
| Daten-/Schutzbedarf | Betroffene Informationen und Klassifizierung |
| Beginn und Ende | Gültigkeitszeitraum |
| Kritikalität | Standard, erhöht, privilegiert oder Notfall |
| Funktionstrennung | Prüfung inkompatibler Rollen |
| Genehmigungen | Führungskraft, Information Owner und System-Owner nach Bedarf |
| Umsetzende Rolle | Administration |
| Prüfnachweis | Funktion und korrekter Umfang |
| Reviewtermin | Risikobasiert festgelegt |
Unklare Anträge wie „Zugriff wie Kollegin/Kollege“ werden nicht ohne Prüfung übernommen.
Die Genehmigung richtet sich nach Risiko und Schutzbedarf:
| Berechtigungsart | Fachliche Genehmigung | Zusätzliche Genehmigung/Kontrolle |
|---|---|---|
| Standardrolle | Führungskraft oder Prozess-Owner | System-Owner nach Rollenmodell |
| Zugriff auf vertrauliche Informationen | Information Owner | System-/Application Owner |
| Privilegierte Berechtigung | System-Owner und IT-Leitung | Unabhängige zweite Instanz |
| Finanz-/Freigaberecht | Fachverantwortliche/r | Funktionstrennungsprüfung |
| Externer Fernzugriff | Interne Auftraggeberrolle und System-Owner | IT-/Informationssicherheitsprüfung |
| Notfallzugriff | Vorab definierte Notfallfreigabe | Alarmierung und nachträglicher Review |
| Technische Identität | Application-/Service-Owner | IT-Betrieb/Sicherheitsprüfung |
Genehmigungen werden nicht durch die umsetzende Administration ersetzt.
Rollen werden anhand tatsächlicher Aufgaben gestaltet:
| Rollen-ID | Rollenname | Zweck | Enthaltene Rechte | Kritikalität | Konflikte | Owner | Version | Review |
|---|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch festzulegen | Noch zu erfassen | Noch zu bewerten | Noch zu prüfen | Noch zu benennen | Entwurf | Nicht durchgeführt |
Rollen mit historisch gewachsenen oder nicht erklärbaren Rechten werden nicht ungeprüft weiterverwendet.
Bei jeder Vergabe und Überprüfung wird gefragt:
Nicht genutzte, veraltete oder nur vorsorglich vergebene Rechte werden entfernt oder befristet.
Kritische Tätigkeiten werden angemessen getrennt, beispielsweise:
| Konflikt-ID | Rolle/Recht A | Rolle/Recht B | Risiko | Kompensation | Genehmigung | Review | Status |
|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch zu erfassen | Noch zu bewerten | Noch festzulegen | Ausstehend | Nicht durchgeführt | Offen |
Ist eine Trennung organisatorisch nicht möglich, wird die Ausnahme risikobasiert genehmigt, befristet und durch nachvollziehbare Kontrollen kompensiert.
Authentisierungsverfahren werden nach Risiko, Systemkritikalität und technischen Möglichkeiten festgelegt.
Mindestens gelten:
Konkrete Passwortparameter werden je Plattform nach aktuellem Risiko, technischer Fähigkeit und freigegebener Baseline festgelegt. Eine allgemeine Zahl in dieser Wiki-Seite ersetzt keine technische Konfiguration und Prüfung.
MFA ist mindestens für folgende Zugriffe als Sollanforderung vorgesehen:
| MFA-Feld | Mindestnachweis |
|---|---|
| Scope | Systeme, Konten und Ausnahmen |
| Verfahren | Verwendete Faktoren und Bindung |
| Registrierungsprozess | Identitätsprüfung und sichere Aktivierung |
| Recovery | Ersatz, Verlust und Missbrauchsschutz |
| Erzwingung | Technische Richtlinie und Konfiguration |
| Abdeckung | Vollständige Grundgesamtheit und Auswertung |
| Ausnahmen | Risiko, Kompensation, Befristung und Freigabe |
| Wirksamkeit | Zugriffstest, Alarmierung und Stichprobe |
Aktuell ist eine vollständige MFA-Abdeckung nicht nachgewiesen. Die offenen Maßnahmen M-001, M-004 und M-014 werden im Risikobehandlungsplan geführt.
Privilegierte Rechte werden besonders gesteuert:
Privilegierte Konten werden nicht für E-Mail, allgemeines Browsen oder normale Büroarbeit verwendet.
Soweit Risiko und technische Möglichkeiten es erfordern, unterstützt ein PAM-Verfahren:
Ein beschafftes Werkzeug gilt erst nach nachgewiesener Integration, Nutzung und Wirksamkeitsprüfung als umgesetzte Maßnahme.
Gemeinsam genutzte Funktionskonten werden vermieden. Wenn sie fachlich oder technisch erforderlich sind:
Anonyme oder nicht zuordenbare Konten sind nur bei nachgewiesener Notwendigkeit und mit kompensierenden Kontrollen zulässig.
Dienstkonten, API-Keys, Tokens, Zertifikate, Bots und Automatisierungen erhalten:
| Steuerungsfeld | Mindestanforderung |
|---|---|
| Owner | Benannte verantwortliche Rolle |
| Zweck | Konkrete Anwendung und Prozessbezug |
| Systeme/Scope | Zulässige Quellen und Ziele |
| Rechte | Technisch kleinstmöglicher Umfang |
| Geheimnisschutz | Geeignete geschützte Speicherung |
| Gültigkeit | Ablauf oder geplanter Wechsel |
| Nutzung | Protokollierung und Anomalieerkennung |
| Abhängigkeiten | Dokumentierte Auswirkungen bei Sperrung/Rotation |
| Review | Regelmäßige Bestätigung |
| Stilllegung | Widerruf, Entfernung und Nachweis |
Geheimnisse werden nicht unverschlüsselt in Quellcode, Skripten, Wiki-Seiten, Tickets oder allgemein zugänglichen Konfigurationsdateien abgelegt.
Externe Zugriffe werden vor Aktivierung mit Lieferanten und Dienstleister abgestimmt.
Mindestens erforderlich sind:
Dauerhaft offene Fernwartungszugänge oder nicht zuordenbare Herstellerkonten werden als Lücke behandelt.
Fernzugriffe werden risikobasiert geschützt durch:
Besondere Produktions-, Kunden-, Datenschutz- oder Prototypenanforderungen werden zusätzlich berücksichtigt.
Vor Zugriff auf externe Plattformen werden geregelt:
Schattenkonten außerhalb des zentralen Identitäts- oder Vertragsprozesses werden erfasst und bereinigt.
Für OT- und produktionskritische Systeme werden zusätzlich berücksichtigt:
Technische Einschränkungen begründen keine automatische Nichtanwendbarkeit. Lücken werden bewertet, behandelt und befristet gesteuert.
Zugriff auf Quellcode, Build-, Deployment- und Produktivumgebungen folgt:
Direkte unkontrollierte Änderungen in Produktivsystemen werden vermieden oder als dokumentierte Notfalländerung nachbearbeitet.
Notfallkonten werden nur für definierte Ausfallszenarien eingerichtet.
| Anforderung | Umsetzungssoll |
|---|---|
| Zweck | Abgegrenztes Notfallszenario |
| Owner | Benannte verantwortliche Rolle |
| Schutz | Stark geschütztes Geheimnis und Zugriff |
| MFA | Soweit im Notfall technisch funktionsfähig |
| Nutzung | Alarmierung und vollständige Protokollierung |
| Freigabe | Vorab definierter oder nachträglicher Notfallentscheid |
| Test | Regelmäßige Funktions- und Zugriffskontrolle |
| Nachbereitung | Nutzung prüfen, Geheimnis wechseln und Ereignis dokumentieren |
Ein Notfallkonto wird nicht für Routineadministration verwendet.
Sitzungen werden je Risiko gesteuert durch:
Berechtigungsreviews prüfen nicht nur, ob ein Name in einer Liste steht. Sie bewerten:
| 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- 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 |
Die Intervalle sind interne Entwurfswerte und keine pauschalen Normfristen. Der reale Turnus wird risikobasiert freigegeben.
| Reviewfeld | Mindestinhalt |
|---|---|
| Review-ID | Eindeutige Referenz |
| Stichtag und Zeitraum | Abgegrenzte Prüfung |
| Grundgesamtheit | Vollständiger Konten- und Rechtebestand |
| Systeme und Rollen | Dokumentierter Scope |
| Prüfer/in | Fachlich geeignete Rolle |
| Owner-Bestätigung | Geschäftlicher Bedarf |
| Kritische Abweichungen | Überrechte, verwaiste oder unklare Konten |
| Maßnahmen | Entzug, Korrektur, Untersuchung oder Ausnahme |
| Umsetzungsnachweis | Technische Bestätigung |
| Abschluss | Unabhängige Qualitätsprüfung |
| Review-ID | System/Scope | Stichtag | Grundgesamtheit | Prüfer/in | Abweichungen | Korrekturen | Abschluss |
|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch festzulegen | – | Nicht ermittelt | Noch zu benennen | Nicht erhoben | Nicht erhoben | Nicht durchgeführt |
Eine fachliche Bestätigung ohne nachgewiesenen technischen Entzug erkannter Rechte schließt den Review nicht ab.
Regelmäßige Kontrollen identifizieren:
Solche Konten werden risikobasiert gesperrt, untersucht, bereinigt und dokumentiert.
Sicherheitsrelevante Identitäts- und Zugriffsereignisse werden angemessen protokolliert, beispielsweise:
Zweck, Zugriff, Auswertung, Aufbewahrung und Datenschutz der Protokolle werden festgelegt. Protokolle ohne aktive Auswertung oder getesteten Alarmweg werden nicht als vollständige Überwachung dargestellt.
Da der Identitätsdienst eine kritische Abhängigkeit ist, werden:
Die Details werden mit Notfallvorsorge und BCM und Wiederanlaufplanung abgestimmt.
Zu melden sind insbesondere:
Die Meldung erfolgt über den Meldeweg für Sicherheitsvorfälle. Die Bearbeitung richtet sich nach Incident Response.
Risikobasiert werden:
Eine Passwortänderung allein schließt eine mögliche Kontokompromittierung nicht.
Abweichungen, beispielsweise fehlende MFA-Fähigkeit oder notwendige Sammelkonten, werden nach Ausnahmen und Risikoakzeptanzen gesteuert.
Mindestens erforderlich sind:
Eine technische Einschränkung wird nicht automatisch als dauerhaft akzeptiertes Restrisiko behandelt.
| Eintrag-ID | Identität/Rolle | System | Abweichung/kritischer Zugriff | Risiko | Kompensation | Freigabe | Ende | Review | Status |
|---|---|---|---|---|---|---|---|---|---|
| Noch zu vergeben | Noch zu erfassen | Noch zu erfassen | Noch zu bewerten | Noch zu bewerten | Noch festzulegen | Ausstehend | Noch festzulegen | Nicht durchgeführt | Offen |
Geheime Kontonamen, Kennwörter, Tokens oder technische Angriffsdetails werden nicht in dieser Wiki-Tabelle geführt.
| ISA-Kapitel | Themengebiet | Kontrollfragen ISA 6.0.3 | Inhalt dieser Regelung | Status |
|---|---|---|---|---|
| 4.1 | Identitätsmanagement | 3 | Identitätsquellen, Lebenszyklus, Konten und Authentisierung | 0 von 3 bewertet |
| 4.2 | Zugriffsmanagement | 1 | Genehmigung, Minimalprinzip, Privilegien, Reviews und Fernzugriffe | 0 von 1 bewertet |
| Gesamt | Identität und Zugriff | 4 | Kontrollfragenbezogene Umsetzung und Nachweise erforderlich | 0 von 4 bewertet |
Für jede Kontrollfrage werden in der VDA-ISA-Selbsteinschätzung erfasst:
Die vier Kontrollfragen sind Teil der 46 Informationssicherheitsfragen und werden nicht individuell ausgeschlossen.
| Annex-A-Control | Behandlung in dieser Regelung | Aktueller Status |
|---|---|---|
| A.5.15 Zugriffskontrolle | Grundsätze, Rollen, Minimalprinzip und Need-to-know | Geplant; Umsetzung nicht geprüft |
| A.5.16 Identitätsmanagement | Identitätsquellen, Register und Joiner-Mover-Leaver | Geplant; Bestand nicht bestätigt |
| A.5.17 Authentisierungsinformationen | Geheimnisschutz, MFA, Ausgabe, Recovery und Widerruf | Geplant; MFA-Abdeckung offen |
| A.5.18 Zugriffsrechte | Antrag, Genehmigung, Umsetzung, Review und Entzug | Geplant; keine Reviews nachgewiesen |
| A.6.5 Wechsel/Beendigung | Rollenwechsel, Austritt und Rückgabe | Geplant; Prozesswirksamkeit nicht geprüft |
| A.8.2 Privilegierte Berechtigungen | Trennung, Genehmigung, PAM und Überwachung | Geplant; privilegierter Bestand offen |
| A.8.3 Zugriffsbeschränkung | Rollen, Systemrechte, Daten- und Mandantentrennung | Geplant; technische Prüfung offen |
| A.8.4 Quellcodezugriff | Repository-, Build- und Deploymentrechte | Geplant; Scope nicht geprüft |
| A.8.5 Sichere Authentisierung | MFA, Session-, Reset- und Recovery-Schutz | Geplant; technische Nachweise fehlen |
| A.8.18 Privilegierte Hilfsprogramme | Kontrolle administrativer Werkzeuge und Umgehungsfunktionen | Geplant; Inventar und Prüfung fehlen |
Die Anwendbarkeit und der Umsetzungsstatus der ISO-Maßnahmen werden in der Statement of Applicability freigegeben. Diese Regelung ersetzt keine SoA-Entscheidung.
| Steuerungsobjekt | Nachweisbarer Stand |
|---|---|
| Identitätsquellen und Schnittstellen | Nicht bestätigt |
| Vollständiger Kontenbestand | Nicht vorgelegt |
| Rollen- und Berechtigungsmodell | Nicht vollständig erfasst |
| Joiner-Mover-Leaver-Nachweise | Nicht vorgelegt |
| MFA-Abdeckung | Nicht erhoben |
| Privilegierte Konten und Rechte | Nicht vollständig inventarisiert |
| Externe und Fernzugriffe | Nicht vollständig inventarisiert |
| Technische Identitäten und Geheimnisse | Nicht vollständig inventarisiert |
| Funktionstrennung | Nicht systematisch geprüft |
| Berechtigungsreviews | Nicht durchgeführt beziehungsweise nicht nachgewiesen |
| Austritts- und Sperrtests | Nicht durchgeführt |
| Notfallkonten und Tests | Nicht bestätigt |
| TISAX-Kapitel 4.1 und 4.2 | 0 von 4 Kontrollfragen bewertet |
| Wirksamkeitsnachweise | Nicht vorgelegt |
Bewertung: Die Regelungsstruktur ist vorhanden. Eine Aussage zur tatsächlichen Zugriffssicherheit, MFA-Abdeckung, ISO-Konformität oder TISAX-Reife ist nicht zulässig.
Mindestens erforderlich sind:
Nachweise enthalten Quelle, Datum, Scope, Grundgesamtheit, verantwortliche Rolle, Ergebnis, Abweichungen und eindeutigen Ablageort.
| Kontrolle | Prüfgegenstand | Entwurfsturnus | Nachweisstatus |
|---|---|---|---|
| Joiner-Stichprobe | Genehmigung, Rolle, MFA und sichere Erstausgabe | Regelmäßig | Nicht durchgeführt |
| Mover-Stichprobe | Entfernung alter und Vergabe neuer Rechte | Regelmäßig | Nicht durchgeführt |
| Leaver-Stichprobe | Rechtzeitige Sperrung, Sitzungswiderruf und Rückgabe | Regelmäßig | Nicht durchgeführt |
| MFA-Abdeckung | Grundgesamtheit, Erzwingung und Ausnahmen | Monatlich/regelmäßig | Nicht erhoben |
| Privilegienreview | Konten, Rechte, Owner, Nutzung und Befristung | Vierteljährlich im Entwurf | Nicht durchgeführt |
| Externe Zugriffe | Vertrag, Person, MFA, Zeitbegrenzung und Protokoll | Vierteljährlich im Entwurf | Nicht durchgeführt |
| Rollen-/SoD-Prüfung | Kritische Kombinationen und Kompensation | Halbjährlich im Entwurf | Nicht durchgeführt |
| Technische Identitäten | Owner, Rechte, Geheimnisse und Rotation | Risikobasiert | Nicht durchgeführt |
| Break-Glass-Test | Zugriff, Alarm, Protokoll und Rotation | Noch festzulegen | Nicht getestet |
| Identity-Recovery-Test | Wiederanlauf, Rechte und Vertrauensbeziehungen | Nach BCM-Testplan | Nicht getestet |
Entwurfsturnusse sind vor Freigabe risikobasiert zu bestätigen.
| Kennzahl | Berechnung | Entwurfsziel | Aktueller Stand |
|---|---|---|---|
| MFA-Abdeckung | Geschützte relevante Konten / relevante Konten | 100 % im bestätigten Scope | Nicht erhoben |
| Fristgerechte Joiner | Rechtzeitig bereitgestellte / fällige Konten | Vor Freigabe festlegen | Nicht erhoben |
| Fristgerechte Leaver | Rechtzeitig gesperrte / fällige Konten | 100 % | Nicht erhoben |
| Fristgerechte Reviews | Abgeschlossene / fällige Reviews | 100 % | 0 nachgewiesen |
| Kritische Überberechtigungen | Ungeklärte kritische Abweichungen | 0 ohne freigegebene Ausnahme | Nicht erhoben |
| Verwaiste Konten | Konten ohne gültige Person oder Owner | 0 | Nicht erhoben |
| Befristete externe Zugriffe | Befristete / aktive externe Zugriffe | 100 % | Nicht erhoben |
| Privilegierte MFA-Abdeckung | MFA-geschützte / privilegierte Konten | 100 % | Nicht erhoben |
| Rechtzeitig rotierte Geheimnisse | Fristgerecht gewechselte / fällige Secrets | 100 % | Nicht erhoben |
| TISAX-Kontrollfragen 4.1/4.2 | Bewertete / 4 | 4 von 4 | 0 von 4 |
Kennzahlen dürfen kritische Einzelkonten, fehlende Grundgesamtheiten oder unwirksame Sperrungen nicht durch Durchschnittswerte verdecken.
Eine Maßnahme gilt nicht allein wegen einer Richtlinie, Ticketfreigabe oder Systemkonfiguration als wirksam.
Geeignete Wirksamkeitsnachweise sind beispielsweise:
Feststellungen werden über Abweichungen und Korrekturmaßnahmen behandelt.
Identitäten und Berechtigungen werden im Auditprogramm als hoch priorisiertes Auditfeld geführt.
Mögliche Stichproben über Interne Audits:
Ein positives Auditergebnis gilt nur für Scope und Stichprobe.
| Offener Punkt | Verantwortung | Status |
|---|---|---|
| Identitätsquellen, Systeme und Schnittstellen inventarisieren | IT / Personal / Einkauf | Offen |
| Vollständigen Konten- und Rollenbestand herstellen | IT / System-Owner | Offen |
| Joiner-Mover-Leaver-Verfahren operationalisieren und testen | Personal / IT | Offen |
| Genehmigungs- und Funktionstrennungsmatrix freigeben | Geschäftsführung / Fachbereiche / IT | Offen |
| MFA-Scope, Verfahren und Recovery festlegen | IT / ISMS | Offen |
| Vollständige MFA-Abdeckung umsetzen und nachweisen | IT / System-Owner | Offen |
| Privilegierte Konten und PAM-Bedarf bewerten | IT / ISMS | Offen |
| Externe und Fernzugriffe inventarisieren und zeitlich steuern | IT / Einkauf / Fachbereiche | Offen |
| Technische Identitäten und Secrets erfassen | IT / Entwicklung / System-Owner | Offen |
| Reviewturnusse risikobasiert freigeben | IT / Information Owner / ISMS | Offen |
| Erstes vollständiges Berechtigungsreview durchführen | Information-/System-Owner | Offen |
| Leaver-, Break-Glass- und Recoverytests durchführen | Personal / IT / BCM | Offen |
| TISAX-Kapitel 4.1 und 4.2 kontrollfragenbezogen bewerten | TISAX / IT / Personal | Offen |
| Prüffrage | Status Entwurf |
|---|---|
| Sind alle Identitätsquellen und Kontenbestände bekannt? | Nein |
| Sind Rollen, Owner und Genehmigungen vollständig? | Nein |
| Funktioniert Joiner-Mover-Leaver nachweisbar? | Nicht geprüft |
| Werden alte Rechte bei Rollenwechsel entfernt? | Nicht geprüft |
| Werden Austritte rechtzeitig und vollständig gesperrt? | Nicht geprüft |
| Ist MFA für alle relevanten Zugriffe technisch erzwungen? | Nicht nachgewiesen |
| Sind privilegierte Rechte getrennt, begrenzt und überwacht? | Nicht nachgewiesen |
| Sind externe Zugriffe benannt, befristet und protokolliert? | Nicht nachgewiesen |
| Sind technische Identitäten und Secrets gesteuert? | Nicht nachgewiesen |
| Sind Funktionstrennung und kritische Kombinationen geprüft? | Nein |
| Wurden Berechtigungsreviews vollständig durchgeführt? | Nein |
| Sind Notfall- und Recoveryzugänge getestet? | Nein |
| Sind alle vier Kontrollfragen aus Kapitel 4.1/4.2 bewertet? | Nein; 0 von 4 |
| Sind die zugehörigen 46 Informationssicherheitsfragen vollständig berücksichtigt? | Ja als Sollumfang; 0 von 46 bewertet |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Regelung für Identitäten, Authentisierung, MFA, privilegierte Rechte, Fernzugriffe, Reviews und Nachweise angelegt | IT-Leitung / ISMS | Ausstehend | – |
| Funktion | Name | Entscheidung | Datum |
|---|---|---|---|
| Geschäftsführung | – | Ausstehend | – |
| IT-Leitung | – | Fachliche Prüfung ausstehend | – |
| ISMS-Beauftragte/r | – | Sicherheitsprüfung ausstehend | – |
| Personalwesen/Datenschutz | – | Schnittstellenprüfung ausstehend | – |
Maßgeblich bleiben die lizenzierten Normtexte, die offizielle ISA-Arbeitsmappe, der bestätigte Assessment Scope sowie die freigegebenen Rechts-, Vertrags-, Kunden- und Unternehmensanforderungen.