DORA is reshaping ICT risk governance in financial services

At a glance

What this is: This is an independent analysis of DORA and its effect on ICT risk, incident reporting, resilience testing, and third-party oversight in financial services.

Why it matters: It matters because financial IAM, NHI, and security teams must align access governance, vendor oversight, and incident response with a regulation that turns resilience into an enterprise obligation.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Veriff’s analysis of DORA compliance for financial services

Context

DORA makes ICT risk a board-level operational issue for financial services, not just a security programme concern. The regulation forces institutions to prove they can prevent, detect, report, and recover from ICT-related incidents across systems, vendors, and business processes.

For IAM, NHI, and PAM teams, the most important shift is that access governance now sits inside resilience governance. That includes third-party access, service accounts, secrets, and the lifecycle controls that determine whether a disruption becomes a contained incident or a regulatory problem.

Key questions

Q: How should financial institutions align IAM and third-party access with DORA?

A: They should treat IAM, PAM, and NHI controls as part of the regulated ICT risk framework, not as separate technical tools. That means documenting access ownership, tightening supplier credential lifecycles, and ensuring incident reporting can trace identity-related failures across internal and external systems. DORA expects governance evidence, not just security intent.

Q: Why do third-party credentials create DORA compliance risk?

A: Because delegated access often persists longer than the business need that created it, especially across vendors, managed services, and temporary integrations. If keys, tokens, or service accounts are not revoked promptly, they expand the attack surface and weaken incident containment. Under DORA, that becomes both an operational and a governance problem.

Q: What breaks when identity events are not visible during an ICT incident?

A: The organisation loses the ability to classify scope, prove root cause, and produce timely regulatory reporting. If service account misuse or vendor access abuse is not observable, the incident response process becomes guesswork and recovery slows. DORA’s reporting obligations assume identity telemetry exists and is actionable.

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.

Technical breakdown

ICT risk management under DORA

DORA requires financial entities to maintain an ICT risk management framework that is continuously updated, documented, and embedded in governance. In practice, that means inventories, risk assessments, control reviews, and incident handling cannot live in separate silos. The framework has to cover internal systems and the external services those systems depend on, including identity, access, and third-party technology layers. For identity teams, this is where access policy, credential lifecycle, and vendor access oversight become part of resilience engineering rather than standalone compliance tasks.

Practical implication: map IAM, PAM, and NHI controls directly into the ICT risk framework and board reporting cycle.

Incident reporting and operational resilience testing

DORA ties incident reporting to resilience testing because organisations need evidence that controls work before a major event occurs. The article highlights initial notification, follow-up reporting, and ongoing communication with regulators, alongside threat-led penetration tests, scenario testing, and vulnerability assessments. That combination matters because resilience is not proven by policy alone. It is proven by how quickly an institution can identify impact, isolate scope, and explain root cause across systems, third-party providers, and identity dependencies.

Practical implication: align detection, triage, and reporting playbooks so identity-related failures can be escalated as regulated incidents.

Third-party ICT risk and delegated access

DORA treats outsourced ICT services as part of the institution’s risk surface, which is especially relevant where vendors, managed services, or integrators hold access to production environments. Contract terms, audit rights, notification timelines, and liability allocation are all part of the control model. That is a governance problem as much as a technical one, because third-party access often persists beyond the business need that created it. Where service accounts, API keys, and vendor credentials are involved, offboarding and monitoring are the difference between controlled dependency and uncontrolled exposure.

Practical implication: require lifecycle controls for all third-party credentials and audit them as part of supplier oversight.

Threat narrative

Attacker objective: The objective is to disrupt regulated financial services, expose sensitive data, and create operational and reputational damage that cannot be contained quickly.

1. Entry begins when financial institutions rely on external ICT providers, exposed credentials, or weakly governed access paths that expand the attack surface beyond the core enterprise.
2. Escalation occurs when standing access, poor monitoring, or delayed incident detection allows an attacker or failure to move from a local issue into a broader service disruption.
3. Impact follows when outages, breaches, or third-party failures interrupt payments, banking services, or regulated operations and force reporting, containment, and recovery under DORA.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

DORA is really a governance model for dependency risk, not just a compliance rule. The article frames resilience as a mix of risk management, reporting, testing, and supplier oversight, which is the right structure for modern financial operations. That matters because identity, hosting, and vendor access are now inseparable from service continuity. The practitioner conclusion is that ICT governance and identity governance have to be designed together.

Third-party access without lifecycle offboarding: DORA exposes the failure mode where vendor credentials outlive the business relationship that justified them. The article’s emphasis on ICT third-party risk management, SLAs, and oversight points to a common gap: access is granted for delivery, but not systematically revoked when delivery ends. That is a control failure, not a documentation issue. The practitioner conclusion is that supplier risk reviews must include credential retirement as a hard control.

Incident reporting only works when identity events are observable in time. DORA assumes an organisation can detect, classify, and escalate major ICT incidents quickly enough to satisfy regulatory obligations. If service account abuse, compromised API keys, or outsourced access failures are invisible, the reporting process becomes reactive and incomplete. The practitioner conclusion is that identity telemetry is part of regulatory readiness, not just detection engineering.

DORA accelerates the convergence of security, resilience, and access governance in financial services. The article shows that resilience testing, vendor controls, and management accountability are now part of one operating model. That pressures teams to treat IAM, PAM, and NHI controls as evidence-bearing controls for the firm’s wider resilience posture. The practitioner conclusion is that access governance can no longer be measured only by policy compliance.

Resilience testing should be read as a proof requirement for delegated access. Threat-led exercises and scenario tests become meaningful only when they include the identity paths that can fail under stress. If suppliers, service accounts, or privileged operators are excluded, the test understates real recovery risk. The practitioner conclusion is that testing scope must match actual delegation chains.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why third-party access and incident reporting are so often under-instrumented.
• Read Ultimate Guide to NHIs , Regulatory and Audit Perspectives for the audit and evidence angle that DORA teams usually need next.

What this signals

Third-party access will become the pressure point in DORA programmes. When 92% of organisations expose NHIs to third parties, the risk is not abstract. It means financial institutions need to look at contract renewal, vendor exit, and delegated access as one lifecycle, not three separate processes. The practical question is whether your supplier governance can prove that credentials are removed as reliably as they are issued.

DORA also pushes identity teams toward evidence-based resilience. If access reviews, incident timelines, and recovery tests cannot be linked, regulators will see control design without control proof. That is where the compliance burden shifts from policy writing to operational traceability.

Incident reporting becomes easier when identity telemetry is built into the control plane. Financial institutions that can correlate privileged access, service account activity, and vendor sessions will be better positioned to explain impact and recovery. For a broader control baseline, the NIST Cybersecurity Framework 2.0 remains a useful reference point for govern, identify, protect, detect, respond, and recover.

For practitioners

• Map identity controls into ICT risk governance Tie service account management, privileged access review, secret rotation, and third-party credential oversight to the same risk register used for DORA reporting and board review.
• Add credential offboarding to supplier exit processes Require explicit revocation of API keys, certificates, tokens, and vendor accounts when a contract ends, is renewed, or changes scope.
• Test identity failure inside resilience exercises Include compromised service accounts, broken federation, and third-party access loss in tabletop and technical tests so incident response teams practice the identity path, not just the infrastructure outage.
• Build regulator-ready evidence for access governance Preserve logs, review records, and incident timelines that show who had access, why it existed, and when it was removed.

Key takeaways

• DORA turns resilience into a governance obligation that spans ICT risk, supplier oversight, and identity controls.
• The biggest practical gap is often not the regulation itself but the inability to prove who had access, why it existed, and when it ended.
• Financial teams should align IAM, PAM, and NHI evidence with incident reporting and resilience testing before a regulator or outage forces the issue.

Key terms

• Digital Operational Resilience: The ability of an organisation to keep critical digital services running, recover quickly from disruption, and prove that its controls work under stress. In financial services, this includes governance, incident handling, testing, and supplier oversight, not just technology uptime.
• 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.
• Third-Party ICT Risk: The risk created when external vendors, managed service providers, or other suppliers handle systems, data, or credentials that affect business continuity. Under DORA, this risk includes contract terms, monitoring, audit rights, and the lifecycle of delegated access.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Veriff: Digital Operational Resilience Act (DORA): Key steps for financial services success. Read the original.