Every organisation needs a way to identify risk, score it, decide what to do, and check whether that decision held.
According to Copla, that structure, known as a risk management framework, splits into two very different categories: frameworks built by standards bodies like ISO, COSO and NIST that any business can adopt, and the one framework regulators like DORA and NIS2 actually demand, which nobody can write except the organisation itself.
Copla recently delved into how the risk management process is only as good as step one in the full process.
Five components underpin any credible framework, regardless of which standard’s language is used: named governance and accountability, continuous risk identification drawn from real assets and vendors, consistent scoring, a treatment decision (mitigate, transfer, avoid or accept), and ongoing monitoring that feeds back into reporting. Skip governance and what exists is a methodology, not a framework.
Skip monitoring triggers and the register only moves once a year, at audit time, rather than when the business actually changes.
Among the adoptable frameworks, ISO 31000 offers principles and shared vocabulary but no certification scheme. COSO ERM ties risk to strategy and board-level performance, making it a fit for larger institutions rather than a compliance officer with thirty vendors and a spreadsheet. NIST RMF is a seven-step process built specifically for US federal information systems under FISMA, while NIST CSF 2.0 offers outcome-based cybersecurity guidance, now including a “Govern” function added in its 2024 update. FAIR replaces qualitative ratings with a financial figure, loss frequency multiplied by loss magnitude, but demands calibrated data most risk functions don’t yet have.
None of these, however, satisfy what DORA Article 6 or NIS2 Article 21 require: a documented framework specific to the organisation’s own critical functions, dependencies and risk appetite, approved and owned by the management body itself. A supervisor expects to recognise the business in the document, not a template with a different logo.
The build order matters as much as the components. Start with an inventory of actual systems and vendors, run a business impact analysis before scoring anything, set risk appetite at leadership level, then build the register and apply controls only where a specific risk justifies one. Review triggers, not calendar dates, should reopen the register whenever a new vendor, incident or regulatory change occurs.
Copyright © 2026 FinTech Global
