|
|
7.2.1 Risks 'in scope'
7.2.2 Risks 'out of scope'
7.2.3 Roles and responsibilities
ITSCM primarily considers those IT assets and configurations that support the key Business processes. However, the installation of mechanisms to deliver ITSCM may not necessarily be sufficient to keep those business processes operating after a Service disruption. Should it be necessary to relocate to an alternative working location, provision will also be required for items such as office and personnel accommodation, copies of critical paper records, courier Services and telephone facilities to communicate with Customers and third parties.
The ITSCM Process should identify the required and agreed minimum level of business operation following a service disruption, along with a requirements definition covering systems, facilities and service requirements. The process then examines the risks and threats to these requirements and develops an IT Risk reduction or mitigation Programme. This programme implements mechanisms delivering the Continuity requirements necessary to provide the required optimum level of business operation. These mechanisms may include splitting a data centre over more than one location, implementing disk mirroring (or other levels of RAID as required), System replication to a standby site, dual routing of communications links, installing secondary communications links, or provision of standby power supply (UPS and/or generator).
Scope considerations include:
At the broadest level, the scope of ITSCM is usually defined in terms of the:
Organisations continually face risks, ranging from a localised service disruption in a single department to major service disruptions that affect multiple organisations and communities. As the business activities and Infrastructure of an organisation Change, so do the business processes and the organisation's risk assessment profile. The risks covered by ITSCM tend to be those that could result in serious disruption to business processes, for example the loss of, or denial of access to, IT systems or networks. These risks are discussed in more detail later in this Chapter.
The likelihood of events such as these happening has been proven over the years. Talking to Building Services and IT Operations Support Management provides an insight into the frequency, types and nature of regular service disruptions. In addition, the press has provided substantial coverage of major service disruptions, from terrorist activities to natural disasters and Infrastructure Problems. Below is a brief list of high profile events that have caused significant problems to organisations over the years:
Poison Gas Tokyo Underground System, Japan (March, 1995)
Power Loss Auckland, New Zealand (December, 1997)
Earthquake Los Angeles, USA (January, 1994)
Kobe, Japan (January, 1995)
Bomb World Trade Centre, New York, USA (February, 1993)
Bishopsgate, London, England (April, 1993)
Oklahoma City, Oklahoma, USA (April, 1995)
Docklands, London, England (February, 1996)
Manchester, England (June, 1996)
Flood Bangladesh (July, 1996)
Pakistan (August, 1996)
Technical Failure London Stock Exchange (2000)
Web site denial of service attacks e.g. Yahoo (2000)
| Example In the late 1970s a major earthquake in Romania left 1000 dead in Bucharest alone. This is a phenomenon that recurs approximately every 40 years. There were no major IT networks in Romania 20 years ago. It is almost certain that there will be a major earthquake by 2020 that will destroy all existing IT Infrastructure within the fault area. Contingency for them is not a potential luxury, it is an absolute survival essential, which affects not only existing IT Infrastructure but every significant IT change. |
ITSCM does not usually directly cover longer-term risks such as those from changes in business direction, diversification, restructuring, and so on. While these risks can have a material Impact on IT Service elements and their Continuity mechanisms, management usually has some time to identify and evaluate the risk and include risk mitigation through changes or shifts in business and IT strategies, thereby becoming part of the Change Management programme.
Similarly, ITSCM does not usually cover minor technical faults (for example, non critical disk failure), unless there is a possibility that the impact could have a material impact on the business. These risks would be expected to be covered mainly through the Service Desk and the Incident Management process, or resolved through the planning associated with the disciplines of Availability Management, Problem Management; and to a lesser extent through Change Management, Configuration Management and 'day to day' operational management.
The initial implementation of ITSCM is typically progressed as a project and needs to be considered as a part of other projects, whereas, on an ongoing basis ITSCM evolves into operational responsibilities. Without the roles and responsibilities being addressed, and openly endorsed and communicated from a senior level within the organisation at an early stage in the project, it will struggle to generate the support, resourcing and 'buy-in' required for it to deliver the business requirements. This could have a number of consequences resulting in the recovery capability being delayed, running over budget, the scope being reduced or work not being completed to the required standard.
Due to the understanding required of the business and the management of risks within the project, there is a logical fit within the Security Management and Business Analysis areas of most IT organisations. Quite often these roles possess similar skills/knowledge and often have to undertake risk and impact assessments, and implement Risk reduction measures as part of their usual Role. For this reason it is not unusual to find an ITSCM responsibility within an Information Security function.
The roles and responsibilities of individuals within the initial project and ongoing support of the ITSCM facilities are discussed later in this Chapter.
|
|
