Risk themes: putting your risk framework to work

A service provider outage makes the news. Your team needs to decide whether it affects a service you rely on, what evidence to check and whether someone needs to act.

The headline alone cannot answer those questions. You need the context of your relationship with that provider and the expectations your organisation has already set.

That is where risk themes fit. They give your team a structured way to describe the risks that matter, so provider information can be considered against your own risk framework.

What is a risk theme?

A risk theme is a defined area of risk, such as service continuity, information security or financial viability. It brings related concerns together under a shared description.

For a third-party risk team, a useful theme answers a practical question: what could happen in this area that would matter to our organisation?

A service continuity theme might cover prolonged outages, failed recovery tests and reliance on a single delivery location. A financial viability theme might cover signs that a provider could struggle to keep delivering its contracted services.

Those are illustrative categories. Your organisation should use the themes and definitions that fit its services, obligations and approved approach to risk.

In Contrata, Risk Themes sit within Control Centre. Each theme is an area within your organisation’s Risk Framework. It can include risk appetite, policy statements, descriptions of severity and guidance for assessments and monitoring. The framework supplies the organisational context; themes make that context more specific.

Illustrative stock photograph · Mikhail Nilov / Pexels

Think of themes as the building blocks of a risk framework

A risk framework describes how your organisation manages risk: who is responsible, how risk is assessed, which controls are needed, and how issues are monitored, escalated and reported.

The Australian Department of Finance describes a framework as the arrangements for designing, implementing, monitoring and improving risk management. Its guidance also explains how shared risk categories support consistent reporting and decisions. This guidance is written for Commonwealth entities, but the distinction between a framework and its categories is useful more broadly. Read the Department of Finance guidance.

Themes form part of that structure. To put them to work, connect each one with the organisation’s expectations:

• Theme: the area of risk you are considering.
• Risk appetite: the level and kind of risk your organisation is prepared to take in pursuing its objectives.
• Policy statements: the requirements or expectations that guide how the risk should be managed.
• Evidence and review: the information your team uses to decide whether those expectations are being met.

For example, “service continuity” identifies an area of concern. An appetite statement explains your organisation’s position on disruption. A policy might require relevant providers to maintain and test recovery arrangements. Test results, incidents and provider responses give your team evidence to assess.

Appetite and severity answer different questions. Appetite describes the organisation’s willingness to take risk. Severity describes how serious a particular risk or event is assessed to be. Contrata’s theme configuration includes descriptions of severity levels so reviewers have a shared reference for those assessments.

The Institute of Risk Management’s guidance on risk appetite and tolerance provides further background on connecting appetite with decisions. It is professional guidance, rather than an Australian regulatory requirement.

How this works in Contrata

Contrata brings theme definitions into a central Risk Framework area and provides a place to examine theme relevance when reviewing monitoring incidents. Your team can use those definitions alongside the provider information and its own approved policies.

The practical sequence is to define the risk context, consider information about the provider, then review why it matters to your relationship.

1. Define the risk context

Start with the framework and policies your organisation already uses. Keep the language specific enough to guide a review.

“Technology risk” may be too broad on its own. “Disruption to technology services that support customer transactions” gives the reviewer a clearer subject. The right level of detail depends on your organisation: a short list of well-defined themes is easier to apply than overlapping labels that nobody interprets consistently.

Keep appetite and policy wording aligned with approved documents. If a policy says a particular control is required, an AI-generated summary should not quietly soften it to a preference.

2. Review the theme definitions

Review each theme against your approved source documents before making it active. Check that its description, appetite and policy statements express the expectations your organisation actually uses.

Risk themes are managed centrally for use across providers rather than chosen separately for each provider. The provider’s own service and relationship context still matters when reviewing a particular event.

3. Consider provider information in that context

A reported event may be relevant to several themes. A cyber incident, for example, could raise questions about data protection and service continuity.

Relevance also depends on the service you receive. An outage in a provider’s unrelated business division could have a different significance from an outage affecting the platform your customers use.

Where theme matches and supporting evidence are available, Contrata’s monitoring incident detail can show why themes apply, with a rationale and linked evidence. These explanations give your team points to examine during its review.

4. Review the evidence and decide what to do

A theme match is a reason to investigate. Your team still needs to establish what happened, what remains uncertain and what action is appropriate.

Check the source and timing of the information. Confirm whether it concerns your contracted service. Compare the evidence with the relevant policy, contractual commitments and tolerances. Where information is missing or conflicting, record the gap and identify the person responsible for resolving it.

Acknowledging an incident records that it has been seen. It does not resolve the incident; your team still needs to determine whether any further action is required.

Illustrative stock photograph · panumas nikhomkhai / Pexels

A worked example: two recovery targets do not match

Consider a fictional Australian organisation and its payroll provider. The organisation relies on that provider to process payroll before a fixed cut-off.

The organisation’s framework includes a service continuity theme. Its illustrative appetite statement says it has low appetite for provider disruption that could prevent payroll being processed on time. Its policy requires appropriate recovery arrangements for services that support time-critical processing.

The provider’s agreement states one recovery target, but its latest test plan uses a longer target. These are two stated targets; neither tells the reviewer what recovery time was actually achieved in a test.

The theme helps frame the review around continuity. The policy explains why recovery evidence matters. The documents expose a discrepancy that needs an answer.

Your reviewer would ask:

• Do both targets refer to the same service and disruption scenario?
• Was the longer target formally agreed, or is it only an assumption in the test?
• Would that recovery time put payroll processing at risk?
• Who needs to clarify the discrepancy or approve a change?

The person responsible for the provider relationship records the open question and requests clarification, including updated evidence and the actual test result. The organisation would then decide whether to require remediation, change an arrangement or escalate the risk under its own governance process.

Receiving another document does not resolve the discrepancy automatically. The decision depends on what that document establishes.

What risk themes do not establish

A theme does not demonstrate that a control works. A policy statement does not prove that a provider follows it. An absence of relevant monitoring items does not establish that a provider is safe.

These distinctions matter when reporting to management. Explain what evidence supports a conclusion, which questions remain open and who owns the next action.

For APRA-regulated entities, CPS 230 sets out broader requirements covering operational risk governance, assessment, controls, monitoring, business continuity and service provider arrangements. Risk themes can support the way a team organises its work, but configuring themes alone does not establish compliance. Read APRA’s current CPS 230 standard.

Start with one theme your team can use

Choose an area that regularly leads to a provider review. Give it a clear definition, connect it with the relevant appetite and policy statements, and test the wording against a recent event.

Could another reviewer understand why the event matters? Could they identify the evidence they need and the next decision? If the answer is unclear, refine the theme before adding more categories.

Risk themes are most useful when they help your team carry its agreed framework into an actual review: the risk being considered, the expectation being tested, the evidence available and the decision still needed.