Amedeo Maturo

Protección de Datos y Administración Electrónica

Road To CISA – Step 4, Risk Analysis

It’s spring time here in Alicante, but that doesn’t mean that I abandoned my dear CISA Review Manual 2013. Today, I’ve been studying the intriguing chapter referred to «Risk Analysis«. And the first question comes to mind: «What is Risk?». The question may sound like «What is Physics«, but I think that the answer is quite easier to understand.

Oxford Dictionary sais that «risk» is «a situation involving exposure to danger» but this definition doesn’t help much. I rather use the ISACA definition that shows us «risk» as «the combination of the probability of an (harmful) event and its consequence» (the «harmful» is mine).

Ok, we got the risk concept, so next step is Risk Analysis. Risk Analysis guides an IT Auditor to:

1. Identify Risks and Vulnerabilities (R & V).

2. Determine controls that mitigate R & V.

Risks are not a static entity, they evolve with the business. So, if Risks evolve, the Risk Assessment must be an ongoing process, like this one described in the following .pdf: Risk_Assessment_Process (yeah, I know, I’m not that good with PowerPoint…).

First step in this ongoing process: Identify Business Objectives (B.O.); than, take a look at the Information Assets supporting B.O. Now, look at what kind of Threats and Vulnerabilities (T&V) are those assets exposed to.

What probability exists that those T&V may have an impact to your assets? You may classify probability with a mere percentage (it doesn’t sound good to me), or classify based on this home-made scheme:

  • unearthly: if this happens, The End is near;
  • rare: that must be bad luck;
  • normal: you better fix it;
  • frequent: you better change something now;
  • very frequent: fix it or die.

Once you have performed the Risk Assessment, you need to put in place controls to mitigate risks. Obviously, I would start to mitigate the very frequent, frequent and normal risks, in that order.

Hey, wait…

What if you classify risks not by probability, but by the importance of their impact? I mean, maybe there’s a frequent risk with a very low impact on your B.O. Does have this risk priority to, say, a rare risk that can shot down your business? I didn’t find a clear answer to that question, so I need to study more. But, generally speaking, I thing that a good IT Auditor is able to deal with a clever combination of  these two values: Probability and Impact.

At the end of the Risk Assessment, IT Auditor presents the controls to Senior Management, with a list of countermeasures and their relative implementation costs.

CISA Review Manual 2013 suggests three ways of presenting these countermeasures:

  1. the cost of control, compared to the benefits of minimizing (or erasing) the risk;
  2. the Senior Management’s appetite for risk: how much risk they can accept;
  3. preferred risk reduction methods, i.e.:
  • terminate risk;
  • minimize probability of risk;
  • minimize impact;
  • transfer the risk via insurance (in this case, you can valuate the insurance premium as a implementation cost to reduce risk).

Now, if you think that the IT Auditor work is finished, well, think again. This is an ongoing process, so, at the end, you are like in the Monopoly board game: throw the dices and «GO».

 

P.S. Thanks shutterstock.com for the pic.

Categoría: Alicante, CISA, ISACA, IT Auditor, Risk Analysis

Etiquetas:

Deja un comentario

Archivos

Temas