Thinking in terms of dependencies

Data as a starting point

View your IT environment as a layered structure. At the core is always the data: customer information, financial records, and the information that powers your primary processes. Surrounding this are the layers that make that data accessible and usable.

Directly surrounding the data are the applications—the software that employees and customers use to work with the data. Around that lies the platform: virtualization, operating systems, and the management software that keeps everything running. Then follows the infrastructure, including hardware, the network, and the data center. For some, this is still partially on-premises, while for others, it is entirely in the cloud. The outermost layer is that of suppliers and the ecosystem: the contracts, licenses, and partner programs that determine the conditions under which you may use all that technology.

For each layer, you ask the same questions. Who provides this? Which jurisdiction does that party fall under? And what happens to the data if this layer disappears or changes? The closer a layer is to the data, the more weight those questions carry. In 'Sovereignty is more than a promise', we already addressed who holds the keys and which laws govern the owner. By thinking in layers, you can see where you need to ask those questions first.

Not every dependency carries the same weight

If you choose a hyperscaler, that is primarily a jurisdictional issue, regardless of the costs. A US-based supplier falls under the Cloud Act, even if the servers are located in the Netherlands. For workloads that rely on your (customer) data, that is a risk you must be able to justify. If a workload does not touch your data, the situation is very different.

You do not need to put a tool for tracking schedules, sending out surveys, or managing other minor tasks through the same rigorous process as your ERP system. As long as it contains no customer data and your primary process does not grind to a halt if the tool is down for a day, the dependency is limited. Mapping dependencies therefore also means consciously choosing where not to overcomplicate things.

And if you take this to its logical conclusion, you end up at the chips in the hardware. These are manufactured somewhere, and almost never in Europe. Being completely independent is therefore not a realistic goal. Knowing where you are dependent and what that means for your core business, however, is.

Technology also has an organizational side

Dependency is not just about what software can do or how it functions. The acquisition of VMware by Broadcom clearly demonstrated this. The technology remained the same, but licensing models, bundles, and the partner program were completely overhauled in a short period. For many organizations and cloud providers, this had far-reaching consequences, quite apart from the technology itself.

The outermost layer—that of suppliers and the ecosystem—can therefore be just as volatile as the technology itself. A supplier can change ownership, shift strategy, or impose different terms. That is why the important question is: how agile are you if one of your suppliers makes a sudden pivot? Can you adapt, can you switch, and does your data remain secure and accessible in the meantime?

That calls for alternatives, not panic. In 'Multi-tenant options for VMware CSPs', we already noted that panic migrations often create more risk than they eliminate. Agility lies in preparation: knowing which workloads can run where, ensuring data isn't locked into a single platform, and having a fallback or backup that doesn't rely on the same technology as production.

Peeling back layer by layer

Mapping your dependencies starts at the core and works outward. Which data is critical? Which applications, platforms, and infrastructure does that data rely on? And which suppliers are behind those? This allows you to see, layer by layer, where the real risks lie and where a dependency is perfectly fine.

That is exactly what the Cyber Security Act requires: insight into your supply chain, informed choices, and demonstrable risk management. It is not about locking everything down to the maximum, but about applying the most stringent measures where the core could be impacted.

The goal is not to avoid dependencies. New technology offers new opportunities, and you want to be able to take advantage of them. The goal is to do so without taking unnecessary risks with your data.

Fundaments also relies on international vendors. We acknowledge that, and we design our services so that our customers' data remains governed by Dutch law and in Dutch hands, regardless of changes in the surrounding layers. Curious about what your layers look like and where the risks lie? Get in touch, and we'll peel back the layers together.