ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
SourceSSR2 Section or RecReport SectionCommentResponseChangeAssigned to
2
ICANN Board0While in no way criticizing the approach the SSR2 RT took to establish the priorities they assigned, the Board encourages the SSR2 RT to consider relevant factors such as dependencies and relationships with other community work, determination of effort, as compared to expected impact of implementation work, or degree of complexity, among others, in order to categorize each recommendation as ‘high priority’, ‘medium priority’, or ‘low priority’. This analytical and tiered approach will provide a more useful guideline for planning timely implementation of the recommendations.ALL subteams need to consider dependencies



** COME BACK for the priority **
3
RrSG0It is not clear how the recommendations below will be carried out. While some recommendations are directed to the ICANN Board or ICANN Org (and within their remit, e.g. audit of Compliance or staffing), many of the recommendations would need to to go through the PDP process to avoid having ICANN org creating policy. Those recommendations that include policy elements should be referred to the GNSO Council for further action.ALL subteams highlight any actions that are expected to initiate a PDP
4
RySG0the proposed recommendations would benefit from an explicit statement of the problem that each over-arching recommendation is intended to address.ALL subteams need to state the expected benefit from implementing the recommendation or expected harm if the recommendation is not implemented
5
BC1Complete the implementation of all relevant SSR1 recommendationsThe BC believes this is critical. ICANN Org has incorrectly represented these recommendations as implemented, when in fact practically none are completed. These recommendations are nearly eight years old, and the time has long since passed for their implementation.We believe that a prompt implementation of Suggestion 2 will allow the ICANN community to track the implementation of recommendations of all review teams, not just SSR. The tracking and visibility will allow the ICANN community to raise concerns much earlier in the timeline.Updated wording to Suggestion 2.
6
M3AAWG1Complete the implementation of all relevant SSR1 recommendations. (1) Implement SSR1 RT recommendations and other, prior recommendations from ICANN advisory committees, as directed by the ICANN Board.Thank you.None.
7
SSAC1Complete the implementation of all relevant SSR1 recommendations. (3.1.1) It would be helpful for the SSR2 final report to provide a more thorough clarification of the reasons why these SSR1 recommendations are, in SSR2 RT’s opinion, not fully implemented.We believe that ICANN org should conduct a comprehensive assessment of the SSR1 recommendation implementation, and then from that develop a plan to finish the job, and then execute the plan.Update wording to Recommendation 1.
8
SSAC1Complete the implementation of all relevant SSR1 recommendations. (3.1.2) The SSAC has some concerns about the viability of implementation of such a significant list of actions. Specifically, the SSAC is concerned about the extent, cost, sequence, and timeframe of the necessary actions required to implement all of these recommendations. Are there other measures that the SSR2 RT may wish to propose that would give the 135 proposed recommendations a significant prospect of avoiding the same incomplete fate as the 27 outstanding SSR1 recommendations by the time of the next SSR review?SSR2 believes that all of the recommendations are aligned with the ICANN strategic plan, and as a result, all of these recommendation should be fully implemented. Obviously, the resources to do that implementation must be allocated by the ICANN Board.None.
9
NCSG1Complete the implementation of all relevant SSR1 recommendations The NCSG considers of vital importance to implement the recommendations from SSR1 that have not been implemented yet, especially Recommendations 9 and 6. In fact, the team found that 26 SSR1 recommendations were not completely implemented and 2 haven’t been implemented at all. Therefore, the NCSG invites ICANN board/Org to provide justifications on those matters and take immediate actions to start their implementation in a timely manner. Moreover, the SSR review Team noted that there are four repeating issues (page 22 and 23 of the draft report subjected to this call for Public Comment). We would like to ask ICANN’s Board what actions they will be taking in order to prevent such a situation from occurring again in the future. The affected SSR1 recommendations are the numbers #9, #12, #15, #16, #20, #22, #27, they have now been re-addressed in the recommendations 1 to 5 of the SSR2 that were reviewed by the WS1 team.Thank you.None.
10
ICANN Board1Complete the implementation of all relevant SSR1 recommendations To that end the Board encourages the SSR2 RT to provide for each SSR1 recommendation an analysis of why it believes that ICANN org’s implementation efforts do not meet the intent of the recommendation, specific details as to what the SSR2 RT sees as the outstanding issues or risks for each SSR1 recommendation, how the SSR2 RT suggests each recommendation should be addressed considering the extensive developments that may have impacted the recommendations issued nearly eight years ago, and what relevant metrics could be applied to assess implementation in the future.SSR2 believes that all of the recommendations are aligned with the ICANN strategic plan, and as a result, all of these recommendation should be fully implemented. Obviousley, the resources to do that implementation must be allocated by the ICANN Board.Update wording to Recommendation 1.
11
RrSG1Complete the implementation of all relevant SSR1 recommendations The RrSG agrees with this recommendation.Thank you.None.
12
ICANN Org1The SSR2 RT strongly recommends that the ICANN
Board and ICANN org complete the implementation of the SSR1
Recommendations.		ICANN org encourages the SSR2 RT to provide for each SSR1 recommendation:
● An analysis of why it believes that ICANN org’s implementation efforts do not meet the intent of the recommendation.
● Specific details as to what the SSR2 RT sees as the outstanding issues or risks for each SSR1 recommendation.
● Clarification on how the SSR2 RT suggests each recommendation should be addressed considering the extensive developments that may have impacted the recommendations issued nearly eight years ago.
● Relevant metrics that could be applied to assess implementation in the future.		We believe that ICANN org should conduct a comprehensive assessment of the SSR1 recommendation implementation, and then from that develop a plan to finish the job, and then execute the plan.Updated wording to Recommendation 1.
13
RySG1Complete the implementation of all relevant SSR1 recommendations. Unless indicated elsewhere in our comments, the RySG supports the implementation of all relevant
recommendations.		Thank you.None.
14
GAC1Complete the implementation of all relevant SSR1 recommendations. the report could provide a more detailed assessment clarifying the reasons why the SSR1 recommendations are deemed to not have been fully implemented. This would be also relevant due to the large number of recommendations especially if take into account both the SSR1 and SSR2 recommendations (combined, they amount to 53 main recommendations and this number is even higher if we take each specific item of the SSR2 report into consideration).We believe that ICANN org should conduct a comprehensive assessment of the SSR1 recommendation implementation, and then from that develop a plan to finish the job, and then execute the plan.Updated wording to Recommendation 1.
15
IPC1The IPC is supportive of this recommendation, and discusses its support for this recommendation in greater detail below.
It is the IPC’s position that these outstanding SSR1 recommendations must be implemented and are critical to the effective implementation of any new SSR2 recommendations. As the RT finds 27 of the initial 28 recommendations to still be relevant, the IPC strongly supports the recommendation that all relevant SSR1 recommendations be expeditiously implemented.		Thank you.None.
16
SSAC1(3.1.3) The SSAC believes that with so many recommendations from both reports where there appears to be overlap or adjacency between recommendations in SSR1 and SSR2 that they should group them accordingly, ensure that they are in fact distinct recommendations and not duplicates, and that the proposed actions and deliverables are unique. A table and categories for each class of recommendations in the reports would likely serve both the RT and the audience well.The SSR2 RT has merged related recommendations.**** list items that got merged after all of the subteams are finishedHeather
17
BC2SSR1 Recommendation 9 -Information Security ManagementSystems and Security CertificationsThe BC concurs with this recommendation.
18
SSAC2SSR1 Recommendation 9 - Information Security Management Systems and Security Certifications(3.1.3) Given that Recommendation 1 of the SSR2 report recommends the completion of the SSR1 recommendations, and Appendix D of the SSR2 report contains further details relating to findings and conclusions, including SSR1 Recommendation 9, SSR2 Recommendation 2 seems duplicative.
19
NCSG2SSR1 Recommendation 9 - Information Security Management Systems and Security Certifications#Recommendation 2 requires ICANN to conduct periodic reviews, audits, etc. of their system’s security, stability, and resiliency. We would like to suggest that the review team proposes a specific cycle to conduct the checks. The NCSG suggests that they are conducted on a yearly basis.
20
RrSG2SSR1 Recommendation 9 - Information Security Management Systems and Security CertificationsIt makes sense for ICANN Org to be certified for key critical certifications like ISO 27001 and 27701. Such certifications will advance ICANN Org as an organization in terms of data protection and system security.
Contracted parties will also benefit if ICANN ORG has certification like ISO 27001 and 27701 regarding their accountability towards compliance with laws or if they use such certifications themselves.
ICANN Org management, the CEO, and the ICANN Board most fully support such certifications. The ICANN Board should adopt an accountability oversight mechanism for the Board members.
21
ICANN Org2SSR1 Recommendation 9 - Information Security
Management Systems and Security Certifications		ICANN org considers this recommendation to already be implemented and asks the SSR2 RT to clarify the observed issue or risk, clearly identify a desired outcome and describe how success will be measured. (See supporting detail in the public comment report)
22
RySG2The RySG supports this recommendation.
23
IPC2The IPC is supportive of this recommendation.
24
BC3SSR1 Recommendations 12,15, and 16 - SSR Strategy and Framework, Metrics, and Vulnerability DisclosuresThe BC concurs with this recommendation.
25
SSAC3SSR1 Recommendations 12,15, and 16 - SSR Strategy and Framework, Metrics, and Vulnerability Disclosures(3.1.4) Given that Recommendation 1 of the SSR2 report recommends the completion of the SSR1 recommendations, and Appendix D of the SSR2 report contains further details relating to findings and conclusions, including SSR1 Recommendations 12, 15, and 16, SSR2 Recommendation 3 seems duplicative.
26
NCSG3SSR1 Recommendations 12,15, and 16 - SSR Strategy and Framework, Metrics, and Vulnerability Disclosures#Recommendation 3 requires ICANN to elaborate the framework and agree with the Metrics and Vulnerability Disclosure. We believe that this process should be done in collaboration with the community represented through the SGs.
27
RrSG3SSR1 Recommendations 12,15, and 16 - SSR Strategy and Framework, Metrics, and Vulnerability DisclosuresThe RrSG doubts that such methods can be applied on a global level without discriminating against certain regions and/or creating high costs for specific contracted parties in certain areas.
Modification of the contracts and agreements should not go through a consensus document process. The output from such consensus documents can be considered during arrangements negotiations like any other discussion points during such negotiations.
28
RySG3SSR1 Recommendations 12,15, and 16 - SSR Strategy and Framework, Metrics, and Vulnerability DisclosuresThe RySG generally supports this recommendation.
However, the RySG notes that contract changes can be triggered only by Consensus Policy or contract
negotiations. Further, the RySG suggests that the recommendation clarify that the vulnerability
disclosure reporting is for the ICANN organization and that ICANN is not a general clearinghouse for
vulnerability reports for all contracted parties - those should be directed to the relevant party.
29
IPC3The IPC is supportive of this recommendation.
30
SSAC3.1ICANN org should address security issues clearly, publicly (with consideration for operational security, e.g., after an established moratorium and anonymization of the information, if required), and promote security best practices across all contracted parties.(3.1.5) This recommendation prompted several questions from the SSAC: How does this differ from current ICANN org procedures? What factors led the SSR2 RT to reach this conclusion? Is there an inference that ICANN org has not addressed security issues? The second part of the recommendation relating to promoting security best practices appears to be a distinct issue and merits further clarification. Is ICANN org deficient in this area, and does the SSR2 RT propose actions that would implement their recommendation? Specifically, where are the gaps in capabilities and actions by ICANN org or community in this area? What specific best practices does the SSR2 RT believe should be developed or implemented to address such gaps, and what do they envision as a useful framework to catalog, share, and enhance operational best practices related to a given topic that is relevant to the ICANN community?
31
SSAC3.2ICANN org should also capture SSR-related best practices in a consensus document, establish clear, measurable, and trackable objectives, and then implement the practices in contracts, agreements, and MOUs(3.1.6) The SSAC believes that this recommendation is not practical and cannot be implemented in a reasonable time frame. ...
There is a definite need to consider new security-related policies that could become binding for ICANN’s contracted parties, but the proposed process using a consensus approach drawn from a very broad community of diverse interests does not appear to be an optimal solution.
32
ICANN Org3.2SSR Recommendation 3.2: “SSR-related best practices”Requests for clarification of terms
33
SSAC3.3ICANN org should implement coordinated vulnerability disclosure reporting. Disclosures and information regarding SSR-related issues should be communicated promptly to trusted, relevant parties (e.g., those affected or required to fix the given issue), such as in cases of breaches at any contracted party and in cases of key vulnerabilities discovered and reported to ICANN org. (3.1.7) The actions in this recommendation are unclear. SSAC understands that ICANN org has, appropriately, already implemented responsible disclosure on a need-to-know basis. What is ICANN org not doing at present that it should do? How does one measure whether the reporting is done appropriately or not when such disclosures cannot necessarily be open disclosures?
34
SSAC3.4ICANN org should establish a clear communication plan for reports to the community and produce regular (at least annual) and timely reports containing anonymous metrics of the vulnerability disclosure process. These communiques should contain responsible disclosure as defined by the community-agreed process and include anonymized metrics.(3.1.8) SSAC understands that ICANN org has established a vulnerability disclosure process. What aspects of this recommendation differ from ICANN org’s current practices?
35
ICANN Org3.4ICANN org should establish a clear communication plan for reports to the community and produce regular (at least annual) and timely reports containing anonymous metrics of the vulnerability disclosure process. These communiques should contain responsible disclosure as defined by the community-agreed process and include anonymized metrics.ICANN org asks the SSR2 RT to clarify which “community-agreed process” this recommendation refers to. ... If the SSR2 RT believes additional improvements are needed, ICANN org asks that the SSR2 RT identify what gaps exist that the Cybersecurity Incident Log does not address.
36
BC4SSR1 Recommendation 20 and 22 - Budget Transparency and Budgeting SSR in new gTLDsThe BC concurs with this recommendation. Budget transparency would provide a clear indicator of ICANNOrg’s prioritization of SSR-related recommendations.However, the BC disagrees with the concept that ICANN may be less transparent according to level of effort involved, as a subjective determination--ICANN must strive for transparency throughout each of its processes.Thank you, we clarified.
37
SSAC4SSR1 Recommendation 20 and 22 - Budget Transparency and Budgeting SSR in new gTLDs(3.1.9) Given that Recommendation 1 of the SSR2 report recommends the completion of the SSR1 recommendations, and Appendix D of the SSR2 report contains further details relating to findings and conclusions, including SSR1 Recommendations 20 and 22, SSR2 Recommendation 4 appears duplicative. Please see the SSAC’s feedback in 3.1.3 regarding the overlap or adjacency between recommendations in SSR1 and SSR2.Thank you, we addressed this by providing a new structure.
38
NCSG4SSR1 Recommendation 20 and 22 - Budget Transparency and Budgeting SSR in new gTLDs#Recommendation 4 deals with Budget Transparency and Budgeting SSR in the new gTLDs. We suggest that the SSR2 team check how or whether this is related or could be integrated into the ongoing work of the new gTLDs PDP working group.Thank you, we have reached out.
39
RrSG4SSR1 Recommendation 20 and 22 - Budget Transparency and Budgeting SSR in new gTLDsThe RrSG supports this recommendationAppreciated
40
RySG4SSR1 Recommendation 20 and 22 - Budget Transparency and Budgeting SSR in new gTLDsThe RySG supports this recommendation.Appreciated
41
IPC4The IPC is supportive of this recommendation.
Budget transparency would be helpful in reflecting ICANN’s commitment to SSR recommendations, however the opening language of this recommendation (e.g., “Where possible” and “reasonable in terms of effort”) leaves open the possibility that ICANN could circumvent the transparency intended by this recommendation.		Thank you, we clarified.
42
ICANN Org4.1Where possible (contractually) and reasonable in terms of effort (i.e., over 10% of the activity described in the budget line item), ICANN should be more transparent with the budget for parts of ICANN org related to implementing the Identifier Systems Security, Stability, and Resiliency (IS-SSR) Framework and performing SSR-related functions, including those associated with the introduction of new gTLDs....If the SSR2 RT does not consider the current operational model to meet the requirements of SSR2 recommendation 4.1, ICANN org asks the SSR2 RT to provide details as to how it suggests this recommendation should be addressed considering the developments that have occurred since the SSR1 recommendation issued nearly eight years ago, and what relevant metrics could be applied to assess implementation in the future.Thank you, we added language.
43
BC5SSR1 Recommendation 27 - Risk ManagementThe BC concurs with this recommendation.AppreciatedNo action
44
SSAC5SSR1 Recommendation 27 - Risk Management(3.1.10) Given that Recommendation 1 of the SSR2 report recommends the completion of the SSR1 recommendations, and Appendix D of the SSR2 report contains further details relating to findings and conclusions, including SSR1 Recommendation 27, SSR2 Recommendation 5 appears duplicative.
The SSAC is aware that ICANN org maintains a centralized risk matrix. To what extent do the measures proposed in SSR2 Recommendation 5 differ from current practice within ICANN org? What is the failing in the organisation's policies and procedures that motivate this recommendation? Please see the SSAC’s feedback in 3.1.3 regarding the overlap or adjacency between recommendations in SSR1 and SSR2.		See actionUnderline importance of documentation and audits as main issue we identified. Cannot assess quality without. Lack of clear process, procedures, and documentation that could not be demonstrated.
45
RrSG5SSR1 Recommendation 27 - Risk ManagementThe RrSG supports this recommendation, which should build upon ICANN Org existing risk management structure.See actionmention the use of current system going forward, intent was not replacement.
46
ICANN Org5SSR1 Recommendation 27 - Risk ManagementICANN org considers this recommendation already to be implemented and asks the SSR2 RT to clarify the observed issue, clearly identify a desired outcome, and describe how success will be measured.See actionUnderline importance of documentation and audits as main issue we identified. Cannot assess quality without. Lack of clear process, procedures, and documentation that could not be demonstrated.
47
RySG5The RySG supports this recommendation and suggests that it is bundled with recommendations 7, 8
and 9.		Mergedmerge BC/DR
48
IPC5The IPC is supportive of this recommendation.Appreciatedno action
49
BC6Create a Position Responsible for Both Strategic and Tactical Security and Risk ManagementThe BC concurs with this recommendation and further recommends this position be installed as an executive at the C-level of ICANN.This was the intent, see minor amendment. Confirm language is clear.
50
SSAC6Create a Position Responsible for Both Strategic and Tactical Security and Risk Management(3.2.1) The SSAC believes that it would be helpful to understand the context of this recommendation in the light of the existing organisational structure and capabilities of ICANN org.An explnanation has been added.Security should be at the top, not hidden under someone else. Reference clause 6.1 ISO27001 add NIST? We have intention to have this person lead and consult on contracts, etc. Regardless of what ICANN is, this is best practice literally everywhere; this person should oversee audit, not CTO. General oversight is important.
51
NCSG6Create a Position Responsible for Both Strategic and Tactical Security and Risk Management#Recommendation 6: recommends ICANN to create a C-suite position for Risk Management or within C-Suite for Strategy. We acknowledge that and recommend that the Review team draft a job description that could fit the role. This job description could be appended to the final report.We feel the ORG and board should create this function. There is clear guidance in relevant standards. Reference is made to the inclusion of a reference to NIST 800-53, which describes roles for risk management controlsJob is not to create that, board task. Board and org should prioritize security. Look at best practices, look at standards.
52
ICANN Board6Create a Position Responsible for Both Strategic and Tactical Security and Risk ManagementAs noted above, as a general observation on the formulation of draft recommendations, the Board encourages the SSR2 RT to provide specific details as to what issues or risks the SSR2 RT has identified with the current operations, how the SSR2 recommendation will address these issues or risks, and what relevant metrics could be applied to assess implementation.It is important to note that what the SSR2 has identified is the absence of a role that is considered indispensable in large organizations that manage critical information infrastructure. The identification of the absence of this dedicated role is one of the risk identified by the Review team as the absence of this key critical security functions cannot be coordinated effectively.The review team is not meant to do the risk analysis, the team is not even claiming that ICANN is missing risks. The report focuses on "meta" issues, i.e. the lack of process and documentation presented during the review. Refer to relevant publications by ISO and NIST regarding how to assess and _document_ these tasks.
53
RrSG6Create a Position Responsible for Both Strategic and Tactical Security and Risk ManagementThe RrSG agrees that there should be a position responsible for strategic and tactical security and risk management; it is not clear why this does not already exist. If the fucntion does not already exist, it seems to be a function that fits within the OCTO remit, and so should be part of that team. The RrSG does not consider this specific recommendation as one that requires a PDP; this is something that ICANN Org and the Board can do directly.CSO is not supposed to be that low, best practice. see proposed clarification at 6.2Security should be at the top, not hidden under someone else. Reference clause 6.1 ISO27001 add NIST? We have intention to have this person lead and consult on contracts, etc. Regardless of what ICANN is, this is best practice literally everywhere; this person should oversee audit, not CTO. General oversight is important.
54
ICANN Org6Create a Position Responsible for Both Strategic and Tactical Security and Risk ManagementICANN org encourages the SSR2 RT to provide specific details as to what issues, risks, or gaps the SSR2 RT has identified with the current operations, how the SSR2 recommendation will address these issues, risks, or gaps, and what relevant metrics could be applied to assess implementation.See amendments suggested in rationale and findingsThe review team is not meant to do the risk analysis, the team is not even claiming that ICANN is missing risks. The report focuses on "meta" issues, i.e. the lack of process and documentation presented during the review. Refer to relevant publications by ISO and NIST regarding how to assess and _document_ these tasks.
55
RySG6Create a Position Responsible for Both Strategic and Tactical Security and Risk ManagementThe RySG does not support this recommendation.
We agree that ICANN may not currently have one single-threaded owner for SSR-related work and budgets (though we agree OCTO is performing some of these functions and the Board or Finance are performing others), but we believe this can be accomplished with the resources available. Given there is a distinction between the management of internal ICANN IT systems that seems to be under the purview of ICANN’s Chief Information Officer and ICANN’s responsibility for the security and stability of the DNS that is the remit of the Chief Technology Officer, perhaps it would be more realistic to recommend more transparency of areas of duplication and clarity as to lines of responsibility.		SSR2 Team, notes the concerns raised by RySG and would like to reiterate that while these functions can be found in various existing positions within ICANN Org, the SSR2 believes that this function needs to be at a strategic level where the risk controls can be interwoven organization wide.This is not about resources but about orgnization, refer also to previous comments. OCTO staff etc could simply be move in org.
56
IPC6The IPC is supportive of this recommendation, and discusses its support for this recommendation in greater detail below.
The IPC supports the SSR2 RT’s recommendation that a C-Suite level executive officer position be created to coordinate and strategically manage ICANN’s security and risk management objectives. As the RT points out, the current system that decentralizes the roles related to SSR across two separate units within ICANN appears unlikely to be effective. The IPC agrees with this assessment, particularly in light of ICANN’s failure to efficiently implement the SSR1 objectives that have been outstanding since 2012. It is the hope of the IPC that a designated officer, supported by a sufficient budget and staff, will be able to more efficiently prioritize and implement these critical security and risk management activities for which ICANN is responsible. Accordingly, the IPC is strongly supportive of the RT’s recommendations related to this new position, including SSR2 Recommendation 7: “Further Develop a Security Risk Management Framework.”		SSR2 duly notes the support. LanguageNote inefficiency of arrangement.
57
BC7Further Develop a Security Risk Management Framework The BC concurs with this recommendation. In particular, the BC agrees with the recommendation regarding measurement. Too often, ICANN does not benefit from measurement data that could help mitigate abuse, improve processes, inform policymaking, or otherwise assist the community. The BC concurs with the RDS2 RT’s previous recommendation that all new policies include tracking metrics to understand the policy’s efficacy; measurement of success, therefore,is an important part of the SSR2 RT’s recommendation here. ICANN should endeavor to source these metrics internally rather than soliciting less-than-reliable, self-reported information from the community.Appreciated, metrics included in text.ICANN should source metrics internally where possible, if only to provide multiple points of measurement.
58
SSAC7Further Develop a Security Risk Management Framework (3.2.2) This is a restatement of Recommendation 5 and it is unclear what objective is achieved through this repetition. The SSAC comments in relation to Recommendation 5 apply here, including the tensions relating to the levels of open disclosure of risk profiles. An appropriate attitude to risk is that an organisation’s activities should be informed by risk, but not necessarily fully dictated by considerations of risk. This is the opposite of the direction espoused by recommendation 7.3.2. The SSAC suggests that the report should clarify what is being requested here and clearly identify how this recommended action and the associated deliverables differ from related recommendations in this report.TBCConsider structure: 5&7 how to tell the SSR1-SSR2 narrative? The key is to establish a clear process and structure for risk, etc. Regular third party audit would help support this structure. The board should consider what systems / sites / etc. are relevant and should be organized according to best practice. ICANN can be certified according to ISO 27k etc, and moreso implement these standards. SSR2 cannot see any good reason for ICANN to follow international standards considering the DNS criticality. Furthermore, far larger organizations are certified and there are many examples of DNS players using these standards. Third party audit allows proper checks on these controls, policies, etc. Would put ICANN, board, and community in check. Keep in mind this is critical infrastructure.
59
RrSG7Further Develop a Security Risk Management Framework This recommendation seems redundant with recommendation 2. Audits and an ISMS are part of the ISO certification, so this level of detail seems excessive. Everything in this recommendation is something that ICANN should do for recommendation 2.The team is aware that this is technically required but aims to give some details to staff and community on what we consider the most important aspects.
60
ICANN Org7SSR2 Recommendation 7: “security risk management”Requests for clarification of termss.b.
61
ICANN Org7Further Develop a Security Risk Management Framework As noted above, ICANN org seeks clarification as to what is meant by “security risk management” as opposed to risk management more generally. The main elements and outcomes of ISO 31000 are included in the ICANN org’s risk management framework. Under the framework, ICANN org uses its own in-house resources to achieve the same outcomes in a fit-for-purpose way. In this regard, ICANN org considers parts of this recommendation to be duplicative of SSR2 Recommendation 5.Rec 5 was follow up and has been removed. Check rewrite for clarity.
62
RySG7The RySG supports this recommendation and suggests that it is bundled with recommendations 5, 8 and 9.Merging BC/DR but keeping risk separate. It is a different process that enables BC DRmerge BC/DR Risk separate
63
IPC7The IPC is supportive of this recommendation.Appreciated
64
BC8Establish a Business Continuity Plan Based on ISO 22301The BC concurs with this recommendation.Appreciated
65
RrSG8Establish a Business Continuity Plan Based on ISO 22301With the exception of 8.3, this recommendation seems redundant with recommendation 2, which would require ICANN do to this for ISO certification.
Clarified.Certification and adherence are different things but both matter. Narrative: follow procedure. Action: look at rec 2 together with 6,7,8,9. Possibility to restructure / clarify.
66
ICANN Org8Establish a Business Continuity Plan Based on ISO 22301This recommendation mentions Disaster Recovery and Business Continuity Planning. ICANN org considers the recommendation regarding disaster recovery already to be implemented. ICANN org has established disaster recovery and continuity plans for systems for ICANN org and IANA functions. Due to potential risks of providing attackers with information to facilitate attack, documents regarding disaster recovery and continuity planning are confidential. The Board has oversight responsibility for ensuring that these programs are in place.
ICANN org supports the recommendation to establish a Continuity Plan for all of ICANN org. Such a Continuity Plan is currently under development as part of the ICANN org’s Risk Management Framework.		Clarify team's narrative: Only evidence is from 2017, is this up to date right now, documented, etc. This is not sufficient. Third party, redacted report would have been fine. Industry standard is to do this regularly (1/y) and document. see action
67
RySG8Establish a Business Continuity Plan Based on ISO 22301The RySG supports this recommendation and suggests that it is bundled with recommendations 5, 7 and 9.Done5 has been removed, restructure rest, merge BC/DR
68
IPC8The IPC is supportive of this recommendation.Appreciated
69
RrSG8.3For Public Technical Identifiers (PTI) operations (IANA functions, including all relevant systems that contribute to the Security and Stability of the DNS and also Root Zone Management), ICANN org should develop a shared approach to service continuity in close cooperation with the Root Server System Advisory Committee (RSSAC) and the root server operatorsThe RrSG supports recommendation 8.3.Appreciated
70
BC9Ensure the Disaster Recovery Plan is Appropriate, Functional, and Well DocumentedIn general, the BC supports Recommendation 9. However, we suggest ICANN should develop and manage an ISO 22301 Business Continuity Management Systems (BCMS), which clearly indicate regular testing of disaster recovery sites and publishing test results within a specified period to all stakeholders as required. The BC also suggests regular internal auditing to prepare adequately for external audits and certification. We also recommend that the implementation team undergo individual certification in ISO 22301/ISO 27031 Implementation and Lead Auditor (I & L.A) program to prepare them in the efficient implementation of Business Continuity Plan (BCP).Thank you, clarified and expanded based on your comment. Clarify our position using their language
71
RrSG9Ensure the Disaster Recovery Plan is Appropriate, Functional, and Well DocumentedThis recommendation seems redundant with recommendation 2, which would require ICANN do to this for ISO certification.Clarified.Certification and adherence are different things but both matter. Narrative: follow procedure. Action: look at rec 2 together with 6,7,8,9. Possibility to restructure / clarify.
72
ICANN Org9Ensure the Disaster Recovery Plan is Appropriate, Functional, and Well DocumentedAs noted with regard to SSR2 Recommendation 8, ICANN org considers this recommendation already to be implemented. Further, ICANN org encourages the SSR2 RT to include a clear justification as to why it believes the benefits of a third disaster recovery site justifies the costs of such a site.see actionClarify: team wants geographical dispersal, different jurisdictions, this is not about the number of sites but that currently two of them are in the same country and jurisdiction and the same continent. ICANN supports a key system that is one level above normal BC/DR requirements (critial infrastructure). Two sites in the United States might be redundant, instead do one there and one in Europe/Asia/Africa? THis would give greater geographical dispersal, plus jurisdiction difference (think travel bans). Suspected compromise of procedure would be a huge issue.
73
RySG9Ensure the Disaster Recovery Plan is Appropriate, Functional, and Well DocumentedThe RySG supports this recommendation and suggests that it is bundled with recommendations 5, 7 and 8.Clarified.Action: look at rec 2 together with 6,7,8,9. Possibility to restructure / clarify.
74
IPC9The IPC is supportive of this recommendation.Appreciated
75
BC10Improve the Framework to Define and Measure Registrar & Registry Compliance The BC concurs with this recommendation and encourages both staff and the Board to take active roles in their implementation. ICANN’s compliance function needs improvement, both in the manner in which it is staffed and in the tools it has available to correct problematic behavior on the part of contracted parties or their customers.This recommendation, correctly implemented, would have a lasting impact on ICANN Org’s capability to address abuse and ensure security and resilience.The BC further agrees with the specific recommendation about bringing the EPDP to a close and implementing WHOIS policy. All parties need and deserve the predictability that will come with a fully implemented policy.AgreeSee SMART table. For all recommendations: Add more detail on why we recommend, and why it makes sense, define objective for ICANN. Additionally: Board should go beyond pain points, some of this is not part of SSR review team work - this is about raising the bar not fixing one thing, awareness of best practices and industry standards seems to be lacking (which is a problem). Other organizations use internal audit (as is required for/by many industries). SSR2 is giving nice advice, this should be managed internally without such reviews.
76
SSAC10Improve the Framework to Define and Measure Registrar & Registry Compliance (3.3.2) Unless the underlying contractual commitments exist to compel contracted parties to act within clearly defined parameters and responsibilities, then the compliance measures proposed here seem ineffectual. Does the SSR2 RT believe that these contracts are sufficiently prescriptive with respect to behaviours and the residual issue is simply one of enforcement of compliance? As the report notes, “Compliance has few options to enforce the agreements” and the measurements proposed in this recommendation appear to 5 measure ineffectuality of enforcement. Are there measures that could have a beneficial outcome on improving this space?Agree; clarified text
77
NCSG10Improve the Framework to Define and Measure Registrar & Registry Compliance #Recommendation 10: The SSR2 team justifies, elaborates more, analyzes impact and compares what they are recommending here to the current modes of operations. We also note that the recommendation strays into suggesting board action on areas which the review team is not empowered to comment on such as current GNSO policymaking.Disagree, see explanation. Clarify what requires Board, staff and contracted party action and what requires PDP
78
RrSG10Improve the Framework to Define and Measure Registrar & Registry Compliance In general, this recommendation is for policy and should go through the ICANN policy process. Regarding the sub recommendations:



Disagree, see explanation. Clarify what requires Board, staff and contracted party action and what requires PDP
79
RySG10Improve the Framework to Define and Measure Registrar & Registry Compliance The RySG notes that Compliance’s size and scope has grown exponentially in recent years and we disagree with SSR2’s characterization and implication that contractual compliance is so under-enforced or under-resourced that entire new teams need to be hired to deal with specific issues. We note this throughout the report, but call it out specifically here.
80
IPC10The IPC is generally supportive of this recommendation, and discusses its support for this recommendation in greater detail below.
The RT recommends, and the IPC supports, several methods for ICANN to better utilize its relationships
with the Registrars and Registries to combat DNS abuse, including SSR2 Recommendation 10: “Improve
the Framework to Define and Measure Registrar & Registry Compliance,” SSR2 Recommendation 15:
“Enhance Contracts with Registrars and Registries to Incent the Mitigation of DNS Abuse,” and SSR2
Recommendation 16: “Create Pricing Incentives for Contracted Parties to Mitigate Abuse and Security
Threats.” The IPC supports these recommendations and any steps to more effectively combat DNS abuse
relating to the Registry Agreement (RA) and Registrar Accreditation Agreement (RAA) contracts.
...
Accordingly, the IPC supports these SSR2 recommendations that would
require meaningful enforcement of existing obligations of registries and registrars to prohibit certain
security threats and abusive activities, enhance such requirements to further mitigate such activities,
include real consequences for registrants who engage in prohibited abusive behavior, and motivate active
and consistent investigation and response to reports of abuse by registrars.		Agree, clarified text
81
ICANN Board10.1Establish a performance metrics framework to guide the level of compliance by Registrars and Registries for WHOIS obligations (including inaccuracy), as well as other elements that affect abuse, security, and resilience, as outlined in the RDS/WHOIS2 Review and the CCT Reviewthe Board asks the SSR2 RT to clarify what functionality beyond complaint handling, audits, breach notices, suspensions, and terminations it seeks ICANN Compliance to implement within the scope of the agreements. The Board asks that the SSR2 RT provide greater details on what issues or risks exist from the current operational model, how the SSR2 RT recommendation will address them, and what relevant metrics could be applied to assess implementation.
Further, it is unclear what is meant by the terms "performance metrics framework", "guide level of compliance", and "other elements that affect abuse, security, and resilience". The Board suggests that the SSR2 RT provide more detail on the intent of this recommendation to ensure that it is properly considered for implementation. The Board notes that this recommendation may overlap with recommendations from the Initial Report on New gTLD Subsequent Procedures (Section 2.12.3), the Registration Directory Service (RDS)-WHOIS2 Review Final Report and recommendations (4.1, 4.2, and 5.1), and CCT Review Team Final Report recommendations (21). The Board requests clarification on the intent of recommendation 10.1 in light of this potential overlap.		More details have been added; the Board (and staff) should review decades of discussions and written comments by non-contracted parties impacted by abuse and contracted party action to gain a deeper uderstanding of Compliance problems, user needs, and required improvements
82
RrSG10.1Establish a performance metrics framework to guide the level of compliance by Registrars and Registries for WHOIS obligations (including inaccuracy), as well as other elements that affect abuse, security, and resilience, as outlined in the RDS/WHOIS2 Review and the CCT Review.10.1 - This is already covered by ICANN- Compliance metrics on complaints, Compliance audit, Whois ARS, monitoring by GDD tech team, etc
83
RySG10.1Establish a performance metrics framework to guide the level of compliance by Registrars and Registries for WHOIS obligations (including inaccuracy), as well as other elements that affect abuse, security, and resilience, as outlined in the RDS/WHOIS2 Review and the CCT Review.Compliance-related recommendations must be linked to specific contract terms. “Other
elements that affect abuse, security, and resilience” is too vague to be implementable. The RySG
believes this is out of scope of SSR2.
84
RrSG10.2Allocate a specific budget line item for a team of compliance officers tasked with actively undertaking or commissioning the work of performance management tests/assessments of agreed SLA metrics.10.2 - This is something Compliance already does. A review team, with limited understanding of the operation and structure, should defer to Compliance to determine how it will best allocate resources.
85
RySG10.2Allocate a specific budget line item for a team of compliance officers tasked with actively undertaking or commissioning the work of performance management tests/assessments of agreed SLA metrics.The RySG does not see the value in specific compliance officers to handle specific contractual
compliance issues. All of Compliance is capable of responding to compliance complaints and ICANN has
demonstrated that it’s capable of conducting a full audit of all Ry contracts on a specific issue, like SLAs.
86
SSAC10.3Amend the SLA renewal clause from ‘automatically renewed’ to a cyclical four-year renewal that includes a review clause included (this review period would consider the level of compliance to the performance metrics by the Registrar and Registry and recommend the inclusion of requirements to strengthen the security and resilience where non-compliance was evident).(3.3.3) Given that the report has noted some challenges relating to enforcement of agreements with contracted parties, it is unclear what the review and the subsequent “recommend the inclusion of requirements” precisely entails.
Which party is to perform these reviews? Is it the team envisaged in recommendation 10.2? If not then who would be performing such a review? If so, would these compliance officers possess the skills to be able to, “recommend the inclusion of requirements to strengthen the security and resilience where non-compliance was evident”? Who is to receive the review’s recommendations? What criteria would be used by this party to assess these recommendations for additional requirements?
If requirements are being proposed, where is the contractual foundation to enforce these requirements? Does recommendation 10.3 implicitly refer to recommendation 15, where changes to the contractual conditions are proposed? Some further clarity on these recommendations would be helpful to understand both the detail of the proposed actions and the overall intent of these recommended measures.		Text clarified
87
RrSG10.3Amend the SLA renewal clause from ‘automatically renewed’ to a cyclical four-year renewal that includes a review clause included (this review period would consider the level of compliance to the performance metrics by the Registrar and Registry and recommend the inclusion of requirements to strengthen the security and resilience where non-compliance was evident).10.3 - It is the position of the RrSG that contract negotiations do not originate from review teams or working groups. That is reserved for ICANN Org, and the RrSG/RySG.
88
RySG10.3Amend the SLA renewal clause from ‘automatically renewed’ to a cyclical four-year renewal that includes a review clause included (this review period would consider the level of compliance to the performance metrics by the Registrar and Registry and recommend the inclusion of requirements to strengthen the security and resilience where non-compliance was evident).The RySG believes that this is outside the scope of the SSR2’s work. The RySG notes that there is an established contract amendment process: consensus policy and negotiations between CPs and ICANN. This recommendation has no basis in policy or fact - it is a conclusory statement that presupposes the question. If the SSR2 has identified problems with performance metrics, then it could recommend that ICANN and the community study them. In this case, the SSR2 is proceeding down the same slippery slope as CCT-RT in recommending solutions without recommending ICANN first engage in exploration and work to determine if a solution is needed.
89
RrSG10.4Further, the ICANN Board should take responsibility for bringing the EPDP to closure and passing and implementing a WHOIS policy in the year after this report is published.10.4 - It is not for a review team to determine the pace of the PDPs or IRTs. There can be unexected issues that arise (as during the implementation of EPDP Phase 1), and it is better for ICANN to develop and implement policy properly rather than rushing to meet an artificial deadline.Misunderstood Rec.; clarified
90
RySG10.4Further, the ICANN Board should take responsibility for bringing the EPDP to closure and passing and implementing a WHOIS policy in the year after this report is published.The RySG notes that this recommendation is not made to the appropriate party. A recommendation on a GNSO policy process should be referred to the GNSO Council as the manager of the policy process. Furthermore, it’s outside the scope of a review team to recommend that a PDP wrap up (as it undoubtedly will even without the RT’s recommendation).Misunderstood Rec.; clarified
91
GAC10.4Further, the ICANN Board should take responsibility for bringing the EPDP to closure and passing and implementing a WHOIS policy in the year after this report is published.The GAC also agrees with Recommendation 10.4 on implementing the EPDP policy recommendations within 1 year.Agreed
92
IPC10.4While the IPC is supportive of the intent behind recommendation 10.4, it notes that it is not the role of the Board to direct the outcome or timing of a community-led PDP. The RT may wish to revise this language, for example to refer to the Board itself, and via Org, offering all necessary support to achieve the desired outcomeMisunderstood Rec.; clarified
93
BC11Lead Efforts to Evolve Definitions Around Abuse and Enable Reporting Against Those DefinitionsThe BC concurs with this recommendation and reiterates its previous statements regarding DNS abuse:
•...while the BC appreciates the need for actionable definitions of abuse, we are concerned about recent efforts to limit or otherwise over-restrict discussion about the serious issue of domain name system abuse. Such asubject deserves fulsome consideration by the entire community...
•ICANN has a responsibility to enforce its contracts in the areas of DNS-related abuse. This community dialogue cannot delay or defer ICANN’s commitments or operations related to DNS abuse.
•ICANN should clarify the purposes and applications of “abuse” before further work is done to define DNS abuse.
•Once those purposes are identified, ICANN should determine whether abuse definitions used by outside sources can serve as references for the ICANN community, or whether a new, outcomes-based nomenclature could be useful (including impersonation, fraud, or other types of abuse) to accurately describe problems being addressed.		agreed
94
NCSG11Lead Efforts to Evolve Definitions Around Abuse and Enable Reporting Against Those Definitions#Recommendation 11: As this related to the definition of DNS Abuse, we believe that it is highly important to elaborate more on the methodology and the validation mechanisms.Agree that ICANN Org implementation plans should provide details on methodology and validation
95
RrSG11Lead Efforts to Evolve Definitions Around Abuse and Enable Reporting Against Those DefinitionsThe RrSG has concerns about this recommendation. The ICANN community is currently engaged in abuse and threat activities, as are the contracted parties. The
definition of abuse and threats can be difficult to define broadly, which is perhaps indicitive why there is not a definition that satisfies the review team. It is essential that contracted parties, which have undertanding of implications of these activities, be involved in the process (rather than the ICANN board engaging only security-related community members).		Misunderstood Rec.; as w/ all groups, RrSG should be involved; however, this effort should not be driven by CPH's (or ICANN Org's) desire to minimize their responsibilities, accountability or cost.
96
GAC11Lead Efforts to Evolve Definitions Around Abuse and Enable Reporting Against Those DefinitionsThe GAC welcomes Recommendation 11 on efforts to implement current community vetted definitions of DNS Abuse without delay and the need to ensure that definitions evolve to meet continuing threats, in the context of efforts aimed at finding a more effective approach to address DNS Abuse, including with the GAC’s support through its advice, comments, and correspondence. Although the GAC shares the overall goal of achieving clarity and consistency with regard to the definition of DNS Abuse and Security Threats, it is not quite clear how the different processes suggested in Recommendations 11.1, 11.3 and 11.4 should interrelate. The GAC therefore invites the Review Team to consider, in view of existing procedures and rules, how this goal can be best achieved.Agree; clarification and more detail provided
97
IPC11The IPC is supportive of this recommendation, and discusses its support for this recommendation in greater detail below.
As a preliminary matter, the IPC supports SSR2
Recommendation 11: “Lead Efforts to Evolve Definitions Around Abuse and Enable Reporting Against
Those Definitions” and any related efforts to define abuse so that reporting and consequences for abuse
can flow more efficiently from an agreed-upon definition.		Agree
98
RySG11.1ICANN Board should drive efforts that minimize ambiguous language and reach a universally acceptable agreement on abuse, SSR, and security threats in its contracts with contracted parties and implementation plans. The RySG does not think it is feasible or realistic for there to be “universally acceptable agreement” on definitions for abuse, SSR, and security threats but is willing to continue its extensive ongoing discussions to try to reach such an agreement.Disagree with contention that such an abuse definition is not feasible.
99
SSAC11.2ICANN org and Board should implement the SSR-relevant commitments (along with CCT and RDS/WHOIS2 Review recommendations) based on current, community vetted abuse definitions, without delay(3.3.4) If the underlying issue is that SSR2 has found evidence that the ICANN Board and ICANN org are not properly processing and acting on the outcomes of other reviews then it should say so explicitly. This recommendation that refers to recommendations from other reviews tends to suggest such a conclusion without actually saying so.Agreed. Clarified.
100
ICANN Board11.2ICANN org and Board should implement the SSR-relevant commitments (along with CCT and RDS/WHOIS2 Review recommendations) based on current, community vetted abuse definitions, without delayThe language of this recommendation presupposes that each of the recommendations are (1) accepted or approved by the ICANN Board; and (2) prioritized by the ICANN community for immediate implementation. The Board notes that it does not believe this to be within scope of the SSR2, and is not aligned with the Bylaws.
Additionally, the Board seeks clarification regarding whether this recommendation makes sense in terms of resource deployment in light of the ongoing community discussions regarding the definition of "DNS abuse". The Board also seeks clarification of the information the SSR2 RT has to support its position that the definition of abuse has been vetted through the bottom-up multistakeholder process.		Disagree with Board's/Staff's interpretation and understanding.Team has documented how it's in scope, why it should be prioritized, and we've shown where ICANN's own records show definitiion vetting. Logic requires multiple things to interact.