Digital sovereignty is often approached from the top: the choice of a host, a cloud, a vendor. That matters, but it leaves in the dark a layer we rarely see fully mapped: integration flows. API gateways, integration platforms, message buses, SaaS connectors, observability tools: that is where data travels, and it is often where the dependencies nobody explicitly chose are hidden.
This article offers a practical approach to knowing where your data goes. It is not a legal opinion: compliance questions must be validated with your legal and compliance teams.
Why the integration layer is a blind spot
Several reasons explain why this layer is poorly known:
- it has been built in strata: a vendor gateway here, a managed integration platform there, connectors added project by project;
- it appears to transport without storing: one forgets that it logs, caches, traces, and sometimes replicates;
- its dependencies are indirect: a gateway hosted in Europe may send its metrics, logs or traces to a third-party service located elsewhere;
- control planes are often distinct from data planes: traffic may stay local while configuration, statistics or licences transit through a remote service.
What the question “where does my data go?” covers
For each flow, we try to answer four questions:
- Where is the data processed? The physical location of the components that see the data in clear text.
- Who operates these components? The company itself, a provider, a vendor in SaaS mode.
- Under which jurisdiction is the operator placed? An operator subject to an extraterritorial law, such as the US Cloud Act, may be compelled to disclose data even when it is hosted in Europe. The precise analysis of this risk belongs to your legal counsel.
- What remains after the passage? Logs, caches, traces, backups, analytics data: where are they, for how long, and who can access them?
Step 1: map the flows
One starts from the entry and exit points: exposed APIs, consumed APIs, file exchanges, event-driven flows. For each flow, one records:
- the sender and the recipient;
- the components traversed (gateway, integration platform, bus, proxy);
- the nature of the data (personal, financial, sensitive, technical);
- the ancillary services that are fed (logs, metrics, traces, alerts).
Useful sources: gateway configuration, API catalogue, architecture diagrams (to be checked against reality), network logs. Architecture diagrams are often behind reality; the actual configuration takes precedence.
Step 2: identify unchosen dependencies
This is the step that produces the most surprises. Typical dependencies we look for:
- a SaaS control plane for a gateway deployed locally;
- an external observability platform receiving logs and traces, sometimes with excerpts of requests;
- integration connectors that transit through the vendor’s infrastructure;
- licence or telemetry checks that contact a remote service;
- backups or replications configured by default.
None of these dependencies is necessarily a problem. The problem is that it is not known, and therefore not decided.
Step 3: classify and decide
For each identified dependency, one decides:
- accept: the risk is known, judged acceptable, and documented;
- reduce: filter what is sent (for example by masking personal data in logs), change region, encrypt with keys under your control;
- replace: with a component operated internally or by an operator placed under a jurisdiction compatible with your requirements.
The decision belongs to the organisation; the role of the mapping is to make it possible.
The link with DORA
For the financial entities concerned, the DORA regulation, applicable since January 2025, requires in particular that risks related to ICT service providers be mastered: keeping a register of information on contractual arrangements, analysing dependencies, exit strategies for services that support critical or important functions. Mapping integration flows feeds these efforts directly, without replacing them. The exact scope of the obligations depends on your situation: this should be validated with your compliance teams.
Step 4: prepare reversibility
Knowing where the data goes is not enough if a component cannot be changed. For each critical building block of the integration layer, we check:
- that the configuration is exportable in a usable format, ideally versioned in Git in a form independent of the product;
- that API contracts are documented independently of the gateway;
- that a replacement scenario has at least been sketched, with its timescales.
The realistic time to replace a gateway is defined with the teams, depending on the context.
Frequent mistakes
- Confusing hosting with sovereignty. A component hosted in Europe may be operated by an actor subject to another jurisdiction, or depend on a remote service for its configuration, licences or telemetry.
- Forgetting ancillary data. Logs, traces and caches often contain more information than one thinks, sometimes excerpts of requests or identifiers.
- Doing the mapping only once. Each new connector, each new observability option can add a dependency. The mapping must live with the estate, ideally from the versioned configuration.
- Treating the subject as purely legal. Legal counsel qualifies the risk, but only the technical team knows where the data actually goes.
What to take away
Sovereignty of integration flows starts with a simple question — “where does my data go, and who can access it?” — which few organisations can answer completely. Map, identify unchosen dependencies, decide explicitly and prepare reversibility: these steps depend on no product. They give a solid basis for architecture decisions, and for discussions with compliance.
Alongside its consulting work, CAB Ingénierie develops STOA, a sovereign iPaaS and API integration platform.
Let's talk about your project
Do you want to know where your API and integration flows actually go, or prepare the reversibility of a critical building block? Tell us about your context in a few lines: cab-ingenierie.com · contact@cab-ingenierie.com