I am using eRamba for an entity that is spread across different locations, which are my business units. These locations share some common assets (like computers, emails, etc.) and also have a common asset risk analysis, because the risks and controls for these risks are the same for the assets across the different locations.
However, my main problem is that not all locations have the same security maturity level. For example, not all controls active in location A are active in location B. Therefore, the risk treatment part (controls in place and risk score) is not representative of all the locations.
Should I duplicate the assets and asset risks for locations that are at a lower maturity level? Or should I continue using the same risk analysis and create a project to schedule the necessary improvements? Is there something Iām missing or doing wrong?
try giving an example so we understand better what you mean - for example:
risk scenario: locations are in unsafe neighbours and burglars could break in
Asset: locationA, locationB
treatment: mitigate
internal control: here is where you need to reflect the reality of this risk solution - for example if location A has great controls (Cctv, guards, etc) and location B has nothing then you need to ask yourself what wants the organisation want to do with location B, in eramba there are two options: an exception (if they dont want to do anything) or a project (if they want to do something in the future)
Having risk management by location is the concept of āauditable entityā ā meaning that you could have various entities - HQ, Location A, Location B.
Ideally, the GRC tool should allow the controls or risk instantiated to each entities - from data perspective, you are replicated risks and controls. This will then allow you to assess risks and controls at each entity. Of course, you should also think about how to aggregate the results.
In simple term, it is like you first build the library of asset. Then you can instantiate the assets to each entity ā AWS_server.Asia vs AWS_server.Europe. If the system design well, it should be easily to view AWS_server asset risk assessment from all locations easily.
Based on my experiences, unless it is absolutely needed (meaning very matured company), it is probably easier to simply name your asset with the location in the front if you firmly the need. Utilize the other customized field so that you can agreement the different location together easily will do.
Thank you, @kisero and @hpchao, for your replies. Iāll give an example to illustrate my situation:
My business units are my locations: LocationA, LocationB
Assets: Computers (Each location have pretty much the same assets so Iāve made only one asset linked to both locations)
Risks scenario: Computers get stolen
Internal control:
in locationA: CCTV, K-Lock, Guards
in locationB: K-Lock
This is where Iām encountering trouble. The two solutions seem to be:
I put CCTV, K-Lock, Guards as internal controls, and since we want to reach the same security level accros all location, i create a project to implement these control in locationB.
In this case, the residual risk will not be representative of each individual location but rather of the organization as a whole. This approach would be easier to manage with fewer items.
I duplicate the assets and risks for each location so that they are truly representative of each individual location in terms of controls in place and residual risks.
This approach would come at the cost of managing a lot more items.
I think itās up to me and my direction to decide which approach is better.
Donāt forget you also have the issues functionality for the controls. So ultimately you have three controls. CCTV, K-Lock, Guards. These all should mitigate the ācomputers get stolenā risk. However, if they are not performing fully (i.e. not implemented at a site) you can log an issue against them, this will be reflected in the risk (triggering a āControl has issuesā status), you can then assess the risk (from an organisation perspective) and amend the ratings accordingly. Obviously if the issues are then resolved (i.e. CCTV and guards are implemented at site B) then you resolve the issue, record the details and reassess the risk. You can of course use projects too as has been explained - personally i would do both, log an issue with a control, record that issue and have a project to fix the issue. You can also use customisation of fields (in issues) to capture data, i.e. add a location dropdown option with the location names so the issue records the location which can be reported on - albeit this dropdown would be independent of the business structure settings/config, either way, useful for reporting and notification purposes.