Internal Controls

Introduction

Internal Controls can be created one by one using the Web-Interface (Actions / Add) or multiple Internal Controls can be imported in one action using CSV Imports or REST APIs.

In this episode, we will review how Internal Controls are created using the web interface and what fields on the form are particularly important based on the outcome of your identification process explained in the previous episode. 

Identification Process

Based on the maturity of your control you will document it in more or less detail, there are basically three options:

We strongly advise you that when creating anything in eramba you always reflect the reality of your organisation and nothing else. If the control is not done, then do not create one. If your policies do not reflect the control, do not create them. If your control is not yet mature, do not try creating audits for it.

Title and Objective

Always use a simple yet clear title, for example, if you are creating a control about Laptop Encryption, simply call it: "Laptop Encryption". The objective field is important, is the one-liner that explains to someone what the control does (not for what reason, that is implicit in eramba as it will be linked to problems).

Owners

When creating a control you must always talk to the owner of the control, to the team that operates the control. For example, if the control is about laptop encryption and in your organisation that is done by the Service Desk team, then talk to them to clarify the problems driving the need for the solution, the documentation required, testing, etc.

There are two mandatory and key roles:

• GRC Owner: this is the GRC team, the team has an interest in this control to exist.
• Control Operator Contact: this is the team that operates this control every day. In our example, this would be "Service Deks"

It is very important that you take a systematic approach to these roles.  When you configure notifications for owners and collaborators this will ensure that the right people receive them. We also typically advise using groups (as opposed to users, as shown in the screenshot above). As Groups can contain more than one user this ensures more chances of getting feedback.

Policies

As explained, this is already a different maturity level which you will ideally reach at some point. Do not link policies unless they reflect the truth of how things are done. You will need to create the policy in the Policy module and then link it to the control.

As explained in the Identification episode, if you do not have a document that reflects how the control is done is better to use a Project to describe what is missing. That project can be linked to the Internal Control or to the problem, is up to you.

Audit Tab

This is the highest level of maturity when it comes to document controls, we do not recommend doing this unless the previous levels are met.

If you need to audit the control that you are creating, you need to describe which days of any given year the audit should take place, what evidence you will need, etc.

The audit tab requires the following:

• Dates on which the testing should be carried out each year. Remember these are calendar year dates, this means whatever date you put there means that every year on that date eramba expects the Internal Control to be tested.
• Test methodology to be followed. This typically details the evidence required and how it will be analysed.
• The Success Criteria is where you define what analysis results are required for a pass or a fail.
• The Auditor: this will be typically the GRC team that has an interest in collecting the evidence and testing it
• Evidence Owner: this is whoever has to provide the Auditor with evidence, for example, the head of the department being audited.

When you create notifications, the fields mentioned above can be included in your notification body and subject to personalise the message so people will know what is required from the content of the email.

There is sometimes confusion about the dates. The dates you provide relate to a calendar year. If your last audit date is 8th November and you try adding another date a quarter later it will not work because that would be outside the current calendar year.

If you see a warning as shown in the screenshot above this is because the chosen date would be beyond the end of the calendar year.

The example below shows a typical audit control that should be carried once per year in September:

After saving your controls, audit records will be automatically created for you for the current calendar year and the next calendar year based on the dates you provided.

Note: if you edit the control settings by adding new dates or different dates, eramba will create new audit records for these dates. Existing records won't be deleted. If you delete audit dates from your control settings, eramba won't remove audit records previously created for these dates. If you change the audit methodology, success criteria, or any of the two roles, eramba will update all existing audit records that have future dates that have not been marked as completed.

Maintenance Tab

Maintenance tab entries work almost the same way as audits but they lack the following:

• Evidence Owner Role
• Success Criteria

The reason for this is because there is no pass or fail. The maintenance simply indicates a list of tasks that must be performed by the maintenance owner.