Course Introduction

This course explains the theory behind Internal Controls and how they relate to other modules within Eramba.

As a support module, it is not intended for standalone use; rather, it exists to support the delivery of our key GRC use cases (Compliance, Risk, Etc). This course covers how the module is utilized, with a specific focus on Control Testing (both manual and automated).

Additionally, we will explore how to leverage Common Features—such as notifications, automation, reporting, and custom fields—to increase the module's power and efficiency.

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:

Mitigate Risks: Reduces the likelihood or impact of identified threats.
Mitigate Compliance Requirements: Demonstrates adherence to standards such as ISO, PCI, and SOC.
Protect Data: Explains and verifies how data is protected within the organization.
Verify Policy Implementation: Helps determine whether documented Policies are actually implemented and functioning.
Regular Testing: Ensures control effectiveness through both manual and automated testing methods.

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

Scope

Theory Concepts

Get ready: there is a ton of boring, but extremely important, theory ahead.

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 a specific problem.
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.

Problems & Solutions

Yes, more thoery im afraid. Is important you understnad what role Internal Controls have in eramba, the diagram below helps with that.

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.

We focus on this module to explain what Internal Controls are. Similar explanations exist for Security 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.

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.

Core Concepts

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

Auditing is a resource-intensive commitment that many organizations underestimate, as the typical business manages between 50 and 120 Internal Controls. If you test these controls an average of twice per year with each audit taking approximately three hours, you are looking at a total workload of 300 to 720 hours annually; this represents between 37.5 and 90 full working days for a single person. Because of this high cost, it is vital to first document your controls without audit requirements and only commit to a testing schedule once you have defined an annual budget that determines exactly which high-priority controls you can actually afford to verify.

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.

Statuses

As in any other module, Statuses play a key role in understanding if your controls are missing, have failed audits, or have open issues.

Statuses are a common feature that you must understand well to make the most of eramba; please ensure you review the Dynamic Status common feature guide.

In this context, statuses play a critical role primarily when using Audits and Maintenances—without those, they are less relevant.

As part of the Problems & Solutions approach in eramba, these statuses will automatically be displayed on Risks, Compliance, and Data Flows.

This "inheritance" ensures that if a control fails an audit, the risk it is supposed to mitigate or the compliance requirement it fulfills will immediately reflect that failure. It provides a real-time, transparent view of your security posture across the entire platform.

You can customize Statuses to indicate many other common KPIs (Key Performance Indicators), such as:

Duration of Audits: Categorize by how long they take (e.g., Short, Medium, Long).
Automated vs. Manual: Quickly visualize your automation coverage.
Audit Evidence Quality: Rate the maturity of the documentation provided.
Controls without Policies: Identify "orphan" controls that lack a formal governing document.
Controls without Audit Plans: Spot controls that are documented but aren't being tested.

Common Features

Notifications

Enabling "Warning" notifications on the Audit, Maintenace tabs is pretty common since they will allow you to trigger emails to Audit Evidence owners a few days in advanced of the PLanned audits or maintenances.

The email includes a link that takes the user directly to the Audit or Maintenance record. Once there, they can provide the necessary evidence required to conduct the task by adding Comments and Attachments. If you prefer them not to do that, simply edit the email and adjust it with whatever instruction you prefer.

It is very important to review the Notification common functionality in detail before making these adjustments. There are many possibilities available, and it is best to have them clear in your mind before continuing.

Built-in Macros in the notifications allow you to include specific attributes from the audit directly in the email, such as the Evidence Required description. There are many other types of Warning notifications you can customize to keep your team informed, for example:

Audit Completed
Audit Failed / Passed
Maintenance Completed
Audit Expired
Etc.

We also recommend creating Report notifications in conjunction with your Views. Some of these are already predefined under Internal Controls; you simply need to enable them:

List of Controls with expired audits
List of Controls with audits due in the next couple of weeks
Etc.

Customisation

There are many ways in which you can customize the module; most of the time, this revolves around creating custom fields for:

Stating the maturity of the Internal Control.
Stating the duration of each audit or maintenance.
Stating the quality of the evidence provided for each audit or maintenance.
Etc.

It is very important that you understand how the Customizations common functionality works before you attempt using it in eramba. We also strongly recommend setting these adjustments BEFORE you start putting data into the module.

Views

In each of the tabs (Internal Controls, Issues, Audits, etc.), you will most likely define your own Views to simplify access to commonly used information—such as expired, failed, or pending audits.

Customizing these views allows you to filter out the noise and focus specifically on the controls or records that require immediate attention. By saving these views, you can also trigger the Report Notifications we discussed earlier, ensuring that the right data reaches your inbox on a set schedule.

It is very important that you understand how the User Interface common functionality works before you attempt using it in eramba. We also strongly recommend setting these adjustments BEFORE you start putting data into the module.

Create/Import/APIs/Edit/Delete

There are no special remarks in this area; of course, it is fundamental that you understand how the User Interface and APIs common functionality work across the entire system to move around the software without friction.

Familiarizing yourself with the API is particularly useful if you plan to integrate eramba with external tools for automated evidence collection or to sync control statuses with other dashboarding software.

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:

Theory First: Ensure you fully understand the Theory of Internal Controls before performing any actions in the software.
The "Sandbox" Control: Create one dummy Internal Control—complete with Audits and Maintenances—until you are fully familiar with the User Interface.
Customize Fields: Add any custom KPIs or maturity markers needed for your specific reporting.
Enable Notifications: Adjust the email body and triggers based on whether or not you expect to receive feedback from owners.
Adjust Views: Set up your filters so you can see exactly what needs your attention at a glance.
Document the Basics: Create your real Internal Controls using only a Title, Description, Operator/Owner, and (optionally) a Policy. We strongly recommend skipping Audits and Maintenances at this stage unless you are an experienced user.
Strategy Phase: Once all controls are documented, decide which ones you wish to test and choose your methodology (Manual or Automated).
User Access: Create accounts for stakeholders so they can provide evidence or feedback as necessary.