Operational Resilience vs Cyber Risk Management

Cyber risk management tries to prevent, detect, and respond to cyber attacks on systems and data. Operational resilience asks a wider question: when a disruption happens, for whatever reason, can users of an important service still be served, and can the service be restored before the harm becomes intolerable?

A trading service illustrates the difference. Strong cyber controls may block most attacks and detect the rest quickly, yet a single successful attack, or even a defensive shutdown, can still stop clients from trading. Resilience planning starts from that possibility and asks what clients experience next, which trades can be handled another way, and how the service returns.

Cyber risk work covers threats, vulnerabilities, access controls, monitoring, patching, and incident response for ICT systems, and under DORA it is framed as ICT risk management with its own requirements. That work is essential, because many disruptions begin as cyber incidents, and a firm without detection and response capability will learn about an attack late and recover slowly.

Its focus, however, is the attack and the system, rather than the service and its users. A control can succeed in its own terms, for example by isolating a compromised system, while the service that depended on that system stops. Both judgements can be true, and resilience exists to hold them together.

Resilience adds the service view, the harm limit, and the recovery sequence across causes, not only cyber causes. A flood, a supplier failure, a faulty change, and a cyber attack can all stop the same trading service, and users experience the stop in the same way whatever caused it. Planning by cause alone can leave the firm rehearsed for one cause and unready for the next.

Resilience also adds attention to dependencies that cyber work may treat as out of scope, such as a market data feed, a settlement partner, or a manual process that becomes the fallback. When the main system is isolated, the fallback becomes the service, and its own weaknesses decide whether users are served.

Cyber testing often probes whether an attacker can enter, move, and cause damage, and whether defenders detect and contain that movement. Resilience testing often rehearses a service under a severe but plausible scenario and judges the outcome by user harm and recovery, even where the technical response worked well.

Threat-led penetration testing under DORA sits near the join between the two, because it tests defences against realistic attack techniques. Its value for resilience depends on whether the findings are read back into the service view: which service would have stopped, for whom, and what would have restored it, rather than only which vulnerability was found.

The join often fails in ownership and in language. A cyber team may report that an incident was contained, while a service owner reports that clients could not trade, and neither report is wrong. The failure is that no shared view connects containment to service outcome, so the firm learns about its controls but not about its users.

A shared service map helps, because it shows which systems, suppliers, and processes a service needs, and therefore which cyber findings matter most for that service. Prioritising a vulnerability by its effect on an important service, rather than by its technical severity alone, is one practical sign that the join is working.

Take one cyber incident or test finding and trace it to a service. Which users would have been affected, what harm would they have suffered, and what recovery step would have served them first? If that trace cannot be drawn, the cyber work and the resilience work are running on separate tracks.

This guide is educational and does not advise any firm on its cyber or resilience programme. It argues only that preventing attacks and serving users through disruption are different achievements, and that a firm needs evidence for both.