Notifications
Clear all
Topic starter
10/07/2026 9:18 pm
TL;DR: Many European financial firms were still not compliant in early 2026, and Gartner expects 40% will miss DORA requirements when audits and follow-up inspections begin later this year, according to JupiterOne. Static spreadsheets, CMDBs, and traditional GRC tools cannot maintain the live dependency and control evidence DORA expects.
NHIMG editorial — based on content published by JupiterOne: DORA Is a Graph Problem. Most Firms Are Trying to Solve It With a List
By the numbers:
- 2026., y half of European financial firms were not compliant in early 2026.
Questions worth separating out
Q: What breaks when DORA compliance is managed with spreadsheets and CMDBs?
A: Static tools break the evidence chain.
Q: Why do identities matter so much to DORA compliance?
A: Because identities are part of the dependency structure DORA expects firms to understand and prove.
Q: How do security teams know if DORA control evidence is actually working?
A: Control evidence is working when it can be regenerated from live telemetry, not manually reconstructed for an audit.
Practitioner guidance
- Map the DORA Register of Information to live dependencies Replace spreadsheet-driven RoI preparation with a continuously updated model of assets, identities, applications, and provider relationships so control evidence reflects the current environment.
- Include machine identities in audit scope Inventory service accounts, API keys, tokens, and delegated integrations alongside infrastructure assets so access paths are visible when documenting resilience and control coverage.
- Validate third-party and subcontractor access paths Trace external providers down to subcontractors and service connections, then confirm which identities and permissions actually link them to critical financial systems.
What's in the full article
JupiterOne's full article covers the operational detail this post intentionally leaves for the source:
- How its cyber asset graph models cloud, identity, code, and endpoint relationships for DORA evidence.
- How the platform maps transitive third-party dependencies across providers and subcontractors.
- How incident scoping and resilience testing use live relationship context to identify blast radius.
- How the platform evaluates controls against live data rather than documentation alone.
👉 Read JupiterOne's analysis of why DORA compliance is a graph problem →
DORA compliance and asset graphs: what IAM teams need to know?
Explore further
10/07/2026 9:41 pm
Graph-based compliance is becoming the default expectation for resilience programmes. DORA makes it hard to defend compliance with document-centric processes because the regulation depends on current relationships, not historical statements. That shifts the burden from collecting evidence to modelling the operating environment. For identity teams, the practical conclusion is that access, entitlement, and third-party dependencies must be represented as live relationships, not separate governance records.
A question worth separating out:
Q: Who is accountable when DORA readiness fails?
A: Accountability sits across cybersecurity, legal, compliance, enterprise risk, procurement, IT, and executive leadership because DORA is a cross-functional resilience requirement. If cybersecurity is left solely responsible, the operating model usually lacks the business engagement needed to maintain accurate evidence and remediation ownership.
👉 Read our full editorial: DORA compliance is a graph problem, not a list problem
