From compliance to digital resilience
DORA, NIS2 and sector-specific frameworks have raised the regulatory bar significantly. Most institutions are responding with compliance programs that satisfy reporting requirements. Few are using the regulatory pressure as a catalyst to redesign the underlying resilience operating model — which is what the regulations are actually trying to produce.
Diagnostic
Is your DORA program producing resilience — or just reports?
- ICT risk, security, business continuity and third-party risk are tracked in separate registers with separate KPIs and separate owners.
- Recovery time and recovery point objectives are documented but have not been validated in tested scenarios in the last 12 months.
- Critical third-party incidents would be detected by the bank only after the third party reports them — not through integrated monitoring.
- Board reporting is incident counts and audit findings, not forward-looking resilience indicators that enable decisions.
- The program owner is a compliance executive accountable for filings — not a resilience executive accountable for operational outcomes.
Context
Digital resilience has become a board-level topic. Regulators expect not only control inventories and incident reports, but evidence of continuous, integrated, tested resilience across ICT risk, third-party exposure, business continuity and operational recovery. Documentation is not sufficient. Resilience must be demonstrated through testing and operational evidence.
Why compliance programs do not produce resilience
Compliance programs map regulatory requirements to existing controls, identify gaps and close them with documentation, processes and additional reporting. The output is a more compliant institution. It is not necessarily a more resilient one. The fragmentation between IT, security, risk and business continuity remains — it is now better documented rather than better integrated.
Resilience is operational when the disciplines share forums, scenarios and escalation paths — not when they share a compliance report.
From control inventory to tested efficacy
Controls assessed for effectiveness — not only for existence in a register. Many controls survive audit cycles without being tested under realistic conditions. Recovery time and recovery point objectives must be validated in actual exercises, not assumed from design documentation.
Critical vendors as part of the perimeter
Critical third parties are an extension of the institution's risk surface. DORA-style frameworks require integrated monitoring, contractual resilience requirements, incident-handling protocols and exit planning proportionate to the criticality of the relationship.
Tested end-to-end — not just documented
Recovery plans tested across the full stack: technology recovery, people, processes, third parties and communications — on scenarios that reflect actual threat patterns. A plan that has never been exercised end-to-end is a hypothesis, not a plan.
Forward-looking resilience indicators
Boards moved from retrospective incident counts to forward-looking resilience metrics: tested recovery times, third-party exposure levels, control efficacy trends, scenario coverage. The reporting must enable decisions — not only provide assurance after the fact.
"The regulatory window is finite. Use it to redesign the operating model — not to produce more reports."
— RSV Consult perspective
How to use the regulatory window
DORA-style frameworks create executive attention and budget for resilience. The window is finite. Institutions that use it to redesign the operating model emerge with both compliance and capability. Institutions that use it only for reporting emerge with compliance and the same structural fragility — and less budget to address it next cycle.
The first 90 days
Integrate the disciplines
Build a single incident command structure spanning IT, security, risk, business continuity and communications. One escalation path. One scoring model. One register replacing the four parallel ones — visible to the same forum and the same executive.
Test what is documented
Schedule end-to-end recovery exercises against realistic threat scenarios — third-party failures, ransomware, regional outages. Capture actual recovery times. Treat any gap between documented RTO/RPO and tested reality as a finding, not a footnote.
Reframe board reporting
Replace retrospective incident dashboards with forward-looking resilience indicators: tested recovery times, third-party exposure, control efficacy trends, scenario coverage. The board should be able to make resourcing decisions from the report, not only receive assurance.
What changes when this works
Time-to-decision during incidents collapses because the disciplines share a forum, a scoring model and an escalation path. Critical third-party exposures become visible before the third party reports them — not after. The board moves from receiving incident counts after the event to making forward-looking decisions on coverage, capacity and investment. The institution emerges from the regulatory cycle with both compliance and capability — and uses the next cycle for further capability, not remediation.
Resilience is not a reporting exercise. It is an operating model. Compliance documents what you have. Operational resilience demonstrates that it works under pressure.