What should an ERM framework document include?

At minimum: risk appetite (how it is set and reviewed), risk descriptions and categories (taxonomy), risk library management, risk event recording, assessment methodology (scoring system and matrix), roles and responsibilities, and reporting/escalation cadence.

How do you right-size an ERM framework for an SME?

Start small and iterate. Avoid copying 60-page bank policies. Focus on what your organisation actually needs: clear definitions, a practical scoring system, assigned ownership, and a reporting cadence that matches your governance cycle. A framework that is clear, consistent, and actually used beats a perfect document nobody reads.

Back to Articles and Learning

Risk Management7 min read

How to Build an ERM Framework: The Essential Guide

Elliot Poublan

Dec 30, 2025

Updated Apr 21, 2026

How to Build an ERM Framework: The Essential Guide

At first, Enterprise Risk Management (ERM) can sound daunting. Frameworks, taxonomies, appetites, libraries - if you've been tasked with this, read this first and then let us know how you feel after. Here's the truth: at its heart, ERM is simply about creating a structured way to think about risk, write it down, evidence what you're doing to control it, and make sure everyone in the business is playing by the same rules.

In short

An ERM (Enterprise Risk Management) framework is the documented operating model for how an organisation identifies, assesses, owns, monitors and reports risk - so investors, regulators, the board and the executive all work to the same rules.

Core chapters - risk appetite, taxonomy, risk library, risk events, assessment methodology, roles and responsibilities, reporting and escalation.
Right-sized - SMEs do not need a 60-page bank policy; they need a clear, consistent framework that actually gets used.
Why it matters - boards, regulators and investors expect to see structure and accountability, not good intentions.
Make it real - socialise it, embed it in onboarding, link it to your actual risk register and reporting cadence.

So where do you begin? Let's strip it back to the basics.

So Why Do We Need a Framework?

At some point, informal approaches stop being enough.

Investors want to see risks tracked and managed before they commit serious capital.
Regulators expect evidence of governance, not just good intentions.
The Board needs clarity: what are our biggest risks, how exposed are we, and what are we doing about it?
Leadership teams get tired of inconsistent reports and need a single source of truth.

A framework gives structure, credibility, and consistency - the things that informal spreadsheets and ad-hoc reports eventually fail to deliver.

Real-World Example

When Informal Risk Management Breaks Down

A mid-sized technology company with 300 employees had been managing risks informally for years. Each department kept its own spreadsheet. When a potential investor asked to see their risk register during due diligence, the CFO spent three days trying to consolidate 12 different Excel files with conflicting definitions, duplicate risks, and no clear ownership. The investor walked away, citing "lack of governance maturity" as a concern. The company lost a £15 million investment opportunity. Six months later, they implemented a proper ERM framework. When the next investor came knocking, they had a single, coherent risk register ready in 30 minutes. That's the difference a framework makes.

You Need a Document (Yes, Really)

The starting point for any ERM framework is boring but essential: a document. Call it your ERM Framework, ERM Policy, or Risk Management Policy - the label doesn't matter. What matters is that it clearly sets out:

Why risk management exists in your organisation.
How it will be carried out day to day.
Who is responsible for what.

Without it, you end up with risk owners pulling in different directions, executives getting inconsistent reporting, and everyone arguing about what a "high" risk actually means.

Make It Real: Socialise the Framework

The second step is making sure the document isn't just gathering dust on the intranet. A framework only works if people know about it, understand it, and use it.

That means:

Rolling it out through training or workshops - not just emailing a PDF.
Embedding it in onboarding for new staff so it becomes part of your culture.
Making sure executives reference it when risks are discussed - use it in meetings, not just in theory.
Linking it to your actual risk management tools - if your framework says "risks are assessed quarterly," make sure your system enforces that.

Risk management shouldn't live in a binder - it should live in the business. The best frameworks are the ones people actually remember and use, not the ones that look impressive in a policy library.

The Core Chapters

Every ERM framework looks slightly different, but the essentials don't really change. At minimum, your document should define how your organisation will approach:

1. Risk Appetite

Not the actual appetite itself, but how it is set, reviewed, and approved. Who owns it? How often is it revisited? How does it guide decision-making?

2. Risk Descriptions & Categories

The taxonomy. A framework should define the language and categories the business will use to describe risks - so everyone is consistent.

3. Risk Library

How risks are captured and maintained. Do you have a central library? Who updates it? How do you stop duplicates creeping in?

4. Risk Events

How the organisation records and responds when risks materialise. The framework should lay out the process: when do you log an event, and who reviews it?

5. Assessment Methodology

The scoring system. The framework should set the rules for how likelihood and impact are assessed, and how residual risk is derived. Define your risk matrix (e.g., 5x5 or 4x4), what each level means in practical terms, and how you calculate residual risk after controls. The actual scores live in your risk register, not in the framework - but the framework sets the rules everyone must follow.

6. Roles and Responsibilities

The who. Risk Owners, Control Owners, the Risk Team, Executives, the Board - the framework spells out responsibilities and escalation lines.

7. Reporting and Escalation

The cadence. How often risks are reviewed, how results are reported upwards, and what triggers escalation.

For more mature firms, ERM Frameworks may include approach to gathering and reporting Key Risk indicators (KRIs), Horizon Risks and your approach to Controls within your organisation.

Why This Matters

Without a structured ERM framework, risk management becomes reactive and fragmented. You'll spend more time debating definitions than managing risks. With one in place, everyone knows the rules of the game - and that clarity pays dividends when investors, regulators, or the Board ask the tough questions.

Consider this: when a regulator asks "How do you assess risk?" you want to point to a documented framework, not explain it off the cuff. When an investor asks "What's your risk appetite?" you want to show them a clear policy, not give them a vague answer. When the board asks "Who owns this risk?" you want a framework that spells it out, not a conversation about "we think it might be..."

Trust me - when an investor, or third party asks you whether you have this document - you want it ready to go and not just in your head.

Right-Sizing Your Framework

The biggest mistake SMEs make is copying a 60-page ERM policy from a bank or insurance company. Overkill frameworks are as bad as no framework at all, as in the end, you don't end up relating to it, it receives no buy-in and doesn't get executed.

Common Mistake

The 60-Page Framework That Nobody Read

A professional services firm with 150 employees decided to "do ERM properly" by copying a major bank's ERM framework document. The result? A 58-page policy document that referenced systems they didn't have, processes they couldn't implement, and roles that didn't exist in their organisation. The Risk Manager spent six months writing it. The board approved it. And then... nothing. Nobody used it. Risk owners found it too complex. Executives couldn't relate to it. Three years later, during an audit, they discovered that only 2 people in the entire company had actually read it. They had to start over with a practical, right-sized framework that matched their actual needs. The lesson? A framework that's perfect on paper but unusable in practice is worse than no framework at all.

Start small, keep it practical, and iterate as you mature.

Think of it this way: your ERM framework doesn't need to be perfect; it just needs to be clear, consistent, and actually used.

In short: you need a framework because at some point, informal risk management stops cutting it. Document it, socialise it, and make sure the basics are covered - appetite, categories, library, events, assessments, roles, and reporting. That's the foundation of ERM done well.

Once your framework is in place, the next step is choosing how to assess risk within it. See how to assess enterprise risk: four approaches explained. For the governance model that sits on top, read the 3 Lines of Defence model in risk management. And when it's time to report to the board, see how to produce board-ready risk reports.

If you are still building the operating layer beneath the framework, read our guides on what a risk register actually is and when to move from Excel to a GRC tool. And for the business case behind the work, see the ROI of GRC and how risk management creates value.

Frequently asked questions

What should an ERM framework document include?: At minimum: risk appetite (how it is set and reviewed), risk descriptions and categories (taxonomy), risk library management, risk event recording, assessment methodology (scoring system and matrix), roles and responsibilities, and reporting/escalation cadence.
How do you right-size an ERM framework for an SME?: Start small and iterate. Avoid copying 60-page bank policies. Focus on what your organisation actually needs: clear definitions, a practical scoring system, assigned ownership, and a reporting cadence that matches your governance cycle. A framework that is clear, consistent, and actually used beats a perfect document nobody reads.