About the Default Risk Workflow
You can use the seeded Default Risk Workflow to track risks from the time they are identified to the time they are closed. Below you'll find information on each of the default risk workflow stages.
Workflow Stages
Identified
The workflow begins once a risk has been identified and requires a review.
Evaluation
In the Evaluation stage, the scoring and quantification is set based on the level of risk observed by the business. If a risk was identified by risk-flagging rules within an assessment, the scoring and quantification details are pre-filled.
The risk approver chooses to treat, reduce, or reject the risk based on the business' risk appetite. If no treatment is necessary, the approver can advance the workflow to the Monitoring stage and select an outcome. If the approver decides to treat the risk, they will create a treatment plan that includes completing specific tasks, assigning a risk owner, and adding controls to mitigate the risk. The approver can add additional owners as needed and the owners will receive a notification.
Treatment
Once a risk advances to the Treatment stage, an email is generated to the risk owner. The email notifies the risk owner that they have been assigned a risk and includes a link to the assigned risk. Once a risk advances to the treatment phase, all of the risk task assignees are sent their assigned tasks and a link in bulk.
In the Treatment stage, the risk is actively mitigated by the risk owner. During this time, tasks are completed, control statuses are updated, and the treatment plan is executed. The risk owners have the ability to edit the custom risk attribute fields, treatment field, and category field.
The risk owner does not have the ability to edit the following system fields: deadline, treatment plan, description, reminder, risk owner, risk approver, risk template (set upon creation of the risk; not editable by risk approver or owner), source (set upon creation of the risk; not editable by risk approver or owner), inherent risk level, residual risk level, target risk level, vulnerability, and threat.
After accessing the risk, the risk owner can record notes regarding the treatment in the Treatment field and can either Submit the treatment or Request exception from the approver. The Submit button only appears for the Default Risk Workflow, if the Default Risk Workflow is cloned, the Review button will appear. For more information, see Managing Risk Exceptions.
At this point, the system deadline and reminder field will begin evaluating. The deadline will be for the risk approver to respond to the treatment plan or send back the exception. The treatment status is updated using the system workflow using the statuses in the table below, and the risk now becomes view only for the risk owner.
|
Treatment Status |
Description |
|---|---|
|
In Progress |
The risk owner is actively working on a risk. They can submit a treatment to the risk approver or request an exception.
Note:
In the Default Risk Workflow, Risk Owners can access assigned risks only while it is in the Treatment - In Progress stage. When the risk moves to any other stage, Risk Owners lose access to the Risk details screen. In custom workflows, Risk Owners retain access to assigned risks regardless of the workflow stage. If access appears intermittent, verify the current workflow stage. To grant Risk Owners continuous access to assigned risks in the Default Risk Workflow, enable Notify risk owners when they're added to risks in Global Settings. |
|
Exception Requested |
The risk owner requests an exception. The risk is closed in the chosen state and will not be mitigated further. The risk approver can grant the exception or send the risk back to the risk owner. Sending the plan back to the risk owner will reset the treatment status to In Progress. |
|
Under Review |
A treatment plan is submitted by the risk owner and is awaiting review by the risk approver. The risk approver can approve the treatment plan or send the plan back to the risk owner. Approving the risk will move the risk to the Monitoring stage. Sending the plan back to the risk owner will reset the treatment status to In Progress. |
|
Exception Granted |
The risk approver has granted the exception requested by the risk owner. The risk is closed in the chosen state and will not be mitigated further. |
|
Approved |
The risk owner completes the treatment plan, and the plan is approved by the risk approver. The risk is mitigated and remains in the monitoring state. |
The risk approver must complete one of the following actions by the system deadline:
-
Click the Approve button to respond to the treatment plan, close the risk, and move the risk to the monitoring phase. This button only appears for the Default Risk Workflow, if the Default Risk Workflow is cloned, the Advance button will appear.
-
Click the Grant an Exception button to accept the exception, close the risk, and move the risk to the monitoring phase.
-
Click the Send Back button to send the exception back to the risk owner for them to update their treatment and resubmit for approval.
Monitoring
During the Monitoring stage, the risk is in a closed state. The risk approver designates a residual risk score, which signifies that the treatment has been applied, and the risk becomes view only until reopened. In this stage, an outcome is selected, and the remaining risk level can be set based on the mitigation activities completed. Although the risk is not actively being worked on, it is being monitored. A risk approver can select an outcome from the Result options listed below.
|
Result |
Description |
|---|---|
|
Accepted |
The risk level or score is at or below your risk appetite and no treatment is required. |
|
Avoided |
The risk was avoided by changing the processing activity, asset, or vendor so that the risk is no longer relevant. You can also develop an alternate strategy to avoid the risk. |
|
Ignored |
A risk is identified but is being ignored due to a lack of understanding or funding. |
|
Reduced |
The risk completed a defined treatment process to reduce the impact or probability of a risk event occurring. |
|
Rejected |
The processing activity, asset, or vendor the risk was related to was deemed too risky to continue and is rejected. The risk is not deleted for audit purposes. |
|
Transferred |
The risk is transferred to a third-party (insurance) to reduce the impact of the risk. |