Security Risk Assessment Should Not Be a Template Exercise
- M G

- Jun 26
- 5 min read

Introduction
Security Risk Assessment is one of the central tools of security risk management. It is expected to help organizations understand threats, identify vulnerabilities, assess potential consequences, and make informed decisions about how to protect people, assets, and operations. However, in practice, many security risk assessments become overly standardized documents. They follow a familiar format, use a standard risk matrix, assign likelihood and impact scores, and produce a polished report. The problem is that a polished document is not necessarily a useful assessment.
The purpose of a Security Risk Assessment is not to demonstrate that a process was followed. Its purpose is to reduce uncertainty and support decisions. This distinction is important. In complex environments, especially where organizations operate in fragile, conflict-affected, or politically unstable contexts, risk is not static. It changes with geography, timing, actors, activity type, staff profile, and operational exposure. Therefore, a meaningful risk assessment must be context-specific, collaborative, time-sensitive, and actionable.
ISO 31000 as a Foundation, Not a Finished Product
ISO 31000:2018 provides a useful foundation for risk management. It emphasizes the importance of establishing context, identifying risks, analysing and evaluating them, treating risk, and continuously monitoring and communicating throughout the process. This structure is valuable because it prevents risk management from becoming improvised or purely reactive.
However, ISO 31000 is a general risk management standard. It is not a ready-made Security Risk Assessment methodology. It does not automatically answer the practical questions that security managers face in the field: Is this route acceptable today? Should staff remain in this location? Is the organization exposed to targeted or incidental threats? Are existing controls realistic? What decision should leadership make now?
This is where misuse begins. When ISO 31000 is treated as the assessment itself, rather than as a framework supporting professional judgment, the process can become mechanical. The organization may end up with a technically correct document that does not reflect the actual security environment. In security risk management, the framework should support the analysis; it should not replace it.
Risk as Uncertainty, Exposure, and Consequence
Academic risk literature generally treats risk as more than a simple combination of likelihood and impact. Kaplan and Garrick’s classic formulation asks three basic questions: what can happen, how likely it is, and what the consequences are. This remains highly relevant to security risk assessment. Aven’s work goes further by emphasizing uncertainty and the severity of consequences. This is particularly important in security contexts, where data is often incomplete, adversary behavior is adaptive, and conditions can change quickly.
For security managers, this means that risk assessment should not only classify risks into low, medium, or high categories. It should explain uncertainty. What do we know? What do we assume? What information is missing? How reliable are our sources? What could change the assessment? A risk rating without explanation may create false confidence. A good assessment should make uncertainty visible so that leadership understands not only the risk, but also the limits of the assessment.
The Problem with Generic Risk Matrices
Risk matrices are widely used because they are simple, visual, and easy to communicate. They can help organizations prioritize risks and explain decisions to non-specialist audiences. However, they also have serious limitations. Cox’s critique of risk matrices shows that they can suffer from poor resolution, range compression, and misleading prioritization. In simple terms, very different risks can end up with the same rating, and risks that require different responses can appear equivalent.
This does not mean that risk matrices should never be used. It means they should be used carefully. A risk matrix is useful only if it improves decision-making. If it helps prioritize resources, define escalation thresholds, assign responsibility, and guide mitigation, then it has value. But if it is included only because the template requires it, it becomes decorative rather than analytical.
In some cases, a narrative assessment, scenario-based analysis, decision tree, exposure-based model, or weighted scoring approach may be more useful than a traditional matrix. The method should be selected based on the decision being supported, not because it is familiar.
Context Must Drive the Assessment
A strong Security Risk Assessment should begin with the operational context. This includes the organization’s mandate, risk appetite, staff profile, location, activity, timing, movement patterns, local relationships, threat actors, and available response capacity. The same threat can produce very different risks depending on who is exposed and what they are doing.
For example, a protest near an office may represent a manageable disruption for national staff but a serious exposure for international visitors unfamiliar with the environment. A road movement may be routine for an experienced field team but inappropriate for a new partner organization without communications, local contacts, or emergency support. A city-level “medium risk” rating may hide highly specific neighborhood, route, or timing-related risks.
This is why generic assessments often fail. Security risk is rarely only national or even city-level. It is often route-specific, site-specific, activity-specific, and time-specific.
Timing and Review
Risk assessments also have a shelf life. In stable environments, annual review may be sufficient for some organizational purposes. In volatile environments, it is not. Political unrest, conflict escalation, criminal activity, access restrictions, new checkpoints, public demonstrations, military operations, or community tensions can change the risk picture rapidly.
Therefore, risk assessments should be reviewed through two mechanisms: scheduled review and trigger-based review. Scheduled review ensures discipline. Trigger-based review ensures relevance. Any major incident, operational change, deterioration in the threat environment, change in staff exposure, or new information should trigger reassessment.
The question should not be, “Do we have a risk assessment?” The question should be, “Is this assessment still true?”
Collaboration and Local Knowledge
Security risk assessment should not be produced in isolation. Local staff, drivers, program teams, logistics personnel, HR, leadership, partner organizations, and external security networks may all hold relevant information. Each group sees different parts of the risk picture. Drivers may understand route dynamics. Local staff may understand community tensions. Program teams may understand acceptance and access. Leadership understands organizational tolerance and decision constraints.
A collaborative process improves both accuracy and ownership. It also reduces the risk of producing an assessment that is technically sound but operationally unrealistic.
Conclusion
Security Risk Assessment should be treated as a decision-support tool, not a compliance product. ISO 31000 provides a valuable foundation, but the real quality of an assessment depends on context, judgment, uncertainty analysis, collaboration, timing, and practical action.
A good assessment should not simply classify risk. It should help answer what should be done, by whom, by when, and under what conditions the decision should change.
The strongest Security Risk Assessments are not the ones that look most standardized. They are the ones that help organizations make better decisions before the situation forces those decisions on them.



Comments