The CRO's DORA Mandate: Integrating Operational Resilience Into Enterprise Risk Management
From CISO's Problem to CRO's Mandate
For a decade, operational resilience lived in the CISO's domain. It was framed as a cybersecurity concern — firewalls, intrusion detection, incident response, penetration testing. The CRO's risk taxonomy treated ICT risk as a sub-category of operational risk, typically receiving less governance attention than credit risk, market risk, or liquidity risk.
DORA changes this. Article 6(4) requires that the ICT risk management function be organized with "sufficient authority, status and resources" and, critically, that it "be independent in order to avoid conflicts of interest." Article 5(2) places the management body's accountability for the ICT risk management framework on the same level as its accountability for any other risk framework.
For the CRO, this means operational resilience must be integrated into the enterprise risk management (ERM) framework — not as an appendix, but as a first-class risk category with its own risk appetite statement, its own risk limits, its own stress testing programme, and its own board reporting cadence.
The CISO remains essential as the subject-matter expert and operational leader. But the CRO is the governance owner — the person accountable to the board for ensuring that ICT risk is identified, assessed, reported, and managed with the same discipline applied to financial risks.
The CRO's DORA Responsibilities
DORA's five pillars create specific responsibilities that fall within the CRO's domain:
Pillar I: ICT Risk Management Framework (Art. 5-16)
The CRO's primary Pillar I responsibilities:
| Responsibility | DORA basis | Practical action |
|---|---|---|
| Risk appetite articulation | Art. 6(8)(a) | Define quantitative risk tolerance for ICT disruption — maximum tolerable downtime, data loss, financial impact |
| Risk assessment oversight | Art. 6(1) | Ensure ICT risk assessment uses the same methodology, scoring, and escalation thresholds as other risk categories |
| Risk reporting to board | Art. 14 | Integrate ICT risk reporting into the board risk committee agenda — same frequency, same rigor as credit/market risk |
| Risk exception governance | Art. 6 | Own the risk acceptance process for ICT risks above appetite — with expiry dates, compensating controls, and maker-checker approval |
| Three lines of defense | Art. 6(4) | Ensure ICT risk management (2nd line) is independent from ICT operations (1st line) |
Risk appetite statement for ICT risk. Most institutions have risk appetite statements for credit, market, and liquidity risk — quantified, board-approved, monitored with limits and triggers. Few have equivalent statements for ICT risk. DORA requires one. The statement should articulate:
- Maximum tolerable disruption time for critical functions (linked to BIA-derived RTO/RPO)
- Maximum tolerable data loss (RPO translated to data volume)
- Maximum tolerable financial impact from a single ICT incident
- Maximum acceptable third-party concentration level (e.g., no single provider >40% of critical services)
- Minimum resilience testing coverage (e.g., 100% of critical functions tested annually)
Pillar II: Incident Management (Art. 17-23)
The CRO's role in incident management is governance oversight, not operational response. The CISO and SOC handle the response; the CRO ensures that:
- Incident classification criteria align with the risk appetite framework
- Major incidents trigger board notification within the governance framework
- Post-incident risk reassessment is conducted and the risk register is updated
- NCA reporting is timely and accurate
- Lessons learned feed into risk mitigation priorities
Pillar III: Resilience Testing (Art. 24-27)
The CRO governance role in testing:
- Approve the annual testing programme scope based on risk assessment outputs
- Ensure testing covers all critical functions (risk-based prioritization for non-critical)
- Oversee finding remediation — deviation/CAPA lifecycle governance
- Report testing results and remediation status to the board
- Validate that TLPT scope and methodology are proportionate to the risk profile
Pillar IV: Third-Party Risk (Art. 28-44)
Third-party ICT risk is where the CRO's mandate is most expanded by DORA:
The third-party register under Art. 28(3) is a risk management artifact, not just a compliance artifact. The CRO should own the risk interpretation of the register — identifying concentration risks, single points of failure, and dependencies that exceed the risk appetite.
Integrating ICT Risk Into the ERM Framework
The practical challenge is integration. ICT risk cannot be managed effectively as a standalone silo — it must be embedded in the same ERM framework that manages all other risk categories.
Risk Taxonomy Integration
| ERM component | Current state (typical) | DORA target state |
|---|---|---|
| Risk taxonomy | ICT risk is a sub-category of operational risk, often treated as residual | ICT risk is a first-class category with specific sub-categories aligned to DORA pillars |
| Risk appetite | No quantified appetite for ICT risk | Board-approved, quantified risk tolerance with limits and triggers |
| Risk assessment | Separate CISO-driven assessment, not integrated with ERM assessment cycle | ICT risk assessment integrated into the enterprise assessment cycle, same methodology |
| Risk reporting | CISO presents to IT committee; limited board visibility | ICT risk on the board risk committee agenda, Art. 14 compliant reporting |
| Risk limits | No specific ICT risk limits | Defined limits for concentration, downtime, third-party dependency |
| Stress testing | Cyber stress test as separate exercise | ICT disruption scenarios integrated into enterprise stress testing |
| Three lines model | 2nd line ICT risk function may not exist or may lack independence | Independent ICT risk function with CRO reporting line |
Risk Scoring Alignment
ICT risks should be scored using the same methodology as other enterprise risks — likelihood x impact, with the impact dimension calibrated to financial, operational, reputational, and regulatory consequences. This enables apples-to-apples comparison across risk categories and ensures that ICT risks compete for mitigation resources on a level playing field.
| Impact dimension | ICT risk calibration | Scale |
|---|---|---|
| Financial | Direct loss + regulatory fines + recovery cost + business interruption | 1-5 aligned with financial risk scale |
| Operational | Critical function disruption duration | 1-5 aligned with BIA criticality |
| Reputational | Customer impact, media exposure, market confidence | 1-5 aligned with reputational risk scale |
| Regulatory | NCA findings, remediation orders, personal liability | 1-5 aligned with regulatory risk scale |
The Board Reporting Cadence
Art. 14 requires annual board reporting at minimum. In practice, the CRO should integrate ICT risk into the quarterly board risk committee cycle:
The CISO's 12 KPIs provide the operational metrics. The CRO's role is to contextualize these metrics within the enterprise risk framework — translating ICT metrics into risk language that the board understands and can govern.
The CISO-CRO Relationship Under DORA
DORA creates a governance partnership between the CRO and CISO that must be clearly delineated:
| Function | CISO | CRO |
|---|---|---|
| ICT risk identification | Leads technical risk identification | Ensures integration into ERM |
| Risk assessment | Provides technical assessment | Validates methodology and scoring alignment |
| Risk appetite | Advises on feasibility of limits | Proposes and owns board-approved appetite |
| Incident response | Leads operational response | Oversees governance and regulatory compliance |
| Board reporting | Provides data and analysis | Presents to board risk committee |
| Testing programme | Designs and executes testing | Approves scope and prioritization based on risk |
| Third-party risk | Assesses technical risk of providers | Owns concentration risk assessment and appetite |
| Remediation prioritization | Advises on technical priority | Allocates risk budget and resources |
The relationship works when the CISO has operational authority and the CRO has governance authority. It fails when either role encroaches on the other's domain — or when the CRO treats ICT risk as "the CISO's problem" and limits their involvement to receiving reports.
Use the DORA readiness assessment to evaluate your institution's risk governance maturity, consult the pillars overview for a complete DORA requirements map, and review the glossary for precise regulatory terminology. The EBA's guidelines on ICT risk management and ESMA's technical standards provide additional context for the CRO's governance responsibilities.
Conclusion
DORA elevates ICT risk from a technical concern to a governance discipline. For the CRO, this is both a mandate and an opportunity — an opportunity to bring the same rigor, quantification, and board accountability to ICT risk that has long been applied to financial risks. The institutions where the CRO fully owns the operational resilience governance framework will demonstrate to supervisors that ICT risk is managed with enterprise discipline. The institutions where ICT risk remains siloed in the CISO's domain will find that DORA's governance requirements expose that gap under examination.
Resume en francais
DORA transforme la resilience operationnelle d'une preoccupation technique du RSSI en un mandat de gestion des risques d'entreprise pour le CRO. Cet article cartographie les responsabilites specifiques du CRO a travers les cinq piliers de DORA : la gouvernance du cadre de risque TIC avec l'articulation de l'appetit au risque (Pilier I), la supervision de la gouvernance de la gestion des incidents (Pilier II), la gouvernance du programme de tests (Pilier III), l'evaluation du risque de concentration tiers (Pilier IV) et la gouvernance du partage d'informations (Pilier V). L'article detaille l'integration du risque TIC dans le cadre ERM existant — taxonomie, appetit au risque, evaluation, reporting, limites, stress testing et modele des trois lignes — et definit la relation RSSI-CRO sous DORA, ou le RSSI detient l'autorite operationnelle et le CRO l'autorite de gouvernance. La cadence de reporting au conseil integre le risque TIC dans le cycle trimestriel du comite des risques du conseil avec les memes rigueur et structure que le risque de credit, le risque de marche et le risque de liquidite.