Exception Management

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

  • Episodes12
  • Duration23m 40s
  • LanguagesEN
Episode 1

Introduction to the Exceptions Module

Quick introduction to the module key capabilities

The Exception module allows you to record and manage three types of Exceptions: Risk, Compliance, and Policy. Each has its own exception module, and while they work almost exactly the same way, they are used in different scenarios:  

  • Risk Exceptions: when the treatment of a Risk includes a decision that no one wants to take, but there is no other option. Typically this is used when a Risk is accepted. Risk exceptions are linked to all three Risk modules in eramba.
  • Compliance Exceptions: when a compliance requirement is not applicable to you. 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.
  • 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). Policy Exceptions are linked to documents on the Policy module.

Each exception type has its own module:

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

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 a single role called “Requester,” which is typically the person or group that requested the exception.


If you do not like these titles, you can use customisations to change them to whatever name you prefer. 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 will use extensive configurable notifications (that can trigger emails or REST APIs) that will trigger in x amount of days before and after the expected expiration date, or whenever someone writes a comment or attachment.
 


Like any other module in eramba, powerful filters will allow you to query the system in literally thousands of different ways (e.g., give me all expired policy exceptions, give me all exceptions used in PCI-DSS, etc.).


Filters can be saved and emailed to you automatically at regular intervals in PDF or CSV format, so you do not have to log in to eramba to know what work is ahead of you.

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 own reports with a report builder based on widgets that you drag and drop into a template. You can use text, tables, filters, and charts that we ship with.

 

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

 

You will want to flag items based on your own 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 we ship with hundreds of them preconfigured for you.


But 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 exceptions. You can optionally trigger emails and REST APIs, too. 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.


Eramba uses web forms to create things, and these forms have been preset to you. The good news is that eramba ships with custom fields on every module, so 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.