Which IT risks do most organisations overlook?

What is dependency risk in IT, and why is it overlooked?

Dependency risk is the chance that a system you don't control fails and takes your processes, or your recovery, down with it. It's overlooked because risk registers list the assets an IT team owns, not the suppliers those assets lean on.

Picture a Monday morning. Your servers are online and last night's backup jobs show green. But your CRM provider is down, the integration that syncs orders has stopped, and your MSP's remote tooling is offline after a security incident. Nothing of yours has failed, yet nobody can work.

Endpoint visibility, for example through an EDR platform, tells you what runs on your own devices. It doesn't tell you what happens when a supplier upstream goes dark.

A typical dependency chain

A mid-sized organisation in the Netherlands or Germany might depend on:

• Microsoft 365 or Google Workspace for email, files and collaboration
• A SaaS CRM or ERP platform for sales, finance and customer data
• An integration layer or iPaaS that moves data between those platforms
• An MSP that manages infrastructure, patching and remote access
• A backup provider that holds the copies you'd recover from

How often do third-party failures actually cause disruption?

Often enough that EU and national authorities now treat it as a core threat. Several recent incidents show that a single supplier can disrupt thousands of organisations at once.

• Supplier compromise. In its Threat Landscape for Supply Chain Attacks (2021), ENISA found that in 66% of the supply chain attacks it analysed, suppliers did not know, or failed to report, how they had been compromised.
• One tool, many victims. According to CISA advisory AA23-158A, the CL0P ransomware gang began exploiting a zero-day SQL injection flaw (CVE-2023-34362) in Progress MOVEit Transfer on 27 May 2023 and stole data from the underlying databases. Every organisation running the file transfer tool on the internet was exposed through the same product.
• One faulty update. On 19 July 2024, a CrowdStrike update crashed Windows machines worldwide. Microsoft estimated that 8.5 million Windows devices were affected, less than 1% of all Windows machines, yet airlines, hospitals and banks were disrupted because of where those devices sat.
• One shared IT provider. In October 2023, a ransomware attack on the municipal IT provider Südwestfalen-IT disrupted services in more than 70 German municipalities, from resident records to registry offices, The Record reported.

The ENISA Threat Landscape 2025 describes the same pattern: digital infrastructure and services in the EU remain high-value targets, "particularly in the frame of incidents leveraging cyber dependencies used as launchpads for follow-up attacks".

Why don't dependency risks show up in IT audits?

Because most audits check whether your own controls exist, not whether you can operate when someone else's controls fail. Three blind spots come up again and again.

1. No dependency map. Teams document the systems they own. Third-party services are rarely charted with their failure modes, owners and the processes that rely on them.
2. The availability assumption. A SaaS uptime SLA is easy to mistake for a recovery promise. It isn't. A 99.9% availability target says nothing about getting your data back after an accidental deletion, a malicious admin or a sync error that overwrites good records.
3. Access you don't control. Many platforms gate access to your own data. If the provider is down, suspends your tenant or restricts access during an incident, you may not be able to export or restore anything, sometimes not even from a backup that depends on that platform's credentials or APIs.

The result is a gap between having a backup and being able to recover, which is where most organisations are exposed. We cover the SaaS side of this in more detail in what happens when your SaaS provider goes offline.

Are backups still enough when you depend on third parties?

Yes, but only if they're built to be independent of the systems they protect. A backup that lives inside the failing platform, or can only be restored through it, fails with it.

Classic backup designs quietly assume three things: the recovery environment is available, systems can be restored one by one, and you keep access to the platform where the data lives. In a connected estate all three can fail at once. That's what happened to the Australian pension fund UniSuper in 2024, which recovered from copies held with another provider; we cover the lessons in UniSuper and third-party backups.

The 3-2-1-1-0 rule is a practical baseline: three copies, on two media, one off-site, one immutable or offline, and zero errors after verification. Don't forget endpoints, which often hold working files that never reach a server; see endpoint backup for hybrid work.

How do you reduce hidden dependency risks? A 4-step approach

Start with visibility, then make recovery independent and prove it works. These four steps fit an SME IT team or an MSP running the exercise for a client.

1. Map every external dependency

• List each SaaS platform, cloud service, MSP, integration and API you use.
• Record which process depends on it, which data it holds and who holds its admin credentials and encryption keys.

2. Assess recovery, not only availability

• Can we restore this data without the provider being online?
• How long can the process run without this system? That's your RTO, the time you can afford to be down.
• How much data can we afford to lose? That's your RPO, how much work you can lose. Our RTO and RPO explainer covers how to set both.
• What do we do if the provider restricts access during its own incident?

3. Build an independent recovery path

• Keep backup copies outside the production environment, with a provider that isn't the one most likely to fail.
• Use separate credentials and require MFA for backup administration.
• Make at least one copy immutable and one air-gapped.
• Extend coverage to SaaS data and endpoints, not only servers.

4. Test a supplier failure, not only a server crash

• Run at least one recovery test a year that assumes a key supplier is unavailable.
• Check that the runbook doesn't need access to the system that failed.
• Record the restore times you achieve and compare them with your RTO.

Does NIS2 require you to manage dependency risk?

Yes, for organisations in scope. Directive (EU) 2022/2555 requires essential and important entities to take risk-management measures that explicitly cover continuity and suppliers.

• Article 21(2)(c): "business continuity, such as backup management and disaster recovery, and crisis management".
• Article 21(2)(d): supply chain security, including the relationships between each entity and its direct suppliers or service providers.
• Article 21(3): entities must take into account the vulnerabilities specific to each direct supplier and service provider and the quality of their cybersecurity practices.
• Article 20: management bodies approve these measures, oversee them and can be held liable.

In the Netherlands the Cyberbeveiligingswet came into force on 15 August 2026; in Germany the NIS2UmsuCG has applied since 6 December 2025. See the Article 21 overview and our guide to NIS2 supply chain security.

What to do next

Your biggest exposure probably isn't a missing backup. It's a backup you can't restore because the provider, platform or tool it depends on is the thing that failed. Map your dependencies, give each critical one a recovery path that works without it, and test that path at least once a year.

Mindtime is built to be that independent copy. Backups sit only in our own Tier III data centres in the Netherlands and Germany, under EU law and independent of US hyperscalers, as immutable copies (Object Lock) plus an air-gapped copy. Every backup job is checked automatically, backups are scanned for malware, and you can boot VMs instantly in an isolated recovery environment on a separate, clean network. For MSPs, our EDR platform adds endpoint visibility across every client tenant, while the MSP runs the service.

Want to know which of your dependencies would block recovery? Get a free assessment.

This article is information, not legal advice.