What are the signs that an organisation is underprepared for DORA-style operational resilience requirements?

A common sign is that risk management, contract language, and recovery expectations have not been updated for critical ICT providers. If teams cannot clearly state service levels, reporting duties, access rights, termination conditions, or how regulatory risk is being transferred or mitigated, resilience planning is probably incomplete. That gap becomes visible during supplier reviews and incident response exercises.

What underprepared DORA readiness looks like in practice

Organisations usually look underprepared when operational resilience has been treated as a policy exercise rather than a working control set. The signs show up as vague ownership, outdated third-party assumptions, and weak evidence that ICT dependencies, recovery tolerances, and incident duties have been tested against real operating conditions.

Another warning sign is that supplier oversight is still generic. Under DORA-style expectations, critical ICT arrangements need clear service commitments, escalation paths, access and exit provisions, and enough operational detail to show the firm can govern the relationship rather than simply rely on it.

A final clue is inconsistency between what teams say they can recover and what exercises prove. If recovery objectives, reporting obligations, and contractual rights do not line up with test results, the organisation likely has resilience language but not resilience capability.

Where the gaps usually appear first

Most underprepared firms expose the gap in three places: contract management, incident readiness, and dependency mapping. Contracts may omit audit rights, termination support, or regulatory reporting duties. Incident playbooks may not reflect supplier obligations, time limits, or decision ownership. Dependency maps may stop at named vendors and fail to show which critical services actually rely on them.

That matters because DORA-style resilience is not only about having policies for ICT risk. It is about demonstrating that critical services can be monitored, tested, and restored even when a supplier, integration, or internal control fails.

Contract language is too high level to enforce service levels or regulatory duties.
Critical suppliers are reviewed as procurement items rather than operational dependencies.
Recovery testing is performed, but the results do not change tolerance, escalation, or exit planning.
Business, legal, risk, and technical teams use different definitions of what is “critical”.

Why these signs matter before an incident occurs

Underpreparedness is often visible long before a major outage. If a firm cannot show how provider access is controlled, how incident information will be obtained, or how termination and transition would work in practice, then resilience depends on goodwill instead of enforceable operating conditions.

The most important distinction is between documented assurance and usable assurance. A contract clause or review checklist is only useful if it produces verifiable behaviour during a supplier failure, major incident, or regulatory inquiry.

That is why teams should look for gaps in evidence, not just gaps in wording. If there is no clear record of testing, review outcomes, or negotiated remediation for critical ICT providers, the programme is probably not ready for supervisory scrutiny.

Risk and Threat Considerations

When DORA-style requirements are only partially implemented, the main risk is that a third-party ICT failure becomes a business continuity and regulatory problem at the same time. Weak contracts, weak visibility, and weak testing make it hard to contain disruption, prove oversight, or trigger the right response in time.

Failure mechanism: Critical dependencies are assumed to be manageable, but the organisation has not operationalised reporting duties, access rights, termination rights, or recovery expectations well enough to act on them during stress.

Impact: Incident response slows down, recovery becomes more dependent on the supplier than the firm expects, and the organisation may be unable to demonstrate the level of resilience and oversight that DORA-style supervision expects.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 sets the technical controls, while DORA and ISO/IEC 27001:2022 define the regulatory obligations.

Framework	Control / Reference	Relevance
DORA	EU Digital Operational Resilience Act	Directly governs ICT third-party risk, incident reporting, and resilience testing for the subject.
Recommendation — Align ICT contracts, testing, and incident processes to DORA's operational resilience expectations.
NIST CSF 2.0	GV.SC-01 — Supply Chain Risk Management	Operational resilience gaps often appear in third-party oversight and dependency governance.
	RC.RP-01 — Recovery Plan Execution	The question centers on whether recovery expectations are realistic and executable.
Recommendation — Establish supplier risk oversight and define actionable third-party obligations. Validate recovery plans against exercised supplier and service dependencies.
ISO/IEC 27001:2022	A.5.19 — Information security in supplier relationships	Supplier contracts and oversight are central to the readiness gap described.
	A.5.29 — Information security during disruption	Underprepared firms often fail to maintain control and response during incidents and outages.
Recommendation — Specify and review supplier security obligations in critical ICT contracts. Define disruption procedures that preserve security and service continuity.

Practitioner Guidance

What to verify: Check whether each critical ICT provider has a current service description, measurable obligations, named escalation routes, and an exit path that can actually be executed. If any of those elements exist only in procurement paperwork, treat the control as incomplete.

What to prioritise: Focus first on the arrangements that can most quickly increase blast radius, especially suppliers with production access, recovery dependency, or unresolved incident notification responsibilities. Those relationships determine whether a disruption stays local or becomes systemic.

Practitioner takeaway: The strongest indicator of readiness is not that the organisation has a resilience framework, but that it can prove its critical ICT relationships are contractually clear, operationally tested, and usable under pressure.