Risk Management Frameworks: Which One, and How

A risk management framework is a repeatable method for deciding what could go wrong, how much it matters and what you are going to do about it. Every framework on this page does the same five things: set the context, identify risks, analyse and evaluate them, treat them, and monitor and report. The differences are where each one leans, what it produces at the end and who will accept that output. NIST RMF produces an authorisation for one system. ISO 31000 produces principles a whole organisation can build on. COSO ERM produces a board conversation. FAIR produces a number in currency. OCTAVE produces a worksheet a small team can finish in a week.

That is the whole guide in one paragraph, and it is more than most of the pages ranking for this query manage. What follows is the detail: each framework as it actually stands in its current edition, the regulation that quietly expects each one, a decision tree that picks the framework from four questions, and a ninety-day plan that ends with a register a board has read. If you already know which framework you need and want the working page, it is the risk management module, and the risk register template is the artefact every one of them ends in.

What is a risk management framework, and what is it not?

A framework is the method: the steps you follow, the roles that follow them, the criteria you score against and the cadence you repeat it on. It is not the same as a standard, which is a published set of requirements you can be assessed against, and some of which you can be certified to. It is not the same as a process, which is the framework applied to one scope this quarter. And it is not the register, which is the record the process leaves behind. The pages that rank for this query use all four words for each other. Auditors do not, and the distinction decides what you can claim. You can be certified to ISO 27001. You cannot be certified to ISO 31000, ISO 27005, NIST RMF, COSO or FAIR, whatever a vendor's badge suggests.

ISO 31000 defines risk as the effect of uncertainty on objectives. That definition matters more than it looks. It means a risk is not a threat or a vulnerability on its own; it is what uncertainty does to something you are trying to achieve, which is why every credible framework starts by asking what the objectives are before it asks what could go wrong. It also means risk can be positive, which COSO's strategy-linked framing takes seriously and most cyber-only frameworks ignore.

What does every risk management framework have in common?

Strip the vocabulary off and every framework performs the same five activities. It sets the context: scope, objectives, appetite, the criteria you will score with. It identifies what could go wrong against those objectives. It analyses each risk for likelihood and impact and evaluates it against the criteria, which is where the priority comes from. It treats the risks that sit above appetite, by avoiding, reducing, sharing or accepting them. And it monitors the result and reports it to whoever owns the outcome. Governance wraps the loop: who is accountable, who challenges, who assures.

What differs is emphasis. ISO 31000 is strongest on the principles that should shape every step and says least about how to score. NIST RMF is almost entirely about selecting and authorising controls for one system, and hands the analysis itself to a separate publication, SP 800-30. ISO 27005 is the analysis and treatment loop written for ISO 27001. FAIR is the analysis step alone, done in money. OCTAVE is identification for teams without a risk function. COSO is governance and strategy with the loop underneath. The useful question is not which framework is best but which step you are weakest at and who is going to ask for the output.

What are the seven steps of the NIST Risk Management Framework?

The NIST RMF, published as SP 800-37 Revision 2, is a seven-step process for managing security and privacy risk to one information system at a time. Several of the pages above still describe it as six steps. Revision 2, published in December 2018, added Prepare at the front, and NIST's own description of the framework has listed seven ever since. The steps, in NIST's words, are:

1. Prepare. Essential activities to prepare the organisation to manage security and privacy risks: roles, a risk management strategy, risk tolerance, common controls.
2. Categorize. Categorise the system and the information it processes, stores and transmits, based on an impact analysis. FIPS 199 supplies the low, moderate and high impact levels.
3. Select. Select the set of SP 800-53 controls to protect the system, based on the risk assessment, and tailor the baseline.
4. Implement. Implement the controls and document how they are deployed.
5. Assess. Determine whether the controls are in place, operating as intended and producing the desired results. SP 800-53A holds the assessment procedures.
6. Authorize. A senior official makes a risk-based decision to authorise the system to operate. This is the step no other framework has: a named person accepts the residual risk in writing.
7. Monitor. Continuously monitor control implementation and risks to the system, and feed what changes back to the start.

Two things the RMF is not. It is not an enterprise risk framework; it scopes one system, and an organisation running it across fifty systems still needs COSO, CSF 2.0 or ISO 31000 for the aggregate view. And it does not contain a scoring model. The likelihood-and-impact analysis lives in SP 800-30, which the RMF calls at the Categorize and Select steps. It is mandatory for US federal information systems and is the backbone of FedRAMP and of CMMC assessments, whose RA.L2-3.11.1 practice is a risk assessment in this mould. Outside that world it is borrowed by organisations that want the Authorize step: a control-selection discipline with an accountable signature at the end.

What does ISO 31000 actually require?

Nothing, strictly. ISO 31000:2018 is guidance, not a requirements standard, which is why no organisation is certified to it. What it gives you is a structure in three parts. Eight principles say what risk management should be: integrated, structured and comprehensive, customised, inclusive, dynamic, based on the best available information, aware of human and cultural factors, and continually improving. A framework, with leadership and commitment at the centre, says how to embed it: integration, design, implementation, evaluation, improvement. And a process says what to do: establish scope, context and criteria; assess risk through identification, analysis and evaluation; treat it; and run communication and consultation, monitoring and review, and recording and reporting alongside every step.

The 2018 edition was confirmed without change in 2023, so it is current. Its value is that it is sector-neutral and vocabulary-setting. When a regulator writes risk assessment, risk treatment or risk criteria into a law, it is using ISO 31000's words, and a programme built on it will translate into DORA, NIS2, Solvency II or GDPR without renaming anything. Its weakness is the same as its strength: it does not tell you how to score, and a team that starts here will need to borrow a scale from ISO 27005, a matrix from their sector, or FAIR.

How does ISO/IEC 27005 relate to ISO 27001?

ISO/IEC 27005:2022 is the fourth edition of the guidance on managing information security risks, and it exists to help you meet clause 6.1 of ISO 27001: the requirement to define and apply an information security risk assessment process, and a treatment process that produces the Statement of Applicability. ISO 27005 is not certifiable and contains no auditable requirements. The certification auditor tests your 6.1.2 process; 27005 is the most direct way to build one that passes.

What it adds to ISO 31000 is specificity. It distinguishes an event-based approach, which starts from what could happen to the organisation, from an asset-based approach, which starts from the asset inventory and its threats and vulnerabilities, and it lets you choose. It describes risk criteria, likelihood and consequence scales, the risk owner, and the four treatment options in the same terms 27001 audits use. If you are certifying, or answering NIS2 or DORA with an ISO 27001 core, this is the process framework, and the Annex A controls are what the treatment step selects from.

What is COSO ERM and why does SOC 2 care about it?

COSO's Enterprise Risk Management: Integrating with Strategy and Performance, the 2017 edition, replaced the 2004 cube that older articles still draw. It has five components and twenty principles. Governance and Culture (five principles) covers board oversight, operating structures, culture and talent. Strategy and Objective-Setting (four) covers business context, risk appetite, evaluating strategic alternatives and setting objectives. Performance (five) is the loop everyone recognises: identify, assess severity, prioritise, respond, and take a portfolio view. Review and Revision (three) handles substantial change, review of risk and performance, and improvement. Information, Communication and Reporting (three) is the reporting layer.

COSO matters beyond enterprise risk because it is the source of the risk assessment criteria in SOC 2. The Trust Services Criteria are built on COSO's internal control framework, and CC3.1 to CC3.4, the risk assessment criteria, are COSO principles six to nine restated. An organisation that speaks COSO will find its SOC 2 auditor speaking the same language. The framework's other distinctive contribution is the portfolio view: the insistence that risks be aggregated and compared across the organisation rather than scored in silos, which is exactly where most registers fail.

What is FAIR, and when should you quantify risk in money?

FAIR, Factor Analysis of Information Risk, is published by The Open Group as two standards, the Risk Taxonomy (O-RT) and the Risk Analysis (O-RA), and promoted by the FAIR Institute. It is the one framework here that produces a number rather than a colour. Risk is decomposed into loss event frequency, itself the product of threat event frequency and vulnerability, and loss magnitude, the sum of primary loss to you and secondary loss from the reactions of others: fines, customer churn, litigation. Each factor is estimated as a range with a confidence rather than a point, and the ranges are combined by Monte Carlo simulation into an annualised loss exposure, also as a range.

Use FAIR when the decision is about money: whether a control is worth its cost, how much cyber insurance to buy, which of two programmes to fund first, what to tell a CFO who does not accept that a 4 times 5 is worse than a 5 times 4. Do not use it to triage a hundred risks in an afternoon; a matrix does that faster. And do not mistake it for a control framework. FAIR tells you what a risk costs. It does not tell you which control to buy, and it says nothing about governance. Most organisations that adopt it run it on their top ten risks and leave the long tail on the matrix.

What is OCTAVE Allegro and who is it for?

OCTAVE Allegro, published by the Software Engineering Institute at Carnegie Mellon in 2007, is the streamlined successor to the original OCTAVE of 1999. It is an assessment method rather than a governance framework: four phases and eight steps that a single analyst or a small workshop team can complete with worksheets. Phase one establishes drivers, with step one setting the risk measurement criteria. Phase two profiles assets: develop the information asset profile, then identify the containers where it is stored, transported and processed. Phase three identifies threats: areas of concern, then threat scenarios. Phase four identifies and mitigates risks: identify, analyse, and select a mitigation approach.

Its distinctive move is to start from the information asset, not the network, which keeps a small team from drowning in infrastructure. Step one, the risk measurement criteria, is also quietly the appetite statement that every later framework will ask for, so a team that starts with Allegro has already written the hardest sentence. OCTAVE FORTE, released in 2020, is the enterprise governance version with ten steps, and belongs in the COSO and ISO 31000 corner of the map rather than here.

COBIT, NIST CSF 2.0, NIST AI RMF and ISO 42001: are they risk management frameworks?

Partly, and the distinction matters because three of them are routinely listed as if they were. COBIT 2019 is ISACA's framework for the governance of enterprise information and technology: forty governance and management objectives across five domains, of which one, APO12 Managed Risk, is the risk process. It is a governance framework that contains risk management, useful where IT governance and SOX-style control are the concern. NIST CSF 2.0, released in February 2024, organises cybersecurity outcomes under six functions, Govern, Identify, Protect, Detect, Respond and Recover, and its Govern function now carries the risk management strategy outcomes (GV.RM) that were implicit in 1.1. It is an outcome framework, not a risk process: it tells you what a mature programme achieves, and the profile method is how you measure the gap.

NIST AI RMF 1.0, January 2023, with a Generative AI Profile added in July 2024, is a genuine risk framework for one domain: four functions, Govern, Map, Measure and Manage, applied to AI systems. ISO/IEC 42001:2023, published in December 2023, is a management system standard in the ISO 27001 mould. It contains a risk assessment requirement, and it is certifiable, but it is not a risk management framework any more than ISO 27001 is; it is the system a risk framework runs inside. Both are what you reach for when the EU AI Act Article 9 asks a provider of high-risk AI for a risk management system across the lifecycle.

Which framework does each regulation expect?

None of them names one. Every regulation on this table requires the outputs a framework produces, a method, a register, a decision and a review date, and leaves the framework to you. That is liberating and dangerous in equal measure: you may use any method, and you must be able to show it was one.

The practical consequence is that one process can serve every regime you answer to, provided it produces the artefacts each one names. This is what a control crosswalk exists for: the risk is assessed once, the treatment is a control, and the control is mapped to every clause that requires it. Organisations that run a separate risk process per regulation end up with five registers that disagree.

How do you choose a risk management framework?

Four questions decide it, and the first is not about you. Who is asking for the result? A board or investor wants enterprise language and a link to strategy, which is COSO ERM or ISO 31000. An auditor or regulator wants the process their regime names, which sends you to ISO 27005 for the ISO 27001, NIS2 and DORA family, to NIST RMF with SP 800-30 for US federal, CMMC and FedRAMP work, and to COSO for SOC 2 and Solvency II. A CFO or insurer wants a number, which is FAIR. Then the size of the team: if fewer than ten people will do the work, start with OCTAVE Allegro's worksheets and grow into the regime's framework once the first register exists; if more, adopt the regime's framework directly and add FAIR for the ten risks that decide budgets.

How do you implement a risk management framework in ninety days?

Ninety days is enough for one framework, one legal entity and an owner with a day a week to reach a register the board has read. The plan below assumes that. Groups multiply it by the number of entities that need their own register, which under DORA and NIS2 is usually all of them.

Days 1 to 15: decide and scope

Choose the framework by the regime, using the tree above. Write the risk appetite statement, which in OCTAVE terms is the measurement criteria and in COSO terms is the appetite principle: one paragraph per category saying how much of that risk the board will carry. Name the owners on the three lines model, and fix the scoring scale before anyone scores anything. A 5 by 5 matrix with defined anchors for each level is the minimum; FAIR ranges for the top risks are the upgrade.

Days 16 to 45: identify and assess

Build the inventory the framework starts from: information assets for OCTAVE and ISO 27005, systems for NIST RMF, objectives and processes for COSO and ISO 31000. Run workshops per business area rather than one central session; the second line facilitates, the first line supplies the risks. Score inherent risk first, then map the controls that already exist and score residual. How to create a risk register covers the mechanics, including the risk statement format that stops entries like cyber from getting into the register at all.

Days 46 to 75: treat and evidence

Every risk above the appetite line gets a treatment decision, avoid, reduce, share or accept, an owner and a date. Reduce means a control, and a control means evidence that it operates; attach it now rather than before the audit. Define key risk indicators with thresholds for the risks that move, so monitoring is a dashboard rather than a quarterly rediscovery. This is also where third-party assessments join the register instead of living in procurement.

Days 76 to 90: report and review

Produce the first board report from the register, not from a slide deck written about it. Walk internal audit through the framework so the third line has tested it before the regulator does. Put the review cadence in the calendar: ISO 31000 says monitoring and review are continuous, DORA says the framework is reviewed at least yearly, NIS2 and ISO 27001 expect review on significant change, and most boards want a quarterly view. Finally, test the export in the format your regulator wants, because the day you need it is not the day to discover the register has no owner column.

Who owns what? The three lines

Every framework assumes a division of labour, and the IIA's Three Lines Model is the version regulators recognise. The first line, business and IT management, owns the risks: it runs the controls, keeps the register current and raises incidents. The second line, risk and compliance, owns the method: it sets the framework, criteria and appetite, challenges the first line's scores, aggregates and reports. The third line, internal audit, owns assurance: it tests that the framework operates and reports to the audit committee rather than to management. The board sets the appetite, receives the reports and owns the outcome.

DORA Article 6(4) makes this explicit for financial entities; ISO 31000's leadership component and COSO's governance component assume it. The commonest failure is the second line writing the register because the first line will not, and the third line never testing it. A register nobody in the business recognises is the first thing an experienced examiner notices.

What does the output look like under any framework?

Whatever framework you chose, it ends in a register, and the register looks the same. One row per risk. A risk statement with a cause, an event and a consequence, in one sentence. An owner who is a person, not a department. An inherent score on the agreed scale. The controls that address it, each linked to evidence that it operates. A residual score. A treatment decision. A review date. The names of the columns change between NIST, ISO and COSO; the columns do not.

Whichever framework produces it, the register has to live somewhere that keeps it scored, owned and current; the enterprise risk management software guide sorts the tools that do that into four segments and gives you the scorecard to choose between them.

Qualitative or quantitative: is a 5 by 5 matrix enough?

For triage, yes. For budgets, no. The matrix gets a hundred risks into three piles in an afternoon, shows the board where the appetite line sits, and satisfies ISO 27001 6.1.2, NIS2, DORA and the SOC 2 CC3 criteria. Its problems are mathematical. Ordinal scales cannot be added or multiplied honestly: a 4 by 5 and a 5 by 4 both score 20, and one of them is a bad week while the other ends the company. Two scores of 8 are not a 16. It cannot answer whether a control is worth its cost, and its scores drift, upward before budget rounds and downward before audits.

The working answer is both. Use the matrix to decide what to look at, and FAIR, or at least a calibrated range in currency, to decide what to spend on the risks that survive triage. Regulators do not require quantification, but supervisory conversations under DORA and Solvency II go noticeably better when the answer to how much is a range rather than a colour.

What do the other results get wrong?

• Six NIST RMF steps. Two of the top five pages still count six. Revision 2 added Prepare in 2018; NIST's own page lists seven.
• Confusing the CSF with the RMF. One page describes the Cybersecurity Framework as a six-step process for federal systems. That is the RMF. The CSF is a voluntary outcome framework for any organisation, and 2.0 has six functions, not steps.
• Certifiable frameworks that are not. Nobody is certified to ISO 31000, ISO 27005, NIST RMF, COSO or FAIR. Only ISO 27001 and ISO 42001 on this page carry an organisational certificate.
• Listing management system standards as risk frameworks. ISO 42001 contains a risk assessment requirement; it is not a risk management framework, any more than ISO 27001 is. It is the system the framework runs inside.
• The 2004 COSO cube. Still drawn on several pages. The 2017 edition replaced it with five components and twenty principles wrapped around the strategy lifecycle.
• No regulation mapping. Not one of the ranking pages says which regulation expects which framework, which is the only reason most readers are searching.
• Framework, standard, process and register used interchangeably. Auditors distinguish them, and so does the question of what you can claim.

Frequently asked questions

What is a risk management framework?

A repeatable method for identifying what could go wrong against your objectives, scoring how much it matters, deciding what to do about it and monitoring the result. It fixes the steps, the roles, the scoring criteria and the cadence so that two assessments a year apart are comparable.

What are the five components of a risk management framework?

Context and criteria, identification, analysis and evaluation, treatment, and monitoring and reporting, with governance wrapped around them. Some authors count seven by splitting communication and continuous improvement out; the substance is the same.

What are the most common risk management frameworks?

For enterprise risk, ISO 31000 and COSO ERM. For information security, ISO/IEC 27005, NIST RMF and OCTAVE. For quantification, FAIR. For governance of IT, COBIT. For cyber posture, NIST CSF 2.0. For AI, NIST AI RMF and ISO/IEC 42001.

Which risk management framework is best?

The one whose output the person asking will accept. Boards accept COSO and ISO 31000. ISO 27001 auditors accept ISO 27005. US federal assessors accept NIST RMF. CFOs and insurers accept FAIR. There is no best in the abstract, and most organisations run one framework for governance and one for the technical assessment.

What is the difference between a risk management framework and a risk management process?

The framework is the method and the organisation around it; the process is the method applied to one scope in one period. ISO 31000 uses exactly this split: a framework built on principles, and a process the framework runs.

What is the difference between ISO 31000 and COSO ERM?

ISO 31000 is sector-neutral guidance built on eight principles and says little about strategy or scoring. COSO ERM is built around strategy and performance, has five components and twenty principles, and is the basis of the SOC 2 risk assessment criteria. Financial services and listed companies tend to COSO; public bodies and organisations starting from nothing tend to ISO 31000. Many use both.

What are the seven steps of the NIST RMF?

Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor, per SP 800-37 Revision 2. Older sources list six because Prepare was added in 2018.

Is NIST CSF a risk management framework?

It is an outcome framework: six functions describing what a mature cybersecurity programme achieves. It measures your gap through profiles rather than walking you through a risk assessment. Pair it with SP 800-30 or ISO 27005 for the assessment itself.

Can you get certified to ISO 31000?

No. ISO 31000 is guidance and is explicitly not intended for certification. Individuals can hold training certificates in it; organisations cannot be certified to it. The same is true of ISO 27005, NIST RMF, COSO and FAIR.

What is risk appetite and where does it go?

The amount and type of risk the board is willing to carry in pursuit of its objectives, written down per category. It is the line drawn across the matrix that decides which risks must be treated. Write it before scoring anything; it is OCTAVE's measurement criteria, COSO's appetite principle and ISO 31000's risk criteria under different names.

How often should a risk assessment be reviewed?

Continuously in principle, and on a fixed cycle in practice. DORA requires the ICT risk management framework to be reviewed at least yearly. ISO 27001 expects reassessment at planned intervals and on significant change. Most boards want a quarterly view of the top risks and an annual full refresh.

What is a risk management framework example for a small company?

OCTAVE Allegro: a single analyst, eight steps, worksheets, starting from the handful of information assets that matter. Its first step, the risk measurement criteria, produces the appetite statement you will need for any framework you grow into.

Is there a risk management framework template?

The framework itself is a method, so the template is the register it produces. The risk register template carries the columns every framework ends in: statement, owner, inherent score, controls, residual score, treatment, review date.

Which framework does DORA require?

None by name. Article 6 requires an ICT risk management framework that is documented, reviewed at least yearly and owned by the management body, with the three lines of defence. ISO 27005 or NIST RMF for the process and COSO or ISO 31000 for the governance layer satisfy it.

How much does implementing a risk management framework cost?

The framework documents cost little: NIST publications are free, ISO 31000 and 27005 are a few hundred euros each, COSO's is under a thousand. The cost is time. A first register for one entity is roughly a day a week of one owner for a quarter plus the workshop hours of the first line, and a platform that keeps the register, controls and evidence in one place is what stops that quarter repeating every year.

Primary sources

• NIST, About the Risk Management Framework, SP 800-37 Rev. 2
• NIST, The Cybersecurity Framework 2.0, CSWP 29, February 2024
• NIST, AI Risk Management Framework 1.0, January 2023
• ISO, ISO 31000 Risk management
• ISO/IEC 27005:2022, Guidance on managing information security risks
• COSO, Enterprise Risk Management: Integrating with Strategy and Performance, 2017
• FAIR Institute, What is FAIR
• SEI, Introducing OCTAVE Allegro, 2007
• ISACA, COBIT 2019
• The IIA, Three Lines Model, 2020

Written by the Venvera compliance team. Framework editions and step names checked against the publishers' own pages in September 2026. Where a regulation is cited, the article or clause number is given so you can read the text yourself.