Sample workflows in GRC Workflow

You can use the sample workflows as delivered or modify them to meet your requirements. They can also be used as templates and learning tools for your own workflows.

The sample workflows are enabled in fresh installations.

Action Item Approval workflow

When an action item is created, the Action Item Approval workflow starts automatically. An email is sent to the Action Item Assignee informing them that an action item is assigned to them. The due date for the task is set to 7 days prior to the action item’s Due Date. When an action item is complete, the assignee selects Actions > Submit for Approval. The workflow then does the following actions:

  • Copies the value in the Issue Owner field of the parent issue to the action item’s Issue Owner for Approval field.
  • Sets the action item’s Status field to Awaiting Approval.
  • Sends an email to the Issue Owner informing them that an action item is waiting for their approval.

The Issue Owner reviews the action item, and then approves or rejects the closure of the Issue. The due date for the task is set to the action item’s Due Date.

If the Issue Owner selects Actions > Approve, the workflow completes the following actions:

  • Sets the Status field to Closed.
  • Sets the Approve Reject field to Approve.
  • Sets the Actual Completion Date to today's date.

If the Issue Owner selects Actions > Reject, the task is re-assigned to the Action Assignee. The workflow completes the following actions:

  • Sets the Status field to Open.
  • Sets the Approve Reject field to Reject.
Figure 1. The Action Item example workflow
A graphic of the workflow is shown.

Finding workflow

The Finding workflow uses the Finding System Task view and depends upon the out-of-the-box schema for Finding and related object types.

In this workflow, note the following key elements:
  • The cancellation path

    If a stage is declined, the workflow returns to the Finding Preparation stage. In your own workflow, you might choose this route or choose to go back to the immediately preceding stages. Plan the paths through the workflow in both a forward and backward direction.

  • Task overrides

    The task overrides for each stage define the Key Fields that are listed. The user guidance text is from the Task View itself. With this method, the Key Fields change with each stage and are specific to a stage.

Figure 2. Finding workflow
The finding example workflow with stages and actions
Figure 3. The specification for the Finding workflow
A flow diagram of the Finding workflow, from finding preparation to closure.

Incident workflow

The Incident workflow moves an incident through an investigation and approval process.

When an incident is created, the Incident workflow starts automatically. The workflow sets an owner for each stage (primary owner, approver, and reviewer). It sets the due date based on discovery date and incident criticality.

Figure 4. Incident workflow
A flow diagram of the Incident workflow, from start and in progress to closure.

Issue review workflow

In an Issue Management and Remediation (IMR) framework, you can effectively document, monitor, remediate, and audit issues.

Issues are items that are identified against the documented framework and are deemed to negatively affect the ability to accurately manage and report risk. In its lifecycle, an issue can have one of two states: Open or Closed.

When an issue is created, the Issue Review workflow starts automatically. The workflow sets the Status of the issue to Open and the Original Due Date to the due date that was entered when the issue was created. An email is sent to the Issue Owner, informing them that an issue is assigned to them. The due date for the task is set to 15 days prior to the issue’s Due Date.

To resolve the issue, the Issue Owner establishes and records the appropriate actions.

Figure 5. Issue Review workflow
The issue review example workflow with stages and actions

The Issue Owner can request a due date extension at any time during the issue lifecycle by setting the Requested Due Date and selecting Actions > Request due date change. The Issue Approver is notified of this request via email. The approver can approve or reject the request. If approved, the issue’s Due Date is set to the requested due date.

The Issue Owner can submit the issue for review by selecting Actions > Submit for review. The workflow performs the following validations:

  • All action items under the issue are closed.
  • The Issue Conclusion field is populated.
  • The Issue Type field is populated.

If any of the validations fails, the workflow prevents the Issue Owner from submitting the issue for review. If all the validations pass, the Issue Approver is notified of the request via email. This task due date is set to the issue’s Due Date. If rejected, the Issue Owner is notified of the rejection via email. The Issue Owner can make updates and then re-submit the issue for review. If the issue is approved, the issue’s Status is set to Closed.

The issue can be re-opened by starting the Issue Review workflow.

Loss Event Review workflow

The Loss Event workflow is similar to the configurable lifecycle for Loss Events.

In this workflow, take note of the following elements:
  • Different paths based on an amount value

    The workflow provides different levels of approval (approval level 1 and approval level 2) based on the gross loss value of the loss event.

  • Use of preference objects

    Approval level 1 and approval level 2 are retrieved from the Preference object. There are different approvers based on the division where the loss event occurred. Study this example if you want to learn more about how to implement a Preference object in workflows.

Figure 7. Loss Event workflow
The loss event example workflow with stages and actions

Questionnaire Assessment workflow

The Questionnaire Assessment workflow moves a questionnaire assessment through the information gathering, review, and approval stages.

Questionnaire assessment workflow with stages and actions.

Workpaper workflow

The Workpaper workflow uses the Workpaper System Task view and depends upon the out-of-the-box schema for Workpaper and related object types.

There are multiple types of Workpapers, for example Notification Letters and Test Evidence. However, the sample workflow is high level and not defined for one specific type. In the Workpaper workflow you create, you will likely define it for a specific type of Workpaper, in which case, you can choose to have separate workflows for each type or one workflow with separate branches with conditions that specify the type.

In this workflow, take note of the following elements:
  • Who can view the Actions button

    The final two forward actions, Send for Review and Approve and Complete, are restricted to specific users, the preparer and the reviewer, respectively. These actions are displayed only to them. For all other users, there is no action on the Actions button. When you encounter a situation like this, you can add an explanation to the user guidance for the stage that explains why there is no option on the Actions button.

Figure 8. Workpaper workflow
The workpaper example workflow with stages and actions
Figure 9. The specification for the Workpaper workflow
A flow diagram of the Workpaper workflow, from planning to workpaper completion.

BCM workflows

IBM OpenPages Business Continuity Management includes the following sample workflows:

Business Continuity Plan Review and Approval Process

This workflow allows the user to start the review and approval process for a new or published Business Continuity Plan (BC Plan).

For a new BC Plan, the workflow guides the process through the in progress, in review and approval stages. The author, reviewer, and approver are required fields to advance the workflow. Upon completion of the process, the workflow sets the next review date to 365 days and the status to published.

For a published BC Plan, the user has two options:

  • Renew the current BC Plan without making changes to the published version

    If this option is selected, a comment is required by the reviewer and the workflow sets the next review date to 365 days. The workflow advances the process to require only an approval.

  • Revise the published BC Plan

    If this option is selected, the workflow “locks” the current BC Plan, makes a copy of the plan, and sets the status of the copied plan to draft.

    The copied draft version of the plan moves through the review and approval process of the workflow. Upon completion, the workflow sets the plan status to “published”, increments the version number, and sets the next review date to 365 days. The status of the previously published plan is set to archived.

Note: The following child associations that were present on the previous (“locked”) BC Plan also appear on the new version of the BC Plan: BCTest Plan, Teams, and Business Impact Analysis (BIA). All parent associations, with the exception of BC Events, are preserved for the new BC Plan.
Figure 10. Business Continuity Plan Review and Approval Process workflow
The Workflow Editor shows the stages in the workflow: Start, In Progress, In Review, Approval, and End.
Business Impact Analysis to Determine Critical Processes
This workflow moves the Business Impact Analysis (BIA) through a review and approval process. A calculation on the BIA object is required to move it to the approval phase. After approval, two of the resulting values of the calculation, Impact Tier and Maximum Acceptable Outage, are saved on the Process parent of the BIA object.
Figure 11. Business Impact Analysis to Determine Critical Processes workflow
The Workflow Editor shows the stages in the workflow: Start, In Progress, In Review, Approval, and End.
Business Continuity Test Result Reporting
This workflow allows the user to move document test results through a review and approval process.
Figure 12. Business Continuity Test Result Reporting workflow
The Workflow Editor shows the stages in the workflow: Start, Document Results, Document Issues, and End.

MRG workflows

Numerous sample workflows are provided to facilitate use cases for IBM OpenPages Model Risk Governance:

  • Model Candidate workflow

    This workflow allows a user to add a Model object to the inventory as a candidate. The Model candidate is submitted for Approval as either a Model or a Non Model. The approver can perform an override of the candidate proposal. After a model candidate has been confirmed as a Model, the Model Development and Documentation process can begin.

  • Model Development and Documentation workflow
    This workflow takes a model from the completion of the candidate process through to approval for deployment. It consists of four stages and multiple sub-workflows that involve various stakeholders:
    • Definition and planning (model owner)
    • Development and documentation (model developer)
    • Pre-implementation review (model validation)
    • Approval (head of model development)
  • Model Tier Scorecard workflow

    This workflow performs a model tier assessment on the model, the results of which are used to assign a tier to the model. The Model Scorecard triggers and the values in Preference records are used to compute scores and tier. At the end of the workflow the scores and tier are copied up to the parent Model.

  • Pre-implementation Review workflow

    This workflow is performed at the completion of the model development and documentation workflow. The Review Planning team that is identified on a Preference object is responsible for completing this review. This workflow is also used for conducting reviews after the model is in production.

  • Model Attestation workflow

    This workflow is typically started by an MRG administrator and records a model owner's response to a request for attestation.

  • Challenges workflow

    This workflow is started against a Model, one of its Usages, or a Review. The result can be no action or changes to a Model or Usage.

  • Change Requests workflow

    This workflow provides governance for changes to Models. A workflow can be based upon changes in the business or to the data and other inputs to a Model. Users can accept, approve, or reject the change and decide whether it is material or not.

  • Metric Value workflow

    This workflow automates the Breach Status calculation and facilitates performance monitoring of deployed models. This is critical to the ability to proactively decide to make changes to the model or its usages or to remove a model from production. Typically, an MRG administrator creates Metric Value objects, a Metric Capturer provides the latest data for the Metric, and the Metric Owner reviews and approves it. The workflow calculates breach status for the Metric and copies the most recent Metric Value information to the Metric.

  • Model Decommission workflow

    This workflow is used to remove a Model from production and retire it.

The OpenScale Update Metric Last Value Info workflow supports the integration of MRG with IBM Watson® OpenScale. It updates the Metric Last Value Information fields on Metric objects for IBM Watson OpenScale models with values from the most recent Metric Value object that IBM Watson OpenScale sent to OpenPages. The workflow updates the following four fields on the Metric object:

  • Breach Status
  • Collection Status
  • Value
  • Value Date

PCM workflow

The Policy Review workflow in IBM OpenPages Policy Management is designed to advance a Policy object through a policy review and approval process. A Policy Review Comment (PRC) object is created by each action prior to the review stages (SME, executive, and final) and associated with the Policy in review. The PRC captures the comments and approvals for each reviewer. The executive review is optional, depending on whether the policy changes are substantive.

The Workflow Editor shows the stages in the workflow: Start, In Progress, In Review, Approval1, and End.

RCM workflows

OpenPages includes sample workflows for processing Regulatory Events. The workflows can be modified without the need for development resources or coding. Workflows can be tailored to match an organization’s methodology for processing alerts published by regulatory agencies.

  • Regulatory Change Review Workflow

    When a Regulatory Change record is created, this workflow starts. The user determines the applicability of the Regulatory Change record and determines the impact of the Regulatory Event. The user can also create and assign Regulatory Tasks to users within RCM for actions that need to be taken to respond to the Regulatory Event. When Regulatory Tasks are assigned to users, this workflow cannot close until all related Regulatory Tasks have been completed.

  • Regulatory Task Workflow

    When a Regulatory Task record is created, this workflow starts. The workflow alerts the owner of the Regulatory Task that a record has been created and assigned to them. After the user completes the assignment that is provided in the Regulatory Task record and clicks Task Completed, the workflow changes the status field to Completed and populates the date that the task was completed.

  • Regulator Interaction Workflow

    This workflow guides the user through preparing for, and responding to, a regulator interaction, such as a meeting request, inquiry, or examination. A user creates a Regulator Interaction record and then can add documents to the record prior to manually initiating the workflow. The workflow is assigned to the user listed as Primary Internal Contact of the primary parent Regulator record associated to the Regulator Interaction, otherwise the Owner field must be input for the workflow to initiate. The user then proceeds through identifying other users for collaboration, preparing a plan to respond to the regulator interaction, executing the plan, and awaiting the outcome of the interaction prior to closing the workflow. The fields provided for each view within the workflow are tailored for the user based on the type of regulator interaction and the stage of the workflow.

  • RI Component Workflow

    This workflow automatically initiates upon the creation of an RI Component record. Similar to the Regulator Interaction Workflow, the user proceeds through stages for preparing a plan to respond to the regulator, executing the plan, and awaiting the final outcome of the interaction with the regulator. The fields that are provided in each view within the workflow are tailored for the user based on the type of regulator interaction and the stage of the workflow.

  • RI Sub-Component Workflow

    This workflow automatically initiates upon the creation of an RI Sub-Component record. Similar to the Regulator Interaction Workflow, the user proceeds through stages for preparing a plan to respond to the regulator, executing the plan, and awaiting the final outcome of the interaction with the regulator. The fields that are provided in each view within the workflow are tailored for the user based on the type of regulator interaction and the stage of the workflow.

  • Compliance Review Comment Workflow

    This workflow automatically initiates upon the creation of a Compliance Review Comment record when a Reviewer has been identified by the creator of the record. A workflow stage is assigned to the Reviewer to review the comment provided by the creator of the record. After inputting information in the Comment Response field, the Reviewer can submit the response for the record creator’s review. The creator of the record can then close the workflow or request a follow-up review from the Reviewer.

Workflows for the Reg-Track connector
The following workflows are available with the Reg-Track connector:
  • Trigger Change - Regulatory

    This workflow creates a Regulatory Change record and associates the record to a Reg-Track Regulatory Event when the conditions of a rule from the Rules Engine are met that indicate the Reg-Track Regulatory Event addresses a regulatory change, such as a proposed or final rule published in the Federal Register. The workflow also populates certain fields on the created Regulatory Change record, including categorizing the Regulatory Change record as Regulatory Change. This workflow enables the association of multiple Regulatory Change records to a Reg-Track Regulatory Event so that multiple users can analyze the impact of the Reg-Track Regulatory Event on their particular areas of responsibility within the organization.

  • Trigger Change - Horizon Scanning

    This workflow creates a Regulatory Change record and associates the record to a Reg-Track Regulatory Event when the conditions of a rule from the Rules Engine are met that indicate the Reg-Track Regulatory Event addresses an issue other than a regulatory change, such as a speech or enforcement action published by a regulator. The workflow also populates certain fields on the created Regulatory Change record, including categorizing the Regulatory Change record as Horizon Scanning. This workflow enables the association of multiple Regulatory Change records to a Reg-Track Regulatory Event so that multiple users can analyze the impact of the Reg-Track Regulatory Event on their particular areas of responsibility within the organization.

  • Reg-Track Regulatory Change Review Workflow

    When a Regulatory Change record is created, this workflow starts. The workflow guides the user through the processing of a Reg-Track Regulatory Event. The user determines the applicability of the Reg-Track Regulatory Event that is associated with the Regulatory Change record and determines the impact of the Reg-Track Regulatory Event. The user can also create and assign Regulatory Tasks to users within RCM for actions that need to be taken to respond to the Reg-Track Regulatory Event. When Regulatory Tasks are assigned to users, this workflow cannot be closed until all related Regulatory Tasks have been completed.

  • Send Email Notification

    This workflow can be used to send mail notifications to users who are named within a rule that is created in the Rules Engine.

Workflows for the Thomson Reuters connector
The following workflows are available with the Thomson Reuters connector:
  • Trigger Change - Regulatory

    This workflow creates a Regulatory Change record and associates the record to a TRRI Regulatory Event when the conditions of a rule from the Rules Engine are met that indicate the TRRI Regulatory Event addresses a regulatory change, such as a proposed or final rule published in the Federal Register. The workflow also populates certain fields on the created Regulatory Change record, including categorizing the Regulatory Change record as Regulatory Change. This workflow enables the association of multiple Regulatory Change records to a TRRI Regulatory Event so that multiple users can analyze the impact of the TRRI Regulatory Event on their particular areas of responsibility within the organization.

  • Trigger Change - Horizon Scanning

    This workflow creates a Regulatory Change record and associates the record to a TRRI Regulatory Event when the conditions of a rule from the Rules Engine are met that indicate the TRRI Regulatory Event addresses an issue other than a regulatory change, such as a speech or enforcement action published by a regulator. The workflow also populates certain fields on the created Regulatory Change record, including categorizing the Regulatory Change record as Horizon Scanning. This workflow enables the association of multiple Regulatory Change records to a TRRI Regulatory Event so that multiple users can analyze the impact of the TRRI Regulatory Event on their particular areas of responsibility within the organization.

  • TRRI Regulatory Change Review Workflow

    When a Regulatory Change record is created, this workflow starts. The workflow guides the user through the processing of a TRRI Regulatory Event. The user determines the applicability of the TRRI Regulatory Event that is associated with the Regulatory Change record and determines the impact of the TRRI Regulatory Event. The user can also create and assign Regulatory Tasks to users within RCM for actions that need to be taken to respond to the TRRI Regulatory Event. When Regulatory Tasks are assigned to users, this workflow cannot be closed until all related Regulatory Tasks have been completed.

  • Send Email Notification

    This workflow can be used to send mail notifications to users who are named within a rule that is created in the Rules Engine.

Workflows for the Wolters Kluwer connector
  • Trigger Change - Regulatory

    This workflow creates a Regulatory Change record and associates the record to a WK Regulatory Event when the conditions of a rule from the Rules Engine are met that indicate the WK Regulatory Event addresses a regulatory change, such as a proposed or final rule published in the Federal Register. The workflow also populates certain fields on the created Regulatory Change record, including categorizing the Regulatory Change record as Regulatory Change. This workflow enables the association of multiple Regulatory Change records to a WK Regulatory Event so that multiple users can analyze the impact of the WK Regulatory Event on their particular areas of responsibility within the organization.

  • Trigger Change - Horizon Scanning

    This workflow creates a Regulatory Change record and associates the record to a WK Regulatory Event when the conditions of a rule from the Rules Engine are met that indicate the WK Regulatory Event addresses an issue other than a regulatory change, such as a speech or enforcement action published by a regulator. The workflow also populates certain fields on the created Regulatory Change record, including categorizing the Regulatory Change record as Horizon Scanning. This workflow enables the association of multiple Regulatory Change records to a WK Regulatory Event so that multiple users can analyze the impact of the WK Regulatory Event on their particular areas of responsibility within the organization.

  • WK Regulatory Change Review Workflow

    When a Regulatory Change record is created from a WK Regulatory Event, this workflow starts. The workflow guides the user through the processing of a WK Regulatory Event. The user determines the applicability of the WK Regulatory Event that is associated with the Regulatory Change record and determines the impact of the Regulatory Event. The user can also create and assign Regulatory Tasks to users within RCM for actions that need to be taken to respond to the Regulatory Event. When Regulatory Tasks are assigned to users, this workflow cannot be closed until all related Regulatory Tasks have been completed.

  • Send Email Notification

    This workflow can be used to send mail notifications to users who are named within a rule that is created in the Rules Engine.

FCM workflows

FCM includes the following sample workflows:
  • FCM Certification – Business Level
  • FCM Certification – Control Eval
  • FCM Certification – Process Eval
  • FCM Certification – Control
  • FCM Certification – Process

The workflows support the internal sub-certification framework at the Control and Process levels. Two distinct workflow paths, Control sub-certification and Process sub-certification, facilitate this and run simultaneously starting at the Business Entity Level.

Depending on the organization’s internal sub-certification framework, you can choose to:

  • Enable only one of these workflow paths.

    For example, the Control workflow may be disabled if the sub-certification at the Process level is all that is needed to meet your organization’s requirements.

  • Disable the FCM Certification – Business Level workflow if the business entity is not categorized as in-scope for SOX.

    If the FCM Certification – Business Level workflow is disabled, operations performed in this workflow must be reviewed, such as re-setting the Certification Status field to “Not Reviewed” to determine the impacts to the overall sub-certification process and remaining workflows.

FCM Certification – Business Entity Level workflow
  • The sub-certification process begins at the Business Entity level.
  • The workflow is activated for all business entities that are in scope for SOX.
  • The Business Level workflow has two stages, start and end.
  • The out-of-the-box workflow is started by using the Scheduler, which is set to start each calendar quarter and may be adjusted to the organization’s needs.
  • This workflow triggers the start of the following workflows:
    • FCM Certification - Control (field “classification” = key controls, workflow applicability = key controls), and
    • FCM Certification - Process (field “in scope” = SOX, workflow applicability = in scope for SOX)
Workflow Path at the Control level

The objectives of the FCM Certification – Control Workflow are to:

  • Start automatically from the Business Level workflow for all Controls that are classified as “key” controls.
  • Create a new Control Eval object for each key Control.
  • Automatically start the FCM Certification – Control Eval workflow.
The objectives of the FCM Certification – Control Eval Workflow are to:
  • Provide a mechanism for the user to certify the control data for each key Control on a quarterly basis.
  • Create a read only record of the certification (the Control Eval object) with the relevant data points mapped from the Control object on a specific date

The user has the option to complete the workflow with the following action: certify or certify with exception.

Note: The user can perform the following actions:
  • Certify – the Exception Description field must be blank
  • Certify with Exception - the Exception Description field must be populated with the exception description.
  • After certification is complete, the Control Eval object is locked to maintain the integrity of the data.
Workflow path for Control Eval
Workflow Path at the Process level

The objectives of the FCM Certification – Process Workflow are to:

  • Start automatically from the Business Level workflow for all Processes that are "in scope for SOX".
  • Create a new Process Eval object for each in-scope process.
  • Automatically start the FCM Certification – Process Eval workflow.
The objectives of the FCM Certification – Process Eval Workflow are to:
  • Provide a mechanism for the user to certify the process data for each “in scope” process on a quarterly basis.
  • Create a read only record of the certification (the Process Eval object) with the relevant data points mapped from the Process object on a specific date

The user has the option to complete the workflow with the following actions: certify or certify with exception.

Note: The user can perform the following actions:
  • Certify – the Exception Description field must be blank
  • Certify with Exception - the Exception Description field must be populated with the exception description.
  • After the sub-certification is complete, the Process Eval object is locked to maintain the integrity of the data.
Workflow path for Process Eval

DPM workflow

DPM includes the following sample workflow:
  • Data Privacy Assessment

When a new data asset (resource) is imported into OpenPages from Watson Knowledge Catalog, the Data Privacy Assessment workflow starts automatically. The first stage is Data Asset Review, where a reviewer must determine if a privacy assessment is needed or not. If they need more information, they can request more information from the data asset owner by selecting Actions > Request Additional Information. The data asset owner would now need to provide the requested information and select Actions > Submit for Data Asset Review.

If the privacy officer determined that a privacy assessment is not needed, they would select Actions > Privacy Assessment Not Needed. This sets the PIA Status field on the resource to Not Needed and the workflow ends.

If the privacy officer determines that a privacy assessment is needed, they would select Actions > Privacy Assessment Needed. This sets the PIA Status field on the resource to Needed and creates a Questionnaire Assessment assigned to the primary owner of the resource.

The privacy officer now selects a questionnaire template for the assessment, and the asset owner would complete the questionnaire. Once the questionnaire is completed, the asset owner would select Actions > Submit for Approval.

The privacy officer now reviews the privacy assessment and can either Approve or Reject it. If rejected, it will be returned to the Asset owner for remediation, and if Approved, then the workflow ends.

Figure 13. Data Privacy Assessment sample workflow
Workflow shows the privacy assessment approval