I am evaluating Eramba and read through most of the documentation, but I am struggling to get my head around Compliance Analysis Findings vs Control Issues.
I understand that a Compliance Package (ISO 9001) contains Compliance Package Items (5.2.2 Communicate Quality Policy) and an Internal Controls (Email everybody the policy) links back to the Compliance Item to demonstrate the compliance of the control. That all makes sense.
If, during an internal audit of ISO 9001, we identify that 5.2.2 was not met, presumably from a failing of the Internal Control, would I create a Compliance Analysis Finding against the Compliance Package Item, or a Control Issue against the Internal Control?
A control issue seems to play nicer with the Dashboard widgets (i.e shows that Compliance 9001 has a control issue), whereas a Compliance Analysis finding does not, but it makes more sense per the documentation.
Control Issues - Things that you know are wrong and want to fix with your controls (you have an issue with a “solution”, not necessarily in the context of a “problem”).
Compliance Analysis Findings - Things your auditors/examiners think you’re doing wrong (they have an issue with the solution(s) applied to their problem). I believe the intent with this one is not to have it front and center as part of your GRC program - for example, you could disagree with the auditor, or the finding could be something that was formerly a Control Issue that has already been corrected (thus, why would you continue to report on it?).
There’s certainly cases where it may seem like you should have the same “thing” logged in two places - i.e. you don’t encrypt X is a control issue with your encryption control, but the auditor also said that. In that case, you’ve got a choice - do you want to track it twice, or perhaps fall back to only in one place?
End of the day, you’ll want to look at the pros/cons to each approach, pick one and be consistent with your choice.
when you created the internal control, you define your testing dates and methodology. if the testing fails, then the audit is “failed” and therefore the control is “failed”.
that will reflect in your compliance analysis, the item 5.2.2 will show as “Control Failed”.
if you decide to re-test the control, you either wait to the next programmed audit (based on your controls audit testing configuration) OR you create and ad-hoc audit , just for this re-testing you plan on doing. if the testing works … then you set it to “pass” and control will be green.
a control issue is used for a different thing, a control issue is when you know before even testing the control that it will fail because the control is not operative, is not working well. this is why on this occasions (when you have an issue during a testing cycle) you do not even test, you know it will fail.
note: we miss better documentation on issues and maintenances, we created a task for this
ok, this is something else - this you will use after your external (not internal) auditor comes and describes findings. this is why you have deadlines, etc. now some poeple uses this module also for internal auditor findings, and i think that is not an issue and is ok to do. there is a whole module of documentation for this feature.
Thanks for both of your responses. I might be thinking about this wrong, so please feel free to correct me.
Is there not a missing link between a Compliance Finding and a Control Item/ Policy (either existing or to be newly created as a result of the finding)?
If an External Auditor finds a non-compliance with a Compliance Item, something has to be done/ fixed to “resolve” it, and there is nowhere to “link” that action.
Take a really simple example. An External Auditor identifies that Policy X needs a change, which puts you in “breach” of Compliance Item 1.2.3. (perhaps that change is a job title or something simple and that there are still 9 months until the next policy review). You want a record of 1.2.3 being “out of compliance”, which you do with a Compliance Finding - but this is not indicated on the charts. You would also want to indicate that the reason this Compliance Item is failing is that Policy X needs changing - so Policy X is “non-compliant” (or whatever term you want to call it).
With the way I understand Ermaba, I would need to;
Create the Compliance Finding “Auditor found X wrong”
Create an “audit” of the Policy (ad-hoc) and “fail” it. (now the Compliance Package shows as non-compliant)
Create a review of the Policy to change it (fine)
Create an “audit” of the Policy (ad-hoc) and “pass” it (now the compliance Package shows as Compliant)
Close the Compliance Finding
Is this correct (being true to the platform intention)?
grc is a management practice, a bit like sales or marketing. we all do things differently so there is no missing or wrong or right … everyone has a different approach and that is ok. we have no such connection for the time being, custom fields in the future will let you link modules in any way you want but that feature is not implemented yet.
if a compliance item has a problem , you can link a project to that compliance item. the compliance item is link to the finding.