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