Recommendation by Recommendation Status
Recommendations to Improve Diversity | Implementation Status |
1.1 SO/AC/Groups should agree that the following seven key elements of diversity should be used as a common starting point for all diversity considerations within ICANN: * Geographic/Regional Representation * Language * Gender * Age * Physical Disability * Diverse skills * Stakeholder Group or Constituency. | Org implementation: Complete. See implementation documentation. Board/NomCom implementation: Complete. See implementation documentation. |
1.2 Each SO/AC/Group should identify which elements of diversity are mandated in their charters or ICANN Bylaws and any other elements that are relevant and applicable to each of its levels including leadership (Diversity Criteria) and publish the results of the exercise on their official websites. | Org implementation: Complete. See implementation documentation. Board/NomCom implementation: Complete. See implementation documentation. |
1.3 Each SO/AC/Group, supported by ICANN staff, should undertake an initial assessment of their diversity for all of their structures including leadership based on their Diversity Criteria and publish the results on their official website. | Org implementation: Complete. See implementation documentation. Board/NomCom implementation: Complete. See implementation documentation. |
1.4 Each SO/AC/Group should use the information from their initial assessment to define and publish on their official website their Diversity Criteria objectives and strategies for achieving these, as well as a timeline for doing so. | Org implementation: Complete. See implementation documentation. Board/NomCom implementation: Complete. See implementation documentation. |
1.5 Each SO/AC/Group, supported by ICANN staff, should undertake a regular update of their diversity assessment against their Diversity Criteria and objectives at all levels including leadership. Ideally this update should be carried out annually but not less than every three years. They should publish the results on their official website and use this information to review and update their objectives, strategies, and timelines. | Org implementation: Complete. See implementation documentation. Board/NomCom implementation: Complete. See implementation documentation. |
1.6 ICANN staff should provide support and tools for the SO/AC/Groups to assist them in assessing their diversity in an appropriate manner. ICANN should also identify staff or community resources that can assist SO/ACs or other components of the community with diversity-related activities and strategies. | Complete. See implementation documentation. |
1.7 ICANN staff should support SO/AC/Groups in developing and publishing a process for dealing with diversity-related complaints and issues. | Complete. See implementation documentation. |
1.8 ICANN staff should support the capture, analysis, and communication of diversity information, seeking external expertise if needed, in the following ways: 1.8.1. Create a Diversity section on the ICANN website. 1.8.2. Gather and maintain all relevant diversity information in one place. 1.8.3. Produce an Annual Diversity Report for ICANN based on all the annual information and provide a global analysis of trends and summarize SO/AC/Groups recommendations for improvement, where appropriate. This should also include some form of reporting on diversity complaints. 1.8.4. Include diversity information derived from the Annual Diversity Report in ICANN's Annual Report. | |
Recommendation for a Framework of Interpretation for Human Rights | |
3.1 The CCWG-Accountability WS2 recommends the adoption of the Framework of Interpretation it developed for the ICANN Bylaws dealing with Human Rights, which can be found in Annex 3. | See Implementation Documentation. |
Recommendations on Jurisdiction | |
4.1 Recommendations Relating to OFAC Sanctions and Related Sanctions Issues [...] | |
4.1.1 ICANN Terms and Conditions for Registrar Accreditation Application Relating to OFAC Licenses For ICANN to enter into a Registration Accreditation Agreement (RAA) with an applicant from a sanctioned country, it will need an OFAC license. Currently, “ICANN is under no obligation to seek such licenses and, in any given case, OFAC could decide not to issue a requested license.” This uncertainty could discourage residents of sanctioned countries from applying for accreditation. The sub-group recommends that the above sentence should be amended to require ICANN to apply for and use best efforts to secure an OFAC license if the other party is otherwise qualified to be a registrar (and is not individually subject to sanctions). During the licensing process, ICANN should be helpful and transparent with regard to the licensing process and ICANN’s efforts, including ongoing communication with the potential registrar. | See Implementation Documentation. |
4.1.2 Approval of gTLD Registries In the 2012 round of the New gTLD program, it was difficult for residents from sanctioned countries to file and make their way through the application process. The Applicant Guidebook (AGB) states: “In the past, when ICANN has been requested to provide services to individuals or entities that are not SDNs (specially designated nationals) but are residents of sanctioned countries, ICANN has sought and been granted licenses as required. In any given case, however, OFAC could decide not to issue a requested license.” The sub-group recommends that ICANN should commit to applying for and using best efforts to secure an OFAC license for all such applicants if the applicant would otherwise be approved (and is not on the SDN list). ICANN should also be helpful and transparent with regard to the licensing process, including ongoing communication with the applicant. | See Implementation Documentation. |
4.1.3 Application of OFAC Limitations by Non-U.S. Registrars It appears that some non-U.S.-based registrars might be applying OFAC sanctions with registrants and potential registrants, based on a mistaken assumption that they must do so simply because they have a contract with ICANN. Non-U.S. registrars may also appear to apply OFAC sanctions, if they “cut and paste” registrant agreements from U.S.-based registrars. While ICANN cannot provide legal advice to registrars, it can bring awareness of these issues to registrars. The sub-group recommends that ICANN clarify to registrars that the mere existence of their RAA with ICANN does not cause them to be required to comply with OFAC sanctions. ICANN should also explore various tools to remind registrars to understand the applicable laws under which they operate and to accurately reflect those laws in their customer relationships. | Complete. See Implementation Documentation. |
4.1.4 General Licenses OFAC “general licenses” cover particular classes of persons and types of transactions. ICANN could pursue general licenses to cover transactions integral to ICANN’s role in managing the DNS and contracts for Internet resources, such as registries and registrars entering into Registry Agreements (RAs) and Registrar Accreditation Agreements (RAAs), Privacy/Proxy Accreditation, support for ICANN-funded travelers, etc. This would enable individual transactions to proceed without the need for specific licenses. A general license would need to be developed in conjunction with the U.S. Department of the Treasury, which must amend OFAC regulations to include the new license. This regulatory process may be a significant undertaking. The sub-group recommends that ICANN take steps to pursue one or more OFAC “general licenses.” ICANN should first prioritize a study of the costs, benefits, timeline and details of the process. ICANN should then pursue general licenses as soon as possible, unless it discovers significant obstacles. If so, ICANN should report this to the community and seek its advice on how to proceed. If unsuccessful, ICANN needs to find other ways to remove “friction” from transactions between ICANN and residents of sanctioned countries. ICANN should communicate regularly about its progress, to raise awareness in the ICANN community and with affected parties. | In progress. Tentative completion date: Q3 2024. |
4.2 Recommendations relating to Choice of Law and Choice of Venue Provisions in ICANN Agreements [...] | |
4.2.1 Choice of Law and Venue Provisions in the Registry Agreement The sub-group identified several alternative approaches for the RA, which could also apply to the RAA. The body of the report discusses the advantages and disadvantages of each approach.
4.2.2 Choice of Law Provisions in Registrar Accreditation Agreements The options for the RAA are essentially the same as for the RA. 4.2.3 Choice of Venue Provisions in Registry Agreements Under the RA, disputes are resolved by “binding arbitration,” pursuant to ICC rules. The RA contains a choice of venue provision stating that the venue is Los Angeles, California as both the physical place and the seat of the arbitration. When entering into contracts with registries, ICANN could offer a list of possible venues for arbitration rather than imposing Los Angeles, California. The registry that enters into a registry agreement with ICANN could then choose which venue it prefers at or before the execution of the contract. | See implementation documentation. |
Recommendations for Improving the ICANN Office of the Ombuds (IOO) | |
5.1 The Ombuds Office should have a more strategic focus. | In progress. Tentative completion date: Q2 2025. |
5.2 The Ombuds office should include procedures that:
| In progress. Tentative completion date: Q2 2025. |
5.3 Once ICANN has agreed to a revised configuration for the Office of the Ombuds, a plan should be developed for a soft relaunch of the function, which should incorporate action to emphasis the importance of the Ombuds function by all relevant parts of ICANN, including: Board, CEO, Community Groups, Complaints Officer. | Not started. Tentative completion date: Q2 2025. |
5.4 All relevant parts of ICANN should be required (should include the corporation, the Board and committees, and anybody or group with democratic or delegated authority) to respond within 90 days (or 120 days with reason) to a formal request or report from the Office of the Ombudsman. The response should indicate the substantive response along with reasons. Should the responding party not be able to meet the 120-day limit due to exceptional circumstances, that party can apply to the IOO to seek an additional extension prior to the expiration of the original 90-day delay. The application should be in writing, stating the nature of the exception and the expected time required to respond. The IOO will respond to such requests within a week. | In progress. Tentative completion date: Q2 2025. |
5.5 The ICANN Office of the Ombuds should establish timelines for its own handling of complaints and report against these on a quarterly and annual basis. | In progress. Tentative completion date: Q2 2025. |
5.6 The Office of the Ombuds should be configured so that it has formal mediation training and experience within its capabilities. | See Implementation Documentation. |
5.7 Ideally, the Office of the Ombuds should be configured so that it has gender and, if possible, other forms of diversity within its staff resources. (The primary objective of this recommendation is to ensure that the Community has choices as to whom in the IOO they can bring their complaints to and feel more comfortable doing so.) | See Implementation Documentation. |
5.8 ICANN should establish an Ombuds Advisory Panel:
CCWG-Accountability Implementation guidance: The Ombuds panel is not meant to be a decision-making body – it is only there to assist the Board or relevant Board Committee with the specific tasks enumerated in the recommendation. The Panel is specifically prohibited from getting involved in any matter before the Ombuds; the Ombuds shall not seek, even on anonymized terms, guidance from the Panel on any matter before the Ombuds. The Panel will only have the six specifically enumerated powers set out in the recommendation. In implementing the portion of the recommendation “recommend to the Board firing an Ombuds for cause” - because under the Bylaws only the Board has the power to fire the Ombuds, the CCWG advises that the Board should implement this recommendation by preparing and publishing information about the process any ICANN community participants can use to provide the Board with feedback about, or raise concerns regarding, the performance of the Ombuds. The Panel is welcome to offer feedback on the performance of the Ombuds but can only provide any feedback though this process (aside from the regular external evaluation). The CCWG suggests this clarification to preserve the right of the Panel to raise any concerns with the performance of the Ombuds function while not interfering with the Board’s responsibilities in managing the engagement of the Ombuds and considering concerns raised in an appropriate way. In implementing the portion of the recommendation “Make recommendations regarding any potential involvement of the IOO in noncompliant work based on the criteria listed in recommendation 11”, this should only occur at the request of the Board. Finally, a formal process to select the panel members should be created. This should ensure that candidates have extensive ICANN and/or ombuds experience, and also have complete independence from the SO/ACs. The selection process may be designed in any appropriate means to achieve independence, such as by selection by the Board, an independent recruitment firm, or other appropriate process. Regardless of the process which is selected the ICANN Board should post details regarding the process that will be utilized. | Not started. Tentative completion date: Q2 2025. |
5.9 The Ombuds employment contracts should be revised to strengthen independence by allowing for a:
| In progress. Tentative completion date: Q2 2025. |
5.10 The Ombuds should have as part of their annual business plan, a communications plan – including the formal annual report – publishing reports on activity, collecting and publishing statistics and complaint trend information, collecting user satisfaction information, and publicizing systemic improvements arising from the Ombuds’ work. | In progress. Tentative completion date: Q2 2025. |
5.11 The following points should be considered and clarified publicly when looking at the Ombuds’ involvement in any non-complaints work:
| In progress. Tentative completion date: Q2 2025. |
Recommendations to Increase SO/AC Accountability | |
6.1 Accountability | |
6.1.7 Links to SO/AC transparency and accountability (policies, procedures, and documented practices) should be available from ICANN’s main website, under “accountability.” ICANN staff would have the responsibility to maintain those links on the ICANN website. | Complete. Completed in Q1 2024. See implementation documentation. |
6.3 Participation | |
6.3.6 if ICANN were to expand the list of languages that it supports, this support should also be made available to SO/AC/Groups. | In progress. Tentative completion date: Q3 2024. |
Recommendations to Improve Staff Accountability | |
7.1 To address the lack of understanding of the existence and/or nature of existing staff accountability , the following actions should be taken: 7.1.1 The ICANN organization should improve visibility and transparency of the organization’s existing accountability mechanisms, by posting on icann.org in one dedicated area the following:
| See implementation documentation. |
7.1.2 The ICANN organization should also evaluate what other communication mechanisms should be utilized to further increase awareness and understanding of these existing and new accountability mechanisms. | |
7.2.1 The ICANN organization should enhance existing accountability mechanisms to include:
| See implementation documentation. |
7.2 To address the lack of clearly defined, or broadly understood, mechanisms to address accountability concerns between community members and staff members regarding accountability or behavior: 7.2.2 Consistent with common best practices in services organizations, standardize and publish guidelines for appropriate timeframes for acknowledging requests made by the community, and for responding with a resolution or updated timeframe for when a full response can be delivered. The ICANN organization should include language in the performance management guidelines for managers that recommends people managers of community-facing staff seek input from the appropriate community members during the organization’s performance reviews. Identification of appropriate community members, frequency of outreach to solicit input, and how to incorporate positive and constructive feedback into the overall performance review should be at the discretion and judgement of the personnel manager, with appropriate guidance from HR as necessary. Such a feedback mechanism should be supplemental to the existing mechanisms available to the community to provide input on ICANN staff performance, including direct communication to specific staff member, their personnel managers, senior executive staff, Board Directors, and the Complaints Officer. | See implementation documentation. |
7.3 The ICANN Organization should work with the community to develop and publish service level targets and guidelines (similar to the Service Level Agreement for the IANA Numbering Services) that clearly define the services provided by ICANN to the community as well as the service level target for each service. In this context: 7.3.1 ICANN should work with the community to identify and prioritize the classes of services for which service level targets and guidelines will be implemented, and to define how service level targets and guidelines will be defined. 7.3.2 Develop clear and reasonable guidelines for expected behavior between the ICANN organization and the community for those newly identified activities. 7.3.3 Develop and publish the resulting service levels, targets, and guidelines in a single area on icann.org. These targets and guidelines should also inform any regular information acquisition mechanism described in Recommendation 2 of this report. | See implementation documentation. |
Recommendations to Improve ICANN Transparency | |
8.1 Improving ICANN’s Documentary Information Disclosure Policy (DIDP) | |
8.1.1 The caveat that the DIDP applies only to “operational activities” should be deleted. | See implementation documentation. |
8.1.2 The DIDP should include a documentation rule whereby, if significant elements of a decision-making process take place orally, or otherwise without a lasting papertrail, the participants in that decision-making process should be required to document the substance of the conversation, and include it alongside other documentation related to this decision-making process. | See implementation documentation. |
8.1.3 The DIDP should be expanded to include clearly defined procedures for lodging requests for information, including requirements that requesters should only have to provide the details necessary to identify and deliver the information. | See implementation documentation. |
8.1.4 The DIDP should impose clear guidelines on ICANN for how to process requests, including delegating a specific employee or employees with the responsibility of responding to DIDP requests, including a commitment to provide reasonable assistance to requesters who need it, particularly where they are disabled or unable to identify adequately the information they are seeking. | See implementation documentation. |
8.1.5 The DIDP should commit to complying with requesters’ reasonable preferences regarding the form in which they wish to receive information under request (for example, if it is available as either a pdf or as a doc), if ICANN either already has that information available in the requested format, or can convert it to the requested format relatively easily. | See implementation documentation. |
8.1.6 The DIDP should specify that requests should receive a response “as soon as reasonably possible” and should cap timeline extensions to an additional 30 days. | See implementation documentation. |
8.1.7 The phrase “to the extent feasible, to reasonable requests” should be deleted from the provision on Responding to Information Requests. | See implementation documentation. |
8.1.8 In cases where information subject to request is already publicly available, ICANN staff should direct requesters, with as much specificity as possible, to where the information may be found. In other words, if the processing of a DIDP request reveals that the information has already been published, staff should include information about where this information may be found in their response to the requester. | See implementation documentation. |
8.1.9 The exception for information “that relates in any way to the security and stability of the Internet, including the operation of the L Root or any changes, modifications, or additions to the root zone” should be amended so that it only applies to information whose disclosure would be harmful to the security and stability of the Internet, including the operation of the L Root or any changes, modifications, or additions to the root zone. | See implementation documentation. |
8.1.10 The exception for “drafts of all correspondence, reports, documents, agreements, contracts, emails, or any other forms of communication” should be amended to clarify that this information should be disclosed unless it would be harmful to an ongoing deliberative or decision-making process. | See implementation documentation. |
8.1.11 The exceptions for “trade secrets and commercial and financial information not publicly disclosed by ICANN” and for "confidential business information and/or internal policies and procedures" should be replaced with an exception for “material whose disclosure would materially harm ICANN’s financial or business interests or the commercial interests of its stake-holders who have those interests.” | See implementation documentation. |
8.1.12 Where an exception is applied to protect a third party, the DIDP should include a mechanism for ICANN staff to contact this third party to assess whether they would consent to the disclosure. | See implementation documentation. |
8.1.13 The exception for information requests which are “not reasonable, excessive or overly burdensome, not feasible, abusive or vexatious or made by a vexatious or querulous individual” should be amended so that either the Ombudsman or the Complaints Officer automatically reviews any decision to use this exception. | See implementation documentation. |
8.1.14 The following sentence should be deleted: “Further, ICANN reserves the right to deny disclosure of information under conditions not designated above if ICANN determines that the harm in disclosing the information outweighs the public interest in disclosing the information.” | See implementation documentation. |
8.1.15 ICANN should consider future processes to expand transparency at ICANN Legal, including through clarification of how attorney-client privilege is invoked. | See implementation documentation. |
8.1.16 Wherever possible, ICANN's contracts should either be proactively disclosed or available for request under the DIDP. The DIDP should allow ICANN to withhold information subject to a non-disclosure agreement; however, such agreements should only be entered into where the contracting party satisfies ICANN that it has a legitimate commercial reason for requesting the NDA, or where information contained therein would be subject to other exceptions within the DIDP (such as, for example, where the contract contains information whose disclosure would be harmful to the security and stability of the Internet). CCWG-Accountability’s Implementation Guidance: As the recommendation starts with the language "wherever possible" we would recommend that ICANN publish a document clearly stating its position on the limited use of NDAs and documenting the information that will make available on its contracted relationships, as discussed below. In the first year of implementation ICANN should publish a register of all suppliers (name of supplier, country or origin and actual annual amount) it pays 500,000$US or more per fiscal year broken down by categories (e.g., computer equipment, software, telecommunication services, contracting etc.). Starting in the second year of implementation ICANN should lower this threshold to 250,000$US. The Board should review this threshold amount on a regular basis to effectively ensure transparency. In scoping ATRT4 or future ATRT reviews SO/ACs should consider if the information provided in the above Register meets their requirements. Should they feel the need for adjustments they should request the review consider this | Complete. Implementation documentation in progress. |
8.1.17 The DIDP should include a severability clause, whereby in cases where information under request includes material subject to an exception to disclosure, rather than refusing the request outright, the information should still be disclosed with the sensitive aspects severed, or redacted, if this is possible. | See implementation documentation. |
8.1.18 Where an information request is refused, or the information is provided in a redacted or severed form, the DIDP should require that ICANN’s response include the rationale underlying the decision, by reference to the specific exception(s) invoked, as well as information about appeal processes that are available. | See implementation documentation. |
8.1.19 The Ombudsman’s mandate regarding transparency should be boosted to grant the office a stronger promotional role, including by integrating understanding of transparency and the DIDP into ICANN’s broader outreach efforts, by publishing a list of the categories of information ICANN holds. | See implementation documentation. |
8.1.20 Either the Ombudsman or the Complaints Officer should be tasked with carrying out reasonable monitoring and evaluation procedures, such as publishing the number of requests received, the proportion which were denied, in whole or in part, the average time taken to respond, and so on. | See implementation documentation. |
8.1.21 ICANN should commit to reviewing the DIDP every five years. | See implementation documentation. |
8.2 Documenting and Reporting on ICANN’s Interactions with Governments | |
8.2.1 In the interest of providing the community greater clarity with regard to how ICANN engages government stakeholders and to ensure that the ICANN community and, if necessary, the Empowered Community is fully aware of ICANN’s interactions with governments, the CCWG-Accountability recommends that ICANN begin disclosing publicly the following (notwithstanding any contractual confidentiality provisions) on at least a yearly (but no more than quarterly) basis with regard to expenditures over $20,000 per year devoted to “political activities”,8 both in the U.S. and abroad:
This recommendation was overtaken by the implementation guidance provided by the CCWG-Accountability in Annex 9 of its Final Report. CCWG-Accountability Implementation Guidance: Note - This recommendation needs to be consistent with DIDP exceptions, specifically the exception which states: Information provided by or to a government or international organization, or any form of recitation of such information, in the expectation that the information will be kept confidential and/or would or likely would materially prejudice ICANN's relationship with that party (note - the WS2 Transparency recommendations for DIDP did not mention or modify this exception which is currently included in the DIDP and as such it would be expected to stand). The above discussion of DIDP policies is by way of explanation, and does not expand the application of this policy. Overall one must recognize that ICANN is a critical actor in the DNS and has significant expertise in the area. ICANN’s corporate objectives include a number of activities and programs to share this expertise with all interested parties including governments. As such any activities where ICANN is presenting information which is publicly available or which is part of formally published ICANN position on a subject through training programs, conferences or individual meetings should not be required to be disclosed beyond the reports which are currently published by ICANN and reports regarding bilateral conversations with governments. Note: Reporting on bilateral conversations can be found in the ICANN Quarterly Reports. Additional information on specifics of these reports can be requested via the DIDP subject to the stated exceptions. An example of such a report can be found at https://www.icann.org/en/system/files/files/quarterly-report-08may18- en.pdf page 29. To further facilitate the community’s understanding of ICANN’s objectives in discussions with governments it should publish an annual Government Engagement Strategy which should describe the focus of its interactions with governments for the coming year. This document should be derived from existing documentation including but not limited to annual planning, CEO reports to the Board and correspondence with the GAC. | See Implementation Documentation. |
8.3 Transparency of Board Deliberations | |
8.3.1 The DIDP exception for deliberative processes should not apply to any factual information, technical reports, or reports on the performance or effectiveness of a particular body or strategy, as well as any guideline or reasons for a decision which has already been taken or where the material has already been disclosed to a third party. This recommendation was overtaken by the implementation guidance provided by the CCWG-Accountability in Annex 9 of its Final Report. CCWG-Accountability Implementation Guidance: For the sake of greater clarity, current publications of Board Briefing Materials appear to fulfil this requirement Note: As ICANN organization points out, documents/information already provided to a third party (without obligation to keep as confidential) should not be withheld simply because of a deliberative process exception. | See Implementation documentation. |
8.3.2 The Bylaws should be revised so that material may only be removed from the minutes of Board meetings where it would be subject to a DIDP exception. Decisions to remove material from the minutes of Board meetings should be subject to IRP appeal. This recommendation was overtaken by the implementation guidance provided by the CCWG-Accountability in Annex 9 of its Final Report. CCWG-Accountability Implementation Guidance: The basis for redaction of Board minutes and withholding information from a DIDP request should be substantially consistent. For the most part this would seem to be the case including if the CCWG-Accountability recommendations which apply to the DIDP are implemented. As such ICANN should publish a register of all redaction of Board minutes explaining the basis for the redaction. Additionally, the register should explain how the basis for this redaction aligns with the DIDP exceptions and if it does not align with such an exception explain why. Note: Re IRP appeal – this is currently in the Bylaws | See Implementation documentation. |
8.3.3 Where material is removed from the minutes of Board meetings, the default should be to allow for its release after a particular period of time, once the potential for harm has dissipated. CCWG-Accountability Implementation Guidance: When redacting any information, the Board should identify if the redacted information can eventually be released or not (ICANN should publish the list of the classes of information which can never be disclosed by law, or other reasons, such as staff employment matters etc.). If redacted information is identified as eventually being subject to release it should identify the conditions which would allow the release (this information should be included in the above-mentioned Register). The CEO (or his/her designee) would annually review redacted information which is noted as being conditionally subject to release to see if the conditions for release are met and shall release all appropriate information and update the Register accordingly. For all redactions (other than those that are part of a category that can never be disclosed), the redacted material should be disclosed during the annual Register review process in the 15th year after the redaction was first entered onto the Register. | See Implementation documentation. |
8.4 Improving ICANN’s Anonymous Hotline (Whistleblower Protection) | |
8.4.1 The policy should be clearly posted as “Employee Hotline Policy and Procedures” on the ICANN public website under the “Who we Are” or “Accountability and Transparency” portions as soon as possible. | See implementation documentation. |
8.4.2 Related to the above, the term “whistleblower” should be included in introductory text explaining the policy so that an ICANN community member – who may not know that the policy is called a “Hotline Policy” – may easily locate it using “whistleblower” as the search term. For example: “The following outlines elements of ICANN’s Hotline Policy and Procedures. Some organizations refer to this as “whistleblower protections.” | See implementation documentation. |
8.4.3 The definition of incidents reported should be broadened from “serious issues” to encourage the report of all issues and concerns related to behavior that may violate local laws and conflict with organizational standards of behavior. Furthermore, the policy should provide specific examples of such violations to guide a potential reporter. | See implementation documentation. |
8.4.4 ICANN need to improve internal administration of the Hotline process by employing case management software to better enable tracking, documenting, reporting, and anticipating potential problem areas. | See implementation documentation. |
8.4.5 ICANN should regularly provide employees with data about use of the Hotline, that details not only the frequency of use but also the types of incidents reported. | See implementation documentation. |
8.4.6 ICANN should not prioritize receipt of reports as “urgent” and “non-urgent,” but treat every report as a priority warranting formal acknowledgment of receipt of a report within 48 hours at the latest. | See implementation documentation. |
8.4.7 ICANN needs to more effectively address potential fear of retaliation against the reporter by stating unequivocally that alleged retaliation will be investigated with the same level of rigor as alleged wrongdoing. ICANN should also guarantee remedy for reporters who suffer from retaliation as well as clarify that good-faith reporting of suspected wrong-doing will be protected from liability. | See implementation documentation. |
8.4.8 ICANN’s Hotline Policy and Procedures should undergo a third-party audit least every two years to help identify gaps and enable timely corrections. The audit, in turn, should be posted on the public website. | In progress. Tentative completion date: Q3 2024. |
Contact us at implementationoperations@icann.org