Question - I have been using Eramba wrong, is it bad?

Forum - Software
1

I know it’s a provocative title, but I think it’s true. Despite having used Eramba for somewhere between 6–8 years (first the community edition then the enterprise) I realized recently I have been using it wrong.
I actually went back and watched a few more episodes of the learning courses offered on eramba.org and realized my mistakes.

Here is a quote where we do things differently than Eramba advises.

Episode 1

Introduction to the Internal Control Module

In eramba, Internal Controls are activities that your organisation performs to deal with a problem (in eramba, that is Risks, Compliance Requirements and Data Privacy).

Eramba says:

Every time someone moves a finger in your organisation, they are doing something, therefore an Internal Control is likely to exist.
Internal Controls are solutions to Problems.

We went at it a different way, and it kinda works for us, so the reason for this post is to get some feedback if we are missing something major because of this “mistake”.

We basically went at it like this:

Analyse context ⇒ determine assets to protect ⇒ check for risks ⇒ identify measures to mitigate ⇒ summarize treatment (aka those measures) in a policy ⇒ use one or more “internal controls” in Eramba to periodically check the execution/implementation of some details mentioned in the policy

Let me give you an example:

When the ISO 27001 Annex A ask what we do about “8.13 Information backup” our reply is “here is our Backup Policy” which details how we handle that.

The policy contains a high-level outlook but also the specific details of what/when/how is to be backed up as well as a matrix listing all systems with backup targets and RTO/RPO.

As a policy is basically just a piece of paper as I used to say before Eramba it’s useless without monitoring.

So we chose random parts of all our policies which are suitable to be monitored and/or measured and use the “internal controls” to verify.

i.e. we have internal controls where we regularly approach the person responsible to provide proof that he:

  • setup backups in the intervals specified in the policy
  • has done 2 successful restore tests every 6 months
  • is using encryption as directed in the policy

This has worked pretty well, the only issue I noticed was when assigning controls in eramba, the policies get automatically added.
That’s when I realized that I have many controls mapped to one policy while Eramba seems to say that one control should be mapped to multiple policies.

So for us, controls are a means to check the implementation and effectiveness of policies.

Sorry for the long post, just wanted to get some feedback on what you guys reading this forum think about this issue.

2

If Eramba works for you and meets your GRC objectives without adding unnecessary burden then you have it right. I’m finding I have one or more controls for each policy.
My struggle is mapping Eramba’s granular control audits to our existing broader scope internal audits, where one audit covers many controls. Either I change my practice or use Eramba in a highly customised (and burdensome?) way.

2 Likes
3

So have we. The interesting question is how are you using controls? As Eramba said: “Internal controls are solutions to problems” or differently?

Would you mind giving me an example of say two controls and the policy they are mapped to, so I get an idea of how you are using them?

1 Like
4

We are still in the process of implementing the system, so the mapping is still in progress. However, the approach I have taken for our ISO 27001 compliance is to have one Eramba Control for each Annex A control as a starting point. Hence the following controls map to our Security Incident Reporting procedure:

  • Response to information security incidents
  • Assessment and decision on information security events
  • Information security incident management planning and preparation
5

I have the exact same approach as you @Ovidiu
Many controls for a policy, or control point.

We have started “implementing” ISO27001:2022 by implementing ISO27002:2022 at first. This has caused us to have a lot of different controls and while Eramba says that they experience that 1 control can mitigate 5-15 problems we have some of our controls which have a much wider reach(some compliance elements has +30 controls) due to they way we have structured our GRC process.

And as Eramba says, everyone does GRC a little bit different from each other.
I can see that i work with it differently from other companies in our group but it works for us.

After we are done structuring all the controls meant to sustain ISO272002:2022 I will map our controls towards ISO27001:2022, NIS2, NIST and GDPR of course where relevant

So while maybe not intended to be used this way, I find that Eramba in our usecase works best this way for us

6

Thank you all for describing your different approaches, it certainly helps figure out if or what to change with our own approach.

As far as I remember, my approach which differs from Eramba has only once bothered me. Namely, when I edit a risk, I would assign policies, and then I’d expect the controls assigned to those policies to be automatically assigned but Eramba does this in reverse (if I assign controls it auto-assigns the connected policies).
So I have learned that after I assign policies I need to assign the controls for these policies and then double check that Eramba hasn’t auto-assigned any policies which I wouldn’t like. No big deal, just something I need to be aware of.

7

This is undeniably true. We will never tell anyone how they should do GRC. We show them one way that works for most organisations and is up to them to take it (fully, partially, etc) or not.

But everyone should bear in mind eramba is not a spreadsheet nor a custom made software, so if you deviate from “our” recommendations you might (maybe yes , maybe not) hit a wall for which there won’t be an easy fix, potentially making eramba more cumbersome than your spreadsheets.

1 Like