DORA compliance is a graph problem, not a list problem

At a glance

What this is: JupiterOne says DORA compliance is failing where firms rely on static lists instead of live relationship data for assets, controls, and dependencies.

Why it matters: For IAM, NHI, and broader security teams, the message is that DORA evidence depends on continuously current identity, asset, and third-party relationships, not audit-time snapshots.

By the numbers:

• Nearly half of European financial firms were not compliant in early 2026, according to JupiterOne.
• Gartner predicts that 40% will not have met all of DORA’s requirements when audits and follow-up inspections begin later this year, according to JupiterOne.

Context

DORA requires financial institutions to prove that ICT risk is continuously managed across assets, dependencies, controls, and third parties. That is difficult when the operating model still depends on spreadsheets, CMDBs, and GRC repositories that capture static state rather than current relationships.

The identity angle matters because DORA-relevant evidence is not limited to servers and applications. The article explicitly calls out cloud resources, code, endpoints, user identities, machine identities, and subcontractor dependencies, which means governance fails whenever those entities are tracked as disconnected records instead of live relationships.

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 does DORA make continuous visibility more important than periodic audit checks?

A: DORA expects institutions to demonstrate current operational resilience, which means the control evidence has to reflect the live environment rather than a monthly or quarterly snapshot. Periodic checks miss changes in cloud services, identities, suppliers, and dependencies. That creates a mismatch between what the business believes is protected and what regulators can verify.

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 for DORA compliance when responsibility spans IT, risk, legal, procurement, and the board?

A: Accountability should sit with executive leadership and be shared through a formal governance model. DORA expects board-level oversight, clear ownership from the CISO and compliance function, and coordination across IT, risk, legal, and procurement. If responsibility is fragmented, controls drift, vendor oversight weakens, and incident response becomes slower and harder to evidence during review.

Technical breakdown

Why DORA compliance becomes a graph problem

DORA asks for a Register of Information that reflects current assets, dependencies, and controls, not an audit folder of prior attestations. A graph model is useful because it represents entities as nodes and their relationships as edges, letting teams answer operational questions about impact, dependency, and exposure in real time. That is materially different from list-based tools, which can enumerate items but cannot explain how a change in one asset affects a business function or a third-party chain.

Practical implication: Use relationship-aware data models when the compliance question is impact and dependency, not simple inventory.

Why spreadsheets, GRC, and CMDBs stall DORA evidence

Spreadsheets and traditional GRC systems can record controls, policies, and assessments, but they do not derive live evidence from the environment. CMDBs often improve inventory structure, yet they still lag reality and commonly miss cloud-native resources, SaaS applications, code repositories, and identities. For DORA, that gap matters because stale data undermines both the Register of Information and the ability to prove that controls remain effective between review cycles.

Practical implication: Treat documentation systems as records of intent, not proof of continuous control operation.

How live asset graphs support incident and third-party obligations

A live cyber asset graph links identities, code, cloud resources, and controls so teams can trace blast radius, impacted business functions, and transitive supplier risk quickly. That matters for DORA incident reporting, resilience testing, and third-party oversight, because each of those obligations depends on understanding not just what exists, but what it touches. In practice, the graph becomes the evidence layer that connects technical telemetry to regulatory reporting.

Practical implication: Build reporting and testing workflows around dependency paths so evidence can be generated from the current environment.

NHI Mgmt Group analysis

Live relationship evidence is now the compliance boundary, not static inventory. DORA turns asset context into a control requirement because institutions must prove current dependencies, not merely maintain a catalog. That shifts the governance question from whether an asset is listed to whether its relationships are continuously observable. Practitioners should treat live graph data as part of the compliance control plane, not as a reporting convenience.

Register of Information failures are often identity and dependency failures in disguise. The article’s strongest point is that modern financial environments include user identities, machine identities, cloud services, and subcontractors in the same compliance surface. When any of those are absent from the dependency model, the RoI becomes structurally incomplete. This is where identity governance and third-party governance converge under DORA, and teams need one shared relationship model.

Graph context is the only practical way to connect DORA’s five pillars. Incident management, resilience testing, third-party risk, and ICT risk management all depend on seeing how one control or asset affects another. A list can support a single audit question, but it cannot reliably support cross-pillar reasoning. The named concept here is compliance graph drift: the gap between recorded compliance objects and their live operational relationships. Practitioners should close that drift before audit pressure exposes it.

Manual compliance workflows create evidence latency that DORA does not tolerate. The problem is not only scale but time. If evidence is assembled after the fact, it can describe yesterday’s state while DORA expects present-tense assurance. Security and compliance teams should shift from snapshot collection to continuously refreshed control evidence.

For financial institutions, third-party risk is now a dependency mapping problem. DORA’s supplier and subcontractor obligations make transitive visibility essential. If the organization cannot trace which provider supports which business function, remediation will be reactive and incomplete. Practitioners should align governance, procurement, and security on a shared dependency model.

What this signals

DORA is pushing financial institutions toward evidence models that can answer questions about current state, not just policy intent. For IAM and NHI programmes, that means identity relationships, entitlement scope, and third-party access paths need to sit inside the same governance model as applications and infrastructure.

Compliance graph drift: the longer an organisation relies on static records to represent dynamic infrastructure, the further its audit narrative drifts from operational reality. That drift matters most when regulators ask for evidence that a control still existed at the time the risk was present.

The practical signal for security leaders is that compliance tooling must become operationally aware. If a platform cannot show identity, asset, and dependency context together, it cannot reliably support DORA reporting, incident scoping, or resilience testing.

For practitioners

• Build a live Register of Information Model assets, controls, identities, code, and providers as continuously updated relationships rather than static entries in a spreadsheet or CMDB.
• Map identity and service dependencies together Include user identities, machine identities, cloud services, and SaaS applications in the same dependency structure so regulatory evidence reflects real operational paths.
• Replace snapshot attestations with continuous evidence Pull control evidence from operational systems on an ongoing basis so DORA reports can be supported by current telemetry instead of periodic review notes.
• Trace third-party and subcontractor relationships Document transitive dependencies from core services to providers and subcontractors so incident scope and supplier exposure can be assessed quickly.
• Align incident, resilience, and compliance workflows Use the same asset relationship model to support major incident classification, scenario testing, and audit responses across DORA pillars.

Key takeaways

• DORA exposes the weakness of compliance programmes built on static inventories, because the regulation expects live evidence of assets, dependencies, and controls.
• The article’s core evidence is that many European firms were still not compliant in early 2026, and Gartner predicts 40% will miss full requirements by audit time.
• Practitioners need a relationship-first operating model that connects identity, assets, providers, and controls so compliance evidence can be generated from the current environment.

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.
• Asset Graph: An asset graph is a relationship model that connects devices, cloud resources, identities, applications, and controls into one structure. It allows teams to ask not only what exists, but also what depends on it, who owns it, and what exposure it creates.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Evidence Latency: Evidence latency is the delay between a control event occurring and the proof of that event becoming available for audit or governance use. In identity operations, long latency often means access reviews, offboarding, or privileged approvals are still being managed manually rather than continuously.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, IAM, and secrets management. It helps practitioners connect identity control evidence to the broader security and compliance programme they run every day.