Access Management - Mapping organizations to Groups in eramba

A basic step in the implementation of eramba is to create groups for every department in your organisation (no matter if they will ever log into eramba or not).

The reason for this is:

  • You want to assign “things” (Risks, controls, etc) to owners in order to ensure accountability
  • You may want them to logging eramba to provide you with feedback (when a deadline is due, etc)

To achieve this you need to create one group for every department in your organisation, trouble is organisations come in different shapes and forms. The solution for this is to use naming conventions:

The example above shows a typical company, where your “groups” in eramba will be most likely “IT” , “Finance” and “HR”.

For example:

  • When a Risk that belongs to “IT” will be due, notifications will be triggered to whoever is a member of the group “IT” (typically we recommend assigning one or two user accounts per group to make sure someone will respond).

You might be tempted to create groups for the “Tax” sub-department in the Finance department. We typically recommend keeping things simple unless you need to complicate them. Remember the two purposes of why you need groups:

  • Accountability
  • Feedback

Will there ever be an item owned by the “Tax” department? Will I ever need feedback from them? Feedback that can not be provided by the more generic “Finance” department?

Some companies work in a group model, something like the screenshot shown below:

The principle is the same, you will create groups using based on the criterias mentioned before. This time your groups might use a different naming convention, for example:

  • UK_Sales, Germany_Sales
  • GRC, IT

As you can see, eramba has no concept of hierarchy (one on top of hte other) and therefore you need to use naming conventions to differ the “Sales” team in UK and Germany.

This decisions will most likely take place in other modules in eramba, for example when Business Units are created (this is only needed for Risk and Data Privacy use case). These business units many times “mirror” your group definition and therefore must follow the same naming convention scheme.

1 Like