We sometimes have users that work for a holding type of company, this means a parent entity owns multiple entities.
Holdings can take many forms and shapes, but their essence is pretty much the same, a parent with or without central functions and entities underneath.
When working with Risk management in such scenario you will need to structure data in eramba in a way that each department on each company can store and see Risk related data that relates to them. You will implement the Risk case as per our documentation as usual but you will have to consider a few minor twists in certain areas:
- Access Management: you will use naming conventions to assign descriptive names to the groups of every department on every company, see this article for details. This is very important to make sure each company see what relates to them alone!
- Risk Classification: risks from all companies will be stored in eramba, the risk classification you define will apply to all these risks. You can not have a “per company” risk classification.
- Business Unit: your business units will need a naming convention such as Acme_Limited_HR, Foo_Bar_GmbH_Logistics to make sure they are clearly differentiated.
Now comes the Risk story, as you probably know from our documentation, to create a Risk you need three things:
- Context (BU, BU Processes, Assets, Third Parties)
- Risks (Asset, Third Party or Business)
- Solutions (Internal Controls, Policies, Exceptions and Projects)
The typical issue relates to how you will document and manage Risks (and controls, policies, etc). This is best explained with an example, say you would like to document the following Risk:
- The risk is that laptops can be lost or stolen, this is a common risk to all three companies. The risk is mitigated differently (each one of them has different encryption put in place, owned by different teams, etc) on each company. The risk is also higher (impact) in Acme than the other two, because they handle very secretive IP.
In this scenario, you will need to document the Risk three times, one for each company, because the Risk is just different (the treatment and the classification). You will need naming conventions just because from a reporting and data management perspective, you wouldn’t be able to see which item belongs to which company. The naming convention has nothing to do with ownership, that will be clearly differentiated.
- Imagine another example, where laptops can be lost or stolen is a common risk to all three companies. All three companies rely on the same mitigation controls managed by the same team.
In this scenario, all three Bussiness Units will be associated to a single asset, which will be linked to a single risk which will be linked to the same mitigation.
In summary, every time a Risk setting (classification, mitigation or context) is different, you will need individual risks, when the attributes are the same then you can re-use the same items.