DORA compliance is a graph problem, not a list problem

At a glance

What this is: This analysis argues that DORA compliance fails when firms treat operational resilience as a static inventory exercise rather than a live dependency and control problem.

Why it matters: For IAM, NHI, and broader security teams, the key issue is that DORA exposes how identity, cloud, and third-party dependencies must be continuously evidenced, not periodically asserted.

By the numbers:

• 2026.
• Gartner predicts that 40% will not have met all of DORA’s requirements when audits and follow-up inspections begin later this year.

👉 Read JupiterOne's analysis of why DORA compliance is a graph problem

Context

DORA compliance is fundamentally a visibility problem. The regulation expects financial firms to know what they have, how systems depend on each other, and whether controls remain in place as environments change, which makes static inventories and annual attestations insufficient.

That matters to IAM and NHI programmes because identities, service accounts, tokens, cloud permissions, and third-party integrations are part of the dependency graph DORA expects firms to evidence. Where those relationships are invisible, control assurances become brittle and audit readiness becomes guesswork.

Key questions

Q: What breaks when DORA compliance is managed with spreadsheets and CMDBs?

A: Static tools break the evidence chain. They can describe assets and controls at a point in time, but they cannot continuously validate current dependencies, cloud changes, or machine identities. Under DORA, that means firms may appear organized while still lacking defensible proof that controls are operating now.

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. Service accounts, delegated access, API keys, and third-party integrations can connect critical systems in ways that inventories miss. If those identities are invisible, resilience claims are incomplete.

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. If the same register, dependency map, or control assertion changes materially when the environment changes, the programme has continuous assurance. If it does not, the evidence is stale.

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.

Technical breakdown

Why DORA needs a live dependency graph

DORA expects firms to maintain current evidence of assets, dependencies, and controls across continuously changing ICT environments. A graph model represents relationships between cloud resources, identities, code, endpoints, and third-party services, so teams can reason about impact rather than isolated records. This matters because resilience is not just about whether an asset exists, but whether its dependencies are understood well enough to prove continuity and control. In identity terms, the graph must include service accounts, access paths, and provider relationships because those are often the hidden routes through which operational risk spreads.

Practical implication: build DORA evidence from live relationships, not static asset lists.

Why spreadsheets, GRC tools, and CMDBs fall short

Spreadsheets and conventional GRC tools are good at documenting intent, but they do not continuously verify the environment. CMDBs may contain asset records, yet they often miss cloud-native services, SaaS, code repositories, and machine identities, and they rarely validate that relationships are still correct. That creates a gap between the compliance narrative and the operational state. Under DORA, that gap is a problem because the regulator cares about evidence that survives change, not a snapshot that was accurate when last updated.

Practical implication: use control evidence sources that can be re-queried as the environment changes.

How transitive third-party risk becomes a compliance issue

DORA extends beyond direct suppliers to the subcontractors and service dependencies that sit behind them. In practice, this means firms need to understand transitive exposure, not just named vendor relationships. Identity and access are central here because third-party service accounts, delegated permissions, and integration credentials often connect financial systems to external providers. If those identities are not mapped into the same dependency model as the rest of the environment, the organisation cannot credibly demonstrate operational resilience across the supply chain.

Practical implication: map third-party access paths and machine identities into the same register used for DORA reporting.

Threat narrative

Attacker objective: The objective is to exploit hidden dependencies and weak control evidence to create operational disruption, audit failure, or both.

1. Entry occurs through fragmented asset, identity, or third-party visibility, where critical connections are missing from the compliance model.
2. Escalation happens when stale records and manual attestations hide the real dependency chain, allowing risky access or service relationships to persist unchecked.
3. Impact is regulatory and operational at once: the firm cannot prove resilience, cannot accurately scope incidents, and faces remediation cost plus possible penalties.

NHI Mgmt Group analysis

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.

Identity is now part of the compliance perimeter, not a separate concern. The article’s strongest implication is that machine identities, service accounts, and delegated access paths are operational dependencies that influence auditability and resilience. When those identities are absent from the evidence model, the organisation cannot reliably show who can reach what, through which provider, and under what control conditions. Practitioners should treat identity topology as a DORA evidence problem, not just an IAM administration task.

Register of Information workflows expose a broader control gap: static governance cannot prove continuous assurance. The failure is not merely poor documentation. It is the assumption that periodic review can stand in for continuous validation in a fast-changing environment. That assumption breaks when cloud services, software supply chains, and access relationships change faster than manual processes can track. The practitioner takeaway is to replace snapshot compliance with continuously verifiable control evidence.

DORA is pushing financial firms toward relationship-aware security architectures. The regulation effectively rewards organisations that can answer impact questions quickly, including which assets, identities, and providers are implicated when a control fails. That aligns with the broader move toward security graphs and away from disconnected inventories. Teams that cannot model relationships will struggle not only with audit evidence but also with incident scoping and resilience testing.

Third-party governance must include the access model, not just the contract model. DORA’s supply chain expectations extend into subcontractors and integrated services, which means procurement records alone are not enough. The meaningful question is whether external identities and service relationships are visible, bounded, and continuously reviewed. Practitioners should treat third-party access paths as first-class compliance objects.

What this signals

Control evidence will keep moving closer to the live environment. DORA is another signal that regulators will not accept documentation as a substitute for operational proof. For IAM and NHI programmes, that means identity inventories, entitlement data, and third-party access mappings need to be queryable from the systems that actually enforce access, not reconstructed after the fact.

Relationship modelling is becoming a governance capability, not just an architecture preference. Teams that can trace how identities, assets, and providers connect will be better placed to answer audit, incident, and resilience questions quickly. The practical shift is toward security graphs, continuous telemetry, and lifecycle controls that stay aligned as environments change.

Identity lifecycle blind spots will continue to distort resilience reporting. If offboarding, rotation, and third-party access revocation are not visible in the same control model as cloud and application dependencies, DORA reporting will remain fragile. Practitioners should expect more pressure to prove that access paths are both current and bounded.

For practitioners

• 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.
• Shift from snapshot attestations to continuous control evidence Use telemetry from cloud, endpoint, identity, and security systems to prove that controls remain in place after changes, not just at review time.
• Test resilience against relationship-driven blast radius Run scenarios that start with a compromised dependency or external identity and measure how far the impact spreads across business functions and regulated services.

Key takeaways

• DORA compliance becomes far harder when organisations rely on static lists instead of live dependency models.
• Identity and third-party access are part of the resilience evidence chain, not separate admin issues.
• Teams that can regenerate control evidence from live systems will be better positioned for audits, incident response, and operational continuity.

Key terms

• Register Of Information: A Register of Information is the live record a regulated organisation uses to describe its assets, dependencies, and controls. Under DORA, its value depends on accuracy, completeness, and the ability to reflect changes in the operating environment rather than storing a stale compliance snapshot.
• Transitive Third-Party Risk: Transitive third-party risk is exposure that passes through one provider to another service or subcontractor the organisation does not directly control. It matters because operational resilience can fail in places that procurement records do not show, especially when external access and delegated services are involved.
• Continuous Control Evidence: Continuous control evidence is proof generated from live systems that a control is operating as intended right now. It is stronger than a periodic attestation because it can be refreshed as infrastructure, identities, and dependencies change, which is exactly the condition regulated environments increasingly face.
• Cyber Asset Graph: A cyber asset graph is a relationship model that connects assets, identities, code, controls, and providers so security teams can reason about impact and dependency. It is useful when compliance or resilience depends on understanding how changes in one part of the environment affect everything else.

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.

👉 The full JupiterOne article shows how graph context supports DORA evidence, incident scoping, and third-party dependency mapping.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners build programmes that support continuous control evidence and lifecycle accountability.