Can't edit Risk Description when inherit from Risk Statement

[Carlos58]

We just installed IRM. If I create a risk from a Risk Statement, the Risk inherits the description from the Risk Statement, but it doesn't let me edit that description for the risk. Is this the way it suppose to work? I would imagine that it should import the Risk Description from the Risk Statement, but it should let you edit it if necessary. Can anybody clarify for me why this happens?

Thanks for your help.

Carlos

[Sulabh Garg · Accepted solution]

Hello Carlos,

Its optional for you if you want to inherit Risk description from Risk statement or not using "Inherit from risk statement" checkbox. If you do not want to inherit Risk statement's description you can uncheck it.

If you do not want to make the 'Description' as Read only when you checked "Inherit from risk statement" checkbox, then you need to deactivate the UI policy named as "Make description, type, category, classification, assessment and name visible statement is not empty".

Please be aware if you deactivate the UI policy it will also make other fields as editable such as type, category, classification, assessment.

Please Mark ✅ Correct/helpful, if applicable, Thanks!! 

Regards

Sulabh Garg

[Carlos58]

Sulabh, I really appreciate your clarification. It makes sense. Thanks!

[Jakob V]

Hi.

You are right. The risk inherit risk statement information, such as description.

To explain why it is this way we need to look at how Risks are connencted to risk statements in terms of reporting, aggregation etc... For me this makes sense because we would not really want, from a risk perspective, anyone to change the "risk statement/risk" while assessing it. Just to make my point clear i will use the risk statement title as the example, but the principle apply for the description aswell.

Lets say the risk statement title is "Downtime due to human error". The 2 risks we create in relation to this risk statement are:

• Downtime due to human error (Risk statement)  Messaging App (entity)
• Downtime due to human error for (Risk statement) instant money tranferring app (entity)

Both these risk aggregate their score to the risk statement. In the end we are actually adding all of the risks together and aggregate to the risk statement and so on.

If we changed the title for the risks. You can achieve this through changing the description aswell (changing mindset of assessor, framing the risk differentluy, adding prerewuisites to assessments etc)

• Downtime due to Technical error (Risk statement)  Messaging App (entity)
• Downtime due to Human error for (Risk statement) instant money tranferring app (entity)

While the risk statement stay the same "Downtime due to human error". Due to our "small" change from human to technical we have actually made the risk aggregation irrelevant, because we aggregate risks that are different, not the same.

However, the point here should not be that it is impossible to add information to the risk but be careful. In relation to your "issue" above i would suggest that you add new information to the risk record. Below you see information from the risk statement, but also specific field that is related to the risk.

[Carlos58]

Jakob,

Thanks for the explanation and for taking the time to clarify. It helps me better understand the advantages of using Risk Statements.

We are implementing IRM globally, so I thought that the Entities would refer to a geographic location or to an actual Legal Entity (company); however, it looks like you can create entities for a business functions, and application, or a process. Is this correct?