DORA is reshaping ICT risk governance in financial services

At a glance

What this is: DORA is an EU regulatory framework that standardises ICT risk governance for financial entities and raises expectations for incident reporting, resilience testing, and third-party oversight.

Why it matters: Financial and identity teams need to treat operational resilience as a governance requirement because access, vendor dependency, and incident handling now carry explicit regulatory expectations across the ICT estate.

Context

DORA is the EU’s Digital Operational Resilience Act, a regulation aimed at making financial institutions more resilient to ICT-related incidents. In practical terms, it turns cyber resilience into a formal governance obligation for banks, insurers, payment firms, investment firms, and related licensed entities.

The core problem is not only attack volume but operational dependence on digital services, third-party providers, and tightly coupled processes. DORA responds by requiring institutions to define responsibilities, monitor ICT risk continuously, report major incidents, and prove resilience through testing and oversight.

Key questions

Q: Who is accountable for ICT risk management under DORA?

A: Senior management is accountable, with regulated entities expected to assign clear responsibilities for ICT risk oversight, reporting, and resilience testing. In practice, that accountability extends to access governance because identity failures can trigger incidents, supplier exposure, and recovery problems. The board cannot delegate away the evidence requirement.

Q: Why does DORA make third-party oversight more demanding?

A: Because regulated firms remain accountable even when a critical service is run by a provider. DORA expects contractual rights, continuous monitoring, and clear recovery expectations, so outsourced ICT does not become ungoverned ICT. Third-party access and obligations now need lifecycle control, not just procurement approval.

Q: What breaks when incident reporting for ICT events is slow or inconsistent under DORA?

A: Slow or inconsistent incident reporting weakens containment, obscures regulatory accountability, and makes it harder to learn from operational failures. In practice, teams lose time correlating impact, documenting decisions, and preserving evidence. That creates compliance risk and can also delay remediation across connected services, especially when the incident affects multiple business lines or third-party dependencies.

Q: What is the difference between resilience testing and ordinary vulnerability scanning?

A: Vulnerability scanning finds known weaknesses, while resilience testing checks whether the organisation can continue, recover, and report under realistic disruption. DORA cares about the business and regulatory outcome, not just the presence of technical flaws. Both matter, but only testing proves recovery capability.

Technical breakdown

ICT risk management as a governed control plane

DORA treats ICT risk management as an ongoing control plane, not a periodic compliance exercise. That means institutions need defined ownership, documented processes, continuous monitoring, and periodic reassessment of controls as systems, vendors, and threat patterns change. The article also ties this to board-level accountability, which matters because resilience failures increasingly start with governance gaps rather than a single technical weakness. For identity and access teams, that often means the risk model must include who can change critical systems, who can approve vendor access, and how exceptions are tracked across operational workflows.

Practical implication: map ICT risk ownership to named roles and make escalation paths auditable across identity, operations, and vendor management.

Incident reporting turns detection into a regulatory workflow

DORA requires major ICT incidents to be reported quickly, with an initial notification followed by more detailed updates on root cause, impact, and remediation. That changes the function of detection and triage, because the organisation is no longer only deciding how to contain an incident internally. It must also preserve evidence, maintain a clean chronology, and coordinate with competent authorities while the event is still active. For identity programmes, this raises the bar on logging, access traceability, and the ability to reconstruct privileged actions across systems and third parties.

Practical implication: align incident response playbooks with reporting obligations so evidence collection, root-cause analysis, and regulatory notification are linked from the start.

Third-party risk now includes resilience proof, not just contracting

DORA makes third-party oversight materially more demanding because critical ICT providers must be vetted, monitored, and contractually bound to incident response, data protection, inspection rights, and liability terms. The real shift is that supplier trust can no longer rest on procurement due diligence alone. Financial entities need continuous assurance that provider controls, access boundaries, and recovery capabilities actually match the services being consumed. Where vendors operate privileged integrations or hold sensitive data, the governance burden extends into lifecycle management, offboarding, and recovery validation.

Practical implication: review vendor contracts and access governance together so provider obligations, termination rights, and recovery expectations are enforced as one control set.

Threat narrative

Attacker objective: The end state is operational disruption that degrades financial services and erodes trust in regulated ICT systems.

1. Entry occurs through ICT dependency rather than a single compromise, because the article frames outages, breaches, and third-party failures as the operational triggers DORA is designed to absorb.
2. Escalation happens when weak oversight, poor monitoring, or untested controls allow an ICT event to spread across services, vendors, or business processes before containment is effective.
3. Impact is measured in disrupted financial services, delayed reporting, reputational damage, and potential systemic effects on trust and market stability.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DORA turns operational resilience into an identity and governance problem, not just a security programme. The article’s emphasis on board accountability, continuous monitoring, and third-party oversight shows that resilience now depends on who owns access, who approves exceptions, and who can evidence control performance. For IAM and IGA teams, this is a governance shift as much as a technical one, because the control failures DORA cares about are organisational before they are infrastructural.

Third-party access governance becomes part of resilience assurance under DORA. The regulation’s focus on ICT third-party providers means vendor trust has to be proved through contract terms, monitoring, and offboarding discipline, not assumed from procurement review alone. That has direct implications for NHI and privileged access programmes where provider credentials, integrations, and recovery paths can outlive the business need that created them. Practitioners should treat supplier access as a lifecycle governed asset, not a static onboarding event.

Incident reporting changes the value of identity telemetry. DORA’s reporting deadlines make traceability, chronology, and root-cause evidence essential rather than optional. Identity logs, privileged session records, and vendor-access audit trails become compliance evidence as well as security data, which means gaps in log quality are now governance gaps. Organisations that cannot reconstruct access and change history quickly will struggle to meet both operational and regulatory expectations.

DORA validates a resilience-first model for regulated digital services. The article shows a move away from fragmented local controls toward standardised, testable governance across the EU financial sector. That direction matters because it pushes security leaders to align identity controls, resilience testing, and incident workflows into one operating model instead of treating them as separate functions. The practical conclusion is that resilience is now measured by recoverability, accountability, and proof.

Named concept: resilience evidence chain. DORA implicitly demands a continuous evidence chain connecting ownership, monitoring, testing, incident reporting, and third-party oversight. That chain is what regulators, auditors, and internal risk leaders will inspect when an ICT event occurs or a provider fails. The practitioner takeaway is to design governance so evidence is produced by normal operations, not assembled after a disruption.

From our research library:

• An unplanned outage in a cloud environment costs an average of $9,000 per minute, per the Uptime Institute’s 2023 Global Data Center Survey.

What this signals

Resilience evidence chain: DORA pushes financial institutions to treat governance evidence as an operational output, not an audit afterthought. If you cannot trace who owned a control, who changed it, who tested it, and who reported the incident, you do not have a defensible resilience model.

For identity and access programmes, the practical effect is that access governance, privileged activity logging, and vendor lifecycle management now sit inside the same regulatory conversation as recovery and continuity. That makes identity telemetry more valuable, but also more unforgiving when the records are incomplete.

For practitioners

• Define ICT risk ownership Assign board-level and operational owners for ICT risk decisions, incident escalation, and third-party oversight so accountability is explicit in the control model.
• Link incident response to reporting obligations Update incident playbooks so detection, evidence preservation, root-cause analysis, and regulator notification follow one sequenced workflow.
• Review third-party contracts and access lifecycles Check that provider agreements cover incident notice, audit rights, recovery expectations, and termination of access when services end.
• Strengthen resilience testing across critical services Include scenario testing and threat-led penetration testing for systems and vendors that support high-value financial workflows, then track remediation through to closure.

Key takeaways

• DORA reframes ICT resilience as a governed responsibility across financial services, with clear ownership and documented oversight.
• The regulation ties incident handling, resilience testing, and third-party assurance into one compliance model rather than treating them as separate disciplines.
• Identity, access, and vendor lifecycle controls become part of the evidence base regulators will expect when an ICT event occurs.

Key terms

• ICT Risk Management Framework: A structured set of governance, technical, and operational controls used to identify, monitor, and reduce risk from information and communication technology. For DORA, it must cover internal systems, third-party dependencies, reporting, and recovery in a way regulators can assess.
• Digital Operational Resilience Act: DORA is an EU regulatory framework that requires financial entities and their critical ICT providers to prove they can withstand, respond to, and recover from disruption. For identity teams, it turns authentication, access, and recovery into evidence-bearing controls rather than background IT functions.
• Third-Party ICT Risk Oversight: Third-party ICT risk oversight is the practice of governing technology risk introduced by external service providers. It includes due diligence, contractual security requirements, monitoring, testing, and exit planning. The goal is to ensure outsourced services do not undermine resilience, accountability, or recovery during disruption.
• Incident Reporting Workflow: An incident reporting workflow is the structured sequence used to detect, classify, notify, and document a cyber incident. In regulated environments, it helps teams preserve evidence, meet notification timelines, and coordinate internal response while keeping reporting consistent across business and technical stakeholders.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.