Question - Duplicating Controls for departmental audit/compliance reporting?

If we need to report compliance against a department, for example CCTV, do we need to have multiple controls for CCTV one per department? and as such multiple compliance packages

I can see that I could have multiple audits for each control and assign these audits to each department, but the control status and subsequent mapping to control packages only reflects a single status, the most recent audit.


in eramba compliance packages are used to reflect compliance within a given scope, for example pci-dss. Pci asks for cctv in one or more of their requirements, you can then create one or more controls as needed (many ways on how that can be segregated) to test cctv. if testing goes well, control is green and pci requirement is green.

im not sure what you mean by department?

We have multiple locations, and say HR is in one building and Finance in another, one has very good CCTV, the other doesn’t, how can we report that one is compliant and the other is not?

In my scenario, we have to expand this out for say 50 controls per department, each control has to be audited multiple times for each dept, so is that 50 X number of depts for controls in eramba?

We understand the efforts around the audit cycle doing it this way, just we need it reporting on each departments compliance status.

Another way to look at this, using our real setup, is that we have multiple divisions being audited, and they will have their own control maturity and compliance status

there is something we call broad and specific controls, is documented here: Internal Controls - Google Docs

in eramba we create controls because we have problems (risks or compliance requirements), this controls are implemented to address problems (risk or compliance). you can have one or more controls for the same “topic” depending on how you define them, broad (one cctv for all department) or specific (one cctv per building ,per technology, etc). there are labour / cost consequences in going the “specific” way. you seem to be aware of that.

if you need to report per building … well … you know the cost associated with it, if someone in your business is willing to pay for that very well. if this is too much effort/cost then you need broader controls… is a question of money and how much assurance your business needs around that problem (risk or compliance) and control (solution).

we have 40 offices around the world , some 120k m2 to cover.

  • we choose to use a standard cctv system across all locations to make management and testing a lot simpler. if we would have gone with different suppliers we would end up having more controls in eramba, as each control has a different testing methodology.
  • we use cctv (solution) to deal with the a risk of getting office stuff stolen (risk - problem) and meet comliance requirements (compliance - problem), our business did not want (pay) to have full coverage (120k m2) and therefore accepted the assurance of the control will be lower.

i hope this serves as an example … not trying here to tell how this is supposed to be done of course. anyway, the way users group their controls has nothing to do with eramba…

OK Great, Thanks

Many specific controls it is !!!

Just one more thing, if you want to report if cctv is ok per building you use one control per building. A different thing is to report compliance , remember that if pci in requirement 1.2.3 (i dont know which one is) asks for cctv , you link all your cctv controls to that single requirement.

if one of these controls fails testing , that pci requirement will become red.

just making sure that bit is clear … good luck phillip !

Yep got it. I think I will have multiple compliance packages also, a top level one where I map all the CCTV controls to then one for each department, which only maps there controls, this way I can easily see the status for each department and a rolled up view for the company :slight_smile:

ISO:27001 - Dept A
ISO: 27001 - Dept B
ISO:27001 - Company