What is a risk management framework?

A risk management framework is the structure that defines how an organisation identifies risk, scores it, decides what to do about it, and checks whether that decision held: who owns each step, what method they use, and how it gets reported upward.

Ask which one to use and the phrase splits in two. Some frameworks you adopt: ISO 31000, COSO ERM, NIST RMF, built by a standards body and available to anyone. One you have to write yourself, and if a supervisor or a board has asked for one, that is usually the one they mean. A compliance and risk management platform like Copla can store what you write. It cannot write it for you.

What follows covers the components, the frameworks you can adopt, and the one you cannot.

What every risk management framework contains

Every standard names these parts differently, and the differences matter less than they look. ISO folds three of them into one stage called risk assessment. COSO gives governance its own component. NIST buries most of it inside control selection.

Strip the vocabulary away and five core components have to exist somewhere in any of them, forming a structured approach rather than a loose checklist: someone accountable, a way risks get onto the list, a way to score them, a decision about what to do with each one, and a loop that checks whether the decision held. Effective risk management comes from how well an organisation runs these five, not from which standard’s labels it borrows.

Risk governance

Most guides list risk governance last, as a footnote about roles and responsibilities. It belongs first.

Before anyone identifies a single risk, someone has to own three things:

• Who sets the risk appetite the organisation is willing to carry.
• Who signs off acceptance, when a risk gets carried rather than treated.
• Who answers for it, when a board or a regulator asks why a particular exposure was allowed to sit.

Without a named owner at each of those points, what exists is a methodology, not a framework.

That accountability has to survive the person who first set it up leaving the business. Governance structures are also where the risk appetite statement gets set: the documented threshold that later tells identification and scoring what actually counts as significant, rather than leaving every risk on the register looking equally urgent. This is corporate governance applied to risk specifically, not a separate discipline sitting next to it.

Risk identification

That means starting from an inventory of the systems, vendors, processes and dependencies actually in use, not from a workshop where six people list whatever they remember going wrong last year.

A register built from a generic template, or from an hour of recall, inherits somebody else’s business: swap the company name and nothing else in it would need to change. One built from your own assets, vendors and dependencies reflects yours, gaps included, because no template already knows what your organisation runs on.

Risk identification also has to span every one of the risk categories the business actually carries, not only the ones a workshop happens to find memorable:

• Financial risks: exposure tied to revenue, cost or capital.
• Operational risks: process and delivery failures.
• Compliance risks: breaches of a regulatory or contractual obligation.
• Technical risks: system, infrastructure and vendor failure.

It is also not a one-off event: new vendors, new systems and new processes change what could go wrong, so the input to this step has to update continuously, not get revisited whenever the next audit is booked.

Assessment and scoring

Assessment turns a list of risks into a ranking. Risk scoring means assessing risks for likelihood and impact, on a scale applied the same way every time, so the result can be compared across the whole register rather than argued about one entry at a time.

Some organisations add a financial figure to the highest-priority risks: an estimated cost if the risk materialises, stated in terms a board already uses for every other decision. That is a useful addition to the scoring, not a replacement for it.

What matters is whether the method gets applied identically, regardless of who is scoring or when.

Skip that discipline and a register still produces numbers, just not a ranking anyone can trust, and emerging risks end up scored on the same inconsistent basis as everything already on the list.

Treatment

Every risk on the register gets one of four responses: mitigate it, transfer it, avoid it, or accept it. Risk mitigation strategies are the most familiar route, but they are not the only legitimate one:

• Mitigation reduces the likelihood or the impact, through a control or a process change.
• Transfer shifts the financial consequence elsewhere, typically through insurance or a contract clause.
• Avoidance removes the activity that creates the risk.
• Acceptance carries the risk as it stands, a legitimate choice, not a gap in the process, provided someone with the authority to carry that exposure has signed off on it and left a documented rationale, not a verbal understanding that evaporates when someone changes jobs.

Controls sit downstream of this step, not ahead of it. Implementing controls because a checklist demanded them, before anyone worked out what needed controlling or which control objectives applied, solves a problem nobody named.

Monitoring and reporting

Risk monitoring closes the loop. Every treatment decision gets tracked until it is actually finished, not logged as agreed and left there.

Whatever remains once treatment is applied is residual risk, and it needs the same discipline as everything upstream of it: recorded, owned, and accepted by someone with the standing to accept it. Many programmes track this through key risk indicators, metrics that move before a risk actually materialises, rather than waiting for an incident to prove the register was wrong.

Continuous monitoring, not an annual pass, is what catches emerging threats before they become findings. The register should move when the business moves, not sit still until the next audit forces a look.

Reporting is what the whole loop is for: a board needs exposure stated in terms it can act on, and an auditor needs a decision it can trace back to a reason. A framework that produces neither one is generating paperwork, not managing risk.

The frameworks you can adopt

Five names come up whenever this question gets asked, and they are not competing for the same job. ISO 31000 gives you language and structure. COSO ERM connects risk to strategy at board level. NIST RMF and NIST CSF 2.0 come out of the same US federal body and answer different questions from each other. FAIR replaces a rating scale with a number a finance team can use.

Most organisations using more than one of these are not choosing between them; they are layering one for enterprise-wide structure over others built for narrower risk domains underneath it.

ISO 31000

ISO, the International Organization for Standardization, publishes 31000 as principles and guidelines, not a set of requirements. It sets out how to embed risk management into governance and decision-making at any organisation, of any size, in any sector.

Its 2018 revision made explicit what earlier guidance left implicit: consideration of human and cultural factors, and continual improvement as an ongoing discipline rather than a one-off fix.

What it does not give you is anything to be audited against. ISO 31000 is explicit that it provides good-practice guidance rather than a certifiable standard, which is the detail most comparisons skip past: nobody performs an “ISO 31000 audit,” because there is no certification scheme sitting behind it the way there is for ISO 27001.

First published in 2009 and revised in 2018, it fits an organisation that wants a defensible structure and a shared vocabulary for talking about risk, board included, and is not looking for a certificate to put on a wall. It is a solid foundation to build a programme on, though building on it is not the same as proving the programme works.

COSO ERM

COSO, the Committee of Sponsoring Organizations of the Treadway Commission, is better known first for Internal Control, the framework most auditors learn before any other. Its enterprise risk management framework is the newer, wider one, originally published in 2004 as an integrated framework and updated in 2017 to connect risk explicitly to strategy and performance rather than stopping at control design.

It is built around five components across 20 principles:

• Governance and culture
• Strategy and objective-setting
• Performance
• Review and revision
• Information, communication and reporting

Its argument is that risk management only works when it sits inside strategy-setting rather than beside it, which is why the framework spends as much space on board-level business objectives as it does on control performance for individual risks.

That makes it a strong fit for a larger organisation, banks and other financial institutions among them, whose board already expects risk exposure discussed in the same conversation as strategic performance. It is a poor fit for a mid-market team that needs an ICT risk register finished by the third quarter.

COSO ERM answers a corporate governance question about how risk connects to organisational objectives. It has little to say to a compliance officer with thirty vendors and one spreadsheet, wondering where to start on Monday morning.

NIST RMF

NIST, the National Institute of Standards and Technology, publishes the Risk Management Framework, RMF, as one specific document: Special Publication 800-37, currently at revision 2, defining a seven-step process for US federal information systems and the contractors who serve them.

Categorising risks by system impact happens in step two, deliberately, before any control gets selected. The whole process exists to reach an authorisation to operate a system, not to manage risk across a business generally.

A good share of what ranks for “NIST risk management framework” actually describes a generic five-part cycle instead, identify, assess, respond, monitor and similar, and attributes it to NIST. NIST did not write that version. The confusion matters because RMF is also a different document from the NIST Cybersecurity Framework, covered next, and the two get conflated constantly.

NIST RMF fits an organisation operating in, or selling into, the US federal government, where the FISMA requirement to use it is not optional. For a financial entity regulated under DORA or NIS2 in the EU, it is not the standard a supervisor has in mind, whatever a generic ranking guide implies.

NIST CSF 2.0

The NIST Cybersecurity Framework is voluntary guidance for managing cybersecurity risks, organised around outcomes rather than prescribed methods: it describes what a well-managed cyber-risk posture looks like without mandating the specific controls that get you there.

Version 2.0, released in 2024, added a sixth function, Govern, formalising something the first version left implicit: that cybersecurity decisions are a board-level risk question, not only a technical one.

It suits an organisation that wants a common vocabulary for cyber threats that a technical team and an executive team can both use without translation.

Its limit is its design choice. CSF describes the outcome, not the method to get there. That is genuinely useful for a team with the maturity to fill in its own methods. For a team of one, already stretched across several other jobs, an outcomes list with no attached method is a description of the destination, not a route to it.

FAIR

FAIR, Factor Analysis of Information Risk, replaces a red-amber-green scale with a number: loss frequency multiplied by loss magnitude, expressed in the same currency a board already uses for every other decision.

The FAIR Institute positions it as the only international standard for quantifying cyber and operational risk in financial terms, and the Open Group has ratified the underlying methodology as a formal technical standard.

What that precision costs is rarely stated plainly. A FAIR model needs loss data, calibrated estimates, and someone who understands the statistics well enough to know when an output is meaningful and when it is not. Feed it guesses dressed up as inputs and it returns a guess dressed up as precision: a number confident enough to be quoted in a board pack and wrong enough to be dangerous.

FAIR fits an organisation with a risk function able to build and maintain that data pipeline. It is the wrong first framework for a team still building its asset inventory.

The framework you have to write yourself

None of the five frameworks above is what a DORA supervisor means when asking for your DORA ICT risk management framework. The confusion is easy to understand: the phrase is identical to the one used for ISO 31000 or COSO ERM, and most of what ranks for it was written about those instead.

DORA requires every financial entity in scope to have “a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system” (Article 6), reviewed at least once a year and reported to the competent authority on request. Article 5 puts the management body on the hook directly: it must define, approve, oversee and take ultimate responsibility for that framework, not delegate it and move on.

NIS2 places comparable regulatory obligations on who NIS2 applies to: essential and important entities must take appropriate and proportionate risk-management measures under Article 21, with management-body approval and liability for getting it wrong under Article 20.

Writing that document means describing your organisation as it actually operates: its critical functions, its dependencies, its risk appetite, and the controls that respond to what you have actually found, in language specific enough that someone who has read fifty of these could still tell yours apart from a template.

Regulatory compliance here is not a certificate you hold. It is a document a supervisor can open at any time and recognise as yours.

The adopted frameworks are not wasted here. ISO 31000 gives you a structure to write it in. ISO 27001 gives you a management system to keep it alive inside. Neither one is the deliverable a supervisor is asking for. That one, you write yourself.

How to build a risk management framework that holds up

Knowing what a framework needs to contain does not tell you what order to build it in, and that order is most of why programmes stall.

1. Start with what the business actually depends on: the systems, vendors, processes and the dependencies between them. A register built without that inventory is guesswork wearing formatting.
2. Run a business impact analysis before you score anything, so criticality comes from analysis rather than instinct. Skip this step and every risk tends to end up rated high, because nothing has told the scoring what actually matters most.
3. Set the risk appetite and the accountability at leadership level.
4. Build the register itself, against the real assets and the real impact analysis, not a template borrowed from a vendor’s onboarding deck.
5. Apply controls where a specific risk justifies one, each mapped to the regulatory requirements or control objectives it actually satisfies, rather than added because an auditor expects to see it.
6. Set review triggers, not just review dates: a new vendor, an incident, a regulatory change should each reopen the register on its own, not wait for the calendar to catch up. That is ongoing monitoring and continuous improvement in practice, not slogans on a policy’s cover page.

This sequence decides whether the finished framework survives contact with a supervisor. Most compliance teams can get this far unassisted. An automated risk management platform, or an in-house CISO team brought in to run the process, only decides how much it hurts to maintain afterwards.

The five components above are not difficult to build individually. What decides whether the result is a framework a supervisor accepts, or a document that sits in a folder until the next audit, is whether it was written for your business specifically, and whether the frameworks you adopted gave you structure rather than a substitute for the one you still had to write. Book a demo to see how Copla approaches that part of the work, not just the part every guide already lists.