Risk management frameworks: which one fits a UK tech firm risk management frameworks

The enterprise questionnaire asks: "Which risk management framework does your organisation follow?" Your ISO 27001 auditor and your investor's due diligence list ask the same thing, and the deal waits on the answer.

There is no single best choice among risk management frameworks. Most UK tech firms run one information security risk method, ISO/IEC 27005 if they hold or want ISO 27001, describe it in NIST CSF terms when US customers ask, and add FAIR only when the board wants risk in money. This list includes a framework only if a customer, auditor, regulator or board is likely to name it to a 25 to 150-person B2B tech supplier.

The goal is one method and one register that answer every reader, not a framework per customer.

Which risk management frameworks does a UK tech firm actually meet?

A UK B2B tech firm meets eight risk management frameworks in practice: ISO/IEC 27005, ISO 31000, NIST CSF 2.0, the NIST RMF, COSO ERM, FAIR, the NCSC Cyber Assessment Framework and DORA's ICT risk management framework. Two of them run your risk work. The rest are how particular customers, boards or regulators describe what they expect from you.

Each framework below gets the same three parts: what it is, when it matters to a tech supplier, and what to do.

Also considered, and left out because a tech supplier is rarely asked about them by name: OCTAVE, TARA and the CIS Controls. COBIT is an IT governance framework rather than a risk method. If you build or deploy AI, the NIST AI RMF covers AI risk specifically.

Framework, standard or method: what is the difference?

A framework sets the structure and principles for managing risk, a standard is a published document you can be audited or benchmarked against, and a method is the repeatable way you actually identify, analyse and evaluate each risk. Questionnaires use the three words interchangeably, so answer with the method you run and the framework it follows.

A firm can follow several frameworks and still run only one method.

Which frameworks run your information security risk work?

ISO/IEC 27005 and ISO 31000 are the two frameworks most UK tech firms build their own risk process on. ISO/IEC 27005 gives the information security method that an ISO 27001 auditor recognises. ISO 31000 gives the organisation-wide principles it sits within. Most firms of 25 to 150 people need the first and can borrow from the second.

1. ISO/IEC 27005

What it is. The international guidance standard for managing information security risks, published by ISO and IEC; the current edition is ISO/IEC 27005:2022. It covers the whole cycle, from identification and assessment through treatment, communication and review. See our ISO 27005 overview for the detail.

When it matters to a tech supplier. When you hold or want ISO 27001. The certification standard requires a risk assessment process; ISO/IEC 27005 is the guidance on how to run one, and an auditor will recognise it.

What to do. Name it as the basis of your method, then make sure the process actually runs. Our page on ISO 27001 clause 8.2 covers the cadence and change triggers auditors look for.

2. ISO 31000

What it is. The ISO guidelines for managing any kind of risk, in three parts: principles, a framework and a process. ISO 31000:2018 is voluntary guidance, not a certifiable standard, and a revision is under way. Our ISO 31000 overview tracks its status.

When it matters to a tech supplier. When a board, a larger customer or an investor asks how you manage risk beyond security: commercial, operational and people risk.

What to do. You rarely need to adopt it separately. Say your information security method follows ISO/IEC 27005 within an ISO 31000-aligned approach, and use one scoring scale for every risk type.

Which frameworks do US customers use to describe your security?

NIST CSF 2.0 and the NIST Risk Management Framework are the US frameworks a UK supplier is most likely to be asked about. CSF 2.0 is how many US enterprise buyers describe the security they expect. The NIST RMF is a system authorisation process met mainly in US government supply chains.

3. NIST CSF 2.0

What it is. The US National Institute of Standards and Technology's Cybersecurity Framework, version 2.0, released on 26 February 2024. It organises security outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. NIST designed 2.0 for organisations of every type and sector, not only critical infrastructure. See our NIST CSF overview.

When it matters to a tech supplier. When a US customer's questionnaire is organised by CSF functions, or asks for your "CSF profile".

What to do. Map your existing controls and risk process to the six functions once, and reuse the mapping. You do not need a second risk method to speak CSF.

4. NIST Risk Management Framework

What it is. The process in NIST SP 800-37 Revision 2 (December 2018) for managing security and privacy risk to information systems, in seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor. NIST says it can be applied to any organisation, but it is built around authorising systems.

When it matters to a tech supplier. When you sell into US federal or defence supply chains, where system authorisation is the norm.

What to do. If that is not your market, recognise the name and move on. If it is, expect the buyer to set the control baseline.

Which frameworks does a board or investor bring?

COSO ERM and FAIR answer the board's two questions. COSO ERM shows how risk connects to strategy and objectives, which audit committees and investors recognise. FAIR answers "how much": it quantifies information risk in money. A tech firm usually meets both around a funding round or a new board seat, not in a customer questionnaire.

5. COSO ERM

What it is. The Committee of Sponsoring Organizations of the Treadway Commission's Enterprise Risk Management—Integrating with Strategy and Performance (2017), with 20 principles that tie risk to strategy, performance and board oversight. Our COSO ERM overview covers the components.

When it matters to a tech supplier. When a board, an audit committee or an investor wants risk reported against objectives. Note that SOC 2 draws on a different COSO publication: common criteria CC1 to CC5 follow the 17 principles of COSO's 2013 Internal Control–Integrated Framework, as our Trust Services Criteria guide explains.

What to do. Link each top risk in your register to a business objective and report the top risks to the board on a fixed cycle.

6. FAIR

What it is. Factor Analysis of Information Risk, published by The Open Group as the Open FAIR standards: a risk taxonomy (O-RT) and an analysis process (O-RA). It analyses a risk scenario quantitatively, so risk can be expressed in money rather than colours. See our FAIR overview.

When it matters to a tech supplier. When the board asks how much cyber risk the firm carries, or when you are deciding how much cyber insurance to buy.

What to do. Keep your register's qualitative scoring, and run FAIR on the three to five scenarios the board cares about most. We recommend quantifying selectively rather than converting the whole register.

Which frameworks do regulated and public-sector customers bring?

The NCSC Cyber Assessment Framework and DORA reach a tech supplier through its customers, not directly. Public-sector and essential-service buyers use the CAF to judge their own resilience, and banks and insurers with EU operations must hold suppliers to DORA's contract terms. Neither makes a UK tech firm adopt the framework itself.

7. NCSC Cyber Assessment Framework

What it is. The National Cyber Security Centre's Cyber Assessment Framework, version 4.0, a tool for assessing and improving cyber security and resilience. It is designed mainly for organisations operating essential services under the NIS Regulations, UK critical national infrastructure and public-sector bodies that support core government functions.

When it matters to a tech supplier. When your customer is one of those organisations and your service supports what they are assessed on. The CAF says nothing about suppliers, so this is our reading: such a buyer may ask how your controls support the outcomes it is assessed against.

What to do. Map your controls to the CAF outcomes your service touches, alongside your NIST CSF mapping. Public-sector buyers may also cite HM Treasury's Orange Book; it governs risk management in government organisations, not yours.

8. DORA's ICT risk management framework

What it is. Regulation (EU) 2022/2554, the Digital Operational Resilience Act. Article 6 requires financial entities to have "a sound, comprehensive and well-documented ICT risk management framework". It binds the financial entities listed in Article 2, such as banks, insurers and payment institutions in the EU.

When it matters to a tech supplier. When you sell to banks or insurers with EU operations. Article 30 requires their contracts for ICT services supporting critical or important functions to include, among other terms, appropriate security measures, tested contingency plans and audit rights. DORA applies to an ICT supplier directly only if EU supervisors designate it as critical. UK banks and insurers apply the PRA's SS2/21 on outsourcing and third party risk management, which reaches suppliers the same way: through contracts and due diligence. For FCA-regulated common platform firms, rule SYSC 8.1.8R sets conditions on outsourcing critical or important operational functions, including effective access to data and premises for the firm, its auditors and the FCA, and a contingency plan for disaster recovery.

What to do. Do not adopt DORA as your framework. Read the contract terms, then show evidence from the method and register you already run.

Which risk management framework fits your trigger?

The right framework is set by who is asking. An ISO 27001 auditor wants ISO/IEC 27005-style method evidence, a US enterprise buyer wants NIST CSF language, a UK bank wants evidence against its contract terms, and a board wants COSO-style reporting or FAIR numbers. The same method and register can answer all of them.

How do you answer "which risk methodology do you follow?"

Answer in one sentence that names the framework, the method and the register, and use the same sentence everywhere. A consistent answer tells the reader the process is real. Changing the framework name for each questionnaire tells them the opposite, and auditors compare questionnaire answers with what they see.

An example that holds up: "We manage information security risk with a documented method based on ISO/IEC 27005, recorded in one risk register reviewed quarterly by leadership, and we map our controls to NIST CSF 2.0 for customers who use it." The quarterly cycle is illustrative; state what you actually do.

The test is whether you can produce the method document and a dated register within a day of being asked.

How does one register serve ISO 27001, SOC 2 and customer frameworks?

One register serves every framework when each risk links to the controls that treat it, and each control carries tags for the frameworks it satisfies. ISO 27001 reads the register as its risk assessment record, SOC 2 reads it as risk assessment evidence, and customer frameworks read the control tags. Nothing is assessed twice.

A risk such as "customer data exposed through a misconfigured cloud bucket" links to its access and configuration controls, each tagged with the ISO 27001 Annex A control, SOC 2 criterion and NIST CSF category it meets. A new customer framework adds a tag column, not a register.

For the requirements on each side, see our ISO 27001 guide and our SOC 2 overview.

How to use this list

Start from your trigger, not from the list. Find your situation in the trigger table, name the framework it points to, and build the one method that serves it. Add the other items only as new customers, auditors or board members bring them.

The NCSC's risk management guidance supports building up this way: it says "no one size fits all" and that your approach should be "tailored to the key characteristics of the risk challenge".

What are the common mistakes when choosing a risk management framework?

The common mistakes are adopting a framework built for a different organisation, running a separate register for each standard, and treating a customer's regulation as your own. The NCSC's guidance is explicit that analysis should be proportionate to the risk challenge.

• Adopting a bank's framework. A 60-person SaaS firm that copies a bank's risk framework can end up with committees it cannot staff. Borrow the principles; keep the method small.
• One register per standard. Two registers drift apart, and an auditor who sees both will ask which one is true.
• Reading DORA as your own obligation. The obligation sits with your customer. Your job is to evidence the contract terms they pass to you.

A framework you cannot evidence is a claim, not a method.

Frequently asked questions