Assurance components

Learn about the components that affect assurance for risk in Projects.

Risk scoring factors

Risk scoring factors are attributes that have an impact on the achievement of objectives within an organization. Each risk scoring factor can have one name and assigned weight, and be associated with one scale.

Default and custom risk scoring factors

There are two default risk scoring factors:

  • Impact
  • Likelihood

Each default risk scoring factor is associated with a 3-point scale:

  • 1 Point - Low
  • 2 Points - Medium
  • 3 Points - High

You can re-label the default risk scoring factors and modify the point scale associated with each risk scoring factor.

Optionally, you can also define up to eight custom risk scoring factors, assign a weight to each, and specify a custom scale. Since not all risk scoring factors may be equally important, you can specify a weight to reflect the perceived importance of the risk scoring factor. The higher the value of the weight, the more important the risk scoring factor is to your organization, and the more the risk scoring factor will contribute to the overall inherent risk score.

Note

You cannot modify the weight of the default risk scoring factors (Likelihood and Impact), which is set at 100%.

Defining risk scoring factors

Project Admins can define risk scoring factors under Manage project types > Risks and Controls tab.

For more information, see Customizing terms, fields, and notifications.

Scoring risks

Professional Managers and Professional Users can score risks when they add or edit risks.

For more information, see Defining risks and controls

Risk scoring factors in Projects vs. Strategy

Risk scoring factors in Projects contribute to the assurance score displayed in Projects and on the Assurance tab in Strategy (if Projects objectives have been linked to risks in Strategy).

Risk scoring factors in Strategy contribute to the inherent and residual risk scores displayed in Strategy.

Weight

Defining a control weight allows you to express the percentage of the risk that the control mitigates.

How it works

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

Determining a control weight

Determining a control weight depends on the risk and your environment. Some organizations or departments use discretionary methods, while others use historic data or data analysis techniques to determine a control weight.

Defining a control weight 

You can define the weight for each control when you associate risks and controls.

For more information, see Defining risks and controls

Tests

As you perform walkthroughs and tests or execute procedures, Projects automatically aggregates testing results and issues, and calculates assurance in real-time. As controls pass, assurance increases, and as controls fail, assurance decreases.

Performing walkthroughs and tests or executing procedures

Depending on the project workflow, the following testing tasks are available:

Workflow Task Information
Internal Control Test the design of controls using the Walkthroughs page. Executing procedures and testing controls
Test the effectiveness of controls using the Test page.
Workplan Execute procedures using the Execute Procedure page.

Noting whether an execute procedure, walkthrough, or testing round passes or fails

Depending on the project workflow, there are different options for noting whether an execute procedure, walkthrough, or testing round passes or fails.

Workflow Test type Option Pass or Fail
Internal Control Walkthrough Designed Appropriately Pass
Design Failure Fail
Testing Round Operating Effectively Pass
Exception(s) Noted Fail
Workplan Execute Procedure No issues Pass
Issues noted Fail

When does a control pass or fail, and when is it considered "Not Tested"?

Projects automatically calculates when a control passes or fails based on the following logic:

Control status Logic
Pass

the associated walkthrough or execute procedure passed

OR

at least one of the control's applicable testing rounds passed (the other testing rounds must not be tested)

Fail

the associated walkthrough or execute procedure failed

OR

at least one of the control's applicable testing rounds failed

Not tested

the associated walkthrough has not been tested AND all of its applicable testing rounds have not been tested

OR

the associated execute procedure has not been tested

Scenarios

The following table shows a few different scenarios that illustrate when a control passes or fails. The table illustrates a project that contains one walkthrough and two applicable testing rounds per control:

Control Walkthrough Interim Test Final Test Does the control pass or fail?
Control 1 Pass Pass Pass Pass
Control 2 Fail Fail Fail Fail
Control 3 Pass Pass Fail Fail
Control 4 Pass Pass Not Tested Pass
Control 5 Fail Pass Pass Fail
Control 6 Not Tested Pass Pass Pass
Control 7 Not Tested Pass Fail Fail
Control 8 Not Tested Not Tested Not Tested Not Tested