How to Build an ERM Framework

Building an effective ERM framework requires more than adopting a recognised methodology, it requires clear governance, accountability and consistent execution. This guide walks through the key stages of creating a practical framework that supports better decision-making across the organisation. It also highlights the common pitfalls that prevent ERM programmes from delivering value.
5 min read time

Building an effective enterprise risk management framework is one of the most consequential things a risk manager or CRO can do for their organisation. Get it right and leadership has a reliable basis for navigating uncertainty, making better decisions, and demonstrating governance quality to regulators and stakeholders. Get it wrong, or skip the foundations, and risk management becomes reactive, fragmented, and largely decorative.

Most ERM framework failures are not failures of methodology. The COSO and ISO 31000 frameworks are well documented and widely understood. Failures are almost always failures of implementation: governance that looked clear on paper but lacked genuine accountability; risk appetite statements that were approved and then never used; and risk registers that were updated annually and ignored the rest of the time.

This guide covers the practical steps involved, from governance and risk appetite through to technology selection and cultural embedding, with attention to the implementation choices that most commonly determine whether the framework actually works.

What an ERM Framework Actually Is

An ERM framework is the structured system through which an organisation identifies, assesses, manages, monitors, and reports on risk. It is not a risk register in isolation, a policy document, or a software platform. It is the overall architecture that connects risk to strategy, assigns accountability, ensures risk information flows to the right people at the right time, and creates the conditions under which the board can exercise genuine governance over risk.

Both the COSO ERM Framework and ISO 31000 provide recognised foundations on which most organisations build their bespoke frameworks. Neither should be adopted wholesale without adaptation to the organisation's specific sector, regulatory context, size, and risk profile. The frameworks are inputs to design, not templates to be implemented verbatim.

Step 1: Establish Governance and Accountability

Why Governance Comes First

A framework without genuine governance accountability is a collection of documents and processes that nobody is truly responsible for. This is the most common single reason ERM frameworks fail to deliver. Before designing any specific component, the accountability architecture needs to be explicit, agreed, and enforced.

The Three Lines Structure

The IIA's Three Lines Model provides the standard structure for distributing risk management responsibility. The first line, operational management, owns and manages the risks in their area. They are not merely recipients of risk reporting; they are accountable for identifying risks, maintaining controls, and updating the risk picture as their environment changes.

The second line, the risk and compliance function, designs the framework, sets methodology, provides training and support, challenges first-line assessments, and consolidates the risk picture for management and board reporting. The second line does not own the risks. Its role is oversight and challenge, not substitution for first-line accountability.

The third line, internal audit, provides independent assurance that the first and second lines are functioning as intended, reporting directly to the board or audit committee.

Board-Level Accountability

The board bears ultimate responsibility for the organisation's approach to risk. This means approving the ERM framework and the risk appetite, receiving and engaging with risk reporting, and holding management accountable for the quality of the programme. The FCA's systems and controls sourcebook is explicit about these expectations for regulated firms.

Naming individual risk owners for each significant risk is equally important. Without named ownership, risks get monitored by the risk function but managed by nobody. The owner is accountable for managing the risk, not for performing all the work associated with it, but for ensuring it is adequately addressed and escalated when necessary.

Step 2: Define Risk Appetite

What Risk Appetite Actually Means

Risk appetite is the amount and type of risk the organisation is willing to accept in pursuit of its objectives. It is the cornerstone of any ERM framework and one of the most frequently poorly executed components in practice.

Vague appetite statements provide no practical governance value. "We have a low appetite for reputational risk" tells nobody what they can or cannot do. A specific statement that "we will not enter commercial relationships with parties subject to regulatory sanction in the past three years" is actionable, communicable, and can be monitored.

Setting Appetite at the Right Level

Risk appetite must be set by the board, not determined by the risk function. The board's job is to decide, in the context of the organisation's strategic objectives, how much risk is acceptable to take on in pursuit of those objectives. The risk function's job is to provide the information that supports that decision, not to make it.

Appetite should cover the main risk categories in the taxonomy with specific enough statements for each that a manager in the business could use them to guide decisions. Quantitative thresholds are preferable where they are achievable: maximum acceptable financial loss from operational failures, KRI breach levels that trigger escalation, control testing pass rate thresholds below which the risk position is considered outside appetite.

Monitoring and Enforcing Appetite

Appetite only functions as a governance mechanism when actual risk positions are regularly compared against it, with clear processes for escalating and responding to breaches. If breaches consistently occur without consequence, the appetite statement has been reduced to a governance formality.

Step 3: Develop a Risk Taxonomy

A risk taxonomy is a consistent classification system for the types of risk the organisation faces. Without one, different teams use different language, the same underlying risk gets categorised differently across business units, and consolidation into an enterprise risk picture is unreliable.

What a Taxonomy Should Cover

A taxonomy for most organisations covers strategic risk, encompassing the risks arising from strategic decisions and the external environment; operational risk, arising from people, processes, systems, and external events; financial risk, covering market, credit, and liquidity exposures; compliance and regulatory risk; technology and cyber risk; people and talent risk; reputational risk; environmental and climate risk; and third-party and supply chain risk.

The right taxonomy reflects the actual risks the organisation faces, not a generic framework list. A small credit union has a different risk profile from a multinational insurer. The taxonomy should reflect that.

Keeping the Taxonomy Current

As the organisation's risk environment changes, the taxonomy may need to evolve. AI governance risk, for example, was not a prominent taxonomy category five years ago and is now a significant concern in most sectors. A taxonomy review as part of the annual framework review is good practice.

Step 4: Design the Assessment Methodology

Likelihood, Impact, and Consistency

The standard risk assessment approach evaluates each identified risk on two dimensions: likelihood, how probable is materialisation over a defined horizon, and impact, how severe would the consequences be if it did. The combination produces a risk rating that allows risks to be ranked and prioritised.

Consistency matters more than sophistication. A simple, clearly defined scale applied consistently across the organisation produces more useful risk data than a theoretically elegant methodology applied differently by different assessors. Every risk owner using the same definition of "high likelihood" and "high impact" is a more important goal than methodological precision.

Inherent vs Residual Risk

The distinction between inherent risk, before any controls are applied, and residual risk, after controls are considered, is fundamental to a credible risk register. The gap between the two represents what the control environment claims to be achieving. Where that gap is large, meaning the risk function claims controls are significantly reducing a high inherent risk, that claim needs to be independently evidenced, not simply accepted. This is where internal audit's testing of control effectiveness directly supports the reliability of the risk register.

Calibration Across the Organisation

Without calibration, a high-risk rating in one business unit and a high-risk rating in another may represent very different levels of actual exposure. Cross-functional calibration workshops, where risk owners discuss their ratings together, produce more consistent and more reliable risk pictures than individual assessments submitted in isolation.

Step 5: Build the Risk Register

The risk register is the operational core of the framework. A well-designed register captures: the risk description, specific enough that someone unfamiliar with the area could understand what could go wrong and how; the risk category from the taxonomy; the named risk owner; the inherent risk rating covering likelihood and impact; the current controls in place, with an assessment of their effectiveness; the residual risk rating reflecting the position after controls; actions required with defined owners and due dates; key risk indicators being monitored and their current status; and the date of last review.

The Living Register Problem

The most common risk register failure is treating it as a document rather than a living record. A register updated comprehensively once a year and left unchanged for the remaining eleven months is not providing ongoing risk intelligence. It is providing a historical snapshot. Registers should be updated as risk positions change, controls are tested and results recorded, and actions are completed.

Step 6: Connect Risk to Strategy and Planning

A mature ERM framework is not a parallel process running alongside strategic planning. It is embedded within it. This means risk assessments are conducted as part of new strategic initiative development, not retrospectively after commitments are made. Board and executive papers include explicit risk considerations. Strategic planning cycles begin with a view of the current risk landscape as context for objective-setting.

When risk management exists alongside strategic decision-making without connecting to it, it adds administrative overhead without influencing outcomes. When it is genuinely integrated, it changes how decisions are made.

Step 7: Establish Monitoring and Reporting

Key Risk Indicators

Key risk indicators are metrics that provide early warning of increasing risk exposure before incidents occur. A well-designed KRI moves before the risk event, giving the organisation an opportunity to act rather than react. Staff turnover in critical functions is a KRI for people risk. System availability statistics are a KRI for technology risk. Overdue compliance actions are a KRI for regulatory risk.

KRIs need defined thresholds that connect to appetite, with pre-designed responses for amber and red breaches. A KRI that breaches its threshold and triggers no response has not served its early warning purpose.

Reporting Structure

Operational risk owners should update their risk positions monthly, or more frequently in volatile environments. Management-level reporting consolidates this into an executive view. Board reporting provides a high-level picture of top risks, appetite status, emerging threats, and significant changes, typically quarterly.

The quality test for board reporting: can a board member, having read the report, form a genuine view of where the organisation's most significant risks lie and whether they are being adequately managed? If the answer is no, the reporting is not serving its governance purpose.

Step 8: Select the Right Technology

Managing a meaningful ERM framework on spreadsheets is a significant constraint. Version control problems, manual errors, inconsistent data entry, and the time required to compile board reports from multiple sources all limit what is achievable.

Purpose-built ERM software provides a single, centralised risk register accessible to all relevant stakeholders; standardised assessment and scoring; automated monitoring and alerts when KRIs breach thresholds; board-ready reporting generated from live data without manual compilation; and support for the three lines governance model with appropriate access controls.

The critical selection criterion is whether the platform supports your risk framework or requires you to adapt your framework to fit the software. A platform that forces a methodology that does not reflect how the organisation actually thinks about and manages risk will either be poorly adopted or will produce risk data that does not mean what the labels say. ISO 31000's principle that the risk management framework should be customised to the organisation's context applies directly to technology selection.

Step 9: Embed Through Training and Culture

A framework that lives in a document or platform but is not understood or used by the people responsible for managing risk is not working, regardless of how well it is designed. Embedding ERM in organisational culture is the most difficult and most important dimension of implementation.

What Embedding Requires

Clear training for all risk owners covering their responsibilities, the assessment methodology, and how to use the risk register. Consistent communication from senior leadership about why risk management matters and how it connects to the organisation's objectives. Visible use of risk information in actual decisions, demonstrating that the framework has real influence rather than existing for compliance purposes. And consequences for non-engagement that are proportionate but real: risk owners who persistently fail to maintain their risk information without consequence send a clear signal to the rest of the organisation about whether the framework is taken seriously.

Step 10: Review and Continuously Improve

An ERM framework is never finished. The environment in which it operates changes, and the framework must change with it. An annual review of the framework itself, separate from the ongoing review of individual risks, should assess whether the taxonomy still reflects the organisation's actual risk landscape, whether risk appetite remains appropriate given strategic developments, whether reporting is meeting board needs, whether technology is enabling or limiting the programme, and whether the governance structure is producing genuine accountability or nominal compliance.

Maturity in ERM is a journey. Most organisations start with basic risk identification and periodic reporting and build progressively toward integrated, real-time risk intelligence connected to strategic decision-making. The key is that each iteration is genuinely better than the last, and that the improvement is driven by honest assessment of what is and is not working rather than by the desire to appear more mature.

References and Further Reading

Next Steps

Ready to elevate your enterprise risk management?

Join 150+ organisations who’ve already made calQrisk their competitive edge.