Question: Compliance package applying to multiple assets

I’m evaluating Eramba and have spent a lot of time with the documentation. But I cannot figure out how to approach a situation where a compliance package applies to multiple assets (in my case IT systems).

I have 200 IT systems. Each of them is subject to the same compliance package that specifies 100 requirements. So in total there are 200 x 100 = 20 000 compliance requirements that periodically need to get reviewed/audited. Each system has an owner that is supposed to review the requirements for his or her system.

What’s your recommendation on how to deal with this scenario in Eramba?

I think using imports in the compliance analyse will be the best way to implement your case

auditing will be only for the controls … which are sure less and limited

Would that mean importing the same compliance package 200 times?

Is there a smooth strategy to “reusing” a single compliance package multiple times?


when importing you put in the field of assets , all the assets related to the compliance item
so you import once

1 Like

There’s a bit of an art when deciding how to break things down in a situation like this. Depends on what you need from and end reporting goal. For example, you could do this with either one compliance package or 200. If the requirements are the same and the consequences to your organization are the same, I would lean towards a single compliance package.

Then moving on to the controls, if your organization is really set up to where each of your 200 systems has a different system owner and system administrator, then you’re looking at creating a control* for each of the systems. For example “System 1 - Password Parameters” as each system owner may have some maintenance related to that. However, if some of these controls operate at a department or entity level you can consolidate and document your criteria for the maintenance/audits to include however many systems (something like a Global HR function that handles all background checks).

You don’t want these system owners in the compliance analysis area - that is where you will work. They will perform maintenances on controls, review their assets, policies and risks as assigned to them.


review this: Compliance Management | Eramba learning portal

the number of systems is irrelevant, read the documentation above please

Thanks for this @kisero! I had missed that help text. Seems like my approach of linking all my assets with a compliance package is not recommended. Neither is having a GRC system double as an inventory system or CMDB.

Have I understood it right that you advocate having GRC staff evaluate all assets with respect to the requirements, thereby making the number of assets as well as the asset owners (system owners in my above drawing) irrelevant? Instead of having 200 x 100 = 20 000 compliance requirements like above, I would have a mere 100?

you might not missed it, we wrote that this morning

nope, we advocate (strangely similar to avodado) to think in processes and who runs them and how well they deal (solution) to the problem you are dealing (requirement 1.3.4 from pci ,etc)

when doing the above, assets are irrelevant. process owners (not asset or systems or office or whatever) are needed, we all need accountability in particular when you start testing controls. i think you need to re-read the entire internal control documentation.

to be honest i did not read the entire post, we just dont have much time, but 20k requirements seems plain incorrect in our view and 100 seems ok.