Who is this article for?

Users who need to understand Incident lifecycle.

No special access or permissions are required.

The Incident lifecycle in Ideagen Internal Audit (Aura) follows a structured progression from creation through to closure, with similarities to the Audit lifecycle but with key differences in planning and execution.

1. Understanding the Incident lifecycle stages

The Incident lifecycle progresses through distinct states that provide an overall structure for managing incidents from creation to closure:

• Draft
• Open, Complete, Approved
• Closed

Each Incident starts in Draft form and includes management and execution of work that is Completed, Reviewed and Approved, before eventually being Closed once its Actions have been dealt with.

2. Recognising key differences from Audits

Unlike Audits, Incidents have several distinguishing characteristics:

• Are not planned
• Can be identified (created) by a wider range of people, including those in the business
• Are not broken out into programmes of Work Plans/Steps, ORCTs or Questionnaires
• Do not need to be checked out for offline working

3. Understanding Incident visibility

An Incident will be visible to:

• Its Owner
• Anyone with permission to read All Incidents
• Anyone with permission to read Incidents within their assigned Entity Process scope

4. Managing Incident execution

The execution of an Incident is managed via Completion and Approval sign offs, with rules comparable to those for objects within an Audit work lifecycle:

• When an Incident is Open, its properties are fully editable
• When an Incident is Complete, its Definition attributes become read-only
• When an Incident is Approved, its Management and Execution attributes (except Action completion) become read-only

An Incident could also have multiple Reviews in a similar fashion to the Audit work.

5. Closing an Incident

When management are satisfied that an Incident has been fully documented and executed, the Incident can be eventually Closed.

Note: An Incident cannot be Closed until all its Actions (if any) are Approved. A Closed Incident cannot be deleted.

6. Working with Standalone (Entity) Actions

To support the full lifecycle management of an Incident, it is possible to create and execute Actions against Incidents, independently of Audits. Actions can also be raised against Entity ORCs, covered by the concepts of Entity Actions.

Entity Actions have the same general attributes as (Audit) Actions, except that they do not require parent Findings and link directly to other objects in the Entity as appropriate.

Entity Actions may be attached to an:

• Incident
• Entity
• Entity Objective
• Entity Risk
• Entity Control

Note: Entity Actions must attach to one Entity/Process cell, in the same way as (Audit) Actions. Entity Actions will be tracked, executed and updated in the same way as (Audit) Actions, using the same existing user interfaces.