Risk Statements vs. Individual Risks

[Carlos58]

Apologies for asking so many questions, but we just recently implemented IRM.  We are debating on the advantages or not of using Risk Statements vs. creating individual risks without inherit any information from the Risk Statements. We are wondering what approach have other organizations taken. Do you create Risks using Risk Statements or not? and why?

Thanks for your feedback,

Carlos

[Mehernosh Amrol]

I've found it much easier to create the Risk Statements and associate with the Entity Type.  By doing Individual Risks, you'll have to type/Copy-Paste the information (Likelihood/Impact, etc.) for EACH Risk you create.  You'll also have to add Owners, Assessment Type, etc manually.  Creation and reporting are automated for you using the Risk Statements and Entity Type.  You will also lose out on Reporting on the Risk rating for the Risk Statements.

I see a more negative impact of NOT using the Risk Statements.

[Carlos58]

Mehernosh, thanks very much for you comment.

I thought that Likelinood & impact was done at individual Risk level during the risk assessment, and not at Risk Statement level.

The other issue I find is that when you create several risks by using a risk statement that is related to several entities, you can not modify the description of each individual risk. Is the intention of a Risk Statement to have all risks with the same description that they inherited from the Risk Statement? 

[Mehernosh Amrol]

The Likelihood & Impact are set up from the Risk Statement and, if I remember correctly, can be modified at the Risk level when NOT USING Advanced risk.  I have Advanced Risk enabled in my PDI and I can't modify it.  (I'm new to Advanced Risk.)

The Description is read-only when inherited by the Risk Statement to ensure that the meaning is the same.  Think of the Risk of a fire.  The description of a fire is the same to a Facility or a Data Center, correct?  Loss of Data, Loss of Personnel.  Why would want the Risk Description to be different for each Entity.  You also have the option of unchecking the box for "Inherit from risk statement" if you really need to.

This may be a helpful link:

https://www.youtube.com/watch?v=ecTY0MpHeB4

[Sebastien Fix]

Hi, 

If you define your risk names as very specific ("Risk of downtime of SAP for the Finance process"), then they wouldn't work as Risk Statements ever. In that case, simpler to make Risks. This is the quick & dirty way though 🙂

If you rethink your way of describing your Risks as something more general "Downtime of ERP system" then you can use "Finance process" as your entity and then reuse it for "HR process", "Accounting process", etc Now it makes sense to use Risk Statements and get all the good stuff about Risk Aggregation and Reporting.

While the name of the Risk would have to be the same as the Risk Statement, you still have fields (OOTB) for description or Additional Information to write down more specific details related to the Entity being reviewed.