Server Error
Server Error
Server Error
Server Error
Server Error
Server Error

Exception Management

Record and Manage your Risk, Compliance and Policy Exceptions lifecycle - long

  • Episodes7
  • Duration18m 5s
  • LanguagesEN
Episode 7

Reviewing Exceptions

How to review items in the module


After creating items in the module you will most likely need to track their progress and changes with the help of the people involved in them.

In this episode, we will explain how Exceptions are reviewed.

Comments & Attachments

Each Exception record has the option to include Comments and attachments that track down who wrote what and when. We use this functionality to track down interactions between the two key roles involved in an exception (Requester and GRC Team).

When you or the person giving you feedback click there they can write whatever they want, for example, "We are reviewing the Exception, we will let you know". You can then click there as well and reply back. In the end, a trail of conversations will be logged where "who", "wrote what" and "when" will be evident.

After all discussions take place you can then complete the review. Is of course important to remind you that accessing those menus is completely controlled by Access Lists, so you can remove the "Remove" function, etc to those that provide you with feedback.

Review Process

As mentioned before the review process is typically an interaction between two roles, the "GRC Contact" and the "Risk Review Contact". This interaction typically works in two ways:

  • Offline: the interactions take place between the two roles over email or in person and once they agree to something, the "GRC Contact" updates the review and attaches as evidence whatever discussion took place.
  • Online: both parties might talk offline, but their feedback goes into eramba as "Comments & Attachments" (in the offline mode only the GRC Contact uploads content to "Comments & Attachments").

The online mode:

The offline mode:

Record Update

There are two scenarios when an Exception needs to be reviewed:

  • The exception is no longer needed
  • The exception is still required and must (or not) be extended

The discussions that will take place in regard to these scenarios will ideally be documented using the process above (online or offline).

If the exception is no longer needed, then the following is required in eramba:

  • Set the status to "Closed"
  • Set the "Closure Date"

The associated items (Policies, Risks, Compliance Requirements) then would also be disassociated from the exception.

If the exception must be extended then the following actions should be performed:

  • Change the "Exception Deadline" to something new