Technological sovereignty is often debated in terms of jurisdiction, compliance, or vendor origin. All of that is important, but it leaves out the important issue of retaining critical knowledge, which directly impacts the CIO.
Case in point, British bank TSB undertook a critical platform migration in 2018. The operation relied on a structure that, on paper, had guarantees of a validated provider, testing, and formal program governance.
Once the migration was complete, the new platform began experiencing technical difficulties, resulting in a significant disruption to branch, telephone, online, and mobile banking services, affecting a large portion of its 5.2 million customers. The extent of the matter was so complex, key problems weren’t resolved until the end of the year.
The crisis also had a significant economic impact. Banco Sabadell, which acquired TSB in 2015, had to absorb losses exceeding €200 million, and four years later, in December 2022, British regulators imposed a combined fine of nearly £49 million on the bank for failures in operational risk management, governance, and outsourcing supervision related to the migration. Then, in April 2023, the Prudential Regulation Authority, the Bank of England’s prudential supervisor, personally fined the then CIO £81,620 for failing to take reasonable steps to ensure adequate supervision.
The lesson from this case isn’t that a large migration can go wrong. Every CIO knows that can happen. But TSB didn’t have the capacity to govern and question critical vendor dependency.
The constant of knowledge
When we talk about technological dependence, we usually think of market concentration, long-term contracts, proprietary formats, migration difficulties, or negotiating power with the vendor. All of that exists and will continue to be important. But knowledge dependence is another form that comes up in the conversation and has a greater impact on the CIO’s day-to-day work.
This occurs when the organization doesn’t retain enough internal knowledge to discuss the technology, or subject it to serious scrutiny.
The TSB case was a clear example. The oversight of a critical department relied too heavily on unquestioned supplier guarantees. In other words, there was insufficient internal capacity to rigorously govern the outsourcing relationship.
With this example, the meaning of lock-in changes. It no longer manifests itself when migration becomes prohibitive or when an architecture becomes unchangeable. It begins earlier, when the company is operating its technology but can no longer reliably evaluate it.
In fact, this dependency isn’t easy to perceive because it coexists with a sense of reasonable operation. The services are available and the providers respond, and yet risks are being taken.
On the other hand, it forces a broader definition of sovereignty. The issue goes beyond where the data resides, under what jurisdiction a provider operates, and what degree of regulatory exposure a platform introduces.
Another question is how much critical knowledge does the company retain about what underpins its operations. From this perspective, maintaining sovereignty doesn’t equate to reviewing ownership of the technology or internalizing its implementation, thus preventing reducing the conversation to a legal or geopolitical debate.
Hidden knowledge dependencies
The common mistake when discussing tech dependence is to focus solely on the noisiest areas like cloud computing, AI, large platforms, and data storage. When discussing knowledge dependence, it’s essential, but not always easy, to look inward.
One area to consider is the architecture. Even if systems are functioning, it may become increasingly difficult to answer basic questions, like why the environment is designed this way, which parts are replaceable, or what changing a critical layer would entail. If this is the case, it’s a sign of dependency.
Another aspect is the operation. Outsourcing execution can make perfect sense, but problems arise when understanding is also outsourced. That is, when the internal team needs to go externally to make decisions or solve problems.
Dependency can also be hidden within the complexity of technological layers. In other words, it doesn’t necessarily have to be directly linked to a large platform, but to the set of integrations and connectors surrounding it, or a partner ecosystem that’s become a tangled mess. If no one understands the complete picture, dependency exists.
The knowledge CIOs can’t afford to lose
All of this shifts the focus to the specific responsibility of knowledge. Not all capabilities carry the same weight or have the same strategic value. But there’s a decisive threshold, the moment when the organization no longer sufficiently understands a dependency to be able to manage it. From that point on, the risk extends beyond the operation itself. The quality of decisions deteriorates, the CIO’s ability to discuss risks or costs diminishes, and many aspects end up being accepted without clear rationale.
If it isn’t detected in time, there’s a risk of reaching a point of no return, where control of the technological roadmap is lost.
The debate for the CIO
The solution isn’t necessarily to distrust suppliers or outsourcing on principle. There’s a more subtle and demanding issue for the CIO of clearly deciding what knowledge can and can’t be shared externally. So the debate on sovereignty needs to become more pragmatic and more linked to the company’s actual capacity to understand what it depends on, and to change course when necessary.
In an environment of complex platforms, encapsulated services, and outsourced intelligence, preserving decision-making capacity will be an indisputable condition for technological autonomy.