On 11 October 2026, Yandex said a drone attack had forced the complete shutdown of its data centre in the Vladimir region, with some services unavailable to users. According to The Moscow Times and Reuters, it was the third major Yandex data centre taken out of action within days.
This article is not about the conflict. It is about a question every CIO, CISO, chief risk officer and business continuity lead should be able to answer in minutes and most cannot: where, physically, do your critical cloud and data-centre vendors run, and is your backup really outside the zone that could fail with the primary? The Yandex sequence is simply the most vivid recent proof that a facility, and the region around it, can go dark with little warning.
Our Crest.Digital News Bite covers the incident and the resilience question it raises. Watch it below, then read on for the practical steps.
Crest.Digital’s vendor intelligence platform links critical vendors to the infrastructure and locations behind them, so concentration is visible before an incident rather than after.
Explore the PlatformThree Facilities in Four Days: What Was Reported
8 October, Sasovo (Ryazan region). Drones reportedly struck a Yandex data centre, starting a fire and temporarily halting operations. Two of the three supercomputers used to develop Yandex’s AI models are housed there, and Yandex said it did not yet know whether that equipment could be restored. Meduza reported that the disruption reached companies running on Yandex infrastructure, including the websites of Russian Railways and the mobile operator MegaFon.
9 October, Kaluga region. A second strike disabled “several modules” of another Yandex facility, and the company said it was very difficult to give a timeline for restoring equipment. Data Center Dynamics noted that Yandex’s status page listed a power outage in one availability zone and slower Object Storage response across several others. Yandex shares fell about 4% on the Moscow Exchange.
11 October, Vladimir region. A third site was shut down completely. The Next Web reports that Yandex said rival cloud providers had agreed to let its clients move data and applications quickly, and quotes an analyst who said Yandex could shift some work to its remaining sites, “but that option will disappear” if attacks continue. Yandex operates five large data centres in Russia, so three of five were affected in four days.
A note on sources: attribution and damage assessments are still developing, and we have relied on Yandex statements as reported by the outlets linked above. We have not independently verified the extent of damage.
The Diversification Trap: Multi-Zone Is Not Multi-Risk
Most cloud contracts promise availability measured in percentages, and most architecture reviews tick a box for “multi-zone” or “multi-region” deployment. Those are necessary and nowhere near sufficient. Geographic diversification means that the primary, the backup and everything needed to recover sit in locations that do not share the same hazard, whether that hazard is conflict, a power grid, a flood plain, a sanctions regime, a regulator or a single fibre route.
Three traps recur when we review third-party resilience.
1. Zones that share a hazard. Availability zones within one metro area or one country protect against a failed rack or a cooling fault. They do not protect against an event that affects the whole area. The DCD report of problems spreading across several zones is a reminder that logical separation can sit on shared physical dependencies.
2. Backups that live next door. Teams often place backups with the same provider, in the same region, because it is cheap and fast. If both copies share a risk zone, you have a replica, not a recovery plan.
3. Hidden recovery dependencies. Even if data is safe elsewhere, recovery may depend on a control plane, identity service, DNS, licence server, key-management service or support team located in the affected area. These are the fourth-party links described in our piece on your vendors’ vendors.
The Exposure Chain: From Critical Vendor to Risk Alert
The way to turn this from a worry into a control is to treat location as data that belongs in the vendor record. The chain looks like this: critical vendor, infrastructure location, geographic exposure, concentration, business continuity plan, alternative provider, risk alert. Each link answers one question, and a gap in any link is where surprises come from.
Seven Questions Every Critical Vendor Should Answer
- Critical vendor: Which suppliers would stop a core service, payment flow or regulated process if they failed?
- Infrastructure location: In which facilities, cities and countries do they run your workloads, data and backups?
- Geographic exposure: What conflict, grid, climate or regulatory hazards apply to those locations?
- Concentration: How many of your critical services share the same location or the same provider?
- Business continuity plan: Is the failover target outside the hazard zone, and has it been tested?
- Alternative provider: Is there a pre-assessed second source, and how fast could you actually move?
- Risk alert: Who is told, and how quickly, when conditions around a critical location change?
This is where third-party risk and operational resilience meet. Our earlier articles on vendor concentration risk and on geopolitical third-party risk set out the portfolio view. What the Yandex sequence adds is speed: location exposure can change in a single night.
A Seven-Step Plan to Test Whether Your Backup Is Truly Separate
You can run this as a quarterly exercise or, better, as a continuous monitoring routine. We deliver it as a configurable pod: reusable connectors, workflow and evidence trail, with client effort focused on mapping and control logic.
Inventory Critical Technology Vendors
List cloud, hosting, colocation, SaaS and network providers that support critical services, ranked by business impact and regulatory importance.
Capture Where Each One Runs
Record facilities, regions and zones for primary workloads, backups, control planes and support operations. Ask suppliers directly and verify against contracts and certifications.
Score Geographic Exposure
Overlay each location with conflict, grid stability, natural-hazard, sanctions and data-localisation indicators, using a consistent scale reviewed by risk and security.
Test for Concentration
Flag where several critical services, or a primary and its backup, share a location, a provider or a hazard. Report the result to the risk committee.
Check the Continuity Plan Against the Map
Confirm the failover site is outside the same hazard zone, that recovery dependencies are also covered, and that recovery time has been tested, not assumed.
Pre-Qualify an Alternative Provider
Run due diligence on a second source before you need it, including contract terms, data portability and realistic migration time.
Wire Up Risk Alerts
Monitor news, regulatory and status signals around critical locations and route alerts to owners with a defined response playbook.
Step five is the one most programmes skip. A continuity plan that was approved before the facts changed is a document, not a control. Internal audit can independently test the map against the plan, in line with Institute of Internal Auditors expectations of assurance over resilience and risk management.
Crest.Digital is developing supplier-location and horizon-risk intelligence on top of its vendor risk platform, so critical-vendor exposure can be mapped, monitored and alerted across the industries we cover.
What Regulators Already Expect
The question is not new to supervisors. The EU’s Digital Operational Resilience Act requires financial entities to manage ICT third-party risk, including concentration risk and exit strategies for critical providers. The UK’s FCA operational resilience rules require firms to stay within impact tolerances for important business services under severe but plausible scenarios, and India’s Reserve Bank of India has issued outsourcing and IT-governance requirements that expect regulated entities to retain control over critical outsourced services. Our summary of what global regulators expect in 2026 and the piece on DORA and NIS2 as operating discipline go deeper.
For banks, GCCs and technology companies serving them, the practical test is whether you can show a supervisor a current record of where critical services run and what happens if that place is lost. “Severe but plausible” now plainly includes the loss of an entire site and its neighbours.
Where Agentic AI Helps, and Where Humans Decide
Location intelligence is a data-gathering problem that people do poorly at scale. Agentic AI workflows can collect facility and region disclosures from questionnaires and contracts, read public status pages and news for signals about critical locations, flag when a primary and its backup share a risk zone, draft the alert, and track remediation until an alternative is in place. Human-in-the-loop governance stays essential: people confirm exposure scores, approve failover decisions and own the response, with an audit trail on every step. The related concentration theme for AI providers is covered in our article on AI third-party concentration risk.
Your Turn: Is Your Backup in the Same Risk Zone?
- Yes or unsure: We have not mapped backup and recovery locations against hazards.
- No, tested: Our failover sits outside the primary’s risk zone and we have proved it.
- Contract only: We rely on provider SLAs and have not examined locations.
Tell us where you stand in the comments when you share this article on LinkedIn.
Crest Perspective
Risk programmes that treat third-party governance as a compliance checkbox are consistently underprepared when a material vendor incident occurs. The programmes that withstand regulatory scrutiny are not necessarily the most technologically sophisticated — they are the ones where risk tiering is documented, escalation paths are tested before they are needed, and the board receives accurate, timely information about the organisation’s most critical vendor dependencies.
Frequently Asked Questions
Geographic diversification means placing primary workloads, backups and recovery dependencies in locations that do not share the same hazard, such as conflict, power-grid failure, flooding or a single regulatory regime. Running in several availability zones inside one metro area or country improves protection against equipment faults but not against an area-wide event. True diversification is judged by whether one event could take out both the primary and its fallback.
An SLA is a commercial promise with service credits attached, not a guarantee that service will continue. It says little about where a provider’s facilities sit, whether backups share the same risk zone, or how quickly you can move to another provider. Resilience assessment needs location data, tested recovery times, concentration analysis and a pre-qualified alternative provider, in addition to contractual terms.
Start with contracts, data-processing agreements and security certifications, then add targeted due-diligence questions about facilities, regions, backup locations, control planes and support operations. Verify answers against public status pages and certification scopes, record them in the vendor register, and refresh them when a vendor announces changes. Continuous monitoring is more reliable than an annual questionnaire because infrastructure footprints change.
Define severe but plausible scenarios, including loss of an entire site and neighbouring facilities, then map the primary, backup and recovery dependencies for each critical service against the same hazards. Run failover tests that include identity, DNS, key management and staffing, not only data restore, and record recovery times against your impact tolerance. Internal audit should independently review the mapping and test results.
A good alert names the critical vendor, the affected facility or region, the services and business processes that depend on it, the current concentration position, and the playbook step the owner should take, such as invoking failover or contacting the alternative provider. It should be routed to a named owner, time-stamped, and tracked to closure so that the response leaves an audit trail.