Most organisations think they have their IT risks covered. Backups are running. Uptime is monitored. Incidents have a response plan.
But there is a category of risk that sits outside all of that — and it only becomes visible when recovery fails. A SaaS provider goes offline. A managed service provider is compromised. A critical API stops responding. Suddenly, internal processes grind to a halt, even though your own infrastructure is still running. Your backups exist. Your servers are online. And yet: you cannot recover.
The risk is not inside your own systems. It is in the dependencies between them. Modern IT environments are built on interconnected services, and those connections create failure points that traditional audits rarely surface. This blog explains where those risks hide and what to do about them.
Key Takeaways
• Modern IT ecosystems create hidden dependencies that exist outside your direct control
• Backup alone does not protect against third-party disruptions — recovery requires independence from the failing system
• Organisations that cannot recover without a provider are exposed to operational risk that traditional IT audits rarely surface
Why Are Modern IT Ecosystems So Interconnected?
Over the past decade, most organisations have moved from self-managed infrastructure to a layered model of SaaS platforms, cloud services, managed service providers (MSPs), and third-party integrations. Each layer adds capability — and each layer adds a dependency.
A typical dependency chain
A mid-sized organisation today might depend on:
• Microsoft 365 for communication and collaboration
• A CRM SaaS platform for sales and customer management
• A third-party integration layer for real-time data sync
• An MSP for infrastructure management and monitoring
• A cloud backup provider for data protection
If one link in this chain fails, the disruption does not stay local. It cascades.
This is no longer theoretical. According to ENISA's analysis of supply chain attacks, supply chain incidents now regularly affect hundreds of downstream organisations from a single provider compromise. In 2023, the MOVEit vulnerability compromised data at over 2,500 organisations worldwide through a single file transfer tool.
Why Dependency Risks Stay Invisible
Dependency risks rarely appear on IT risk registers — not because they are small, but because they are structurally hard to see.
The three most common blind spots
• No dependency map: IT teams document systems they own. Third-party services are rarely charted as formal dependencies with explicit failure modes.
• The availability assumption: SaaS platforms and cloud providers publish uptime SLAs. These are often mistaken for recovery guarantees. They are not. A 99.9% uptime SLA says nothing about data recoverability after a breach or configuration error.
• Invisible access control: Many platforms control access to your own data. If the provider is unavailable, or restricts access during an incident, you may not be able to export or restore your data — even from your own backup.
This gap between availability and recoverability is one of the most underappreciated risks in modern IT risk management.
What Happens When One Dependency Fails?
The impact of a dependency failure extends well beyond the affected service.
Operational impact
• Employees lose access to critical applications and cannot perform core tasks
• Automated data flows between systems stop — triggering errors downstream
• Customer-facing services may fail entirely, even when the primary product platform is working
Recovery challenges that most organisations miss
Even when backups exist, recovery may be blocked because:
• The recovery environment itself depends on the failed provider
• Data cannot be restored into a working environment without the SaaS layer
• Access credentials or encryption keys are controlled by the provider, not the organisation
A solid disaster recovery strategy must account for these external dependencies — not just internal hardware or software failure.
Are Backups Still Effective in Dependent Environments?
Yes — but only if they are designed with independence in mind.
The limitation of traditional backup assumptions
Classic backup architectures assume three things that no longer hold in modern environments:
• The recovery environment is available and accessible
• Systems can be restored independently from one another
• Access to the platform where data lives is not restricted
In a highly interconnected ecosystem, all three of these assumptions can fail simultaneously. Backup data may exist — but be completely inaccessible or unrestorable without the cooperating systems.
What effective backup looks like in 2024
Organisations need backup strategies that:
• Operate independently from production environments and the affected ecosystem
• Allow data export and recovery without requiring the original platform to be online
• Protect data across SaaS, endpoints, and servers — not just servers alone
• Are tested regularly against realistic failure scenarios, not just hardware outages
This is where solutions like backup as a service provide meaningful control: they store data in isolated environments and allow recovery to proceed independently from the primary ecosystem.
How to Reduce Hidden Dependency Risks: A 4-Step Framework
Reducing dependency risk starts with visibility. Most organisations cannot manage risks they have not mapped.
Step 1 — Map all external dependencies
• List every third-party provider, SaaS platform, and integration in your environment
• Document which internal processes depend on each external service
• Identify data flows and which provider controls access to which data set
Step 2 — Assess recovery scenarios, not just availability
For each dependency, ask:
• Can we restore our data without this provider being online?
• Do we control the encryption keys for our backed-up data?
• How long can this business process operate without this system?
• What is our fallback if the provider restricts access during an incident?
Step 3 — Implement independent recovery capability
• Store backups outside production environments, in isolated locations not managed by the same provider
• Ensure recovery does not require a single provider — especially the one most likely to be affected
• Extend backup coverage to endpoints, which often hold operational data not captured by server backups
Protecting endpoints is especially critical: endpoint backup ensures that data on laptops and workstations remains accessible even when central systems are down.
Step 4 — Test recovery, not just backups
• Run at least one annual recovery test that simulates a third-party provider failure (not just a server crash)
• Verify that recovery procedures do not require access to the system that failed
• Document recovery times and compare against operational tolerance thresholds
The NIS2 Directive — now binding for essential and important entities across the EU — explicitly requires organisations to demonstrate resilience and recovery capabilities, including the ability to recover from supply chain incidents. This gives dependency risk management a regulatory dimension beyond IT best practice.
Conclusion
Modern IT ecosystems offer real advantages in flexibility and scalability. But they also create dependency chains that can block recovery when they fail — often in ways that traditional backup strategies do not address.
The gap between having a backup and being able to recover is where most organisations are exposed. Reducing that gap requires understanding which external systems your recovery depends on, and ensuring you can operate independently when they are unavailable.
Rethinking your recovery strategy — not just your backup policy — is the starting point.
Frequently asked questions
What is a dependency risk in IT ecosystems? +
A dependency risk occurs when your organisation relies on external systems or providers that you do not directly control. If those systems fail, your operations can be disrupted even if your own infrastructure is working correctly. The risk is not just downtime from the external provider — it is the inability to recover your own data or continue your own processes without that provider being available. Dependency risks are particularly dangerous because they are often invisible: they are not listed in internal IT inventories, and they may only become apparent when a recovery attempt fails.
Why are supply chain attacks increasing? +
Supply chain attacks are increasing because attackers have learned that targeting a central provider is far more efficient than attacking individual organisations. A single compromise of an MSP, a software update mechanism, or a SaaS platform can simultaneously affect thousands of downstream customers. According to ENISA, supply chain attacks have become one of the primary vectors for large-scale cyber incidents in Europe. The MOVEit incident in 2023 is a recent example: one vulnerability in a widely used file transfer tool compromised data across more than 2,500 organisations globally.
Is backup alone enough to protect against dependency risks? +
No. Backup is essential, but it is not sufficient on its own. The critical issue is not whether backup data exists — it is whether recovery is possible without depending on the system or provider that failed. If your backup solution itself relies on the same provider, or if restoring data requires the SaaS platform to be online, then backup does not solve the problem. Organisations need independent recovery capability: backups stored in isolated environments, with recovery procedures that can be executed without the cooperation of the affected provider. This distinction — between having a backup and being able to recover — is the most important gap to address.