Summary

  • ICANN appointed Mirror Group LLC on 20 August 2026 to conduct Safeguard Assessment for the 2026 Round, deciding which applied-for strings require additional contractual safeguards.
  • The appointment is not performance evidence. The central test is whether each classification produces a clear, comparable record of facts, reasons, conflicts, recusals and quality control.

ICANN’s appointment settles who will administer one of the 2026 Round’s higher-consequence judgement processes. Safeguard Assessment is part of String Evaluation. It determines whether an applied-for string requires Safeguard Public Interest Commitments, or Safeguard PICs, in the applicable Registry Agreement.

ICANN says it selected Mirror Group through a competitive RFP and expects the work to be fair, consistent and objective. Mirror Group describes itself as an evaluation, research and strategy firm. Those are attributable descriptions of the selection and the supplier, not performance evidence. There is no 2026-round string classification in the cited record, so there is not yet an outcome to endorse or fault.

The December 2025 RFP forecast that evaluation would begin around November 2026, assumed 2,000 applications and allowed six months from String Confirmation Day for determinations. When the application window closed, ICANN reported more than 1,600 primary applications and more than 1,100 replacement-string applications. It also said the final count remained subject to receipt of evaluation fees. The figures establish the scale of submissions, but not the final number of paid applications or completed classifications.

A classification with contractual force

The framework places strings into four risk-based groups: regulated sectors with open-entry requirements; highly regulated sectors with closed-entry requirements; strings with potential for cyberbullying or harassment; and strings associated with inherently governmental functions. The task is not simply to match words against a list. It requires a contextual judgement about meaning, consumer expectations, regulation and intended use.

That context is especially important in a globally diverse application round. A string may have an ordinary meaning in one language, a regulated-sector meaning in another, or a governmental association in a particular jurisdiction. Variants, and any replacement strings that enter evaluation, can create further comparisons. The Evaluation Guide and calibration process therefore have to turn broad group descriptions into a method that can be applied across scripts and markets without treating literal translation as sufficient evidence.

Applicants must answer the Safeguard Assessment/Mission and Purpose questions, and those answers are published with the application. The evaluation also takes account of application comments and relevant GAC input, including Early Warnings or Consensus Advice where applicable. Participation therefore enlarges the evidence available to the evaluator. It does not itself decide the classification.

Mirror Group’s panel will conduct the expert assessment under ICANN’s framework; the Applicant Guidebook places the group determination with ICANN. At the close of the application comment period, that determination concludes this part of evaluation and becomes an input to contracting. The Guidebook states that it cannot be challenged under Extended Evaluation and Evaluation Challenges because it does not affect the application’s progression. Yet, if a group applies and the application proceeds to contracting, the relevant Safeguard PICs must be included in Specification 11 of the applicable Base Registry Agreement without modification.

That is a precise procedural asymmetry. The classification does not stop an application from progressing, but it can attach prescribed operating obligations to the eventual contract. The point is not that ICANN has no accountability mechanism of any kind; it is that these two evaluation challenge routes do not apply to this determination, while the contractual consequence is prescribed. The RFP separately requires the provider to support accountability mechanisms described in the Applicant Guidebook and to supply ICANN with the necessary records.

The RFP sets an evidence standard

The most important provisions in the RFP concern the record that should sit behind each answer. It requires an independent expert panel, an Evaluation Guide prepared before applications are received for evaluation, and training and calibration intended to produce consistent treatment across panellists. Each determination is to carry three rationales — one public, one for the applicant and one for ICANN — with supporting work product recorded through TAMS.

The provider must also operate internal review and quality control, identify and document potential conflicts, maintain recusal and panellist-substitution procedures, retain relevant materials under ICANN’s document-retention requirements, and deliver a final report covering outcomes, lessons and recommendations. Communications and outcomes are to be tracked and auditable in TAMS. Separately, evaluations and evaluator work may be reviewed by an ICANN-designated independent quality-control provider. The RFP says ‘may’, not ‘will’.

Taken together, those provisions describe more than a panel verdict. They describe a decision ledger: the applicable facts, the sources considered, the rule applied, the reason for inclusion or exclusion, the handling of conflicts and the checks used to keep like cases aligned. The RFP says assessment results will be published so applicants and the community can understand the basis for the decision. The public rationale will be the outward-facing part of that ledger. Its usefulness will depend on whether it is specific enough to permit comparison rather than merely repeating the category label.

The 20 August appointment announcement did not publish the contract value, the number of bidders or the procurement scoring. Nor did it publish panellist names, the Evaluation Guide, a calibration record, conflict disclosures, a recusal record or the identity of any quality-control provider. That establishes only what the announcement contained. It does not establish that the materials do not exist or that they will not be published later.

The RFP timetable had anticipated a provider announcement on 23 June; ICANN announced Mirror Group on 20 August. The cited record does not explain the difference, and the timing alone says nothing about the quality of the assessments to come.

The appointment therefore begins, rather than completes, the evidentiary test. Publication of a usable Evaluation Guide, meaningful panel and conflict disclosures, well-reasoned rationales, consistent treatment across strings and languages, and visible quality-control evidence would strengthen the case that the process is working as designed. Boilerplate explanations, unexplained departures between comparable cases or an opaque recusal trail would point the other way. Until determinations appear, responsibility has been assigned but legitimacy remains to be earned in the record.

Sources

  1. https://www.icann.org/en/announcements/details/icann-announces-safeguard-assessment-provider-for-2026-round-20-08-2026-en
  2. https://www.icann.org/en/announcements/details/icann-request-for-proposal-2026-round-safeguard-assessment-09-12-2025-en
  3. https://www.icann.org/en/system/files/files/2026-round-safeguard-assessment-rfp-09dec25-en.pdf
  4. https://newgtldprogram-2026-agb.icann.org/en/11-module-7-string-and-application-evaluation-procedures.html
  5. https://www.icann.org/en/announcements/details/icann-2026-round-closes-with-more-than-1600-new-gtld-applications-13-08-2026-en
  6. https://www.mirrorgroupllc.com/whoweare