The control framework becomes superficial. Teams may produce policies and contracts, but they still lack proof that assets are inventoried, responsibilities are defined, suppliers are monitored, and controls are improving over time. That leaves cyber-resilience untested in practice and makes it difficult to demonstrate that the organisation can withstand disruption and recover effectively.
Why paper compliance fails as a DORA operating model
DORA is not satisfied by a policy pack, a contract review, or a one-off assurance exercise. It expects firms to show that digital operational resilience is lived through inventory, governance, monitoring, testing, and improvement. A paper-only approach often leaves the organisation with documented intent but no defensible proof that critical services, dependencies, and recovery paths are actually understood and controlled. That matters because the regulation is designed to expose whether resilience exists under stress, not whether the organisation can describe it neatly on paper. For background on the regulatory objective, the EU Digital Operational Resilience Act (DORA) sets the expectation that financial entities can withstand, respond to, and recover from ICT disruption.
In practice, many organisations discover the gap only after a test, an audit challenge, or a supplier issue forces them to prove what the documentation never verified.
What evidence-based resilience looks like under DORA
An evidence-based programme turns resilience into something the organisation can observe and prove. That means it can identify critical functions, map the supporting assets and suppliers, assign accountable owners, test incident and recovery arrangements, and track whether weaknesses are being reduced over time. The important shift is from static compliance artefacts to operational evidence: asset registers that match reality, test results that show whether recovery objectives are met, third-party oversight that is continuous rather than annual, and management information that shows trends instead of isolated snapshots.
This is also where many organisations misread the requirement. DORA does not ask whether a control exists somewhere in a policy. It asks whether the control is effective in the operating environment. A supplier clause is useful, but it is not a substitute for knowing which business services depend on that supplier, what failure modes matter, and how quickly the organisation can detect and respond when those dependencies degrade.
- Inventory evidence should tie critical services to systems, data, and suppliers.
- Testing evidence should show both planned exercises and remediation of findings.
- Governance evidence should show named ownership, decision-making, and follow-up.
- Monitoring evidence should demonstrate that issues are detected and escalated in time.
The strongest analogue in broader cyber governance is the control-and-outcome pairing used by the NIST Cybersecurity Framework 2.0, where outcome-based control maturity matters more than document volume. Where resilience evidence depends on control verification and not just policy existence, the approach is close to how NIST SP 800-53 Rev 5 Security and Privacy Controls treats control effectiveness as something that must be implemented and assessed, not merely declared.
Where teams break down is at the point where they cannot connect a control to a service, a test, or a remedial action that changed the risk picture.
Where organisations usually overclaim resilience
Tighter compliance routines often increase documentation overhead, requiring organisations to balance audit comfort against operational proof. That tradeoff becomes visible when teams mistake completeness of paperwork for completeness of resilience. The common overclaims are familiar: a supplier register is treated as supplier oversight, a tabletop exercise is treated as recovery readiness, or a business continuity plan is treated as proof that the technology stack can actually be restored.
There is also a governance edge case worth naming. Some organisations can show strong policy lineage but weak control telemetry, while others can show excellent technical monitoring but poor board-level accountability for remediation. DORA needs both. If the evidence only proves that a requirement was written down, the organisation has not shown that it can operate under disruption. If the evidence only proves technical activity, it may still fail to show that management can challenge, prioritise, and correct resilience gaps across the business.
That distinction is especially important where third parties, cloud services, or shared platforms are involved. Paper assurances often collapse there because dependency chains are longer than the original review assumed, and recovery responsibilities are split across multiple parties. This is one of the main reasons DORA-style resilience work cannot stop at legal terms or policy acknowledgements.
Guidance is not fully uniform across firms on how much evidence is enough for every control, but the consensus is clear that evidence must be current, specific to the service, and traceable to action.
Risk and Threat Considerations
The material risk is false resilience: the organisation believes it can tolerate disruption, but the operating model has not been stress-tested in a way that proves it. That creates exposure across availability, recoverability, third-party dependence, and supervisory challenge. It also creates a governance risk, because the board and senior management may be making decisions on artefacts that do not reflect real operating conditions.
Failure mechanism: The failure usually appears when controls are documented but not exercised, dependencies are incomplete, and monitoring does not prove whether recovery objectives are actually achievable. In a disruption, that combination can hide single points of failure, untested restoration steps, and supplier weaknesses until the organisation needs them most.
Impact: The organisation may be unable to restore critical services within the expected tolerance, may fail to demonstrate effective oversight of ICT risk, and may struggle to evidence remediation after incidents or supervisory review. That can turn a manageable operational issue into a resilience, compliance, and trust problem at the same time.
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 | The question is about treating DORA as paperwork instead of operational resilience. |
| ICT third-party risk management — ICT Third-Party Risk Management | Supplier oversight and dependency evidence are central to the failure mode described. | |
| Digital operational resilience testing — Digital Operational Resilience Testing | The issue is that resilience is not proven through exercised and remediated testing. | |
| Recommendation — Align controls to tested ICT resilience outcomes rather than static compliance artefacts. Map critical services to suppliers and verify oversight with current, service-linked evidence. Use testing results to prove recovery capability and close gaps that tests expose. | ||
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | The question concerns whether resilience is managed as an operating discipline, not paperwork. |
| ID.AM — Asset Management | The answer depends on proving inventories and dependencies are accurate and current. | |
| PR.IP — Information Protection Processes and Procedures | Paper compliance fails when processes exist but are not operationally verified. | |
| Recommendation — Tie resilience decisions to risk outcomes that management can track and challenge. Maintain accurate asset and dependency inventories that support service recovery decisions. Verify that resilience processes are executed, tested, and improved in the live environment. | ||
Practitioner Guidance
What to prioritise: Build the evidence chain from critical service to dependency to test result to remediation. If any of those links is missing, the resilience story is still theoretical.
What to verify: Check whether each important control has a current, service-specific artefact that proves it is working in practice, not just approved in principle. The most useful evidence is usually operational and repeatable, not polished and static.
Common mistake: Treating annual review packs as sufficient proof. Teams often underestimate how quickly supplier, asset, and recovery assumptions drift away from reality between formal reviews.
Practitioner takeaway: If the organisation cannot show that it knows what it depends on, how those dependencies are tested, and what changed after the last test, it is doing compliance theatre rather than resilience management.
Related resources from NHI Mgmt Group
- What breaks when organisations treat cyber resilience rules as a one-time compliance exercise?
- What breaks when organisations treat NIS2 as a policy exercise rather than an operational security programme?
- What breaks when organisations treat audit logs as compliance evidence only?
- What breaks when organisations treat FedRAMP as a one-time compliance exercise?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
