Quick Introduction

Course Introduction

This course is a mix of theoretical concepts, implementation, and operational instructions designed to help you understand how Compliance Management is implemented and managed within eramba.

The course follows a logical progression through three main pillars:

Theoretical Concepts: The underlying logic and compliance methodology.
Common Features: Explains how common features (Notifications, Reports, etc.) apply to this use case with multiple examples.
Implementation Steps: The technical implementation of the module step by step.
Operational Steps: The day-to-day activities required to keep Compliance data accurate.

To successfully navigate this course, you will need to reference two additional types of documentation:

Common Features: These are universal functionalities found across almost every eramba module. Examples include Notifications, Reports, Custom Fields, and the API.
Related Modules: These are supporting modules that provide the "solutions" to your Compliance Requirements. To fully implement Compliance Management, you will interact with Policies, Internal Controls, Exceptions, and Projects.

LLMs

Statistically, most people don’t "read" — and certainly don’t fully "understand" — documentation. If you’re planning to take this course be assured you will 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 Compliance Management 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 diligent and careful on your questions you will get a lot of support from your LLM.

You can then ask questions a bit like if you would be asking them on a demo call:

Typical Scenarios

This use case allows you to work with the following common situations:

Handle any type of Compliance requirements - Cybersecurity (ISO 27001, NIST, Etc), Financial (SOX, FCA, SOC1/2-T1/2, Etc), Quality (ISO 9001, Etc), Etc.
Any number of compliance requirements, there is no limit to how many you upload to eramba
Being able to explain to auditors how exactly you are compliant to these requirements (through the use of Internal Controls, Policies, Exceptions and Projects)
Use of reports that clearly demonstrate how compliant you have been over time.
Being able to produce template documentation such as Statements of Applicability (SOA)

Framework Guides

Some people would like to see content from us such as “How to be compliant with SOC 2,” “ISO 27001,” or “SOX.” Or even worse, “How Eramba makes me compliant with PCI, NIST, or whatever.” Unfortunately is not possible.

GRC tools do not make an organisation compliant; the same applies to project management or accounting tools. These tools will not make your project a success or your business financially successful. They facilitate and professionalise the work, helping you achieve higher standards of quality.

GRC relies on many people doing their jobs correctly so that systems work properly and generate value and trust for the company, its shareholders, partners, and customers. People and systems (which rely on people) are the real key. Microsoft Project, SAP, or Eramba simply support the task.

You can review the following articles for popular compliance framrworks, they are brief and useful to understand them:

That is the case of ISO 27001—and 27002—for which we have practical advisory if you need help.
Digital Operational Resilience Act (DORA)
Network & Information System (NIS2 Article 21)

Supported Versions

Compliance Management runs on both on-premise and cloud deployments and is available in Enterprise and Community editions. Community limitations relate to common functionalities (notifications, reporting, etc), not related modules, as most of these features are not included.

Workshops

Every couple of months, Eramba offers free training on this course. Keep an eye on our website for updates. If you are an enterprise customer, you can purchase 8-hour workshops delivered by a GRC professional (no “CSMs” at Eramba) and an Eramba expert to ensure you start on the right foot. Gambling on a poor implementation to save the minimal cost of these workshops is a bad financial decision. Contact support@eramba.org for details.

Theory

Module Relationships

The Compliance Management use case requires the use of multiple “related modules” in eramba.

The Compliance Management / Compliance Packages module serves as the central library for actual compliance requirements (such as NIST, SOC, or SOX). The Compliance analysis module is then used to link these requirements from the library to other modules within the system.
The Compliance Management / Compliance Analysis module is where you will analyse compliance requirements and associate them with “Solutions” (the green modules below). This is also the module from which you will understand how compliant you are and the one used during external audits. This module is the core of everything.
The green modules, Security Policies, Internal Controls, Exception Management and Projects are what we call “Solutions”. These modules will help explain to people how you actually deal with each compliance requirement.

Let’s use an example so you can better understand this process, imagine you need to be compliant with ISO 27002 requirement 8.1 “User Endpoint Management”. A company (we will see the answer is always different later) could associate the following solutions:

The company employs several internal controls to address this problem, specifically: "End-Point Encryption," "Strong Authentication," and "Anti-Malware Software." These measures are documented in the Internal Control module documentation.
Policies: a single document called “Endpoint Security Policy,” where it is described how endpoint devices are managed in the company. This could also include more documents, such as “Endpoint Build Process” or “Endpoint Inventory Process,” etc. We are trying here to provide documents that explain in written form how “these things” are managed. (Policy Module documentation)
Exceptions: These are used when a Compliance requirement is intentionally not treated because the requirement is not applicable to you. For example, if your company for some reason does not use endpoint computers (it would be strange, right?), this would not apply to you. (Exception module documentation)
Projects: These represent future plans, for example “Implement endpoint protection for Linux.” (Project module documentation)

Every “Problem” (compliance requirement) is different and they require one or more or a combination of “Solutions” (the four options mentioned above). Many times these solutions change (your company changes how it operates).

Effective compliance management aims to accurately reflect reality. Therefore, it is crucial to implement genuine, existing "solutions." Populating the system with non-existent items is unproductive, as these entries will be disregarded by auditors and anyone relatively serious.

These solutions will work pretty much (never exactly) the same way for CIS V8 requirements 3.6, 10.1, 10.2 and 10.4. And for NIST CSF PR.DS.01, Etc.

According to statistics gathered from our community, these "Solutions" are frequently utilized across various compliance requirements, typically being used 5 to 15 times on average. If you have 1000 compliance requirements, you will most likely need somewhere around 100 solutions.

While this guide will detail the mechanism of this process later, for now, your primary focus should be understanding the nature of each solution.

Problems & Solutions

The diagram above is part of a larger framework within eramba known as "Problems & Solutions." Importantly, these same solutions are equally applicable to Risks and Data Flows.

The "Compliance" box, located in the bottom middle row, functions in the same way as the "Problems," "Risks," and "Data Privacy" boxes. The solutions mentioned will automatically be linked in eramba to:

Any Risk you create, such as "Laptops can be lost or stolen."
Any Data Flow (within the Privacy module) that describes how Personally Identifiable Information (PII) is stored on laptops.

The solutions developed to address "Compliance" issues will also be beneficial in tackling the other two sources of problems.

It is very important that you have a solid understanding of what we mean by Internal Controls and Policies at this stage, ideally also about Projects and Exceptions, although these last two are less urgent.

Status

There are multiple operational tasks regarding compliance management in eramba. These are all aimed at keeping data updated and accurate and, most importantly, ensuring everyone is on board.

The idea is that you can demonstrate compliance throughout the year. For this, the “Solutions” (in particular Internal Controls) will be audited. Policies will be reviewed. Exceptions will be reviewed. Projects will be followed up.

If an associated internal control fails a test, all Compliance Requirements linked to that internal control will inherit the issue, regardless of when it occurs. This allows you to see clearly from the "Problem" perspective (the compliance requirement) whether the treatment is actually effective. The same logic applies to policy reviews, exception reviews, and project deadlines.

Statuses is what helps you answer the question, "Are we compliant with ISO or SOC or whatever?" - the way Statuses can tell you that is based on how often and the result of these operational tasks (audits, reviews, etc).

Compliance Packages

We call “Compliance Packages” things that were written by someone that your company must comply with for one reason or another. Typical examples:

ISO 27001, PCI-DSS, SOC, etc.
Some framework invented by a customer of your organisation that you must comply with in order to work with them.
Some local or global regulation.
Contractual obligations, which many times include clauses such as “you must be compliant, otherwise…”.

Because all these things come in different forms, shapes, languages, etc in eramba we have an open ofrmat to sotre them, a plain CSV file with a specfic format (explained below under "Custom" packages.

Under Compliance Management / Compliance Packages, you will be able to import CSV files that include the frameworks you want to work with.

While you can import multiple frameworks, we strongly advise you to start with one. After you complete the analysis phase for that one, then upload the second.

After uploading a package, you will see that there will be multiple “Compliance Package Items.” These are the actual requirements inside the “Package.” You can edit these “Items” from the web interface under the “Compliance Package Item” tab at the top.

Please note that the "Compliance Mappings" feature is being deprecated, please do not use it.

Templates

The following table includes the full list of Packages ready to download and import as CSV files into Eramba. This list is updated regularly, and we accept community collaborations. Please submit them to support@eramba.org for our review.

Package	Publisher	Version	Notes
Secure Control Framework	SCF	2025.3	https://www.securecontrolsframework.com/ Thanks to Tamás Földesi
Secure Control Framework	SCF	2022.2	https://www.securecontrolsframework.com/ Thanks to Derek Price
PCI-DSS V3.1	PCI Council	3.1	https://www.pcisecuritystandards.org/
PCI-DSS V3.2	PCI Council	3.2	https://www.pcisecuritystandards.org/
PCI-DSS V3.2.1	PCI Council	3.2.1	https://www.pcisecuritystandards.org/
PCI-DSS V4	PCI Council	4	https://www.pcisecuritystandards.org/
PCI DSS V4.0.1	PCI Council	4.0.1	https://www.pcisecuritystandards.org/
PCI-Card Production-Logical Security Requirements V2	PCI Council	2	https://www.pcisecuritystandards.org/
PCI-Card Production-Physical Security Requirements V2	PCI Council	2	https://www.pcisecuritystandards.org/
CYBERSECURITY REQUIREMENTS FOR FINANCIAL SERVICES COMPANIES (NEW YORK STATE 500 of Title 23)		March 1st, 2017 - 500 of Title 23	See the official law codification
Massachusetts General Law Chapter 93H		201 CMR 17.00	https://malegislature.gov/laws/generallaws/parti/titlexv/chapter93h
ISO 22301	ISO	2019	You need to provide evidence you purchased the standard to get a copy.
ISO 9001	ISO	2015	You need to provide evidence you purchased the standard to get a copy.
ISO 14001	ISO	2015	You need to provide evidence you purchased the standard to get a copy.
ISO 27001	ISO	2013	You need to provide evidence you purchased the standard to get a copy.
ISO 27001	ISO	2022	You need to provide evidence you purchased the standard to get a copy.
ISO 27002	ISO	2013	You need to provide evidence you purchased the standard to get a copy.
ISO 27002	ISO	2022	You need to provide evidence you purchased the standard to get a copy.
ISO 27701	ISO	2019	You need to provide evidence you purchased the standard to get a copy.
ISO 37001	ISO	2025	You need to provide evidence you purchased the standard to get a copy.
ISO 42001	ISO	2023	You need to provide evidence you purchased the standard to get a copy.
ISO 45001	ISO	2018	You need to provide evidence you purchased the standard to get a copy.
CIS Controls	CIS	8.1	https://www.cisecurity.org/controls/
CIS Controls	CIS	8	https://www.cisecurity.org/controls/
CIS Controls	CIS	7.1	https://www.cisecurity.org/controls/
SANS – Critical Security Controls Top 20	SANS	3
NIST 800-171	NIST	2.0	NIST https://csrc.nist.gov/publications/detail/sp/800-171/rev-2/final
NIST SP 800-171 r3	NIST	3.0	NIST https://csrc.nist.gov/pubs/sp/800/171/r3/final
NIST 800-172	NIST	2021	https://csrc.nist.gov/publications/detail/sp/800-172/final Thanks to Derek Price
NIST 800-53 v4	NIST	Revision 4	https://nvd.nist.gov/800-53
NIST 800-53 v5	NIST	Revision 5	https://nvd.nist.gov/800-53
NIST CyberSecurity Framework v1	NIST	1.0	https://www.nist.gov/cyberframework
NIST CyberSecurity Framework v1.1	NIST	1.1	https://www.nist.gov/cyberframework
NIST CyberSecurity Framework v2	NIST	2	https://www.nist.gov/cyberframework
NIST Privacy Framework	NIST	1.0	https://www.nist.gov/privacy-framework
NIST AI Risk Management Framework	NIST	1.0	https://www.nist.gov/itl/ai-risk-management-framework
HIPAA Security Rule		Jan 2013	https://www.hhs.gov/hipaa/for-professionals/security/index.html
HITRUST v8		8	https://hitrustalliance.net/
HITRUST CSF v9.3.1		9.3.1	https://hitrustalliance.net/
Cloud Security Alliance	CSA	3.0.1	https://cloudsecurityalliance.org/research/working-groups/cloud-controls-matrix/
CSA CAIQ-Lite			https://cloudsecurityalliance.org/blog/2019/03/01/introducing-caiq-lite/ Thanks to Mick Otoole
SOC2 Report (Confidentiality, Security and Availability Principles)		2022
SWIFT CSP v1.0		1.0	https://www.swift.com/myswift/customer-security-programme-csp
SWIFT CSF		2024	Thanks to Sonia Azeem
Cyber Essentials - UK - Willow Version		v3.2 (Willow)	https://www.cyberessentials.ncsc.gov.uk/ Thanks to Felipe Bueno
Cyber Essentials - UK			https://www.cyberessentials.ncsc.gov.uk/
Cyber Essentials v14			https://www.cyberessentials.ncsc.gov.uk/
GDPR (2016/679)			European Union
Australian NSW Cyber Security Framework			Thanks to Roshan Fernandes
Australian NSW Cyber Security Policy V6.0		2023-2024	Thanks to Roshan Fernandes
Australian Government ISM			Thanks to Roshan Fernandes
Australian Signals Directorate Essential Eight	Australian Signals Directorate	2023 v1	Thanks to Hamid Osmani
Cybersecurity Maturity Model Certification		1.0	Office of the Under Secretary of Defence for Acquisition & Sustainment
Publicly Available Specification 1296: 2018		2018	You need to provide evidence you purchased the standard to get a copy. Thanks to David Davis
Proof of Age Standards Scheme: Requirements for Identity and Age Verification - PASS-1: 2020		2020	Thanks to David Davis
TDIF - Trusted Digital Identity - 04 - Functional Requirements		v1.3	Thanks to David Davis
NCSC Cyber Assessment Framework		v3.1	Ref: https://www.ncsc.gov.uk/collection/caf , Ref: https://discussions.eramba.org/t/compliance-ncsc-cyber-assessment-framework-v3-1/2115
Qatar 2022 Cyber Security Framework		2022	https://www.qatar2022.qa/sites/default/files/Qatar2022Framework.pdf
CMMC v2.0		v2.0	https://www.cmmc-compliance.com/ Thanks to Derek Price
FedRAMP Rev. 4		4	https://www.fedramp.gov/ Thanks to Derek Price
AESCSF-SP1			https://aemo.com.au Thanks to Bret Watson
AESCSF-SP2			https://aemo.com.au Thanks to Bret Watson
AESCSF-SP3			https://aemo.com.au Thanks to Bret Watson
Saudi Arabian Monetary Authority - BCM		v1	https://www.sama.gov.sa/
Saudi Arabian Monetary Authority - CTI		v1	https://www.sama.gov.sa/
Saudi Arabian Monetary Authority - CSF		v1	https://www.sama.gov.sa/
EU Digital Operational Resilience Act (DORA)	European Union		https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en Thanks to Mark Fuchten
UK Government - National Security Cyber Centre (NCSC)			Thanks to Martin Freeman
Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM)		v4.0.6	Thanks to Martin Freeman
Prudential Standard CPS 230 Operational Risk Management		DRAFT	Thanks to Martin Freeman
NIS2 Directive	European Union	2	https://digital-strategy.ec.europa.eu/en/faqs/directive-measures-high-common-level-cybersecurity-across-union-nis2-directive-faqs
NIS2 - Article 21	European Union
TISAX	Trusted Information Security Assessment Exchange	6.0.2	https://portal.enx.com/
PKI Maturity Model	PKI Consortium	v1	https://pkic.org/pkimm/model/
Cloud Computing Compliance Control Catalog (C5)	BSI	C5:2020	Thanks to Tobias Gurtzick
Esquema Nacional de Seguridad (ENS)	CCN		https://gobernanza.ccn-cert.cni.es/ens-navegable Thanks to vidaktobyl

Custom

If you want to upload your own compliance packages, you need to create a CSV file and ensure it is formatted in such a way that Eramba can understand the contents. We organise compliance packages (CSV files) into “chapters” and “items”:

Chapters are made of three fields:

ID
name
description

Items are made of four fields:

ID
name
description
Questions

The following example shows the column entries for PCI-DSS requirement 2:

In the image above, you see the chapter row (composed of three fields) and the item row (composed of four fields). The PCI requirement is translated into a CSV-formatted file with the chapter and item all in one straight row.

To successfully create a CSV file, follow these guidelines:

Make sure there are entries in all 7 columns.
There should be no empty cells. If you do not know what to put, simply write “N/A”.
If you are using Microsoft Excel, you need to save the spreadsheet as “Windows CSV” (not DOS CSV).

Strategy

As you go through the list of Problems (compliance requirements), you will first need to decide whether they are applicable to your organisation or not. This is what we call the “Compliance Strategy”: what do you want to do with this requirement? Sadly, most of the time we just have to be “Compliant,” but sometimes the item may be “Not Applicable” (it does not affect you).

For example, many PCI requirements apply specifically to “Service Providers,” which are complex organisations. If you are not one of those companies, these requirements can be set as “Not Applicable.”

There is a relation (not forced) between the “Strategy” and the solutions involved, as shown in the diagram below:

Compliance Analysis

It is very important that you have a solid understanding of what we mean by Internal Controls and Policies at this stage, ideally also about Projects and Exceptions, although these last two are less urgent.

As explained, the process by which you implement compliance in Eramba is basically:

Understand the problem and what is expected from your organisation (in particular by auditors).
Define whether the problem is applicable to you or not (Compliance Strategy).
Identify owners in your organisation that relate to the problem.
Understand whether the problem requires a document or an activity.
Identify whether these things are already done; if not, you will need projects.

If you follow the diagram above, you will end up with something like the screenshot shown below.

The analysis phase and the linking between problems and solutions are done at Compliance Management / Compliance Analysis. A “View” will be automatically created for each “Compliance Package” you create under Compliance Management / Compliance Packages.

Mappings

What if you need to be compliant with multiple compliance packages (SOC 2, ISO 27001, etc.)? The process does not change. After you complete the first package, you repeat the process with the second package.

What will happen is that the “Solutions” you identified for the first package will help you with the second package. For example, “Change Management” is required in all these packages (in some of them not just once, but many times).

Since the task in Eramba is to determine whether “Change Management” is done and whether it meets the “Problem,” once you document it (assuming it exists), you will most likely reuse the same policies and internal controls across other frameworks. The end result looks a bit like the image above.

The requirements of these frameworks are never the same—the idea that frameworks overlap is not real. Read this article to understand why that is the case.

The reality is often times more complicated, because these frameworks as for "change management" but expect different things from it. So the diagram above can also look like the diagram below:

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 Compliance modules (see the Internal Control, Policy, Assets, etc. guides for examples applicable to those modules that are involved with Compliance) are listed below:

Compliance Management / Compliance Analysis: A common custom field typically used as the module is implemented is “Fulfillment,” which aims to explain how well the requirement is addressed based on the “Solutions” available in your organisation.

There is a tendency to focus on custom fields that describe the “maturity” of the mitigation. This is typically not needed in Eramba, as the associated solutions (Internal Controls, Policies, etc.) already have those attributes, and they will be inherited by the Compliance Analysis module. This is explained on these modules guides.

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 Compliance modules (see the Internal Control, Policy, Assets, etc. guides for examples applicable to those modules that are involved with Risks) are listed below:

Compliance Management / Compliance Analysis: A common Dynamic Status is derived from the custom field suggested above. Another very common Dynamic Status is to inherit from the Policy, Internal Controls, etc. modules their maturity (this requires a custom field on those modules and custom Dynamic Statuses) and their status regarding audits and reviews.

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.

System views will be automatically created as soon as you upload a compliance package. You would still need to adjust the columns to your own liking. You typically can also create views that list "Compliance Requirements" for which there are issues (Audit Failed, Expired, etc).

Notifications

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

The most common examples for the Compliance modules (see the Internal Control, Policy, Assets, etc. guides for examples applicable to those modules that are involved with Risks) are listed below:

Compliance Management / Compliance Analysis:
- Report: We typically send a weekly report with the view mentioned in the previous chapter with “Non-Compliant” issues. This can also include an over-time chart showing the trajectory of this report.
- Another typical report is one sent to each “Department” with their associated compliance requirements so they can see how compliant they are.

Automations

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

We are updating the documentation, please be patient!

Reporting

See Reporting documentation

Implementation

Access Management

In order to complete these tasks, you need to understand how Access Management works

It is critical to get this right before implementing the Compliance Management use case, as correcting it later can be complex and time-consuming. The following steps must be completed:

Log in to Eramba for the first time and set the Admin password and email (do not use a personal email address). See our Install Guide (choose the one that applies for you) for details.
Create a group for your GRC department (name it according to your department).
Create user accounts for the GRC team, assign them to the group created in the previous step, and grant Admin privileges. Ensure that no portals are enabled other than Main. Do not create user accounts for anyone outside the implementation team. User accounts for the rest of the organization should be created after the implementation is completed.
Create a dummy user account, assign it to the following groups: View Projects, View Internal Controls, View Compliance Analysis, View Policies, View Exceptions, and enable the Main portal only.
Log out as Admin, from now on always login with your personal account
Create one Group for every Department in the scope of your Risk program
Optional: Set up SAML, Google OAuth, or LDAP connectors and, if desired, update the Authentication settings to use these connectors in order to authenticate user accounts against a remote directory.

Packages

In this phase we will uploading packages:

From the list of frameworks, contracts, laws, etc. that you need to be compliant with, choose the one that matters the most to you.
- You need to validate whether the package already exists as a template (see list above).
- Alternatively, you need to create the package (see instructions above).
Go to Compliance Management / Compliance Packages / Import.
Import the package, make sure you set as "Owner" the GRC group you created on the previous chapter.

Analysis & Solution Creation

In order to complete these tasks, you need to understand the process by which you do Compliance Analysis in eramba

Since you are starting to implement and learn how Eramba works, we recommend that you begin by creating “sample” solutions for a particular compliance requirement. Since we do not know what you are trying to be compliant with in this guide, we cannot provide precise examples, so we recommend creating “sample” items as a first step.

This phase, in particular the identification of Internal Controls, is by far the most complicated for people new to GRC tools. On average, it takes around 7 minutes to identify solutions for each requirement (less if you are experienced). If you find stuck in this phase (in 4 hours you should be able to complete some 30 or so solutions), you can use our template database as inspiration (do not attempt to use them as is) or contact support@eramba.org for consulting assistance. With a couple of hours of work together, you will know how to perform this task on your own. By all means, do not use templates.

Create Sample Solutions (Treatment)

In order to complete these tasks, you need to understand how Internal Controls and Policies work. Optionally, but highly recommended, is that you also understand how Projects and Exceptions work.

Now is time to create "Sample" solutions that we will then link to a single "Compliance Requirement":

Create a Control Catalogue / Policy called "End-Point Security Standards". Make sure the GRC Contact is the “GRC” group created before and the Policy Reviewer is the dummy account created before. Set the “Next Review” date to two days from today. Complete the policy with any details you want; this is just a practice item. Set the portal permissions to “Private.”
Create Control Catalogue / Internal Controls “End-Point Security Controls" and link the Policy “End-Point Security Standards” to the Internal Control just created. Make sure the GRC Contact is your GRC group and the Control Operator is the “Dummy” account. Ignore Audits and Maintenances for now.
Create a Security Operations / Project "End-Point Security for Mac Computers", Make sure the “Project Owner” is the “Dummy” account and the “GRC Contact” is your GRC group. Set the “Deadline” to two days from today and the project as “Ongoing.”
Create an Risk Management / Exception called "Linux Computers not Secured", Make sure the “GRC Contact” is your GRC group and the “Requestor Contact” is the dummy account. Set the deadline to two days from today and the “Status” to “Open.” Link the Risk created before to the Exception.
Link the Internal Controls, Policy, Exception, and Project to any compliance requirement.

You should now have a decent idea of how all these different modules work and tie together. Complete this guide to the end, and then restart this process until you have identified all real solutions (treatment) for each compliance requirement you are dealing with.

Basic Section Report

In order to complete these tasks, you need to understand how Reporting work in detail.

As you complete the Analysis phase (which will take you some time) is a good idea to visualise a simple System Item Report that is pre-built for you to see progress:

Click on the checkbox of any item in Compliance Management / Compliance Analysis.
Click on Report / Section Report / System Report Template and load it.
There are multiple charts that will display the progress of your implementation, in particular “Compliance Strategy.” If you followed our analysis, you would have only switched the strategy to “Compliant” for those items where you identified solutions, leaving all others incomplete. This will highlight how much work remains.
You can send this report by email every week by going to the Common Features menu, clicking on Notifications, and creating a Report Notification with that report embedded.

Basic Module Configurations

In order to complete these tasks, you need to understand how the user interface and customisations work in detail.

Apply the following basic configurations to all modules involved so far: Compliance Management / Compliance Analysis, Control Catalogue / Policies, Control Catalogue / Internal Controls, Compliance Management / Compliance Exceptions, Security Operations / Projects:

Using customisations, make sure you hide as many fields as possible, leaving the form as lean as possible.
Adjust the default view by configuring columns, sorting, etc., and set it as “Default for Me.”
Clone the previous view and set it as “Default for Others.”
Pin “Template” views, which are hidden by default.
Create your own custom views.

Advanced Module Customisations (Optional)

In order to complete these tasks, you need to understand how customisations, Dynamic Statuses, and Reports work in detail. This is an optional step.

As you identify Internal Controls and Policies as part of the “Compliance Analysis” phase, you often do not know exactly if these items are “mature” or not, meaning if they are really solutions. Sometimes it is a good idea to create a simple custom field with a dropdown called “Maturity” with basic options: Unknown (Default), OK, NOT OK. Then, using Dynamic Statuses, views, and reports, you can track the percentage of these items.

On the Control Catalogue / Policies, Control Catalogue / Internal Controls modules:

Create a custom field with the fields mentioned above (or whatever you want to call them).
Create two Dynamic Statuses, one for “Unknown” and the other for “Not OK.”
Create two views where each filters items against those Dynamic Statuses you created.
Create a Section Report that shows those two Dynamic Statuses in a report.
Adjust the landing dashboard with a chart showing those two statuses.

Compliance Management / Compliance Analysis module:

Create two Dynamic Statuses that inherit the statuses created in the Policy and Internal Control modules.
Create two views for these statuses, showing the affected compliance requirements.

Internal Control Audits

In order to complete these tasks, you need to understand how Internal Controls and in particular Audits work in detail. Our recommendation is that you always start with a “dummy” control to test your understanding of the module and its notifications, and only once you feel comfortable.

The objective of this phase is to define testing for the controls you have identified:

For every Internal Control you created, decide whether you want to test it or not.
If you want to test it, decide whether you will use manual or automated testing.
Configure audits.

Basic Weekly Reports

In order to complete these tasks, you need to understand how Views and Notifications work in detail.

The idea of this section is to enable Report notifications for all four solution modules, these report notifications will notify you of expired and soon to be expired items that need your attention. For each one of the following modules: Control Catalogue / Policies, Control Catalogue / Internal Controls, Compliance Management / Compliance Exceptions, Security Operations / Projects:

Pin the views “Expired…” and “Deadline in the next couple of weeks.”
Enable the pre-defined report notifications; do not forget to adjust the recipient (typically your GRC group) and the frequency.

Warning Notifications

In order to complete these tasks, you need to understand how Notifications work in detail.

For each one of the following modules Control Catalogue / Policies / Reviews, Control Catalogue / Internal Controls / Audits, Compliance Management / Compliance Exceptions, Security Operations / Projects define the type of "Feedback" you wish to obtain from the departments inr your organisations:

Enable the “-1 Deadline” warning notifications, making sure you adjust the Subject and Body to reflect exactly what your intentions are.
Enable the "Comments & Attachment" notification
Create a “dummy” item in the module and set the deadline (this will be different for each of these modules) to two days in the future. Make sure the owner of the item is the “dummy” account created during the Access Management phase.
At midnight, the notification should pick up the item you created and send emails to your dummy account. You can now test the permissions of that account and ensure it can provide feedback correctly.
Correct any missing or incorrectly assigned permissions, ensuring the dummy account can perform all the intended tasks.

Roll-Out of Accounts

In order to complete these tasks, you need to understand how Access Management work in detail.

This involves the creation of user accounts for each department created during the “Access Phase”. This will help these people log in to Eramba and see Compliance Requirements, Internal Controls, Policies, Projects and Exceptions assigned to them, provide feedback for Risks, and perform any other tasks you wish them to perform.

To create an account:

Go to System / Settings / Organization & Access
Create user accounts with the same group settings as the “Dummy” user; just include the “Group” for the department that the person belongs to.

The operational side of things after Risks are created involves keeping both the Context and the "Solutions" updated. These activities all take place in this phase at the intervals you define for each of them.

Reporting

In order to complete these tasks, you need to understand how Reporting work in detail.

Start by:

Customising your landing dashboard.

For every module involved:

Create a Section Report.
Configure a Report notification to send it over email regularly.
Create an Item Report.

Operations

A key operational task for this use case is to review and test all items related to your Compliance Requiremetns. Review each module's documentation to make sure you understand how it works.

Audit your internal controls (Internal Control documentation)
Review your policies (Policy documentation)
Review your projects (Project documentation)
Review your exceptions (Exception documentation)