User Responsibilities System

Nelson Kho

Overview

Even with a tightly configured risk management system, there always seems to be a lot of data that needs maintenance to ensure compliance and governance standards are met.

As RiskView allows for the distribution of data management responsibilities, this problem is reduced by being shared amongst all the parties involved in the process. But we have also been listening and working on ways to make this process more efficient, measurable, and report-able.

That’s why in RiskView 7.8, we are introducing a data governance framework called Responsibilities.

NOTE: Responsibilities is completely Administrator controlled. If you don’t want it enabled, then there’s nothing you need to do.

Assuming you do want it enabled, Responsibilities takes a cascading approach to allocating any issues found to the person closest to the issue.

What this image is trying to show is that where the System Administrator distributes ownership, then the next level owner will be given the issue to resolve. Conversely, if the ownership is not distributed, then it all falls back on the System Admin.

Responsibilities is a collection of queries that flag issues where specific system policies are not being complied with.

Each Responsibility tests a single condition. When the condition is being met, no issue is raised. When the condition is not met, then an issue is raised with the person closest to the issue in the ownership tree.

RiskView 7.8 includes a reworked In-Tray that shows all the issues related to the currently logged-in User.

In-Tray

The In-Tray shows all issues initially, but they can be filtered by the category of issue by clicking on the left hand column.

For each issue, a detailed description is provided to allow the User to do something immediately.

When clicking on an item in the In-Tray list, Users will be able to view/edit the item directly. Users also have the ability to include data from child registers (for clients with multiple registers).

The “In-Tray Summary” dashlet in RiskView has been updated to show tiles for each issue category and will change depending on the responsibilities of the logged-in User.

The System Administrator also has the option to enable/disable certain responsibilities within the system (as some of the components might not be used in the system).

To do that:

  • Navigate to the Configuration Editor
  • Proceed to the Register Policies tab and select Responsibilities
  • Each responsibility and its description are listed here and the System Administrator can then disable/enable the responsibilities

Configuration editor


Categories

System Integrity

The responsibility in this category ensures that the System Administrator has the proper email address and not the default.

The responsibility is delegated to System Administrator.

Responsibility

Focus Area Conditions Responsibility Example from In Tray
System Admin Requires Valid Email Address The system administrator’s email address must be valid (i.e. it must be changed from the default email address or it cannot be empty). System Administrator. System Admin Requires Valid Email Address

Register Integrity

The responsibilities in this category mainly deal with the data integrity within the Register (e.g. no Location or Department data within the Register when it is required in the Action form).

Some of the responsibilities listed are delegated to System Administrator, otherwise they will be delegated by the System Administrator to Register Owners.

Responsibilities

Focus Area Conditions Responsibility Example from In Tray
Register Requires Owner The register must have an owner if it has an active bowtie and the register is active. System Administrator. Register Requires Owner
Register Requires Locations The register that contains active bowties must have at least one active Location when the following settings are enabled in the Configuration:

  • Risk Location Show
  • Actions Locations Show
  • Actions Locations Require
Register Owner, if no Register Owner is defined then this will be passed on to the System Administrator. Register Requires Locations
Register Requires Departments The register that contains active bowties must have at least one active Department when the following settings are enabled in the Configuration:

  • Risk Department Show
  • Actions Departments Show
  • Action Departments Require
Register Owner, if no Register Owner is defined then this will be passed on to the System Administrator. Register Requires Departments
Register Requires Roles The register that contains active bowties must have at least one active Role when the following settings are enabled in the Configuration:

  • Action Owner Role
  • Action Responsible Role
  • Action Verifier Role
  • Audit Owner Role
  • Business Unit Owner Role
  • Risk Owner Role
  • Risk Control Owner Role
  • HAZID Study Owner Role
Register Owner, if no Register Owner is defined then this will be passed on to the System Administrator. Register Requires Roles
Register Requires Activities The register that contains active bowties must have at least one active Activity when Risk Activity Show is enabled in the Configuration. Register Owner, if no Register Owner is defined then this will be passed on to the System Administrator. Register Requires Activities

Register Data Hygiene

The responsibilities in this category mainly deals with the data hygiene within the Register.

The responsibilities are delegated by the Register Owners.

Responsibilities

Focus Area Conditions Responsibility Example from In Tray
Risk Scenario Requires Owner Every active bowtie must have an active Owner when the following settings are enabled in the Configuration:

  • Risk Owner Show
  • Risk Owner Required
Register Owner, if no Register Owner is defined then this will be passed on to the System Administrator. Risk Scenario Requires Owner
Risk Scenario Requires Major Accident Event (MAE) MAE must be attached to an active bowtie when the following settings are enabled in the Configuration:

  • MAE Risk Show
  • MAE Risk Required
Bowtie Owner, if no Bowtie Owner is defined then this will be passed on to the Register Owner. Risk Scenario Requires Major Accident Event (MAE)
Risk Scenario Requires Location Location must be attached to an active bowtie when Risk Location Show is enabled in the Configuration. Bowtie Owner, if no Bowtie Owner is defined then this will be passed on to the Register Owner. Risk Scenario Requires Location
Risk Scenario Requires Department Department must be attached to an active bowtie when Risk Department Show is enabled in the Configuration. Bowtie Owner, if no Bowtie Owner is defined then this will be passed on to the Register Owner. Risk Scenario Requires Department
Risk Cause Requires Description An active Cause must have the description field populated in an active bowtie. Bowtie Owner, if no Bowtie Owner is defined then this will be passed on to the Register Owner. Risk Cause Requires Description

Compliance

The responsibilities in this category are mainly associated with how well the bowties and critical controls are maintained and reviewed.

The responsibilities are delegated to the Bowtie Owners.

Responsibilities

Focus Area Conditions Responsibility Example from In Tray
Risk Scenario Requires Review Bowtie Review Date must be specified in an active bowtie when the following settings are enabled in the Configuration:

  • Module Analysis
  • Risks Days Enabled

Bowtie Review Date must be lesser than what is defined in Risks Days Between Audits.

Bowtie Owner, if no Bowtie Owner is defined then this will be passed on to the Register Owner. Risk Scenario Requires Review
Critical Risk Control Requires Non Default Control Effectiveness Critical Risk Control in an active bowtie must have a non-default Control Effectiveness when it meets the following requirements:

  • MAE Risk Show option is enabled in the Configuration
  • The Risk Control to be a Critical Control and has a status score greater than 0
  • The Risk Control is linked to an active Risk Scenario
  • The related Risk Scenario is in Qualitative Mode and is linked to an active MAE
Risk Control Owner, if no Risk Control Owner is defined then this will be passed on to the Bowtie Owner. If none of those two are available, then it will be the Register Owner. Critical Risk Control Requires Non Default Control Effectiveness
Critical Risk Control Requires Review

Critical Risk Control without Base Control in an active bowtie must be reviewed at a defined interval.

Last Verification Date must be lesser than what is defined in Control Critical Days Between Audits.

Risk Control Owner, if no Risk Control Owner is defined then this will be passed on to the Bowtie Owner. If none of those two are available, then it will be the Register Owner. Critical Risk Control Requires Review
Base Control Requires Review

Base Control must be reviewed at a defined interval.

Last Review Date must be lesser than what is defined in Control Non Critical Days Between Audits.

Base Control Owner, if no Base Control Owner is defined then this will be passed on to the System Administrator. Base Control Requires Review

Ownership

The responsibilities in this category will show items that are assigned to the user.

Responsibilities

Focus

Area

Conditions Responsibility Example from In Tray
Actions Related to User Action assigned to the user will be listed (either as Originator, Implementer or Verifier). The status of the Action has to be one of the following:

  • Pending
  • In Progress
  • Awaiting Verification
  • Sending to External System
Action Owners (Originator, Implementer or Verifier), if no Action Owners are defined then this will be passed on to the Register Owner.  Actions Related to User
Lessons Learned Related to User Lessons Learned assigned to the user will be listed. The status of the Lessons Learned has to be one of the following:

  • Pending
  • Initial Review Process
  • Final Review Process
  • Approved for Reuse
Lessons Learned Owner, if no Lessons Learned Owner is defined then this will be passed on to the Register Owner. Lessons Learned Related to User
Verification Worksheets Related to User Verification Worksheet assigned to the user will be listed. The status of the Verification Worksheet has to be one of the following:

  • Pending
  • In Progress
Verification Worksheet Owner, if no Verification Worksheet Owner is defined then this will be passed on to the Register Owner. Verification Worksheets Related to User
Risk Studies Related to User Active Risk Study assigned to the user will be listed. Risk Study Owner, if no Risk Study Owner is defined then this will be passed on to the Register Owner. Risk Studies Related to User
Base Controls Related to User Active Base Control assigned to the user will be listed. Base Control Owner, if no Base Control Owner is defined then this will be passed on to the System Administrator. Base Controls Related to User
Projects Related to User Active Project assigned to the user will be listed. Project Owner, if no Project Owner is defined then this will be passed on to the Register Owner. Projects Related to User

Wrap-Up

RiskView 7.8 has a lot of new features but this is one we think will go a long way to helping RiskView become more “self”-maintaining by sharing the governance load.

We are very keen to hear your opinions and welcome any feedback. Do you think you’ll use it? Are the Responsibilities identified appropriate? Would you like to see any specific new Responsibilities?

We look forward to your input.

Is it helpful to you?

Total Votes: 1

1
0