Major incidents

Incident Models

Timescales

Timescales must be agreed for all incident-handling stages (these will differ depending upon the priority level of the incident) – based upon the overall incident response and resolution targets within SLAs – and captured as targets within OLAs and Underpinning Contract s (UCs). All support group s should be made fully aware of these timescales. Service Management tools should be used to automate timescales and escalate the incident as required based on pre-defined rules.

Many incidents are not new – they involve dealing with something that has happened before and may well happen again. For this reason, many organizations will find it helpful to pre-define ‘standard’ Incident Model s – and apply them to appropriate incidents when they occur.

An Incident Model is a way of pre-defining the steps that should be taken to handle a process (in this case a process for dealing with a particular type of incident) in an agreed way. Support tools can then be used to manage the required process. This will ensure that ‘standard’ incidents are handled in a pre-defined path and within pre-defined timescales.

Incidents which would require specialized handling can be treated in this way (for example, security -related incidents can be routed to Information Security Management and capacity - or performance -related incidents that would be routed to Capacity Management.

The Incident Model should include:

• The steps that should be taken to handle the incident
• The chronological order these steps should be taken in, with any dependences or co-processing defined
• Responsibilities; who should do what
• Timescales and threshold s for completion of the actions
• Escalation procedure s; who should be contacted and when
• Any necessary evidence-preservation activities (particularly relevant for security - and capacity -related incident s).

The model s should be input to the incident-handling support tools in use and the tools should then automate the handling, management and escalation of the process.

A separate procedure, with shorter timescales and greater urgency, must be used for ‘major’ incidents. A definition of what constitutes a major incident must be agreed and ideally mapped on to the overall incident prioritization system – such that they will be dealt with through the major incident process.

Note: People sometimes use loose terminology and/or confuse a major incident with a problem. In reality, an incident remains an incident forever – it may grow in impact or priority to become a major incident, but an incident never ‘becomes’ a problem. A problem is the underlying cause of one or more incidents and remains a separate entity always!

Some lower-priority incidents may also have to be handled through this procedure – due to potential business impact – and some major incidents may not need to be handled in this way if the cause and resolution s are obvious and the normal incident process can easily cope within agreed target resolution times – provided the impact remains low!

Where necessary, the major incident procedure should include the dynamic establishment of a separate major incident team under the direct leadership of the Incident Manager, formulated to concentrate on this incident alone to ensure that adequate resource s and focus are provided to finding a swift resolution. If the Service Desk Manager is also fulfilling the role of Incident Manager (say in a small organization), then a separate person may need to be designated to lead the major incident investigation team – so as to avoid conflict of time or priorities – but should ultimately report back to the Incident Manager.

If the cause of the incident needs to be investigated at the same time, then the Problem Manager would be involved as well but the Incident Manager must ensure that service restoration and underlying cause are kept separate. Throughout, the Service Desk would ensure that all activities are recorded and user s are kept fully informed of progress.

Дата добавления: 2014-12-23