Internal Controls

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). Every time someone moves a finger in your organisation, they are doing something, therefore an Internal Control is likely to exist. The screenshot below displays common examples of internal controls:

The diagram below shows the Internal Control module, which has three sub-modules (Audits, Issues and maintenance) and links directly to Eramba's three sources of problems: Risk, Compliance and Data Privacy. Internal Controls are solutions to Problems.

For example, if PCI requirement 1.1.1 says "A formal process for approving and testing all network connections". How would you explain to people around you how (and if) you meet that requirement? In eramba, you would:

• Interview the department that deals with this topic, and ask them if a solution exists, you would validate if that is the case and then based on their input:
  • Create an item in the Policy module called "Firewall Change Process" that explains how the process (activity) of change management takes place in the company (at least on paper)
  • Create an Internal Control called "Firewall Rule Reviews" that would have two links, one to the Process mentioned before and one to the Compliance Requirement 1.1.1, therefore linking a "Problem" with a "Solution".

Note: Some people mix up Compliance Requirements with Internal Controls. Compliance requirement (PCI, ISO, etc.) tells us all what these standards expect to see. How we achieve that goal is your business. Thousands of companies are ISO 27001 certified, they all do it differently.

Is perfectly normal that the GRC team does not know every activity performed in the company, and for that reason is perfectly normal that once the GRC team has a problem (Risk, Compliance Requirement or Data Flow), it turns around, and asks everyone in the company (or those in the scope of the GRC program) what is being done and by whom. if the GRC team deems that solution as applicable, then the items mentioned above are created and linked.

Another example: if your Network team raises a Risk where firewall changes could be implemented without proper revision and therefore create holes everywhere, you might suggest creating a Risk in eramba (another problem) and re-use the solutions previously creates for the problem PCI 1.1.1:

• The policy "Firewall Change Process"
• The internal control "Firewall Rule Reviews"

There are no "Templates" for Internal Controls, every company has different solutions (just like in life). Problems on the other side, can be the same for everyone: PCI, ISO, SOX, NIST, GDPR, etc apply to everyone with the same requirements/problems.

Is perfectly normal for an Internal Control to be used multiple times across all three problems (and multiple times on each of these problems). A basic report in eramba for Internal Control will quickly highlight that. The chart below shows a control that is used in treating two risks and multiple compliance requirements. The average leverage of a control in the community is between 5 and 15. If you have 1000 problems, you do not need 1000 solutions, most likely you will need 100 or so.

 

Internal Controls are the core of every GRC department because typically they keep problems at bay. Making sure they are owned by teams and they understand why these internal controls are important is essential. In eramba, there is an explicit definition of accountability for every control.

In eramba, every Internal Control can be linked to the policy module. Activities typically need some form of governance (procedure) so they are performed systematically. eramba allows you to make those associations. The screenshot below shows a basic report of a control showing its relationships to documents in the policy module.

Internal Controls must be operated systematically, otherwise, laptops in your organisation would be built in 60 different ways and the whole thing would become unmanageable and untestable. For that reason in eramba you can, for every Internal Control define:

• How you would like to test them (methodology)
• Define the dates (one or more) when you would like to test the control
• Define who provides the evidence and who runs the audit

The screenshot below shows how these settings are configured on an Internal Control:

Based on the configuration, eramba will create audit records and expect you to complete them on time. 

Audit records look in eramba as shown in the screenshot below:

Every audit record will hold the evidence provided as Comments and attachments. This is typically collected through the use of notifications that will be sent automatically to the Auditor Evidence Owner. This person will have to log in to eramba and provide evidence. This provides you with a very clear and systematic approach to control testing.

You know the saying, anyone can plant a tree, not many can keep it alive. Internal Controls require maintenance and in eramba, you can also define how frequently these maintenance tasks should be performed and by whom. Notifications will help you keep track of these events. You will simply document these maintenances as part of your Internal Control definition.

Every maintenance record will hold the evidence provided as Comments and attachments. This is typically collected through the use of notifications that will be sent automatically to the Maintenance Owner.

You can create an almost infinite of notification scenarios (when a control fails an audit when a control mitigates a high risk and the control is missing an audit, etc) - these notifications can trigger emails or REST API calls which can, in turn, initiate automation tasks with other tools.

eramba allows you to create filters against your Internal Control data, this allows you to make pretty much any kind of question:

• what controls do we use in PCI
• what controls do we use to mitigate high risks
• what controls we use in ISO that are missing from the last audit
• Etc

There are a million combinations available for you to set up to match the way your company works. Any filter you create can be exported as a CSV or sent to you as often as you want over email. You won't even have to log in to the system to know what is going on. 

You can also build graphical reports using eramba report builder, simply drag and drop widgets and build your report template.

The outcome will be a graphical report with your desired data. These reports can also be sent over email in PDF format as often as you want so you don't have to log in to the system.

 

You will want to flag items based on some form of status:

• when a control expires,
• when an audit has been closed but is missing evidence,
• when a control failed too many audits, etc.

We use statuses across all modules to highlight these flags and we ship eramba with hundreds of them preconfigured for you, there are hundreds of conditions available to you. When a status triggers (or not) additional notifications and automation can be initiated.

Eramba uses web forms to create items in a module. All modules in eramba ship with a customisation engine that allows you to modify these forms by hiding, removing and adding fields (and tabs).

The Internal Control, like most modules in eramba, can not just initiate REST calls (using notifications) but also receive REST calls from other systems. A build-in Swagger interface is available that allows developers to build integrations.