Internal Controls

Introduction

In this episode, we share with you a method that will help you:

• Identify your Internal Controls
• Define how mature they are and what will be documented in eramba

Control reflects how things are done in the company, no single person can know how that is done. For that reason when identifying controls in eramba is essential to interview different departments to understand from them, the experts, how things are done and how they could be realistically tested.

The method described here is one of many, you can use any method you want to identify and document controls in eramba. Make sure you have completed and understood all previous episodes before doing this one.

Requirements

Internal Controls should only be documented in eramba if three conditions are true:

• You have a problem (Risk, Compliance Requirement or Data Flow) for which an Internal Control exists in your organisation
• A team systematically operates the Internal Control, someone owns responsibility for operating this control.
• The Internal Control works systematically, perhaps not perfectly well, but it does work and is in use in the organisation.

The key to identifying Internal Controls is to start with a Problem. By all means, avoid creating Internal Controls in eramba just because you know these controls exist in your organisation.

Identification

The process we use to identify Internal Control in eramba is shown in the diagram below:

• You always start with a problem:
  • A Risk, Compliance Requirement or a Data Flow
  • The solution to this problem MUST require an activity. Sometimes problems are solved with just a document. For example, if the problem is a compliance requirement that requires you to have "A network diagram", then the solution to this problem is a Document, not an Internal Control.
• You need an activity:
  • You must identify an activity which is currently being executed in your company to deal with this problem
  • The activity must not be a project, an activity is something that is systematically done all the time, for example, encrypting laptops or firewall reviews, account provisioning, Etc.
  • If there is no activity currently being done in the organisation that addresses this problem, then is best to create a Project and link that project to the problem. This indicates that today nothing is done in regards to this problem.
• The activity needs an owner:
  • Whoever is doing that activity must be identified, typically this is a Team (IT, Finance, etc.)
  • You must explain to the owner what problem is being addressed by the activity they perform
  • If there is no owner for that activity this is a sign of a lack of maturity and is best to create a project

Here starts a process where three key questions must be answered by the owner (not you) to document this internal control. The maturity of the control is oftentimes related to the feedback you get at this stage, these questions must be answered by the owner of the activity:

• The owner needs to describe what the activity is all about, this will be used in eramba to briefly describe the objective of this internal control. For example: "We encrypt laptops to protect information"
• The owner needs to provide you with a written document that explains how this activity is done. For example: "End Point Encryption Procedure".
• The owner needs to tell you if this activity has been audited in the past or if it has never been tested then what evidence can be provided in case you decide to test it later.

At the end of the process, you end up with two scenarios:

• You have identified an Internal Control and possibly a document that will be stored in the Policy module
• You do not have Internal Control and you end up with a Project

Whatever items in eramba are created in those scenarios they will be linked to the problem you analysed. 

Attributes

If the process above ends in the scenario where an Internal Control has been identified, you now need to decide in how much detail you will document it. The diagram shown below provides a framework that will help you make decisions quickly.

• Since you identified a Problem, an Owner and an Activity that more or less is executed in a systematic way you can create an Internal Control in eramba.
• If the Internal Control owner provided a document (policy, standard, procedure, etc) that reflects how that Internal Control is operated, we recommend creating it on the Policy module and linking it to the Internal Control. If there is no document, then is best to create a Project (that describes a document that must be created by the owner) linked to the Internal Control.

• You need to decide if you want to test this control every year based on:
  • The severity problem that solves
  • The assurance that you are required by your managers
  • Your budget
• Do not set audits unless there is a document that describes the activity. Is very difficult to tell if something is working ok or not without a reference.

Summary

If your Internal Control has a supporting document you will end up with an internal control linked to your problem (one or more). The Internal Control will have (one or more) documents linked to the Internal Control. The internal control may or not have audits associated.

If your Internal Control does not have any supporting documentation or there is documentation but is not reflecting the reality you will need a project linked to the Internal Control. The Internal Control will be linked to your problem.

Note: some people prefer to link the Project to the problem instead of to the Internal Control. This is also a valid option. That option is shown in the diagram below:

If you have a problem that requires Internal Control and your organisation has no such thing then you need a Project linked to the Problem that indicates that today your organisation does not have anything but in the future, if the project is completed, there will be a solution.

In the next episode, we will explain to you how to create this control, the important thing for now is that you have all you need in order to do that! The identification phase is over!