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.
- Episode 1Introduction to the Exceptions Module7 mins left
- Episode 2Access Management & User Interface1 min left
- Episode 3Configuring the Exceptions Module1 min left
- Episode 4Exceptions Module Tabs0 mins left
- Episode 5Exceptions Module Associations1 min left
- Episode 6Creating an Exception2 mins left
- Episode 7Reviewing Exceptions1 min left
- Episode 8Reviewing Exceptions Using Notifications and Feedback5 mins left
- Episode 9Typical Filters: Exception Module2 mins left
- Episode 10Typical Reports: Exception Module1 min left
- Episode 11Typical Dynamic Statuses: Exception Module1 min left
- Episode 12Exception Module Implementation Guidance1 min left