Identify and Manage Provider Dependency

Where dependencies arise

Vendor lock-in is a dependency on a provider that makes switching difficult. Its causes extend beyond proprietary data formats and interfaces.

Which dependencies matter most?

A dependency deserves particular attention when it restricts an important decision or your organisation’s operations. For example:

• A critical service cannot be replaced within an acceptable timeframe.
• Data can be exported, but necessary configurations and permissions cannot.
• The contract allows switching, but no suitable technical alternative exists.
• An acquisition or price change alters essential conditions.
• The provider promises comprehensive control of your data but cannot substantiate important claims.

Always assess dependency for a specific service and use case. Benefits, costs and risks can vary considerably depending on how it is used.

Eight Questions for an Initial Overview

1. Which companies and other providers are necessary to deliver the service?
2. Which data, metadata, configurations and logs would we need when switching?
3. Which proprietary services or interfaces would we need to replace?
4. What knowledge and partners would we need for an alternative?
5. Which contractual rights support switching, and which are missing?
6. Is there a realistic target environment?
7. What duration, costs and operational interruptions should we expect?
8. Have we already tested an export, recovery or migration?

Unanswered questions are a useful result. They show where further information and evidence need to be requested.

Check claims against evidence

The statement “Your data stays in Europe” can mean many things. Check whether the commitment also covers backups, support access, the technical control plane and control of encryption keys.

Suitable evidence includes contractual location commitments, architecture and data flow diagrams, subcontractor information and your own technical checks.

The guide distinguishes four evidence statuses: verified, partially verified, unknown and not applicable. Missing information remains an open issue rather than automatically being treated as a requirement met or unmet.

Prepare a realistic exit plan

An export alone is rarely enough. Review data and metadata, configurations, interfaces, identities and permissions together. Also establish the target platform, required skills, support from the current provider, costs and timeframe.

A documented test shows whether the planned transfer and recovery actually work. Without such a test, the ability to switch remains an assumption.

Make the right decision

You can deliberately accept a known dependency, reduce it structurally or limit its consequences. Other options include additional providers, better contractual terms, migrating applications or bringing an activity in-house.

What matters is which option fits your needs and realistic alternatives. Document the rationale, outstanding questions, next steps and responsibilities.

Understand the legal requirements

For financial entities within its scope, DORA addresses risks associated with ICT service providers and exit strategies, among other matters. NIS2 and the German BSIG include suppliers and service providers in security requirements. The Data Act sets out rules for switching between data processing services.

These frameworks have different scopes. They do not apply universally to every organisation. Together, they illustrate why critical dependencies need to be understood early and assessed using appropriate evidence.

Turn the overview into a practical plan

The guide “A Practical Guide to Assessing Digital Sovereignty” combines 25 questions with an evidence checklist and a decision documentation template.

With Autonomy Track, you record your assessment, link evidence and track actions and responsibilities. Over 190 action templates help you make relevant improvements promptly.