Most organizations have an enterprise risk management framework in name.
They have the committee structures, the risk registers, the quarterly reporting cycles. What they rarely have is the data infrastructure underneath it. The part that determines whether those frameworks actually hold up when regulators show up.
That gap is not a governance failure; it’s a data failure. And it is costing risk functions credibility, audit cycles and, in the worst cases, regulatory penalties that were entirely preventable.
The hard truth: a risk framework built on disconnected spreadsheets and manually assembled reports is not a risk management capability. It’s a documentation exercise. If you want a framework that scales under regulatory pressure — BCBS 239, Solvency II, DORA or whatever comes next — the conversation has to start with data.
An enterprise risk management framework is the structured system of policies, processes, tools and governance structures an organization uses to identify, assess, monitor, report and respond to risk across the enterprise. A mature ERM framework covers financial risk, operational risk, compliance risk, cyber risk and increasingly, model risk and AI risk.
The leading standard is the COSO ERM framework, which defines risk management as an integrated, enterprise-wide capability rather than a siloed function. ISO 31000 provides a complementary international standard. Both share a core premise: risk management is only as good as the information feeding it.
That premise is where most organizations hit a wall.
Risk functions depend on data. Specifically, critical data elements (CDEs): the fields, metrics and indicators that matter most for risk identification and regulatory reporting. Examples include counterparty exposure figures, capital adequacy ratios, loss event amounts and liquidity coverage calculations.
If those CDEs are poorly defined, inconsistently calculated or untraceable to their source, the risk framework built on top of them is structurally compromised. You may have a governance framework that looks sophisticated on paper, but if “total exposure” means three different things in three different systems, your risk reports are inaccurate by design.
The specific data gaps that undermine ERM most consistently are:
These gaps do not just create audit findings. They make it structurally impossible to meet certain regulatory expectations.
Two regulations illustrate this data dependency better than any others.
BCBS 239 (Principles for Effective Risk Data Aggregation and Risk Reporting) sets out exactly what regulators expect from systemically important banks: accurate data, complete data, timely aggregation and the ability to adapt reporting to new risk scenarios. The principles are not abstract. They require demonstrable data lineage, documented CDE ownership and automated controls on data quality. Banks that cannot show the provenance of a reported figure are not compliant, regardless of the sophistication of the risk models.
Solvency II imposes comparable requirements on insurers. The Own Risk and Solvency Assessment (ORSA) process demands that insurers substantiate their capital calculations with auditable data. The EIOPA guidelines on data quality make explicit that insurers must document data sources, validate quality and maintain records of how data flows through actuarial models.
In both cases, the regulator is not just asking about the risk numbers. They are asking about the data supply chain that produced those numbers. And that supply chain has to be traceable, governed and continuously monitored — not reconstructed from memory during an examination.
The spreadsheet-and-email approach to ERM data is a known liability, and yet it persists in a surprising number of institutions. The reasons are understandable: ERM evolved before modern data platforms existed, and risk teams are not typically resourced to run data engineering projects.
But the costs are severe and they compound at the worst moments. When a new regulatory requirement arrives — or when a stress event creates demand for rapid, granular reporting — manual processes reveal their limits immediately. Data collection takes weeks instead of hours. Lineage cannot be demonstrated. Quality issues are discovered mid-report. The risk function looks unready, which is precisely the outcome ERM is supposed to prevent.
The failure mode is predictable: risk data lives in dozens of systems, is manually extracted and transformed by analysts, lands in a spreadsheet that becomes the “golden source,” and is then manually formatted into a report that may or may not match what was submitted last quarter. No one can prove where the numbers came from, no one owns the quality of the underlying fields and the next audit cycle starts the process over.
Building an ERM framework that holds up under regulatory scrutiny requires data capabilities that most risk functions do not own internally. Those capabilities need to be embedded in the enterprise data infrastructure, not bolted on to the risk function as a side project.
The minimum viable data foundation for a serious ERM framework includes:
CDE cataloging and ownership. Every critical data element must be formally defined, assigned to a business owner and recorded in a central catalog. Definitions must be consistent across systems. Ownership must be accountable and active, not nominal.
Automated data lineage. Risk-relevant data assets must have documented, automated lineage from source system to risk report. This is not optional under BCBS 239 or Solvency II. Lineage needs to be queryable, not reconstructed.
Continuous data quality monitoring. Quality rules tied to CDEs must run automatically and surface issues upstream, before data reaches the risk reporting layer. Monitoring should include completeness, accuracy, consistency and timeliness checks relevant to each CDE.
Policy enforcement at the data layer. Risk policies — on data retention, access controls, approved calculation methodologies — need to be operationalized as enforceable rules, not just documents that reference data systems by name.
Integrated risk reporting. Risk reports should be generated from governed data assets with traceable lineage rather than assembled manually. This requires a connection between the risk reporting layer and the underlying data catalog.
Collibra’s data governance platform provides the infrastructure layer that connects ERM requirements to actual data assets. Here is how it maps to the ERM workflow:
CDE identification and cataloging. Collibra’s data catalog allows risk teams and data owners to formally register CDEs, attach business definitions, link them to physical data assets in source systems and assign stewardship. When a regulator asks what “net exposure” means and where it comes from, the answer is in the catalog, not in someone’s memory.
Lineage automation. Collibra Data Lineage captures and visualizes how data flows from source through transformation to the risk reports and regulatory submissions that depend on it. Lineage is maintained automatically as pipelines change, rather than being documented manually after the fact.
Data quality monitoring. Collibra Data Quality and Observability runs automated quality checks against registered CDEs and surfaces issues in real time. Risk teams can set thresholds aligned with regulatory tolerances and receive alerts when data falls outside acceptable ranges, before it corrupts a downstream report.
Policy and access governance. Collibra’s governance capabilities allow risk and compliance teams to define policies, associate them with data assets and enforce access controls consistently. This is the operational mechanism that makes “data governance” more than a phrase.
Business glossary for regulatory consistency. A shared business glossary ensures that terms like “counterparty,” “exposure at default” or “qualifying capital” have single, agreed definitions that are used consistently across risk models, reporting tools and regulatory submissions.
Risk leaders who have made this investment report three categories of return that resonate with finance and the board.
First, audit efficiency. Regulatory examinations that previously required weeks of manual data reconstruction are handled in hours, because lineage is documented and CDEs are cataloged. This reduces direct cost and organizational disruption.
Second, regulatory confidence. Demonstrating automated controls, traceable lineage and owned CDEs changes the character of regulatory interactions. Examiners engage differently with institutions that can show a governed data infrastructure rather than apologize for spreadsheets.
Third, risk reduction. Bad data in risk models produces bad risk decisions. Automating quality monitoring and enforcing CDE definitions reduces the probability of material errors in risk calculations, which is, after all, the point of the framework.
The case is not complicated. The enterprise risk management framework is only as good as the data it runs on. Building the data foundation is not a technology project separate from ERM; it is the ERM investment with the longest leverage.
If your organization is under regulatory pressure and your risk data infrastructure is not keeping pace, explore how Collibra’s compliance solutions can help you build a data-ready ERM framework that holds up when it counts.
Collibra
Enterprise AI Control Plane
I would like to get updates about the latest Collibra content, events and more.
Thanks for signing up
You'll begin receiving educational materials and invitations to network with our community soon.