Enterprise Risk Management in Practice

Written by Jonas Osman Abdelghafour — actuary and financial risk manager (FRM, GARP USA).

Every enterprise risk management framework I have reviewed in twenty years of consulting looks respectable on the cover. There is a risk appetite statement, a taxonomy, a three-lines-of-defence diagram, and a heat map that has probably been reused across several unrelated committees. What separates a framework that actually runs the company from one that decorates the intranet is not the diagram — it is a handful of design choices that most organisations still get wrong.

This piece collects those choices as I see them, with an eye to the practitioners who have to make ERM defensible to a board, a regulator, and an internal auditor in the same quarter.

Start from decisions, not from risks

The most common failure mode is a framework that catalogues risks exhaustively and then has no mechanism to convert that catalogue into decisions. A useful ERM function starts from the other end. Ask: which decisions does this organisation take, and how would risk information change them?

For an insurer, the decisions are capital allocation, reinsurance structure, product mix, pricing, and investment strategy. For a bank, they are asset origination, ALM positioning, liquidity buffers, and product design. For a corporate, they are capital projects, hedging, supplier concentration, and geographic footprint.

Every risk report that does not connect to one of these decisions is overhead. Every decision that is not visibly informed by risk is a governance gap. A framework that maps the two together is small, sharp, and used — see the companion note on ERM demystified for a longer treatment of the map itself.

Risk appetite that bites

A risk appetite statement is worth exactly as much as the decisions it stops. If nothing has ever been declined because it breached appetite, the statement is not calibrated — it is decoration. Three properties separate a real appetite framework from a symbolic one.

Quantitative limits at the level where decisions are made. A group-level appetite of "we maintain a 180 percent solvency ratio under stress" is useless to an underwriter pricing a facultative treaty. Cascade the metric down: economic capital consumption per line of business, concentration limits per counterparty, sensitivity ceilings per market factor. Every operational limit should be traceable back to the group statement.

A pre-committed response when a limit is breached. The most common weakness of appetite frameworks is that a breach triggers a discussion, not an action. Pre-commit: below X, monitor. Between X and Y, remediation plan within thirty days. Above Y, close the exposure. Boards find this uncomfortable and management often resists it — which is exactly why it works.

Independent measurement. If the first line measures its own consumption against appetite, appetite will not bind. The second line owns the calculation, and the third line reviews the methodology on a cycle. This overlaps with the three-lines governance model that I have written about separately.

ORSA and equivalents: forcing scenarios that matter

The Own Risk and Solvency Assessment is one of the most valuable regulatory instruments Solvency II introduced. Its value has nothing to do with the document — it comes from the scenarios chosen and the honesty with which management engages with them.

A useful ORSA has three or four narrative scenarios that stress the specific fragilities of the business, not the generic ones. For a monoline motor insurer, that means severity inflation combined with a legal reform; for a pension scheme, longevity plus a real-rate collapse; for a bank, an asset-quality shock combined with deposit flight. Copying the regulator's illustrative scenarios wastes the exercise.

The ORSA report should also project — not just describe — the balance sheet under each scenario over the business planning horizon, using the same assumptions and the same models the business uses for its own plan. When the ORSA numbers diverge from the business plan, there is a governance conversation to be had. That conversation is the point.

I cover scenario construction and board use in more depth in the ORSA scenario design note. For financial firms, this connects to the capital modelling guide I use with clients.

The taxonomy problem

Every ERM function invests time in a risk taxonomy. Every ERM function eventually finds that the taxonomy is either too coarse to be useful or so granular that nobody can navigate it. The way out is to accept that a taxonomy has two jobs and they need different structures.

The reporting taxonomy is what appears in board packs, the ORSA, and regulatory returns. It should have seven to fifteen categories, mutually exclusive, stable over time. Do not change it lightly — comparability across years is a feature, not an accident.

The management taxonomy is what the first line uses to log, track, and act on issues. It can and should be more granular, and it can evolve as the business changes. The mapping from management to reporting taxonomy must be many-to-one and unambiguous.

Confusing the two is what produces the sprawling taxonomies that make ERM systems unusable. Separate them and both improve.

Emerging risks: build a habit, not a register

Every framework I have seen has an emerging-risk register. Almost none of them are useful. The register captures things that were already obvious when they were added — pandemic risk in 2019, geopolitical risk in 2022, AI in 2024 — and produces no advance warning at all.

What works is a quarterly habit rather than a document. A rotating group of first-line experts, second-line risk, and one external voice spends ninety minutes discussing what has changed in the operating environment. The output is one page. The discipline is that the group must identify at least one scenario the ORSA does not currently cover, and either explain why it should not, or feed it into the next ORSA cycle.

This turns emerging-risk work from a compliance exercise into an intelligence function. It also gives the board something concrete to react to, which is more than most emerging-risk registers ever produce.

Model risk sits inside ERM, not next to it

Firms that separate model risk management from ERM end up duplicating governance and, worse, treating models as a technical problem rather than a strategic one. Every model that informs a decision consumes risk-taking capacity, and its failure is a risk in its own right. That is a first-order ERM concern, not a footnote.

Practically, this means the same committee that approves risk appetite should approve the model inventory's materiality tiering and the remediation plan for material findings. The model risk remediation note sets out how I structure that in practice, and independent model validation is the service line that delivers it.

The board relationship

The single largest predictor of whether ERM works in a given organisation is the quality of the relationship between the Chief Risk Officer and the board. Frameworks help, but no framework survives a CRO who cannot get uncomfortable messages heard.

Two practical suggestions. First, the CRO should own no more than five metrics on the board scorecard, and each should be one the CEO would rather not see. If everything on the risk dashboard is green, the dashboard is wrong. Second, the CRO should present alone to the board at least twice a year — without the CEO in the room. This is a hard cultural change to make and worth the fight.

Closing

Enterprise risk management is not a project. It is a habit of connecting decisions to risk, calibrating appetite so it binds, choosing scenarios that hurt, and letting the results change the plan. The frameworks are largely interchangeable. The choices above are not.

If you are rebuilding an ERM function or preparing an ORSA cycle that will actually get used, I am happy to talk. See the enterprise risk services page or get in touch.