ICANN ICANN Email List Archives

[dssa]


<<< Chronological Index >>>    <<< Thread Index >>>

[dssa] Fwd: ICANN News Alert -- Update to DNS Risk Management Framework Consultant RFP - Responses to Questions Received

  • To: DSSA WG <dssa@xxxxxxxxx>
  • Subject: [dssa] Fwd: ICANN News Alert -- Update to DNS Risk Management Framework Consultant RFP - Responses to Questions Received
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Tue, 21 Aug 2012 06:58:57 -0500

hi all,

here's a progress report on the DNS risk management framework consulting 
process.  

mikey


Begin forwarded message:

> From: "ICANN News Alert" <communications@xxxxxxxxx>
> Subject: ICANN News Alert -- Update to DNS Risk Management Framework 
> Consultant RFP - Responses to Questions Received
> Date: August 20, 2012 10:46:17 PM CDT
> To: <mike@xxxxxxxxxx>
> 
> 
> News Alert
> 
> 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 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@xxxxxxxxx to the attention of 
> Patrick Jones in the ICANN Security team.
> 
> Questions
> 
> Proposal Submission
> 
>  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
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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
> 
>  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.
> 
>  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.
> 
>  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
> 
>  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
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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.
> 
>  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
> 
>  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.
> 
> 
> 
> This message was sent to mike@xxxxxxxxxx from:
> ICANN | 12025 Waterfront Drive Suite 300 | Los Angeles, CA 90094-2536
> Email Marketing by 
> 
> Manage Your Subscription                                                      
>                                         
> 

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy