Why is your risk analysis taking weeks or months, instead of hours or days?
Why don’t stakeholders take your results at face value?
Where are you going wrong with your risk measurement process?
In risk analysis, it’s easy to lose focus, run off the rails and produce results that don’t support business decision-making.
You may end up showing too little data to convince your stakeholders or just asking them for too much--for instance, how can decision makers sort out 158 “high risk” items on a risk registry of 200?I’ve found that if you practice these five habits, you’ll approach your risk analysis tasks with a lot more clarity, and your end product will be easier to understand and more actionable by the organization.
1. Learn the Purpose of the Risk Analysis
Who is your audience? Why are you doing this analysis? What question(s) will the analysis answer? What is the timeline for this initiative?
Understanding underlying issues, initiatives and questions will only help in the process. Identifying these key questions upfront, will result in increased efficiency and delivery.
Each initiative is different and will carry new stakeholders and objectives. This will help scope the analysis properly, understand what types of analyses need to be done, and assist in the final deliverables of the project (i.e. format, wording, and content included).
2. Understand the True Loss at Stake
In every analysis, defining the Loss Event and Threat Event is vital. But they’re often confused.
- A Loss Event arises when a threat attempts to compromise an asset and the asset is susceptible to the attack, which results in a material loss to the organization.
- A Threat Event is the attempt that may not necessarily result in a loss.
Identifying where the loss occurs will prevent any confusion in the analysis process. This will also prevent scope creep: Far too often analysts think about those “what-if” scenarios that send the analysis on a tangent and do not fit within the specified scope.
3. Define to Avoid Double Counting
Your company should have a risk model, methodology or common language and consistent definitions to prevent miscommunication and double counting at a grand scale. (We recommend the FAIR model).
For example, knowing the difference between…
- Reputational Loss/Damage (losses resulting from an external stakeholder perspective that an organization's value has decreased and/or that its liability has increased) vs.
- Competitive Advantage (losses resulting from intellectual property or other key competitive differentiators that are compromised or damaged)
…will solidify your department’s and organization’s methods and prevent overstating losses. When the model, methodology and language is not known organization wide, documenting the important items will aid in defending the analysis and work conducted for the project at hand.
4. Don’t Get More Granular than You Need
Some risk analysis departments utilize all data available to them from Subject Matter Experts (SMEs). Often, when hunting down detailed data, some items may be forgotten or even already considered in another dataset.
To avoid diminishing returns on data gathering, conduct research and data gathering at a high level. For example, when analyzing the patch levels of servers related to X, we do not need to know the 5-year history of each patch conducted on each server within the organization. Use your judgment to conduct your analysis accurately with a useful amount of precision.
5. Document Everything
Documenting scope, assumptions, and rationale leads to clear and defensible work. Forgetting to document something can result in many issues, such as incomplete, inaccurate work or even indefensible work when presenting final results.
For instance, if you conduct an analysis on the risk associated with current security and password practices for organization X, and the organization’s initiative at hand is to implement multifactor authentication, don’t just produce results saying the initiative would be cost effective, explain what was considered within your work. It may sound obvious, but I’ve seen this mistake made.
Documenting throughout the entire analysis will show key rationale and reasoning behind each data set used. By documenting thoroughly, this will allow the deliverable to reference historical data that will be known organizationally. This makes the work and results more commonly accepted and powerful in the decision making process.
Related:
What Belongs on a Risk Register?
