Risk Management

Introduction

As explained in the introduction of this course, there are three types of Risks:

• Asset Risks
• Third Party Risks
• Business Risks

They all need an "Input" that helps you describe what the Risk is all about, depending on which type of Risk you are creating and what "Inputs" you require.

• Asset Risk Management: requires assets, these assets require a Business Unit.
• Third Party Risk Management: requires assets (as mentioned above) and Third Parties with whom you share these assets.
• Business Risk Management: requires Business Units and optionally their processes.

The diagram below shows inputs inside a pink square and solutions inside a green square.

Risks have four treatment options (combination of them, etc): Policies, Internal Controls, Exceptions and Projects. For example: If an "Asset Risk" describes how "Laptops and be lost or stolen" your treatment might be:

• Two mitigating "Internal Controls" under the name "Laptop Encryption" and "Central Authentication".
• You might also link a "Project" called "New central data loss prevention solution".

Your inputs might be:

• An "Asset" called "Laptops" and another called "Mobile Phones", both linked to the business unit "Technology".

In this episode, we are concerned with the identification of Risks (pink square), not with their treatment. We will explain in detail what items you need and one method on how those can be obtained. 

Note: there are an infinite number of methods on how to identify Risks, we are simply here trying to provide one simple method that will ensure you collect those "Inputs" you need.

Prerequisites

Make sure you complete the Supporting Modules / Asset Management course before you continue with this guide.

Dependencies

As shown in the diagram above, depending on what type of Risk you want to create what inputs you need:

Risk Type	Business Units	Process	Assets	Third Parties	Liabilities
Asset Risk	At least one	Not required	At least one	Not required	Optional
Third-Party Risk	At least one	Not required	At least one	At least one	Optional
Business Risk	At least one	Optional	Not required	Not Required	Not required

The following examples will hopefully help you understand these relationships:

• An Asset Risk titled "Laptops can be lost or stolen" could have as inputs two "Assets" called "Laptops" and "Phones" and those two assets will have as a parent BU "IT".
• A Third Party Risk titled "Offices Equipment Stolen by Cleaning night shift" could have as input a Third Party called "Cleaning Company", an asset called "Office Equipment" and the BU that owns that asset would be called "Facilities".
• A Business Risk titled "Staffing Issues prevent IT Ops from running" could have as input a Business Unit called "HR" and a process called "Recruiting"

The examples above are generic and are meant to help the reader understand that Risks can be described in three ways.

Identification Method

Your goal is to identify inputs and as a second step, Risks that are related to them.

As part of the identification process make sure that all these objects (Assets, Third Parties, Risks, etc.) have clear owners, for example, the Asset "Laptop" will be owned by the group "IT" and the Third Party "AWS Services" will also be owned by the group "IT".

We recommend you use "Groups" and not "User" accounts as owners of these items, hopefully, you followed our implementation guides and you already have them created in your system. In this episode, we will present you with a simple method that helps you collect all the information you need to input risks in eramba.

Although there are many ways to do this, the method described here is very simple and is proven to have worked everywhere:

• Define the scope of your Risk practice: The scope can be one, two, or all, departments. If your scope is not the entire organization, always remember the strength of a chain is determined by its weakest link. In our example, the scope will be the entire organization.
• Break down the organization into "manageable" pieces with clear owners: In our example, we will break down the organization into HR, IT, Finance and Sales. You should have owners (one or more) and you should also have one group in eramba for each one of these departments.

• Set a meeting with "Owners" and let them know you are building a Risk register that will hopefully help them to make their Risks visible to the board and get some funding to deal with them. No one wants to own a ticking bomb after all.

Once you compiled the table above, you need to interview them in the hope they will share with you what problems they would like to expose to the board. Is wise to listen to them, you don't want to tell the experts of a department what problems they have. Also, you want to make sure their problems are documented, what if they become a reality and you decide they are not important? We always recommend asking the following four questions, we are using the Finance department as an example: 

• What do you guys do here? We do invoices, pay invoices, review expenses, calculate taxes and administer budgets. They will most likely spend half an hour talking about it, our job is to keep it simple. These will be your "Processes".
• With what? We use Laptops, Email, Sharepoint, Banking Applications and Invoices. As you can see this is not an inventory. Review our Asset Management course "Typical Questions" if you expected one. These will be your "Assets".
• With whom? Tax Consultants. These will be your "Third Parties".
• Under what regulations? SOX and various commercial contractual agreements. These will be your "Liabilities".

The feedback obtained can be temporarily written on a paper or spreadsheet as shown in the table below.

You can now go through this list of items (shown above) and with the help of the Finance contact (in this example) brainstorm what problems exist. Typically they already know what Risks they face, and never ignore those. Risks in eramba are described as scenarios so their "Title" is very important.

Like newspapers, you will need to get creative to make risk titles a striking headline! A typical Risk typically title includes:

• Threat (Unauthorized Access)
• Vulnerability (lack of provisioning)
• Asset, Third Party or Business Unit (Banking in this case)
• Ideally an adjective, such as "Massive"

NOTE: eramba ships with a list of threats and vulnerabilities, you might want to identify which ones apply the the risks you are creating.

Repeating this method through all your departments will get you all the inputs you need to start recording Risks in eramba.

Outcome

For every input and Risk identified, you will need to identify a few additional, bare minimum attributes:

• BU: owner (ideally group in eramba)
• Third Party: owner (ideally group in eramba)
• Liability: owner (ideally group in eramba)
• Asset: owner (ideally group in eramba), asset type and when the next review of the asset will take place.
• Risk: owner (ideally group in eramba), assets and next risk review.

While there are more attributes for these items, these are the bare minimum we strongly advice you to clearly define as part of the identification exercise.

Questionnaires

No matter if you go through the interviews above in person or over email, phone or Zoom you will be asking questions and expect answers.

eramba has an Online Assessment module that allows you to upload questionnaires and send them online to anyone (people inside or outside your organisation such as Third Parties).  We recommend you look at the Supporting Modules / Online Assessment module to know more.

Spreadsheets

If your organization already has a list of Risks then your focus perhaps should be around identifying the items eramba neds for every risk out of those spreadsheets.

Chances are you will be missing fields, the same interview process we explained above can be used to fill in missing gaps. The process is important because ensures accountability from all teams involved is defined and discussed, this is essential for the Review process.