Skip to main content

Overview

Good security risk management is built on solid analysis, and good practice holds that organisations operate more effectively and securely when they systematically evaluate risks. This chapter discusses the methodologies and tools used to conduct thorough risk analysis, to form the basis for informed decision-making and strategic planning. It underscores the importance of contextual understanding, enhanced by data-driven analysis, in developing robust security risk mitigation measures. Context and risk analysis are not a precise science. Rather, they are a means to support organisations to increase their understanding and improve their decision-making by identifying the key questions to ask.

Chapter summary

A structured and disciplined approach can help to separate facts from perceptions and emotions, allowing the analyst to absorb more information for a fuller picture. It can also help teams arrive at a consensus, grounded in the available evidence. The below lists the basic steps of an analytical process that security and programme staff have found useful. The specific activities undertaken within each step can vary in complexity depending on the capacity and resources of the organisation. It is important to remember that there is no one-size-fits-all, and the most appropriate model is the one that will be readily understood and consistently employed by staff at all levels. In general, organisations that opt for simplicity over complexity stand a better chance of their tools being used by staff.

Step 1: Context, threats and vulnerability analysis

  • Macro-context analysis. Examine the broader context where the programming will take place (using a PESTEL framework, for example), the conflict dynamics (if relevant) and the key actors.
  • Internal analysis. Review the organisation’s programme objectives, priorities and structures, the geographical presence of staff, security risk management capacities and operating modalities.
  • Threat identification. Identify potential dangers (internal and external) to the organisation’s core assets (i.e. people), programmes, processes, property and reputation.
  • Vulnerability and acceptance analysis. Identify the specific vulnerabilities (and strengths) of the organisation, its staff and programmes. Evaluate the level of acceptance of each of these in the area.

Step 2: Risk identification and evaluation (risk assessment)

  • Risk identification. List the plausible risks of working in the context based on the identified threats and the specific vulnerabilities of the organisation and its staff.
  • Risk analysis and evaluation. Assess the likelihood and potential impact of the identified risks. Rate them accordingly, from low to high, to determine priorities for mitigation measures and management planning.

Step 3: Risk mitigation and management planning

  • Mitigate identified risks. Determine the measures needed to reduce the likelihood and/or impact of each risk. These will often be influenced by the organisation’s security strategy.
  • Address residual risk. Reflect on any residual risk that may remain after all mitigation measures are implemented. Decide whether to accept, avoid or share it. This will be guided by the organisation’s objectives, risk appetite and programme criticality.

Step 4: Monitor and review

  • Monitor and review: Continuously monitor, review and adapt the risk assessment as necessary to ensure it remains relevant and effective.

This process can be documented and form part of security plans.

Analytical process

The individual(s) leading or coordinating the risk assessment process, usually security staff, should aim to ensure inclusivity. This involves gathering perspectives and information from all staff and considering risks through different lenses. This approach fosters a common understanding of risks and a shared responsibility for security measures. An example would be a risk assessment workshop where individuals with diverse personal profiles and roles come together to discuss the threats and vulnerabilities they personally experience.

Last chapter

Next chapter

4.2Developing a security strategy