Weak DORA readiness usually shows up as incomplete asset visibility, slow incident handling, inconsistent risk assessments, and limited testing of recovery paths. It also appears when third-party ICT providers are not governed as part of the same control framework. These gaps suggest the organisation can describe resilience in policy, but cannot yet demonstrate it under pressure.
When DORA Gaps Become Operationally Visible
A weak ICT risk management programme rarely fails in one dramatic moment. It shows up as routine control drift: assets are missed, risk decisions are inconsistent, testing is infrequent or superficial, and resilience claims cannot be reproduced during an incident or recovery exercise. Under DORA, that is usually the point at which policy language stops being persuasive.
The clearest sign is that the programme cannot connect inventory, ownership, impact, and recovery into one defensible view. If teams cannot show which ICT services matter most, who owns them, how dependencies are monitored, and what recovery objective they support, then the programme is still descriptive rather than operational.
Third-party ICT oversight is part of the same test. DORA expects organisations to treat external providers, outsourced services, and delegated controls as part of the resilience model, not as a separate procurement concern. A control set that protects internally owned systems but cannot demonstrate equivalent scrutiny for critical vendors is incomplete.
- Missing or stale ICT asset inventories
- Risk assessments that differ by team or are not refreshed after material change
- Recovery plans that exist but have not been validated against realistic failure paths
- Third-party dependencies that are documented but not actively governed
That pattern is why resilience programmes often look stronger in governance documents than in evidence. The question is not whether controls exist, but whether they are current, tested, and tied to operational decision-making.
Where DORA Readiness Breaks Down in Practice
The most common weakness is poor visibility into the ICT estate, including service ownership, critical dependencies, and control coverage. Without that baseline, organisations tend to manage incidents reactively and cannot prove that their risk picture reflects the real environment.
Another failure mode is slow or inconsistent incident handling. If event triage, escalation, root-cause analysis, and post-incident action tracking are not standardised, then the programme cannot show that it learns from disruption. That matters because DORA is not satisfied by a generic incident process, it expects disciplined operational response and follow-through.
Recovery testing is equally revealing. A programme may have backup procedures, failover steps, and business continuity documents, yet still be weak if those paths are not exercised under realistic conditions. The most telling gap is when recovery is assumed rather than demonstrated, especially for critical ICT dependencies and outsourced services.
For organisations looking to benchmark the maturity of their control environment, NHI Mgmt Group’s Ultimate Guide to NHIs, Regulatory and Audit Perspectives is useful because it frames governance and auditability as evidence problems, not just policy problems. The broader lifecycle view in NHI Lifecycle Management Guide also helps teams think about visibility, rotation, and offboarding as operational controls, while Top 10 NHI Issues is a useful reminder that hidden access paths and third-party exposure are usually where weak programmes are exposed first.
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 set the technical controls, while DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | ICT risk management — ICT Risk Management | DORA directly governs ICT risk control, resilience, testing, and incident handling for this question. |
| ICT third-party risk management — ICT Third-Party Risk Management | Weak DORA readiness often shows up in poor governance of outsourced ICT dependencies. | |
| Operational resilience testing — Operational Resilience Testing | Recovery and testing gaps are a core sign that resilience cannot yet be demonstrated. | |
| Recommendation — Build and evidence ICT risk controls that stay effective under operational stress. Apply uniform oversight to critical ICT suppliers and validate their resilience obligations. Test recovery paths under realistic scenarios and fix failures exposed by exercises. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | A coherent ICT risk programme needs a current strategy tying risk decisions to business services. |
| ID.AM — Asset Management | Incomplete asset visibility is one of the clearest symptoms of weak readiness. | |
| RC.RP — Recovery Planning | Recovery paths must be proven, not assumed, to meet resilience expectations. | |
| Recommendation — Align ICT risk decisions to business-service criticality and approved risk tolerance. Maintain an accurate inventory of ICT assets, owners, and dependencies. Validate recovery procedures against realistic disruption scenarios and actual dependencies. | ||
Practitioner Guidance
What to verify: Test whether the organisation can produce a current ICT service map, named ownership, dependency list, and recovery evidence for its most important business services. If any of those must be assembled ad hoc during an audit or incident, the programme is not yet strong enough for DORA expectations.
What to prioritise: Focus first on the control areas that create proof, inventory accuracy, incident workflow discipline, recovery validation, and third-party oversight. Those are the places where organisations either demonstrate resilience or reveal that they only have a policy for it.
Practitioner takeaway: DORA readiness is less about having more documents and more about proving that critical ICT risk decisions, recovery actions, and supplier controls still hold when the organisation is under pressure.
Related resources from NHI Mgmt Group
- Who is accountable for ICT risk management under DORA?
- How should organisations build DORA-aligned ICT risk management around Active Directory and other identity services?
- How should organisations build ICT risk management that satisfies DORA, NIS2, and ISO 27001 without creating extra operational drag?
- What are the signs that an AI risk management programme is failing?
