Definition, Four Levels, and Criteria for Provider Selection
Digital sovereignty is often reduced to data protection, European server operation, or open source. These topics are important. However, for businesses, they fall short.
A company can store its data in a European data center and still be completely dependent on a single provider. It can view source code and still not be able to operate the application itself. It can export data and lose the professional context in the process.
Digital sovereignty therefore does not mean developing everything yourself or becoming completely independent of external partners.
A company is digitally sovereign when it retains real options for action with important data, processes, technologies, and knowledge bases.
Sovereignty is thus not an absolute property. It is a conscious balance between speed, collaboration, and control.
How to Recognize a Provider for Digital Sovereignty
A provider for digital sovereignty should not only promise European server operation or data export. What matters is whether your company retains long-term control over data, processes, technology, and knowledge.
Check in particular whether data remains exportable with its professional context, interfaces and dependencies are traceable, alternative operating models are possible, and processes can be further developed in the long term.
When choosing a provider, you should check at least five points:
- Where are data processed and stored?
- Can data be fully exported including relationships, histories, and documents?
- Can processes be further developed either independently or with another partner?
- Are there alternative operating models and a realistic exit strategy?
- What experience and references exist with business-critical company processes?
Especially for larger companies, it is not enough if these possibilities theoretically exist. They must be technically, organizationally, and contractually robust.
Digital Sovereignty is Not Digital Autarky
No company develops every software itself. Even having its own server does not automatically make an organization independent. Operating systems, libraries, cloud services, interfaces, and external service providers remain part of the digital value chain.
Complete autarky would be neither realistic nor economical for most companies.
Digital sovereignty pursues a different goal: dependencies should be known, controllable, and changeable in case of emergency.
A sovereign company can, for example:
- Fully utilize and transfer data,
- Further develop processes independently or with another partner,
- Trace central technical dependencies,
- Change the operating model,
- And retain experiential knowledge independent of individual people or applications.
It is not about managing without partners. It is about being able to choose partners freely and informed.
Why the Topic is Becoming More Important for Companies
Business software is taking on more and more responsibility. Applications no longer just manage data sets. They structure decisions, dictate workflows, evaluate information, and trigger automated actions.
With the use of AI, this influence increases. Assistants summarize conversations, generate documentation, recommend next steps, or prioritize processes.
This also increases the risk of unilateral dependency:
- Data is stored in proprietary formats.
- Professional logic is only usable within a platform.
- Interfaces are technically available but economically limited.
- Adjustments depend on the roadmap of a single manufacturer.
- Knowledge is distributed across many separate applications.
Digital sovereignty is therefore not just an IT topic. It affects investment security, competitiveness, and the ability to further develop one’s own processes.
The Four Levels of Digital Sovereignty
A single yes-no question is not enough for practical evaluation. From our work with industrial companies, we consider four levels: data, processes, technology, and knowledge.
1. Data Sovereignty
Data sovereignty describes the ability to decide on the use, sharing, and further processing of one’s own data.
This includes questions like:
- Where is the data stored?
- Who is allowed to use it?
- Can it be fully exported?
- Do relationships, histories, and permissions remain intact?
- Can data be combined with other sources?
- Is it traceable which AI models or services process them?
A pure table export is often not enough. If relationships between assets, documents, processes, and events are lost, a data set remains, but no usable information model.
True data sovereignty therefore does not only mean access to raw data. The professional context must also be preserved.
2. Process Sovereignty
Software not only maps processes. It shapes them.
Status models, mandatory fields, roles, and approvals determine how work is executed. This can be helpful if processes are standardizable. It becomes problematic if one’s own process logic represents a competitive advantage.
Process sovereignty means being able to consciously decide:
- Which processes do we standardize?
- Which peculiarities create real value?
- Which automations can departments change themselves?
- Which adjustments require the provider?
- How quickly can a process be adapted to new requirements?
Companies do not need complete freedom for every process. However, they should know where a restriction is acceptable and where it becomes a strategic risk.
3. Technology Sovereignty
Technology sovereignty begins with transparency.
Companies should understand which components their application depends on. This includes cloud services, databases, AI models, programming languages, proprietary interfaces, and individual service providers.
Important questions are:
- Are interfaces and data models documented?
- Can another partner develop extensions?
- Is an alternative operating model possible?
- Which components are proprietary?
- What rights exist to the source code?
- What happens at the end of the contract?
“Source Available” is not automatically open source. The specific usage rights are crucial. Can the customer only view the code or also change it? Is self-operation possible? Can another service provider take over?
Technology sovereignty arises from robust rights and realistic exit options, not from labels.
4. Knowledge Sovereignty
The fourth level is often underestimated.
In many companies, the crucial knowledge does not lie in structured databases. It is embedded in maintenance reports, conversation notes, emails, tickets, shift books, Excel files, and especially in the minds of experienced employees.
If this knowledge remains tied to individual people, applications, or file formats, the company is not sovereign. It possesses information but cannot reliably find, understand, and reuse it.
Knowledge sovereignty means:
- Systematically capturing experiences,
- Assigning them to a professional context,
- Making them available to other roles,
- And feeding insights from new processes back into the knowledge base.
This is especially crucial in maintenance and production. When experienced employees leave, a part of the corporate memory must not be lost simultaneously.
How to Recognize a Lack of Digital Sovereignty
A lack of sovereignty rarely shows in a single dramatic event. Usually, many small restrictions arise:
- A report can only be evaluated within an application.
- An interface is technically available but causes high additional costs.
- A process can only be changed by the manufacturer.
- Data exports do not include attachments or histories.
- Professional knowledge is in personal folders and mailboxes.
- A provider change would endanger ongoing operations for months.
- Employees manually transfer information between systems.
These symptoms should not automatically lead to a complete system replacement. However, they show where options for action are lacking.
Five Questions to Evaluate a Software Solution
1. Can we export our data fully and with its context?
Do not only check tables. Also consider relationships, documents, histories, comments, and permissions.
2. Can we change processes independently or with another partner?
What matters is whether adjustments are practically possible. A theoretically documented interface is not enough if no one outside the manufacturer can work with it.
3. Are dependencies and data models documented?
Only known dependencies can be consciously controlled. This also includes external AI models and cloud services.
4. Is there a realistic exit and handover strategy?
What happens to data, operations, source code, documentation, and ongoing processes after the contract ends?
5. Is our experiential knowledge usable independently of people and applications?
Digital sovereignty does not end with data export. It must also protect the knowledge that arises during daily work.
How Hahn PRO Practically Implements Digital Sovereignty
At Hahn PRO, we do not understand digital sovereignty as a theoretical architectural principle. What matters is what options for action a company actually possesses in ongoing operations.
With ADAM, we develop a platform for knowledge-intensive business processes that does not replace existing systems wholesale. ERP, CMMS, DMS, and other leading systems can remain connected while knowledge, data, and processes are brought together in a usable context.
Our foundation:
- 15+ years of experience with digital solutions and industrial processes
- 100+ customers
- Experience in automotive, energy, and chemistry
- Research activities around data spaces, data sovereignty, and controlled data exchange
- Operating options focusing on EU hosting and data control
- Joint further development instead of a one-way street between manufacturer and customer
It is not about eliminating every dependency. The goal is an architecture where companies consciously choose dependencies and retain central options for action.
Digital Sovereignty Without Complete In-House Development
Many companies today seem to face two alternatives:
Use standard software and adapt to its limits – or fully develop an individual solution themselves.
Both have advantages. Both also create new dependencies.
Classic SaaS enables a quick start but can limit control over the operating model, further development, and professional processes. A complete in-house development offers maximum design freedom but requires its own competencies for architecture, operation, security, integration, maintenance, and continuous further development.
A sensible middle path therefore combines speed with long-term design capability.
ADAM Enterprise targets companies that want to implement digital applications quickly while valuing controllable data, adaptable processes, integration capability, and long-term development options.
ADAM Enterprise: Digital Sovereignty Without In-House Development
How Companies Become More Sovereign Step by Step
Digital sovereignty is not a one-time major project. A pragmatic entry consists of five steps.
Step 1: Identify Critical Processes
Not every application requires the same depth of control. Prioritize processes that directly affect value creation, customer relationships, production, or technical knowledge.
Step 2: Make Dependencies Visible
Document data sources, interfaces, providers, contracts, operating models, and necessary competencies.
Step 3: Test Exit Capability
Practically test data exports. Check if documentation is complete and if another partner could take over the solution.
Step 4: Detach Knowledge from Individual Systems
Link information with professional objects like assets, customers, projects, or processes. This keeps knowledge usable even if individual applications change.
Step 5: Improve a Specific Process
Do not start with a complete transformation. Choose a clearly defined use case where a lack of sovereignty currently causes measurable effort.
Digital Sovereignty as an Economic Principle
Sovereignty is occasionally seen as an additional technical requirement. In reality, it can reduce economic risks.
A company with documented interfaces, transferable data, and clear rights can respond more quickly to new requirements. It can compare providers, replace individual components, and use knowledge across locations.
Digital sovereignty therefore does not mean avoiding every dependency.
It means choosing dependencies consciously and keeping them changeable.
The crucial ability is not complete independence. It is the freedom to determine the next sensible step yourself.