Vendor Lock-in: When You Are Not in Control of Your Own Data

One of the most uncomfortable questions I can put to a managing director is a simple one: if your software supplier doubles the price tomorrow, or pulls the plug, what do you do then? Usually it goes quiet. Not because the answer is hard, but because the honest answer is: then I am stuck. That is exactly what vendor lock-in is. And it is not a software problem, it is a control problem.

I look at these dependencies as someone who audits rather than sells. I have run audits across five industries and five countries, from aviation to precision engineering. The pattern is always the same: it is not the supplier who shouts the loudest warnings who becomes dangerous. The dangerous one is the supplier you can no longer break away from without bringing operations to a halt. Let us be blunt: whoever is not in control of their own data and their own update cycles has given away part of their independence without noticing.

Lock-in is not convenience, it is external control

Vendor lock-in does not mean that a tool is convenient and you are happy to stay with it. It means that switching is made so expensive, so risky or so technically awkward that in practice you can no longer leave. This dependency is rarely a single malicious contract. It grows in small steps that each look harmless:

• Your data sits in a format that only this supplier can read cleanly. A full export? It does not exist, or it costs extra.
• Updates arrive when the supplier chooses to deliver them, not when you need them. You wait on someone else's cycles.
• Interfaces to other systems are deliberately kept thin. Anyone who wants out has to rebuild a great deal by hand.
• The knowledge about your own processes sits with the supplier, not with you. Every question costs a day rate.
• The contract binds you for years, the exit is expensive and nowhere cleanly described.

Each individual point sounds harmless on its own. Taken together, they add up to a cage with a nice finish. And nobody built it maliciously; it simply grew that way, because no one asked the right questions before signing.

The conflict no one sees coming

Here is a real-world example that stayed with me. A company was not allowed to update an important system because a supplier freeze period was running. At the same time, the cyber insurance policy demanded, in the small print, up-to-date security levels. Two contracts, one contradiction, and the mid-sized firm sat right in the middle. Update, and it breaches one agreement. Do not update, and it risks losing cover in the event of a claim.

That is the invisible side of lock-in. As long as everything runs, you notice nothing. The conflict only surfaces when it matters: during a security incident, during an audit, during an outage. And by then it is too late to renegotiate the dependency. Hope is not a strategy.

Dependency costs nothing as long as everything runs. It sends the bill at precisely the moment you can least afford it.

Who really owns your data?

The ownership question around data is easily glossed over, because it sounds so self-evident. Of course my data belongs to me, and the contract often says so too. The decisive question is a different one: can you get to your data without the supplier, in a format you can carry on working with somewhere else? Ownership you can only exercise with someone else's permission is half ownership.

Three examples make this tangible. An AI that pre-sorts job applications gathers sensitive personal data and scoring logic over months. If that sits with the supplier and you cannot get to it cleanly, a switch is not only expensive, it is a data protection issue. A camera with a model that inspects your components in final quality control learns on your parts, your tolerances, your lighting. That trained model is your capital. Does it belong to you or to the supplier? And an AI that creates orders in your ERP hangs on your master data. If that sits in a closed supplier cloud, the heart of your ERP is no longer entirely in your hands.

Five levers that keep you in control

The good news: you can guard against lock-in without giving up good tools. It is not about building everything yourself. It is about nailing down the right points before you sign:

• Settle data export in writing: in which open, readable format can I extract my data at any time, at no extra cost? Put it in the contract, do not accept a promise.
• Describe the exit up front: what happens to data, models and configuration if I terminate? Who helps with the transition, and at what price? An exit that is only negotiated in the middle of a dispute is always expensive.
• Secure update authority: are security updates possible at any time, independent of marketing freeze periods? This point saves you in a conflict with your cyber insurer.
• Bring the knowledge in-house: at least one person on your side has to understand what the tool does, where the data sits and how to switch it off in an emergency. Otherwise you are only swapping one lock-in for another.
• Standard before special path: wherever possible, insist on open interfaces and widely used formats. The more ordinary the technology, the easier the switch.

No magic. But all of these points belong settled before you sign, not after. After signing you hold the weaker negotiating position, and the supplier knows it.

What an auditor sees in the dependency

A salesperson wants you to buy. An auditor wants you to remain able to act even when something goes wrong. That is why, for me, vendor lock-in is not a convenience topic but a resilience topic. In an information security management system to ISO/IEC 27001, dependency on suppliers is a control point in its own right: what happens to operations if a critical service provider fails, dictates the price or blocks access?

I ask this question in every sparring session too, and it is a literal relative of the supply chain in manufacturing. No one takes on a single supplier for a critical part without a contingency plan. No second source, no buffer stock, no fallback option? That would be negligent. With software and AI, many firms do exactly that, simply because the dependency sits invisibly in the data centre rather than visibly on the shop floor.

Data sovereignty is therefore nothing abstract. It is the digital variant of an old workshop rule: never rely blindly on a single machine, a single supplier, a single person on whom everything depends. Whoever keeps their data, their update authority and their knowledge in-house is not buying convenience. They are buying the freedom to decide for themselves when it counts. And that, in case of doubt, is worth more than any discount in the offer.