Internal Controls

Record your Internal Controls and their Audit records

  • Episodes14
  • Duration1h 15m 28s
  • LanguagesEN
Episode 1

Introduction to the Internal Control Module

Quick introduction to the module key capabilities

Internal Controls in eramba are activities that your organization performs to deal with a problem (in eramba, that is Risks, Compliance Requirements, and Data Protection). Every time someone moves a finger, they are performing an action, an Internal Control.
 


Firewalls on their own do nothing. It is not until someone decides that a rule is necessary, the rule is approved, the rule is configured, etc., before the firewall becomes alive. The actions around the firewall are Internal Controls. In eramba, you will document these actions under this module. As a starting point, you will call them by some descriptive name and describe briefly what the action is about.
 


The actions mentioned above (and any Internal Control) require humans to follow procedures and standards. These documents (procedures, standards, etc.) govern how actions are to be carried out. Without governance, everyone would being doing things differently, and nothing would work in a systematic and predictable way. Every Internal Control in eramba is ideally linked to such documents that come from the Policy Module.
 

 

As shown on the screenshot below, eramba has built-in charts that will make these relationships straightforward.
 


Internal Controls are carried out all across the company. HR checks if employees have contracts, Software teams check if code is tested, Legal checks if suppliers have contracts, Finance checks if suppliers are not bogus, etc. Most of the time, Controls are not operated by Security or GRC Teams. They are spread across the organization, and for that reason, you need to know who runs them. In eramba, each Internal Control will have two roles:

  • Owner: the person that knows the problem (risk, compliance requirement, etc.) and has an interest in the control to be documented.
  • Collaborator: the person that operates the control (e.g., creates firewall rules).

Remember that through customisations, you can rename these titles to whatever works for you.
 


These people need to know how to operate the control (document), and they need to know that the activity they perform deals with a GRC problem (i.e., Risks, Compliance Requirements, Data Protection). You should never create a control without talking to these people.

Some people mix up Compliance Requirements with Internal Controls. The compliance requirement (PCI, ISO, etc.) tells you what the goal of the control is. How you achieve that goal, that is your business. Your company and eramba might meet ISO, but how you do it and how we do it will be different. Companies do things differently and still achieve the same objectives.

Like any other solution in eramba, Internal Controls will be leveraged across your problems, typically 5–15. Say you create a control about “Endpoint Encryption.” PCI requires it, ISO requires it, a Data Flow will require it, a Risk will require it.
 


The screenshot above is part of a basic chart that shows Internal Control and how it is used to access many different compliance requirements. The pie chart below shows the same across different solutions.
 

Since Internal Controls are pretty critical and run across the entire organization, eramba uses three different ways to keep them working, check if they are really working as they should, and document any known issue with them. These are:
 

  • Audits: you will define a yearly calendar of audits, eramba will create the records and use notifications to remind you, collect evidence, etc.
  • Maintenances: help you keep controls working by setting up a yearly calendar of maintenance activities (e.g., review the fuel and oil levels of electricity generators every month).
  • Issues: document controls that we know are not working. When the issue began, when it is resolved, who is responsible, etc.


You will notice that each one of them has its own tab on the top of the module. This is because each of them has records that, while always linked to some Internal Control, are kept separately.

 


Testing controls is a good idea when you can afford it (it takes time, and time is money) and or you need to have assurance controls work as expected. Every control you want to test requires the following additional configuration:
 

  • The dates of any given year on which you want to test.
  • How you will perform the test.
  • What the success criteria will be to determine if the test is a pass or a fail.
  • Who the auditor will be.
  • Who will provide evidence (this does not necessarily have to be the Internal Control operator).
     


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

 

In addition to the settings defined above, Audit records will hold the following details:

  • Actual Audit Start Date
  • End Date
  • Result
  • Conclusion

 

 

Every audit record will hold the evidence provided as Comments & 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. Those who are not used to test controls should remember that testing costs money. Assume 100 Internal Controls, tested on average 1.5 times a year with an average testing time of 2 hours., That is 300 hours, or 37 working days of a single person.

Some controls require maintenance in order to operate, like how a car requires an oil change after a certain mileage. Controls that require maintenance need the following configurations:

 

  • The dates of any given year on which you want to perform maintenance.
  • How it will be performed.
  • Who will be responsible for the maintenance.
     

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

 


In addition to the settings defined above, Maintenance records will hold the following details:

  • Actual Audit Start Date
  • End Date
  • Task Result
  • Task Conclusion

 


Every maintenance record will hold the evidence provided as Comments & Attachments. This is typically collected through the use of notifications that will be sent automatically to the Maintenance Owner. This person will have to log in to eramba and provide evidence.
 


When a control is not working and we know this for a fact, we can document it straight away as an issue. Issues are linked to their parent control and hold the following attributes:

  • Start Date
  • End Date
  • Owner
  • Description
  • Status (Open or Closed) 
     


So far, we discussed creating and reviewing audits and maintenance in the register, but there is a lot more to it. You will use notifications to trigger emails or REST APIs to notify when audits and maintenance are due—say, one, five, or 10 days before and after the deadline. 

 

 

You will create filters that let you know what audits and maintenances are expired, what audits and maintenances are due in the next couple of weeks, the top-10 controls, new controls, and so on. There are literally a million combinations available to you. 
 


Any filter you create can be exported as a CSV or sent to you as often as you want over email, so you won't even have to log in to the system to know what is going on. 

Reports are also available as charts. These are shipped with standard reports and let you know visually what is going on. 
 


You can create your own reports with a report builder based on widgets that you drag and drop into a template. You can use text, tables, filters, and charts that we ship with.

 

 

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 your own conditions: 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 with hundreds of them preconfigured for you.
 


But you can also create your own statuses based on your own conditions, and again, you have access to thousands of possibilities with the status configuration tool.
 


 

Every time a status matches (or fails to match) your conditions, a label will be applied to the Internal Control (or its child audits, maintenances, and issues). You can optionally trigger emails and REST APIs, too. For example, you can notify the Control owner and collaborator when the control has failed more than 30% of audits for the current calendar year. The options are endless, and it is really up to you what level of complexity you wish to use.

Eramba uses web forms to create things, and these forms have been preset for you. The good news is that eramba ships with custom fields on every module, so you can add, hide, rename, and move around fields on the form in almost any way you want.

 

 


A user-friendly interface lets you do all of the work without needing to know how to code software.

As explained, REST APIs can be triggered from eramba to other systems using notifications. You set the condition (from a preset notification or status defined by your own logic), and when it matches, eramba will trigger the REST based on your endpoint url, headers, payload, etc. Eramba can also receive REST APIs calls to create, update, delete, or list Internal Controls.
 

 

We use Swagger, so our documentation is automatically created no matter what we change on our software.