http://www.icann.org/en/news/announcements/announcement-20aug12-en.htm Update to DNS Risk Management Framework Consultant RFP - Responses to Questions Received 20 August 2012 On 16 July, ICANN published a request for proposals<http://www.icann.org/en/news/announcements/announcement-16jul12-en.htm> for an expert consultant to assist ICANN with the development of a DNS Risk Management Framework. The announcement indicated that questions on the RFP could be submitted between 1-16 August 23:59 UTC. The period to submit questions on the RFP is now closed. ICANN is providing the questions received and responses in this update so all parties interested in responding to the call for proposals may have the same information. The deadline for responses to the call for proposals is 31 August 2012, 23:59 UTC. Responses should be sent to drmf-rfi@icann.org<mailto:drmf-rfi@icann.org> to the attention of Patrick Jones in the ICANN Security team. Questions Proposal Submission 1. We would like to know if you will accept proposals for this assignment from a consortium (two consulting firms) or if you are looking for a single consultant. Response - Proposals from a consortium would be welcomed. The proposal should include a description of how the parties in the consortium would work together and interact with ICANN. Timing 2. What is the anticipated time span of the project, in terms of ICANN meetings elapsed, given the the required times for internal and public comment? Response - Ideally, ICANN would be able to retain a consultant to begin work on this project in late September, and participate in an open community panel at the ICANN meeting in October in Toronto, Ontario. Specific timing deliverables will be set once the consultant is retained, but it the expectation from the Board-level working group that a draft DNS Risk Management Framework be available for discussion in early December 2012, and following relevant public comment periods for the ICANN Board at the ICANN meeting in Beijing, China in April 2013. 3. What is the anticipated duration of the transition plan to complete the launch in terms of ICANN staff availability? Response - ICANN staff will be available and following the work of the consultant throughout the project. This should reduce any delays between the start of the project and the implementation phase to operational risk management at ICANN. 4. What is the anticipated start date to execute on the RFP activities? Response - The consultant should be available to begin as soon as possible after the completion of the contracting process. Ideally this work should commence in late September so that there is sufficient time to start in advance of the ICANN meeting in Toronto. The Board-level working group will have a open community session at the ICANN meeting on Thursday 18 October, participation from the consultant in this session would be expected in order to use this time to interact with the community. 5. When will ICANN state its decision on the winning bidder? Response - ICANN intends to make its decision quickly, based on the quality of the responses received and the internal selection process. ICANN is aiming for early September to make this decision. Staff Support 6. What is the anticipated size of ICANN's internal team to implement the methodology and geographical location and diversity of designated staff? Response - Implementation of the DNS Risk Management Framework will be led by ICANN's Security team but will involve expertise from staff in other departments, including Legal, DNS Operations, IT, Finance, IANA, among others. ICANN's staff are globally distributed, although the Security team is currently split between the East Coast and West Coast US. 7. What is the makeup of the ICANN staff dedicated to executing risk management activities (number of staff, hierarchy, etc.)? Response - ICANN's Security team provides staff support to the Board Risk Committee and Board-level DNS Risk Management Framework Working Group. There are ICANN staff from the Legal team providing both Board support and Executive team participation by ICANN's General Counsel. The Executive team follows risk management activities, and individual department staff track department risks. 8. What is the commitment of FTEs in regards to ICANN's availability to contribute to the project efforts? Response - The ICANN Security team will provide staff support to engage with the consultant on this project. Preparation of Materials 9. The RFP indicates that the expert consultant will deliver a report to the Board DNS Risk Management Framework Working Group and the ICANN community. Will the deliverables that the expert consultant produces be shared verbatim with the community as public documents, or will ICANN or the expert consultant prepare summaries to be shared publically? Response - The consultant should assume that the deliverables produced for the this project will be shared verbatim with the community as public documents. The consultant should also provide executive summaries where appropriate to support community comprehension of the risk framework once it is developed. List of Tasks for a DNS Risk Management Framework 10. Task 2 - Risk Framework - Has ICANN previously adopted a risk management framework? Which framework is it? Response - Yes, ICANN has an internal enterprise risk management framework. 11. Task 2 - Risk Framework - Does ICANN have any frameworks that it is considering for adoption into their organization? Response - ICANN would be receptive to practical and implementable approaches to DNS risk management. 12. Task 2 - Risk Framework - Does ICANN have an Enterprise Risk Management (ERM) framework with which this security risk management framework should align? Response - ICANN has an internal enterprise risk management framework. ICANN would be receptive to practical and implementable approaches to DNS risk management. 13. Task 2 - Risk Framework - Would ICANN consider basing their risk management framework on leading practices and globally accepted frameworks such as Risk IT and COBIT5 for Security? Response - COBIT is primarily an information technology process framework. The consultant should take into account the focus of the risk management framework is not entirely on information technology, but broadly on DNS risks for ICANN as an organization. COBIT5 and Risk IT can serve as examples but should not be the sole basis of the consultant's proposed framework. 14. Task 2 - Risk Framework - The list of deliverables does not clearly articulate the requirement of risk governance (e.g., risk appetite and tolerance, responsibilities and accountability for IT risk management, awareness and communication, risk culture). Is this also a desired deliverable? Response - Recommendations from the consultant on mechanisms for clearly articulating the requirement of risk governance would be welcomed within the context of DNS risks. 15. Task 3 - Build Consensus - How long is the public comment cycle expected to last? The process for ICANN's public comment cycle is described at http://www.icann.org/en/news/public-comment. The total length of the public comment cycle will depend on whether comments are received in the initial comment period, requiring a reply comment period. The Working Group envisioned public comment being conducted in the early part of 2013, although this is subject to change depending on a variety of factors. 16. Task 3 - Build Consensus - Will the Working Group provide review and comment prior to the public comment cycle? Will there be opportunity to make revisions to the framework prior to release for public comment, based on feedback from the Working Group? Response - Yes 17. Task 3 - Build Consensus - What measure will the Working Group utilize to gauge if consensus has been achieved? Response - The Working Group seeks a DNS Risk Management Framework that will be implementable and is generally accepted by the community as meeting the deliverables in this tender. 18. Task 3 - Build Consensus - The RFP indicates that the expert consultant will "assist staff and the working group to build consensus in support of the risk management framework within ICANN (the organization and the community)." Will the expert consultant be interacting directly with the community, or will the expert consultant interact with the community only through ICANN staff? Response - From a starting point, it is desired by the Board-level Working Group to have the consultant participate in the open session of the Working Group at the ICANN meeting in Toronto on 18 October 2012. This meeting will provide an opportunity for interested participants in the community to ask questions, and for the consultant to engage with those attending the meeting. It is also expected that the consultant will interact directly with experts in the community in development of the risk framework. 19. Task 4 - Risk Cycle - The RFP indicates that Task 4 is part of a "Potential Phase II". What are the determinants for whether "Phase II" will occur? The Board and ICANN senior management will determine next steps in the process after the delivery of the Phase 1 DNS risk management framework, including the timing and feasibility of Phase II as described in the RFP. The response to the RFP can include a description of how the consultant would consider deliverables in Phase II. 20. Task 4 - Risk Cycle - Should the proposal include estimates for potential Phase II activities? Response - Yes, although this could be presented at a high level, granular detail on steps in Phase II is not required for Phase I but may be helpful for ICANN to understand the methodology that the consultant proposes to use. 21. Task 4 - Risk Cycle - What tools is ICANN utilizing today to identify, document, manage and monitor risks? Response - ICANN tracks risks within its departments and also provides regular updates on key program risk areas through the relevant Board Committee, such as the Board Risk Committee, Board Finance Committee, Board IANA Committee, among others. The new gTLD program has a separate risk reporting mechanism through the Board New gTLD Committee. 22. Task 4 - Does ICANN leverage any Governance, Risk Management and Compliance (GRC) technology solutions? Response - ICANN's Compliance team is in the process of developing tools to assist its efforts in managing compliance risks. ICANN would be receptive to suggestions for technology solutions that assist in making the DNS risk management framework practical and implementable once delivered by the consultant. 23. Task 4 - Risk Cycle - Does ICANN leverage previously identified and documented risks in their organization? Are there other risk activities occurring in the organization? What are they? Response - ICANN conducts regular meetings of its Board Risk Committee and utilizes its previously identified and documented risks in managing risk within the organization. 24. Task 4 - Risk Cycle - Would ICANN like to include in the deliverable a baseline process, risk and control library for their key security risks? Response - The primary tasks for this contract are described in the RFP. Additional information should support the delivery of a DNS risk management framework for the organization. 25. Task 4 - Risk Cycle - In addressing the risk plan (risk response strategy), does ICANN want sample test procedures included to validate the effectiveness of the risk plan in addition to monitoring procedures of key indicators? Response - Yes, these can be included if they support the framework. 26. Task 4 - Risk Cycle - Would ICANN like assistance in the design and development of monitoring and dashboard reports? Response - Design and development of monitoring and dashboard reporting would go toward implementation and execution of an initial cycle of the framework as part of Phase II. These suggestions could be included in the RFP but are not required at this stage. General 27. What are the key selection criteria ICANN is using to award this RFP? Response - ICANN will evaluate the responses received to identify an expert consultant that can apply risk methodologies to the unique aspects of the Domain Name System, including its international nature and multistakeholder participation. ICANN needs a consultant who can deliver a quality product in a relatively narrow period of time, that will hold up to community scrutiny and analysis. Glen de Saint Géry GNSO Secretariat gnso.secretariat@gnso.icann.org http://gnso.icann.org