3 Ways to Get a Risk Analysis Project Off to a Bad Start

3-Ways-to-Get-Your-Risk-Analysis-Project-Off-to-a-Bad-Start.jpgThe first big step in a risk analysis is scoping.  Each part of the analysis process builds on the other so if you get scoping wrong, the rest of your analysis is on shaky ground at best.  Remember,  scoping is where you clearly:

  • Identify what question you’re looking to answer via your analysis
  • Uncover what assets, threats and loss types could impact said question
  • Surface what assumptions you are, and equally important, are not making.

Get off on the right foot on scoping – avoid these three biggest pitfalls/missed opportunities I've seen as part of my scoping work with customers:

1.  Giving in to Scope Creep

It’s not an uncommon experience, especially when looking for scenarios to make up a risk register, that one scenario almost imperceptivity blurs its way into another.  Where collectively we thought we were talking about secure coding practices on web applications for example, we somehow end the conversation with secure coding when it comes to product security.  Both concerns, yet radically different scenarios. 

One of the biggest markers for scope creep is a lack of clarity.  This comes in the form of an unclear loss event, unsure assets involved and/or relevant threat communities.  Speaking from experience, one of the greatest skillsets an analyst can develop is making sure that the focus of a scoping session stays on the original intent of scenario (i.e. what question[s] we are looking to answer), as well as ensuring that you can find your way out of a rabbit hole.  

2.  Losing Sight of the Loss Event

I frequently see scenarios proposed that would better be categorized as control deficiencies, rather than loss events (in other words, risks).  This would include things like: inefficient security awareness and training, inadequate SDLC process, poorly managed systems, etc.  These items may very well be concerning and could be contributing factors to a loss event, but you cannot attribute a frequency or a magnitude, the two critical components of a loss event.  

What you can do though is tease out what the scoping team is concerned with; what is that scary scenario, if it did occur, that this control deficiency would play a role in?  Inefficient security awareness and training could possibly be tied to increased successful phishing campaigns.  Inadequate SDLC process could be tied to a greater number of successful web application attacks.  Poorly managed systems could be tied to larger malicious code losses on internally managed systems.

3.  Not Thinking about the Next Step (i.e. Data Gathering)

Nothing is more frustrating to your constituents and business subject matter experts (SME’s) than placing more time on their calendar to ascertain information you should have gathered the first time around.  I'm referring to the final stage of scoping, identifying the SME's who will be able to provide you data associated with the scenarios developed.  I realize that this is more of a missed opportunity rather than a scoping pitfall, but I’ll tell you that you gain more allies than detractors by making sure you understand how one phase flows into the next.  Remember, every little bit helps. 

Related: 

Anatomy of a FAIR Risk Analysis

5 Habits for Highly Effective Risk Analysis

Learn How FAIR Can Help You Make Better Business Decisions

Order today
image 37