Who is this article for?

Users who need to understand Departments.

No special access or permissions are required.

Incidents (also commonly known as Loss Events) are a key component of Operational Risk Management (ORM) and more generally Enterprise Risk Management (ERM), allowing you to track and manage risk events independently of audits.

1. Understanding incident management features

Incident Management provides comprehensive functionality for tracking and managing risk events:

• Raise Incidents independently of audits
• Define Incident scope in relation to the Universe, optionally linking to specific Entity Risks (Set Scope and Set Risks)
• Classify each Incident (for example, Actual Loss, Near Miss) and capture monetary values
• Add further documentation via Attachments, Notes and Cross References
• Manage the Incident life cycle (for example, Draft, Live, Complete, Approved and Closed) and ascribe ownership and interested parties
• Define corrective Incident Actions and manage their subsequent execution as part of centralised Action Tracking
• Flexible role permissions control who can raise, read and manage Incidents
• Analysis charts and Incident Tracker

Incidents exist within your Universe and are managed independently of Audits; they do not form a direct part of any audit work and they cannot be checked out for offline working.

2. Working with incident attributes

The attributes are grouped into logical sections following a Definition, Management and Execution pattern.

2.1 Definition

This contains the details about the Incident:

• Reference - an auto-generated globally-unique reference number for the Incident
• Title - a short, descriptive title for the Incident
• Date - date raised
• Scope - the Entity/Process cell(s) affected by the Incident. This may cut across multiple Entities and is therefore akin to the Audit Scope behaviour. (Retired Entity Processes will not be shown)
• Description - a description of the Incident. Rich-text to support full formatting
• Category - a single-select segmentation allowing additional optional categorisation of the Incident for analysis purposes
• Type - a single-select segmentation that indicates the nature of the incident, such as Near Miss and Loss
• Severity - a single-select segmentation describing either the severity or urgency with which the Incident needs to be addressed. For example, High, Medium, Low or Immediate, three to six months

2.2 Management

This section contains details of who is assigned to manage the Incident; separate from the Definition because the person who originally raises the Incident may not be responsible for determining its ownership or managing its progress:

• Owner - the Person ultimately responsible for the management of the Incident
• Interested Parties - additional Person(s) to be kept informed of the progress of the Incident
• Departments - a multi-select segmentation
• Incident State - set the Incident to Draft/Open/Completed/Approved and Closed

2.3 Execution

• Value - a numeric value field of the total monetary amount associated with the Incident
• Outcome - a single-select segmentation indicating the ultimate outcome of the Incident, for example, Insurance Claim, Legal Action
• Outcome Comments - rich text format for the entry of detailed comments describing the final outcome of the Incident
• Cross References - the term Cross Reference is analogous to a Hyperlink where you are able to create a link to a record within the system that is of related interest

3. Managing incident actions

Incidents can have multiple Standalone Actions attached to track corrective measures and their execution.

4. Linking entity risks to incidents

Use the Link To functionality to tie Entity Risks (as long as it is Live) with the Incident.

A summary of Entity Risks that have been Set with the Incident can be shown on the data grid. This pop up window allows you to navigate to the specific Entity Risk by simply clicking on it with your mouse.

5. Understanding incident relationships

Incidents can be associated with multiple Entity/Process cells; therefore they are not contained within any single Entity.

They have the following relationships with other items within Pentana:

• An Incident may be entirely unlinked initially to entity/process cells, and linked after investigation
• Risks - an Incident may be optionally linked to multiple Entity Risks, but restricted to those within its linked Entity Process scope
• Actions - an Incident may have multiple Standalone Actions attached
• Attachments - an Incident may have multiple File Attachments
• Cross-References - an Incident may have multiple Cross-references
• Reviews - an Incident may have multiple Reviews
• Notes - an Incident may have multiple Notes