Internal Controls

Internal Controls in eramba 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 performing an action, an Internal Control.

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.

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

• Create an item in the Policy module called "Firewall Change Process" 
• 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.

The Internal Control and the Process mentioned above describe how your organisation does those things. Only you know that answer, no template can guess it. Internal Controls describe how you do things and allow you to audit these controls to gather sufficient evidence that will convince people around you that you are not lying. In the end, we need to reflect the reality of things.

Now you might have data moving through your networks described in the "Data Privacy" module as a "Flow". When creating any data "Flow", you will be asked by eramba, how do you protect data? In this example, you might as well re-use the Internal Control and Process mentioned above. Controls and Policies will be re-used across your Risks, Compliance Requirements and Data flows many times.

Internal Controls are the activities your organisation does systematically to address problems: Risks, Compliance Requirements and Data Flows. There are no templates for these things because we all do things differently. A few more examples can be found in the screenshot below:

Some people mix up Compliance Requirements with Internal Controls. Compliance requirement (PCI, ISO, etc.) tells us all what they expect to see. How we achieve that goal is our business. Your company and eramba might meet the ISO 27001 standard but how you do it and how we do it will be different. Companies do things differently and still achieve the same objectives.

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, Internal Controls require governance in the form of a Standard, Procedure, Policy, Etc. In eramba, you will be able to associate these two modules.

As shown in the screenshot below eramba has built-in charts that will show the relationships between internal actions and documents.

Internal Controls are carried out right across the company by different teams:

• HR checks if employees have contracts,
• Software teams check if the 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 organisation and for that reason, you need to know who runs them. In eramba, each Internal Control will have two roles:

• GRC Contact: the person who understands the problem (risk, compliance requirement, etc.) and has an interest in the control to be documented.
• Control Operator Contact: the person that operates the control (e.g., creates firewall rules).

Remember that with our customisation feature, you can rename these titles to whatever works for you.

In eramba, accountability is very clear, everything needs an owner and everything needs a driving "Problem". You should have no problems to explain to people why Internal Controls are needed. As shown in the screenshot below any control basic report will show these associations.

 

 

Like any other solution in eramba, Internal Controls will be leveraged across your problems, typically 5–15. For example in the screenshot above we see the Internal Control "AD Group Reviews" is used across many compliance requirements. As you mature your eramba implementation that leverage will increase and therefore you will need fewer "solutions" to deal with more "problems".

The pie chart below shows the same across different solutions. eramba has more than 200 charts in total across the system.
 

Since Internal Controls are critical and run across the entire organisation, eramba uses three different ways to keep them working:

• Audits: you will define a yearly calendar of audits and eramba will create the records and use notifications to remind you, record evidence, etc.
• Maintenance: they 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 at 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 in 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 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.

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 in any given year on which you want to perform maintenance.
• How it will be performed.
• The person that 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 and 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 have discussed creating and reviewing audits and maintenance in the register, but there is a lot more to it.

You will use notifications to automatically 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 maintenance activities have expired, what audits and maintenance activities are due in the next couple of weeks, the top-10 controls, new controls, and so on. There are literally 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. 

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 eramba.

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 eramba 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, maintenance activities 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 to meet most company's expected use. The good news is that eramba ships with the option of using custom fields in every module so you can add, hide, rename and move around fields on the form to meet the operational requirements of your company's processes.

 

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 calls based on your endpoint URL, headers, payload, etc. As well as outgoing API calls eramba can also receive REST API 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.