Two vendors reach the final round of the same procurement. One runs its support desk from Poland, the other from Ukraine. Only one of them will be asked what happens when the power goes out.
That asymmetry is not unfair. It is a good question and it deserves a real answer. It is only incomplete, because the power goes out in Poland as well, and in that round nobody will ask for the plan.
The short answer is yes, with a condition that has nothing to do with the border: only as safe as the vendor's continuity plan and the date it was last tested, which is the same condition that applies to the vendor in Poland. Ukraine's exposure to power loss is higher, and that is a real difference rather than a rounding error.
So this article answers the question directly, and then does the more useful thing: it turns the question into a check you can run on every vendor in the round, including the ones nobody is worried about.
The question that only gets asked once
Continuity is treated as a property of a place. A vendor in a quiet country is assumed to have it. A vendor in a loud one is asked to prove it. Neither assumption survives contact with how support operations actually fail.
A support desk is not a building. It is a help desk tool you do not own, an internet connection, a shift rotation of people, and the authority to act on a customer's account. Any of those can stop working. Knowing which country the team sits in tells you something real about three of them and nothing at all about the software.
So the honest version of the question is not is Ukraine safe. It is what is this vendor's written plan for losing power, losing connectivity and losing people, and when did they last run it. That version is answerable, comparable across vendors, and awkward for exactly the vendors who should find it awkward.
What actually stops a support queue
Uptime Institute's Data Center Resiliency Survey 2026, reported by Network World, asked what causes end-to-end IT service outages. The answer is not exotic. Networking and connectivity comes first at 23%, power second at 21%, a company's own IT systems and software third at 18%, and third-party IT services, including public cloud and software as a service, cause 10%.
That third-party line is the one buyers underestimate. One outage in ten is somebody else's product failing while your own team did everything right. If your help desk platform is down, your support operation is down, and it does not matter which country your agents are sitting in.
This is why a country name is a starting point rather than an assessment. It tells you which of the four to probe hardest. It does not tell you what the vendor has done about any of them.
Power is the leading cause, and it is not a Ukraine story
A second Uptime Institute dataset asks a narrower question, about data centre outages rather than end-to-end IT services, and there power dominates outright. Power failures account for 45% of impactful data centre outages, well ahead of any other category, and the root causes inside that number are the backup equipment itself: uninterruptible power supplies, transfer switches and generators. The two figures are not one number narrowing; they are two populations, and power is near the top of both.
That detail matters more than the headline. The failures are not usually the grid going down. They are the equipment that was supposed to catch the grid going down, failing to catch it. A generator that has not been load-tested is a generator with an opinion, not a generator with a record.
The picture is improving, and we would rather say so than trade on alarm. Half of operators reported an impactful outage in the past three years, down from 74% in 2020. But when one does land it is expensive: in Uptime Institute's own reporting of its 2026 analysis, 57% of respondents said their most recent major outage cost more than $100,000.
The third thing that breaks is people, and it is what a buyer can actually check
Uptime Institute found that 92% of operators said human error was at least a minor contributor to significant outages over the past three years. The leading driver inside that, for 2026, is not carelessness or inexperience. It is failure to follow established procedures.
That is the whole argument of this article. The dominant human cause of outages is people not following a procedure, which means the procedure existed and the following of it did not. A plan nobody has run is a document. A plan a team has run is a habit.
What a buyer can genuinely check before signing is not the grid, the carriers or the generators, none of which you can audit. It is whether the team has been made to run the plan against them, and what broke when they did. Almost nobody asks.
What outsourcing support to Ukraine actually exposes you to
Here is the honest version, without decoration.
On the second item, power, Ukraine's exposure is higher than Poland's, and we are not going to pretend otherwise. On the third, people, wartime mobilisation is a staffing factor here that a vendor elsewhere in Europe does not have to manage, and any vendor who does not raise that with you before you ask is telling you something about how they handle everything else. On the first item, connectivity, there is additional wartime exposure, and it is documented rather than speculative. The International Telecommunication Union, citing the fifth Rapid Damage and Needs Assessment published in February 2026, records an estimated 2.48 billion dollars of direct damage to Ukraine's telecommunications, digital and media sector since the start of the full-scale invasion. What decides the risk at vendor level is narrower than the national picture: how many independent routes the vendor holds, and whether the failover between them has been tested.
What the aggregate record shows is that the work kept being delivered and the invoices kept being paid. Lviv IT Cluster, citing National Bank of Ukraine data, reported that Ukraine's export revenue from computer services reached $6.66 billion in 2025, up 3.3% on 2024. That is not a resilience story and we are not offering it as one. It is an aggregate demand signal and nothing more: buyers outside the country paid for more work in 2025 than in 2024. It does not show that any particular client renewed, and the source does not claim it does.
So it settles nothing, in either direction, about the vendor in front of you. That is why the rest of this article is a checklist rather than a reassurance.
Europe already tells its banks to ask these questions
If asking a support vendor about continuity feels like an unusual level of scrutiny, in one large European sector it is already mandatory.
The European Union's Digital Operational Resilience Act, which entered into application in January 2025, obliges financial entities to manage the risk of their information and communications technology providers as part of their own risk framework. Under the regulation, published in full as Regulation (EU) 2022/2554 in the Official Journal, they must run due diligence before signing, keep a register of those arrangements, and hold exit plans that are documented and periodically tested for any provider supporting a critical function.
Two things follow for everyone else. First, these questions are standard practice rather than an accusation, so asking them costs a vendor relationship nothing. Second, the regulator's instinct is the right one: the obligation is not merely to hold an exit plan but to test it.
The questions to ask any support vendor about continuity
Use these on every vendor in the round. A vendor who has done the work answers them in a sentence each. A vendor who has not will answer with adjectives.
- What is your backup for connectivity, and who else has tested it? Two providers on the same physical cable is one provider.
- What happens to a shift when a site loses power? The useful answer names where the work moves and how long the handover takes, not what equipment exists.
- When did you last run the failure on purpose, and what broke? Ask for the date. A plan with no last-run date has never been a plan, and a test where nothing broke was not a test.
- Which of your tools would take us down with them? Every vendor depends on somebody. You want the list, not the reassurance.
- Who can answer a customer at three in the morning if the team lead is unreachable? Continuity of authority fails before continuity of staffing does.
- How much of our queue history lives only in your account? Whatever lives only there is the part you cannot take with you, which is the ownership question behind whose help desk the work runs in.
- What is the notification rule, and what is the time on it? Not whether you will be told. How long before you are told.
- What does the contract say happens if you cannot staff the shift? Credits, escalation, or a named alternative. Silence is an answer too.
| What fails | Who supplies it | What proves the plan is real |
|---|---|---|
| Connectivity | Telecoms carriers, and the vendor's routing choices | Two independent paths, and the date the second one last carried live traffic |
| Power | The grid, then the vendor's backup equipment | A load test with a date on it, not an inventory of hardware |
| The help desk platform | A third party, often the same one you use | A written fallback for taking tickets while it is down |
| People | The vendor, within national rules | A named deputy per shift, and the last date cover was actually tested |
What changes when the support team is not yours
An internal support team has an implicit continuity plan: the same managers who lose the service are the ones fixing it, and everybody finds out at the same moment. Outsourcing removes that. The failure now happens inside another company, and you learn about it through a channel somebody has to remember to use.
That is a contract problem, not a trust problem, and it is solved in the same place as every other delivery question. The clauses worth arguing about are the notification time, the named deputy, the fallback for the tool, and what the reporting looks like on the day it goes wrong rather than on a normal Tuesday. It sits next to the questions of location and coverage model covered in our guide to nearshore and offshore support.
Ask for these before signature. After signature they become a negotiation, and you will be negotiating during the outage.
How IMMIDO fits
We are a Ukraine-based team. We run 24/7 first-line support inside your own tools, operated by a Europe-based team, and we work as a fixed monthly team, not per ticket. Our clients are other businesses, so the tickets that reach us come from somebody's staff with a case and a transaction, not from a consumer in a live chat.
Working inside your help desk is the part of that which matters here. The queue, the history and the access stay in your account, so the question of what you lose if we stop has an answer that does not depend on our goodwill: you keep the system, because it was always yours, and moving to another provider stays a scheduling problem rather than a recovery one.
We do not publish an uptime percentage. We cannot let you audit one, so it would be a number you have to take on faith, and this whole article argues against taking that kind of number on faith. What we will do is answer the questions above in writing, with dates, and put the notification rule and the cover arrangement in the contract where you can enforce them.
If you are running a vendor round now, ask us the eight questions and ask everybody else the same eight. See how we run first-line support, then book a call and put our answers next to theirs.
Sources: Uptime Institute, 2026 Annual Outage Analysis and Data Center Resiliency Survey 2026, as reported by Network World and in Uptime Institute's own release; Lviv IT Cluster, citing National Bank of Ukraine data on 2025 computer services exports; the International Telecommunication Union, citing the fifth Rapid Damage and Needs Assessment, on damage to Ukraine's telecommunications sector; the European Union's Digital Operational Resilience Act, Regulation (EU) 2022/2554 on EUR-Lex, with background from the European Insurance and Occupational Pensions Authority. All accessed 8 September 2026.