Digital sovereignty is emerging as a procurement question, not just a political slogan. Where do leaders draw the line?

The Digital Sovereignty double-edged sword

The distinction matters. “Digital sovereignty” can describe a legitimate enterprise need, but it can also become a persuasive label that makes ordinary governance problems sound like a new strategic doctrine.

That is why security buyers are increasingly being told to think not only about how well a product works, but also about who governs it, how it is maintained, and what dependencies come with it.

Heng Lee, Director, Government Affairs and Public Policy (Asia-Pacific and Japan), Kaspersky, speaking for his firm, argues that this broader lens is overdue — a framing that carries particular weight given Kaspersky’s own history with jurisdiction-based restrictions in several markets.

In his professional view, cybersecurity platforms are no longer mere software products; they are privileged systems that process sensitive security data, distribute updates, and increasingly influence automated decisions. That means organisations should care not only about detection performance, but also about transparency, control, and resilience throughout the product lifecycle.

Lee’s argument has some traction because it starts from a real operational truth, even if it is also a case he has an interest in making.

• Modern security stacks are deeply entangled with cloud services, identity systems, threat-intelligence feeds, update pipelines, and licensing models. If any of those dependencies fail, a security team can lose visibility or response capability at the worst possible moment.
• In that sense, Lee has a point when he says that resilience is not just about whether a platform is installed, but whether it can keep working under stress. He is also correct, as far as it goes, that “ownership” is not the same as assurance. An organisation can host a platform on its own infrastructure and still have limited visibility into how the software is developed, updated, or verified. That is a useful warning, particularly at a time when software supply-chain attacks have made buyers more conscious of how trust is established in the first place.

However, Lee’s framing also illustrates the limits of vendor-led sovereignty language. The buyer’s real challenge is not whether a vendor can describe itself as sovereign-friendly. It is whether the vendor can prove, in practical and independently verifiable terms, that its controls are meaningful. Transparency, after all, is not just a promise to open the curtain. It is the question of who holds the flashlight, how much of the machinery is visible, and whether outsiders can verify what they are being shown.

That is why some security leaders remain skeptical of the term itself. To them, digital sovereignty is less a strategic category than a bundle of procurement concerns: data residency, access control, jurisdictional exposure, update integrity, incident response continuity, and the ability to switch providers without unacceptable disruption. Those are real issues, but they do not necessarily require a new doctrine. They require disciplined vendor due diligence.

For example, Tito Castillo, Enterprise Architect & Data Management Consultant at Agile Health Informatics Ltd — whose background is in health-sector data architecture rather than cybersecurity specifically — has opined publicly that “digital sovereignty is not a procurement decision” and should instead be treated as a structural capability an organisation either has or does not. He argues that the important questions are whether the organisation can explain how a model or service works, audit the outputs, govern the data, and replace the capability without unacceptable disruption. That is a credible foil to Heng Lee because it disputes the premise that sovereignty can be bought by contract alone.

The matter of critical infrastructure

A second viewpoint comes from buyers in critical infrastructure, finance, telecoms, and government, where sovereignty language often resonates most strongly.

These organisations are under pressure to ensure that the tools protecting them are not subject to hidden legal, political, or operational dependencies. In that context, the appeal of hybrid or on-premises security architectures is obvious. The logic is straightforward: if a platform handles sensitive telemetry or is deeply embedded in response workflows, then buyers want stronger assurances about where data goes, how updates are governed, and what happens if the external environment becomes unstable.

Yet even here, the concept can overreach. A platform that runs locally is not automatically more trustworthy than a cloud-delivered one, and a locally hosted system can still be opaque about its own build process, patch chain, or internal dependencies. Likewise, complete technological independence is rarely realistic.

Security teams still rely on external research, global threat intelligence, and specialized expertise that most organizations cannot replicate internally. The practical goal is not isolation, but controllable dependence.

Taking a risk-management perspective

A third framing, and arguably the most useful one discussed by seasoned observers, treats sovereignty as a risk-management question rather than an identity statement. On this view, the right answer is not to swear allegiance to one vendor class or deployment model, but to map the actual risks:

• where data resides
• who can access it
• how software is signed and verified
• what the exit plan looks like
• whether the organization can maintain operations if a vendor becomes unavailable.

That approach is less dramatic than sovereignty rhetoric, but often more useful. This is where the term begins to show its double meaning:

• For buyers, sovereignty can be a serious way to ask whether critical security capabilities remain under meaningful control.
• For vendors, it can become a branding device that shifts the discussion away from trust deficits and toward abstract principles. The same phrase can therefore function as both a legitimate concern and a marketing shield.

That tension is what makes the current wave of sovereignty talk worth watching. The question is not whether cybersecurity buyers should care about jurisdiction, transparency, or continuity. They should. The question is whether the industry is using sovereignty language to clarify those issues, or to make them sound more strategic than they really are.

The acid test in procurement decisioning

For organisations making procurement decisions, the safest approach is to treat sovereignty claims as testable claims

1. What exactly is being controlled?
2. What can be independently verified?
3. What dependencies remain?
4. And what happens if the vendor’s legal, political, or operational environment changes?

These are the questions that matter, regardless of what label the vendor uses.

And that may be the most important point of all. “Digital sovereignty” is not meaningless, but neither is it self-validating.

In cybersecurity, as in procurement more broadly, the burden is still on vendors to prove that their language maps to reality. As Lee put it in his submission to CybersecAsia.net: “Infrastructure ownership does not equate to technology assurance.”