Zusammenfassung

  • Am 6. September ermächtigte der ICANN-Vorstand den President and CEO oder dessen Beauftragte, mit dem bevorzugten Anbieter einen Vertrag über strategische Personalverstärkung für Engineering & IT zu schließen. Veröffentlicht wurde der Beschluss am 9. September.
  • ICANN nennt Softwareentwicklung, Qualitätssicherung, Content-Management und weitere technische Kompetenzen, skalierbare Kapazität sowie längere Abdeckung über Zeitzonen hinweg.
  • Nach ICANNs eigenen Delegationsrichtlinien lassen sich Befugnis und Verantwortung übertragen, Rechenschaft jedoch nicht. Auch die Vertragsrichtlinie trennt delegierte Unterschrift und fortbestehende Genehmigungsverantwortung.
  • Der öffentliche Beschluss enthält keine Rollenlandkarte. Ein begrenzter Kontrollbeleg könnte internen Eigentümer, externe Funktion, Berechtigungsklasse, Freigabegrenze und Entzug der Zugänge dokumentieren, ohne Personen oder sensible Systeme offenzulegen.

Der Vorstand genehmigte Elastizität

Die am 6. September 2026 verabschiedeten Beschlüsse erlauben dem President and CEO oder seinen Beauftragten, einen Vertrag mit dem bevorzugten Anbieter einzugehen und die dazugehörigen Zahlungen zu leisten. Gegenstand ist eine strategische Personalverstärkung für Engineering & IT. Die Seite erschien drei Tage nach der Sitzung.

Die Begründung beschreibt das Betriebsmodell recht genau. Externes Fachwissen soll interne Fähigkeiten ergänzen, bei wechselnden Prioritäten schnell skalieren, zeitweise benötigte Spezialkenntnisse bereitstellen und die Abdeckung über globale Zeitzonen ausdehnen. Genannt werden Software Engineering, Qualitätssicherung und Content-Management. Unterstützt werden strategische Vorhaben ebenso wie laufende Betriebsdienste.

Solche Angaben beschreiben Leistung, nicht institutionelle Befugnis. Wer eine Änderung vorbereitet, muss sie nicht freigeben dürfen. Wer einen Build am Prüfplan scheitern lässt, setzt damit keine ICANN-Politik. Wer im Bereitschaftsdienst einen Dienst wiederherstellt, kann einem Runbook folgen, während die Annahme des Betriebsrisikos bei einer benannten internen Rolle verbleibt.

Der Beschluss belegt keine gegenwärtige Vermischung. Er veröffentlicht lediglich nicht die Funktionskarte, anhand derer Außenstehende die Grenze nachvollziehen könnten. Verhandlungsangaben sind geschwärzt; Anbieter, Preis, Laufzeit, Unterzeichnung, Personalzahl, Standorte und Ausführungsstatus sind aus der Seite nicht ersichtlich. Diese Lücken rechtfertigen weder Verdacht noch Spekulation.

ICANN hat die Rechenschaftsregel bereits formuliert

Die im Oktober 2024 geänderten Delegation of Authority Guidelines beginnen mit einer scharfen Trennung: Befugnis und Verantwortung können delegiert werden, Rechenschaft nicht. Der Vorstand bleibt für seine durch die Bylaws verliehenen Befugnisse rechenschaftspflichtig. Liegt eine Befugnis beim President and CEO, kann er andere mit der Leitung einer Aufgabe betrauen; die Verantwortung bleibt bei ihm.

Dasselbe Dokument weist dem President and CEO das Tagesgeschäft innerhalb der durch Vorstandsbeschlüsse gesetzten Grenzen zu. Der Vorstand beaufsichtigt. Es verlangt keine operative Zentralisierung, sondern einen dauerhaften Eigentümer für verteilte Arbeit.

Die seit Januar geltende Contracting and Disbursement Policy setzt diese Trennung praktisch um. Sie definiert Genehmigungsstufen und sieht – vorbehaltlich ihrer Regel für eigens bewilligte Projektbudgets – für Verpflichtungen über 750.000 US-Dollar den Vorstand vor. Ein Officer darf die Unterschrift für bestimmte Vertragsklassen schriftlich delegieren, wenn Rechtsfreigabe und Mitteilung an die übrigen Officers dokumentiert sind. Seine Genehmigungsbefugnis überträgt er damit ausdrücklich nicht; er bleibt letztverantwortlich.

Diese Grammatik passt auch zur technischen Verstärkung: Unterzeichner, Ausführender, Freigebender und Rechenschaftsträger dürfen verschieden sein, wenn ihre Verbindung beweisbar bleibt.

Die gemischte Belegschaft hat Vorgeschichte

Das Protokoll vom 3. Mai 2025 reicht bis 2014 zurück. Damals beauftragte ICANN nach Vorstandsgenehmigung erstmals ein externes Unternehmen zur Verstärkung der IT. Auswahlverfahren fanden 2014 und 2017 statt, gefolgt von mehreren Verlängerungen bis Mai 2025. Der damalige Anbieter unterstützte Entwicklung, Qualitätssicherung und Inhalte.

Daraus folgt weder, dass 2026 derselbe Anbieter bevorzugt wird, noch dass der neue Beschluss eine Verlängerung betrifft. Fest steht nur: Externe technische Kapazität ist ein dauerhaftes Betriebselement und keine spontane Krisenmaßnahme.

ICANNs Form 990 für FY25 liefert Größenordnung, nicht Vertragsdetails. Es meldet 136 unabhängige Auftragnehmer mit jeweils mehr als 100.000 US-Dollar Vergütung im relevanten Zeitraum; mehrere der höchstvergüteten Anbieter werden als IT-Beratung geführt. Regionale Personenzahlen umfassen laut Erklärung direkt Beschäftigte, über Drittarbeitgeber entsandte Kräfte und langfristige unabhängige Auftragnehmer.

Die Steuererklärung erklärt außerdem, schriftliche Interessenkonfliktregeln gälten auch für unabhängige Auftragnehmer und verlangten jährliche Erklärungen. Die öffentliche Seite zu Mitarbeiterpraktiken beschreibt gesondert Vertraulichkeit und Konfliktpflichten für Beschäftigte. Das sind positive Kontrollnachweise, aber keine öffentliche Zuordnung der September-Rollen zu Systemklassen, Daten und Entscheidungsrechten.

Kontrollklassen veröffentlichen, nicht die Angriffsfläche

Rechenschaft verlangt keine Namen einzelner Auftragnehmer, Hosts, Zugangsdaten, Schwachstellen oder Einsatzanweisungen. Solche Details könnten Sicherheit und Privatsphäre gefährden. Sinnvoll wäre ein Rollen- und Kontrollbeleg, der an die Beschlüsse 2026.09.06.03–.04 und nach Vertragsabschluss an eine stabile Vertragskennung gebunden ist.

Für jeden Arbeitsbereich könnte er den rechenschaftspflichtigen ICANN-Officer und den internen Betriebsverantwortlichen nennen. Die externe Funktion würde als Klasse erscheinen, zusammen mit System- oder Datenklassifizierung und Berechtigungsstufe. Der Beleg könnte ausweisen, ob eine Rolle eine wesentliche Handlung vorbereiten, ausführen, empfehlen oder niemals genehmigen darf. Hinzu kämen Funktionstrennung, Eskalation, Unterauftragsregeln und der Status von Vertraulichkeits- und Konflikterklärungen.

Auch das Ende gehört in dieselbe Kette. Ein Startdatum ohne Endbedingung ist nur eine halbe Berechtigung. Prüf- und Ablaufdaten, Bestätigung des Zugangsentzugs, Übergabe von Code und Betriebsbelegen sowie Korrekturverlauf lassen sich dokumentieren, ohne Kontoinhaber oder technische Schwächen zu veröffentlichen.

Das ist Daniel Kades redaktionelles Modell, keine angekündigte ICANN-Vorschrift. Die Quellen belegen weder übermäßigen Zugang noch unklare Freigaben oder schwaches Offboarding. Sie zeigen eine Kapazitätsgenehmigung, deren öffentliche Verbindung zur internen Befugnis noch fehlt.

Ein Anbietername beantwortet die Befugnisfrage nicht

Der Begleitbeschluss hält bestimmte Verhandlungsangaben vertraulich, bis der President and CEO ihre Freigabe für möglich hält. Eine spätere Veröffentlichung von Name, Betrag oder Laufzeit würde die Beschaffung transparenter machen. Sie verriete nicht automatisch, wer eine relevante Änderung freigibt oder wann ein Zugang endet.

Die Governance Guidelines geben dem Vorstand die Aufsicht über Managementleistung, Unternehmensrisiko und solide IT-Planung. Das Verzeichnis der Governance-Dokumente macht die institutionelle Verteilung auffindbar. Es fehlt ein kleinerer Anschluss: eine öffentliche, aggregierte und sichere Projektion dieser Ordnung auf die gemischte Belegschaft.

ICANN stuft die Genehmigung als administrative Organisationsfunktion ohne Pflicht zur öffentlichen Konsultation ein. Ein Rollenbeleg würde Personalführung nicht zur Abstimmung stellen. Er würde ICANNs eigenen Satz prüfbar machen: Kapazität kann eine Vertragsgrenze überschreiten; Rechenschaft bleibt zurück.

Quellen