Examples of de-centralised risk management processes

The article Centralised or de-centralised risk management in your enterprise? said that usual ways of defining a discrete risk management process are

  • to assess and manage risk for a particular area of activity (possibly the total activity of the enterprise), or
  • to assess and manage risk in an enterprise, or perhaps a community, relating to a specific type of risk theme.

This article lists examples of each way to scope a risk management process that can be maintained with or without ‘enterprise’ risk management.

The whole enterprise (Enterprise Risk Management) A work unit within the organisation A defined business process or system A project, programme, or portfolio A specific proposed change or initiative Security risk Fraud risk Health and safety Business continuity ‘Legal’ risk

What to read first: Centralised or de-centralised risk management in your enterprise?

Risk specialists Version 2.0 Beta

‘Area of activity’ examples

Clusters of enterprise activity attracting a de-centralised risk management process commonly include:

  • The whole enterprise (Enterprise Risk Management). Such a risk management process is hardly ‘de-centralised’, but it can exist separate from any other risk management in the same enterprise.
  • A work unit within the organisation. Work units can be nested within larger units, representing the management hierarchy. If the organisation contains teams with departments within branches within divisions, there can be team, departmental, branch, and divisional risk management processes with boundaries between them.
  • A defined business process or system.
  • A project, programme, or portfolio. This vocabulary comes from PRINCE2 and M_o_R. A programme is a group of related projects, while a portfolio is the whole collection of programmes and projects taking place within an enterprise. I don’t like this spelling of ‘programme’, but it comes from the PRINCE2/M_o_R source, and the Francophile spelling will alert both of us that the p-word is being used in that special sense. Launch of a new product or expansion into a new market can be risk-managed like a project or programme.
  • A specific proposed change or initiative, such as an enterprise acquisition, implementation of new ICT, or change to a regulation (from the regulator’s point of view). For risk management purposes, a proposed change or initiative can be treated as a project to which resources have not yet been committed.
There are some other potential enterprise activity clusters that may be less helpful for scoping risk management. I think it’s unhelpful to assess (all) the risks separately for each regional office, when there are many regional offices with nearly identical functions and activities. (Much worse is sitting in head office and giving each regional office a risk rating. That is not even risk management. It is risk scoring, something I described in the topic ‘What is Risk Management?’—among a list of misconceptions of risk management.)

Theme or ‘type of risk’ examples

Kinds of risk that may attract a separate risk management process include:

  • Security risk. ‘Security’ risk is hard to pin down in words, but everyone knows it when they see it. Security risk management has its own mature methods and standards. In the public sector there may be an external requirement to manage security risk in particular ways, reflecting the community interest in security of public assets, beyond the interests of a single organisation.
  • Fraud risk. In different industries, fraud risks have widely different profiles. To take just two examples, customers might be a fraud threat (insurance), or customers might be at risk from fraud (banking). Some important types of fraud risk must be managed closely, even if the enterprise itself is not seriously threatened by fraud. For that reason, fraud risk can benefit from a separate risk management process. Where public or community assets are involved, or if the enterprise is a listed company, there may be an externally imposed requirement to approach fraud risk in a particular way regardless of enterprise objectives.
  • Health and safety. There is always an objective to minimise death, injury and disease. Minimising death is regarded as important, whether or not there is any particular link to enterprise objectives. Assurance of health and safety objectives may be critical to regulators or particular stakeholders, even if the details do not take up much time among top management and board members. Regulators or legal defensibility may require a discrete risk management process for health and safety.
  • Business continuity. Business continuity programs are important for most operations and better practices involve an integrated approach across the whole of an enterprise, possibly even crossing organisation boundaries to involve complete supply chains. The risk management style for business continuity is usefully specialised and simplified. The simplified risk process can select necessary risk treatments (readiness preparations) with a minimum of dithering and delay. There is likely to be a specialised and separate risk management process for business continuity.
  • ‘Legal’. I have no clear understanding of the boundaries of a ‘legal’ risk assessment, but I have seen examples maintained by enterprise legal departments.

There may be separate risk management processes for different aspects of a given major theme. For instance, there may be three separate risk assessments for personnel security, physical security, and electronic information security, as very different knowledge bases are involved. ‘Business’ or ‘operational’ risk might also be understood as risk themes, with careful explanations.

Parent articles

Centralised or de-centralised risk management in your enterprise?

What is Enterprise Risk Management? What is a ‘risk management process’? Centralised and de-centralised approaches: ERM as an enterprise-level risk management process Centralised ERM Decentralised risk management processes throughout the enterprise Decentralised but standardised risk management processes through the enterprise. How you end up with one or the other The good and bad in each approach: The common problem is a long path from trigger event to enterprise outcome. ERM as a ‘top level’ risk management process is incomplete. Centralised ERM is ok, but has big problems. Decentralised risk management processes need an enterprise view created. Creating the enterprise view Decentralised but standardised risk management processes are not a solution. The bottom line: decentralised is smart, but there are conditions to meet.

Risk specialists Version 2.0 Beta

Main article on Decentralised risk management processes within an enterprise