Feature - Multiple Audit Sets Per Control

General
#1

Eramba is one of the best GRCs out there but we are finding one huge issue - The inability to create audit sets with different owners per control.

Let me explain. For Example, say we have a control called AD Password Policy that spells out the requirements for an AD Password Policy. We want to validate this quarterly so currently we can create an audit that is implemented and assigned to a group. This is no problem if you have one service or group to audit. In our case, we have more than 10 services in our compliance program and we want to have each service team submit their own quarterly validation of compliance.

Currently, we would have to duplicate the control once for each service and add the 4 audits per year per control. The control doesn’t change and duplicating creates a management nightmare.

It would be ideal if we could create one control then assign an audit set to one a business unit (AKA services), create multiple sets per control and track the compliance that way.

Thoughts?

Thanks

#2

Personally, I think that sounds far more complicated than adding distinct controls for each business unit and dealing with the duplication/overlap. I get a lot of value out of having the controls setup individually, even when there is overlap. For example, I can run reports for controls owned by particular people and meet with them to go over the audit plan for the coming quarter or year.

Also, with the 1:1 relationship between control and audit, I have one throat to choke when it comes to a control that’s failed. Under your proposed plan, this gets muddy (not impossible, but more complicated).

Lastly, I think the method you outlined could cause problems with compliance management. Specifically, what if one team is auditing AD for a domain/forest/environment that has nothing to do with PCI? Their audit would be tied to the parent control, which is assigned to PCI. If it fails, the compliance status could report a failure, even though the specific environment is not related.

I always create controls like “Password Policy - AD” or “Password Policy - Linux”. If I have multiple environments, I use something like “Password Policy - AD (Dev)”. It’s always worked well for me.

GRC is certainly an area where different approaches work in different environments. But, I don’t think I would adopt the approach you laid out. Your mileage may vary.

#3

I agree on @kyle.gililland on this. We have a few different IT departments where some controls are aligned (shared services) and some needs validations per department, country etc. I have developed a name-syntax for all controls so that it is easy to identify the scope of the control based on the control name.

We are using the powerful API to develop reports that can look at the situation at a lot of different angels and very “at a glance” see what departments are missing what controls.