Schritt-für-Schritt-Anleitung zu Ihrem ersten ISO 27001:2022 Überwachungsaudit für Identity Management

Ihr erstes Überwachungsaudit nach ISO 27001:2022 ist der Zeitpunkt, an dem Auditoren nicht mehr nur Ihre "Transition-Pläne" akzeptieren, sondern überprüfen, ob Ihr Identity Management im täglichen Betrieb wirklich funktioniert.

Bis 2026 wird das regulatorische Umfeld noch deutlich strenger. NIS2 gilt EU-weit, DORA reguliert Finanzunternehmen, und Compliance verschiebt sich von "Dokumentation zeigen" hin zu belastbaren Nachweisen. Manuelles Access Management und reine SSO-Setups reichen nicht mehr aus - sie tauchen als Findings im Auditbericht auf.

In diesem Leitfaden erfahren Sie:

• Was sich in ISO 27001:2022 für Identity und Access geändert hat
• Wie Überwachungsaudits in Ihren dreijährigen ISO-Zyklus passen
• Wie Sie Identity Lifecycle Management - inklusive non-human identities - vorbereiten
• Wie Sie Audit-Evidenz aufbauen, die externe Auditoren und Aufsichtsbehörden heute erwarten
• Wo Automatisierung und Plattformen wie Iden aus einem jährlichen "Audit-Feuerwehr-Einsatz" wiederholbare, stressarme Audits machen

Bevor Sie starten: Voraussetzungen für ein reibungsloses Überwachungsaudit

Bevor Sie Checklisten und Tools angehen, sollten diese Grundlagen stehen:

• Transition abgeschlossen
  ISO/IEC 27001 wurde 2022 überarbeitet und hat die Ausgabe von 2013 als aktuelle Version der Norm abgelöst
  Organisationen, die nach ISO 27001:2013 zertifiziert waren, mussten ihre Zertifikate bis zum 31. Oktober 2025 auf ISO 27001:2022 überführen; Zertifikate, die bis dahin nicht umgestellt wurden, sind erloschen
  Ihre Statement of Applicability (SoA) sollte den neuen Controls-Stand von 2022 widerspiegeln.

• Klarer Identity Scope
  Dokumentieren Sie die Geschäftsbereiche, Standorte und Systeme, die im Scope Ihres ISMS liegen - und damit auch für Annex A 5.16 (identity management) und 5.17 (authentication information).

• Definierte Sources of Truth
  HRIS für Personaldaten, Directory/IdP (z. B. Okta/Entra) für Accounts, CMDB oder Cloud-Inventar für Infrastruktur - jeweils mit eindeutig verantwortlicher Rolle.

• Dokumentierte Joiner-Mover-Leaver-(JML)-Prozesse
  Auch teilweise manuelle Abläufe benötigen dokumentierte Verfahren, die zeigen, wie Identities erstellt, geändert und entfernt werden.

• Non-human identities im Blick
  Service Accounts, SaaS Bots, API Keys, CI/CD User, RPA Bots und Machine Identities müssen inventarisiert werden - und dürfen nicht als "IT-Magie" im Hintergrund laufen.

• Ein gewisser Grad an Zentralisierung
  Wenn Sie Zugriffe per E-Mail und Excel verwalten, können Sie das Audit eventuell noch bestehen - müssen aber mit mehr Findings rechnen. Eine IGA-Plattform wie Iden ermöglicht es, Policies, Workflows und Audit Trails über alle human und non-human identities hinweg zu zentralisieren.

Schritt 1: Ihr Überwachungsaudit im regulatorischen Kontext 2026 neu einordnen

Auditoren prüfen heute, wie Ihr ISMS gegenüber realen regulatorischen Anforderungen besteht - nicht nur gegenüber dem ISO-Normtext.

Warum 2026 anders ist

• ISO 27001 Zertifizierungen laufen typischerweise in dreijährigen Zyklen mit jährlichen Überwachungsaudits in Jahr eins und zwei und einem Rezertifizierungsaudit in Jahr drei
  Wenn Sie 2024-2025 zertifiziert oder auf 2022 umgestellt haben, ist Ihr Audit 2026 das erste, das vollständig auf dem neuen Control-Set basiert.

• NIS2 musste von den EU-Mitgliedstaaten bis zum 17. Oktober 2024 in nationales Recht überführt und ab dem 18. Oktober 2024 angewendet werden
  Viele Technologie-, Finanz- und Professional-Services-Unternehmen in der EU gelten nun als "essential" oder "important".

• Unter NIS2 drohen essential entities bei schwerwiegender Non-Compliance Geldbußen von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes - je nachdem, welcher Betrag höher ist
  Die Risiken laxen Access Managements waren noch nie größer.

• Der Digital Operational Resilience Act (DORA) der EU gilt seit dem 17. Januar 2025 für in Scope befindliche Finanzunternehmen und ihre ICT-Dienstleister und bringt harmonisierte Anforderungen an ICT Risk Management und Incident Response mit sich
  Identity und Access Control stehen im Zentrum dieser Anforderungen.

Ihr Auditor kennt diesen Kontext genau. Rechnen Sie mit Fragen wie:

• "Zeigen Sie Evidenz, dass alle Access-Änderungen einer Identity und einer Freigabe zugeordnet sind."
• "Wie stellen Sie sicher, dass non-human identities regelmäßig überprüft und bei Nichtbedarf entzogen werden?"
• "Wie verifizieren Sie, dass SSO-Gruppen aktuellen Rollenprofilen entsprechen - und nicht veralteten Setups?"

Tipp
Positionieren Sie das Audit gegenüber dem Management als Teil Ihrer NIS2-, DORA-, HIPAA- oder CMMC-Readiness - nicht nur als "ISO-Thema". ISO 27001 ist heute ein Anker für Ihre gesamte regulatorische Compliance.

Schritt 2: Verstehen, was sich in ISO 27001:2022 für Identity Management geändert hat

ISO 27001:2013 behandelte Access Control, aber die Revision 2022 hebt die Erwartungen an das Management von human und non-human identities deutlich an.

Annex A 5.16 - Identity management

Annex A 5.16 in ISO 27001:2022 verlangt von Organisationen, den vollständigen Lifecycle digitaler Identities so zu steuern, dass Zugriffe zurechenbar, autorisiert und nachvollziehbar sind - und stellt explizit klar, dass dies für human und non-human identities gilt

Auditoren achten insbesondere auf:

• Lifecycle-Abdeckung
  Prozesse für das Anlegen, Ändern, Sperren und Entfernen von Identities für alle Mitarbeitertypen und Systeme.

• One-person/one-identity-Prinzip
  Personalisierte Accounts statt Shared Logins; klare Owner für non-human identities.

• Risikobasierte Behandlung
  Strengere Prüfung privilegierter Accounts (Admins, Produktion, CI/CD, Cloud Control Planes).

Annex A 5.17 - Authentication information

5.17 regelt, wie Sie Passwörter, Keys, Tokens und andere Secrets verwalten. Auditoren verknüpfen dies mit Ihrem Identity Lifecycle:

• Werden Secrets rotiert, wenn sich eine Identity oder ein Access ändert?
• Werden API Keys und Service-Account-Credentials so gemanagt wie Benutzerpasswörter?

Häufiger Fehler
5.16 nur als weiteres Access-Control zu behandeln. Auditoren werden JML-Flows, non-human identities und Freigaben über mehrere Controls hinweg stichprobenartig prüfen - nicht nur Ihr SSO.

Schritt 3: Eine vollständige Identity-Inventur aufbauen (human und non-human)

Wirksame Steuerung beginnt mit Transparenz über alle Identities. Bauen Sie eine vollständige Inventur auf - und halten Sie diese kontinuierlich aktuell.

3.1 Start mit human identities

1. Daten aus HRIS und Directory ziehen
   Export aller aktuellen sowie kürzlich inaktiven Mitarbeitenden aus HRIS und IdP.

2. Identity Keys normalisieren
   Vergabe eines eindeutigen Identifikators (Mitarbeiter-ID oder HR-Nummer) über alle Systeme hinweg.

3. Zu Rollen und Bereichen zuordnen
   Perfektes RBAC ist nicht erforderlich - aber Sie müssen wissen, in welchem Team bzw. welcher Funktion jede Person arbeitet.

3.2 Non-human identities ergänzen

Non-human identities sind inzwischen eine der häufigsten Ursachen für Findings in ISO 27001:2022 Audits.

Inventarisieren Sie mindestens:

• Service Accounts (Datenbanken, Betriebssysteme, Backups)
• Application Accounts für Integrationen
• CI/CD User und Deployment Bots
• API Keys, die von externen Services genutzt werden
• SaaS Bots und Automatisierungen
• Machine Identities in der Infrastruktur (Container, VMs, IoT)

Für jede non-human identity sollten Sie erfassen:

• Zweck und zugehöriges System
• Business Owner (nicht nur "IT")
• Technischer Owner
• Genutzte Daten und Zielsysteme
• Authentifizierungsmethode
• Prozesse für Erstellung, Rotation und Revocation

Tipp
Nutzen Sie bestehende Logs als Einstieg: Cloud IAM-Listings, IdP Service Principals, SaaS Admin-Konsolen etc. Iden kann Identities aus SSO, HRIS und über 175 SaaS-Apps konsolidieren - ohne dass Sie 30 verschiedene Admin-UIs durchsuchen müssen.

Schritt 4: Lifecycle-Prozesse entwerfen und dokumentieren, die Auditoren prüfen werden

Mit einer sauberen Inventur können Sie nun belegen, dass der Lifecycle jeder Identity kontrolliert abläuft.

4.1 Joiners - Access ab Tag eins

• Trigger: HR legt einen neuen Datensatz an bzw. aktualisiert ihn.
• Prozess:
  • Die Identity wird aus HR heraus im Directory/IdP provisioniert.
  • Basiszugriffe ("Birthright Access" wie E-Mail, Kollaboration, Ticketing) werden rollen- bzw. teambasiert vergeben.
  • Ausnahmen oder erhöhte Berechtigungen erfordern dokumentierte Freigaben.

Was Auditoren erwarten:

• Evidenz, dass Access der Policy entspricht
• Freigabenachweise für Ausnahmen
• Keine "Schatten-Accounts", die außerhalb dieses Prozesses angelegt werden

4.2 Movers - Rollen- und Teamwechsel

Bei Movers entstehen typischerweise Privilege Creep und Segregation-of-Duties-Probleme.

• Stellen Sie sicher, dass HR-Rollenänderungen automatisch Access Reviews auslösen.
• Definieren Sie Regeln, welche Berechtigungen bei Rollen- oder Abteilungswechsel entfernt werden.
• Dokumentieren Sie Freigaben für temporäre oder überlappende Zugriffe.

4.3 Leavers - Offboarding (inklusive non-human identities)

Sie müssen schnell beantworten können: "Was passiert, wenn jemand das Unternehmen verlässt?"

Mindestens:

• HR-Offboarding deaktiviert Accounts automatisch.
• Zugriffe auf zentrale Systeme werden entzogen oder übertragen.
• Non-human identities, die an diese Person gekoppelt sind, werden identifiziert und entzogen bzw. neu zugeordnet.

Häufiger Fehler
Davon auszugehen, dass "AD-Account deaktivieren" ausreicht. Auditoren wählen heute Einzelpersonen stichprobenartig aus und erwarten System-für-System-Nachweise, dass Zugriffe entzogen wurden - inklusive SaaS und weniger sichtbarer Anwendungen.

4.4 Dokumentieren - und dann, wo möglich, automatisieren

Dokumentieren Sie Ihre JML-Flows und automatisieren Sie anschließend:

• IGA/Identity Governance (Iden) für Policies, Workflows und Freigaben
• SSO/IdP für Account-Lifecycle
• HRIS als primären Trigger

Iden automatisiert policybasiertes Onboarding, Änderungen und Offboarding für alle Identities (auch für Apps ohne SCIM oder APIs) mit fein granularem Zugriff und voller Transparenz.

Schritt 5: Evidenzsammlung über Ihren gesamten Stack automatisieren

Manuelle Evidenz (Screenshots, Tabellen) ist nicht mehr zeitgemäß. Auditoren erwarten aktuelle, konsistente Nachweise.

5.1 Starke Evidenz definieren

Für Identity-Management-Controls benötigen Sie:

• Zentrale Logs (wer hat wann welche Berechtigung mit welcher Freigabe erhalten)
• Vollständige Übersichten über User und deren Zugriffe
• Historische Reports für Stichtagsprüfungen
• Automatisierte User Access Review (UAR)-Nachweise

5.2 Grenzen von SSO-only kennen

SSO ist heute Mindeststandard - aber kein vollumfänglicher Schutz:

• Viele Apps unterstützen SCIM nicht oder verlangen hohe Aufpreise.
• Fein granulare Berechtigungen (Channels, Repos, Projekte) werden nicht immer über den IdP gesteuert.
• Non-human bzw. lokale Accounts können SSO vollständig umgehen.

Iden schließt diese Lücken:

• Anbindung an jede App - mit oder ohne SCIM oder API
• Erfassung fein granulärer Berechtigungen (Workspace, Channel, Repo, Projekt)
• Automatisierte UARs und Evidenzsammlung

Iden automatisiert Provisionierung und Governance für mehr als 175 Apps, inklusive Long-Tail- und Non-SCIM-SaaS-Tools, mithilfe einer universellen Connector-Technologie

Kunden, die Iden einsetzen, verzeichnen typischerweise rund 80 % weniger manuelle Access Tickets und sparen etwa 120 Stunden pro Quartal bei User Access Reviews

Diese Zahlen sind kein "Nice-to-have", sondern ermöglichen echte Audit-Readiness statt jährlicher Ad-hoc-Krisen.

Tipp
Fragen Sie konsequent: "Wenn ein Auditor uns bittet, nachzuweisen, dass dies vor sechs Monaten passiert ist - welchen Log oder Report zeigen wir?" Ist die Antwort "eine Excel-Tabelle" oder "ein Postfach", besteht Handlungsbedarf.

Schritt 6: Ein internes "Überwachungsaudit" für Identities durchführen

Ein interner Review vor dem eigentlichen Audit macht aus großen Risiken kleine Hinweise - oder eliminiert Probleme vollständig.

6.1 Prägnante Identity-Checkliste erstellen

Auf Basis von Annex A 5.16/5.17 und Ihren Risiken:

• Gibt es eine aktuelle Inventur aller human und non-human identities im Scope?
• Können wir JML-Evidenz für aktuelle Joiners, Movers und Leavers zeigen?
• Sind privilegierte Accounts und Service Accounts namentlichen Ownern zugewiesen?
• Liegen aktuelle User Access Reviews für kritische Systeme vor?
• Werden Secrets (Passwörter, Keys, Tokens) gemäß Policy verwaltet?

6.2 Reale Fälle stichprobenartig prüfen

Wählen Sie echte, aktuelle Beispiele:

• Neueinstellungen (letzte 3-6 Monate)
• Rollen- oder Abteilungswechsel
• Austritte von Mitarbeitenden
• Kritische Service Accounts und Integrationen

Verfolgen Sie die Evidenzkette:

• HR-Datensatz -> IdP-Account -> App-Zugriffe -> Freigaben -> Offboarding-/Change-Logs

Mit Iden erhalten Sie einen zentralen Identity-Datensatz mit vollständiger Lifecycle- und Entitlement-Historie - inklusive Bots und Service Accounts.

Häufiger Fehler
Nur zu prüfen, ob Dokumentation existiert - und nicht, ob Prozesse tatsächlich gelebt werden. Auditoren schauen heute immer auf Letzteres.

Schritt 7: Den Tag des Überwachungsaudits meistern - und was danach kommt

7.1 Während des Audits

• Transparenz zeigen
  Wenn bestimmte Access Controls noch manuell laufen, sprechen Sie das offen an - und zeigen Sie Ihre Roadmap zur Automatisierung.

• Mit Evidenz führen
  Wenn gefragt wird "Wie managen Sie non-human identities?", zeigen Sie Ihre Inventur oder Ihr IGA-Dashboard - nicht nur Folien.

• Soft Findings ernst nehmen
  Kommentare wie "das wirkt fragil" sind Hinweise auf Verbesserungsbedarf - nutzen Sie sie aktiv, statt sie nur zu dokumentieren.

7.2 Nach dem Audit

• Findings klassifizieren

  • Sofortmaßnahmen (z. B. fehlende Revocation)
  • Prozessverbesserungen (z. B. bessere HR-Trigger)
  • Strukturelle Anpassungen (z. B. Einführung von IGA)

• Maßnahmen mit Ihrer Roadmap verzahnen
  Nutzen Sie die Findings, um den Schritt von manueller zu automatisierter Identity Governance über alle Apps hinweg zu begründen - nicht nur für die "einfachen" Anwendungen.

• Multi-Framework denken
  Automatisierte JML-Prozesse, gesteuerte non-human identities und UAR-Evidenz zahlen gleichzeitig auf ISO 27001, HIPAA, SOC 2, CMMC, NIS2 und DORA ein. Iden ist darauf ausgelegt, die zentrale Identity-Governance-Schicht zu sein, die Sie dafür benötigen.

Nächste Schritte: Ihr Überwachungsaudit als Identity-Upgrade nutzen

Für Heads of IT und CISOs in SaaS-lastigen Organisationen geht es beim ersten ISO 27001:2022 Überwachungsaudit darum, Identity Governance - über human und machine identities hinweg - skaliert und unter echter regulatorischer Prüfung nachzuweisen.

Konkrete Schritte:

• Nutzen Sie diesen Audit-Zyklus, um Ihre Identity-Inventur und JML-Prozesse zu baselinen.
• Priorisieren Sie Automatisierung dort, wo Auditrisko und Aufwand am höchsten sind: Offboarding, privilegierte Zugriffe, non-human identities und Access Reviews.
• Konsolidieren Sie Evidenz aus SSO, HRIS und Apps an einem zentralen, durchsuchbaren Ort - entweder intern oder mit der Unified Platform von Iden.

Richtig umgesetzt werden künftige Audits zur Routine - weil Ihre Identity Governance kontinuierlich läuft und nicht nur in der "Audit-Saison".

FAQ: ISO 27001:2022 Überwachungsaudits & Identity Management

1. Worin unterscheidet sich ein Überwachungsaudit von der initialen ISO 27001 Zertifizierung?

Das initiale Audit (Stage 1 + Stage 2) prüft Design und Implementierung Ihres ISMS im Detail. Überwachungsaudits sind jährliche Reviews, bei denen Controls stichprobenartig geprüft und die kontinuierliche Verbesserung bewertet wird.

In einem typischen ISO 27001 Programm ist die Zertifizierung drei Jahre gültig, mit jährlichen Überwachungsaudits in Jahr eins und zwei und einem vollständigen Rezertifizierungsaudit in Jahr drei

Für Identity Management können Sie erwarten, dass Auditoren echte JML-Fälle, das Management non-human identities und aktuelle Access Reviews testen - nicht nur dokumentierte Verfahren abfragen.

2. Welche Identity-Evidenz erwarten Auditoren unter ISO 27001:2022?

Häufig angeforderte Nachweise:

• Aktuelle Inventuren aller human und non-human identities
• Stichproben von JML-Workflows mit Zeitstempeln und Freigaben
• Logs oder Reports über Account-Lifecycle-Events in zentralen Systemen
• UAR-Entscheidungen und Nachweise zur Remediation
• Verfahren für das Management von Service Accounts und API Keys

Wenn Sie "Zeigen Sie mir"-Anfragen ohne hektische Suche in Tabellen beantworten können, sind Sie sehr gut aufgestellt.

3. Brauche ich eine vollwertige IGA-Plattform, um Annex A 5.16 zu erfüllen?

Nicht nach dem Wortlaut der Norm; gut gestaltete manuelle Prozesse sind grundsätzlich zulässig. Aber mit wachsendem SaaS-Footprint und vielen Non-SCIM-Tools werden manuelle JML-Prozesse und Excel-basierte Reviews:

• Personalintensiv
• Fehleranfällig (vergessenes Offboarding, Privilege Creep)
• Schwer konsistent nachweisbar

Deshalb setzen viele wachstumsstarke Organisationen auf Plattformen wie Iden: breite App-Abdeckung, policygetriebene Workflows, automatisierte Evidenz und keine Legacy-IGA-Komplexität.

4. Wie gehen wir mit non-human identities für ISO 27001:2022 um?

Behandeln Sie non-human identities als erstklassige Objekte in Ihrem ISMS:

• In die Risikobewertung und die SoA aufnehmen
• Für jede Identity Owner, Zweck und Lifecycle definieren
• Geeignete Authentifizierungs- und Rotationsrichtlinien anwenden
• Zugriffe regelmäßig überprüfen - insbesondere für Produktionsdaten oder kritische Systeme

Die Vernachlässigung non-human identities ist heute eine explizite Audit-Lücke.

5. Wie unterstützt Identity Management nach ISO 27001:2022 bei NIS2 und DORA?

NIS2 und DORA verlangen starke Access Controls, klare Verantwortlichkeiten und Nachweise, dass Sicherheitsmaßnahmen in der Praxis funktionieren. ISO 27001:2022 liefert dafür:

• Ein strukturiertes ISMS und risikobasierte Begründung Ihrer Identity Controls
• Dokumentierte JML- und non-human-identity-Prozesse
• Einen Rahmen, um diese Controls zu überwachen und kontinuierlich zu verbessern

Wenn automatisierte Identity Governance und Audit Trails diese Controls tragen, erreichen Sie die kontinuierliche, evidenzbasierte Sicherheitslage, die Aufsichtsbehörden heute verlangen.