BIC Process Control Processes
New Risk
Who is involved inside this process?
Despite all the other risk related processes, the New Risk process does not involve specific roles like the Risk Owner. Everyone who can see the tile New Risk inside the New processes view is able to register a new risk into the Risk Catalogue. Every risk created that way, will be shown as “Not approved” 
.
Which tasks are part of this process?
In the New Risk process, only the initial entry form needs to be completed. After submitting the form, the new risk is listed directly inside the Risk Catalogue.
The entry form contains some mandatory fields, so that the most important information about the risk is entered directly. Among other things, the Risk Owner and the Risk Category Responsible are recorded. An initial qualitative risk assessment specifying the Impact and Probability is also requested. The actual Risk Rating is determined automatically.
Note
Here you can see how the system calculates the corresponding rating according to certain business rules.
When and how is the Action Management process triggered?
After submitting the New Risk form, depending on the user inputs the system may start an Action Management.
The Action Management process is triggered when:
The Next Risk Assessment selected date is later than 30 days from the current date.
The Action Management process starts by informing that “The date for next risk assessment is too late”, so it requires the Risk Owner to take appropriate actions that will be reviewed again by higher-level roles.
Regardless of when and how the Action Management was triggered, the first task of this new process also contains a link to the corresponding risk and four fields whose content is predefined by business logic rules.
The entries below are the fields of the Action Management process that are prefilled with specific data:
Action Management field |
How is it prefilled? |
|---|---|
Responsible for Implementation |
Risk Owner |
Authority in Case of Escalation |
Risk Category Responsible |
Due date |
Today + 30 days |
Review due |
Today + 45 days |
Even if the above list of fields contains predefined content, their values can be adopted inside the Define action task.
Risk Assessment
Who is involved inside this process?
The users involved through this process are the Risk Owner and the Risk Category Responsible, considering this second one as a higher-level role that will review the values and dates previously selected by the first one. Both fields can be assigned to the same user or user group, but they can also be assigned to different users or user groups.
Here you can see how group tasks are handled.
Which tasks are part of this process?
This process consists of up two different tasks:
The primary Assess risk task
The secondary Review assessment task, which will be triggered based on predefined business rules
After the process is manually or automatically launched, the first task requires the Risk Owner to assess the corresponding risk:
If the Risk Owner just confirms the risk as it is again, the process is finished right after submitting the form.
If there are changes (different Risk Rating or Risk Response values, or risk rated as Obsolete) and there is an assigned Risk Category Responsible, the process moves to the second task in order to perform a re-assessment.
Note
After the end of a process where the risk is rated as Obsolete, the 
icon will be displayed next to it.
During the re-assessment task, the assigned user has to define the Result of Re-assessment by choosing between two different options:
I confirm the risk assessment: the values of the assessed risk are updated in the catalogue and can be visualized as part of the risk details view.
I reject the risk assessment for correction by the risk responsible: the values of the assessed risk are rejected and the process returns to the first task, which requires the Risk Owner to perform a new evaluation of the risk. Once this form is submitted, the Review assessment task is required again.
Hint
After updating the corresponding risk inside the Risk Catalogue, the system will also update it inside BIC Process Design if the risk was formerly imported by using the connector.
How is the risk rating calculated?
Once the Impact and Probability values are selected by the involved users, the system calculates the resulting Risk Rating by following certain business rules configured through a DMN (Decision Model and Notation) table.
Below you can find the default definition of the DMN table:
Probability |
Impact |
Risk Rating |
|---|---|---|
Very low |
Very low, Low |
Very low |
Very low |
Medium |
Low |
Very low |
High |
Medium |
Low |
Very low |
Very low |
Low |
Low |
Low |
Low |
Medium |
Low |
Low |
High |
Medium |
Medium |
Very low, Low |
Low |
Medium |
Medium |
Medium |
Medium |
High |
High |
High |
Very low, Low |
Medium |
High |
Medium, High |
High |
The Risk Assessment process also offers fields to maintain the Risk Assessment from an operational risk management perspective:
Impact (EUR)
Probability (%)
Risk Expectation (EUR).
These fields are optional and the field Risk Expectation (EUR) will be automatically calculated based on the inputs of the other two fields.
When and how is the Action Management process triggered?
After finishing the Risk Assessment process, depending on the user inputs the system may start an Action Management.
The Action Management process is triggered when:
The Risk Rating value is changed (increased or decreased).
The Risk Response value is changed.
The risk is rated as Obsolete.
The Action Management process starts by requiring the Risk Owner to take appropriate actions that will be reviewed again by higher-level roles.
Regardless of when and how the Action Management was triggered, the first task of this new process also contains a link to the corresponding risk and four fields whose content is predefined by business logic rules.
The entries below are the fields of the Action Management process that are prefilled with specific data:
Action Management field |
How is it prefilled? |
|---|---|
Responsible for Implementation |
Risk Owner |
Reviewer |
Risk Category Responsible |
Due date |
See table below |
Review due |
See table below |
Even if the above list of fields contains predefined content, their values can be adopted inside the Define action task.
The following table shows how the Due date and the Review due date are calculated:
Rule for calculation |
Due date |
Review due |
|---|---|---|
When Risk Rating is increased from Very low, Low or Medium to a higher value |
Today + 30 days |
Today + 45 days |
When Risk Rating is decreased from High, Medium or Low to a lower value |
Today + 90 days |
Today + 105 days |
When Risk Response is changed to Acceptance |
Today + 90 days |
Not maintained |
When Risk Response is changed to Transfer, Avoidance or Mitigation |
Today + 30 days |
Today + 45 days |
When the risk is rated as Obsolete |
Today + 30 days |
Today + 45 days |
Note
The first rule that matches will define the values for Due date and Review due for the Action Management process.
How is the “Next Risk Assessment” date calculated?
When a process is started automatically, BIC Process Control calculates the Next Risk Assessment based on the Interval for Risk Assessment. In this case, the corresponding risk is updated with the new Next Risk Assessment date. This will lead to a new risk version inside the History section.
When a process is manually started from the Risk Catalogue, it is counted as an additional instance on top of the automatically generated one.
Test of Completeness
Who is involved inside this process?
The user involved through this process is the Risk Owner. This field can be assigned to a single user or to a user group.
Which tasks are part of this process?
This process consists of the task Test the completeness of coverage of the risk by controls.
After the process is manually or automatically launched, the related task requires the Risk Owner to test if the risk is completely covered with controls.
In order to verify that, the Result of Test of Completeness field offers two possible options: Controls are complete or Controls are insufficient.
If the Risk Owner selects Controls are complete and the Risk Response is not Mitigation, the process is finished right after submitting the form.
Hint
After updating the corresponding risk inside the Risk Catalogue, the system will also update it inside BIC Process Design if the risk was formerly imported by using the connector.
When and how is the Action Management process triggered?
After finishing the Test of Completeness process, depending on the user selection the system may start an Action Management.
The Action Management process is triggered when:
The Result of Test of Completeness is Controls are complete and the Risk Response is Mitigation.
The Result of Test of Completeness is Controls are insufficient.
The Action Management process starts by requiring the Risk Owner to take appropriate actions that will be reviewed by higher-level roles.
Regardless of when and how the Action Management was triggered, the first task of this new process contains a link to the corresponding risk and five fields whose content is predefined by business logic rules.
The following table shows how these rules are applied to the Action Management process:
Action Management field |
How is it prefilled? |
|---|---|
Responsible for Implementation |
Risk Owner |
Reviewer |
Risk Category Responsible |
Authority in Case of Escalation |
Risk Category Responsible |
Due date |
Today + 30 days |
Review due |
Today + 45 days |
Even if the above list of fields contains predefined content, their values can be adopted inside the Define action task.
How is the “Next Test of Completeness” date calculated?
When a process is started automatically, BIC Process Control calculates the Next Test of Completeness based on the Interval for Test of Completeness. In this case, the corresponding risk is updated with the new Next Test of Completeness date. This will lead to a new risk version inside the “History” section.
When a process is manually started from the Risk Catalogue, it is counted as an additional instance on top of the automatically generated one.
New Control
Who is involved inside this process?
Despite all the other control related processes, the New Control process does not involve specific roles like the Control Owner. Everyone who can see the tile New Control inside the New processes view is able to register a new control into the Control Catalogue. Every control created that way, will be shown as “Not approved” .
Which tasks are part of this process?
In the New Control process, only the initial entry form needs to be completed. After submitting the form, the new control is listed directly inside the Control Catalogue.
The entry form contains some mandatory fields, so that the most important information about the control is entered directly. Among other things, the Control Owner and the Control Tester are recorded. Information on the Effect of Control, the Type of Performance and the Execution interval is also requested.
In order to complete the recording of the control, the new control must be assigned to a risk.
When and how is the Action Management process triggered?
After finishing the New Control process, depending on the user inputs the system may start an Action Management.
The Action Management process is triggered when:
The Next Test of Design selected date is later than 30 days from the current date.
The Action Management process starts by informing that “The date for next test of design is too late”, so it requires the Control Owner to take appropriate actions that will be reviewed again by higher-level roles.
Regardless of when and how the Action Management was triggered, the first task of this new process also contains a link to the corresponding control and four fields whose content is predefined by business logic rules.
The entries below are the fields of the Action Management process that are prefilled with specific data:
Action Management field |
How is it prefilled? |
|---|---|
Responsible for Implementation |
Control Owner |
Authority in Case of Escalation |
Risk Owner (of the associated risk) |
Due date |
Today + 30 days |
Review due |
Today + 45 days |
Even if the above list of fields contains predefined content, their values can be adopted inside the Define action task.
Test of Design
Who is involved inside this process?
The user responsible of this process is the Control Owner. This field can be assigned to a single user or to a user group during the creation of a new control.
Which tasks are part of this process?
This process consists of the task Test design of control.
After the process is manually or automatically launched, the related task requires the Control Owner to test the design of the selected control.
In order to verify that, the Result of Test of Design field offers two possible options: Inappropriate design of control or Appropriate design of control.
By selecting Appropriate design of control, the process is finished right after submitting the form and the control details are properly updated.
Below this field, there is a checkbox that can be used in order to Rate control as obsolete.
Note
After the end of a process where the control is rated as Obsolete, the 
icon will be displayed next to it.
If this checkbox is selected, only the field Comment on Result of Test of Design is mandatory. By unselecting it the original mandatory fields are mandatory again.
Hint
After updating the corresponding control inside the Control Catalogue, the system will also update it inside BIC Process Design if the control was formerly imported by using the connector.
When and how is the Action Management process triggered?
After finishing the Test of Design process, depending on the user selection the system may start an Action Management.
The Action Management process is triggered when:
The Result of Test of Design is Inappropriate design of control.
The control is rated as Obsolete. Also, in this particular case it is not needed to select the result of the test, and the system will not require a higher-level role to review this new rating.
The Action Management process starts by requiring the Control Owner to take actions for appropriate design of the control that will be reviewed by higher-level roles.
Regardless of when and how the Action Management was triggered, the first task of this new process contains a link to the corresponding risk and five predefined fields.
The following table shows how these rules are applied to the Action Management process:
Action Management field |
How is it prefilled? |
|---|---|
Responsible for Implementation |
Control Owner |
Reviewer |
Risk Owner |
Authority in Case of Escalation |
Risk Owner |
Due date |
Today + 30 days |
Review due |
Today + 45 days |
Even if the above list of fields contains predefined content, their values can be adopted inside the Define action task.
How is the “Next Test of Design” date calculated?
When a process is started automatically, BIC Process Control calculates the Next Test of Design based on the Interval for Test of Design. In this case, the corresponding control is updated with the new Next Test of Design date. This will lead to a new control version inside the History section.
When a process is manually started from the Control Catalogue, it is counted as an additional instance on top of the automatically generated one.
Test of Effectiveness of Controls
Who is involved inside this process?
The user responsible of this process is the Control Tester. This field can be assigned to a single user or to a user group during the creation of a new control.
Which tasks are part of this process?
This process consists of the task Test effectiveness of control.
After the test is manually or automatically launched, the related task requires the Control Tester to test the effectiveness of the corresponding control.
In order to verify that, the Result of Test of Effectiveness field offers three possible values: Control is not effective, Control is partly effective or Control is effective.
When selecting Control is effective, the process is finished right after submitting the form and the control details are updated.
Hint
After updating the corresponding control inside the Control Catalogue, the system will also update it inside BIC Process Design if the control was formerly imported by using the connector.
When and how is the Action Management process triggered?
After finishing the Test of Effectiveness of Controls process, depending on the user selection the system may start an Action Management.
The Action Management process is triggered when:
The Result of Test of Effectiveness is Control is not effective or Control is partly effective.
The Action Management process starts by requiring the Control Owner to take appropriate actions for the effectiveness of the control, that will be reviewed by higher-level roles.
Regardless of when and how the Action Management was triggered, the first task of this new process contains a link to the corresponding risk and five predefined fields.
The following table shows how these rules are applied to the Action Management process:
Action Management field |
How is it prefilled? |
|---|---|
Responsible for Implementation |
Control Owner |
Reviewer |
Control Tester |
Authority in Case of Escalation |
Risk Owner |
Due date |
|
Review due |
|
Even if the above list of fields contains predefined content, their values can be adopted inside the Define action task.
How is the “Next Test of Effectiveness” date calculated?
When a process is started automatically, BIC Process Control calculates the Next Test of Effectiveness based on the Interval for Test of Effectiveness. In this case, the corresponding control is updated with the new Next Test of Effectiveness date. This will lead to a new control version inside the History section.
When a process is manually started from the Control Catalogue, it is counted as an additional instance on top of the automatically generated one.
Performance of Controls
Who is involved inside this process?
The user responsible of this process is the Execution of Control. This field can be assigned to a single user or to a user group during the creation of a new control.
Which tasks are part of this process?
This process consists of the task Perform control.
After the process is manually or automatically launched, the related task requires the Execution of Control to test the performance of the corresponding control.
In order to verify that, the Result of Performance of Control field offers three possible options: Ok, Minor deviations or Major deviations.
By selecting Ok, the process is finished right after submitting the form and the control details are properly updated.
Hint
After updating the corresponding control inside the Control Catalogue, the system will also update it inside BIC Process Design if the control was formerly imported by using the connector.
When and how is the Action Management process triggered?
After finishing the Performance of Controls process, depending on the user selection the system may start an Action Management.
The Action Management process is triggered when:
The Result of Performance of Control is Minor deviations or Major deviations.
The Action Management process starts by requiring the Control Owner to take appropriate actions against deviations in the performance of the corresponding control, that will be reviewed by higher-level roles.
Regardless of when and how the Action Management was triggered, the first task of this new process contains a link to the corresponding risk and five predefined fields.
Action Management field |
How is it prefilled? |
|---|---|
Responsible for Implementation |
Control Owner |
Reviewer |
Control Tester |
Authority in Case of Escalation |
Risk Owner |
Due date |
|
Review due |
|
Even if the above list of fields contains predefined content, their values can be adopted inside the Define action task.
How is the “Next Performance of Control” date calculated?
When a process is started automatically, BIC Process Control calculates the Next Performance of Control based on the Execution Interval. In this case, the corresponding control is updated with the new Next Performance of Control date. This will lead to a new control version inside the History section.
When a process is manually started from the Control Catalogue, it is counted as an additional instance on top of the automatically generated one.
Action Management
Who is involved inside this process?
The roles involved through this process are: Responsible for Implementation, Reviewer and Authority in Case of Escalation.
These roles can be assigned to the same single user or user group, but also to different users or user groups.
The user or user group assigned as Reviewer or Authority in Case of Escalation must be different to the Responsible for Implementation.
Which tasks are part of this process?
Three tasks are part of this process:
Define action
Implement action
Review implementation of action
In addition to these three tasks, there is a Manage escalation of action task available, which will be triggered under specific circumstances.
The Define action task, as the first one of this process, must indicate the name of the Corrective Action and also its Priority (Low, Medium, High) and Type. The Responsabilities section inside this form indicates which users or user groups will be assigned as Responsible for Implementation, Reviewer and Authority in Case of Escalation. Regarding the dates, Due date and Review due fields are also part of this form.
The content and values for these fields must be completely entered by the user if the process was launched manually. If it was launched automatically, data inside some of them will be directly predefined by the system according certain rules.
Hint
You can find out more about this topic here.
The second task of this process is Implement action, which is assigned to the user previously selected as Responsible for Implementation.
During this task, the responsible user is required to select the current Status of Implementation. This field contains five possible values: Pending, Implemented, Duplicate, Invalid, and Obsolete. Also, the form requires a comment regarding the selected status.
Once this second task is submitted, the third task of the process is Review implementation of action, which is assigned to the Reviewer.
In the corresponding form, the Reviewer needs to decide the Measure approval. There are two possible results:
Approve implementation. This way, the process is finished right after submitting the form.
Reject implementation. This way, the process returns to the second task, which requires the Responsible for Implementation to perform again the implementation of the action.
The last task of this process is Manage escalation of action, which is assigned to the user or user group selected as Authority in Case of Escalation.
This task is automatically triggered when the Due date for implementation or the Review due date is reached.
When and how can the Action Management process be launched?
This process can be launched manually or automatically.
The process is started manually when:
The user creates a new Action Management process from the New processes section.
The user starts a new Action Management process from the context menu of already existing risks or controls inside the catalogues.
Hint
It is possible to manage who is allowed to start a specific type of process. See Processes administration.
The process may be started automatically as a result of the following processes:
When the process is started automatically, certain fields of the first Define action task will be already filled with predefined data: Responsible for Implementation, Reviewer, Authority in Case of Escalation, Due date and Review due.
Depending on the process which started the Action Management, the values for these fields can vary. For further details, please check the corresponding question When and how is the Action Management process triggered? for each process.
When and how a Manage escalation task is triggered?
A Manage escalation task is triggered when:
an Implement action task is active and the defined due date for implementation has passed.
an Review action task is active and the defined due date for the review has passed.
In both cases the escalation task will be assigned to the user / user group which is defined as Responsible in case of escalation.
What happens after finishing a Manage escalation task?
When a manage escalation task is finished, the next step inside the Action Management process depends on the input that was made during the escalation task.
One of the following steps can happen next:
- When there is no Implementation status set AND the Due date for implement the action is set to the future.
Then the process will create a Implement action task.
- When the field Measure approval is still empty, a Reviewer is defined AND review due date is in the future.
Then the process will create a Review action task.
In all other cases the Action Management process is finished.