Org WS2 Implementation At A Glance

• Diversity recommendations 1.3, 1.4, 1.5 moved to in progress.
• Staff Accountability Recommendation 7.2.1 is complete through the release of the Assessment of ICANN Organization Evaluation of Information Acquisition Mechanisms for ICANN org Performance and Accountability to Stakeholders Implementation of Work Stream 2, Recommendation 7.2.1 page.
• Staff Accountability Recommendation 7.1.1 is complete through the release of the ICANN Organization Employee Practices and Resources page.  
• In addressing Recommendation 1.8, ICANN org released a Diversity at ICANN page, which includes links to community discussions, resources for community groups, and programs supporting participation at ICANN. This page also provides information about diversity, equity, and inclusion within ICANN org.
• Recommendation 4.1.3 is now in progress (9 May 2022)
• Recommendation 3.1 is marked complete (6 May 2022)

• Work Stream 2 Implementation Update (22 August 2022)
• Update on ICANN Work Stream 2 Implementation (2 May 2022)
• Update: Sharing Recent ICANN Work Stream 2 Implementation Progress (22 December 2021)
• Moving Work Stream 2 Implementation Forward (5 November 2021)
• Register for the ICANN Webinar on Work Stream 2 Implementation (10 May 2021)
• An Update on Work Stream 2 Implementation (4 March 2021)
• Moving Toward Implementation: Next Steps for Work Stream 2 (8 May 2020)

• ICANN 73 - ICANN Reviews and Implementation Status Update (24 February 2022)
• ICANN 72 - ICANN Reviews and Implementation Status Update (14 October 2021) 
• ICANN 71 - ICANN Reviews and Implementation Update (2 June 2021)
• An Update on Work Stream 2 Implementation (25 May 2021) 
  • Announcement
  • Zoom recording
• ICANN 70 - Status Update on ICANN Reviews and Implementation (10 March 2021)
• ICANN 69 - Update on ICANN’s Reviews (6 October 2020)

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.

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.

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.

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.

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.

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.

1.7 ICANN staff should support SO/AC/Groups in developing and publishing a process for dealing with diversity-related complaints and issues.

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.

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.

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.

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.

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.

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.

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.1.1 Menu Approach. The sub-group supports a “Menu” approach, where the governing law would be chosen before the contract is executed from a “menu” of possible governing laws. The menu needs to be defined; this could best left to ICANN and the registries. The sub-group discussed a number of possible menus, which could include one country, or a small number of countries, from each ICANN geographic region, plus the status quo (no choice of law) and/or the registry’s jurisdiction of incorporation and/or the countries in which ICANN has physical locations. The sub-group has not determined what the menu items should be, but believes there should be a balance between the advantages and disadvantages of having different governing laws apply to the same base RA, which likely suggests having a relatively limited number of choices on the menu. The sub-group recommends that the Registry choose from among the options on the menu (i.e., the choice would not be negotiated with ICANN). 
• 4.2.1.2 “California” (or “fixed law”) Approach. A second possible option is for all RAs to include a choice of law clause naming California and U.S. law as the governing law.  
• 4.2.1.3 Carve-Out Approach. A third possible option would be a “Carve-Out” approach, whereby parts of the contract that would benefit from uniform treatment are governed by a uniform predetermined law (e.g., California) and other parts are governed either by the law of the registry’s jurisdiction or by a jurisdiction chosen using the “Menu” approach. 
• 4.2.1.4 Bespoke Approach. In the “Bespoke” approach, the governing law of the entire agreement is the governing law of the Registry Operator. 
• 4.2.1.5 Status Quo Approach. A fifth possible approach is to retain the status quo, (i.e., have no “governing law” clause in the RAA).

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.

5.1 The Ombuds Office should have a more strategic focus.

5.2 The Ombuds office should include procedures that: 

• 5.2.1 Distinguish between different categories of complaints and explains how each will be handled. 
• 5.2.2 Set out the kinds of matters where the Ombuds will usually not intervene – and where these matters are likely to be referred to another channel (with the complainant’s permission) 
• 5.2.3 Provides illustrative examples to deepen understanding of the Ombuds’ approach.  

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.

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.

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.

5.6 The Office of the Ombuds should be configured so that it has formal mediation training and experience within its capabilities.

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.)

5.8 ICANN should establish an Ombuds Advisory Panel:

• 5.8.1 Made up of five members to act as advisers, supporters, and wise counsel for the Ombuds and should be made up of a minimum of at least two members with Ombudsman experience and the remainder with extensive ICANN experience. 
• 5.8.2 The Panel should be responsible for: 
• 5.8.2.1 Contributing to the selection process for new Ombuds, which would meet the various requirements of the Board and Community, including diversity 
• 5.8.2.2 Recommending candidates for the position of Ombuds to the Board. 
• 5.8.2.3 Recommending terms of probation to the Board for new Ombuds. 
• 5.8.2.4 Recommend to the Board firing an Ombuds for cause.
• 5.8.2.5 Contribute to an external evaluation of the IOO every five years. 
• 5.8.2.6 Making recommendations regarding any potential involvement of the IOO in non-complaint work based on the criteria listed in Recommendation 11. 
• 5.8.3 The Panel cannot be considered as being part of the Ombuds Office and cannot be considered additional Ombuds, but rather external advisors to the office. 
• 5.8.4 Any such advisory panel would require the Ombuds to maintain its confidentiality engagements per the Bylaws.

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.

5.9 The Ombuds employment contracts should be revised to strengthen independence by allowing for a:

• 5.9.1 Five-year fixed term (including a 12-month probationary period) and permitting only one extension of up to three years (the extension should be subject to a community-based feedback mechanism to the Advisory Panel covering Ombuds performance over the previous years).
• 5.9.2 The Ombuds should only be able to be terminated with cause.

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.

5.11 The following points should be considered and clarified publicly when looking at the Ombuds’ involvement in any non-complaints work:

• Whether there is unique value that the Ombuds can add through the proposed role or function?
• Whether the proposed reporting/accountability arrangements may compromise perceived independence? 
• Whether the workload of the proposed role/function would limit the Ombuds ability to prioritize their complaints-related work? 
• Whether any Ombuds’ involvement with the design of new or revised policy or process, meets the requirement of not, in any way, creating a “stamp of approval”? 
• Whether the proposed Ombuds input may be seen as a “short-cut” or substituting for full stakeholder consultation?

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.

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.

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: 

• 7.1.1.1 Description of the organization’s performance management system and process. 
• 7.1.1.2 Description of how departmental goals map to ICANN’s strategic goals and objectives. 
• 7.1.1.3 Description of the Complaints Office and how it relates to the Ombuds Office. 
• 7.1.1.4 Organization policies shared with the CCWG-Accountability during the course of the WS2 work. 
• 7.1.1.5 ICANN Organization Delegations document. 
• 7.1.1.6 The roles descriptions included in this overall report. 
• 7.1.1.7 Expectations and guidelines regarding the development of staff reports for Public Comments, or staff response to Community correspondence. 

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:

• 7.2.1.1 A regular information acquisition mechanism (which might include surveys, focus groups, reports from the Complaints Office) to allow the ICANN organization to better ascertain its overall performance and accountability to relevant stakeholders. 
• 7.2.1.1.1 The group notes that several new mechanisms are now established, but have not yet been exercised enough to determine effectiveness or potential adjustments. The evaluation mechanism proposed here would be helpful in determining effectiveness of these recent mechanisms before creating yet more mechanisms that may turn out to be duplicative or confusing for the organization and community. 
• 7.2.1.2 Results of these evaluations should be made available to the Community. 

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.

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. 

8.1.1 The caveat that the DIDP applies only to “operational activities” should be deleted. 

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.

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. 

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. 

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.

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. 

8.1.7 The phrase “to the extent feasible, to reasonable requests” should be deleted from the provision on Responding to Information Requests. 

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. 

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. 

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. 

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.” 

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. 

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.

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.” 

8.1.15 ICANN should consider future processes to expand transparency at ICANN Legal, including through clarification of how attorney-client privilege is invoked.

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

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.

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. 

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. 

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. 

8.1.21 ICANN should commit to reviewing the DIDP every five years.

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:

• 8.2.1.1 All expenditures on an itemized basis by ICANN both for outside contractors and internal personnel. 
• 8.2.1.2 All identities of those engaging in such activities, both internal and external, on behalf of ICANN. 
• 8.2.1.3 The type(s) of engagement used for such activities.
• 8.2.1.4 To whom the engagement and supporting materials are targeted. 
• 8.2.1.5 The topic(s) discussed (with relative specificity).

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.

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.

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

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.

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.

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.”

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.

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.

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.

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.

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.

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.