Request failed with status code 502
Request failed with status code 502


User defined email and REST API based notifications to manage GRC - long

  • Episodes5
  • Duration19m 58s
  • LanguagesEN
Episode 1

Introduction to Notifications

Quick introduction to the module key capabilities


Notifications are one of the common features menu available to all modules and used exactly the same no matter in which module you are.

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

GRC Operations

Building a GRC program is simpler than operating it - a bit like spreadsheets they are much simpler to build than to keep updated. Operating a GRC program implies reflecting the reality of the organization at all times, this is not possible unless you receive feedback from every corner of the organization.

Without reports and notifications is very difficult to achieve this and for that reason, notifications, filters and status work closely to help you achieve this difficult task.

Email & REST APIs

When talking about notifications, in all cases except "Report" notifications you can choose to send Emails or/and REST AP|s. This means that based on your own conditions you can trigger automation requests.

While there are innumerable potential use cases for this feature, they will all require some form of software development experience.

Notification Types 

There are four types of notifications in every module in eramba:


To remind someone about a deadline (Policy Review, Risk Review, Control Audit, Task Deadline, Exception Deadline, Etc). This notification can be in the form of an email or REST API.

You can customize the subject and body of the email on any notification to whatever works for you. The email can include "macros" that will let you automatically inject on the email attributes of the item that triggered the notification: Name, Tittle, Owner, Deadline, Etc.

Typically in the case of deadlines you want users to click on the email, login in eramba and provid feedback to whatever item triggered the email.


Those that need to provide feedback will click on Comments & Attachments (you can control what clicks users can see or not making the system a lot simpler than by default) and provide you with some feedback. You will go back and forward until an agreement is reached.

Another use for the "Warning" notification is to let someone know when an item (Risk, Policy, Etc) status changes. This requires you to have some status created (either system or custom made by you). Status is another "Common Feature".

For example if a Control failed too many audits you can trigger a status and send that to the Control Owner. This notification can be in the form of an email or REST API.

Comments & Attachments

When a deadline or status change notification is triggered, is likely you will want some feedback. The Comments & Attachment notification is used to let anyone knows when a new comment has been attached to an item. This notification can be in the form of an email or REST API (to Slack, Etc).


When you want to send a report (Graphical or Filter) to someone regularly. For Example: Send a report to me every week with all the Controls used in ISO-27001 that are missing the last audit.

This requires you to have previously created a Graphical Report or Filter, these are also "Common Features" found on every module.



A special type of notification called "Awareness" will regularly email everyone involved on any given module about their relation with that item. For example you can email the Risk Stakeholder of every Risk every month to remind them about the Risk.

You want to be careful how you use this notification as it will of course send many emails (assuming you have many items), regularly and could become a  bit too much email noise.