Resilience Is Becoming the Real Measure of Technology Risk

For a long time, technology risk was often framed in terms of prevention. Could the organisation block the threat, close the gap, or keep the control exception from appearing? Of course that lens still matters, but it is no longer enough.

Increasingly, organisations are being judged not just on whether they can avoid incidents, but on how well they can respond, recover, and continue operating under pressure. In other words, resilience is becoming the more meaningful test.

Regulators are reinforcing that shift. In the UK, the FCA defines operational resilience as the ability to prevent, adapt and respond to, recover and learn from operational disruption, and firms in scope were required by 31 March 2025 to remain within impact tolerances for important business services. Its more recent observations also show that the emphasis is not simply on having controls, but on demonstrating that services can be recovered within tolerances under severe but plausible disruption.

Why this shift is happening

There are at least three forces driving it.

First, technology environments are now structurally more complex. Cloud platforms, SaaS dependencies, third-party service providers, APIs, and tightly coupled data flows mean that failures are rarely isolated. A control weakness in one layer can surface as disruption somewhere else entirely. European resilience rules such as DORA reflect that reality by focusing not only on ICT risk management, but on incident handling, testing, recovery, and concentration risk in third-party providers.

Second, the pace of change keeps increasing. Cloud delivery already challenged traditional review cycles. AI is accelerating that further. Deloitte's recent technology risk perspective for boards explicitly frames cyber risk, AI, and broader technology governance as converging pressures that demand more integrated oversight, not separate conversations. NIST's current AI-cyber work points in the same direction: AI changes both the threat landscape and the systems organisations are trying to secure and govern.

Third, regulation is increasingly concerned with whether organisations can keep delivering important services, not merely whether they can show that a control framework exists on paper. That is a profound difference. It moves the conversation away from isolated control effectiveness and toward end-to-end operational performance under stress.

What changes when resilience becomes the measure

Once resilience becomes the real test, the question changes. It is no longer simply:

Do we have the right controls?

It becomes:

Will they hold when it matters?

That sounds subtle, but it is a significant shift in mindset. A control can exist, be documented, and even pass periodic testing, yet still fail to support resilience when systems are under load, suppliers are degraded, or teams are managing live disruption.

This is why resilience thinking places more weight on service mapping, dependency awareness, response coordination, and recovery capability. The FCA's approach to important business services and impact tolerances is useful here because it forces organisations to think from the outside in: what must continue, what can degrade, and how quickly must we recover?

Why control design matters more than control count

This is also where design becomes critical. Controls layered on after the fact often struggle to keep pace. They create paperwork, approvals, and reporting, but they may not integrate well with the way work is actually done. Under pressure, those controls are more likely to be bypassed, delayed, or become performative.

Controls designed into systems and processes from the outset tend to be more effective. They are closer to how the organisation really operates. They can generate better telemetry, support faster intervention, and evolve as delivery models evolve. This is one reason continuous controls monitoring and automated evidence are gaining traction: not because automation is fashionable, but because static controls are increasingly poor fits for dynamic environments.

In practical terms, the approaches that are most likely to hold up are usually the ones that:

• embed controls directly into workflows, platforms, or pipelines rather than relying only on manual review;
• monitor critical services, dependencies, and failure indicators continuously;
• link incident response and recovery capability back into control improvement rather than treating them as separate disciplines;
• treat third-party dependence as part of the control environment, not just a procurement matter;
• generate operational evidence that reflects live behaviour, not only point-in-time attestations.

These approaches work because they are closer to reality. They do not assume stability where none exists.

Resilience is not static

Another reason resilience is becoming the better measure is that it forces a more honest view of change. Threats evolve. Architectures evolve. Suppliers change. Business priorities shift. Controls that were entirely reasonable a year ago may no longer be enough.

DORA's structure is instructive here: it explicitly links ICT risk management, detection, response and recovery, testing, learning, and third-party oversight. That is not accidental. It reflects the reality that resilience is maintained through a cycle, not achieved once and filed away.

The same is true more broadly. A resilient control environment is one that can adapt without losing coherence. It supports response under pressure and learns from what actually happens.

From control frameworks to control environments

That is why I think the centre of gravity is shifting. Not away from frameworks entirely, but away from treating frameworks as the primary measure of confidence. The more meaningful question is whether the organisation has a control environment that works in practice.

Frameworks still matter as they provide structure and common language. But the real test increasingly sits in operation: how services behave under stress, whether teams can recover in time, whether dependencies are understood, and whether evidence reflects reality rather than aspiration.

Sources

• FCA ~ Operational resilience overview and impact tolerance expectations
• FCA ~ Operational resilience: insights and observations one year on
• FCA ~ PS21/3 Building operational resilience
• Deloitte UK ~ Hot topics for technology and digital internal audit
• Deloitte UK ~ The technology risk landscape
• NIST ~ Cybersecurity Framework
• NIST ~ AI Risk Management Framework
• European Commission ~ DORA overview
• EIOPA ~ DORA materials
• EBA ~ DORA framework