Emerging Risk Management: What ISO/TS 31050 Means for Australian Organisations

The Risks You Can See Coming But Can't Yet Score

Every organisation has them: the draft legislation that might land next year, the technology your supply chain is quietly adopting, the community expectation that hasn't turned into a regulatory obligation yet. They're too uncertain to score in the risk register, but too real to ignore. This is what emerging risk management is for, and since 2023 there has been an international standard describing how to do it.

The Short Answer

An emerging risk is one you've identified but can't yet assess with confidence, because the data doesn't exist yet. It doesn't belong in your risk register, because scoring it would produce a number you can't defend. It belongs in a separate, lighter-weight watch list where it gets an owner, a review date, and a documented trail of what you knew and when. ISO/TS 31050:2023 is the international guidance for doing exactly this, and Pali GRC includes a dedicated Emerging Risks module built around that lifecycle.

What Is an Emerging Risk, Exactly?

An emerging risk is a new or evolving threat - or opportunity - that your organisation has noticed but cannot yet evaluate properly. The defining feature isn't how bad it might be. It's how little you know about it.

ISO/TS 31050 characterises emerging risks by their newness, the shortage of verifiable data about them, and the resulting lack of the knowledge you'd normally need to make a decision. That's a useful test in practice: if you can already assign a credible likelihood and consequence, it probably isn't an emerging risk any more - it's a risk, and it belongs in the register.

Emerging risks typically arrive from changes in the operating context - legal, technological, environmental, social, political, economic, or ethical. Some concrete Australian examples:

  • Regulatory - an exposure draft of legislation that would change your licensing obligations, with no commencement date confirmed.
  • Technology - staff adopting generative AI tools informally, before there's a policy, a usage log, or any measure of exposure.
  • Supply chain - a single supplier quietly becoming a single point of failure for a service you can't easily insource.
  • Environmental - a change in insurer flood modelling for a site you've held for thirty years without incident.
  • Social - a shift in community or member expectations that hasn't yet produced a complaint, a claim, or a headline.

None of these are register-ready. All of them are things a board would be uncomfortable to learn nobody was watching.

What ISO/TS 31050:2023 Actually Says

The full title is ISO/TS 31050:2023, Risk management - Guidelines for managing an emerging risk to enhance resilience. It was published in October 2023 by ISO technical committee TC 262 - the same committee responsible for ISO 31000 - and runs to 34 pages.

Two points of accuracy worth getting right, because a lot of secondary commentary gets them wrong:

  1. It's a Technical Specification, not a full International Standard. The correct citation is ISO/TS 31050:2023, not "ISO 31050". A TS is published where the subject matter is still developing and the committee wants guidance in circulation before committing to a full standard.
  2. It isn't certifiable. Like ISO 31000, it's guidance rather than a set of auditable requirements. You align to it; you don't get a certificate for it. What you can demonstrate to an auditor, insurer, or board is a documented process that follows it.

The document complements ISO 31000 by taking its principles - integrated, structured, customised, inclusive, dynamic, based on best available information, accounting for human and cultural factors, and continually improving - and showing how they apply when the information is thin and the risk is still taking shape. It's explicitly written to be applicable to any organisation, at any stage, and customised to context. That matters for Australian SMEs and not-for-profits: nothing in it assumes you have a horizon-scanning team.

The practical thrust is that resilience comes from noticing early and reassessing often, rather than from producing a perfect assessment once. Which is a process problem, not an analysis problem - and that's exactly where most organisations fall down.

Why Emerging Risks Shouldn't Go Straight Into the Risk Register

The instinct is understandable: you've got a register, so put the risk in the register. But a risk register is built around a specific assumption - that you can assess likelihood and consequence with enough evidence to justify the score. Emerging risks break that assumption by definition.

Three things go wrong when you force them in:

  • False precision. A residual score of "12 - Medium" against a risk you fundamentally don't understand looks like knowledge. It isn't, and it will be treated as though it is.
  • Crowding. Speculative entries compete for board attention with risks that are genuinely quantified and genuinely being treated.
  • Premature treatment. Registers create pressure to nominate controls. Designing controls for a risk you haven't characterised is expensive and often wrong.

The alternative isn't to ignore them. It's to give them a different home with a different discipline - one that tracks confidence and time horizon rather than likelihood and consequence.

Registered Risk Emerging Risk
Core question How likely, and how bad? How confident are we, and how soon?
Assessment basis Likelihood and consequence scoring Confidence rating and estimated horizon
Evidence available Sufficient to defend a score Limited, contested, or still emerging
Primary response Controls and treatment plans Monitoring, information gathering, review
Success looks like Residual risk within appetite Enough confidence to promote, or dismiss it
Review driver Control effectiveness and assurance cycle Scheduled reassessment as knowledge improves

A Practical Emerging Risk Process

Here's what a workable process looks like for an Australian organisation without a dedicated risk team. Each step maps to how the Emerging Risks module is built in Pali GRC.

1. Capture the source

Record where the risk came from - an internal scan, an external report, an obligation review, a member complaint, a supplier conversation. Source matters more than usual here, because it's your only proxy for reliability when the evidence is thin. Source lists are configurable, so you can align them to how your organisation actually surfaces information.

2. Describe it without pre-judging it

Title, description, division or entity, and a unique reference. The discipline is to describe what was observed rather than what you assume it means. Six months later, the difference between "AI tools may create privacy exposure" and "three teams reported using unapproved AI tools for client correspondence" is the difference between a note and evidence.

3. Rate your confidence, not the risk

This is the step most organisations skip, and it's the one that makes the whole thing work. A confidence rating records how much weight the assessment can bear. Combined with an estimated horizon - when this might plausibly become real - and the potential impact areas, it gives a board a genuinely useful picture without pretending to a precision you don't have.

4. Assign an owner and a review date

An emerging risk without a named owner and a next review date is a document, not a process. Assign both, along with a review frequency appropriate to how fast the risk is moving. Reviews then surface on the owner's to-do list automatically, and keep surfacing until the entry reaches a terminal status.

5. Attach the evidence

Draft legislation, an industry report, an insurer's letter, meeting notes. This is the material that will let a future reviewer - possibly not you - understand why you assessed it the way you did.

6. Review, and keep the notes

At each scheduled review, record what was considered and what changed. Notes should append to a log rather than overwrite, so the trail from first sighting to final outcome stays intact. That log is what turns "we were monitoring it" from an assertion into a demonstrable fact.

7. Link it to what it touches

Connect the entry to related obligations in the Obligations Register and to any existing risks it might affect. A change in legislation that creates an emerging risk usually also touches an obligation you're already tracking, and the link is what stops the two being managed as unrelated problems.

8. Resolve it

Every emerging risk should eventually leave the watch list - promoted to the register, dismissed, or archived. An entry that has been in "watching" for three years with no notes is a governance failure wearing the costume of diligence.

The Emerging Risk Lifecycle

A simple status set does most of the work. In Pali GRC, an emerging risk moves through:

  • Watching - identified and being monitored. Most entries live here longest.
  • Under review - actively being assessed, usually because something changed.
  • Escalated - needs senior or broader attention ahead of the normal review cycle.
  • Converted to risk - confidence is now sufficient; promoted into the risk register and linked.
  • Dismissed - assessed and no longer considered relevant, with the reasoning recorded.
  • Archived - closed for reporting purposes and hidden from the working list.

The key design decision is that only the last three are terminal. Anything in watching, under review, or escalated keeps appearing on the owner's to-do list. You can't quietly lose an emerging risk by not looking at it, which is precisely how most of them get lost.

Where Organisations Get This Wrong

  • Treating it as a horizon-scanning exercise. An annual workshop that produces a list nobody revisits isn't emerging risk management. The value is in the review cycle, not the list.
  • Confusing "emerging" with "big". Emerging means poorly evidenced, not catastrophic. A well-understood catastrophic risk belongs in the register today.
  • No owner. Emerging risks are cross-cutting, which makes it tempting to assign them to a committee. Committees don't get to-do items. People do.
  • Never converting anything. If nothing has ever moved from your emerging list into the register, the list isn't feeding your risk management - it's running parallel to it.
  • Recording conclusions but not reasoning. The note that says "reviewed, no change" is worthless in two years. The note that says what was checked and why it didn't move the assessment is evidence.

Frequently Asked Questions

What is an emerging risk?

An emerging risk is a new or evolving threat or opportunity that an organisation has identified but cannot yet assess with confidence, because there is limited verifiable data about it. It's characterised by newness and uncertainty rather than by severity. Examples include a proposed change to legislation, an unproven technology entering your supply chain, or a shift in community expectations that hasn't yet produced a measurable impact.

What is ISO 31050?

ISO/TS 31050:2023, Risk management - Guidelines for managing an emerging risk to enhance resilience, is a Technical Specification published by ISO in October 2023. It complements ISO 31000 by showing how the general risk management principles and process apply to risks that are new, poorly evidenced, and still developing. It's guidance rather than a certifiable management system standard.

Can you be certified against ISO 31050?

No. ISO/TS 31050:2023 is a Technical Specification providing guidance, and like ISO 31000 it isn't written as a set of auditable requirements. Organisations align to it rather than certify against it. Demonstrating alignment usually means being able to show a documented emerging risk process, evidence of periodic review, and a clear path from an emerging risk into the formal risk register.

Why not just put emerging risks in the risk register?

Because a risk register is built around scoring likelihood and consequence, and an emerging risk usually lacks the data to support a credible score. Forcing one in produces a number that looks authoritative but isn't, and it competes for attention with risks that are genuinely quantified. Keeping emerging risks in a separate watch list preserves the integrity of the register while making sure nothing is quietly dropped.

How often should emerging risks be reviewed?

Review frequency should match how fast the risk is moving rather than a single organisation-wide default. A legislative change with a known commencement date might be reviewed quarterly; a fast-moving technology or supply chain issue might warrant monthly attention. What matters is that each entry carries its own review date and named owner, so the review happens because the system prompts it - not because someone remembered.

When should an emerging risk be promoted to the risk register?

When you have enough verifiable information to assess it with reasonable confidence, and it's credible enough to warrant controls and treatment plans. The trigger is confidence, not severity. At that point the entry should be linked to a new or existing risk in the register and closed out as converted, so the audit trail from first sighting to formal treatment stays intact.

Pali GRC includes a dedicated Emerging Risks module - separate from the Risk Register, aligned to the ISO/TS 31050 lifecycle, with configurable sources and confidence ratings, scheduled reviews driven from each owner's to-do list, and direct links through to your Obligations Register and existing risks. Like every module, it's included as standard.

Contact us today to arrange a conversation about your needs, see the platform in action, and understand how our approach might fit your organisation.

Inaction is as risky as action.

Joe Longo, ASIC Chair
Pali

Pali GRC simplifies your governance, risk and compliance (GRC) activities and saves you precious time and money, and ensures standards and consistency across the enterprise

ProbityPro Probity

ProbityPro manages the complete probity and procurement cycle, with the flexibility needed to accommodate an organisation's nomenclature, procurement processes and governance, workflows and more.