In earlier discussions, we focused on recovery, restoring systems, data, and processing after disruption, and then moved into resilience, asking whether that recovery actually restores business operations in a meaningful way. That progression exposed something important. Systems can return, data can be present, and processing can resume, yet the business may still not be ready to operate.

That reality leads to a harder question. If systems can be restored, but the organization cannot fully control that recovery, has resilience really been achieved?

Recovery has traditionally been measured in technical terms. Systems come back online, data is restored, and workloads resume. On paper, that signals success. In practice, it rarely holds. Applications depend on sequencing, data consistency, and tightly coupled processes. Even when systems are available, they are not always usable. Dependencies do not align, workflows do not reconcile, and operational readiness remains out of reach.

What sits underneath this is not just a technical gap, but a control gap. Recovery may be technically possible, yet constrained by who controls the environment in which it occurs. The ability to recover does not guarantee the ability to operate.

The conversation shifts from restoration to responsibility. Organizations must treat data as a governed asset with clear ownership and accountability. That responsibility does not diminish during disruption. It becomes more critical when access, authority, and control determine whether recovery can proceed.

This is where sovereignty becomes operational. It is not simply about where data resides. It is about who controls access, who determines how recovery is executed, and under what conditions those decisions are made.

What is often described as cloud adoption is, in practice, a shift in control. Data, processing, and operational capability are placed into environments managed by third parties. While governance may remain internal, execution does not. This is an operating model change in which hosting and cloud providers introduce outsourcing dynamics that directly affect control.

Responsibility remains, but control is no longer singular. That distinction matters most when something goes wrong. Reliance on third party providers introduces concentration risk and operational vulnerability, and these risks become visible when recovery depends on access, timing, and execution outside the organization.

This is not theoretical. Switzerland has long established through regulatory expectations that outsourcing does not transfer accountability. Financial institutions remain responsible for their data, their recovery, and their ability to operate regardless of where services are executed. This position is formalized through guidance from the Swiss Financial Market Supervisory Authority, which requires control, auditability, and accountability to remain with the institution.

For many organizations, this level of control is not new. It has existed for decades within the mainframe environment. Mainframes continue to deliver unmatched resiliency, security, and transactional integrity compared with alternative platforms. These characteristics reflect an architecture designed for controlled execution and predictable outcomes.

The difference becomes clear when organizations attempt to move away from that model. Migration frequently introduces complexity, risk, and disruption. Other platforms may aim to replicate similar capabilities, but they do not provide them inherently and require deliberate design to approach comparable results.

This is not an argument against change. It is a reminder that control is not easily recreated once it is distributed.

Resilience has often been framed as the ability to recover. That definition is no longer sufficient. Recovery without control introduces uncertainty. Recovery constrained by external authority introduces risk. Sovereignty determines whether recovery can be carried out in a controlled, accountable, and operationally meaningful way.

Recovery is necessary, and resilience remains essential, but without control, neither is sufficient. Sovereignty ensures that control exists over data, execution, and the conditions under which recovery occurs. In the end, resilience is not defined by whether systems can be restored, but by whether they can be restored under control.

That control sets the stage for a more important question, one that extends beyond recovery and sovereignty.

References

Harvard Business Review, Why Companies Need a Data Strategy 
Gartner, Market Guide for Mainframe and Legacy System Cloud and Hosting Providers 
Gartner, The State of the IBM Mainframe 
Gartner, Too Big to Fail: Why Mainframe Exit Projects Are Likely to Fail 
Bank for International Settlements, Principles for Operational Resilience 
FINMA, Outsourcing – Banks and Insurers (Circular 2018/3) 
European Union, Digital Operational Resilience Act (DORA)