This op-ed was written by Gonzalo de Palacios. The opinions expressed in this op-ed belong to the author and do not reflect the opinions of the European Interagency Security Forum (EISF) or any employee thereof.
Traditionally, many NGOs have used security level systems to adapt their operations to the evolving context. Through the use of social, political, security or other types of indicators, security managers are able to increase or decrease the security level and act accordingly.
Security levels can go from safe and calm contexts to very insecure and extreme situations that could lead to the evacuation of staff or the closure of operations. I have always had difficulties in linking the security levels and their indicators with the risk assessment and furthermore, moving the levels up or down poses several challenges as shown by Kelsey Hoppe in her blog for HPN: ‘Climbing back down: the challenge of reducing security levels’. I have seen very committed staff who did not want to increase the security level because it would mean limiting access and movements (private and professional). I have also seen tensions arise between HQ and field staff when decreasing the security level because the former wanted to have certainty that the situation was conducive to relaxing the heightened security rules.
This security levels approach is very much in line with the extended risk formula: Risk = Threat x Vulnerability.
However, if we keep in mind the ISO 31000 risk management approach, where the achievement of organisational mandates is the primary objective – i.e. that organisations should plan how to stay rather than how to leave and that risk is defined as the effects of uncertainty in the achievement of those goals – a scenario planning approach for managing risks may be more appropriate than a security level system.
While a security level system and indicators may look at what has already happened, scenario planning tries to anticipate what may happen and be ready for ‘how the future might turn out’.
Which system should organisations use? As Lisa Reilly, EISF Executive Director, said, ‘I do not think it is either levels or scenario planning but both can be used together.’ A security level system could be used to obtain the big picture and define operational conditions or minimum security standards, while scenario planning is useful for decision-makers to adapt to a changing reality.
Scenario planning methodology
Scenario planning is a support process for decision-makers to help them face uncertainty when pursuing the organisation’s goals and still have the ability to stay and deliver. Scenario planning is not about eliminating existing risks but about understanding them and their possible consequences better and therefore how to adapt to the new situation.
Once it is clear to an organisation that it wants to fulfil its mandate and try to stay even if the situation deteriorates, it is important to identify the driving forces that may influence the achievement of the organisation’s goals. These driving forces could be issues such as the availability of funding, access, host country regulations, availability of human and material resources, the existence of other organisations, etc.
The next step in the process would be identifying the critical uncertainties or limits to be able to prepare and anticipate the evolution of the context. In security risk management, these uncertainties could be the evolution of the overall security situation (improvement or deterioration), and the capability of an organisation to manage risks.
Once the critical uncertainties have been identified, it is possible to define the different scenarios:
Scenario 1: security improves, but the capability of the organisation to manage risks decreases.
Scenario 2: the security situation improves, as does the capability of the organisation to manage it.
Scenario 3: the security situation deteriorates, as does the capability of the organisation to manage risks.
Scenario 4: security deteriorates, but the capability of the organisation to manage risks increases.
When defining the scenarios, it is recommended to establish the indicators that would help identify how the security situation evolves, the capability of the organisation to manage risks, and the triggers that would indicate it is necessary to take certain actions. Indicators should refer to contextual issues that indicate an evolution of the context, whereas triggers should refer to events affecting the security (e.g. incidents) and the risk management (e.g. changing rules) of an organisation.
Among the possible recommended actions, there could be the possibility of leaving or evacuating a certain location, but also the option of establishing a remote programming approach, to bring new staff or staff with different profiles, invest more (or less) in security risk management, type of projects to implement, staff training needs, adaptation of security protocols, etc.
For appropriate scenario planning, it is important to first do a risk assessment. Conceptually, this risk assessment would be placed in the centre of the axis of the graph shown, taking into consideration that from that ‘photograph’ that fixes the situation and risk management in a particular time and location, the security situation and the capabilities to manage risks may change.
In a scenario planning system, there are elements that can be used in a risk assessment and vice-versa, as both processes are strongly linked. For example, when thinking about the improvement and deterioration of the security situation, we can also be talking about the impact of risks, whereas when thinking about the capabilities, we could be talking about likelihood, among other issues. The indicators and triggers can be easily linked with the identification of the source of the risk, with the reasons why the risk manifests itself and with staff and organisational vulnerabilities. And finally, the recommended actions can be linked with risk treatment measures (avoid, accept, reduce, transfer, retain).
For more information and reflection, the author can be reached at firstname.lastname@example.org