A-R-C Consulting

ISMS & Audit Readiness

ISO 27001 nach der Transition: Von umgestellten Dokumenten zu Audit Readiness

Die Übergangsfrist ist vorbei. IAF MD 26 setzte den 31. Oktober 2025 als spätesten Termin für die Transition zertifizierter Kunden auf ISO/IEC 27001:2022. Viele Organisationen haben Dokumente angepasst, Controls neu zugeordnet und das Zertifikat aktualisiert. Damit ist die Versionsfrage abgeschlossen. Die Betriebsfrage ist es nicht.

Von Andreas Rühl · 1. August 2026 · Quellen geprüft am 2. August 2026

Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.

Sie lautet: Belegt der laufende Betrieb, dass Risikoanalyse, Risikobehandlung, Statement of Applicability, Controls, interne Audits und Managementbewertung tatsächlich dieselbe Geschichte erzählen? Eine umgestellte Richtlinie kann fachlich richtig sein und trotzdem keine Auskunft darüber geben, ob ein Zugriffsreview termingerecht stattgefunden hat, ob eine Abweichung bewertet wurde oder ob das Management aus einer erkannten Schwäche eine Entscheidung abgeleitet hat.

Post-Transition Audit Readiness ist deshalb kein zweites Migrationsprojekt. Sie ist die Fähigkeit, zu einer Managemententscheidung den Risikokontext, die umgesetzte Maßnahme und belastbare Evidenz für den relevanten Zeitraum nachvollziehbar zu verbinden. Wer nur Begriffe und Control-Nummern ersetzt hat, besitzt möglicherweise eine saubere Fassade. Für ein Managementsystem ist das ungefähr so nützlich wie ein frisch beschrifteter Sicherungskasten ohne Kenntnis darüber, welcher Stromkreis tatsächlich funktioniert.

Das gefährliche Signal lautet „Transition abgeschlossen“

Ein Projektstatus kann geschlossen sein, obwohl das ISMS offene Annahmen weiterträgt. Das geschieht selten aus Nachlässigkeit allein. Die Transition wurde häufig als begrenztes Vorhaben organisiert: Normvergleich erstellen, SoA anpassen, Dokumente aktualisieren, Audit bestehen. Der Regelbetrieb folgt jedoch anderen Takten. Lieferanten wechseln, Cloud-Dienste werden erweitert, Rollen verschieben sich, Geschäftsprozesse verändern ihre Abhängigkeiten. Wenn diese Ereignisse nicht zuverlässig in Risikobeurteilung und Steuerung ankommen, altert die überarbeitete Dokumentation vom ersten Tag an.

Ein typischer Bruch entsteht, wenn die Risikobehandlung aktualisiert wurde, die SoA Auswahl und Ausschlüsse aber nicht konsistent begründet. Ein anderer zeigt sich dort, wo neue oder zusammengeführte Controls zwar im Mapping stehen, Prozesse, Verantwortliche und Nachweise jedoch unverändert geblieben sind. Auch interne Audits können den falschen Schwerpunkt setzen: Sie bestätigen dann die Existenz eines Dokuments, prüfen aber weder das Design der Maßnahme noch ihre Umsetzung und ihren Betrieb im betrachteten Zeitraum. Kennzahlen wiederum sehen professionell aus, solange niemand fragt, bei welchem Wert wer welche Entscheidung treffen soll.

Ein Mapping mit vielen grünen Zellen kann erstaunlich beruhigend wirken. Leider akzeptiert ein Control keine Farbe als Wirksamkeitsnachweis; sonst wäre bedingte Formatierung eine Zertifizierungsstelle.

Vom Norm-Mapping zur Entscheidungskette

ISO/IEC 27001 ist ein Managementsystemstandard. Die offizielle ISO-Übersicht betont Aufbau, Umsetzung, Aufrechterhaltung und fortlaufende Verbesserung des ISMS. Nach der Transition kommt es daher weniger auf ein weiteres flächiges Norm-Mapping an als auf die Konsistenz mehrerer miteinander verbundener Entscheidungen.

Kontext, Risiko und Entscheidung

Änderungen bei Geschäftszielen, interessierten Parteien, regulatorischen Anforderungen, Technologien und extern bereitgestellten Leistungen brauchen einen Weg in die Risikobeurteilung. Nicht jede Änderung erzeugt ein neues Top-Risiko. Jede materielle Änderung braucht aber eine nachvollziehbare Entscheidung: bewertet und nicht relevant, zur Behandlung angenommen oder eskaliert.

Der Mechanismus beginnt nicht im Risikoregister, sondern an den Stellen, an denen Änderungen entstehen. Ein Architekturboard genehmigt einen neuen Cloud-Dienst. Der Einkauf verlängert einen kritischen Vertrag. Ein Fachbereich verlagert einen Prozess. Audit Readiness hängt daran, ob solche Ereignisse einen definierten Übergabepunkt zum ISMS besitzen. Ohne diesen Übergabepunkt kann das Risikoregister formal aktuell sein und operativ trotzdem hinterherlaufen.

Ein hypothetisches Beispiel: Ein Unternehmen verlagert einen kundenkritischen Dienst auf eine neue Plattform. Das Projekt dokumentiert Funktion, Kosten und Termin, bewertet aber die geänderten Abhängigkeiten nicht im ISMS. Monate später enthält die Managementbewertung weiterhin die alte Verfügbarkeitsannahme. Das Problem ist nicht bloß ein fehlender Eintrag. Eine überholte Annahme beeinflusst Risikobewertung, Behandlung, Tests und Eskalationsschwellen. Wird sie spät erkannt, müssen mehrere Entscheidungen rückwärts geprüft werden.

Risiko, Behandlung und SoA

Die SoA ist keine dekorative Kontrollliste. Sie muss zur gewählten Risikobehandlung passen und nachvollziehbar machen, welche Controls notwendig sind und wie mit dem Referenzset abgeglichen wurde. IAF MD 26 hebt diesen Vergleich und die mögliche Aktualisierung von Risikobehandlungsplänen hervor, wenn notwendige Controls versehentlich ausgelassen wurden.

Praktisch bedeutet das: Eine SoA-Entscheidung braucht mehr als „anwendbar“ oder „nicht anwendbar“. Erkennbar sein sollten der Bezug zur Behandlung, der verantwortliche Prozess und der reale Umsetzungsstand. Ändert sich das Risiko, muss geprüft werden, ob Behandlung und Control-Entscheidung noch tragen. Ändert sich ein Control, ist umgekehrt zu prüfen, welche Risikobehandlung davon abhängt. Diese Rückkopplung verhindert, dass SoA und Risikoregister zwei getrennte Wahrheiten entwickeln.

Control, Betrieb und Nachweis

Eine Richtlinie belegt eine Erwartung, kein wiederholtes Verhalten. Für jedes wesentliche Control sollte klar sein, welches Betriebsereignis Evidenz erzeugt, wer sie prüft, welcher Zeitraum abgedeckt ist und welche Abweichung eine Maßnahme auslöst. Beispiele reichen von Zugriffsreviews und Restore-Tests bis zur Lieferantenüberwachung und Behandlung von Sicherheitsereignissen.

Die entscheidende Unterscheidung liegt zwischen Artefakt und Aussage. Eine exportierte Benutzerliste zeigt Konten. Sie zeigt nicht automatisch, dass fachlich Verantwortliche Berechtigungen geprüft, Abweichungen bewertet und unzulässige Rechte entfernt haben. Ein Restore-Protokoll kann zeigen, dass ein Vorgang gestartet wurde. Ob das Ergebnis das festgelegte Prozessziel erfüllt, ergibt sich erst aus Prüfkriterium und Bewertung.

In einer hypothetischen Betriebsszene erhält ein Control Owner am Quartalsende eine Benutzerliste. Er bestätigt den Review mit einem Häkchen, weil alle Namen plausibel wirken. Zwei Monate später stellt sich heraus, dass ein technisch privilegiertes Konto keinem aktiven Owner mehr zugeordnet war. Die Liste war vorhanden, der Review ebenfalls. Was fehlte, war ein Kriterium für verwaiste privilegierte Konten und eine dokumentierte Behandlung des Treffers. Das ist der Unterschied zwischen Aktivitätsnachweis und Kontrollnachweis.

Abweichung, Ursache und Verbesserung

Feststellungen, Vorfälle, Kennzahlabweichungen und nicht erreichte Ziele müssen in einen kontrollierten Verbesserungsprozess laufen. Entscheidend ist nicht, ob jede Abweichung sofort verschwindet. Entscheidend ist, ob Ursache, Risiko, Owner, Termin, Wirksamkeitsprüfung und Eskalation zusammenpassen.

Eine Maßnahme „Schulung wiederholen“ kann angemessen sein, wenn fehlendes Wissen die Ursache war. Sie ist schwach, wenn ein unklarer Prozess, eine ungeeignete Rollenverteilung oder ein technischer Engpass das Verhalten erzeugt hat. Post-Transition Readiness verlangt daher nicht möglichst viele geschlossene Tickets, sondern nachvollziehbare Ursachenentscheidungen. Ein Ticketstatus ist schließlich ein Verwaltungszustand, keine Naturkonstante.

Audit Readiness ist ein Zeitreihenproblem

Auditoren sehen nicht nur den heutigen Zustand. Sie prüfen, ob das System im betrachteten Zeitraum betrieben wurde. Ein im Juli nachträglich vervollständigtes Protokoll heilt keinen im Februar ausgefallenen Review. Deshalb sollte Evidenz nicht kurz vor dem Audit eingesammelt, sondern an den operativen Takt gekoppelt werden.

Ein schlankes Evidence Register kann Control und Prozessziel, verantwortliche Rolle, erwartetes Artefakt oder Systemsignal, Frequenz, betrachteten Zeitraum, Ablageort, Prüfkriterium, Ergebnis und gegebenenfalls Abweichung mit Freigabe verbinden. Es muss kein neues Großsystem sein. Entscheidend ist, dass die Verknüpfung eindeutig, zugänglich und wiederholbar ist.

Der Nutzen liegt nicht in zusätzlicher Dokumentation, sondern in früher Sichtbarkeit. Wenn ein monatlicher Nachweis ausbleibt, wird das im Monat erkannt und nicht erst bei der Auditvorbereitung. Wenn die Evidenz zwar vorliegt, aber das Prüfergebnis fehlt, kann der Owner nachsteuern. Wenn eine Abweichung wiederholt auftritt, wird sichtbar, dass die bisherige Maßnahme nicht wirksam genug war.

Auch die Aufbewahrung braucht einen fachlichen Bezug. Nicht jedes Log und jeder Export muss unbegrenzt gesammelt werden. Der relevante Zeitraum, der Zweck des Nachweises, Zugriff und Integrität sollten zur Control- und Auditlogik passen. Eine wahllose Beweissammlung erhöht vor allem Suchaufwand. Ein Auditor, der drei Stunden lang auf einen Download wartet, hat dadurch noch keine zusätzliche Sicherheit gewonnen.

Das Klima-Amendment nüchtern einordnen

ISO verweist auf ISO/IEC 27001:2022/Amd 1:2024 als Climate-action amendment. Die Ergänzung ist in Kontext und Anforderungen interessierter Parteien einzuordnen. Organisationen sollten nachvollziehbar prüfen, ob Klimawandel für ihren ISMS-Kontext relevant ist und ob interessierte Parteien klimabezogene Anforderungen haben.

Daraus folgt weder automatisch ein separates Klimarisikoregister noch eine pauschale Pflicht, jedes Wetterereignis als Informationssicherheitsrisiko zu behandeln. Relevant können beispielsweise Standortabhängigkeiten, Kühlung, Energieversorgung, Lieferketten, Verfügbarkeit oder Kundenanforderungen sein. Wenn die Prüfung keine materielle Relevanz ergibt, braucht auch diese Entscheidung eine nachvollziehbare Begründung. Das Amendment ist ein Kontextsignal, kein Auftrag zu Klimatheater im ISMS.

Der sinnvolle Prüfweg bleibt derselbe wie bei anderen Kontextfaktoren: mögliche Relevanz erfassen, Auswirkungen auf Scope und Risiken bewerten, Anforderungen interessierter Parteien berücksichtigen und eine Entscheidung dokumentieren. Falls daraus eine Behandlung folgt, muss sie in Controls, Betrieb und Evidenz ankommen. Falls nicht, sollte die Begründung erkennen lassen, welche Abhängigkeiten betrachtet wurden. Ein pauschales „nicht relevant“ spart heute zwei Zeilen und erzeugt morgen fünf Rückfragen.

Ein fokussierter Post-Transition-Review

Statt erneut jede Normanforderung einzeln durchzugehen, empfiehlt sich ein stichprobenbasierter Vertical Slice. Dafür werden drei bis fünf wesentliche Risiken oder Geschäftsservices ausgewählt. Jeder Pfad wird vom relevanten Kontext über Risikobewertung und Freigabe zur Behandlung und SoA-Entscheidung verfolgt. Danach wird geprüft, welche Controls tatsächlich laufen, welche Evidenz welchen Zeitraum deckt und was Kennzahlen, interne Audits oder Vorfälle über die Wirksamkeit sagen. Am Ende steht die Frage, welche Information die Managementbewertung erreicht hat und welche Entscheidung daraus folgte.

Ein hypothetischer Slice könnte bei einem kritischen Lieferanten beginnen. Die Organisation prüft, warum der Dienst als wesentlich gilt, welche Abhängigkeit im Risiko beschrieben ist und welche Behandlung beschlossen wurde. Anschließend werden Lieferantenreview, verfügbare Nachweise, festgestellte Abweichungen und Eskalationen betrachtet. Zeigt sich, dass eine wiederholt verspätete Bewertung nie in der Managementbewertung auftauchte, liegt der Bruch nicht nur beim Lieferantenprozess. Die Informationskette zum Management ist unvollständig.

Der Vertical Slice ist wirksamer als eine weitere breite Dokumentensichtung, weil er Übergaben testet. Genau an diesen Übergaben entstehen die meisten Inkonsistenzen: zwischen Änderung und Risiko, Risiko und SoA, Control und Evidenz oder Abweichung und Entscheidung. Das Verfahren zeigt damit nicht nur, ob die Organisation auditfähig aussieht, sondern ob das ISMS Managemententscheidungen unterstützt.

Die Stichprobe sollte bewusst auch einen unbequemen Pfad enthalten: eine verspätete Maßnahme, eine wiederkehrende Abweichung oder ein Control mit lückenhafter Evidenz. Ein ausschließlich aus Vorzeigefällen zusammengesetzter Review bestätigt vor allem die Auswahlkunst des Prüfteams. Der schwierigere Fall zeigt dagegen, ob das System Unsicherheit sichtbar hält, eine autorisierte Entscheidung erzwingt und die Wirksamkeit der Folgemaßnahme später erneut prüft.

Damit erhält das Management keine künstliche Vollständigkeitsbehauptung, sondern eine belastbare Aussage über den Steuerungsmechanismus. Wiederholt sich derselbe Bruch in mehreren Stichproben, spricht das für ein systemisches Problem an der Übergabe und nicht für drei unabhängige Einzelfehler. Dann gehört die Entscheidung nicht allein zum jeweiligen Control Owner. Sie betrifft Prozessdesign, Ressourcen, Eskalationsweg oder die Qualität der Managementinformation. Genau diese Übersetzung von Einzelfund zu Systementscheidung unterscheidet Audit Readiness von einer kurzfristig aufgeräumten Dokumentenablage.

Was das Management vor dem nächsten Auditzyklus entscheiden sollte

Vor dem nächsten Audit sollte das Management nicht um eine pauschale Bestätigung der „Readiness“ bitten. Sinnvoller ist ein begrenztes Entscheidungsbild. Sind alte Referenzen kontrolliert aus operativen Vorlagen entfernt? Stimmen Risikobehandlung, SoA, Control-Owner und tatsächliche Prozesse für die wesentlichen Pfade überein? Gibt es zeitbezogene Evidenz mit Prüfergebnis statt bloßer Artefaktsammlung? Prüft das interne Audit risikobasiert auch Umsetzung und Betrieb?

Ebenso wichtig ist der Umgang mit Veränderung. Änderungen an Services, Lieferanten und Technologie sollten geplant in das ISMS überführt werden. Klima-Relevanz und klimabezogene Anforderungen interessierter Parteien müssen sachlich bewertet und begründet sein. Die Managementbewertung sollte offene Abweichungen, Restunsicherheit und entscheidungsfähige Optionen zeigen. Überfällige Maßnahmen brauchen klare Eskalationsschwellen.

Damit wird aus einer Checkliste ein Steuerungsauftrag. Das Management entscheidet nicht über jede einzelne Evidenzdatei. Es entscheidet über Priorität, Risikoakzeptanz, Ressourcen, Eskalation und die Wirksamkeit des Systems. Gute Audit Readiness reduziert diese Verantwortung nicht; sie macht sie sichtbar und rechtzeitig bearbeitbar.

Fazit und A-R-C-Impuls

Nach dem 31. Oktober 2025 ist die Versionsfrage abgeschlossen. Die Betriebsfrage bleibt: Kann die Organisation zeigen, dass ihr ISMS über Zeit konsistent entscheidet, steuert, prüft und verbessert?

A-R-C macht Informationssicherheit steuerbar, prüfbar und managementfähig. Ein Post-Transition Audit Readiness Review verbindet ausgewählte Risiken mit SoA, Controls, Evidenz, internem Audit und Managementbewertung. Das Ergebnis ist kein Zertifizierungsversprechen, sondern ein priorisiertes Bild der Brüche, die vor dem nächsten Audit oder Managementtermin geschlossen werden sollten.

Abgrenzung

Dieser Beitrag reproduziert keine Normtexte und ersetzt weder die lizenzierte Norm noch Beratung durch Zertifizierungsstelle, Rechtsberatung oder unabhängige Prüfung. Er gibt keine Zertifizierungs- oder Auditgarantie. Auditkriterien, Stichproben und Feststellungen hängen vom konkreten Scope und der zuständigen Zertifizierungsstelle ab.

Primärquellen

Über den Autor

Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.

Passende A-R-C-Leistung: ISO-27001-Beratung