Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

ITIL Tattle

ITIL Tattle

Blog posts on ITIL and ITSM news and best practice from the ISG ITIL Team

Mayday, Mayday, Mayday – What’s a Major Incident?

Students right a life raft in the John Day River in Astoria, Ore., May 31, 2012. U.S. Coast Guard photo by Petty Officer 3rd Class Nathan Littlejohn.

A situation when in the opinion of the master, the vessel, vehicle, aircraft or person is in grave and imminent danger and requires immediate assistance.

International conventions (SOLAS, COLREG) clearly establish when a distress signal (such as a “Mayday” call) may be made.  These same conventions bind those that receive a distress signal to respond in a particular way.

Our major incident process bears striking similarity to this but, thankfully, life and limb are not usually at risk!

In the Opinion of the Master…

Someone needs to make a judgement call that the situation is a Major Incident.  Since we’re not all at sea, that someone is the “Incident Commander”.  There isn’t a definitive and exhaustive list of major incidents, rather they can be many and varied, hence the decision as to whether to declare a Major Incident needs to be made by an individual.  A list of our incident commanders will be circulated shortly, but mostly it will be a member of the ITIL Team.

As we’re not all in the same boat, the first step will be to inform the Incident Commander that something big is happening, so that they can make that judgement call.

Grave and Imminent Danger…

The Incident Commanders have guidance to inform their decision on what might constitute a Major Incident.

As a rough rule of thumb, the Incident Commander should be contacted if one or more of our Business Services are unavailable or significantly degraded due to an unplanned event.  Perhaps the Service Owner or Service Operations Manager becomes aware of a service showing signs of strain, likely to cause degradation or an outage.  Or perhaps it is technical monitoring that shows a failing infrastructure component, or a significant cyber-attack in progress.  Or perhaps it’s an Estates issue where power, cooling or water supplies could be threatened to one of our buildings.

If in doubt, make the shout!  Early invocation of the Major Incident process can minimise the impact on the University, and the Commander will take into account the time of year, the business impact of the incident, the scope and the scale.  Even if some of these are unknown, it is better to alert the Incident Commander sooner rather than wait until the vessel has sunk!

Requires immediate assistance…

Once the Incident Commander has declared a Major Incident, they can assemble a team to work on the Incident.  You may find that you’re co-opted into the team and tasked to provide assistance – the Incident Commander can requisition resources as required, and you are obligated to assist (SOLAS Chapter V, Regulation 33) .  The Commander will release resources as they cease to be required.  However, we don’t insist you provide hospitality for those you rescue and since no souls are likely to be lost, the obligation also only extends to working hours, not 24×7!

A Situation…

For those still wanting examples, here are a few!

Major Incidents

  • Temporary loss of an IS primary building (e.g. the Main Library Building)
  • A single day of severe weather resulting in staff shortages
  • A “top priority” system is unavailable or significantly degraded (e.g. MyEd)
  • A “medium priority” system is unavailable or significantly degraded at a business critical time of year (e.g. Media Hopper Replay during the Examination block)
  • Several business services are unavailable or degraded (e.g. due to a fault with the virtual server infrastructure)
  • The IS Service Desks are receiving an unmanageable volume of calls

“Ordinary” Incidents

  • Temporary loss of an IS satellite building or area (e.g. a single open access computing lab)
  • A single business service is degraded or unavailable
  • Loss of localised network to a non-business critical building
  • Loss of a single component of a business service (e.g. email mailing lists being unavailable)

Service Continuity Events

These go beyond the scope of a Major Incident, although they may begin as such.  I’ll leave them beyond the scope of this article, but suffice to say, they are often marked by risks to flesh and blood!


1 reply to “Mayday, Mayday, Mayday – What’s a Major Incident?”

Leave a reply


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.