What breaks when DORA evidence relies on policies instead of runtime logs?

Why policies fail as DORA evidence

Under DORA, the problem is not whether the policy exists, but whether the control actually operated when a real user, administrator, or system exercised access. A policy can describe approvals, monitoring, or incident handling, yet still leave no proof that those steps happened at runtime. That is why assessors focus on operational records, not intent statements.

Evidence that breaks the gap typically includes timestamped approvals, access logs, alert records, change traces, and incident classification records. When those artefacts are missing, the organisation cannot show that the control was active in the environment being assessed. The result is a compliance weakness even if the policy language is strong.

runtime evidence also matters because DORA is concerned with operational resilience, not paper compliance. A control that is not observable in execution cannot be distinguished from a control that never ran, ran inconsistently, or failed under load. That distinction is central when the assessor is testing whether governance survives contact with production conditions.

What assessors expect to see instead

For access control, assessors want to see who requested access, who approved it, when it was granted, and what was actually used after the grant. For monitoring and incident handling, they want logs that show the detection path, classification decision, triage timing, and response activity. These records establish that the control was not only designed, but enacted.

Policy documents still have value, but mainly as the control statement that frames the intended process. They become supporting context, not primary evidence. If a policy says incidents must be classified within a defined window, the assessor will still look for the ticket history, timestamps, and escalation records that prove the classification occurred on time.

The same logic applies to privileged access and exceptions. If a policy says elevated access is approved and time-bound, the audit trail must show the approval event, the start and end of privilege, and the actual session or command activity. Without that execution trail, the control is not evidenced in a way that survives scrutiny.

For a practitioner-facing view of how this maps to regulatory and audit expectations, the Ultimate Guide to NHIs , Regulatory and Audit Perspectives and the Identity Security Regulatory Map both help connect control design to the evidence auditors expect to review.

Why the gap shows up first in live operations

The failure usually appears when teams rely on annual policy reviews, screenshots, or control attestations in place of operational telemetry. Those artefacts may show that someone approved a process, but they do not show that the process executed correctly in production. That is especially visible in access governance, incident response, and monitoring controls, where live event data is the only reliable proof.

This is also where audit pain tends to multiply: a policy can be copied across systems, but the runtime records differ by application, platform, or business unit. If teams do not retain the right event data at the point of execution, they may be unable to reconstruct what happened even when the control itself worked. In practice, the missing logs become the evidence failure.

For financial services environments, this matters because DORA is not asking for theoretical control descriptions. It is asking whether the organisation can demonstrate operational resilience with records that withstand testing, incident review, and supervisory challenge. The distinction between a documented process and a measurable process is the difference between a paper program and an auditable one.

NHIMG’s Financial Services Identity Security Guide is useful here because it ties identity and privileged access obligations back to the evidence trail needed in regulated environments.

Risk and Threat Considerations

When organisations substitute policies for logs, they create an evidence blind spot that can hide both control failure and misuse. The control may have been bypassed, misapplied, or never triggered, and without runtime records the assessor cannot distinguish those cases. In regulated environments, that can turn a solvable operational weakness into a formal compliance finding.

Failure mechanism: The organisation retains intent artefacts but not execution artefacts, so it cannot prove that approvals, monitoring, or incident handling occurred at the time the control was supposed to operate.

Impact: Assurances become non-verifiable, exceptions become hard to defend, and any actual misuse of access or delayed incident classification becomes easier to dispute, obscure, or miss entirely.

Practitioner Guidance

What to verify: Confirm that each control you expect to evidence has a corresponding runtime record, not just a policy statement. For access-related controls, that means timestamps, approver identity, granted scope, and usage traces; for incident handling, it means classification time, escalation path, and response activity.

What good looks like: A reviewer can reconstruct the full control event from system records without relying on a human recollection or a static document. If the evidence chain stops at the policy, the control is not ready for DORA scrutiny.

Common mistake: Treating policy review as proof of operation. That shortcut is acceptable for documenting governance structure, but not for demonstrating effective control performance in production.

Practitioner takeaway: Under DORA, the safest evidence model is event-based, not document-based, because assessors test whether the control worked in time, in context, and with a traceable operational footprint.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on audit logs instead of runtime enforcement?
• What breaks when runtime policies are guessed instead of observed?
• What breaks when privacy compliance relies on consent banners instead of runtime enforcement?
• What breaks when Kubernetes policies are enforced without runtime evidence?