When a Deal Falls Through – And CRR3 Was to Blame
Sophie, CEO of a mid-sized ICT company, had just secured a partnership with a major bank. Everything was ready: the service agreement, the onboarding plan — even a press release.
Then came the compliance call. “We need your incident reports aligned with CRR3’s operational risk taxonomy. Can you map past outages and risks to the required event categories?”
Sophie paused. CRR3? Taxonomy?
She had never heard of it.
💥 The deal was put on hold.
What Is CRR3 and Why Should You Care?
CRR3 is the EU’s new banking regulation that changes how financial institutions calculate and report their exposure to operational risk — things like IT failures, cyberattacks, vendor disruptions, or fraud.
It’s not just for banks. Every third-party ICT supplier serving banks or financial entities is now part of that risk picture.
That includes you.
Under CRR3, financial entities must:
- Classify all incidents using a standard risk taxonomy
- Maintain a 10-year historical log of losses
- Identify and tag incidents with ESG and ICT attributes
📌 If your services can’t deliver that level of insight, clients will look elsewhere — not because your tech is bad, but because your compliance posture is weak.
Short Analysis: How CRR3’s Operational Risk Reform Impacts ICT Service Providers Under DORA/NIS2
As the CRR3 introduces a harmonized framework for operational risk underpinned by the Business Indicator Component (BIC), it significantly influences the expectations financial entities (FEs) will have towards their third-party ICT Managed Service Providers (MSPs) under DORA and NIS2. Here’s a breakdown of how this affects services delivered to FEs and the critical service gaps MSPs must address to stay relevant and compliant:
Key Influences on MSP Service Models:
1. Loss Data Set and Risk Taxonomy Alignment
FEs will be mandated to maintain 10-year loss data sets categorized under a harmonized risk taxonomy.
- Impact: MSPs must provide evidence-based loss reporting and align incident logs to the EBA’s event types and categories.
- Gap: Most MSPs lack structured loss classification, cross-mapped to regulatory taxonomies (e.g. Internal Fraud, Execution Failures).
2. ICT Risk and Third-Party Risk Attributes
The draft RTS expands risk visibility through operational risk attributes (e.g. ICT risk, third-party risk, model risk, greenwashing).
- Impact: MSPs become part of FEs’ extended risk universe.
- Gap: Many MSPs do not segment or tag incidents with attributes like “third-party failure” or “greenwashing” in their reporting.
3. M&A Risk Integration & Historical Data Requirements
FEs undergoing mergers must absorb historical loss data.
- Impact: MSPs need to ensure data portability and post-merger traceability of incidents.
- Gap: Most MSP platforms are not designed to retrospectively integrate or align risk data across group-level mergers.
4. Operational Resilience and Incident Mapping
With systemic incidents (e.g., software failures or vendor downtimes) being codified under Business Disruption categories…
- Impact: FEs will require third-party assurances and categorization of ICT-related outages.
- Gap: MSPs rarely document outages in ways that map to CRR3 Level 1/Level 2 categories (e.g. “6.2 Inadequate BCM”).
5. Climate and ESG-Coded Risk Exposure
Attributes like environmental risk, greenwashing, and governance risks are now part of loss taxonomies.
- Impact: FEs must extend sustainability and ESG indicators to ICT suppliers.
- Gap: ESG risk attributes are not standard in service delivery or incident reporting among ICT MSPs.
6. Unduly Burdensome Calculations – Temporary Grace Periods
FEs with BI just above €750M may delay reporting under certain conditions.
- Impact: MSPs must prepare to scale resilience evidence once FEs reach full compliance thresholds.
- Gap: Many MSPs misjudge client risk exposure based on company size, rather than BI thresholds.
🔎 Summary of Critical Gaps in Current MSP Service Levels:
| Area | Current Gap | Required Adaptation |
|---|---|---|
| Risk Taxonomy | No mapping to regulatory event types | Align incident types with CRR3/DORA taxonomy |
| Loss Attribution | Inadequate data tagging | Introduce risk attribution per EBA event categories |
| BCM Mapping | Generic BCPs, no Level 2 linkage | Map disruptions to CRR3 categories (e.g., 6.3 Network failure) |
| ESG Risk | No flagging of ESG or greenwashing risk | Introduce ESG incident tracking and reporting |
| Historical Integration | Weak backward compatibility | Enable post-M&A loss data portability |
| Attribute-Based Alerts | Generic severity models | Tag incidents with CRR3 attributes (ICT, Legal, Market, etc.) |
Recommendations for MSPs Under NIS2
- Align service risk frameworks with DORA/CRR3/NIS2 expectations
- Develop incident libraries with mappings to Level 1/2 categories
- Introduce ESG and compliance flagging in ticketing and incident management
- Prepare for data integration across client mergers
- Support clients in evidence-based loss reporting
- Update SLAs and SOC reports to include taxonomy-aware metrics
Conclusion: The CRR3 loss data and taxonomy requirements introduce a new paradigm for risk accountability. Under DORA and NIS2, MSPs must pivot from “trusted enabler” to data-rich resilience partner. Those who don’t adapt risk being replaced.
