Course Introduction

This course explains the theory, implementation and operation of the Internal Controls module and how they relate to other modules within eramba. The course is structured in a particular way that will help you take things step by step.

Initially, you need to understand what we mean by Internal Controls in Eramba and what the key concepts and components of this module are. Then, we describe how the Internal Control module works alongside common features, such as notifications, automations, etc. With sufficient background understanding, we will then cover the implementation and operation of the module.

LLMs

Statistically, most people don’t "read" — and certainly don’t fully "understand" — documentation. If you’re planning to take this course be asured you wil get in trouble.

You can use LLMs to clarify doubts from what you "read" to make sure you "understand", you simply need to copy the URL and paste it into your preferred LLM (OpenAI, Gemini, etc.) together with the prompt below:

I’m trying to understand how Internal Controls works and how it’s implemented in Eramba. This is their documentation. If you’re able to review it, can you answer any quick questions I may have? This is the URL: (paste url here)

If you are somewhat dilligent and careful on your questions you wil get a lot of support from your LLM.

Typical Scenarios

This chapter explains ways in which Internal Controls are used in eramba:

Ensure internal control owners take accountability
Testing of internal controls, manually or automatically
Have an overview of which controls missed, passed, or failed testing.
Follow up on maintenance tasks for your internal controls.

Supported Versions

Internal Controls runs on both on-premise and cloud deployments and is available in Enterprise and Community editions. Community limitations relate to common functionalities (notifications, automation, etc).

Templates

We are working on an integrated list of Internal Control templates; please review our Product Roadmap for details and updates. These templates will not work automatically in your organization because, as explained, controls are never exactly the same. However, they will serve as a valuable source of inspiration.

Theory

Definition

Internal Controls are best described as "Activities" your organisation performs, typical examples in the world of Cybersecurity, Finance and Quality are listed in the table below:

CyberSecurity	Finance	Quality
Access Control Reviews	Segregation of Duties (SoD)	Document Version Control
Access Control Reviews	Bank Reconciliations	Calibration Logs
Multi-Factor Authentication (MFA)	Expense Approval Limits	Non-Conformance Reporting (NCR)

We provide examples from different industries because eramba is used in all sorts of industries, not just cyber. The key qualities of Internal Controls are:

They follow a process (written or not) all the time—step one, two, three, etc. You encrypt laptops the same way every time, right?
They have an owner—a person or a team that performs the activity. Even if the process is done by a Robot, machine or software, that is also owned by someone.
They are not a project; they are something done today—whether good, bad, or "so-so," it is done today.
They cost money and are therefore only implemented to deal with one or more specific problem(s). Statistically in the eramba community, we call this leverage.
If they stop working, the problem becomes a reality and—kapum!
For that reason, Internal Controls are regularly tested to ensure the owner has followed the process and to provide evidence that the problem is under control.
While they seem very common to all organizations, every company performs them in a different way. No two organizations run the same controls exactly the same way; there is no such thing as a "standard template" for a control.

Understanding the bullet points above is absolutely critical to a correct Eramba implementation. Here are a few more points specifically in the context of Cyber:

Policies are not Controls. An "Access Management Policy" or a "Security Policy" is not an Internal Control in Eramba. That is just a piece of paper (or a document).
ISO 27001, SOC2, etc., are not Internal Controls because they do not satisfy the conditions explained above. They are requirements common to the entire planet; every organization deals with them in the manner that fits them best.
There is no such thing as Internal Control templates because no one knows how you perform activities in the organisation.

Problems & Solutions

Internal Controls on their own don't do almost anything in the context of eramba. No-one buys or uses eramba just to keep track of Internal Controls.

Looking at the diagram below, you can think of the gray boxes (and the pinkish one) as modules in Eramba, which are roughly grouped into two categories: Solutions and Problems. The reason most GRC professionals have a job is because there are problems in the organization where they work; in Eramba, those are primarily Risks, Compliance Requirements, and Data moving around.

Solutions is the term we use in eramba to document what is actually being done in the organization today. Eramba requires the reality of the present, not a miracle GRC project that might exist in the future, to address these problems. Here is where Internal Controls play a very important role.

The focus of this module is to explain what Internal Controls are. Similar explanations exist for Policies, Exceptions, and Projects in their respective documentation guides. We strongly advise you to understand these concepts before you implement Eramba.

Examples help to understand things. Imagine the Internal Control: "Quarterly Certified Hard Drive Shredding." This "Solution," which happens to fit the requirements of an "Internal Control" (process, owned, etc) can help deal with the following problems:

Risk: Unauthorized access to data on decommissioned hardware.
Compliance Requirement: ISO 27001 Annex A 8.10 (Information Deletion).
Data: Disposal of End-Point Devices.

Internal Controls have leverage, meaning that typically one of them will deal with multiple problems. The average community leverage is 5–15; this means if you have 1,000 problems (nothing extraordinary nowadays), you do not need 1,000 Internal Controls—you might only need 100. This applies regardless of the organization's size, type, or industry.

The screenshot below is from a basic Internal Control report in eramba that shows how the Internal Control "Change Management Process Review" ties to two Risks.

And then to many compliance requirments (too many to show in a single screenshot)

Internal Controls being activities or process, they often times (not mandatory in eramba) tie to one or more documents in the Policy module (the one on the right) that explain how these controls are supposed to work.

Control Attributes

As already discussed, in its most basic form, an Internal Control is simply the title of the activity, a very brief description (if you wish), the person who performs the control (the owner), and perhaps a policy document that describes how it works.

The GRC Contact will always be you—the GRC team that has an interest in documenting the control. Projects are only needed when your Internal Controls are not working and you wish to associate a Project (see the Projects supporting module documentation) that is correcting them.

As we will see in a minute, Internal Controls can get more complicated with Audits, Maintenances, Issues, and more. It is very, very important that if you have not done this before, you only create controls with these basic attributes (Name, Description and Operator) and nothing more. Once your full catalogue of Internal Controls is created, you can move on to audits and other advanced features.

Audits, Issues and Maintenances

Internal Controls are solutions that require Audits to prove whether they work or not (like an exam: you either pass or fail) and Maintenances to keep them working (like changing the oil in a thermodynamic engine). Sometimes they simply do not work, and you will want to record that failure in a record called Issues.

An Internal Control can have one or more of these records associated with it. You can see these records by clicking on the top tabs, or, if you wish to see the specific items directly, simply use the shortcuts for each control.

In the coming sections, we will explain how each of these three work. You should pay particular attention to Audits, as it is the most commonly used feature.

Learning how the User Interface works is very important, as it can make your life a lot easier when using Eramba. Review the User Interface Common Feature guides for more details.

Audits

The only way to know if your Internal Controls (the activities, remember) work or not is by auditing them (also called testing). There is no way around that. If you don't test, you don't know if the solution works and, therefore, if the problem is really addressed.

When you create an Internal Control, you don't have to define a testing methodology— this is optional. But if you do, you will need to define:

Frequency: How often the test occurs.
Type:
- Manual: You will also need to specify the methodology (the steps to follow).
- Automated: You will need to specify the automation to be executed.
Roles: Who is the Auditor and who is the Auditee (regardless of the type).

If your organization has not consistently put in place an audit program, it is very wise advice to first document your Internal Controls by name and owner first, ensuring accountability is discussed and clear, and then slowly choose which controls to test and which ones not to.

After saving, eramba will automatically create audit records for the current and next calendar year (January–December). For example, if you define testing on May 5th and December 12th, and the day you click "Save" is June 5th, eramba will:

Create one record for the current calendar year: This will be for December 12th. It will not create an audit record for May because that date has already passed.
Create two records for the next calendar year: These will be for May 5th and December 12th.

If you change your mind and edit the Internal Control, you can change any field, and Eramba will adjust the audit records accordingly. If you remove specific audit dates (e.g., May 5th or May 12th), Eramba will delete the records that match those dates—provided they are still marked as incomplete. It will then create any new records based on the scheduling logic mentioned above.

Whatever change is done, eramba will notify you what will happen before you save.

Audit records will be displayed on the Audit tab, you can access the audits of any control by clicking on the shortcut or directly over the Audit tab (in this case you will be listed all audit records for all controls).

Audit records have the following key attributes:

Audit Methodology: This is inherited from what was defined in the Internal Control.
Planned Date: This is the date when the audit is supposed to be conducted.
Automation Script: This depends on the type of audit (if automated).
Start, End Date, and Conclusion: When the audit actually started, when it ended, and what the summary of findings was.
Result: This is the final status—either Pass or Fail.

To complete an audit record, you simply need to edit the audit and fill in these fields. After saving, the record will be closed and will no longer be editable. You should add all of your audit evidence in the form of comments and attachments before finalizing.

If you are using automation, the script will automatically execute at midnight on the day of the planned audit, or you can run it manually at any time by clicking "Run Automation."

We strongly advise you to learn how the Automation common feature works in detail before you attempt any automation. Statistically, as of today, Automation Testing solves approximately 30% of audit needs (even using LLMs to study subjective evidence); therefore, it is important to understand that while it is useful, it is not a "do-it-all" solution.

The Improve button allows you to associate "Projects" and "Security Incidents" with the audit record. This is typically done when an audit Fails.

Maintenances

Maintenances work exactly the same way as Audits. The only difference is in the records stored: instead of an audit methodology and success criteria, you need to provide a description of the maintenance task.

Issues

An Internal Control can have one or more Issues associated with it, which will be displayed on the "Issues" tab. An Issue is a simple record where the Status (Open/Closed) indicates if it is still applicable, and the Start/End dates help you understand for how long the issue was active.

Costs

Manual Testing

This is often the most ignored topic of all. Internal Controls are extremely expensive from a GRC perspective (you can add to that the IT, Etc cost of implementing and operating), and the main reason is their associated testing is audits.

No matter the size or industry of your organisation, you will have anywhere between 50 and 130 internal controls (most companies follow the same processes.
Imagine the following scenario: in average it would take 2 hours to test each control (gather evidence, analyse it, produce a conclusion, etc) and you would test them in average 1.5 times a year (some you will test, some not, some more frequently, etc.). Now do some math - 50–150 controls × 1.5 (frequency) × 2 hours (duration) = somewhere between 150 and 450 hours a year. Do you have that time?

As explained above, you can estimate testing yearly costs. Our suggestion is that you pass this number to your CFO and ask:

“With this money I can guarantee that I will know at all times if we are compliant with this and that, and that we treat risks as expected.”
No money? Then there is no assurance. Let them swallow that pill.

Automated Testing

There are many possibilities when it comes to automations. It essential to understand the automation common feature before making configuration decisions.

Automation helps in some instances, but in average in the community not much more than %30 of the typical Internal Controls can be automated, the reason is automation works very well to test "checklists":

Laptop is enctypted or not
Account should exist based on roster yes or no
Etc

It does not work very well (even if you run an LLM) with anything that requires reasoning, enterprise context, and human interactions:

If diagrams are up to date and reflect reality.
If change management tickets follow the process or not.
If exception approvals were granted correctly or not.
If incident root cause analysis is correctly documented or not.
If your privacy policy is adequate or not.
Etc.

The upfront cost of Automation in these LLM days is negligleble, any LLM can code an automation script in seconds and chances are it will work out of the box no matter to what third party system it requires to connect.

Common Features

Customisation

There are many possibilities when it comes to customisations. It essential to understand the customisation common feature before making configuration decisions.

The most common examples for the Internal Control modules are listed below:

Control Catalogue / Internal Controls: Maturity (Implemented, Tested, Etc)
Control Catalogue / Internal Controls/Audits: Audit Duration (Short, Long, Etc), Evidence Quality, Etc
Control Catalogue / Internal Controls/Maintenance: Maintenance Duration

Dynamic Status

There are many possibilities when it comes to Dynamic Stauses, in particular using them in combination with Custom Fields, Notifications, Reports and Automations. It essential to understand the Dynamic Status common feature before making configuration decisions.

The most common examples for the Internal Control module are listed below:

Control Catalogue / Internal Controls: Maturity (Implemented, Tested, Etc), Automated vs Manual Testing, Internal Controls without Policies, Internal Controls without Audit Plans, Etc
Control Catalogue / Internal Controls / Audits: Audit Duration (Short, Long, Etc), Evidence Quality, Etc
Control Catalogue / Internal Controls / Maintenances: Maintenance Duration

Views

Views are essential as is the main interface with data in eramba, you will most likely adjust them to suit your needs. It essential to understand the User Interface guide before making configuration decisions.

You will create default views for yourself on most modules, typically grouping data using filters, often based on custom fields. Eramba ships with multiple default views on each tab (Audits, Maintenances, Etc) which are not pinned by default.

Notifications

There are many possibilities when it comes to notifications. It essential to understand the notification common feature before making configuration decisions.

It is very common to set up notifications on all these modules because most items have some form of deadline (Audits, Maintenances, and Issues). Additionally, most items have some form of result (Pass, Failed, Completed, Not Completed). Most common notifications are already defined, you just need to adjust (body, subject, recipients) and enable them.

Of course, you will also want to send scheduled reports, such as a "List of controls to be tested next week" or a "List of controls used in NIST which failed the last audit.

Typical Warning notifications:

Control Catalogue / Internal Controls / Audits: Audit Deadline in 1, 10, etc Days, Audit Pass/Failed, Audit Expired, Etc.
Control Catalogue / Internal Controls / Maintenances: Maintenance Expired, Maintenance Completed, Etc.

Typical Report Notifications:

Control Catalogue / Internal Controls: Controls with Expired/Failed Audits, Controls with Expired Maintenances
Control Catalogue / Internal Controls / Audits: List of Audits to test Next Week, List of Failed Audits, List of Expired Audits, Etc
Control Catalogue / Internal Controls / Maintenances: List of Maintenances to complete Next Week, List of Expired Maintenances, Etc

REST APIs

There are many possibilities when it comes to incoming REST Calls. It essential to understand the REST API common feature before making configuration decisions.

REST APIs are enabled by default on the Internal Control and Internal Control / Audit modules, allowing you to receive REST calls from other systems. While this is typically used to update or create Audit records, the possibilities are endless.

Automations

We are working on this part of the documentation

Reporting

See Reporting documentation

Implementation

The Internal Control module should not be implemented on its own; it is a Supporting Module, not a standalone Use Case. You should only use this module as part of the implementation of the core Use Cases: Risk Management, Compliance, or Data Privacy.

Those primary guides are the ones you should follow, as their implementation roadmaps will refer you back to Internal Controls at the appropriate time.

To ensure a smooth rollout, we recommend the following sequence:

Ensure you fully understand the theory of Internal Controls before performing any actions in the software. You cannot create Internal Controls until you have understood and created your "problems".
Eventually you will create Internal Controls, unless your organization's is very used to defining custom internal controls and testing them, only create Internal Controls by name and owner; do not get involved with audits right away.
Create one dummy Internal Control—complete with Audits and Maintenances— and "play" with the module until you are fully familiar with the User Interface.
Using Customisations, add, remove and rename fields, we strongly advice you remove as many fields as possible keeping the form as simple as possible (Customisation Common Feature documentation)
Set up default Views on the Internal Control, Audit, Issues and Maintenances for "you" and "everyone else" (User Interface Common Feature documentation)
Optionally, create notifications depending on your needs:
- If you use Audits and/or Maintenances:
  - Enable Control Catalogue / Internal Controls / Audits / Notifications / Audits -1, -10, -30 Days. Enable as well Comments & Attachments notifications. Also, adjust the Subject and Body of the email to suit your needs. If you don't want anyone but you to receive these notifications adjust the Recipients to the GRC Contact alone.
  - Enable Internal Controls / Maintenances / Notifications / Maintenances - you can do the same as with Audits.
- If you do not need Audits and/or Maintenances:
  - You do not need to enable these notifications.
Optionally (advanced users only), create Dynamic Statuses to reflect your own specific metrics
At this point, you can start creating Internal Controls for every problem identified. Always create Internal Controls without Audits or Maintenances initially; simply include the Name, Operator, and optionally, any related Policies.
Once you create the full catalogue of Internal Controls, you can start considering configuring Audits or Maintenances for specific controls you wish to monitor—either manually or automatically using automations.

Operation

The key operational tasks in the Internal Control module are:

Audits
Maintenances

Remember that missing these deadlines will trigger Dynamic Statuses that will be inherited by any problem (Risk, Compliance Requirement, Data Flow) they are associated with. This is something that, of course, should be avoided.