Internal Controls

Introduction

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

• Identify your Internal Controls without the need for GRC templates
• Identify their attributes (owner, documents, problems they deal with, testing, etc)
• Optionally identify Documents and Projects

Control reflects how things are done across the organisation, no single person can know how an entire company does things and 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 information you will collect using this method is the one eramba needs to create an Internal Control.

The method described here is one of many other methods, 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.

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.

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
• The Internal Control works, perhaps not perfectly well, but it does work and is auditable

When we identify controls that will be documented in eramba, we need information for all these three aspects of the Control.

Maturity

If your organisation does not have an inventory of Internal Control or it has never done systematic Auditing against controls (even if they were not identified as eramba would) we strongly advise you to focus on the basic attributes of an Internal Control: Name, Description and Owner.

The idea is that you quickly build an inventory of Internal Controls and documents and set the accountability with the correct teams. You could also focus on documentation (related Policies) of the Internal Control, ideal it should not be a blocker to creating a control if is not available (as as long the control is operated more or less systematically).

After you have identified all your controls for all your problems you can then move to a second phase where for every control you will define their testing methodology by editing the control and completing fields as needed (frequency, method, etc)

To summarise, there are in our view three identification maturity options, we strongly advice you to start on Level 1 (an option in 2) and not to move to level 3 unless you have identified all your Internal Controls for all your problems or you have extreme confidence on the GRC maturity of your organisation.

 

Identification

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

We will explain in more detail the process shown in the diagram above:

• You always start with a problem (1)
  • By far the most common mistake is not starting by reading a problem and identifying solutions in the organisation. If you do it the other way around it will be very hard to leverage controls.
  • Problems can be: Risks, Compliance Requirements or Data Flows
  • We strongly recommend reading one problem at a time, no matter how tempted you are to group common problems into one bag.
  • The solution to this problem MUST require an activity, if the problem requires a document then you do not need an Internal Control
• Identify activities (or lack of) in your organisation (2)
  • You must identify an activity which is currently being executed in your company to deal with this problem. The activity MUST be currently being performed in the organisation.
  • Sometimes you will identify more than one control (review Typical Questions episode) based on the Broad/Specific attributes and Owners.
  • If there is no activity (2a) being performed, then you do not have an internal control. You can use projects instead.
• The activity needs an owner (3)
  • Whoever is doing that activity must be identified, typically this is a Team (IT, Finance, etc.)
  • You must explain to the owner of that activity, what problem you believe they address. You must validate these with them.
  • If there is no owner for that activity, then is very unlikely you have Internal Control and therefore is best to create a project to deal with this later on (2a).

Here starts a process where three key questions must be answered by the owner (not you) of that Internal Control. This information will be used in eramba:

• 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". To be fair, some activities are so obvious they might not have an associated control.
• OPTIONAL AND ONLY RECOMMENDED FOR ORGANISATION WITH GRC MATURITY - Using your professional judgment, the owner and you determine how this control should be tested and how often. You should not do this unless you really know what you are doing, is far more important to identify all your Internal Controls before getting into the audit topic.
• You and the owner must work out the leverage of this control. Can it be used for more problems as it is? if slightly changed (the way the control is done or the way is tested), could it address more problems? This is very important to avoid creating more solutions than needed and therefore keeping a high leverage ratio.

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 must be linked to the problem you analysed.

Outcome

In the end, if you systematically read a problem and identify solutions you will end up with:

• For every problem you will have a solution (Internal Control) and who owns the solution. Depending on your maturity you will also have a testing plan for them.
• For every Internal Control, their associated documents
• Where solutions did not exist, a list of projects

As important as the list above, you will also have now a link between problems and solutions. Even more important, it will reflect the reality of your organisation in detail and everyone involved will know what part they play in this GRC game.

This is the input you need in eramba.