:






Process activities, methods and techniques



The following sections contain details of each of the stages within the ITSCM lifecycle.

4.5.5.1 Stage 1 Initiation

The initiation process covers the whole of the organization and consists of the following activities:

  • Policy setting this should be established and communicated as soon as possible so that all members of the organization involved in, or affected by, Business Continuity issues are aware of their responsibilities to comply with and support ITSCM. As a minimum, the policy should set out management intention and objectives.
  • Specifyterms of referenceandscope this includes defining the scope and responsibilities of all staff in the organization. It covers such tasks as undertaking a Risk Analysis and Business Impact Analysis and determination of the command and control structure required to support a business interruption. There is also a need to take into account such issues as outstanding audit points, regulatory or client requirements and insurance organization stipulations, and compliance with standards such as ISO 27001, the Standard on Information Security Management, which also addresses Service Continuity requirements.
  • Allocateresources the establishment of an effective Business Continuity environment requires considerable resource in terms of both money and manpower. Depending on the maturity of the organization, with respect to ITSCM, there may be a requirement to familiarize and/or train staff to accomplish the Stage 2 tasks. Alternatively, the use of experienced external consultants may assist in completing the analysis more quickly. However, it is important that the organization can then maintain the process going forward without the need to rely totally on external support.
  • Define the project organization and control structure ITSCM and BCM projects are potentially complex and need to be well organized and controlled. It is strongly advisable to use a recognized standard project planning methodology such as Projects IN a Controlled Environment (PRINCE2) or Project Management Body Of Knowledge (PMBOK).
  • Agree project and quality plans plans enable the project to be controlled and variances addressed. Quality plans ensure that the deliverables are achieved and to an acceptable level of quality. They also provide a mechanism for communicating project resource requirements and deliverables, thereby obtaining buy-in from all necessary parties.

4.5.5.2 Stage 2 Requirements and strategy

Ascertaining the business requirements for IT service continuity is a critical component in order to determine how well an organization will survive a business interruption or disaster and the costs that will be incurred. If the requirements analysis is incorrect, or key information has been missed, this could have serious consequences on the effectiveness of ITSCM mechanisms.



This stage can effectively be split into two sections:

  • Requirements perform Business Impact Analysis and risk assessment
  • Strategy following the requirements analysis, the strategy should document the required risk reduction measures and recovery options to support the business.

Requirements Business Impact Analysis

The purpose of a Business Impact Analysis (BIA) is to quantify the impact to the business that loss of service would have. This impact could be a hard impact that can be precisely identified such as financial loss or soft impact such as public relations, moral, health and safety or loss of competitive advantage. The BIA will identify the most important services to the organization and will therefore be a key input to the strategy.

The BIA identifies:

  • The form that the damage or loss may take for example:
    • Lost income
    • Additional costs
    • Damaged reputation
    • Loss of goodwill
    • Loss of competitive advantage
    • Breach of law, health and safety
    • Risk to personal safety
    • Immediate and long-term loss of market share
    • Political, corporate or personal embarrassment
    • Loss of operational capability for example, in a command and control environment
  • How the degree of damage or loss is likely to escalate after a service disruption, and the times of the day, week, month or year when disruption will be most severe
  • The staffing, skills, facilities and services (including the IT services) necessary to enable critical and essential business processes to continue operating at a minimum acceptable level
  • The time within which minimum levels of staffing, facilities and services should be recovered
  • The time within which all required business processes and supporting staff, facilities and services should be fully recovered
  • The relative business recovery priority for each of the IT services.

One of the key outputs from a BIA exercise is a graph of the anticipated business impact caused by the loss of a business process or the loss of an IT service over time, as illustrated in Figure 4.22.

Figure 4.22 Graphical representation of business impacts

This graph can then be used to drive the business and IT continuity strategies and plans. More preventative measures need to be adopted with regard to those processes and services with earlier and higher impacts, whereas greater emphasis should be placed on continuity and recovery measures for those where the impact is lower and takes longer to develop. A balanced approach of both measures should be adopted to those in between.

These items provide the drivers for the level of ITSCM mechanisms that need to be considered or deployed. Once presented with these options, the business may decide that lower levels of service or increased delays are more acceptable, based on a costbenefit analysis, or it maybe that comprehensive disaster prevention measures will need to be implemented.

These assessments enable the mapping of critical service, application and technology components to critical business processes, thus helping to identify the ITSCM elements that need to be provided. The business requirements are ranked and the associated ITSCM elements confirmed and prioritized in terms of risk reduction and recovery planning. The results of the BIA, discussed earlier, are invaluable input to several areas of process design including Service Level Management to understand the required service levels.

Impacts should be measured against particular scenarios for each business process, such as an inability to settle trades in a money market dealing process, or an inability to invoice for a period of days. An example is a money market dealing environment where loss of market data information could mean that the organization starts to lose money immediately as trading cannot continue. In addition, customers may go to another organization, which would mean potential loss of core business. Loss of the settlement system does not prevent trading from taking place, but if trades already conducted cannot be settled within a specified period of time, the organization may be in breach of regulatory rules or settlement periods and suffer fines and damaged reputation. This may actually be a more significant impact than the inability to trade because of an inability to satisfy customer expectations.

It is also important to understand how impacts may change over time. For instance, it may be possible for a business to function without a particular process for a short period of time. In a balanced scenario, impacts to the business will occur and become greater over time. However, not all organizations are affected in this way. In some organizations, impacts are not apparent immediately. At some point, however, for any organization, the impacts will accrue to such a level that the business can no longer operate. ITSCM ensures that contingency options are identified so that the appropriate measure can be applied at the appropriate time to keep business impacts from service disruption to a minimum level.

When conducting a BIA, it is important that senior business area representatives views are sought on the impact following loss of service. It is also equally important that the views of supervisory staff and more junior staff are sought to ensure all aspects of the impact following loss of service are ascertained. Often different levels of staff will have different views on the impact, and all will have to be taken into account when producing the overall strategy.

In many organizations it will be impossible, or it will not be cost-justifiable, to recover the total service in a very short timescale. In many cases, business processes can be re-established without a full complement of staff, systems and other facilities, and still maintain an acceptable level of service to clients and customers. The business recovery objectives should therefore be stated in terms of:

  • The time within which a pre-defined team of core staff and stated minimum facilities must be recovered
  • The timetable for recovery of remaining staff and facilities.

It may not always be possible to provide the recovery requirements to a detailed level. There is a need to balance the potential impact against the cost of recovery to ensure that the costs are acceptable. The recovery objectives do, however, provide a starting point from which different business recovery and ITSCM options can be evaluated.

Requirements Risk Analysis

The second driver in determining ITSCM requirements is the likelihood that a disaster or other serious service disruption will actually occur. This is an assessment of the level of threat and the extent to which an organization is vulnerable to that threat. Risk Analysis can also be used in assessing and reducing the chance of normal operational incidents and is a technique used by Availability Management to ensure the required availability and reliability levels can be maintained. Risk Analysis is also a key aspect of Information Security Management. A diagram on Risk Analysis and Management (Figure 4.20) is contained within the Availability Management process in section 4.4.

A number of Risk Analysis and Management methods are available for both the commercial and government sectors. Risk Analysis is the assessment of the risks that may give rise to service disruption or security violation. Risk management is concerned with identifying appropriate risk responses or cost-justifiable countermeasures to combat those risks.

A standard methodology, such as the Management of Risk (M_o_R), should be used to assess and manage risks within an organization. The M_o_R framework is illustrated in Figure 4.23.

Figure 4.23 Management of Risk

The M_o_R approach is based around the above framework, which consists of the following:

  • M_o_R principles: these principles are essential for the development of good risk management practice and are derived from corporate governance principles.
  • M_o_R approach: an organizations approach to these principles needs to be agreed and defined within the following living documents:
    • Risk Management Policy
    • Process Guide
    • Plans
    • risk registers
    • Issue Logs.
  • M_o_R Processes: the following four main steps describe the inputs, outputs and activities that ensure that risks are controlled:
    • Identify: the threats and opportunities within an activity that could impact the ability to reach its objective
    • Assess: the understanding of the net effect of the identified threats and opportunities associated with an activity when aggregated together
    • Plan: to prepare a specific management response that will reduce the threats and maximize the opportunities
    • Implement: the planned risk management actions, monitor their effectiveness and take corrective action where responses do not match expectations.
  • Embedding and reviewing M_o_R: having put the principles, approach and processes in place, they need to be continually reviewed and improved to ensure they remain effective.
  • Communication: having the appropriate communication activities in place to ensure that everyone is kept up-to-date with changes in threats, opportunities and any other aspects of risk management.

This M_o_R method requires the evaluation of risks and the development of a risk profile, such as the example in Figure 4.24.

Figure 4.24 Example summary risk profile

Figure 4.24 shows an example risk profile, containing many risks that are outside the defined level of acceptable risk. Following the Risk Analysis it is possible to determine appropriate risk responses or risk reduction measures (ITSCM mechanisms) to manage the risks, i.e. reduce the risk to an acceptable level or mitigate the risk. Wherever possible, appropriate risk responses should be implemented to reduce either the impact or the likelihood, or both, of these risks from manifesting themselves. In the context of ITSCM, there are a number of risks that need to be taken into consideration. The following is not a comprehensive list but does give some examples of risks and threats that need to be addressed by the ITSCM process.


 

Risk Threat
Loss of internal IT systems/networks, PABXs, ACDs, etc. Fire Power failure Arson and vandalism Flood Aircraft impact Weather damage, e.g. hurricane Environmental disaster Terrorist attack Sabotage Catastrophic failure Electrical damage, e.g. lightning Accidental damage Poor-quality software
Loss of external IT systems/networks, e.g. e-commerce servers, cryptographic systems All of the above Excessive demand for services Denial of service attack, e.g. against an internet firewall Technology failure, e.g. cryptographic system
Loss of data Technology failure Human error Viruses, malicious software, e.g. attack applets
Loss of network services Damage or denial of access to network service providers premises Loss of service providers IT systems/networks Loss of service providers data Failure of the service provider
Unavailability of key technical and support staff Industrial action Denial of access to premises Resignation Sickness/injury Transport difficulties
Failure of service providers, e.g. outsourced IT Commercial failure, e.g. insolvency Denial of access to premises Unavailability of service providers staff Failure to meet contractual service levels

Table 4.1 Examples of risks and threats





sdamzavas.net - 2019 . ! , ...