Zusammenfassung

  • ICANNs Ausschreibung vom 5. August sucht eine integrierte SaaS-Lösung für Richtlinien, Unternehmens- und Drittparteirisiken, interne Revision, Compliance, Dashboards und automatisierte Nachweiserhebung. Angebote sind bis 11. September fällig; ein Anbieter, Vertrag oder Betrieb steht nicht fest.
  • Die zentrale Akte muss Risikoinhaber, Kontrollbetreiber, Nachweiserheber, Prüfer, Abhilfeverantwortliche und Aufsicht unterscheiden. Eine portable Konkordanz könnte jeden Status mit Rolle, Befugnisgrundlage, Herkunft, Widerspruch und Berichtigung verbinden.

Ein Dashboard darf den Status eines Risikos anzeigen. Es darf ihn nicht kraft eigener Autorität festlegen.

Genau diese Grenze steckt in ICANNs Ausschreibung für eine Governance-, Risiko- und Compliance-Plattform. Die Unterlagen vom 5. August beschreiben einen weltweit verfügbaren gehosteten Dienst, der Richtlinien, Risikoregister, Drittparteiprüfungen, interne Revision, Compliance-Zuordnungen, Berichte und automatisierte Nachweise in einer Umgebung zusammenführt. ICANN beschreibt die heutige Arbeit als über mehrere Funktionen verteilt, weitgehend manuell und in getrennten Dokumentablagen organisiert. Das begrenze Effizienz, Quersicht und Konsistenz und erhöhe Risiken der Dokument- und Versionsverwaltung.

Eine gemeinsame Akte hat erkennbaren Nutzen. Derselbe Kontrollpunkt braucht nicht drei Namen in drei Tabellen. Ein Revisionsbefund verliert beim Wechsel in die Fachabteilung nicht den Bezug zur Abhilfe. Die Freigabe einer Richtlinie hängt nicht von einer zufällig geöffneten Fassung ab. Verteilte Teams verwenden gleiche Kennungen.

Die zweite Wirkung ist weniger offensichtlich. „Akzeptiert“, „wirksam“, „behoben“ oder „innerhalb des Risikoappetits“ sind keine rein technischen Werte. Es sind Schlussfolgerungen eines zuständigen Menschen oder Gremiums für einen bestimmten Umfang und Zeitraum, gestützt auf Nachweise, die Lücken oder Gegenargumente haben können. Die Software führt Buch über den Akt. Sie erhält dadurch nicht die Befugnis, ihn vorzunehmen.

Die Ausschreibung ist noch kein Ergebnis

Der öffentliche Überblick nennt einen breiten Umfang. Das Richtlinienmanagement soll Erstellung, Prüfung, Freigabe, Veröffentlichung und automatisierte Abläufe umfassen. Das Risikomanagement soll an COSO und ISO 31000 ausgerichtet sein und zentrale Register für dezentrale Teams bereitstellen. Drittparteirisiken umfassen Bewertung, Überwachung und Dokumentation. Die interne Revision erhält Funktionen für Planung, Durchführung, Befunde, Abhilfeverfolgung und Berichte. Compliance soll ISO/IEC 27001, SOC 2, SOC 3 und Datenschutzanforderungen abbilden.

Integrationen können, soweit angemessen, Kontrollen fortlaufend beobachten und Nachweise erheben.

Zu den übergeordneten Anforderungen gehören ein vollständig gehosteter globaler SaaS-Dienst, eine ISO-27001-zertifizierte Umgebung, hohe Verfügbarkeit, rollenbasierte Berechtigungen, Prüfpfade, APIs, Einführung, Support und Schulung. Bewertet werden unter anderem Funktionsumfang, Automatisierung, Reporting, Benutzbarkeit, Support, Finanzkraft, Preis, Referenzen und der Umgang mit Interessenkonflikten.

Das sind Auswahlkriterien, keine erreichten Zustände. Angebote müssen bis 11. September um 23:59 UTC eingereicht werden. Die Bewertung ist vom 14. September bis 13. November geplant; Due Diligence, Vertrag und eine mögliche Vergabe folgen ab 16. November. ICANN kann den Zeitplan ändern, Angebote ablehnen, das Verfahren zurückziehen oder nichts vergeben. Die geprüften Quellen nennen keinen Gewinner und keinen produktiven Dienst.

Der öffentliche Überblick ist zudem nicht die vollständige RFP. Zusätzliche Unterlagen liegen im Beschaffungssystem SciQuest/Jaggaer. Portabilität, Ausstiegshilfe, Dateninhaberschaft, Aufbewahrung, Vorfallbehandlung und Nachweislinie sind deshalb berechtigte Prüffragen. Aus ihrem Fehlen im Überblick folgt nicht, dass sie auch in geschützten Unterlagen, Angeboten oder einem künftigen Vertrag fehlen.

Die Befugnisordnung besteht schon vor dem Produkt

ICANNs Überblick zum Risikomanagement vom Oktober 2022 ordnet alle Organisationsrisiken dem President and CEO zu, der die funktionale Verantwortung an die zuständige Führungskraft delegiert. Die Risk-Management-Funktion ermöglicht den Rahmen, besitzt die Risiken aber nicht. Fachfunktionen tragen die Verantwortung nahe an der risikoverursachenden Tätigkeit. Das Führungsgremium prüft Berichte und Maßnahmen; Board und Risk Committee beaufsichtigen Rahmen und akzeptiertes Risikoniveau.

Das Dokument beschreibt 2022 und beweist nicht, dass jedes Detail unverändert blieb. Die am 20. Juli 2026 genehmigte aktuelle Satzung des Board Risk Committee bestätigt jedoch die heutigen Hauptflächen: Aufsicht über Identifikation, Bewertung, Priorisierung, Minderung, Risikoappetit und Toleranzen. In der internen Revision genehmigt das Komitee Umfang, Pläne und Budget, prüft die Unabhängigkeit externer Anbieter, erhält Befunde und Berichte zum Stand von Korrekturmaßnahmen des Managements.

Das Protokoll vom Februar 2025 hielt die Trennung damals besonders klar fest: Das Komitee beaufsichtigte Planung, Durchführung und Ergebnisse der Revision; das Management blieb für Abhilfemaßnahmen verantwortlich.

Diese Rollen dürfen nicht zu einem allgemeinen „Benutzer“ verschmelzen. Den Prozess zu verwalten heißt nicht, das Risiko zu besitzen. Eine Kontrolle zu prüfen heißt nicht, sie zu betreiben. Abhilfe zu beaufsichtigen heißt nicht, sie auszuführen. Eine Aufgabe zu schließen beseitigt nicht automatisch das ursprüngliche Prüfungsurteil.

Automatisierter Nachweis braucht weiterhin eine Aussage

Automatische Erhebung kann manuelle Bildschirmfotos und kopierte Exporte verbessern. Sie kann Quelle, Zeitpunkt, Umfang und Wiederholung zuverlässiger halten. Anbindungen an Identitätsverwaltung, Tickets oder Cloud-Infrastruktur schaffen einen konsistenteren Verlauf.

Doch ein Nachweis belegt immer eine bestimmte Aussage. Eine Liste deaktivierter Konten kann einen Entzug von Zugängen stützen, nicht die ordnungsgemäße Genehmigung aller verbleibenden Privilegien. Ein Konfigurationswert zeigt eine Einstellung, nicht zwingend alle Ausnahmen. Ein geschlossenes Ticket belegt Tätigkeit, nicht die Wirksamkeit der Abhilfe. Ein aktuelles Dashboard kann auf einer alten Risikoannahme beruhen.

Erforderlich sind daher Aussage, Population, Zeitraum, Quelle, Abfrage oder Transformation, Ausnahmen und zuständige Prüfung. Kontinuierliche Erhebung erhöht die Frequenz. Relevanz und Urteil erzeugt sie nicht.

Jeder Status braucht eine Befugnis-Nachweis-Konkordanz

Die Lösung ist kein öffentliches Register sensibler Risiken. Sie ist eine geschützte Verbindung zwischen Status und legitimierendem Akt.

Jedes wesentliche Risiko, jede Kontrolle, Ausnahme, Prüfungsfeststellung oder Abhilfe sollte eine stabile Kennung, zuständige Funktion und Rolle haben. Die Akte unterscheidet Eigentümerschaft, Bewertung, Genehmigung, Akzeptanz, Prüfung, Widerspruch, Aufsicht und Abhilfe. Sie verweist auf Richtlinie, Risikoappetit, Prüfplan oder Entscheidung, aus der die Befugnis stammt.

Dieselbe Quittung hält Aussage, Umfang und Zeitraum sowie die Herkunft der Nachweise fest: Quellsystem, Erheber oder Abfrage, Transformation, Zeitstempel, Version, Abdeckung und Prüfer. Ausnahmen und widersprechendes Material bleiben verbunden. Jede Änderung nennt handelnde Rolle, Zeitpunkt, Grund sowie spätere Einwände und Berichtigungen.

Auch privilegierte Anbieterzugriffe, Konfigurationsänderungen und Transformationen gehören in die Historie. Beim Ausstieg muss ein Export Kennungen, Beziehungen, Entscheidungen und Korrekturen so erhalten, dass ein anderes System und unabhängige Prüfer sie verstehen. Eine Sammlung flacher PDFs ist nicht portabel, wenn die bedeutungstragenden Verknüpfungen fehlen.

Diese Konkordanz ist ein Vorschlag von Daniel Kade, keine veröffentlichte ICANN-Anforderung. Sie soll das Produkt bei Verwahrung und Ablauf stark und bei der Aneignung von Befugnissen bewusst schwach halten.

Die Ordnung offenlegen, nicht das Risiko

Rechenschaft verlangt nicht, Risikoregister, Schwachstellen, Arbeitspapiere, Rohbelege, Drittparteidetails, personenbezogene Daten, Rechtsrat oder sensible Abhilfe zu veröffentlichen. Eine verhältnismäßige öffentliche Ebene kann zeigen, ob die Befugniskarte genehmigt ist, Funktionen getrennt sind, interne Revision unabhängig widersprechen kann, Herkunft und Korrektur getestet wurden, privilegierte Zugriffe geprüft sind und ein echter Exportversuch gelang.

Überfällige Abhilfen lassen sich aggregiert an das zuständige Aufsichtsgremium melden. Der öffentliche Kernnachweis lautet: Kein Softwarestatus ersetzt stillschweigend eine verantwortliche Entscheidung.

Zentralisierung nützt, wenn sie Fakten verbindet. Sie schadet, wenn sie bewusst getrennte Rollen zusammenlegt. Der dauerhafte Test ist, ob nach Einführung oder Ausstieg noch feststeht: Wer war befugt, was wurde entschieden, welche Nachweise trugen die Entscheidung und wer durfte widersprechen oder berichtigen? Bleiben die Antworten außerhalb des Dashboards erhalten, dient die Plattform der Governance. Leben sie nur im aktuellen Bildschirmzustand, beginnt der Buchhalter die Verfassung zu schreiben.

Quellen

  1. ICANN — Ankündigung der GRC-Lösungsausschreibung, 5. August 2026
  2. ICANN — Projektüberblick zur Ausschreibung der Governance-, Risk- und Compliance-Lösung
  3. ICANN — Überblick zum organisatorischen Risikomanagement, Oktober 2022
  4. ICANN — am 20. Juli 2026 genehmigte Satzung des Board Risk Committee
  5. ICANN — Board-Beschluss zur überarbeiteten Risk-Committee-Satzung, 20. Juli 2026
  6. ICANN — Protokoll des Board Risk Committee, 10. Februar 2025