Here's a peek behind the scenes of IT budget roulette

Supplier risk is no longer just a theory; it is now on the agenda of day-to-day management. A recent government study shows what happens when a handful of parties form the backbone of ICT: if one of them fails—technically, financially, or contractually—entire software systems can grind to a halt. Many people are then unable to work. Parts of processes fail. Incidentally, this is not a problem that only affects the government. It is a concentration risk that lurks in almost every (medium-sized) organization.

The question I regularly ask when I do an intake with a new client, for example, is: How many “single points of failure” have you outsourced?

Because this is what can happen, just to give you a taste of the problems people share. An identity provider that malfunctions. A cloud region that crashes. A software supplier that pulls the plug on updates due to a sale. A data breach or simply a strategic change of course. I could go on and on. Hours or days of downtime are no longer an exception. And as if it has become the most normal thing in the world... every minute directly affects turnover, reputation, and compliance. That can and must change.

The pain often runs deeper than uptime. Contract terms that force you to use a single stack. Closed data formats that make an exit practically impossible. Licensing models that “grow” like wildfire while performance lags behind. Security patches that only arrive after the news has already leaked. You only notice it when you have no more buttons to press.

Suppliers' best practices won't solve this for you. Because... they mainly protect their business model. Your job as a C-level or IT manager is different: making dependencies visible, reducing concentration risk, and shortening recovery time.

That starts with three questions:

Which critical processes are hosted by a single party or in a single cloud region?
How long can you afford to be ‘down’? And can you recover within that time?
Who holds the key to your data, both technically and legally?

The answers you just gave may make you frown. If you are concerned—even slightly—about serious supplier risk, here is a first step to put on the agenda as soon as possible: supplier risk diversification.

In short: be radically pragmatic: design for exit (both technically and contractually), avoid monocultures, ensure data portability, and test your failover as if something were to go wrong tomorrow. Resilience is not a tool. It is a management choice. And you cannot outsource that choice.

Vendor lock-in is not a bug — it's their business

Vendor lock-in is not a side effect; it is the revenue model. This is nothing new, but it is persistent. It starts innocently enough: free credits, bundle discounts, “seamless” integrations. Before you know it, identity, data, collaboration, and billing are all connected to the same lifeline. Convenient, until you realize that every button you press costs money or is no longer yours. Or both.

Lock-in works in three ways:

1) Identity as restrictive handcuffs. If you link everything to a single identity provider, that party gets the master key. IAM policies, conditional access, device trust: wonderful, but your exit path shrinks. Even on-prem resources are controlled via that same key; turning it off means swimming in cold water.

2) Data as an expensive toll road. “My Documents” has long since ceased to be local. Encryption, version management, DLP—all useful—but in a closed ecosystem. Getting out means migrations, data transformations, and new licenses. Often so painful that you keep paying to stay put.

3) Contracts as invisible traps. Bundles, minimum spends, egress costs, API rate limits, mandatory upgrades: every little clause pushes you one step further into the trap. “Best practices” and “reference architectures” make it cozy... and homogeneous.

What to do? How can you protect yourself and regain control over those suppliers?

Always design for exit. Document a technical and legal exit plan: data export (open formats), identity separation, DNS/PKI takeover, and a script for a 48-hour cutover.
Decouple identity. Use a neutral broker or keep a second IdP on standby. Ensure that critical apps can authenticate outside the primary domain.
Avoid monocultures. Standard protocols (SAML/OIDC, SMTP/IMAP, SQL/Parquet) over proprietary glue. Choose tooling that runs outside the ecosystem.
Factor in lock-in. Calculate TCO with egress, migration, training, and compliance costs. Cheap entry means expensive exit.
Test your freedom. Perform a mini-exit every quarter: export datasets, run an app in an alternative stack, simulate IdP failure.

Freedom is not an opinion; it is a capability. If you cannot test it today, you will not possess it tomorrow.

Fourth-party risk: the blind spot in your SLA

Supplier risk does not stop with your contractual partner. It creeps through the entire chain. Large platforms appear robust—until an error in DNS, identity, or networking affects thousands of customers at once. Smaller specialists appear agile—until it turns out that their back-end runs on exactly the same platform. Then you're stuck with twice the trouble: yours directly and your supplier's on top of that.

This is fourth-party risk and concentration risk in one. Your subscription to Canva? Indirectly, you also bought (parts of) AWS. Your deal with that niche SaaS? You implicitly signed up for their cloud, their CDN, their email provider, their IdP. Each component is a domino that could potentially fall.

What you can do now:

Make the chain visible. Request, or rather demand, a dependency map of critical services: hosting, storage, CDN, IdP, email, logging, payments. No insight = no agreement.
Request chain SLAs. Not only uptime from your supplier, but also agreements about their crucial suppliers (with flow-down obligations).
Eliminate single points. Encourage multi-region/multi-provider designs or choose alternatives that already offer this as standard.
Test chain failover. Practice IdP outages, DNS switches, egress blockages. Measure RTO/RPO in practice, not in a brochure.
Ensure data portability. Open formats, documented exports, break-glass access keys. Set up today = available tomorrow.
Factor in risk. Include chain failure and migration friction in your TCO. Cheap SaaS without chain clarity is expensive.

You're not buying a product; you're buying an ecosystem. If you don't know the chain, you're buying risk with your eyes open.

Less dependence. More options. Your choice.

If one supplier stops working, you want to be able to continue working. Without delays or panic. Without political fuss. Without first having to ask permission from the party that is locking you in.

Do you want to be less dependent on a handful of suppliers? Let's talk.

We're not into sales pitches. No tool pushing. No PowerPoint circus. Just a down-to-earth conversation about control: how to limit lock-in, keep your options open, and prevent hidden risks. You decide what you want to discuss: identity, data, contracts, cloud, chain, or something else entirely. We listen. We think along with you. We solve problems. Period.

Why now?

Lock-in never gets smaller if you wait.
Chain risks don't become visible through hope.
Exit opportunities don't arise by themselves.

You don't have to promise anything. No process. No budget. Just an open conversation to assess where you stand and what room for maneuver you want to create. Does it suit you? Great. Doesn't suit you? That's fine too.

Do you want to become less dependent on a few suppliers and regain more strategic room for maneuver?
👉 Schedule a no-obligation appointment.

Control is not something you get. It's something you take. Start today.

Book your appointment now

Click Me