Exception Management

The Exception module allows you to record and manage three types of Exceptions:

• Risk
• Compliance
• Policy

Each has its exception module and, while they work almost the same way, they are used in different scenarios:  

• Risk Exceptions: when the discussion between the Risk Originator and the GRC team leads to a situation where no one is willing to deal with the risk and the preferred course of action is to leave it as is.
• Compliance Exceptions: when a compliance requirement does not apply to your organisation. For example, if you are doing PCI-DSS and you are not a “Service Provider” many requirements do not apply to you so you can link them to a Compliance Exception. In ISO they are sometimes called "justifications for exclusions".
• Policy Exceptions: when someone needs to breach a policy, procedure, or standard (e.g. if a software developer needs to access a production database even when the policy clearly states this is not possible).

Each exception type has its module:

• Risk Exceptions: under Risk Management / Risk Exceptions.
• Compliance Exceptions: under Compliance Management / Compliance Exceptions.
• Policy Exceptions: under Control Catalog / Policy Exceptions.

You will easily see how many Risks, Compliance Requirements and Policies are associated with each Exception type directly on the filters:

Exceptions will have a deadline and a status, “Open” and “Closed.” The idea is you can track exceptions until their deadline and close or keep them open depending on whether they are still applicable or not.

• Open exceptions with an “Expiration Date” in the past will receive an “Expired” status.
• Open exceptions with an “Expiration Date” in the future will receive an “OK” status.
• Closed exceptions with an “Expiration Date” in the past or future will receive an “OK” status. They will also require a “Closure Date.”

Exceptions have two associated roles:

• GRC Contact: the team that manages GRC and has an interest in this exception to be documented
• Exception Requester: the person who approved the decision to create the exception

If you do not like these titles you can use customisations to change them to whatever name you prefer, you can create additional roles as needed (approver, etc). Customisations allow you to rename, add, hide, and move around fields and tabs in any form and any module.

Like any other module in eramba, each exception record supports comments and attachments that allow you to record all review interactions (including approvals) by users, making email discussions unnecessary.

You can use notifications that trigger several days before or after the expected expiration date, or whenever someone writes a comment or attachment. 

The notification can be set to send an email or trigger an API call. These notifications will allow you to reach out to the Exception Requester role to revalidate the exception or notify them when something changes.

Like any other module in eramba powerful filters allow you to query the system in thousands of different ways (e.g. display all expired policy exceptions, display all exceptions used in PCI-DSS, Display exceptions which are about to expire, etc.).

Filters can be saved and emailed to users automatically at regular intervals in PDF or CSV format.  This way users do not have to log in to eramba to know what work is due.

Reports also are available as charts. These are shipped with standard reports and let you know visually what is going on. 

You can create your reports with a report builder based on widgets that you drag and drop into a template. Reports are made of elements such as text, tables, filters, and charts.

The result will be a graphical report with your desired data. These reports can also be sent by email in PDF format as often as you want so you don't have to log in to the system.

Exceptions can be flagged with statuses based on your conditions:

• when an exception expires
• when an exception is missing evidence
• when an exception has no policy
• whether a risk or compliance requirement is linked, etc.

We use statuses across all modules to highlight these flags and there are hundreds of them preconfigured for you.

You can also create your own statuses based on your own conditions and, again, you have access to thousands of possibilities with the status configuration tool.

Every time a status matches (or fails to match) your conditions, a label will be applied to the exception item. You can optionally trigger emails and REST APIs.

For example, you can notify the exception requester when the policy-associated exceptions expire. The options are endless and it is really up to you what level of complexity you wish to use.

The web forms used to create these things in eramba can be customised using the custom fields option available in every module.  You can add, hide, rename and move around fields on the form in almost any way you want.

 

A user-friendly interface lets you do all of the work without needing to know how to code software.