Exception Management

Introduction

In this episode, we will explain how Exceptions are created. The process is the same for all three types of Exceptions.

• Policy Exceptions
• Risk Exceptions
• Compliance Exceptions

You can create exceptions individually or use CSV Imports to create more than one at the same time.

Title / Description

Is always important to describe at least an exception title, something that explains in simple words what the exception is all about.

If you need a field to associate this exception with some other system (like a Change Request or URL) we recommend using Custom Fields.

GRC Contact

The GRC Contact role is always used to link the GRC team or individual who has approved this exception.

Exception Requester

This role is used to assign the team or individual that has requested or/and requires this exception.

Status

The status field helps you to quickly identify which exceptions are still applicable (in use) and which ones are not. By default, eramba will trigger different labels for each one of these statuses.

You can use the dynamic status feature to alter the conditions based on which these labels trigger or not.

Expire & Close Dates

Exceptions have two key dates, when they expire and when the status is changed to "Closed", when they are closed.

Associations

Depending on which exception module you are working you can link:

• One or more Risks (any type) to a Risk exception. This is done from the Risk module, not from the exception module.
• One or more compliance requirements items to a Compliance Exception. This is done from the Compliance Module or from the Compliance Exception module.
• One or more items from the Policy module to the Policy Exception. This can be done from the Policy module or from the Policy Exception module.

The screenshot below shows how compliance packages are shown for any compliance exception. A similar approach can be done on the other Exception modules.