I am evaluating Eramba and interested in hearing whether my GRC model is possible to use or if it is incompatible:
I would like to enter assets (A) with various owners and associate them with [business unit/security policy/something else in Eramba] (X). Then I’d add a set of internal controls (C).
Cruciallly, I want to specify that all these assets (current ones in A as well as future ones) associated with X should be subject to the controls in C. This would automatically force the owners of A to audit them with respect to C, with the same periodicity and timeframe. Note that I would only have to associate C with Xone time, not with individual assets. The only thing I have to do when adding a new asset would be to associate it with X.
Is this model possible in Eramba? Or how should I change my model?
One thing that will be helpful for you to see relationships within Eramba is to jump into the demo, go to the screen in question and click “Help” and it will give you a chart of where relationships exist.
For the elements you mentioned -
Assets relate to business units, but do not relate to controls.
Assets relate to Risks, which then relate to controls.
A control has a maintenance functionality (things to do the needful to maintain it) and an audit functionality (a way to audit the functioning of the control). You can include instructions on the maintenance/audit pages to tell the end user where to pull the list of assets that they need to perform it for.
I suppose the risk would be the glue here → One risk can be associated to multiple assets, then the control is associated to the risk, however, that will get you into a bit of an audit documentation hole that you don’t want to be in. Specifically, if you add an asset to scope today, then you get audited on last quarter’s review, they’ll ask where the documentation for the new asset (that was out of scope) happens to be.
So, I suppose it seems like it may work, but there’s some nuances that I don’t understand from your approach. Is it correct to assume you’ve gone through some of the wonderful documentation?
Yes, I’ve spent many hours with the documentation, enough to understand that the approach Erambra takes to GRC is quite different from the approach of the current GRC system we use. Not saying it’s bad, just different. For my organization to embrace a migration to Eramba it would be helpful to change as little as possible in our GRC model and the way we work.
We have hundreds of controls and assets. For Eramba to fly, it’s crucial that these controls apply automatically by virtue of being associated with some kind of category. Our current GRC system is quite flexible in that regard; it accepts controls being associated with many different kinds of categories such as asset type, organizational unit, roles and so forth.
I’ll continue my evaluation and see if I can find a way that works.