Mapping technology dependencies: an engineering method for digital sovereignty

Most organizations can produce a list of their technology vendors. Procurement has one, and finance has another. Far fewer can say what their systems cannot run without, what would break first if a provider changed its terms, and how long it would take to replace each piece. That second list is the one that matters for digital sovereignty, and it is an engineering artefact, not a procurement one.

Consider a fictional logistics software company. It runs a customer portal, an operations API used by partners, and internal tools, spread across a hyperscale cloud, around forty SaaS products, two AI APIs and a hosted identity provider. Its leadership wants to know which of those dependencies deserve attention and which are fine as they are.

This article proposes a method for that assessment. It is not a report of a client engagement. Regulatory references were checked on 29 September 2026 against the texts linked below; they describe context, not legal advice.

start from functions, not from vendors

A vendor list sorts dependencies by invoice. An assessment should sort them by what they support. Start with the functions the business cannot lose, then trace the technical path of each one.

For the example company, three functions would be enough to begin: customers track shipments in the portal, partners submit orders through the API, and staff dispatch vehicles from an internal tool. For each, follow a request from the user to the data and back, and write down every component it touches: DNS, CDN, load balancers, compute, databases, queues, identity, email, AI calls, monitoring, and the build pipeline that produced the code.

Financial regulation uses the same starting point. DORA organizes ICT third-party risk around services that support "critical or important functions", which is a useful way to scope an assessment even outside the financial sector.

record every dependency the same way

A map is only comparable if each entry answers the same questions. We would use a record like this:

Component and provider
Functions it supports
Data it holds or processes, and its sensitivity
Operator and jurisdiction
Interface: open standard, documented API, or proprietary
Export: what can be exported, in which format, tested when
Effect if unavailable: 1 hour, 1 week, permanently
Contract: notice period, exit assistance, data return
Replacement: known alternatives and estimated effort
Owner inside the organization

The "tested when" field is the one most often empty. A documented export that nobody has run is an assumption, not an exit option.

classify: controlled, portable or critical

With records in place, classify each dependency by the control it leaves you, not by how important the vendor is:

• Controlled. You operate it, or you hold everything needed to operate it elsewhere: data, configuration, keys and the knowledge to run it. Open-source components you build and deploy yourself usually belong here.
• Portable. A provider operates it, but it sits behind a standard interface or a thin layer you own, the data can be exported in a usable format, and a replacement is a project measured in days or weeks. Container workloads, SMTP-based email delivery and OpenID Connect login on your own domain are typical examples.
• Critical. Replacing it would take months, lose data or identifiers, require changes at your customers, or it holds something you cannot export, such as keys, a user directory or the only copy of operational data.

Most dependencies will be controlled or portable, and that is the expected result. The assessment exists to find the short list of critical ones and decide which are acceptable.

estimate exit difficulty by what has to move

"How hard is it to leave" becomes answerable when broken into what would actually have to move:

1. Data. Volume, format, and whether the export preserves relationships and history.
2. Identifiers. User IDs, object IDs and URLs that other systems or customers store. We cover the identity case in detail in leaving an identity provider.
3. Code coupled to a proprietary API. Count the call sites and the features that have no equivalent elsewhere.
4. Keys and secrets. Many managed key services are designed so key material cannot leave them. Data encrypted under such keys depends on that service for decryption.
5. Configuration outside your organization. DNS delegations, partner webhooks, SAML federations and allow-listed IP ranges at customers.
6. Operational knowledge. Runbooks, alerts and the people who know how the component fails.

Score each dimension, but keep the evidence next to the score. A reviewer should be able to see why a dependency was rated critical, not only that it was.

look for the dependencies nobody listed

The components that surprise teams during an assessment are rarely the large cloud contract. They tend to be infrastructure everyone assumes is neutral:

• DNS and domain registration, including who can change the delegation.
• Certificate issuance and renewal automation.
• Transactional email, and the sending reputation tied to the provider.
• CI/CD runners, package registries and container base images.
• Error tracking and logging services that quietly receive personal data.
• SDKs embedded in mobile apps, which cannot be replaced without a release.
• AI APIs called from several services with provider-specific prompts, tools and response formats.

Each of these can be portable. The assessment checks whether it actually is.

make the software supply chain visible

Application dependencies are part of the map. A software bill of materials records them in a machine-readable form, and the Cyber Resilience Act defines it as "a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements."

For products in its scope, Annex I requires manufacturers to "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies." The CRA's reporting obligations apply from 11 September 2026 and the rest of the regulation from 11 December 2027.

SPDX and CycloneDX are the common formats. Generate the SBOM in the build rather than by hand, so it describes what was actually shipped. For sovereignty purposes, the useful questions are which components are maintained by a single vendor, which cannot be built from source, and which would block a release if their registry disappeared.

use regulation as input, not as the deliverable

Several EU texts already ask for parts of this work. They are useful for scoping and for getting budget, but the assessment should produce engineering decisions, not a compliance checklist:

• DORA, Article 28(8), requires financial entities to put in place exit strategies for ICT services supporting critical or important functions, and exit plans that are "comprehensive, documented" and "sufficiently tested and reviewed periodically."
• NIS2, Article 21, lists supply chain security among the required risk-management measures and asks entities to take into account "the vulnerabilities specific to each direct supplier and service provider."
• The Data Act, Chapter VI, applies from 12 September 2025 and sets rules for switching between data processing services. Contracts must allow a notice period of at most two months and a transitional period of at most 30 calendar days, and from 12 January 2027 providers may not charge switching fees. That makes some cloud exits contractually easier. It does not move identifiers, rewrite proprietary API calls or export keys.
• The European Commission's Cloud Sovereignty Framework (version 1.2.1, October 2025) was written for the Commission's own cloud procurement. Its eight sovereignty objectives, from legal and jurisdictional to supply chain and technology sovereignty, and its assurance levels from SEAL-0 to SEAL-4 are a useful shared vocabulary when discussing results with procurement and leadership.

Which of these apply, and how, is a question for your legal and compliance teams. The engineering assessment gives them facts to work with.

what the assessment should deliver

For the example company, a focused first assessment would produce:

• A dependency map for the three traced functions, in the record format above.
• A risk matrix of exit difficulty against impact if unavailable.
• The short list of critical dependencies, with the evidence for each rating.
• Tested exports for the critical ones, or a note that no export exists.
• Architecture recommendations: what to leave, what to wrap behind an interface you own, and what to replace.
• A prioritized roadmap, sequenced so the cheapest reductions in risk come first.

Two outcomes are worth planning for. Some critical dependencies will be accepted, because the alternative costs more than the risk. Others become portable through small changes: a custom domain, an abstraction layer around an AI API, internal identifiers, an export job that runs every month. Replacement is the least common recommendation, and the most expensive.

This is the entry point of our digital sovereignty work: a short, concrete assessment, followed by architecture and implementation where the findings justify it. Bring the functions you cannot lose and the systems behind them, and let's map what they depend on.