Course Introduction

This course explains the theory behind Internal Controls 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. You will need to complete those other guides to get a better overview of how they work.

At the end, we explain how this module is implemented. Please remember: this module is not a "Use Case" but a "Supporting Module," meaning that on its own, it does not add value to eramba.

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

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

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

Common Features

As with any other module in eramba, the Internal Control module has access to common features. You should implement pretty much all of them to ensure your governance is robust and automated.

Keep in mind these common features must be implemented on each sub-module as well—for example, Audits, Maintenances, and Issues.

While the "How to implement" these common features is explained in each of their specific guides, "How they affect the module" will be briefly explained in this guide.

Customisation

There are many ways in which you can customize the module; remember, these customizations can be tied to dynamic statuses and notifications to make them even more useful.

Make sure you review the documentation on how customizations are used and how—by combining them with notifications, reports, and dynamic status—you can get even more powerful implementations.

Examples of common Customisations:

• Internal Controls

  • Maturity (Implemented, Tested, Etc)

• Internal Controls / Audits

  • Audit Duration (Short, Long, Etc)

  • Evidence Quality

• Internal Controls / Maintenances

  • Maintenance Duration

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.

eramba ships with multiple pre-defined statuses, but commonly many more are created to trigger actions (often in conjunction with custom fields defined by you). For example:

• Internal Controls

  • Maturity (Implemented, Tested, Etc)

  • Automated vs Manual Testing

  • Internal Controls without Policies

  • Internal Controls without Audit Plans

• Internal Controls / Audits

  • Audit Duration (Short, Long, Etc)

  • Evidence Quality

• Internal Controls / Maintenances

  • Maintenance Duration

Notifications

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

These modules come with pre-built typical notifications, but the extent to which you can create notifications is really only limited by your imagination when combining them with the Dynamic Status common feature and Custom Fields. We strongly advise you to understand how these features work in combination.

Typical Warning notifications:

• Internal Controls / Audits

  • Audit Deadline in 1, 10, etc Days

  • Audit Pass/Failed

  • Audit Expired

• Internal Controls / Maintenances

  • Maintenance Expired

  • Maintenance Completed

Typical Report Notifications:

• Internal Controls

  • Controls with Expired/Failed Audits

  • Controls with Expired Maintenances

• Internal Controls / Audits

  • List of Audits to test Next Week

  • List of Failed Audits

  • List of Expired Audits

• Internal Controls / Maintenances

  • List of Maintenances to complete Next Week

  • List of Expired Maintenances

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.

Review the User Interface guide to understand how Views are used

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.

Remember, Internal Controls are solutions to problems. This means they should only be created after you understand one or more specific problems.

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.

Automations (tbd)

tbd

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:

1. 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 a problem. Unless your organization's maturity is very impressive, only create Internal Controls by name and owner; do not get involved with audits yet.

2. Create one dummy Internal Control—complete with Audits and Maintenances—until you are fully familiar with the User Interface.

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

4. Set up default Views on the Internal Control, Audit, Issues and Maintenances for "you" and "everyone else" (User Interface Common Feature documentation)

5. Optionally, create notifications depending on your needs:

   • If you use Audits and/or Maintenances:

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

6. Optionally, create Dynamic Statuses to reflect your own specific metrics

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

8. 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 (tbd)

tbd