Specific Threat Assessment

Introduction

In the Specific Threat Assessment stage of the SRM process, we identify the specific threats to the organization for the SRM Area and provide a structured assessment of these threats in a similar way as the General Threat Assessment. Unlike the General Threat Assessment, which looks at the overall threat environment in the SRM area, the Specific Threat Assessment identifies the precise threats to the organization in that area.

Event Descriptions

The concept outlines that vulnerability to a threat may eventually manifest itself in the occurrence of undesirable events, and that risk is assessed as the combination of the likelihood of an undesirable event occurring and the impact would have if it were to occur. Therefore, to conduct a Specific Threat Assessment, it is necessary to generate an Event Description linked to the specific threat. An Event Description is:

The clear description of a harmful event (that involves harm to staff, projects or assets) that the SRA will examine, and must include the negative effect on the organization.

It is important to see that an Event is not the same as a Threat. We can do a Risk Assessment (Impact and Likelihood) on an Event but not on a Threat.

The identification of potential event descriptions to the organization in the SRM Area must be based on the security environment as indicated in the Situational Analysis, as well as actual security incidents that have occurred in the SRM Area. It is important to collect as much specific information as possible, as generic information is of lesser value in determining event descriptions. The incidents analyzed may have been directed at the organization or not, as understanding the entire threat environment is required to understand specific threats. Sources of information to complete this section of the SRM process could be security incident databases; provided by host nation security forces; provided by UN/INGO/NGO organizations; where applicable, provided by international armed forces in the SRM area; or other entities; third party member states; open-source information (e.g., think tanks and other academic institutions); neighboring country teams; and, most importantly the country team in the SRM area itself.

Incident data is however not enough; it has to be analyzed to determine trends and patterns to fully justify the identification of a potential event description to the organization in the SRM area. This will require a certain degree of analysis, the creation of charts and graphs, and mapping the incidents to extract the actual meaning of incidents that have occurred before. The “So What” principle must be applied when considering factual information to determine the real security implications of these incidents. This will allow a more credible determination of potential, specific events.

An effective Event Description will provide security professionals with clear parameters for examination. Event Descriptions should include references to Who may perpetuate the event, What the specific event may be, When the event may take place, Where the specific event may occur within the SRM Area, and/or How the specific event is envisaged. Note that the Why components are not generally required as it is generally irrelevant for event identification. Event Descriptions do not necessarily require all of these components but should include as many as realistically possible to inform the problem.

The following are two examples of Event Descriptions:
“Kidnapping targeting International staff for criminal ransom by non-state actors in Area 1”
[What] [Organizational focus] [Direct] [Who] [Where]

“Vehicle targeted and hit by IED along road X to Field Office Y”
[Organizational Focus] [Direct] [What] [Where]

These Event Descriptions provide sufficient information to narrow down the parameters involved and will allow for a more accurate assessment of the event than a general threat statement such as “Kidnapping”. The table below shows an example of how a list of event descriptions is generated. Note that each Specific Threat has a “worst-case” and “least-worst case” event description. The purpose of having two event descriptors with different outcomes is important to ensure the security practitioners understand various possible outcomes.

Event Descriptions should also reflect whether events result from a direct or indirect threat to the organization. Direct threats are those specific to the organization. Either a particular belligerent group or individual has stated the intent to harm the organization, or recent history has shown that the organization is the target of such a threat. This could include a deliberate attack on an office or vehicle, a public demonstration directed at an organizational location or the kidnapping of a staff member for political or financial purposes.

Indirect threats are those which may affect the organization negatively in a wrong-place-wrong-time scenario, through collateral damage, by association with the actual target, or where the organization is in the way. This could include staff caught in the crossfire between armed elements, or a public demonstration that damages a vehicle that happens to be near the crowd. It is important to note that the differentiation between direct and indirect (sometimes referred to as “Targeted“ and “Incidental“) can sometimes have a very significant effect on the eventual outcome of the risk assessment and so careful consideration, and notation is required for this component of the Specific Threat Assessment. Both direct and indirect threats can be further subdivided into those which are “known” (were statements of intent to harm the organization has been made or it has happened before), or, “assessed” (where although no intent has been stated, the analyst assesses that the threat exists).

The importance of a clear and detailed Event Description cannot be overstated. The identification and recording of these Event Descriptions in the Specific Threat Assessment will effectively drive the rest of the SRM process. Well-defined and realistic Event Descriptions will produce a valid and helpful SRA, but vague or misleading Event Descriptions will produce a poor assessment of risks.

Note: Remember from the Project Assessment we identified where programs are being delivered that are outliers from the “normal” operations of the organization. Where certain projects or departments may be exposed to a threat or have a different profile they require specific event descriptions. This is reflected in the event descriptions and could look like the examples below:

In the example above the project assessment identified:

• Only specific staff are operating in the areas of active conflict and so in the event description, it is made clear that this only affects those staff.
• The country office (HQ) is a higher profile location than other offices and so there are two event descriptions (one for HQ and one for the other offices) that will allow the risk assessment to consider the differences in the risk and allow security decision-makers to take nuanced and appropriate risk management decisions.

Threat Assessment

Once the Specific Threats are identified and Event Descriptions have been fully laid out, the next step is the actual assessment of each event. Just like the General Threat Assessment, the Specific Threat Assessment evaluates each event on three variables: Intent (of the threat actor), Capability (of the threat actor), and Inhibiting Context (of the environment in which the threat occurs) in regards to the event as described in the Event Description.

• Intent – This is defined as “the motivation or disposition of a threat actor to cause the threat event as described” and refers to the mental orientation of the threat actor towards the target. In cases of Direct Threats, security professionals can assess Intent against preset qualifiers using existing knowledge (e.g. measuring the intent of kidnapping based on publicly expressed design and/or past incidents). For Indirect Threats, security professionals will have to utilize existing knowledge of the general situation. For example there may be Indirect Threats where threat actors have stated intent to do harm to non-affiliated organizations, such as Government Ministries, and while this threat is not directed at the organization, given staff may work in these Government Ministries, it must be considered as an Indirect Threat; or, recent trends observed in the ongoing conflict between the rebels and the Government indicate that the fighting is moving closer to two district offices. Collateral damage from inaccurate rebel or government artillery and rocket fire could present an Indirect Threat to the organization.
• Capability – This is defined as “The capacity or ability of threat actors to cause the threat event as described.” This component refers to the physical ability of the threat originator to carry out the ‘threat event’ if it so desired. Capability combines elements of knowledge, skill, and training; financial resources; human resources; planning and coordination; and logistic resources to execute a particular course of action. Typically both resources and knowledge are required; one without the other means that there is no capability. Capability must be assessed for the timeframe of this risk assessment for it to be rated. For example, an extremist organization may be very capable, but if the fighters and equipment are not deployed in the geographical area under consideration, for the threat assessment, the capability should be rated low because the capability is not “in the environment”.
• Inhibiting Context – This is defined as “how permissive the context is for the threat actors to cause the event as described” and refers to the external (i.e. non-organizational) environment in which the threat exists and the degree to which the environment is hostile or permissive to the threat and/or the threat originator. This component can be very broad, and care must be taken to not overreach. It may include elements such as the effectiveness of local law enforcement, or the general disposition of a given society towards that particular threat or threat actor.

As with the General Threat Assessment, the Specific Threat Assessment requires that one descriptor is chosen for each variable from the 1-5 scale, this time focusing on the event as described in the Event Description and using the table below. If it is difficult to choose between two descriptors, the SRM allows the user to choose a “half point” between the two (e.g., 2.5 between 2 and 3)

The scores for the three choices are added to give an overall Threat Score for the event. Each event, therefore, will get a Threat Score and a Threat Rating, exactly like the general threat categories in the General Threat Assessment.
The example below gives a Threat Score of 12 (4+5+3) and based on the same score distribution, the Threat Rating for the event is High.

Conclusion

It is imperative that security professionals fully consider each component of each Event Description within their Specific Threat Assessment and gauge their assessments as objectively, and comprehensively, as possible. It is equally imperative that these assessments are based on factually based judgments and not on supposition, hearsay or conjecture. Choices made here should also reflect threat-related information gathered in the Project Assessment.

At no time should the descriptions be chosen to achieve the desired Threat Rating. Any attempt to “retrofit” the General or Specific Threat Assessment will corrupt the whole SRM process. Considering that security decisions should never be made based on threats, there is absolutely no reason to manipulate the result of any threat assessment and too many reasons not to.

Once each Event Description is assessed by evaluating the three components of intent, capability and inhibiting context, an overall Threat Score can be generated and documented. The overall Threat Scores can then be used further in the SRM process thus:

• Security professionals will have an overview of the overall threat scores for all events. This will give them a clear ranking of the severity of each threat in the geographical area relative to the others and, if required, relative to other threats in other areas of operation.
• The overall threat scores should also be stored in a centralized IT system for the next phase of the SRM process – the Security Risk Analysis.