Course Introduction

This course explains the theory, implementation and operation of the BU, Assets, Liabilities and Third Party modules 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 these controls do in Eramba and what the key concepts and components are. Then, we describe how these modules works alongside common features, such as notifications, automations, etc. With sufficient background understanding, we will then cover the implementation and operation of these modules.

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 Assets and Third Party 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 these modules are used in eramba:

BU, Process, Assets, Liabilities, Third Parties are used in Risk Management (Asset, Third Party and Business Risk)
Third Parties are used in Online Assessmnets to perform Supplier Assessments
Assets are used for Data Privacy and optionally for Account Reviews

Supported Versions

These modules run on both on-premise and cloud deployments and are available in Enterprise and Community editions. Community limitations relate to common functionalities (notifications, automation, etc).

Templates

We are working on an integrated list of 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

Scope

Before diving into the technical details of how these modules function in eramba, it is important to define what they are intended to store:

Business Units: These are the departments within your organization (e.g., IT, Sales, HR). Processes are optional sub-elements that describe the specific activities these departments perform. A single Business Unit (BU) can oversee one or more Processes.
Assets: these are the physical and digital items the organization owns, such as Laptops or Data. Crucially, every Asset must relate to at least one Business Unit (for example, the "IT" BU would relate to the "Laptop" Asset).

It is vital to remember that eramba is not a CMDB or a granular inventory tool. You do not document every individual laptop or every specific employee; instead, you document Asset Classes, such as "Laptops" or "Employees."

Third Parties: For most organizations, these represent Suppliers. While they can technically include customers or partners, the primary focus is typically on vendor management.
Liabilities: These are the contractual or legal agreements your organization has entered into. They represent the obligations that affect your Assets, Business Units, and Third Parties.

Risk Management

While this is explained in more detail in the Risk Management Use Case guide, the brief explanation is that these modules provide the necessary context for your Risks.

You cannot use any of the three Risk modules without first utilizing these supporting modules. As you can see in the diagram below, Business Units, Assets, Third Parties, and Liabilities act as the foundational data that feeds directly into your Risk assessments.

Online Assessments

When working with the Online Assessment Use Case, you will see that assessments can take different inputs depending on the questions you ask and their specific purpose. While these associations are not mandatory for an Online Assessment (OA), they are often highly desirable for data integrity.

Data Privacy

To create a Data Flow (something essential for Data Privacy), you must have at least one Asset defined. And, as we now know, every Asset requires at least one Business Unit to be associated with it.

Common Features

Customisation

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

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

BU/Process: continuity aspects of the process, revenue of the BU, Etc
Assets: location of the asset, criticality, etc
Third parties: supplier email/website, supplier criticality, cooperation with the assessment, etc.

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:

BU/Process: BU without Risks, Process with high revenue, etc
Assets: Critical Assets, Assets subject to special liabilities, Asset without Risks, etc
Third Parties: Risky suppliers, Etc

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

All these modules support Notifications, as that is a standard common feature across eramba. While the core functionality remains the same, the specific use cases vary slightly between modules, with some offering more triggers than others.

Here are common examples of Warning notifications for these modules. Keep in mind that while some of these are built-in, others are custom triggers you will need to configure using the Dynamic Status and Notification engines.

Assets: Asset has no risk associated, Asset Review is Expire, Asset Review is about to expire
Third Parties: First OA Assigned, New OA Finding, Expired OA Finding, OA Passed/Failed

These are "scheduled" summaries (Report Notifications), typically sent weekly or monthly, based on your filtered Views.

Assets: List of assets with no risks (The "Clean-up" report), List of assets with expired reviews, List of assets with reviews due next week.
Third Parties: List of third parties without Online Assessments, List of third parties without associated Risks, List of third parties with Failed Online Assessments.

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.

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.

REST APIs are enabled on all modules, with the exception of Liabilities.

Automation

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

Reporting

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

Implementation

These modules should not be implemented on its own; they are 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, Online Assessments, or Data Privacy.

To ensure a smooth rollout, we recommend the following sequence for any of these modules:

The "Sandbox" Control: Create one dummy item (Asset, Bu, Etc) until you are fully familiar with the User Interface and the form fields.
Customize Fields: Add any custom field needed for your specific reporting.
Enable Notifications: Enable template notifications or create new ones.
Adjust Views: Set up your filters so you can see exactly what needs your attention at a glance.

Operation

The key operational tasks is the review of Assets