Compliance Management
Risk Management
Third Party Risk Management
Data Privacy Management
Internal Auditing
Business Continuity Management
Continuous Control Monitoring (CCM)
Trust Center
.webp)
DORA Enterprise Risk Management: Integration Guide
Highlights
- Privacy regulation is not softening. European supervisory authorities issued around €1.2 billion in GDPR fines in 2025 and personal data breach notifications grew 22 per cent year on year.
- The EU AI Act and GDPR now overlap in every AI system that touches personal data. Running them as separate programmes creates duplication and gaps; running them as one governance problem does not.
- Most GDPR enforcement actions punish drift, not absence: drifted inventories, manual privacy operations, unclear ownership, shadow AI and SaaS, and privacy run as a silo from cyber and third party risk.
- The framework in this guide builds in sequence: data visibility, risk assessment, governance and accountability, operational controls, and continuous monitoring. Joined up with the wider risk programme.
Expert View
|
Matt Davies Chief Product Officer, SureCloud |
What our experts say about integrating DORA ICT risk "The question I ask firms is simple: can your CRO walk into a board meeting and present ICT risk as part of the enterprise risk picture, or does it come in as a separate briefing from the CISO? I've been in rooms where the risk committee and the security committee report different things to the same board. That happens when nobody has made the governance decision to connect them. DORA is the regulatory reason to make that decision, and the firms that use it that way end up with one process, better visibility, and a board that can form a coherent view of ICT risk." |
|
KEY FACTS
|
Why ICT Risk Integration Matters
DORA is explicit about where ICT risk belongs. Article 6(4) positions the ICT risk management framework as an integral component of the overall enterprise risk management framework, governed through the same management body structures as credit, market, and operational risk. The management body's obligations under Article 5 reinforce this: they carry responsibility for defining, approving, and overseeing the risk tolerance for ICT risk with the same governance rigour applied to other risk categories.
For most in-scope firms, the structural challenge is a governance one. Enterprise risk functions already operate board-approved risk appetite frameworks, three lines of defence governance, and KRI reporting cycles. The integration question is whether ICT risk has been properly connected to those existing structures, or whether it operates as a separate discipline managed primarily by the CISO and reported to the board outside the standard ERM governance cycle.
Firms that integrate ICT risk into ERM governance gain a single, coherent risk view at board level, consistent risk appetite governance across all risk categories, and a unified evidential record for audit and supervisory examinations. DORA supervisors will examine both the framework document and the reporting that flows from it.
Applying the Three Lines of Defence Model to ICT Risk
EBA/GL/2019/04, the EBA Guidelines on ICT and Security Risk Management, requires firms to apply the three lines of defence model to ICT risk governance. In an integrated ERM model, this means extending the governance structure the firm already operates, with each line carrying defined ICT risk responsibilities alongside its existing mandate.
First line
Business units and the ICT function own ICT risk day to day. They implement controls, maintain systems, and operate within the risk appetite and tolerance levels approved by the management body. The board's obligation under Article 5(2)(f) to approve ICT audit plans, audits, and material modifications creates the governance framework within which first-line control functions are reviewed and held to account.
Second line
The risk function oversees ICT risk as part of its enterprise-wide remit. In an integrated model, the CRO owns ICT risk reporting to the board alongside credit, market, and operational risk. ICT-specific KRIs feed into the ERM reporting dashboard rather than arriving as a separate CISO briefing, and the risk function provides independent oversight of first-line ICT risk management.
Third line
Internal audit reviews both first and second line ICT risk functions independently. DORA requires management body approval of ICT internal audit plans under Article 5(2)(f), embedding this oversight into existing audit committee governance rather than creating a parallel ICT audit workstream that operates outside the firm's established audit cycle.
Embedding ICT Risk Appetite in the ERM Framework
Risk appetite is the governance mechanism that connects board-level decisions to operational risk management. Under DORA, ICT risk appetite must be set by the management body and operationalised into measurable thresholds that the first line operates within and the second line monitors.
In an integrated ERM model, the ICT risk appetite statement sits within the entity's overarching risk appetite framework. It is reviewed at least annually under Article 6(5), alongside the full framework review, and more frequently following material ICT incidents, supervisory instructions, or significant changes to the ICT environment.
The practical test for integration is straightforward: when the CRO presents the risk appetite framework to the board, ICT risk appetite appears as a defined component, with the same governance rigour as credit or operational risk appetite. When that component is absent, the firm has a structural gap that supervisors are equipped to identify.
Connecting ICT Risk Indicators to ERM Reporting
Key Risk Indicators for ICT risk must feed directly into the firm's enterprise risk reporting cycle. DORA leaves the selection of specific KRIs to each firm; the framework must include detection capabilities and reporting mechanisms that give the management body a current, accurate picture of ICT risk exposure.
Indicator design
ICT KRIs should be designed with the same specificity applied to other risk indicators in the ERM framework: a measurable metric, a defined threshold, an owner, and an escalation path. Generic indicators such as "number of incidents" carry limited analytical value without denominator context, trend data, and explicit linkage to risk appetite thresholds.
Reporting integration
ICT risk reporting should appear in enterprise risk committee papers alongside other risk categories, with comparable depth and analytical framing. When ICT risk reports arrive as separate CISO briefings outside the standard risk governance cycle, the management body loses the ability to assess ICT risk in proportion to other risks across the portfolio.
Escalation alignment
Escalation protocols for material ICT incidents must connect to the firm's existing incident management and risk escalation frameworks. Article 5(2)(i) requires the management body to put in place corporate-level reporting channels covering ICT third-party service provider arrangements, planned material changes to those providers, and major ICT-related incidents. These channels should operate through established ERM governance pathways rather than ad hoc reporting lines that sit outside the firm's standard escalation structure.
Avoiding Parallel Risk Processes
The most common structural problem in DORA implementation is running ICT risk as a compliance programme alongside, but separate from, the ERM framework. Firms in this position produce two sets of risk reports, maintain two governance structures, and expose the management body to an incoherent view of the firm's overall risk profile.
Single risk register
ICT risks should be captured in the entity's enterprise risk register rather than a standalone ICT risk register. This requires alignment on risk taxonomy, risk scoring methodology, and tolerance thresholds between the ICT function and the enterprise risk function, with a single owner responsible for ICT risk entries in the register.
Unified governance calendar
The ICT risk framework review cycle, including the annual review required under Article 6(5) and additional reviews triggered by material ICT-related incidents, supervisory instructions, testing conclusions, and audit findings, should synchronise with the entity's existing governance calendar. Ad hoc ICT governance cycles that fall outside the standard calendar create audit trail gaps and supervisory exposure.
Consistent methodology
Risk assessment methodology applied to ICT risk should be consistent with the methodology the firm uses for other risk categories in the ERM framework. Inconsistency between ICT risk scoring and enterprise risk scoring creates problems at the reporting layer: risks cannot be meaningfully aggregated or compared when the underlying methodology differs.
Shared evidence base
DORA supervisors and internal audit functions will examine the firm's ICT risk governance as part of a broader ERM review. Firms that maintain a single evidence base, covering board papers, risk committee minutes, KRI reports, and framework documents, have a significant operational advantage over firms that maintain separate ICT risk documentation alongside their ERM record.
The CRO's Role in DORA Compliance
DORA is a governance and risk management framework, and the CRO carries central responsibility for integrating it into the entity's risk architecture. Article 5 places obligations on the management body directly, but the risk function is the operational home for ICT risk governance in an integrated model.
In practice, this means the CRO owns ICT risk reporting to the board, ensures that ICT risk appetite is set and reviewed consistently with other risk categories, and provides independent oversight of the first line ICT function through the second line risk framework. The CISO retains responsibility for ICT operations and security, and the governance dimensions of ICT risk sit with the risk function.
Firms that position the CISO as the board's primary interlocutor on ICT risk governance create an oversight gap. The management body needs the enterprise risk lens applied to ICT risk, and that lens belongs to the risk function rather than to the ICT function that owns the operational programme.
UK firms should note that FCA operational resilience requirements are already in force and share significant structural overlap with DORA's ICT risk governance obligations. Firms that have embedded operational resilience governance through the FCA framework are well placed to extend that structure to meet DORA requirements, with the CRO playing the same integrating governance role across both.
