Skip to main content

Accountability Mechanisms

ICANN has a proven commitment to accountability and transparency in all of its practices.  ICANN considers these principles to be fundamental safeguards in ensuring that its bottom-up, multi-stakeholder model remains effective. The mechanisms through which ICANN achieves accountability and transparency are built into every level of its organization and mandate – beginning with its Bylaws, detailed in its Accountability and Transparency Frameworks and Principles (adopted by ICANN's Board in 2008) and annually reinforced in its Strategic and Operational Plan.  In order to reinforce its transparency and accountability, ICANN has established accountability mechanisms for review of ICANN actions. While the full texts of the accountability mechanisms are set forth in Articles IV and V of the ICANN Bylaws, the following is summary and illustrative overview of these mechanisms.

Reconsideration Process

Reconsideration is a mechanism provided by Article IV, Section 2 of the Bylaws by which any person or entity materially affected by an action (or inaction) of ICANN may request review or reconsideration of that action by the Board.

Any person or entity may submit a request for reconsideration or review of an ICANN action or inaction ("Reconsideration Request") to the extent that the person or entity has been adversely affected by:

  1. one or more staff actions or inactions that contradict established ICANN policy(ies); or
  2. one or more actions or inactions of the ICANN Board that have been taken or refused to be taken without consideration of material information, except where the party submitting the request could have submitted, but did not submit, the information for the Board's consideration at the time of action or refusal to act; or
  3. one or more actions or inactions of the ICANN Board that are taken as a result of the Board's reliance on false or inaccurate material information.

Absent a showing of these standards, the reconsideration process is not a mechanism for reconsideration of an action (or inaction) simply because the person or entity does not agree with the action (or inaction).

All Reconsideration Requests must be submitted within fifteen days after:

  1. for requests challenging Board actions, the date on which information about the challenged Board action is first published in a resolution, unless the posting of the resolution is not accompanied by a rationale. In that instance, the request must be submitted within 15 days from the initial posting of the rationale; or
  2. for requests challenging staff actions, the date on which the party submitting the request became aware of, or reasonably should have become aware of, the challenged staff action; or
  3. for requests challenging either Board or staff inaction, the date on which the affected person reasonably concluded, or reasonably should have concluded, that action would not be taken in a timely manner.

Reconsideration Requests are reviewed and considered by the Board Governance Committee ("BGC"). For all Reconsideration Requests brought regarding staff action or inaction, the BGC shall be delegated the authority by the Board of Directors to make a final determination and recommendation on the matter. Board consideration of the recommendation is not required. As the BGC deems necessary, it may make recommendation to the Board for consideration and action.

The BGC shall make a final determination, or a recommendation to the Board within thirty days following its receipt of the Reconsideration Request, unless impractical. In the event that a recommendation is made to the Board by the BGC, the Board shall issue its decision on the recommendation of the BGC within sixty days of receipt of the Reconsideration Request or as soon thereafter as feasible.

ICANN has determined that the reconsideration process can properly be invoked for challenges to expert determinations rendered by panels formed by third party dispute resolution service providers in the New gTLD Program, if the claim is that the Panel failed to follow established policies or processes in reaching the expert determination, or that staff failed to follow its policies or processes in accepting that determination.

For more information about ICANN's Reconsideration Process, please visit Article IV of the Bylaws at, or the Reconsideration page.

Independent Review Process ("IRP")

In addition to the Reconsideration Process, ICANN has also established a separate process for independent third-party review of Board actions (or inactions) alleged by an affected party to be inconsistent with ICANN's Articles of Incorporation or Bylaws. See Article IV, Section 3 of the ICANN Bylaws.

Any person materially affected by a decision or action by the Board that he or she asserts is inconsistent with the Articles of Incorporation or Bylaws may submit a request for independent review of that decision or action.  In order to be materially affected, the person must suffer injury or harm that is directly and causally connected to the Board's alleged violation of the Bylaws or the Articles of Incorporation, and not as a result of third parties acting in line with the Board's action.

An IRP request must be filed within thirty days of the posting of the minutes of the Board meeting (and the accompanying Board Briefing Materials, if available) that the requesting party contends demonstrates that ICANN violated its Bylaws or Articles of Incorporation.  For IRP requests relating to a BGC determination on a Reconsideration Request, such requests must be filed within thirty days of the posting of the minutes of the BGC meeting in which the determination at issue was made.

Prior to initiating a request for independent review, the complainant is urged to enter into a period of cooperative engagement with ICANN for the purpose of resolving or narrowing the issues that are contemplated to be brought to the IRP. See

For more information about ICANN's Independent Review Process, please visit Article IV, Section 3 of the Bylaws at, or the Independent Review Process page.


The ICANN Ombudsman is an independent and impartial neutral whose function is to provide an independent internal evaluation of complaints by members of the ICANN community who believe that the ICANN staff, Board or an ICANN constituent body has treated them unfairly for matters which have not otherwise become the subject of the Reconsideration Process or the Independent Review Process. The Ombudsman shall serve as an objective advocate for fairness, and shall seek to evaluate and where possible resolve complaints about unfair or inappropriate treatment by ICANN staff, the Board, or ICANN constituent bodies, clarifying the issues and using conflict resolution tools such as negotiation, facilitation, and "shuttle diplomacy" to achieve these results. See Article V of the ICANN Bylaws.

The Ombudsman does not have the power to make, change or set aside a policy, administrative or Board decision, act, or omission. The Ombudsman does have the power to investigate these events, and to use Alternative Dispute Resolution technique to resolve them. The Ombudsman is authorized to make such reports to the Board as he or she deems appropriate with respect to any particular matter and its resolution or the inability to resolve it.

For more information about ICANN's Ombudsman, please visit Article V of the Bylaws at or the Ombudsman page.

What is the Empowered Community?

The Empowered Community is the mechanism through which ICANN's Supporting Organizations (SOs) and Advisory Committees (ACs) can organize under California law to legally enforce community powers. The community powers and rules that govern the Empowered Community are defined in the ICANN Articles of Incorporation and Bylaws.

Who can participate in the Empowered Community?

All of ICANN's SOs, as well as the At-Large and Governmental ACs, can participate in the Empowered Community including:

How does the Empowered Community use their powers?

The Empowered Community has a process to raise concerns with an action or inaction made by the ICANN Board or organization. This escalation process gives SOs and ACs opportunities to discuss solutions with the ICANN Board.

For more information, click here for the Empowered Community webpage.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."