Notifications

Notifications are available in all modules of the software, this feature is located at the top bar of every module. 

Once you know how notifications are used you can apply that knowledge to any module.

Just like spreadsheets, building a GRC program is simpler than operating it. The reason for this is that a GRC program is composed of many items (this is why eramba has so many modules) and these modules' data must kept up to date in order to reflect the reality of your organisation.

For example:

• Policies must be reviewed
• Internal Controls must be tested
• Risks must be reviewed
• Projects have deadlines, and their tasks too
• Etc

To keep up with all these deadlines and tasks you need two things:

• An owner for every task that understands what the tas is all about
• A notification that reminds the owner when things are due

All items created in eramba will require you to assign an owner (typically a team), for example:

• The network policy is owned by the Network Team
• The CCTV Internal Control is owned by the Physical Security team
• The Risk "Website could be hacked" is owned by the Applications Team
• Etc

All these items will also have an additional role, one that tells eramba who in your GRC team is related to that object. In the end, you will have almost in every module two roles.

You can configure, on every one of these modules, different types of notifications that will trigger specific events. The typical basic notification is called "Warning" and works the same way on every module.

• For any item (risk, control, policy, etc) with a deadline due, eramba will notify the "Owner" and (optionally) the "GRC Contact". You can actually define any recipient you want, but those are the typical ones.
• The "Owner" clicks on the email (which by the way can be fully customized), logs into eramba and provides feedback on the item.
• The "GRC Contact" gets a notification of the feedback, and replies.
• The two steps above can take multiple rounds until at some point the "GRC Contact" edits the item (Risk, Policy, etc.).

You can configure the workflow in any way you want, you could decide that the notification goes to the GRC Contact instead of emailing the Owner. The GRC Contact will then, offline (in person, email, etc) talk to the "Owner" and simply update the item a summary of those conversations.

Another, very popular type of notification in eramba is a "Report" notification. This is because sometimes you want a "list of things" that interest you sent to your email regularly so you can "keep up with tasks". For example:

• List of Policies that expire next week
• List of Risks owned by IT, which are "High Risk", that are expired
• List of all new Internal Control audits created last week
• Etc

The first step is to create this list, you will use the Filters built-in feature in eramba, there are million possible combinations. Once you have the filter created you will simply create a Report notification.

eramba will run that filter as frequently as you have defined and whatever the filter produces (it might be empty) will be sent by email to your desired recipients.

The typical module will include a combination of the two notifications explained above, warning and report.

The third and perhaps more interesting notification for those interested in advanced automation is a variant of the warning notification explained before, but the trigger in this case is not a deadline but any condition you define.

The condition is a Dynamic Status (please review the course, they are pretty flexible) something built into the core of eramba. Every module's first column will show the status configured on that module.

You can configure this status in any way you want with advanced conditions that include field comparisons, functions, etc. For example:

• When a Risk is "High" and the mitigating control last audit is Failed
• When a Policy name includes the word "Policy"
• When more than %30 of the audits of an Internal Control are set to "Failed"
• When a Risk status includes "Accept"
• Etc

When your conditions match, they will show a status. When they match they can also trigger notifications defined by you.

The notification is very simple, you just tell what status you want to track and where to send emails.

This notification offers a lot of flexibility because the trigger is fully configured based on your own settings.

All warning notifications can be delivered in the form of Emails or/and REST APIs. You decide which will be the delivery method and the recipient. If you choose REST you will configure the endpoint, headers and payload.