How should organisations prove continuous resilience under CRA and DORA?

What continuous resilience proof looks like under CRA and DORA

Continuous resilience is not proved by a policy pack or a single annual test. It is proved by showing that controls still operate after change, and that failures are detected, contained and recoverable when they occur. For CRA and DORA, the evidential standard is operational: repeated validation, traceable results, and clear linkage between the control being tested and the service or product risk it is meant to absorb.

That shifts the burden from “we have controls” to “we can demonstrate those controls still work in the current environment”. In practice, organisations need evidence that testing is recurring, scoped to critical services, and versioned so that a change in configuration, supplier, identity model or recovery process does not invalidate last quarter’s assurance.

A useful way to think about this is as a control loop, not a one-time checkpoint. The strongest proof combines test evidence, remediation evidence, and post-change revalidation so that resilience can be shown as a live property of the operating environment rather than a compliance claim.

Why identity, logging and recovery evidence carry so much weight

In resilience regimes, access and recovery controls are often where the gap between paper and practice appears first. If privileged access still works after a rebuild, if logging still captures the events needed for diagnosis, and if recovery procedures still function after a product or infrastructure change, the organisation has stronger proof that its resilience is real rather than assumed.

That is why evidence should not stop at the control statement. Teams should be able to demonstrate that privileged paths are restricted and reviewable, that recovery accounts and break-glass access are governed, and that logging survives the same failure conditions the business is trying to withstand. The question is not whether these controls exist, but whether they still behave as expected under stress.

This is also where credential and offboarding evidence becomes important. If a departed user, vendor or service account can still authenticate, or if a secret can still be used after ownership has changed, the organisation may be able to pass a documentation review while still failing a resilience test. Financial services identity security guidance is useful here because it connects regulatory resilience expectations to privileged access and third-party risk in a way practitioners can operationalise.

How to structure evidence so auditors and supervisors can follow it

The most defensible evidence chain is simple: define the control objective, show the test that exercises it, show the result, and show what changed after any failure. That structure lets a reviewer trace resilience from requirement to execution instead of relying on narrative assurance.

• Keep recurring test records tied to the specific control, environment and service tier that was exercised.
• Record the date, scope, outcome and remediation status for each validation cycle.
• Retain evidence that the same control was rechecked after significant changes, not only during the scheduled cycle.
• Preserve proof that third-party dependencies, privileged access and recovery paths were included where they materially affect continuity.

For organisations that need a regulatory anchor, the EU Digital Operational Resilience Act (DORA) is the clearest reference point for ongoing operational resilience testing, incident handling and ICT third-party oversight. For product-side resilience, the EU Cyber Resilience Act pushes the same “prove it through the lifecycle” idea into secure-by-design and vulnerability-handling expectations.

Risk and Threat Considerations

Continuous resilience fails when controls are treated as static artefacts. The main risks are drift, blind spots after change, and false confidence from tests that do not exercise the real failure path. In identity-heavy environments, a stale privilege model, an untested recovery account or an orphaned secret can preserve access for an attacker long after the organisation believes the control has been validated.

Failure mechanism: Change introduces control drift, for example a new integration bypasses logging, a privileged account is exempted from review, or an offboarding process leaves a credential valid. The organisation then continues to rely on old evidence that no longer reflects the live state.

Impact: The control set may look compliant while still being unable to detect, contain or recover from a real incident. That creates regulatory exposure under CRA and DORA, but more importantly it increases the chance that a breach, outage or supplier failure becomes prolonged because the expected safeguards are not actually present.

Practitioner Guidance

What to prioritise: Start with the controls whose failure would most directly break continuity, typically privileged access, recovery access, logging, and third-party dependencies. Those are the controls that need repeated validation after any meaningful change, not just periodic sign-off.

What to verify: Ask whether each test proves current operation in the live configuration, not only that a process exists on paper. If the evidence cannot show the post-change state, the proof of resilience is weak even if the control previously passed.

Practitioner takeaway: Under CRA and DORA, the strongest resilience evidence is not more documentation, it is a repeatable chain showing that critical controls still work after the environment changes, especially where access and recovery are involved.

Related resources from NHI Mgmt Group

• Guide: DORA Guide
• Who is accountable when cyber resilience controls fail under NIS2 and DORA?
• Who is accountable when a product cannot prove secure design under the CRA?
• How should manufacturers prove that security testing under the CRA is effective?
• Why do third-party ICT dependencies create the biggest operational resilience risk under DORA?