Skip to main content

Risks and controls

The platform models risk management with two pairs of object types: Risk and Risk Instance for the threats themselves, and Control and Control Instance for the measures that mitigate them. In each pair, the first is the abstract catalog entry and the second is its concrete occurrence somewhere in your enterprise model.

Overview​

A Risk is a catalog item — "Customer Data Breach" as a category of threat your organization tracks. A Risk Instance is that threat showing up somewhere real: the data breach risk on a specific process or activityActivity A named step in a process (e.g. "Approve Invoice"). Each event in an event log records one activity occurrence for one case., with its own values. You can work top-down — build the Risk Catalog first, then relate Risk Instances to it — or bottom-up, identifying a risk on a process first and assigning it to a catalog Risk later.

The same split applies to controls. A Control is a catalog entry for an action that ensures or tests compliance — a formal review, a sign-off, a technical safeguard. A Control Instance is that control applied at a specific place in the model. In releases before 16.4, the Control object was called Business Rule; Business Rule survives as one of the control types, so you can keep everyday business rules apart from the mitigating controls you use for risk management.

If two levels are more granularity than your model needs, you can work with Risks and Controls alone and skip the instances — you lose the distinction between catalog and occurrence, but the model stays simpler.

Where each object can live​

  • A Risk can only be created in the Risk Catalog — in the catalog root, in a risk folder, or nested under another Risk to decompose it.
  • A Control can only be created in the Controls branch — in a controls folder, or nested under another Control.
  • Risk Instances and Control Instances can be created almost anywhere in the repository tree: under processes, activities, resources, folders, and most other objects. A Risk Instance can contain a Control Instance; a Control Instance can't contain anything.

A Risk can relate to many Risk Instances and be a risk for many objects. A Risk Instance is stricter: it can be an instance of only one Risk and a risk for only one object.

Relationships​

Risk and control objects connect to the rest of the model through their own relationship types, shown on the Relationships tab under the Performance, Risks, Opportunities and Controls group:

  • Risk For — links a Risk or Risk Instance to the object it threatens. The object's side of this relationship is Has Risk; the object's main page then shows the risk's current values in its Risk section.
  • Instance of Risk — links a Risk Instance to its catalog Risk. From the Risk's side this is Has Risk Instance.
  • Controlled By — links a Risk or Risk Instance to the Controls and Control Instances that mitigate it. The controls' ratings reduce the risk's inherent value to its residual value — see Residual risk calculation.

When you create the objects in place, the platform connects them for you: a Control Instance created under a Risk starts with the Controls relationship to that Risk, and the creation dialogs for Risk Instances and Control Instances let you set the target object and the catalog association (Risk For and Associate with Risk) before you finish.

Settings​

Risks and Risk Instances share the same settings, on the object's Settings tab:

  • Risk Type (on a Risk) / Risk Instance Type (on a Risk Instance) — classifies the risk. The available types, and any extra risk value they add, are maintained on the Risk Types and Risk Instance Types tabs of Risk and Risk Instance configuration.
  • Data Type — how the risk stores its data. Standard derives the risk value from a matrix of Impact and Likelihood and is the most common choice. Value holds a number directly, without the matrix. Internal Control System switches the risk to the ICS model — see ICS risks.
  • Risk Categories — one or more categories such as Financial or Operational. The same category list is shared by Risks, Risk Instances, Controls, and Control Instances, and is maintained on the Risk Categories tab of Risk and Risk Instance configuration. Its purpose is to check that the mitigating controls cover every category the risk is assigned to. When they don't, a warning appears next to the residual risk value.
  • Financial Impact Unit — the unit for financial values entered on the Data tab.
  • Weighting and Preempt other risks — how much this risk counts when ratings aggregate upward, and whether its own rating overrides the aggregate. These work the same way as for performance indicators — see How ratings aggregate.

The Settings tab of a Risk, showing Risk Type, Data Type, Risk Categories, Financial Impact Unit, Weighting, and the Preempt other risks option.

Controls and Control Instances have their own settings:

  • Control Type — for example Business Rule, Control, or Gap. The list is maintained on the Control Types and Control Instance Types tabs of Control and Control Instance configuration.
  • Control Rating — how effective the control is, on a scale set up on the Control Ratings tab of Control and Control Instance configuration (for example from Ineffective Control to Effective Control). Each rating carries a numeric value used in the residual risk calculation.
  • Risk Categories — the categories this control covers, checked against the categories of the risks it mitigates.
  • Control Keying — Key or Non-Key. Key and non-key controls are weighted differently when their ratings combine — see Residual risk calculation.

The Settings tab of a Control, showing Control Type, Control Rating, Risk Categories, and Control Keying.

Risk data and current values​

With the Standard data type, you enter dated data points on the risk's Data tab: pick an Impact and a Likelihood, and the platform derives the risk Value from the repository's risk matrix. Each data point also takes an optional appetite, financial impact, and reason.

The Risk section of the object's main page shows the current values — the most recent data point that isn't in the future. Data points dated in the future don't show until their date arrives, so you can stage upcoming assessments. The section's legend links to the repository's Risk Matrix, Risk Ranges, Control Ratings, and Control Weighting so you can see how the numbers and colors are derived, and an expandable table breaks down how the controls reduce the inherent value to the residual one.

The Risk section of a risk's main page, showing inherent risk 12, combined controls 8, and residual risk 4, with a Risk Category Not Addressed warning.

The warning icon next to the residual value means the assigned controls don't cover all the risk's categories — select View Categories to see which categories are unaddressed. These warnings are on by default. An administrator can switch them off for the whole repository with Show Category Warnings On Risk Objects, on the Risk Categories tab of Risk and Risk Instance configuration.

Related tasks & references​