Defining risks and controls

Document and assure that operational risks are mitigated by controls. You can either define risks first and then controls, or vice versa.

Note

You can define risks and controls in an Internal Control workflow, which is used for more complex types of projects where narratives are defined, walkthroughs are performed to verify control design, and tests are performed to verify the operating effectiveness of controls.

If you need to perform a simple procedural project, you can define risks and procedures in a Workplan workflow.

What are risks and controls?

A risk is an effect of uncertainty on an objective, with the effect having a positive or negative deviation from what is expected.

A control is a set of measures or actions taken to manage risk and increase the likelihood that established objectives will be achieved.

Terms for "risk" or "control" can vary, depending on your organization's configurations. For example, a risk may be called a requirement, and a control may be called a procedure.

Before you start

Before you can define risks and controls, you need to:

  1. Create a project or a framework.
  2. Define objectives.
Note

Depending on your organization's project or framework configuration, objectives may also be called sections, processes, cycles, functional areas, application systems, or another custom term.

How it works

When you associate a risk with a control, you are specifying the measures or courses of action for how the risk will be mitigated. The combination of identified risks and corresponding controls is called a Risk Control Matrix.

A risk can be associated to many controls and a control can be associated with many risks.

Each control you define has a corresponding walkthrough that is used to verify that the control is designed appropriately. When you create or rollforward a project, you can choose to have one, two, or four testing rounds to verify that the control is operating effectively.

Defining complex relationships between controls and tests

The Risk Control Matrix creates a one-to-one relationship between each control and the associated test. If you need to define more complex relationships between controls and tests you have two options:

Relationship Description How do I achieve this?
One-to-many

A relationship between one test and many testing results

Apply the test against multiple items (e.g. enterprise application systems) and record the test results from all of the items in the same test.

Many-to-one

A relationship between a single testing result and multiple tests

Execute and record the testing result in the first test and link to the testing result from other tests.

Note

You can copy the URL from the browser address bar, and paste it into the Testing Results field for the other tests where the results apply.

Limitations

Each objective can contain a maximum of 1000 risks and 1000 controls.

Example

Defining risks and controls

Scenario

You are a CFO that owns an entire IT General Controls Review project. One of the control gaps identified is related to network security and is owned by IT. The Board wants to know who owns the remediation.

Process

The table below illustrates the risks and controls you defined as part of your organization's Risk Control Matrix. To follow up on the control gap (NS-002), you assign the appropriate IT staff member as the owner of the control.

Risk Associated Control(s)
NS-A: No technology is in place to detect and protect the network from unauthorized vulnerability assessment tools.
  • NS-001: The production network is architected to prevent unauthenticated or otherwise unauthorized traffic to and from sensitive systems.
  • NS-002: Firewalls are in place which are configured to prevent internet traffic that is not specifically required or authorized.
NS-B: Inappropriate or risky changes are made to the configuration of network security devices.
  • NS-003: Only appropriate network administration personnel have access to make changes to the configuration of network firewall devices.
NS-C: Network or system security vulnerabilities exist undetected because no auditing process is in place.
  • NS-004: Monthly vulnerability scans are conducted against external facing IP addresses and applications to detect potential vulnerabilities. Any vulnerabilities identified are followed-up on and resolved timely.
NS-D: Systems and network devices utilize out of date, potentially vulnerable, system software.
  • NS-005: A documented procedure is in place and followed to check for and apply system software patch and upgrades to server systems and network devices on a monthly basis.
NS-E: Data transmitted to and from the network is intercepted by unauthorized individuals.
  • NS-006: Transmissions of sensitive information to and from the network or public facing applications are forced to be done over an appropriately encrypted connection.

Result

  • The IT staff member receives an email notification and is able to assist with updating the control definition.
  • You are able to report to the board who owns the remediation of NS-002.

Permissions

Professional Managers and Professional Users can define and associate risks and controls.

Define risks and controls

Note

Interface terms are customizable, and fields and tabs are configurable. In your instance of HighBond, some terms, fields, and tabs may be different.

  1. Do one of the following:
    • To define risks and procedures in a project:
      1. Open the Projects app.

      2. Open a project, and click the Fieldwork tab.
    • To define risks and procedures in a framework:
      1. Open Frameworks.
      2. Open a framework, and click the Sections tab.
  2. Locate the appropriate objective, click Go To, and select Risk Control Matrix.
  3. Do any of the following:
    • To define a risk, click Add Risk, enter the necessary information, and click Save.
    • To define a control, click Control next to the View by label, click Add Control, enter the necessary information, and click Save.
  4. To associate risks and controls, do the following:
    1. Ensure that you have created at least one risk and one control.
    2. Next to the risk or control, click Associate Risk or Associate Control, define the appropriate associations, and click Save.

Risk fields

Note

Rich text fields cannot exceed 524,288 characters.

Tip

To enable spell check on rich text fields, do one of the following:

  • Chrome, Firefox, or Safari CTRL + right-click within the field on Windows or Command + right-click on Mac
  • Internet Explorer or Microsoft Edge open your browser settings and turn on spell check / highlighting of misspelled words
Field Description

Title

optional

a meaningful title for the risk

The maximum length is 255 characters.

Description

a statement about the risk

Risk ID

optional

the identifying number for the risk

The maximum length is 255 characters.

Impact

optional

a rating of the consequences of the risk occurring

Likelihood

optional

a rating of the probability of the risk occurring

Custom Risk Scoring Factors

optional

specifies the custom risk scoring factors associated with the risk.

Project Admins can define custom attributes for risks under Manage project types.

Tip

You can automate risk assessments for Impact, Likelihood, and Custom Risk Scoring Factors. For more information, see Automating operational risk assessments.

Custom Risk attributes

optional

specifies the attributes associated with the risk.

Project Admins can define custom attributes for risks under Manage project types.

Supporting Evidence

optional

allows you to link Results data to your documentation in Projects to consolidate information, easily sign-off on when remediation is complete, and inform assessments

Note

This option is only available if your organization uses Results.

Control associated to this Risk

optional

allows you to associate a control to the risk

Entity Coverage

optional

allows you to tag the risk to one or more entities for reporting purposes

Note

Only Professional Managers and Professional Users can tag a control with an entity by clicking Show content and selecting each entity to associate with the control. Changes are automatically saved.

History

View a complete history of field-level changes that have been made to the risk

Control fields

Note

Rich text fields cannot exceed 524,288 characters.

Tip

To enable spell check on rich text fields, do one of the following:

  • Chrome, Firefox, or Safari CTRL + right-click within the field on Windows or Command + right-click on Mac
  • Internet Explorer or Microsoft Edge open your browser settings and turn on spell check / highlighting of misspelled words
Field Description

Title

optional

a meaningful title for the control

The maximum length is 255 characters.

Description

a statement about the control

Control ID

the identifying number for the control

The maximum length is 255 characters.

Note

The number is appended to the end of the objective prefix.

Owner

optional

allows you to assign a licensed or non-licensed user as the owner of the control for tracking and reporting purposes

Users assigned the Contributor Tester or Contributor User role are typically assigned as an owner of a control.

Owners can be assigned based on a regional, business unit, or project-related framework. Once a person is assigned as an owner of a control, they receive an email notification with a link to the control, granting them write access to the assigned control, and read access to objectives and risks.

Note

If you bulk upload controls and specify a person in the Owner field, their name displays in Projects, but they are not automatically assigned the control and notified via email.

Frequency

determines the default testing method and sample size in the Test Plan tab

For example, the test plan for a project can be setup with a specified frequency (continuous, weekly, monthly, etc.), or on an as-need basis.

For more information, see Executing procedures and testing controls.

Type

determines the default testing method and sample size in the Test Plan tab

For example, the test plan may include Manual Controls, Application/System Controls, IT General Controls, or It Dependent Manual Controls. 

For more information, see Executing procedures and testing controls.

Prevent or Detect? specifies whether the control is intended to prevent or detect risk, or if it is not applicable

Method

optional

specifies how the control will be tested or implemented

Status

optional

specifies the current state of the control

Custom Control attributes

optional

specifies the attributes associated with the control

Project Admins can define custom attributes for controls under Manage project types.

Relevant Assertions

optional

allows you to tag the control to one or more Relevant Assertions

COSO Principles

optional

allows you to tag the control with one or more COSO Principles

Note

The Projects app supports the 2013 COSO Framework which includes 17 COSO Principles.

Risk associated to this Control

optional

allows you to associate a risk to the control

Control Weight

optional

expresses the percentage of the risk that the control mitigates

The default setting for control weight is 100%. You can input a control weight between 0% to 100%. The sum of control weights can add up to any number.

For more information, see Assurance components.

Entity Coverage

optional

allows you to tag the control to one or more entities for reporting purposes

Note

Only Professional Managers and Professional Users can tag a control with an entity by clicking Show content and selecting each entity to associate with the control. Changes are automatically saved.

History

View a complete history of field-level changes that have been made to the control

Add multiple risks and controls

For information about adding multiple risks and controls at once, see Bulk importing risks and Bulk importing controls respectively.