How to Define Risk Categories

 

How to Define Risk Categories

Risk categories are important

Let’s get this clear from the start – risk categories are important, and it is worth the effort to get them right.
Let’s explore this:

• Your key corporate assets (both tangible and non-tangible) need to be categorised clearly as these assets enable you to achieve your objectives (for example, people are tangible assets, reputation is a non-tangible asset)
• Risk categories provide the framework upon which we define our risk tolerance statements—that is, the extent to which we will tolerate disruption or loss to our assets
• Risk categories may change as we progress from the strategic risk management framework down to the risk management plans of specific business units
• The consequence or impact of the risk event on our assets needs to be rated with an appropriate consequence rating
• Risk categories, and the resulting risk tolerance statements, should be tailored for each level of the organisation, ensuring they do not contradict the overarching strategic-level tolerance statements
• The development of strategic-level risk tolerance statements against each category should be carefully crafted with a clear understanding of the extent to which those strategic tolerance statements either enable or disrupt a business unit’s ability to undertake risk assessments
• The category assigned to each risk should be based on the category of the risk outcome, not the risk event. For example, if the risk outcome involves reputation damage, the risk category should be “Reputation”. If the risk outcome is budget overrun, the risk category should be “Budget”.

The problem with many corporate risk management frameworks is that the risk categories may not fully define the critical elements of the organisation. For example, an organisation that does not include security as a risk category would be missing an essential element of the corporate business requirement and make it difficult for business units to undertake valid security risk assessments.

In this example, failing to include security as a strategic risk category may make any security risk assessments within that organisation potentially invalid unless there is an approved Security Risk Management Framework developed for that purpose. Nevertheless, developing a separate security risk management framework then potentially exposes the overarching corporate risk management framework to being invalid, or failing to withstand external scrutiny should there be court proceedings resulting from an adverse serious security incident.

How do define risk categories

Defining risk categories can be a “two-way street”.

We can define categories based on our understanding of the key elements of the business, and what assets may be disrupted. Or we can also identify risks that may have significant outcomes that we did not think of—therefore the risk identification process may also assist us defining additional categories we may have missed.

Let’s look at an example. Your organisation may have the following strategic-level risk categories:

• Budget
• Resources
• Programs
• Governance
• Reputation.

You are asked to undertake a program-level security risk assessment and, in doing so, identify a risk that is stated as

“Failure to undertake accredited personnel security checks may lead to unauthorised access and release of TOP SECRET information”

The risk event is about failing to undertake proper PERSEC checks. The risk outcome is about accessing and releasing TOP SECRET information—hence the risk should be categorised as “Information Security”. You now know to add a new category called Information Security, and also develop appropriate risk tolerance statements for risk outcomes so you can rate the outcomes as one of:

• Insignificant— may relate to unauthorised access or release of information classified as UNCLASSIFIED
• Minor— may relate to unauthorised access or release of information classified as OFFICIAL
• Moderate— may relate to unauthorised access or release of information classified as PROTECTED
• Major— may relate to unauthorised access or release of information classified as SECRET
• Catastrophic— may relate to unauthorised access or release of information classified as TOP SECRET.

You need to develop the appropriate risk tolerance statements otherwise you cannot properly rate the risk outcome, and as a result, cannot rate the risk. Any risk rating without assessing the risk tolerance statements would make that rating invalid and would most likely not withstand legal scrutiny. The outcomes would be too subjective and not based on any agreed or approved parameters.

By defining a new category as Information Security, it may also prompt you to consider additional security categories that may also be relevant, depending on your specific context. These may include:

• Governance Security
• Physical Security
• Personnel Security
• Cyber Security.

You would now also be in a position to suggest the organisation might want to mature the strategic-level risk management framework to include a category called “Security” that would provide strategic-level “authority” for development of the program-level risk categories that fit that program or project context.

Clarifying the categories also enables you to cross-check asset categories you may have been using in the threat and hazard assessments to ensure they also align.

Examples of risk categories

Here are some examples of strategic risk categories, noting the list is not meant to be exhaustive. Try and limit them to no more than about 6—10 categories:

• Corporate Governance
• Security
• Finance
• Resources
• ICT and Cyber
• Work Health and Safety
• Programs
• Operational
• Reputation.

Here are some examples of risk categories for an ICT project within the same organisation, again noting they are not meant to be exhaustive but do illustrate the difference:

• Project governance
• Deliverables
• Scope
• Timeframes
• Resources
• Information Security
• Cyber Security
• Budget
• Reputation.

It becomes clear that the risk categories for the ICT project need to be tailored for the project. It would be unwise to use the strategic-level categories for the project as they don’t align with the project context.