Object types in Governance console

The following table lists the subcomponents that are included by default.

In addition to the subcomponents listed in the table, the following object types are included in each solution and any authorized user can access them:

• Signature
• File
• Link

Account

Accounts correspond to one or more line items on a financial report. Each account is affected by recurring Processes. These Processes can introduce Risks that must be documented during the financial controls documentation project. An account is identified as significant based on factors such as size, complexity of the processes that operate on the account, or if the account is associated with new product lines within the business. The Processes that support the Account need to be assessed to identify potential Risks and whether the identified Risks have a material impact on the Account.

Ascent Supporting Information

The Ascent Supporting Information object stores supporting information that is imported from Ascent. Supporting Information is regulatory text that does not rise to the level of a legal requirement, but provides more guidance, details, and other information to help entities to understand the requirements and impact of the regulation. The Ascent Supporting Information object type has one parent, Requirement.

Assertion

The Assertion object is used to link Control objects to Account (or Sub-Account) objects. A common practice is to store the type of assertion that the Control is covering as a data field on the Assertion object.

Attestation

The Attestation object, part of the Policy Awareness capability, is used to capture an employee affirmation that they read and understood a policy. An Attestation's primary parent is the Employee record and the secondary parent is the associated Campaign.

Asset

COBIT suggests that there are four types of IT assets, while practitioners often include more types as well. The Asset object is sub-typed by using dependent fields to represent any of these types of IT assets. Assets are typically created as a pool associated to the owning or responsible IT Business Entity, then associated to the relevant operating elements (Baselines, Processes, and so on) in the IT Operating Environment, and potentially associated to relevant Business Entities for the Business as well. Although Assets can represent individual IT assets (for example, a particular Microsoft Windows server), they more often represent a group of assets (for example, a pool of Windows application servers that are used for a particular application).

Asset Link

COBIT suggests that IT assets have complicated relationships. They indicate that assets of type People, Process, Infrastructure, and Information can each be parents and can each be children of each other. In addition, assets of the same type often need to be related to each other. An Asset Link can be used to link Assets in a many-to-many fashion, but the practice (supported by the Create Resource Links helper) is to link exactly two Assets. If the names or attributes of either of the parent assets are changed, the name and attributes of the Asset Link will be out of sync with its parent Assets.

Audit

An Audit represents each execution of an audit against an Auditable Entity. For example, if an Auditable Entity is audited every two years, a separate child Audit instance must be created for each two-year period, such as 2022 and 2024. An organization might audit various processes. For example, you might audit an entity, a specific regulatory requirement, or a data center physical security.

The Audit object is configured as a self-contained object type and a folder is automatically created for each Audit instance. With this configuration, you can copy template audits and audit components from a library to the audit hierarchy without object naming conflicts.

Planning and scheduling of the Audit resources is done at the Audit level.

High-level Audit progress can be tracked by monitoring the Status values and Date values on the Audit. Key audit milestones can be tracked by adding fields that represent completion dates for each of the key milestones to track.

Use the Audit object to manage the audit process across your enterprise. The Audit identifies a holding point to capture information such as scope, objectives, timing information, review, execution, and approval roles. You can track a subset of audits that you are undertaking in a planning horizon, or all audits in the audit universe.

Audit Review Comment

The Audit Review Comment object type is used to provide feedback during the review process for an Audit and its components. It is associated as a child to the instance of the Audit, Section, Workpaper, or Finding for which feedback is being provided.

Audit Section

Audit Sections can be used to represent the phases of the Audit, work programs within the Audit, or other components of the Audit at the level of granularity you want.

Organizations might have multiple standard components for each Audit. Template audits that include sections for each standard component can be created in a library. Planned and Actual Start and End Dates for these sections are used to report progress on key milestones in the audits.

Detailed Audit progress can be tracked by including an Audit Section for each milestone. Alternatively, some organizations might add fields on the Audit that represent completion dates for each of the key milestones they want to track.

Although Audit Sections can be used for planning and scheduling Audit resources, most organizations find this method to be too detailed.

Auditable Entity

An Auditable Entity object is a child of a Business Entity and a Summary Audit Plan. An Internal Audit Business Entity hierarchy is established and all Auditable Entities are created as a child of the Internal Audit Business Entity object. Auditable Entities that are aligned with elements of the Business Entity Organizational Hierarchy are also associated to those Business Entities.

An Auditable Entity represents a single element of the Audit Universe; the collection of things in the business that might be audited. Most Auditable Entities represent business or legal entities, but they can also represent processes, long-running projects or initiatives, compliance programs, or shared IT Services.

Auditable Entities are risk ranked every year to determine the priority of performing an audit that year. A Weighted Risk Score is calculated but the score can be overridden.

Auditor

Resource planning and allocating requires key information about each individual who might perform audit work. The Auditor object is used to create a pool of Auditors who can be assigned to Audits.

Each user who is assigned to audit work is represented as an Auditor instance. Auditors are then available for resource allocation. The Auditor object includes attributes to use to evaluate and select Auditors for audit engagements, such as specialties, languages, and certifications. Auditor objects are associated with the relevant component of the Internal Audit organizational hierarchy. As a best practice, match the Name on the Auditor object with the username.

Baseline

A Baseline object type represents a template of library requirements. It is self-contained, which means folders are created for each Baseline. Baselines in the Library represent elements of the IT operating environment. They are linked to Requirements for that type of element. The Baseline object is copied from the library to the business hierarchy, an association is made to a Requirement in the library, and Risk, Control, and Test object types are created as child objects. The Risk, Control, and Test objects are populated with data from the Requirement when using the Baseline Copy Helper.

For example, a Baseline object can represent a collection of Requirement objects for a data center with Personally Identifiable Information (PII) and a Confidential Data classification. For each Requirement object, set up a best practice to define what to control (Risk object) and how to control it (Control object). You can also establish a practice for verifying the effectiveness of the Control (Test object).

Business Continuity Event

The Business Continuity Event object is used to identify an incident that negatively impacts business operation, for example, a pandemic, hurricane, tornado, or cybersecurity breach. The Business Continuity Event object type contains information such as location and type. A Business Continuity Event object can be associated with a Business Continuity Plan object to provide an easy way to relate specific occurrences to the corresponding plans.

Business Continuity Plan

A Business Continuity Plan is a proactive strategy, including policies and procedures, that describes how an organization and its critical functions will respond during and immediately following a disruption or disaster. The Business Continuity Plan addresses human resources, business processes, assets, and outsourced support services. The Business Continuity Plan object can be associated with other core business continuity objects such as Business Impact Analyses, Business Continuity Test Plans, Risk Assessments, Locations, and Teams.

Business Continuity Test Plan

Testing a business continuity plan is a valuable process used to gauge the effectiveness of the plan and assist in the identification of weaknesses or gaps. Testing can be conducted using various approaches such as table top and full simulation and can aid in the training and awareness of plan participants. The Business Continuity Test Plan object can be used to document the details of the test and can be associated with the parent Business Continuity Plan object and child objects such as the Business Continuity Test Plan Result and Issue.

Business Continuity Test Result

Business Continuity Test Result objects are child objects of a Business Continuity Test Plan. They are used to capture the results of the executed Business Continuity Test Plan. A Business Continuity Test Result can be associated with a related Business Continuity Test Plan and any accompanying Issues.

Business Entity

Business entities are abstract representations of your business structure. A business entity can contain subentities (such as departments, business units, or geographic locations). The entity structure that you create depends on your business needs. For example, you might create a parent entity for your business headquarters and a subentity for each location or department. You might also want to represent both a legal entity structure and a business entity structure.

Business entities are also used to organize library data such as risk and control libraries, or regulatory content (for example, laws, regulations, and standards).

When you set up your business entity hierarchy, work with your IBM® consultant. The structure of your business entities impacts the type and quality of information that can be extracted from the application.

In watsonx.governance Internal Audit Management Business Entities also model the Internal Audit organizational structure, which facilitates reporting and security for the Internal Audit team. The Internal Audit organizational structure is a top-level entity to minimize the chance of accidentally granting a business user access to Internal Audit information. The elements of the Audit Universe that are owned by an Internal Audit team are associated with the team Business Entity. Another top-level Business Entity structure can be created to organize confidential Audits, providing special security to these Audits. Business Entity can also be used to organize a Library of template audit content.

Business Impact Analysis

A Business Impact Analysis (BIA) is used to evaluate the criticality of predetermined processes, their dependencies, and the effect on the business in the event of a disruption. It is used to measure the impact that events such as natural disasters, pandemics, and terrorism can have on critical business processes based on the severity of losses.

The Business Impact Analysis object type is designed to assist you with prioritizing critical impact to the business by ranking predetermined categories using numeric scoring. Numeric impact ratings can be leveraged for key data fields such as Recovery Time Objective (RTO) and Recovery Point Objective (RPO). You can also use the calculation feature to translate your impact data to measurable information such Impact Scores, Impact Tiers, and Maximum Acceptable Outages (MAO).

Business Service

A Business Service is a service provided by the organization, such as withdrawing cash from and ATM or the ability to check a balance online, that can be broken down into supporting Processes. Business Services can be further classified as Important Business Services, which are services provided to external end users where a disruption would cause intolerable harm to consumers or market participants, market integrity, policyholder protection, safety and soundness, or financial stability.

A Business Service object can be a child of a Business Entity or Location object.

Business Service Eval

Business Service Eval objects are children of Business Service objects and they are used to capture values that are provided as part of the assessment of the Business Service for trending purposes. The Business Service Eval is created and populated as part of the last step of a Business Service assessment workflow.

Campaign

The Campaign object is part of the Policy Awareness capability and is used to manage the project management aspects of an awareness campaign. It is also used to define the requirements and criteria that identify which employees need to read and attest to each Policy. Campaigns are typically created in the Published Policy Hierarchy.

Challenge

The Challenge object can be used to store and evidence the presence of a Challenge to any part of the Model Inventory. A Challenge is raised and the response recorded. The Challenge object is a child of the Model and Model Deployment objects.

Change Request

The Change Request object is a child of the Model and Model Deployment objects and allows for the creation and tracking of governance activities that are related to changes in Models and their deployments. The object captures data such as Change Type, Change Description and Status. It is supported by a workflow.

Committee

The Committee object is a child of the Business Entity and allows an organization to represent governance groups/committees. These can then be aligned to Models and can also be a parent of the Employee object. It can store information such as the Terms of Reference for a committee, frequency of meetings, and detail of the Chairperson.

Compliance Plan

Compliance Plans allow for the creation of an overall plan to address regulatory requirements in a structured setting, or to structure a set of regulatory tasks. For example, a Compliance Plan might be created to track regulatory tasks, or to conduct compliance assessments against various regulatory requirements. One or multiple Compliance Themes can be grouped into an overall Compliance Plan for the organization.

Compliance Plan Eval

Compliance Plan Eval objects are children of the Compliance Plan object. Compliance Plan Eval objects are used to capture values that are provided as part of the compliance assessment that is captured on the Compliance Plan. A Compliance Plan Eval record is created and populated as the last step in the Compliance Plan BE Assessment and Compliance Plan Library Assessment workflows.

Compliance Review Comment

The Compliance Review Comment object type enables a user to add and post comments to the Regulatory Change, Regulatory Task, RI Component, RI Sub-Component, and Regulatory Interaction objects. A Compliance Review Comment can be directed to an individual or group of users for their response, and files can be uploaded onto the object to enhance collaboration among users.

Compliance Theme

Compliance Themes allow users to organize regulatory requirements into themes for assessment purposes. This allows for assessing compliance requirements beyond the typical business entity approach, by grouping regulatory requirements across themes that impact across the organization. Sample themes can include data privacy, governance, accountability, etc. This allows users to assess the impact of regulations not just within business entities, but across themes that touch on multiple areas of the organization.

Compliance Theme Eval

Compliance Theme Eval objects are children of Compliance Theme objects. Compliance Theme Eval objects are used to capture values that are provided as part of the compliance assessment that is captured on the Compliance Theme. A Compliance Theme Eval record is created and populated as the last step in the Compliance Theme BE Assessment and Compliance Theme Library Assessment workflows.

Contract

Contract objects are child objects of Vendor or Engagement objects. A Contract represents a business or legal agreement between a Business Entity and a Vendor or Engagement. A Contract contains additional, supporting information, for example, the timeframe of the contract or monetary information. Contracts are optional.

Control

Controls are policies and procedures that make sure that risk mitigation responses are performed.

After you identify the risks that occur in your practices, establish controls, such as approvals, authorizations, and verifications. These controls remove, limit, or transfer these risks.

Controls provide either prevention or detection of risks. Controls are associated with tests that ensure that a control is effective. For example, the human resources department identifies a risk in the new hire process. The process does not comply with regulations and guidelines for diversity and discrimination. Define controls to mitigate this risk, such as, establish hiring policies and procedures, and conduct mandatory training for hiring managers.

In watsonx.governance Internal Audit Management use Controls to create a detailed model of the Controls that exist or that you want to enforce on the activities that are audited. If shared with the Business, the Controls can be rated separately by Internal Audit and by the Business.

Control Eval

Control Eval objects are similar to Risk Evaluation objects except that they are created as children of Controls. They store control assessment data. When report periods and control assessment evaluation cycles are not aligned, use Control Eval objects to capture multiple evaluation cycles within a single reporting period.

Control Objective

A Control Objective is an assessment object that defines the risk categories for a Process or Sub-Process.

Control Objectives define the COSO compliance categories that the Controls are intended to mitigate. Control Objectives can be classified into categories such as Compliance, Financial Reporting, Strategic, Operations, or Unknown.

After a Control Objective is identified, the Risks belonging to that Control Objective can then be defined. In most cases, each Control Objective has one Risk that is associated with it. However, it might have more than one Risk that is associated with it. For example, a financial services company employs traders that are aware of the required ethical standards. The HR department sets up a control objective called 'Personnel'. A risk that is associated with the Control Objective is, Employees engage in business dealings that conflict with the company objectives for ethical and fair trading.

By default, an Internal Audit Management Control Objective is disabled. This object is not often used, except to align with other solutions that might use it.

Cost Center

Cost Center objects are used to group loss events under a business entity. In many cases, firms want to track where loss events occur at a fine granularity, such as cost center level, but do not want to represent all of the organizational layers as business entities.

Disclosure Statement

This object type is used primarily to record text-based commentary in relation to disclosure requirements. Disclosure Statements are children of Requirements.

Employee

The Employee object is part of the Policy Awareness Capability. It is used to capture information about individual employees such as the name, title, email, region, department, or status. Information from the employee profile is then matched against the Attestation Requirements that are defined on a Campaign to determine which Employees need to attest to each Policy. Employee data is typically derived from an HR system export, loaded via Online FastMap, and resides in the reference Employee Business Entity. It is a best practice that the Employee Name field matches the user's username.

Engagement

Engagement objects are child objects of Vendor objects. An Engagement represents a single service that is provided by a Vendor. You use them to differentiate between various services and agreements you have with a Vendor. Engagements are optional. They can be subject to questionnaire assessments, risk assessments, or tiering. You can summarize and analyze risk that is associated with different Engagements. You can add a parent association to the process or sub-process that an Engagement supports.

File

The File object type is used to embed a reference to a file (such as a document, flow chart or spreadsheet) in the Governance console, and associate it to one or more relevant objects.

Finding

Findings can be used to represent observations that are reportable to the business, to the Audit Committee, or both. Alternatively, Findings can be used to represent individual factual observations, while Issues are used to represent consolidated themes and systemic problems, which are then reported to the business, to the Audit Committee, or both.

A Finding represents anything that is uncovered in the course of an audit that needs to be accounted for and addressed by management. You can use a finding to track management's progress in addressing the underlying issue identified. The Issue object can be used in place of, or in conjunction with, the Finding object.

FIRST Loss

FIRST Loss objects can be imported from the FIRST external loss database, for use with scenario analysis, benchmarking, and reports generation, and to export loss data to analytic tools or capital allocation applications. FIRST Loss objects are often organized by loss categories, such as product lines or event types. For example, use a Business Entity to create a hierarchy for FIRST loss data. Name the root object FIRST-data, and create category folders under the root. Link external losses to it.

Incident

An incident is an occurrence that has a potentially adverse effect on your enterprise. Create an Incident object to record information, such as the person responsible for investigating the incident and other related data. The Incident object is used by a workflow to facilitate incident analysis. Categories that apply to incidents include Regulatory Compliance, Legal Compliance, Information Security, and IT. Incidents are stored under the Business Entity or Asset where the event occurred and associated secondarily to an impacted Mandate or Policy.

Issue, Action Item

Although issues are generated in areas where internal controls are not properly implemented, use the Issue object to document a concern that is associated with any object type. For example, a Test is associated with a Control, but the Test failed the last time that it completed. This potential problem can be highlighted by capturing it in an Issue object.

An Issue is resolved through Action Items. You can use an Action Item or a series of related Action Items to form an Action Plan. Each Action Item is assigned to a user for resolution, and tracks progress. After all Action Items for an Issue are complete (when an assignee sets the value to 100%), close the Issue.

In the Internal Audit Management solution, Issues and Action Items can be used instead of, or with, Findings.

KPI, KPI Value

KPIs (Key Performance Indicators) are components of the risk monitoring process and are used to provide leading or lagging indicators for potential risk conditions. Each instance of a KPI within the organization can have unique target and threshold limits. The KPI Value object type records the value of a KPI object at a specific point. Create a KPI object, and then periodically (daily, weekly, monthly) create a KPI Value object so you can detect trends.

KRI, KRI Value

KRIs (Key Risk Indicators) are components of the risk monitoring process and are used to provide leading or lagging indicators for potential risk conditions. Each instance of a KRI within the organization can have unique target and threshold limits. KRI values are used to record the actual value of an indicator at a specific point in time.

Link

The Link object type is used to embed a reference to a URL in the Governance console, and associate it to one or more relevant objects.

Location

The Location object type is used to capture geography and location details that are needed in the contingency planning process. Location information can include, for example, the number of employees who work at a location, assets (such as computer equipment), and other location details.

Loss Event

Loss Events are used to track operational losses that occur in any part of an organization. Loss Events are typically stored under the Business Entity where the loss occurred. The Loss Event objects are used to track, assess, and manage the related internal loss data. You can add multiple impacts and recoveries for each Loss Event by using the Loss Impact and Loss Recovery objects. Loss Event, Loss Impact, and Loss Recovery objects can also be created in IBM OpenPages® Loss Event Entry.

Loss Impact

A loss impact is a financial and non-financial consequence that results from a loss event. Loss Impacts track different types of impacts that are triggered by a Loss Event, such as legal liability, asset loss and damage, or business interruption. Multiple Loss Impacts can be associated with each Loss Event.

Loss Recovery

Loss Recovery objects are used to track the processes that are associated with recouping damages that result from Loss Events.

Mandate

Mandates represent external items with which organizations need to comply, such as laws, regulations, and standards. Content can be pulled from third-party providers, such as UCF, Ascent Reg Tech, or Wolters Kluwer. Mandates are represented in a Library Business Entity structure, and are not replicated throughout the system.

For example, an insurance company has a Mandate object for HIPAA and another Mandate object for GLBA. You can associate the same mandate with different groups within your organization. Privacy mandates, for example, might apply to payroll, insurance services, legal, and IT departments.

The Mandate object also supports content for regulatory compliance.

Metric, Metric Value

The Metric object records the definition of a performance measurement that the organization chooses to track. A user sets the Metric Type, Yellow, and Red Thresholds and other collection information. A Metric is a child of Model Deployment and Model objects.

The Metric Value object records the result of the metric performance measurement. It is designed to behave in a way to allow the organization to store time series results of measurement.

Model

The Model object provides representation of the Models within an organization. At a theoretical level a model as a quantitative method, system or approach that applies statistical, economic, financial or mathematical theories, techniques and assumptions to process input data into quantitative estimates. Within the Model object, key model information can be represented, including: Model Description, Model Ownership, Model Status, Development lifecycle dates, Model Type and Category, and Model Risk Assessment data. A Model object is a child of a Business Entity and parent of Model Deployment objects.

Model Attestation

Model Attestation allows an organization to request a regular sign off or attestation of a Model. The MRG administrator periodically creates a set of blank Model Attestations, which are assigned to the respective Model Owners. Each Model Owner answers a set of questions about the Model and submits their Model Attestation.

Model Deployment

The Model Deployment object is a child of Model. It is used as a key element of recording the deployment of one or more models.

Model Input

If an organization wants to adopt a more granular approach to model documentation, the Model Input object provides the ability to record the inputs. Fields include Input Owner, Type, Status, and Description. A Model Input object can also be the child of a Model Output object, which allows for the creation of Model chains at a detail level if the Model Link approach is not granular enough.

Model Link

If an organization wants to adopt a less granular approach to Model documentation, use Model Link, which is a broad-type association that does not provide explicit details of the feed from one model to another. It acts as a child of multiple models to allow for the generation of Model chains.

Model Output

If an organization wants to adopt a more granular approach to Model documentation, the Model Output object provides the ability to record the Outputs of the Model. The intended purpose is to record the Description and Overview of the Output from a governance point of view.

Model Risk Scorecard

Model risk assessments are performed during the development and documentation phase of a Model. They are also typically performed periodically after a Model is in production. The Model Risk Scorecard object is used to conduct this risk assessment. The user answers a number of questions about the Model. Model Risk Scorecard triggers calculate a risk score and determine the Model tier.

Model Version

The Model Version object is a child of the Model object and a parent of Model Deployment. The Model Version object is optional. If more detail is needed when building multiple versions of a model, the Model Version object can be used as an intermediary object.

Obligation

The Obligation object type represents the normalized and harmonized things you need to accomplish to comply with all of the obligation's associated Mandate, Sub-Mandate, and Requirement objects.

Obligation objects accomplish two primary purposes: they translate the often difficult and wordy legal jargon of Mandates/Sub-Mandates/Requirement into plain English, and they use the commonality across multiple Mandates/Sub-Mandates/Requirements. For example, you might have many Sub-Mandates and Requirements across numerous Mandates that require the use of strong passwords. A single Obligation object can document the details for strong passwords. By complying with this single Obligation, IT can satisfy many Mandates, Sub-Mandates, and Requirements.

Typically, Obligation objects are represented in a library Business Entity structure, and are not replicated throughout the system.

Obligation Evaluation

Once users have mapped internal controls to Obligations, users can conduct an evaluation of how well they are operating in relation to the identified obligation. Users can evaluate the operating effectiveness and design effectiveness of controls within the scope of a compliance theme

Obligation Evaluation Value

Obligation Evaluation Values are used to record the actual value of an obligation at a given point in time within the scope of an Obligation Evaluation.

ORIC Loss

ORIC Loss objects can be imported from the ORIC external loss database, for use with scenario analysis, benchmarking, and reports generation, and to export loss data to analytic tools or capital allocation applications.

ORX Loss

ORX Loss objects can be imported from the ORX external loss database, for use with scenario analysis, benchmarking, and reports generation, and to export loss data to analytic tools or capital allocation applications. You can import external ORX loss data into watsonx.governance Operational Risk Management for use with scenario analysis.

Plan, Timesheet

A Plan object type facilitates audit resource scheduling and allocation at any level. For example, you can create a single Plan object for an entire audit, or you can create one Plan object per task for each auditor who is involved with the audit. Plan objects are used to determine the availability, skills, and experience required of the desired resource. Audit views, reports, and so on, are aligned with Planning at the Audit level. Plans can instead be associated to Audit Sections, in which case these components would need to be modified.

Plan objects also drive time tracking - all time is tracked against Plans. A Timesheet object type is used to record weekly actual hours and expenses that are expended against a Plan object for an Audit. Because Timesheet objects are associated with Plans, it is easy to track deviations between planned and actual time and expenses.

You typically create or modify a Plan object by using the Add or Modify Plans helper, which audit owners can access from a link on the Audit task view. You can also edit plans (but not create them) by accessing the Audit Management > Plans menu item.

You should always use the Timesheet helpers to enter, modify, and approve time and expense data. Timesheet information can be viewed by accessing the Audit Management > Timesheets menu item. You can also add the Timesheet helpers to a Reports tab on your dashboard.

Policy

Policies represent internal guidelines that are adopted by the Board of Directors or senior governance body within an organization. The text of a Policy can either be stored in standardized fields on the object or as an attachment to the object. Policies typically have a distinct lifecycle from Draft to Published to Expired, as well as a review and approval process. Draft policies typically reside in the Organizational Business Hierarchy, while Published and Expired Policies typically reside in reference Library entities. Policies are also often mapped to applicable Mandates in the Library to which they relate.

Policy Review Comment

Policy Review Comments support and facilitate the review and approval process of Policies and Procedures by Subject Matter Experts and Compliance Personnel.

Preference, Preference Group

The Preference object is a child of a Business Entity or Preference Group, and includes variable values that can drive reports, workflows, and computed fields. It has entity-specific variable values that enable different behavior for the same workflows. For example, define variable values to determine the behavior for review and approval workflows such as the appropriate users for each level of review and approval, and the thresholds for determining how many levels of review and approval are required.

The Preference Group is used to group Preference objects together. Without this grouping object, each Preference object must be associated separately with each relevant Business Entities. The Preference Group helps minimize the associated maintenance.

In the default watsonx.governance Internal Audit Management configuration, these objects are used to hold weights for Risk Factors used in Annual Assessment Risk Ranking. Since the weights and factors can be different for each type of audit, such as financial, operational, or strategic, create a separate Preference instance for each audit type. As a child of Business Entity, this approach provides the ability to have entity-specific variable values.

In the default watsonx.governance Model Risk Governance configuration, these objects are used to identify participants in various MRG workflows and to configure parameters in the Model Risk Scorecard configuration.

Procedure

Procedures represent the what, where, when, and how of how policies are implemented in an organization. The text of Procedures is typically stored in the fields on the object. Typically, Procedures are represented as children of a Policy and reside in the same entity structure as its parent Policy.

Process

Processes represent the major end-to-end business activities within a business entity that are subject to risk. Processes reside in areas such as financial reporting, compliance, and information security. For example, Processes in the Accounts Receivable department such as order-to-cash could be improved with controls to protect against financial reporting risks such as fraudulent behavior or financial reporting inaccuracies.

In the Internal Audit Management solution, Processes are also used in scoping audits. Audits can copy Processes that are created by the business entity, or create their own Processes.

Process Eval

Process Evaluation objects are children of Process objects and they are used to capture process measurement values for trending purposes.

When the reporting periods do not align with the evaluation cycles, you can use Process Eval objects to capture multiple evaluation cycles within a single reporting period.

Product

This object type is a child of the Strategic Objective object type and is used to represent Products.

Program

Program objects are used together with Questionnaire Templates to implement Questionnaire Assessments. When a business administrator launches a Program, Questionnaires Assessments are created. A Program is associated with underlying assets, Questionnaire Assessments it created, and the Questionnaire Template it is based on. The Program provides input for the workflow.

Project

A project is designed to organize regulatory tasks into an overall compliance project. For example, there may be regulatory changes that need to be addressed in the compliance framework; users can create a project to identify and assign tasks.

Questionnaire Assessment

Questionnaire Assessment objects are a means of gathering information from business users in the organization. Questionnaire Assessments are created when a Program is launched. Questionnaire Assessments are associated with underlying assets, the Program that launched it, and the Questionnaire Template it is based on. Questionnaire Assessments are used by a workflow to facilitate a review process.

Questionnaire Template, Section Template, SubSection Template, and Question Template

Questionnaire Template, Section Template, SubSection Template, and Question Template objects are used together with Programs to implement Questionnaire Assessments. Questionnaire Template objects are parent objects and organize Section Template objects. Section Template objects are children of Questionnaire Template objects and organize SubSection Template objects. SubSection Template objects are children of parent Section Template objects and organize Question Template objects. Question Template objects contain questions and answer choices.

RapidRatings Ratings

RapidRatings Ratings objects are used with the RapidRatings connector in watsonx.governance Third-Party Risk Management. The RapidRatings Ratings objects store financial ratings and are children of Vendor objects.

Reg-Track Regulatory Event

The Reg-Track Regulatory Event object enables the direct ingestion of regulatory event feeds from Reg-Track into watsonx.governance Regulatory Compliance Management.

Reg-Track Regulatory Event Series

The Reg-Track Regulatory Event Series object is a collection of Reg-Track Regulatory Events that have been assigned the same Reg-Track Series ID within the Reg-Track feed. The grouping of Reg-Track Regulatory Events within the Reg-Track Regulatory Event Series allows changes to be tracked from proposed to final stage in the regulatory change evolution.

Regulation Applicability

The Regulation Applicability object resides in the organizational business hierarchy. It assesses and tracks the regulatory impact of a Mandate in the library on a Business Entity.

Regulator

The Regulator object is part of the Regulator Interaction Management capability and provides the ability for organizations to create a single inventory of all Regulators with which they interact. Regulators are typically created in a reference Library Business Entity. The object is a child of Business Entity and can be associated to Mandates and Regulator Interactions.

Regulator Interaction

The Regulator Interaction object is part of the Regulator Interaction Management capability. The Regulator Interaction object provides the ability to manage the interactions, communication, internal work, review, and approvals that are associated with external regulators such as inquiries, submissions, filings, exams, and meetings. For complex interactions such as exams, you can use the RI Component and RI Sub-Component objects to break the interaction into smaller components or track follow-up inquiries from the regulator. Regulator Interaction can be mapped to the following parent objects: Regulator, Mandate, Sub-Mandate, Requirement, Policy, Procedure, and Control. These parent associations enable a user to link objects that might be at issue in the Regulator Interaction and to identify users who are relevant to those objects and who might need to be consulted when responding to the regulator. Individual tasks that are related to the management of and response to the regulator interaction might be assigned to users through Regulatory Task child objects.

Regulatory Change

The Regulatory Change object is part of the Regulatory Change Management capability. It supports the ability to track regulatory changes, assess the impact of a change on the organization, communicate the change internally to the appropriate people, and drive internal processes in response to the change.

Regulatory Changes typically reside in the Library Business Entity, and can be associated directly to the Regulatory Event, Mandate, Sub-Mandate, or Requirement that changed. The triaging of the Regulatory Change is performed through the assignment of child Regulatory Task objects.

For organizations that receive a feed of regulatory events, users can create multiple Regulatory Change objects and initiate workflows from the ingestion of a regulatory event based on rules that are created within the Rules Engine.

Regulatory Event

The Regulatory Event object is used with watsonx.governance Regulatory Compliance Management (RCM). The Regulatory Event object type enables the direct ingestion of regulatory event feeds by using the REST API or IBM AppConnect into RCM. Together with the Rules Engine, the Regulatory Event object type supports the automated generation of workflows that assign incoming regulator events to users based on supplied data points. Documents that are impacted by regulatory change are also supported. These capabilities help to assign tasks efficiently to users to respond to, and prepare for, regulatory change efficiently. A Regulatory Event can be a child of a Business Entity, Control, Mandate, Sub-mandate, Requirement, Policy, or Procedure. Users can create Regulatory Change objects as children of Regulatory Events.

Note: If you are using a data provider, see the regulatory event object type for that feed, such as the Reg-Track Regulatory Event object type.

Regulatory Initiative

The Regulatory Initiative object is a child of the Business Entity and captures descriptive information about regulations that impact an organization. Regulatory Initiatives represent a broader grouping of regulations. For example, Anti-Money Laundering could be a Regulatory Initiative that includes several different money laundering regulations that organizations must comply with.

Regulatory Task

The Regulatory Task object is used to assign tasks to users when the task is related to one of the following parent objects: Project, Policy, Regulatory Change, Regulator Interaction, RI Component, or RI Sub-Component. A Regulatory Task can also be associated to a Business Entity.

Requirement

The Requirement object details specific requirements, found in the related Mandate or Sub-Mandate object, that the organization needs to adhere to in order to be in compliance.

Content can be pulled from UCF, Ascent Reg Tech, or other third party providers. Typically, Requirements are represented in a Library Business Entity structure and are not replicated throughout the system.

For Ascent Reg Tech, a Requirement is created for each incoming Task.

Requirement Evaluation

Once users have mapped internal controls to requirements derived from regulations, users can conduct an evaluation of how well they are operating vis-à-vis the identified requirement. Users can evaluate the operating effectiveness and design effectiveness of controls in within the scope of a compliance theme.

Requirement Evaluation Value

Requirement Evaluation Values are used to record the actual value of requirement at a given point in time within the scope of a Requirement Evaluation.

Requirement Version

The Requirement Version object details previous and future versions of the Requirement regulatory text. The Requirement Version object is a child of Requirement. The Requirement Version object tracks the regulatory changes over time. Past versions can assist in reviewing a Requirement at a given point in time. Future versions allow the user to prepare for the future regulatory text change and to begin their impact analysis.

Review

The Review object is used to record the scheduling and outcomes of any Model Review activity. It is the child of both the Model Deployment and Model objects. The object is intended to capture the outcomes of Reviews whether they are pre-implementation, post-implementation, and performed by second or third line of defense.

RI Component

The RI Component object (formerly labeled RI Category) is part of the Regulator Interaction Management capability and is used as the middle tier of the three-tier object model (Regulator Interaction, RI Component, and RI Sub-Component). The object is used to break down a complex Regulator Interaction into smaller, more manageable records or to link a follow-up inquiry from a regulator to the parent Regulator Interaction object. Additionally, RI Component can be mapped to the following parent objects: Mandate, Sub-Mandate, Requirement, Policy, Procedure, and Control. These associations enable a user to link objects that might be at issue and to identify users relevant to those objects and who might need to be consulted when responding to the regulator. Individual tasks related to the management of and response to the regulator interaction can be assigned to users through Regulatory Task child object.

RI Sub-Component

The RI Sub-Component object (formerly labeled RI Request) is part of the Regulator Interaction Management capability and is used as the last tier of the three-tier object model (Regulator Interaction, RI Component, and RI Sub-Component). The object is used to break down a Regulator Interaction and RI Component into smaller, more manageable records. Additionally, RI Sub-Component can be mapped to the following parent objects: Mandate, Sub-Mandate, Requirement, Policy, Procedure, and Control. These associations enable a user to link objects that might be at issue and to identify users relevant to those objects and who might need to be consulted when responding to the regulator. Individual tasks related to the management of and response to the regulator interaction can be assigned to users through Regulatory Task child objects.

Risk

Risks are potential liabilities. Risks can be associated with business processes, business entities, or a compliance with a mandate. Each risk has controls that provide safeguards against the risk. The controls help lessen consequences that result from the risk. Use the Risk object to categorize risks; capture the frequency, rating, and severity of observed and computed risk data; and view reports to identify top risk items. For example, the Cash account has a process that is called Payroll. A potential risk that might occur in the payroll is a duplicate payroll disbursements or the creation of fictitious payroll disbursements. Identifying risks in processes is a key component of developing a financial controls documentation project.

In the Internal Audit Management solution, a Risk that is shared between an internal audit and the business can be rated separately.

Risk Assessment

Risk assessments give you the ability to evaluate and report potential liabilities for a set of business entities or processes. A Risk Assessment object contains the names of the assessor and reviewer, the assessment time frames, and the status of the assessment. Use a Risk Assessment to manage the risk self-assessment process. Associate Risk objects with a Risk Assessment to create a link between the business entity and the Risks. For example, create a Risk Assessment to assess operational risks, such as external theft and fraud, internal fraud, physical property damage, or business disruption.

Risk Assessment Eval

Risk Assessment Evaluation objects are similar to Risk Evaluation objects except that they are instantiated as children of Risk Assessments. They store risk assessment data.

Risk Eval

Risk Evaluation objects are children of Risk objects and they are used to capture risk measurement values for trending purposes. Often reporting periods do not line up with risk evaluation cycles and so Risk Eval objects can be used to capture multiple evaluation cycles within a single reporting period.

RiskRecon Ratings

RiskRecon Ratings objects are used with the RiskRecon connector in watsonx.governance Third-Party Risk Management. The RiskRecon Ratings objects store vendor ratings and scores at the category and subcategory levels. The RiskRecon Ratings objects are created under /BusinessEntity/Library/VRM/VRMLibrary/RiskRecon and are children of Vendor objects.

Scenario Analysis

Scenario Analysis (SA) is an assessment technique that is used to identify and measure the potential occurrence of operational risk events or to assess operational resilience. Unlike traditional operational risk assessments, it is a forward looking what if analysis.

Scenario Analysis is designed to derive reasoned assessments of the likelihood and impact of plausible operational losses or to analyze operational resilience. You can use the Scenario Analysis process in Governance console to construct Scenario Analyses and collect supporting qualitative and quantitative data. Within each Scenario Analysis, you can record a range of frequency and severity estimates in buckets along with supporting information for the assessment.

In watsonx.governance Operational Risk Management (ORM), scenario analysis is often used to identify and measure events with low frequency but high severity losses, for example natural disasters, terrorism, or rogue traders. Along with its qualitative elements, scenario analysis is often used as a direct input into a firm’s operational risk capital estimate. Scenario Analyses are typically created for Business Entities and assigned a Risk Category. You can also associate supporting ORM data, for example, risk assessments, relevant loss events, ORIC losses, ORX losses, and risks.

In watsonx.governance Business Continuity Management (BCM), scenario analysis is used to identify and measure severe, but plausible scenarios, that could disrupt important business services to test the likelihood of the business service’s ability to recover within established impact tolerances. Scenario Analysis objects are created as child objects of Business Service objects. The results of a scenario analysis are stored in a Scenario Result object.

Scenario Result

Scenario Result objects are children of Scenario Analysis objects and they are used to capture the results of Scenario Analysis workshops for comparison and trending purposes.

In watsonx.governance Business Continuity Management, a Scenario Results object is created as part of the last action of the Scenario Analysis workflow.

Signature

A Signature generally indicates agreement that the object meets your approval. It has no enforcement powers, and does not prevent the item from being modified after approval has been given.

Signatures (with or without associated locks) are applied to an object from the task view of an object.

If Signature locks are configured on your system, when you sign off on an object, the object and all its associated child objects are locked and cannot be modified until you either revoke your Signature or an administrator unlocks the object.

Strategic Objective

This object type is used to represent an organization's ESG objectives. The object type includes fields for the ESG domain and goals. The Strategic Objective object type has one parent: Business Entity.

Sub-Account

A Sub-Account represents a smaller, more targeted line item that is part of a larger parent Account (or of another Sub-Account). Each Sub-Account object can be associated with parent Account or Sub-Account objects.

Sub-Mandate

Sub-Mandates represent external (or internal) sub-items with which the organization needs to comply. Content can be pulled from third-party providers, including UCF, Ascent Reg Tech, Thomson Reuters, and Wolters Kluwer. Typically, Sub-Mandates are represented in a Library Business Entity structure, and are not replicated throughout the system. Sub-Mandate is recursive, but Deloitte, UCF, Ascent Reg Tech, Thomson Reuters, and Wolters Kluwer content use exactly one level of Sub-Mandate. Sub-Mandates also support content for regulatory compliance. Sub-Mandates can be used to represent paragraphs that are derived from regulatory papers.

Sub-Process

A Sub-Process is a component of a Process. It is used to divide Processes into smaller units for assessment purposes. For example, an order-to-cash financial Process might be composed of several Sub-Processes such as accounts payable, purchasing, and general accounting. Any of these Sub-Processes might expose the Business Entity to risk and can be improved by using controls.

In the Internal Audit Management solution, this object is not used in audit scoping, but might be used in documenting Process details.

Sub-Contractor

Sub-Contractor objects are child objects of Vendor objects. A Sub-Contractor represents a portion of a service that is provided by a Vendor. Sub-Contractor is an optional object type. Sub-Contractors can be subject to questionnaire assessments, risk assessments, or tiering. You can summarize and analyze risk that is associated with different Sub-Contractors. You can add a parent association to the process or sub-process that a Sub-Contractor supports.

Summary Audit Plan

The Summary Audit Plan object type enables a program office to plan audits of Auditable Entities for a pre-determined period of time (annual, half year, or quarter) by scope, risk profile, forecast hours of audits, and so on.

The Summary Audit Plan object is a child of Business Entity. The children of Summary Audit Plan include: Audit and Auditable Entity.

Supply Wisdom

The Supply Wisdom object stores risk ratings of Vendors that are imported from Supply Wisdom. The Supply Wisdom object type has one parent, Vendor.

Supply Wisdom Parent Alert

The Supply Wisdom Parent Alert object stores alert data that is imported from Supply Wisdom. The import creates Business Continuity Event objects for the incoming Alert data and associates the Alerts to the corresponding Vendor and Location objects in Governance console.

System

System is a self-contained object type, which means that folders are created for each System object. The System object groups multiple Baselines to represent elements in the operating environment that can be assessed for risk. It acts as a container for a collection of Asset objects and the related Risks, Controls, and Requirements that together perform a function or comprise an IT service. For example, a System object might represent the servers, operating systems, applications, databases, support personnel, and facilities that provide the corporate email.

Team

The Team object type allows the organization to classify groups that support the business continuity process or are impacted in the planning of business continuity. The Team object can be used to identify key members of the team, the line of business and location and can be associated with the Employee object or Business Continuity Plan object.

Test Plan

A Test Plan is a container for tests and can be associated with parent Control objects and child objects, such as Test Results and Issues. Determine the operating effectiveness of a Control by conducting detailed tests and then documenting the results. Test Plans describe the mechanisms that determine if a Control is effective. For example, a sample Control is: Human Resources authorizes changes in employee status. A test for this control might be: Verify HR authorization stamp on new employee records. The test verifies that the new Control is implemented and in use.

The default Internal Audit Management configuration uses the Workpaper object in place of the Test Plan and Test Result. The Audit object needs access to these objects because they are often used to document business testing.

Test Result

A Test Result is the information that is obtained from running a test plan.

The default Internal Audit Management configuration uses the Workpaper object in place of the Test Plan and Test Result. The Audit object needs access to these objects because they are often used to document business testing.

Threat

A Threat is any circumstance or event with the potential to adversely impact organizational operations and assets. A library of Threats can be created under the Business Entity object and associated or copied to a parent Process, System, or Asset object. Threats can also associate to Vulnerabilities to identify and assess the likelihood and impact of a Threat’s exploitation of a Vulnerability, which would result in risk to an Asset, System, or Process.

TRRI Regulatory Event

The TRRI Regulatory Event object enables the direct ingestion of regulatory event feeds from Thomson Reuters into watsonx.governance Regulatory Compliance Management.

TRRI Regulatory Event Series

The TRRI Regulatory Event Series object is a collection of TRRI Regulatory Events that have been assigned the same Series ID within the TRRI feed. The grouping of TRRI Regulatory Events within the TRRI Regulatory Event Series allows changes to be tracked from proposed to final stage in the regulatory change evolution.

Use Case

The Use Case object is a child of Entity and a parent of the Model object. The usage of the Use Case object is optional. Its primary purpose is to collect information about a use case for models.

Use Case Review

The Use Case Review object is a child of Use Case. Its primary purpose is to capture approval information from various stakeholders of the parent Use Case, such as the names of reviewers, risk ratings and review comments.

Vendor

A Vendor represents a third-party company from which a firm procures goods or services. Vendors can have four types of child objects: Vendor Subsidiary, SubContractors, Engagements and Contracts. Vendors can be subject to questionnaire assessments, risk assessments, or tiering. You can summarize and analyze risk associated with different Vendors. You can add a parent association to the process or sub-process that a Vendor supports.

If you use Supply Wisdom, the Vendor object also has the Supply Wisdom object as a child object.

Vendor ratings can be imported from SecurityScorecard or Supply Wisdom by using connectors.

Vendor Subsidiary

A Vendor Subsidiary represents a subsidiary of a Vendor from which a firm procures goods or services. Vendor Subsidiary is an optional object type. Vendor Subsidiary is a child of Vendor. Vendor Subsidiary can have three types of child objects: SubContractor, Engagements and Contracts. Vendor Subsidiary can be subject to questionnaire assessments, risk assessments, or tiering. You can summarize and analyze risk associated with different Vendor Subsidiaries. You can add a parent association to the process or sub-process that a Vendor Subsidiary supports.

Vulnerability

Vulnerabilities give you the ability to track and assess security weaknesses. You assign scores to Vulnerabilities using the Vulnerabilities Common Vulnerability Scoring System (CVSS v2). The parent object for a Vulnerability can be a System, Incident, Asset, or Risk. Typically, you import Vulnerabilities from an IT security solution.

Waiver

Waivers give you the ability to document, process and manage the lifecycle of exceptions to Policies, Requirements, or Controls. Waivers can be associated to Business Entities, Policies, Procedures, Requirements, Risks, Controls, Baselines, and Assets.

WK Regulatory Event

The WK Regulatory Event object enables the direct ingestion of regulatory event feeds from Wolters Kluwer into watsonx.governance Regulatory Compliance Management.

Workpaper

A Workpaper is any artifact or deliverable you want to track in the scope of an audit. It can represent an engagement letter, a testing matrix, interview notes, or anything else appropriate to the audit in question. The workpaper itself can be attributes that are stored on the Workpaper object, or it can be a Microsoft Word, Microsoft Excel, or other type of file that is attached to a Workpaper object. When Workpaper is used for test evidence, it documents both the test planning and the test results.

Create a Workpaper object from the task view of an Audit Section. Workpaper objects can also be copied from a library, where they represent templates of different types of workpapers that are generated by an internal audit department.