Summary

  • ICANN’s 5 August request for proposals seeks an integrated SaaS platform for policy management, enterprise and third-party risk, internal audit, compliance, dashboards and automated evidence. The public timetable puts proposals due on 11 September; no provider, contract or implementation is established.
  • Central records should preserve the difference between a risk owner, control operator, evidence collector, tester, remediation owner and Board overseer. A portable authority-and-evidence concordance could bind every system state to the role, decision basis, provenance, challenge and correction that give it meaning.

A dashboard can tell the truth and still have no authority to act on it.

That is the central governance question inside ICANN’s 5 August request for proposals for a governance, risk and compliance platform. The organization wants a globally accessible hosted service that can bring policy documents, risk registers, third-party reviews, internal-audit work, compliance mappings, reporting and automated evidence into one integrated environment. ICANN describes its present arrangements as decentralized and largely manual, with separate repositories that limit efficiency, visibility and consistency while increasing document and version-control risk.

The case for better records is straightforward. A control should not acquire three names in three spreadsheets. An audit finding should not lose its remediation owner when it crosses departments. A policy approval should not depend on which copy a user happened to open. A risk register should be usable by distributed teams without becoming nine incompatible local registers.

Yet integration creates a second question. Once the platform becomes the easiest place to see a risk, does its status field begin to substitute for the decision that status claims to record? “Accepted”, “effective”, “closed” and “within appetite” are not clerical facts. They are conclusions made under specific authority, for a defined scope and period, on evidence that may be incomplete or contested.

The software may be the bookkeeper. It cannot be the principal.

The procurement is still a procurement

The public RFP overview sets out a large operational ambition. Policy lifecycle management would cover creation, review, approval, publication and workflow. Enterprise risk management would align with COSO and ISO 31000 and support centralized registers for decentralized teams. Third-party risk would include assessment, monitoring and documentation. Internal audit would include planning, execution, findings, remediation tracking and reporting. Compliance functions would map ISO/IEC 27001, SOC 2, SOC 3 and privacy requirements.

Dashboards would give real-time views of risk posture and key metrics; integrations could continuously monitor controls and gather evidence where appropriate.

High-level business requirements include a fully hosted global SaaS service, an ISO 27001-certified environment, high availability, role-based access controls, audit trails, integrations and APIs, implementation, support and training. Selection criteria include functionality, automation, reporting, usability, support, financial health, pricing, references and conflict-of-interest mitigation.

These are requirements for a competition, not outcomes. Proposals are due at 23:59 UTC on 11 September. Evaluation is scheduled from 14 September to 13 November, with due diligence, contracting and any award from 16 November onward. ICANN may alter the schedule, reject proposals, withdraw the process or make no award. The checked record names no winner and establishes no deployed platform.

The public overview is also only part of the RFP. Additional supporting materials sit inside ICANN’s SciQuest/Jaggaer sourcing tool. That matters when assessing omissions. A public reader can ask whether portability, exit assistance, data ownership, retention, incident handling or evidence lineage will be protected. The reader cannot conclude from the overview alone that the gated requirements, a bidder’s response or a final contract lacks those protections.

ICANN already separates ownership from facilitation

The platform will enter an existing authority architecture. ICANN’s October 2022 overview of its risk-management framework says the President and CEO owns all organizational risks and delegates functional ownership to the relevant executive. The Risk Management function facilitates the framework; it does not own the risks. Functions keep ownership closest to the activities that generate the exposure, supported by Risk Liaisons. The CEO Risk Management Committee reviews reporting and action plans. The Board and its Risk Committee oversee the framework and the level and type of risk the organization accepts.

That document is a 2022 overview, not proof that every operating detail is unchanged. The current Board Risk Committee charter, approved on 20 July 2026, supplies a current control surface. It assigns the committee oversight of risk identification, assessment, prioritization and mitigation, as well as risk appetite and tolerance. For internal audit, the committee approves scope, plans and budget; reviews provider independence; receives findings; and receives reporting on significant exposures, control issues and the status of management’s corrective actions.

Minutes from February 2025 record the same division in especially plain form at that time: the committee oversaw audit planning, execution and results, while management remained responsible for remediation.

These roles are not columns that a vendor is entitled to merge. A risk-management team may administer the process without becoming the risk owner. An internal auditor may test a control without operating it. A Board committee may oversee remediation without performing it. Management may close an action without declaring the original audit judgment mistaken. Central visibility should make those distinctions easier to inspect, not easier to blur.

Automated evidence still needs a proposition

The RFP’s interest in automated evidence is reasonable. Manual screenshots and copied exports are slow, inconsistent and easy to detach from their period or source. A collector connected to an identity system, ticketing service or cloud environment can preserve timestamps, scope and repeated measurements more reliably.

But evidence is always evidence of something. A list of disabled accounts may support one access-control assertion while saying nothing about whether privileged access was properly approved. A configuration value may show that a control exists while saying little about exceptions or the systems outside the query. A completed ticket may document activity but not the effectiveness of the remediation. A fresh dashboard can display an old risk assumption.

The important question is not whether collection was automated. It is which proposition the evidence supports, for what population and period, through which query or transformation, with what exceptions, and who reviewed it under what authority. Continuous collection can improve frequency. It cannot manufacture relevance or judgment.

This is why “real-time visibility” must remain a presentation claim. The platform can show the latest accepted data. It cannot decide whether the acceptance was justified, whether residual risk is tolerable or whether an audit challenge has been answered.

Give every state an authority-and-evidence concordance

ICANN does not need another public database of sensitive risks. It needs a protected join between the record and the act that made the record valid.

For each material risk, control, exception, audit finding or remediation item, an authority-and-evidence concordance should preserve a stable identifier; the accountable function and role; and the type of authority being exercised—ownership, assessment, approval, acceptance, testing, challenge, oversight or remediation. It should point to the policy, risk-appetite statement, audit plan or decision record that supplies that authority.

The same receipt should identify the assertion made, its scope and period, and the provenance of supporting evidence: source system, collector or query, transformation, timestamp, version, coverage and reviewer. Exceptions and contradictory material should travel with the claim. A changed state should record who acted, through which role, when and on what basis. Corrections and superseded conclusions should remain visible rather than disappear beneath the newest dashboard tile.

The vendor side belongs in the receipt too. Privileged access, configuration changes and evidence transformations need audit history. Export should preserve identifiers, links, decision events and correction history in a form that another system and an independent reviewer can understand. An archive of PDFs is not portability if the relationships that make the evidence intelligible are lost.

This is Daniel Kade’s proposed governance control, not an announced ICANN requirement. Its purpose is to keep the central platform thin: powerful at custody, workflow and retrieval; deliberately unable to absorb the authority of the people and bodies it serves.

Public assurance should reveal the map, not the risks

Accountability does not require ICANN to publish its risk register, vulnerabilities, audit workpapers, raw control evidence, third-party security details, personal data, legal advice or sensitive remediation. The 2022 framework overview itself explains why detailed risks and countermeasures can be imprudent to disclose.

A proportionate public layer would answer narrower questions. Has the authority map been approved? Do risk owners remain distinct from process administrators and evidence collectors? Does internal audit retain independent reporting and challenge? Are evidence provenance and correction history tested? Can the organization export a complete, intelligible history without the incumbent interface? Are overdue remediation items reported in aggregate to the proper oversight body? Has privileged vendor access been independently reviewed?

Those assurances would not expose the contents of a high-risk finding. They would show that a system state cannot silently replace an accountable decision.

Centralization is useful when it joins facts. It becomes dangerous when it joins roles that governance deliberately kept separate. ICANN’s RFP can produce a better record system. The durable test is whether, after implementation or after exit, each risk statement can still answer four questions: who had authority, what did they decide, what evidence supported it, and who could challenge or correct it.

If those answers survive outside the dashboard, the platform is serving governance. If they exist only as the dashboard’s current state, the bookkeeper has begun to write the constitution.

Sources

  1. ICANN GRC solution RFP announcement, 5 August 2026
  2. ICANN Project Overview for the Governance, Risk, and Compliance Solution RFP
  3. ICANN Org Risk Management Framework overview, October 2022
  4. ICANN Board Risk Committee Charter, approved 20 July 2026
  5. ICANN Board resolution adopting the revised Risk Committee charter, 20 July 2026
  6. ICANN Board Risk Committee minutes, 10 February 2025