Course Introduction

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

The course follows a logical progression through three main pillars:

1. Theoretical Concepts: The underlying logic and risk methodology.

2. Implementation Steps: The technical configuration of the module.

3. Operational Steps: The day-to-day activities required to keep risk 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 risks. To fully implement Risk 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 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 Risk 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 dilligent and careful on your questions you wil 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:

• Risk Contextualization: Documenting exactly what is at risk by linking entries to Assets, Third Parties, Business Units, or Processes.

• Risk Classification & Scoring: Defining your own scales (e.g., 1–5 or Low–High) to calculate Inherent and Residual risk scores using a customized matrix.

• Risk Treatment Mapping: Assigning specific "solutions" to a risk, such as Internal Controls (activities), Policies (documentation), or Projects (future improvements).

• Life-cycle Automation: Using Dynamic Status to automatically flag risks that are overdue for review or those whose mitigating controls have failed an audit.

• Stakeholder Accountability: Assigning Risk Owners and GRC Contacts to ensure there is clear responsibility for every identified threat.

• Risk Reporting: Generating automated dashboards and reports to communicate the organization's risk posture to management and auditors.

Supported Versions

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

Theory

Module Relationships (Problems & Solutions)

The Risk Management guide requires the use of multiple “related modules” in eramba. Depending on the type of risk you intend to use, there are three options: Asset, Third Party, and Business Risk.

The yellow part of the diagram indicates what we call the risk context, that is, the inputs to the risk:

• An Asset Risk example could be: “Laptops could be lost or stolen, resulting in data loss.” This would be an Asset Risk with a related asset called “Laptops.” The “Laptops” asset has a related business unit called “IT.”

• If you then decide to create a Third Party Risk, for example, “Laptops can be stolen during the night shift when the cleaning company is present,” that risk would fall under Third Party Risk Management. In this case, you would reuse the existing asset “Laptops” and create a new third party called “Cleaning Company.”

• A Business Risk would be different. For example: “If eramba has many bugs, customers will become fed up and go elsewhere.” In this case, the related business unit (in the context of the eramba company) would be “Software Development,” and a specific process would be associated, called “Software Testing.”

In all three scenarios, all risks require treatment. In eramba, this can be achieved using Security Policies, Internal Controls, Exceptions, and Projects:

• Internal Controls: These are activities performed within the company to treat the risk, for example “laptop encryption” or “strong authentication.” (Internal Control module documentation)

• Policies: These are documents that support risk treatment, for example “Acceptable Use of Assets” or “Endpoint Security Policy.” (Policy Module documentation)

• Exceptions: These are used when a risk is intentionally not treated. For example, if Linux computers represent a small subset of your endpoint inventory and are not a priority, you could make this explicit by creating an exception such as “Linux computers not protected.” (Exception module documentation)

• Projects: These represent future plans, for example “Implement endpoint protection for Linux.” (Project module documentation)

A risk can have one or more solutions. The objective is always to reflect the current reality of your risks.

Statuses

There are multiple operational tasks regarding risk management in eramba. These are all aimed at keeping data updated and accurate and, most importantly, ensuring everyone is on board. The last thing you want is for a risk to become a reality and have stakeholders claim they were never informed.

A risk in eramba has multiple related items (Controls, Assets, Exceptions, Policies, etc.), and all of them must be reviewed or tested to ensure they perform as expected.

As seen in the diagram below, a Risk might be reviewed twice a year, while its associated controls are reviewed four times a year and your exceptions only once. Keep in mind that these associated controls and policies are often linked to many different risks and compliance requirements (the "Problems and Solutions" approach).

If an associated control fails a test, all risks 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 risk) whether the treatment is actually effective. The same logic applies to policy reviews, exception reviews, and project deadlines.

Asociated Costs

Doing risk management at this level of maturity costs time and money; however, these costs can be calculated in advance with some degree of accuracy.

For every business unit, you will identify 4–5 assets, 3–4 third parties, and perhaps 1–2 liabilities. You can think in terms of ratios: one Business Unit leads to 8–11 items of context.

For every 10 contextual items (as mentioned above), you can expect to identify 5–10 critical risks that cannot be ignored. For every risk identified, you must determine solutions, which will be leveraged across different risks to some degree. Typically, for every risk you identify, you will need a mix of 3–5 solutions.

If you (or better an LLM) do the math, you will find that if you have five Busienss Unit you then have somewhere in between 20 and 55 Risks and 60 to 275 solutions. The power of multiplication and ratios is that it grows linealy.

If the top of the pyramid is wide (because you make the scope enormous or identify millions of assets), the bottom will become humongous. The problem is not the time it takes to create these htings in eramna (CSV imports make it easy), the problem is the cost of keeping it all updated.

Risks must be reviewed, as must Assets and Third Parties. Policies, Exceptions, and Projects require reviews too. If you imagine an hour and a half for each review per year, you are looking at 174 hours a year. That equates to 22 working days for a single employee. Controls must also be tested—typically twice a year—and while testing duration can vary widely, let’s assume a couple of hours per test. That adds another 80 working days a year for a single employee.

The name of the game is not quantity, is quality.

Templates

We are working on an integrated list of Template Risks, please review our Product Roadmap for details and updates.

Risk Attributes

When creating or editing a Risk, users are presented with a form composed of multiple fields. Some fields are mandatory and must be completed in order to save the Risk, while others are optional and may be used to enrich the Risk record depending on the organization’s needs.

The Risk form is organized into three main tabs: General, Analysis, and Treatment. A fourth tab, Risk Response Plan, is optional and hidden by default.

Remenber you can always customise these forms using the Customisation common feature.

• The General tab defines the core identity and ownership of the Risk. The Risk must be described using a scenario-style title, similar to a newspaper headline, clearly stating what could happen and why it matters. Two roles are always required. The GRC Contact represents the department with an interest in creating and managing the Risk and is typically responsible for its governance and ongoing oversight. The Risk Originator represents the department whose activities generate the Risk, intentionally or unintentionally, and is usually identified during interviews or risk identification workshops. The Risk Review is a mandatory field that is used to force you to perform a review of this risk on the specified date.

Follow our recommendation for "Risk Scenario" best practices in this discussion post.

• The Risk Analysis tab is used to analyse (also referred to as assess) the Risk. The structure and fields of this tab change depending on the Risk module in use—Asset, Third Party, or Business—as each module requires different inputs. Threats and vulnerabilities can be defined either as free text or by using tags. When tags are used, they are automatically filtered based on the selected asset; this automated behavior applies only to Asset risks and does not apply to Business risks. Threat and Vulnerability tags are defined and managed under Settings, where they can be added, edited, or removed. At the end of the form, the Risk must be classified in its initial state, before any treatment is applied. This initial classification is commonly referred to as inherent risk. Based on the configured settings, Eramba places the Risk on the risk matrix and calculates the corresponding risk score.

Since 2013, ISO/IEC 27001 does not require an explicit relationship between Risks and Assets, nor the formal identification of Threats and Vulnerabilities. To simplify the risk assessment process, you may use a single generic Asset for all Risks and hide the Threat and Vulnerability fields using the common customization functionality, if desired.

• The Risk Treatment tab is where the current treatment applied by the organization is defined. It is important that this tab reflects today’s treatment, not future or planned actions; future improvements should be managed through Projects. Based on the selected treatment, you can associate the solutions that are currently in place, such as Internal Controls, Policies, Exceptions, and Projects. After defining the treatment, the Risk must be classified again, this time considering how the Risk has changed as a result of the applied treatment.

You can define which treatment options are available or mandatory based on the selected treatment by using Settings / Treatment Options. For example, if the user selects Mitigate, Internal Controls and Policies can be set as mandatory, while Exceptions and Projects remain optional.

• The Risk Response Plan tab is used to document the actions that must be taken if the documented Risk becomes a reality. This is done by associating one or more documents from the Policy module. The information defined here is also linked to the Incident module, so when an Incident is created, the operator is provided with clear response instructions.

Risk Reviews

Risk must be reviewed at regular intervals, you decide when that dealine is at the time of creation of the Risk. 

Failure to complete your reviews on time will cause the Dynamic Status (common feature) to trigger a yellow status warning. This is clearly a situation you want to avoid to ensure your risk data remains compliant and up to date.

All reviews are stored in the Reviews tab. You can use shortcuts that, when clicked, will filter the full list to show only the reviews applicable to your selected risk.

A Review record includes several attributes, as shown in the screenshot below—primarily when it was scheduled to happen, when it actually occurred, and what was discussed. Next to the Dynamic Status, you will see the Comments & Attachments button; this is essential, as it is where stakeholders will provide their feedback, sign-offs, or any other required documentation.

Based on that deadline, eramba will automatically create two Review records for every new Risk you create:

• An initial record represents the Starting point; this review will have all fields completed, with dates set to the day the risk was created and an automated description. While not mandatory, it is expected that everyone involved will include relevant comments and attachments.

• A second record, which remains incomplete, is for the Next Review date you defined when the risk was created. eramba monitors this planned date to trigger notifications (via the Notifications common feature) and update Dynamic Statuses (via the Dynamic Status common feature).

At this point, there are three typical scenarios:

• Change Review Date: You need to change the "Planned Date" for your next review.

• Scheduled Review: Your "Planned Date" is overdue or approaching, and you need to complete the review record.

• Ad-Hoc Review: You have changed something on the risk (such as its classification) and need to complete a new review to sign off on this change.

• You might not want to do Reviews anymore for this Risk

Scheduled Review

This type of review takes place before, on, or after the planned review date and is the most common scenario. Eramba will notify users (via common notification features) of this deadline and expect their feedback in the form of comments and attachments inserted into the specific review record.

The review is meant to be agreed upon by both parties (the Risk Originator and GRC Contact), where both provide feedback through comments and attachments.

Once the discussion is completed, the GRC Contact can select the review record, click Edit, and complete the form with the other review attributes (Description, Actual Date, Next Review Date, etc.).

Once a review is completed, it can no longer be edited. Once saved, Eramba will automatically create a new review record with the planned date you specified.

Ad-Hoc Review

This type of review is a spontaneous need to create a new review record that does not exist in Eramba. Typically, this happens if the next scheduled review is set too far in the future and a review is required immediately.

To create an ad hoc review, click Add under the Review tab and complete the form. Once the record is created, you should include your feedback in Comments & Attachments.

Change Review

If you want to change the date of your next Scheduled Review, simply edit the record, complete it (stating that you are specifically changing the next review date), and set the new date. Once you save, you will close that record and create a new one with the date you required.

Remove Reviews

If you no longer want to conduct reviews for a risk, simply delete the current incomplete review record.

Risk Classifications

We see many times organizations doing this in a very complicated, impossible-to-sustain way. We strongly advise you to follow some reading guidance on what we see works well and the logic behind it.

The process of configuring eramba for Risk Management is a three-step process centered on one crucial initial decision: whether to use a Single Matrix or a Multiple Matrix setup.

• This is the recommended choice for most organizations. It involves a single matrix with two axes—typically Likelihood and Impact. It is straightforward to maintain and provides a clear, unified view of risk across the organization.

• This approach is significantly more complex and is typically chosen by advanced practitioners. It involves setting up several "simple matrices," one for each specific Impact Type. For example, you might have separate matrices for: Financial Impact, Regulatory Impact, etc.

Once that decision is made, you will need to define three specific settings:

1. Classification Names, etc. (Light Blue): Define the labels and values for your axes (e.g., Low to High, 1 to 5).

2. Calculation Method (Darker Blue): Determine how the system calculates the intersection between these classifications (e.g., Addition or Multiplication).

3. Risk Matrix "Cell" Configuration (Very Dark Blue): Map the results to specific risk levels (e.g., defining which intersections result in a "Critical" or "Low" risk).

The overall process is described in the diagram below:

 

Classification

The final objective of risk classification in Eramba is to place Risks on a two-axis Risk Matrix (for example, Likelihood and Impact).

There are two supported approaches:

• Single matrix with two axes, such as Likelihood and Impact

• Multiple matrices with two axes, where a single Likelihood is combined with multiple Impact types (for example, Financial, Reputational, etc.)

The multiple-matrix approach is much more complex to configure and maintain; therefore, it should be used only after careful consideration in very particular scenarios.

If you are starting and you don't know what to do, we recommend following instructions from this simple forum article

Classifications are managed from Settings / Classification and Settings / Classification Types, where classifications can be added, edited, or removed.

Once a classification is defined and used by multiple Risks, changing it later requires updating the classification on all affected Risks. For this reason, it is recommended to avoid modifying classifications after they are in active use.

Classifications defined in any one Risk module are shared across all three Risk modules, so changes apply globally and will impact Asset, Third Party, and Business Risks alike.

Calculation

If you like math or if you don't and you wish to get an advice we strongly suggest you revew this article on what we see works well and the logic behind it.

Once the classification is defined and you have chosen between a single matrix (recommended) or multiple matrices, the next step is to define the risk calculation. Under Settings / Risk Calculation, you can select from the following options:

• Addition or Multiplication (for a single matrix)

• Multiplication only (for multiple matrices)

Note: Magerit is no longer supported and should not be used. 

Matrix

Once the classification and calculation steps are completed, you can define the Risk Matrix settings. Under Settings / Risk Appetite, you define how the matrix is structured.

For every possible combination in the matrix, you must assign a title, description, and color. These settings can be modified at any time.

Treatment Options

Under Settings / Treatment options you can define, for each treament option (Accept, Avoid, Transfer and Mitigate) what solutiosn are mandantory or optional. This is often times useful to enfroce a systematic treatment of Risks.

Threats & Vulnerabilities

When documenting Risks, you may optionally record Threats and Vulnerabilities, as these fields can be hidden using customization settings. They can be documented either as free text or by using tags. If tags are used, Eramba’s built-in tag databases can be managed under Settings / Threats and Settings / Vulnerabilities.

These tags can be associated with Asset Management / Assets / Settings / Asset Types so that, when an Asset is selected on a Risk, all related tags are automatically displayed. Tags can be added (individually or via CSV import), edited, and deleted.

Risk Identification

This guide helps you understand how the Risk module works through the process of creating, reviewing, and signing off risks. There is very little information here regarding how these risks are identified; this is because the methodology used to identify risks within a given scope (organization, application, etc.) varies widely from one practitioner to another.

We do not advocate for a 'Best Practice' when it comes to GRC, as it is a governance practice much like Sales or Marketing; there is no single 'correct' way, since it must adapt to specific needs, resources, culture, and more. In this guide, we explain a method for identifying risks that works for most organizations

Risk interviews with every department in scope are probably the easiest and most accurate way to collect relevant risk information. If you would like help with this process, contact support@eramba.org.

The overall logic for these interviews is as follows:

• Segment Your Scope: Break down your scope into manageable chunks (for example, by department).

• Schedule Sessions: Set interviews with department heads or key staff; typically, 2 hours is sufficient.

• Establish Context: Ask them what they do (Process), which tools they use (Assets), which vendors they work with (Third Parties), and what rules they must follow (Liabilities). This provides the necessary context for Eramba and overall risk identification.

• Review History: Ask about past incidents. These are "low-hanging fruit" for risks that could recur. Also, seek to understand what solutions or "workarounds" are currently in place.

• Identify Known Risks: Ask what risks they are already aware of and what is currently being done to mitigate them. It is vital to document these; if a known risk materializes and was not recorded, the oversight often falls on the GRC team.

This exercise is as straightforward as it seems and it has been used in mega large, small, public and private organisation with success. The interviewer (typically from the GRC team) acts as a facilitator rather than dictating which risks exist.

Implementation

The process by which you implement this module in eramba is defined in clear stages that you must not skip or take lightly. Remember that many of these phases will make constant reference to supporting modules (Assets, Internal Controls, Policies, etc.) and common features (Notifications, Customizations, Views, etc.).

Access Management

During the implementation phase, it is important to understand how the user interface works (views, add, edit, delete, bulk edits, and similar actions). Reviewing this upfront will make the implementation process smoother and more efficient.

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

1. Log in to Eramba for the first time and set the Admin password and email (do not use a personal email address)

2. Create a group for your GRC department (name it according to your department)

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

4. Create a dummy user account, assign it to the “No Allowed Permissions” group, and enable the Main portal only. The account can remain inactive for now.

5. Log out as Admin, from now on always login with your personal account

6. Create one Group for every Department in the scope of your Risk program

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

Risk Configurations

Before you can create any Risks, you must configure the Risk module(s) you plan to use (Asset, Third Party, and/or Business Risk). Follow these steps to complete this phase of the implementation; detailed instructions for each step are provided in this document:

1. Define whether you will use a Single Risk Matrix (recommended) or Multiple Risk Matrices (not recommended)

2. Configure the Classification Types for the risk matrix (for example, Likelihood and Impact). A single matrix requires two classification types, while a multiple matrix setup requires at least three (one Likelihood and two or more Impact types).

3. Configure the Classifications for each previously type (for example, High, Medium, Low)

4. Select a risk calculation method, ensuring it is compatible with the chosen matrix type

5. Configure the Risk Appetie / Threshold settings so your matrix has all its cells configured

Risk Notifications (Optional)

There are many possibilities when it comes to notifications. It is strongly recommended that you fully understand how they work by reviewing the notification common feature before making configuration decisions.

There are three notifications you will most likely want to enable in Eramba:

• Report: Sends a weekly email with an export of Expired Risk Reviews and Upcoming Risk Reviews (only if there are matching items)

• Warning: Sends an email to both Risk roles 10 days before a Risk Review is due. The email includes a clickable link that allows the Risk Reviewer to provide review feedback

• Comment & Attachment: Notifies all involved parties when a comment or attachment is added

To enable Report notifications, on the Risk tab (not the Risk Review tab), go to Common Features / Notifications:

1. Enable the Report / Risk with Expired Reviews notification.

2. Enable the Report / Risk with Reviews in the Coming Two Weeks notification.

3. In both instances, you may want to edit and adjust the recipient, subject, and body of the email.

You can create any type of report notification you want; the ones mentioned above are just the standard options that ship with eramba.

To enable Warning and Comments/Attachment notifications, navigate to the Risk Review tab and select Common Features / Notifications:

1. Enable the Warning / Review in 1 Day notification.

2. Enable the Warning / Review in 10 Days notification.

3. Enable the Warning / Review Completed notification.

4. Enable the Comments / New Comments notification.

There are multiple ways to trigger warning notifications; the ones mentioned above are just the basic options that most users will employ. The body and subject of these notifications are particularly important. You should consider whether you want recipients to click a link and provide feedback in eramba upon receiving the email, or if you simply want to inform them of a deadline. You must adjust the notification content based on your chosen approach.

Risk Creation

Using Web-Forms

It is recommended to first create a single Risk first using forms to ensure you fully understand how each involved module works.

After creating your first items in any module, use the customization common feature to adjust the fields so that forms display the minimum number of fields necessary for users. Typical examples include: Status of the Risk (Open, Closed, Archived, Etc), Root Cause, Business Case for Treatment, Etc.

Adjust the default views and ensure you have defined a default landing view. You can also set default views for all other users. For example: All Risks, Expired Risks, Risk Expiring in 2 Weeks, Top 10 Risks, Etc.

Once that Risk is completed, creating or importing multiple Risks—manually or in bulk—becomes straightforward. For this phase we provide you with a sample risk "Laptops can be Lost or Stolen and data can be lost" that will have the following related items:

• Business Unit: IT

• Asset: Laptops

• Internal Control: End-Point Security Controls, End-Point Centralized Authentication

• Policy: End-Point Security Standards

• Project: End-Point Security for Mac Computers

• Exception: Linux Computers not Secured

The tasks required to create this Risk begins by creating the inputs to the Risk:

1. Create a Business Unit

2. Create an Asset

Then you can create the Risk:

1. Create a Risk

Then you create the Treatment options to the Risk:

1. Create a Policy

2. Create Internal Controls and link the Policy “End-Point Security Standards” to the Internal Control “End-Point Security Controls”

3. Create a Project

4. Create an Exception

Then you link the treatment options to the Risk:

1. Link the Internal Controls, Policy, Exception, and Project to the Risk

By the end of this exercise, you should have:

• Created one item in every module

• Customized the forms in each module to ensure they are as simple as possible

• Adjusted a default view for yourself and, optionally, for all other users

• Understood how these forms work together to document a Risk

Using CSVs Imports (Optional)

This step is optional and only applies if you already have a list of risks for your organization in a spreadsheet and would like to import them into eramba.

If you already have a spreadsheet-based risk register, you must ensure that your risk calculation method is compatible with eramba; otherwise, the import process will not work.

The most common issue is that a single (or multi-tab) spreadsheet differs from eramba's Risk import structure. Because eramba requires multiple modules—each with its own specific attributes—you cannot perform a single upload. Your task is to break down your existing spreadsheet into the various CSV imports that eramba requires.

Please make sure you review how the CSV Import common functionality works before you attempt any of this.

If you want to import Risks from a spreadsheet into Eramba, some preparation is required to ensure the import works correctly:

1. Create Business Units in eramba using forms

2. Prepare a Spreadsheet with one tab for each one of the following modules: Assets, Third Parties, Risks, Internal Controls, Policies, Projects and Exceptions

3. Import on each tab the CSV Import template from eramba, review the CSV Import common feautre to learn how to work with these imports.

4. Copy/paste the columns from your risk register into the CSV sheets you prepared in the previous step. This will quickly highlight which fields your spreadsheet has that eramba does not, as well as which fields eramba requires that your spreadsheet is missing. You will need to fill these gaps to proceed. If your spreadsheet contains essential data that eramba does not support by default, you can use the Common Customization functionality to create the missing fields.

Once your spreadsheets are completed, import them in the following order:

1. Assets and/or Third Parties

2. Policies

3. Internal Controls

4. Projects

5. Exceptions

6. Risks

Risk Sign-Off

Once you create a Risk is very important that is properly signed off, accountability is really critical in Risk management (consider what will happen when the Risk becomes a reality).

Steps:

1. Create a Item Report of the Risk and download the PDF (Optional)

2. Import that PDF to the "Initial" Review record

3. Both the GRC Contact and Risk Originator Contact must insert a Comment on the "Initial" Review record 

You can use notifications that trigger when a Risk or a Risk Review (Completed) is created to inform those involved. The Risk notification will include specific details of the risk, while the Risk Review Completed notification will request feedback from users via a link in the email.

The same sign-off process is often applied to all related items (Assets, Business Units, Controls, etc.). However, this is an optional, labor-intensive task that we do not recommend performing.

Roll Out of Accounts (tbd)

tbd

Operations

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.

Risks

The key operational task in relation to risk is to perform risk reviews.

Ad-Hoc Review

1. Go to the Risk / Review Tab

2. Click Add, select the Risk

3. Complete the Review form

4. Add comments and attachments to the Review

Scheduled Review

1. Go to the Risk module, select the Risk and click on the Review counter

2. Edit the only review that is incomplete

3. Complete the Review form, select the next Review Date

4. Add comments and attachments to the Review

Solutions

A key operational task outside the Risk module is to review and test all items related to your risks. 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)

Risk Reporting (Optional)

See Reporting documentation

Risk Automation (Optional)

See Automation documentation