Как защитить бизнес в суде при сбоях и потере данных в облаке Яндекса

С 8 по 11 октября 2026 года в работе дата-центров Яндекса в Сасово (Рязанская область), Калуге и Владимире произошла серия крупных аварий. Из-за пожаров и отключений электричества после атак беспилотников одновременно перестали работать две ключевые зоны доступности платформы Yandex Cloud (ru-central1-a и ru-central1-b), а выдача новых серверных мощностей была остановлена

Для тысяч компаний, которые хранят в сервисах Яндекса (бесплатный Яндекс.Диск, корпоративный «Яндекс 360 для бизнеса» и инфраструктура Yandex Cloud) рабочие базы, бухгалтерию и персональные данные клиентов, этот сбой показал главную юридическую проблему: по договорам с провайдером почти все финансовые и правовые риски потери информации несет сам бизнес, а не хранилище. 

Разбираем по пунктам, как устроены правила Яндекса, чем грозят проверки государственных органов и что именно нужно изменить в договорах и технической схеме хранения прямо сейчас.

Часть 1. Утрата данных и ответственность по связанным обязательствам

1. На ком лежат риски, если из-за сбоя в облаке, если из-за этого вы нарушили договорные сроки

Из-за остановки серверов Яндекса ваша компания потеряла доступ к файлам или базам данных и не смогла вовремя сдать работу или оказать услугу своему клиенту. Клиент требует неустойку и возмещение убытков, а вы считаете, что виноват облачный провайдер.

Как это работает по закону и правилам Яндекса: юридически мы имеем два разных договора, регулирующие  разные и никак не связанные между собой правоотношения:

1. Ваша ответственность перед вашим заказчиком. По пункту 3 статьи 401 Гражданского кодекса РФ (ГК РФ) бизнес отвечает за нарушение обязательств независимо от своей вины, если не докажет форс-мажор. А по статье 403 ГК РФ вы отвечаете за сбои и ошибки любых третьих лиц, которых привлекли для работы (включая хостинг и облачные сервисы), как за свои собственные действия. Поэтому авария у Яндекса автоматически не освобождает вашу компанию от штрафов и пеней перед вашими покупателями.

2. Ответственность Яндекса перед вами. Во всех сервисах Яндекса ответственность за работу оборудования и за сохранность самих клиентских файлов разделена:

• Базовое Пользовательское соглашение сервисов Яндекса (опубликовано по адресу https://yandex.ru/legal/rules , далее — ПС): в пункте 9.1 прямо указано, что пользователь применяет сервисы на свой собственный риск, они предоставляются по принципу «как есть», а Яндекс не отвечает за их соответствие целям пользователя.

• Корпоративный сервис «Яндекс 360 для бизнеса» (регулируется Лицензионным соглашением в редакции от 8 сентября 2026 года, Общими условиями в редакции от 6 октября 2026 года и Офертой на услуги): по пункту 3.8 Оферты и пункту 6.5 Общих условий провайдер обязан защищать саму платформу и принимать разумные меры для сохранности данных, но в пункте 6.1 Общих условий закреплено, что сервис предоставляется «как есть» и гарантий сохранности файлов Яндекс не дает. В пункте 5.4.3 Лицензионного соглашения: клиент обязан «самостоятельно обеспечивать резервное копирование принадлежащей Лицензиату информации, обрабатываемой с помощью Программ» .

• Платформа Yandex Cloud (Оферта и Общий SLA от 26 августа 2026 года, вступившие в силу 7 сентября 2026 года): по пункту 7.2.7 Оферты провайдер отвечает за своих подрядчиков (ст. 403 ГК РФ), обеспечивает физическую охрану зданий и работу серверов, но создание резервных копий баз данных и приложений также полностью лежит на клиенте. Точно такие же правила действуют у других российских провайдеров — Selectel и VK Cloud.

Если вы привлекли интегратора для настройки облака, его ответственность зависит от формулировки договора: обещал ли он готовое бесперебойное решение с резервным копированием или просто оказывал разовую консультацию по подключению. 

Интересный момент: генеральный директор компании, принявший решение о размещении и хранении значимых бизнес-данных в облаке, не организовал отдельное резервное копирование вопреки п. 5.4.3 лицензионого соглашения с Яндексом, собственники компании могут взыскать с руководителя прямые убытки за неразумные действия (ст. 53.1 ГК РФ).

2. Что требовать при временной или полной потере данных в облаке и на какие сроки по восстановлению можно рассчитывать

Компания хочет знать, в какой срок Яндекс обязан вернуть пропавшие файлы и сколько времени могут продолжаться работы по восстановлению данных.

Ни один типовой договор Яндекса не содержит гарантии того, что удаленные или поврежденные файлы клиента будут восстановлены, равно как и не устанавливает точных сроков такого восстановления:

• В бесплатном Яндекс.Диске (https://yandex.ru/legal/disk_termsofuse  https://yandex.by/legal/disk_termsofuse/ru/ ) потребовать восстановления данных попросту невозможно, такое право у пользователя и корреспондирующая обязанность платформы  отсутствуют.

• В «Яндекс 360 для бизнеса» при сбое инженеры хостинг-провайдера чинят саму почтовую и файловую платформу, но восстанавливать пропавшие письма или документы администратор вашей компании должен самостоятельно из заранее сделанной внешней резервной копии (размещенной вне контура Яндекс 360). По сути не смотря на то, что хранение осуществляется за плату - объем обязанностей платформы в части обеспечения сохранности данных не сильно отличается от бесплатного хранения.

• В Yandex Cloud действуют Соглашения об уровне обслуживания (SLA), которые гарантируют процент времени работы конкретного оборудования или виртуальной машины за месяц (для единичной виртуальной машины по SLA Yandex Compute от 21 июля 2026 года, вступившему в силу 1 августа 2026 года, этот порог равен 99,95%). Однако работа самой виртуальной машины не означает, что работает ваша программа со всеми связанными базами. Например, во время аварии 11 октября 2026 года к 11:14 МСК панель управления, API и хранилище S3 (с замедлениями) уже открывались, но в управляемых базах данных сохранялись сбои с Apache Kafka, в Kubernetes не работали отдельные кластеры, а сервис мониторинга Monium был полностью недоступен.

Допустимые пределы “простоя” — недоступности платформы для пользователя:

Время допустимого простоя за полный месяц рассчитывается по официальной формуле SLA:

При этом по пункту 4.2 Общего SLA в простой не засчитывается время плановых профилактических и аварийных работ, если в сумме за месяц сервис отключался на них не более чем на 8 часов. Потенциально при любой крупной аварии из допустимого времени простоя можно вычесть первые 8 часов). 

3. Можно ли взыскать с хостинг-провайдера или облачного сервиса убытки за простой и потерю файлов

Пока облако лежало, бизнес терял выручку, платил зарплату простаивающим сотрудникам и тратил деньги на срочный переезд на другие серверы. Можно ли взыскать эти суммы с Яндекса?

По статьям 15 и 393 ГК РФ убытки делятся на реальный ущерб (прямые затраты на восстановление инфраструктуры) и упущенную выгоду (неполученный доход за время простоя). Но статья 400 ГК РФ разрешает в договорах между компаниями заранее ограничивать размер ответственности. В документах Яндекса прописаны три ограничения:

1. Упущенная выгода не возмещается никогда. Провайдер полностью исключает свою ответственность за потерю прибыли, срыв контрактов, уход клиентов и любые косвенные убытки от прерывания бизнеса.

2. Ограничение ответственности по реальному ущербу. В «Яндекс 360 для бизнеса» согласно пункту 12.5 Оферты (и аналогичным п. 12.2 типовых оферт на подписку) максимальная сумма, которую можно взыскать с провайдера по любым претензиям, ограничена суммой, фактически уплаченной клиентом за подписку за 3 (три) месяца, предшествующих моменту возникновения претензии.

В Yandex Cloud единственная стандартная выплата за простой — это сервисный кредит (скидка в счет будущей оплаты услуг самого провайдера) по ступенчатой шкале 10%, 15% или максимум 30% от месячной стоимости неработавших виртуальных машин. Например, если компания платит за серверы в Yandex Compute 100 000 рублей в месяц, то при 12 часах простоя в октябре (доступность падает до 98,3871%) она получит скидку 15% (15 000 рублей), а при 3 сутках простоя (72 часа, доступность 90,3226%) — максимальные 30% (30 000 рублей).

3. Освобождение от выплат при внешних авариях. По пункту 12.8 Оферты Яндекс 360 и пункту 4.1.5 Общего SLA Yandex Cloud провайдер полностью освобождается от ответственности и не начисляет даже скидки по SLA, если сбой произошел из-за обстоятельств непреодолимой силы (форс-мажора по ст. 401 ГК РФ). Как мы уже знаем на примере печальной истории с Wildberries, атаки беспилотников непременно будут рассматриваться провайдером в качестве обстоятельств непреодолимой силы.

Взыскать с провайдера полные убытки сверх трехмесячного лимита можно, если доказать, что нарушение было умышленным. Но если вы потребуете возместить стоимость потерянных файлов, не имея собственной резервной копии (то есть нарушив п. 5.4.3 Лицензионного соглашения), арбитражный суд скорее всего применит статью 404 ГК РФ и откажет в иске. 

Примеры дел с исками к облачному провайдеру:

• Дело № А40-224058/2024. Заказчик предъявил иск о взыскании убытков (реального ущерба) в связи с тем, что провайдер корпоративного ПО на базе Linux в одностороннем порядке прекратил оказание оплаченной технической поддержки и закрыл доступ к обновлениям инфраструктуры. Арбитражный суд города Москвы взыскал с провайдера в пользу заказчика около 13 000 000 рублей реального ущерба.

• Дело А40-144372/2023. ИТ-компания «Эй Би Си» предъявила встречный иск к российскому подразделению облачного и софтверного вендора (ООО «САП СНГ») о взыскании 89 000 000 рублей убытков, вызванных прекращением доступа к облачным сервисам и технической поддержке.

• Дело №А72-10511/2024. Истец (ООО «ПКП «Завод высокотехнологичного оборудования») требовал солидарно взыскать с поставщика (ООО «Айти Альфа») и системного администратора (ИП Цветкова Е.С.) убытки после атаки вируса. Суд удовлетворил иск частичн и взыскал только реальный ущерб (2 263 999,75 руб.) и с одного ответчика (ИП Цветкова Е.С.), полностью отказав во взыскании упущенной выгоды в требованиях к ООО «Айти Альфа». Суд взыскал с подрядчика реальный ущерб, а не упущенную выгоду. Подрядчик при настройке сервера поставил слабые пароли 123456, выдал всем учёткам права администратора, не сделал бэкапы и не закрыл доступ на выходные. Хотя атаку совершили третьи лица, подрядчик создал условия для её реализации: снизил уровень безопасности, не обеспечил сохранность данных и доступов. Суд увидел прямую причинно-следственную связь между некачественными услугами и убытками.

• Дело №А56-85885/2024. Суд первой инстанции удовлетворил Иск.
  Истцом представлены документы, подтверждающие факт несения расходов на разработку и поддержку интернет-ресурса, а также обоснование упущенной выгоды, в том числе на основе сравнительного анализа данных по выручке и поисковому трафику за аналогичные периоды. Эти доказательства позволяют установить размер убытков с разумной степенью достоверности. Ответчик, в свою очередь, ссылается на обстоятельства, исключающие его ответственность, в частности — на якобы имевшую место DDoS-атаку, препятствовавшую нормальной работе сайта истца. Однако суд не находит оснований считать такие обстоятельства форс-мажорными в понимании статьи 401 ГК РФ. Согласно пункту 3 статьи 401 ГК РФ, лицо, не исполнившее обязательство, несёт ответственность, если не докажет, что надлежащее исполнение оказалось невозможным вследствие непреодолимой силы, то есть чрезвычайных и непредотвратимых при данных условиях обстоятельств.

• Дело №А40-293189/2022 Заказчик купил хостинг и услуги по созданию систем безопасности в облаке. После хакерской атаки 09.04.2022 на серверный кластер, арендованный ООО «ДЕФА» у АО «МСТН». Злоумышленники получили доступ к системе виртуализации, скриптом удалили все виртуальные машины и данные, включая резервные копии. Сайт аэропорта Махачкалы был уничтожен. Суд отказал в возмещении ущерба/упущенной выгоды, так как причиной уничтожения сайта стали противоправные действия неустановленных лиц, а не действия провайдера. Прямой причинно-следственной связи с провайдером нет. Договор 2017 года не обязывал исполнителя защищать от атак, направленных на полное уничтожение инфраструктуры. В договоре были конкретные меры: защита от несанкционированного доступа, DDoS, SQL-injection, разграничение прав, шифрование, IP-фильтрация. Суд отметил DDoS-атака не всегда означает полное уничтожение серверной инфраструктуры.

4. В чем разница между бесплатными и платными тарифами хранения

С точки зрения статьи 421 ГК РФ переход с бесплатного Яндекс Диска на коммерческие тарифы переводит компанию из обычного пользовательского соглашения в рамки платного договора оказания услуг, аренды мощностей.

Чем еще опасно использование бесплатного Яндекс Диска для бизнеса: помимо нулевой ответственности провайдера и права Яндекса заблокировать аккаунт за автоматическую выгрузку файлов или массовый файлообмен (п. 4.5 и 4.6 Условий использования Яндекс.Диска), бесплатный Диск привязывается к единому аккаунту Яндекс ID по правилам https://yandex.ru/legal/id_termsofuse  (п. 2.2 ПС). Если сотрудник зарегистрировал такой Диск на свой личный номер телефона и уволился со скандалом, компания не сможет отобрать у него аккаунт и вернуть свои рабочие папки.

Часть 2. Что поменять в договорах со своими клиентами 

Какие действия по снижению рисков стоит предпринять в свете новых угроз для бизнеса?   

Так как согласно статье 403 ГК РФ вы отвечаете перед своими заказчиками за простой дата-центров Яндекса как за свои действия, а сам Яндекс вернет вам максимум скидку 10–30% на тариф или стоимость трехмесячной подписки, ваши договоры с клиентами нужно срочно выровнять под условия провайдера. 

1. Оговорка о приостановке сроков при авариях ЦОД и атаках беспилотников (Back-to-Back)

Как правило договорах с заказчиками указано, что к форс-мажору не относятся проблемы у контрагентов исполнителя (п. 3 ст. 401 ГК РФ). Когда в октябре 2026 года дата-центры Яндекса остановились после атак БПЛА и пожаров, для самого Яндекса это форс-мажор (п. 12.8 Оферты Яндекс 360, п. 4.1.5 Общего SLA Yandex Cloud)1. А для вашей компании перед вашим заказчиком это не форс-мажор, потому что пострадало имущество вашего подрядчика (Яндекса), а не ваше собственное.

Что сделать: 

Включить в раздел о сроках оказания услуг и ответственности ваших клиентских договоров прямую зеркальную оговорку (на основании статей 328, 401 и 421 ГК РФ):

«Сроки оказания услуг (выполнения работ) автоматически приостанавливаются без начисления неустоек, пеней и штрафов на весь период глобальных сбоев магистральных операторов связи и аварий в коммерческих центрах обработки данных (включая площадки Yandex Cloud, Яндекс 360, VK Cloud, Selectel), вызванных пожарами, отключениями электроснабжения, внешними кибератаками или падением беспилотных летательных аппаратов (БПЛА) и их обломков, плюс 48 часов на восстановление систем из резервных копий. Достаточным подтверждением такого сбоя стороны признают официальную карточку инцидента на сайте облачного провайдера (или зафиксированные через сервис Shotapp  образом сведения из средств массовой информации) без необходимости предоставления сертификата Торгово-промышленной палаты».

2. Зеркальное ограничение размера убытков

Если в ваших договорах не ограничен размер ответственности, то Заказчики согласно статье 15 ГК РФ вправе взыскать с вас и прямые расходы, и всю свою упущенную выгоду за время простоя, тогда как Яндекс упущенную выгоду не платит вообще.

Следует добавить в договоры с юридическими лицами и ИП три защитных условия, которые полностью повторяют ограничения самого Яндекса:

 (Обратите внимание: если вы оказываете услуги обычным гражданам-потребителям для личных нужд, по п. 2 ст. 400 ГК РФ ограничивать ответственность ниже закона нельзя — такое условие суд признает недействительным).

Часть 3. Техническая защита, сбор доказательств для суда и страховка

1. Где физически лежат резервные копии: уроки октябрьского сбоя 2026 года 

Многие компании настраивали резервное копирование внутри одного облака Яндекса, считая, что разнесение копий по разным «зонам доступности» защитит от любой аварии.

Что показала практика октября 2026 года: 

В документации Яндекса регион ru-central1 включает четыре основные зоны доступности (ru-central1-a, ru-central1-b, ru-central1-d, ru-central1-e) и отдельную зону для аренды физических серверов целиком (ru-central1-m). Физически эти серверные площадки расположены во Владимире (мкр. Энергетик — зона ru-central1-a), Сасово Рязанской области (зона ru-central1-b), Калуге и Мытищах2. Удары в октябре 2026 года задели все эти зоны одну за другой:

• В ночь на 8 октября после пожара полностью остановился дата-центр в Сасово — отключилась зона ru-central1-b.

• Утром 9 октября была повреждена площадка в Калуге.

• Утром 11 октября из-за перебоев с питанием после атаки полностью встал дата-центр во Владимире (ru-central1-a). Две ключевые зоны (ru-central1-a и ru-central1-b) оказались недоступны одновременно, платформу перевели в аварийный режим, выдачу квот заморозили, и к 18:01 МСК сам Яндекс официально рекомендовал клиентам задействовать альтернативные площадки. 

Как избежать рисков потери данных в будущем ?

1. Не хранить основную базу и резервную копию у одного провайдера. Чтобы не потерять бизнес при остановке дата-центра, настройте ежедневную автоматическую выгрузку копий почты, Диска и баз данных из Яндекса на внешнюю площадку: на собственный сервер в офисе компании либо в облако другого независимого российского провайдера (например, Selectel или VK Cloud).

Идеальная стратегия бекапа «3-2-1-1» выглядит так:

3 — создавайте не менее трёх копий данных (рабочая версия и две резервные).

2 — храните эти копии как минимум на двух разных типах носителей (например, локальный диск и облачное хранилище, диск и лента).

1 — одна из копий должна находиться вне основной площадки (в другой локации или в облаке).

1 — одна из копий дополнительно изолируется от основной сети (air-gapped) или переводится в неизменяемое (immutable) состояние, что делает её недоступной для вредоносного ПО.

2. Географически разносить копии внутри РФ. Держите резервную копию в дата-центре другого региона России (например, Урал или Сибирь), чтобы авария в Центральном округе не затронула оба хранилища, но не выводите базы с персональными данными за рубеж, чтобы не получить штраф от 1 до 6 млн рублей за нарушение локализации по ст. 13.11 КоАП РФ.

3. Запретить удаление аккаунтов при увольнении. Ввести правило для сотрудников: никогда не удалять учетную запись уволенного сотрудника в Яндекс 360, пока вся его рабочая переписка и файлы с Диска не скопированы во внешний архив компании. 

2. Как зафиксировать доказательства для переговоров с контрагентами, суда или ФНС за 1 минуту без нотариуса

Во время сбоя 11 октября 2026 года у клиентов перестал работать даже встроенный сервис мониторинга Monium. 

Если кластеры недоступны, а папки на Диске пусты, в суде или налоговой инспекции нельзя просто на словах заявить об аварии — нужны юридически значимые доказательства. При этом традиционный поход к нотариусу за протоколом осмотра сайта (ст. 102, 103 Основ законодательства о нотариате) стоит десятки тысяч рублей и занимает много времени, за которое ошибки в консоли могут измениться, а сообщения в тикетах — пропасть.

Решение для бизнеса — автоматизированная фиксация через ShotApp:

1. Вместо ожидания нотариуса зафиксируйте личный кабинет через ShotApp. 

Сервис автоматизированной фиксации доказательств ShotApp входит в программный комплекс АС «Вебджастис» (резидент «Сколково», включен в реестр отечественного ПО). Протоколы сервиса соответствуют разъяснениям Верховного Суда РФ (п. 55 Постановления Пленума ВС РФ № 10 от 23.04.2019, п. 13 ПП ВС РФ от 22.06.2021 № 18 «О некоторых вопросах досудебного урегулирования споров, рассматриваемых в порядке гражданского и арбитражного судопроизводства», п.66 ПП ВС РФ от 15.11.2022 № 33 «О практике применения судами норм о компенсации морального вреда») и принимаются арбитражными судами и судами общей юрисдикции по всей России с 2016 года без участия нотариуса (более 1 млн судебных актов, включая дела № А47-15665/2024, № А17-589/2024, № А53-42422/2022, № А63-20899/2022).

2. Что именно фиксирует ShotApp 

Браузерное расширение для ПК и мобильное приложение записывают непрерывное видео экрана и делают заверенные скриншоты защищенных страниц с авторизацией (консоль Yandex Cloud, панель администратора Яндекс 360, Яндекс.Диск, раздел биллинга и тикеты техподдержки), автоматически прикладывая ссылку на исходную видеозапись со сроком хранения на защищенном сервере от 3 до 5 лет.

3. Протоколы ShotApp в судебной практике

Уже более десяти лет бизнесы успешно пользуются сервисом автоматизированной фиксации для представления доказательств в суд. Есть множество успешно выигранных споров, в которых ShotApp помог зафиксировать состояние данных в кабинетах, требующих авторизации (облачные хранилища, почтовые кабинеты, аккаунты в соцсетях и т. д.). Примеры: дело №А47-6384/2025, № А56-13207/2024, А08-8102/2024.

4. Внутренний акт и бухгалтерский баланс: 

Дополнительно в день аварии оформите внутренний Акт о техническом сбое за подписью трех сотрудников (ИТ-специалиста, главного бухгалтера и юриста), а сами ценные базы данных и программы учитывайте на балансе компании как нематериальные активы с точной оценкой стоимости.

3. Одностороннее изменение правил Яндексом (п. 1.3 ПС)

В пунктах 1.3 и 1.4 Пользовательского соглашения Яндекса (https://yandex.ru/legal/rules) указано: Яндекс может менять условия соглашения в одностороннем порядке без какого-либо специального уведомления клиента, новая редакция вступает в силу сразу в момент ее публикации в интернете, а пользователь сам несет риск того, что не прочитал обновленный текст5. Бизнес опасается, что в день крупной аварии провайдер просто перепишет оферту и задним числом снимет с себя ответственность.

Переписать правила «задним числом» под уже случившуюся аварию у провайдера не получится по двум основаниям: 

1. Действует только та редакция, которая была в силе в момент сбоя. 

Любые изменения договора работают только на будущее время. Как прямо подтверждает юридический разбор октябрьского сбоя 2026 года, к авариям 8–11 октября применяются строго те редакции, которые действовали в эти дни:
-Оферта и Общий SLA Yandex Cloud от 26 августа 2026 года (в силе с 7 сентября 2026 года),
-SLA Compute от 21 июля 2026 года (в силе с 1 августа 2026 года),
-Лицензионное соглашение Яндекс от 8 сентября 2026 года,
- Общие условия от 6 октября 2026 года.

2. Запрет на недобросовестное изменение договора. 

Даже если в договоре написано, что одна сторона может менять условия в одностороннем порядке (п. 2 ст. 310 ГК РФ), закон обязывает ее действовать разумно и добросовестно (п. 4 ст. 450, п. 4 ст. 450.1 ГК РФ). В пункте 14 Постановления Пленума Верховного Суда РФ от 22.11.2016 № 54, а также в п. 3 Информационного письма Президиума ВАС РФ от 13.09.2011 № 147 разъяснено: если сторона меняет договор в одностороннем порядке без объективных экономических причин, злоупотребляя своим правом (п. 2 ст. 10 ГК РФ), суд признает такое одностороннее изменение ничтожным, и для сторон продолжают действовать прежние условия договора.

Как технически отслеживать изменения оферт:

• Поручите ИТ-отделу включить бесплатный сервис автоматической проверки изменений веб-страниц для ключевых адресов: https://yandex.ru/legal/rules, https://yandex.ru/legal/disk_termsofuse и страниц оферт Яндекс 360 и Yandex Cloud, чтобы при замене даже одной строчки юристу приходило письмо с сохраненной PDF-копией текста.

• Используйте встроенный архив самого Яндекса: в самом низу каждой страницы правовых документов Яндекс всегда хранит прямые ссылки на все прошлые версии с точными датами их действия (например, https://yandex.ru/legal/rules/27082021), откуда нужную редакцию всегда можно открыть и заверить для суда.

Итоговый чек-лист: 6 шагов для защиты компании от утраты цифровых данных и вызванных этим последствий