Notifications

Introduction

There are many ways notifications can be used in eramba, in this episode we share with you the typical scenarios based on the maturity of the organisation so you can define what suits you best.

Scenarios

Every module in eramba has items and these items go through many different scenarios, the more you customise eramba the more scenarios you will have. The table below provides a few examples:

Module	Situation
Risk	Risk review is about to expire Risk review is completed Risk changes to "High" Risk-mitigating controls failed the last audit Etc
Internal Control	Audit is due Audit is complete Control missed an audit deadline Etc
Policy	Policy review is about to expire Policy review is completed Associated control to policy failed the last audit Associated control to policy is missing the last audit

What we typically want is to trigger some form of notification when these scenarios take place and notify someone (the owner role mentioned before) or something (a remote system if you are doing integrations for example).

In eramba, these scenarios are triggered by Dynamic Status or pre-defined Warning notification scenarios. What happens after the notification triggers depends on the type of feedback you need, we will discuss feedback in the next section.

Comments & Attachments

Every item in the software (Risk, Risk Review, Project, Task, Exception, etc) has Comments and attachments associated, this is the place where we collect and store feedback from everyone. 

Comments & Attachments is the place where feedback (you will read later what this is) is collected, this allows a very detail trail of conversations to be recorded.

Feedback

A key use case when using Warning notifications is what we call "Feedback".

When a scenario takes place you typically want those that are related to the item that triggers the scenario to provide you with some input, what input depends on the item:

• Risk: risk review feedback
• Audit: evidence to test a control
• Policy: feedback on the review of a policy
• Etc

In eramba, you have two general types of feedback:

• Offline: eramba will trigger a notification to those related to the item but the feedback will be done between them using emails, slack or internal meetings. Once the feedback has been collected, those on the "GRC" role will log into eramba and upload this feedback.
• Online: eramba will trigger a notification to those related to the item and they will click on the email they received and provide feedback directly on the item. This will trigger another notification to everyone involved (telling them someone provided feedback on the item). This process can repeat many times, eventually, the GRC role will log into eramba and update the item (close review, audit, exception, etc).

The diagram below shows the online feedback review:

The diagram below shows the offline feedback review:

 

The offline method has the advantage of making it much simpler for people around your company, they don't have to log into eramba and do anything there. Is very recommended for companies that are just starting with eramba.

The online method will require accounts for people around the organisation (those who own something in eramba) and their permissions will need to be adjusted so they can not edit, delete or create items, just provide feedback.

Remember that these notifications are created by you and the recipients do not need to be strictly as shown in the diagrams above. You need to define a workflow that works for you and adjust notifications accordingly.

Maturity

As nice as automation sounds, sending emails to everyone in the organisation can be a problem if these people are not expecting them. For that reason, we strongly advise users to devise a gradual notification and automation strategy.

The table below shows the type of notifications we recommend based on your organisation's strategy and in particular maturity.

As you can see from the table above, in the "Basic Notifications" stage is that you send notifications that always go to your GRC team no matter who owns the item that triggered the notifications in the first place. For example, if a Risk is owned by IT, the notification when the review is due will go to GRC instead of IT.  Your GRC department will then conduct an "Offline" feedback for that Risk. Report notifications are also sent to your GRC team alone, for example, if you create a report that lists "All Risks that must be reviewed next week" you will send that to you, no matter who owns those Risks.

When you progress on your automation journey, you will move to more advanced notifications. The notifications are largely the same as the ones you configured in the Basic stage, but this time the recipients will be other departments (IT, HR, etc.). Following the example, the notification will go to "IT" and if you want the GRC team in CC.

The advanced stage focuses on automation and integration with other tools. Notifications in this stage don't trigger emails instead they use REST APIs. This allows you to initiate integrations with other tools and systems.

Conclusion

At this stage, you should define the following:

• What modules you will be using (based on your use cases)
• For each module, what scenarios you need to identify to trigger notifications or REST calls
• What type of feedback you want to use (Offline or Online)
• What configurations (notifications, dynamic status, filters, etc) are needed in order to make this work

Predefined Scenarios

Almost every module in eramba comes with predefined notifications (warning, report, etc), filters and Dynamic Statuses you can leverage to trigger your desired use cases. They will still need adjustments to completely match your needs but will certainly help you for inspiration.