Which is harder under DORA, passing a questionnaire or proving recovery readiness?

Why proving recovery readiness is the harder DORA test

Questionnaires are useful as a screening tool, but they are still mostly documentary evidence. Under DORA, the harder standard is whether a financial entity can demonstrate that controls work in practice, including controlled access, timely incident reporting, and recovery execution across ICT and third-party dependencies. The difference is simple: intent is easier to state than resilience is to prove.

DORA’s emphasis is operational, not decorative. A supplier can say it has policies, backups, or escalation paths, but regulators and auditors will look for evidence that those arrangements are actually executable under stress, with the right people, systems, and dependencies in place when it matters.

What “proof” looks like under operational resilience expectations

Proof of recovery readiness means showing that the organisation can restore a service to an acceptable state within its defined tolerance, not just that it has a plan. That usually includes tested recovery procedures, validated dependencies, evidence of role clarity, and records that show incidents can be detected, escalated, reported, and contained within the required timelines.

This is where supplier chains matter. If a critical ICT provider, integrator, or downstream service cannot evidence its own recovery, your questionnaire answer becomes only one layer of assurance, not a defence. The regulator’s concern is whether the operational chain is resilient end to end, not whether each party can describe resilience in isolation.

The most relevant evidence is practical and time bound: test results, remediation of failed tests, incident logs, communication trails, restore points, access controls for recovery personnel, and proof that key functions can be performed without depending on an unverified manual workaround.

Why questionnaires are easier to pass than resilience tests

Questionnaires tend to reward completeness of response, while recovery readiness rewards demonstrated performance. A supplier can often answer “yes” to policy questions long before it has validated whether backup access, privileged recovery accounts, logging, escalation routes, and cross-border or cross-entity dependencies will actually hold during a disruption.

For DORA, the gap between stated control and exercised control is the real issue. A control that looks strong on paper but has never been tested under realistic conditions is not strong evidence of readiness. That is especially true when recovery depends on a third party, a shared platform, or a service account path that is rarely used and therefore often poorly governed. NHIMG’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful here because recovery evidence often depends on the governance of non-human access, not just policy statements.

In practice, the harder question is not “Did the supplier fill out the form?” but “Can the supplier still operate, recover, and report when the normal path is unavailable?” That is the kind of assurance DORA is designed to force.

Risk and Threat Considerations

When recovery readiness is only asserted, not demonstrated, the main risk is that a disruption becomes longer and more expensive than planned because the actual recovery path fails at the moment of need. In regulated financial services, that can turn a contained incident into a reportable operational failure, a prolonged outage, or a supplier concentration problem.

Failure mechanism: Teams over-rely on questionnaire answers, then discover during an incident or test that access is not controllable, recovery steps are unworkable, or a third-party dependency cannot restore service within the expected window.

Impact: The organisation loses time, confidence, and regulatory credibility at the point when it most needs evidence. Recovery delays can also expose weak privilege governance, fragile supplier dependencies, and gaps in incident reporting discipline.

Practitioner Guidance

What to verify: Treat questionnaire responses as a starting point, then verify whether the supplier can prove recovery with test evidence, remediation records, and a recent execution trail. If the only evidence is policy language, the assurance level is weak.

Decision rule: If a supplier supports a critical or important function, require evidence of restore, failover, and reporting performance before accepting the control as adequate. If the supplier cannot show that recovery steps were exercised, treat the gap as an operational risk, not a documentation issue.

What practitioners underestimate: Recovery readiness often fails at the seams between teams and suppliers, especially where privileged access, escalation authority, and recovery tooling are controlled by different parties. NHIMG’s Identity Security Regulatory Map helps frame why control evidence, access governance, and regulatory obligations have to line up.

Practitioner takeaway: Under DORA, the winning answer is not the best narrative, it is the best evidence that recovery can actually be executed under pressure.

For financial services teams, the practical standard is to prefer proof over promise, and to treat weak recovery evidence as a supplier-risk signal even when the questionnaire looks complete. NHIMG’s Financial Services Identity Security Guide is relevant because recovery assurance often depends on whether privileged and non-human access can still be controlled during disruption.

Related resources from NHI Mgmt Group

• Who is accountable for proving Active Directory recovery readiness?
• What do organisations get wrong when they treat cyber recovery as a compliance checklist under DORA?
• What happens when an airline tries to assign full blame for outage losses without proving its own recovery readiness?
• What is the difference between incident response and recovery planning under DORA?