Расследование ещё не закончилось, а компания уже объявила, что данные клиентов не пострадали. Через сутки специалисты находят следы выгрузки базы. Теперь бизнесу приходится объяснять не только взлом, но и собственное заявление. Первая проблема возникла из-за атаки, вторую компания создала сама.
Коммуникации при киберинциденте нужны не для того, чтобы представить случившееся в выгодном свете. Клиентам необходимо защитить свои аккаунты и понять, можно ли пользоваться сервисом. Сотрудникам нужны рабочие инструкции. Партнёрам приходится оценивать риски для собственных систем. Регуляторы ждут предусмотренные законом сведения. Хороший пресс-релиз не заменит ни одного из этих действий.
Разберём, как организовать такую работу, что сообщать до завершения расследования, какие обещания опасны и какие российские требования учитывать по состоянию на 16 сентября 2026 года.
Не смешивайте восстановление сервиса и безопасность данных
После атаки у компании могут одновременно возникнуть несколько разных проблем. Сервис недоступен, часть документов похищена, злоумышленники сохранили доступ к отдельным системам, а сотрудники не знают, каким сообщениям руководства доверять. Одно заявление «работа восстановлена» не отвечает на все вопросы.
Доступность сервиса и последствия для данных нужно описывать отдельно. Работающий сайт не доказывает, что похищенных копий нет. Отключённое приложение, наоборот, не подтверждает утечку. Иногда компания сама ограничивает доступ, чтобы остановить распространение атаки и провести проверку.
Поэтому полезнее сообщить, какие функции доступны, какие временно отключены и что установлено о доступе к информации. Фраза «ситуация под контролем» без таких подробностей почти ничего не объясняет.
Не стоит обещать и сохранение репутации благодаря правильной подаче. Длительный простой, потеря документов или раскрытие домашних адресов причиняют реальный вред. Коммуникации помогают уменьшить неопределённость и предотвратить дополнительные потери, но не отменяют последствия плохой защиты.
Сначала соберите факты, а не красивую версию
Первая рабочая задача для кризисной команды состоит в том, чтобы отделить подтверждённые сведения от предположений. Зафиксируйте время обнаружения, источник сигнала, затронутые системы, известные последствия и меры, которые специалисты уже выполнили. Рядом с каждым существенным утверждением должны стоять источник и время проверки.
Например, «личный кабинет недоступен» может быть установленным фактом. «Злоумышленники проникли через подрядчика» пока остаётся версией. «Данные клиентов похищены» требует собственных доказательств и не следует автоматически из первых двух утверждений.
Сообщение о продаже базы тоже нужно проверять. Скриншот, образец записей и громкое название компании не устанавливают ни происхождение информации, ни дату предполагаемой утечки. Но и объявлять публикацию подделкой до проверки нельзя. Разумная формулировка описывает текущую работу, а не желаемый результат.
Отдельно фиксируйте пробелы. Если журналы событий сохранились не полностью, отсутствие записей о выгрузке не позволяет уверенно исключить копирование данных. Пресс-служба должна понимать такую разницу до выхода первого комментария.
Британский NCSC в рекомендациях по кризисным коммуникациям прямо предостерегает от преждевременных заверений, которые придётся отзывать после дальнейшего расследования. Осторожность здесь нужна не ради юридического тумана, а ради точности.
Назначьте ответственных и сократите согласования
Киберинцидент нельзя полностью передать пресс-службе. Руководитель реагирования координирует действия, специалисты по безопасности подтверждают технические факты, владельцы сервисов оценивают последствия для клиентов, юристы проверяют обязательства, а коммуникационная команда переводит сведения на понятный язык. Поддержка и кадровая служба доводят согласованные инструкции до своих аудиторий.
У каждого направления нужен заместитель. Если публикация зависит от единственного директора, который находится в самолёте, проблема заложена в самом процессе. Заранее определите, кто вправе выпустить первичное сообщение и какие формулировки можно использовать без многоступенчатого согласования.
Единый центр коммуникаций не означает, что на все вопросы отвечает один человек. Клиентам может отвечать поддержка, партнёрам менеджеры, журналистам официальный спикер. Все представители компании должны пользоваться одной актуальной сводкой фактов, а не пересказывать разговоры из внутренних чатов.
Сохраняйте версии заявлений и решения об их выпуске. Такая история помогает установить, что компания знала в конкретный момент, почему изменила оценку и какие сведения послужили основанием для публичных обещаний.
Первое сообщение должно помогать, а не успокаивать любой ценой
Универсального правила «выпустить заявление через два часа» нет. Срочность зависит от последствий. Если пользователи не могут получить услугу или должны немедленно защитить аккаунты, сообщение нужно готовить без ожидания полного отчёта. Если специалисты заблокировали отдельную попытку входа без заметных последствий, публичная кампания может вообще не понадобиться.
При этом отсчёт нельзя привязывать только к появлению новости в СМИ. Компания должна оценивать необходимость уведомлений с момента выявления проблемы, а не с момента, когда скрывать проблему стало неудобно.
Первое публичное сообщение должно объяснять, что известно, как инцидент влияет на людей, что компания уже сделала и когда появится следующая информация. Необязательно сразу называть способ проникновения, предполагаемую группировку и окончательное число пострадавших.
Ниже условный пример для ситуации, когда обнаружен посторонний доступ, а часть функций отключена для проверки. Каждое утверждение перед публикацией необходимо подтвердить.
Сегодня утром мы обнаружили несанкционированный доступ к части инфраструктуры и временно отключили личный кабинет. Оформление новых заказов недоступно. Поддержка продолжает принимать обращения по действующим заказам.
Специалисты ограничили доступ к затронутым системам и проверяют, какие сведения могли оказаться у посторонних. Пока масштаб инцидента не установлен. Следующее обновление опубликуем сегодня до 18.00 по московскому времени, даже если проверка ещё будет продолжаться.
В реальном сообщении добавьте проверенный адрес страницы обновлений и работающий способ связи. Не отправляйте людей в недоступный личный кабинет или на телефонную линию, которая фактически перестала принимать звонки.
Извинение уместно, но не должно вытеснять полезную информацию. После слов «приносим извинения» читателю всё равно нужно понять, что делать с зависшим платежом, сорванной доставкой или возможным доступом к аккаунту.
Говорите о неизвестном прямо
Самые опасные формулировки обычно звучат уверенно. «Утечки не было». «Затронуты только общедоступные сведения». «Угроза полностью устранена». Каждое такое утверждение требует оснований, которые в начале расследования могут отсутствовать.
Не подменяйте отсутствие подтверждения подтверждённым отсутствием. Вместо «данные не пострадали» иногда точнее написать, что проверка доступа к данным продолжается и компания пока не может назвать затронутые категории. Фраза неприятная, зато не создаёт ложного чувства безопасности.
Если оценка изменилась, объясните причину. Например, специалисты проверили дополнительный сервер, получили журналы от подрядчика или завершили поиск повторяющихся записей. Число строк в файле и число пострадавших людей могут различаться. Не превращайте предварительный объём выгрузки в окончательное число клиентов без проверки.
Исправления публикуйте заметно, с датой и пояснением. Незаметная замена старой версии лишает аудиторию возможности понять, какие сведения актуальны. Компания вправе уточнять выводы по мере расследования, но должна показывать, где именно выводы изменились.
Не объявляйте виновного раньше, чем появились достаточные доказательства. Даже подтверждённый доступ через систему подрядчика не отвечает автоматически на вопросы об ответственности сторон. Для клиента важнее получить защиту и помощь, чем наблюдать публичный спор компаний.
Отделите публичные заявления от обязательных уведомлений
Пресс-релиз, письмо клиенту и сообщение регулятору решают разные задачи. Публикация на сайте не заменяет установленную форму уведомления. Отправка формы регулятору, в свою очередь, не сообщает пользователю, как защититься от последствий.
Применимые обязанности зависят от статуса организации, затронутых систем, характера инцидента и договоров. Ниже приведены основные ориентиры, а не исчерпывающий перечень требований для любой компании.
Персональные данные и Роскомнадзор
Часть 3.1 статьи 21 закона № 152-ФЗ устанавливает два срока для случаев неправомерной или случайной передачи персональных данных, включая предоставление доступа, если нарушены права субъектов персональных данных.
В течение 24 часов оператор направляет сведения об инциденте, предполагаемых причинах и вреде, принятых мерах, а также указывает ответственное за взаимодействие лицо. В течение 72 часов сообщает о результатах внутреннего расследования и, при наличии, о лицах, действия которых стали причиной инцидента.
Оба срока отсчитываются от выявления соответствующего инцидента, а не последовательно. Закон не предоставляет сначала сутки на первичное уведомление, а затем ещё трое суток на второе. В норме прямо упомянуто выявление оператором, Роскомнадзором или иным заинтересованным лицом.
Нельзя откладывать первое уведомление до завершения всей технической экспертизы. Сам закон предусматривает передачу предполагаемых причин и предполагаемого вреда. Подтверждённые сведения и предварительные оценки следует различать и в документах для регулятора.
Критическая информационная инфраструктура
Для субъектов КИИ действует приказ № 547 ФСБ России от 25 декабря 2025 года. Сведения о компьютерном инциденте на значимом объекте КИИ направляют в НКЦКИ не позднее трёх часов с момента обнаружения. Для иных объектов КИИ установлен срок не позднее 24 часов. Информацию о компьютерной атаке на объект КИИ также направляют не позднее 24 часов с момента её обнаружения.
Поэтому формула «все субъекты КИИ сообщают обо всём за три часа» неточна. В плане должны быть отдельно описаны тип события, статус объекта, адресат и срок.
Государственные информационные системы
С 1 сентября 2026 года действует приказ № 297 ФСБ России от 6 августа 2026 года. Документ регулирует взаимодействие с ГосСОПКА операторов государственных информационных систем, а также иных информационных систем государственных органов, государственных унитарных предприятий и государственных учреждений. Для направления сведений о компьютерных инцидентах в НКЦКИ установлен срок не позднее 24 часов с момента обнаружения.
Организациям из перечисленных категорий недостаточно ориентироваться только на правила уведомления об утечках персональных данных. Несколько обязанностей могут возникнуть одновременно.
Финансовые организации
Универсальный совет «уведомить ФинЦЕРТ до конца следующего рабочего дня» использовать нельзя. В частности, пункт 4 приказа № 547 требует дополнительно направлять в Банк России сведения об атаках и инцидентах на объектах КИИ организаций банковской сферы и иных сфер финансового рынка в сроки, установленные пунктом 3 того же порядка.
Для остальных отраслевых уведомлений нужно отдельно проверять применимые акты Банка России и действующие требования к информационному обмену. Ответственный сотрудник должен заранее знать не только срок, но и рабочий канал отправки, резервный способ связи и порядок подтверждения приёма.
Ответственность за неуведомление
С 30 мая 2025 года непредставление или несвоевременное представление обязательного уведомления об инциденте с персональными данными образует отдельный состав по части 11 статьи 13.11 КоАП РФ. Для коммерческой организации предусмотрен штраф от 1 до 3 млн рублей. Ответственность за саму утечку установлена отдельно. В предусмотренных законом случаях повторных нарушений применяются оборотные штрафы с верхним пределом 500 млн рублей.
Практический вывод не сводится к необходимости «быть открытыми». Нужна таблица обязательств с основаниями, адресатами, сроками и ответственными. Добавьте требования договоров с заказчиками и страховщиками, а при международной деятельности проверьте обязанности в других юрисдикциях. Согласование публичного комментария не должно задерживать обязательное уведомление.
Обновляйте сведения по обещанному графику
Одного заявления недостаточно, если последствия продолжают меняться. Но публиковать одинаковый текст каждые четыре часа только ради частоты тоже бессмысленно. Выбирайте график с учётом потребностей аудитории и возможности команды давать проверенные сведения.
При массовой недоступности сервиса обновления могут понадобиться несколько раз в день. При длительном расследовании полезнее регулярно сообщать о завершённых этапах и новых выводах. Если обнаружен новый риск для пользователей, не ждите очередного планового сообщения.
Обещанное время следующего обновления должно означать время публикации, а не обещание закончить восстановление. Когда срок запуска ещё неизвестен, лучше назвать этап, который проходит команда, и объяснить, что мешает дать надёжный прогноз.
Например, условное обновление может выглядеть так.
Личный кабинет снова доступен для просмотра заказов. Оформление новых заказов остаётся отключённым, специалисты проверяют обработку платежей. Ранее созданные заказы повторно оформлять не нужно. Следующее сообщение о доступности функций опубликуем завтра до 10.00 по московскому времени.
Такой текст полезнее заявления о восстановлении «большей части инфраструктуры». Клиент покупает услугу, а не процент работающих серверов.
Разным аудиториям нужны разные ответы
Клиентам сообщайте, какие услуги доступны, затронуты ли сведения конкретного человека, какие действия требуются и где получить помощь. Когда возможно, отправляйте адресные уведомления пострадавшим, а не заставляйте всех пользователей самостоятельно искать себя в новостях.
Сотрудникам нужны инструкции о рабочих устройствах, доступе к системам, подозрительных сообщениях и резервных каналах связи. Запрет комментировать инцидент журналистам не заменяет объяснения, как продолжать работу и куда сообщать о новых признаках атаки.
Партнёрам важны последствия для интеграций, обмена документами, поставок и выданных доступов. Предупреждение о необходимости отключить конкретное подключение может быть гораздо срочнее общего публичного заявления.
Журналистам предоставьте доступного представителя компании и согласованную сводку. Не требуйте от редакции ждать окончательного расследования, если сервис уже недоступен тысячам людей. Короткий ответ с подтверждёнными фактами полезнее обещания большого комментария без срока.
Содержание сообщений может различаться по деталям, но не по сути. Нельзя уверять клиентов в отсутствии риска, одновременно предупреждая партнёров о подтверждённом постороннем доступе к тем же данным.
Не превратите коммуникации в продолжение атаки
Обычные каналы связи могут оказаться недоступными или скомпрометированными. Если злоумышленник получил доступ к корпоративной почте, обсуждать через неё смену паролей и восстановление инфраструктуры опасно. Резервную связь следует подготовить заранее, а не выбирать в разгар инцидента.
Проверьте, сможет ли команда опубликовать обновление без корпоративной системы входа. Сохраните контакты ответственных вне потенциально затронутой сети. Убедитесь, что резервная страница статуса не зависит от тех же систем, которые может отключить атака. Такие меры дополняют план реагирования, а не заменяют техническую защиту.
Публичная прозрачность не требует раскрывать пароли, внутренние адреса, подробности ещё не закрытых уязвимостей или действия, которые помогут атакующему сохранить доступ. Регулятору и расследующей команде могут понадобиться сведения, которым не место в открытом пресс-релизе.
Не пересылайте полную похищенную базу пресс-службе, редакциям или подрядчикам ради подтверждения масштаба. Не загружайте журналы событий и персональные данные в неразрешённые внешние сервисы, включая чат-ботов. Для коммуникационной работы обычно нужны проверенные выводы и обезличенные примеры, а не дополнительные копии чувствительной информации.
Предусмотрите и защиту самих уведомлений. Объясните, где публикуются официальные инструкции, и не просите пользователя сообщить пароль, код из сообщения или перевести деньги ради «сохранения аккаунта». Страница проверки пострадавших тоже не должна превращаться в инструмент перебора чужих данных.
Помощь должна соответствовать последствиям
Совет «смените пароль» подходит не для любой утечки. Если раскрыты адрес доставки и телефон, новый пароль не уберёт опубликованный адрес. Если посторонние получили данные для входа, одного предупреждения о мошенниках может быть недостаточно.
Поэтому сначала установите, какие сведения затронуты, а затем подготовьте конкретные действия. При риске захвата аккаунтов объясните, как восстановить доступ и какие защитные меры компания уже применила. При раскрытии контактных данных предупредите о возможных звонках и письмах от имени поддержки. При финансовых последствиях помогите клиенту разобраться с оспариваемыми операциями и обращениями в обслуживающую организацию.
Американская FTC в руководстве для бизнеса рекомендует связывать уведомление пострадавших с характером похищенной информации и возможностью уменьшить вред. Для российской компании полезен сам принцип, а конкретные услуги и правовые процедуры нужно выбирать под свою аудиторию.
Поддержка должна уметь отвечать на вопросы об инциденте, а не только повторять извинения. Подготовьте актуальные ответы, порядок передачи сложных обращений и защищённый способ проверки личности. Не требуйте от пострадавшего присылать лишние документы туда, где безопасность ещё не подтверждена.
Если предлагаете компенсацию, опишите условия, сроки и способ получения. Промокод с обязательной новой покупкой не стоит выдавать за полноценную помощь человеку, который потерял деньги или контроль над личной информацией.
Что показывают реальные инциденты
Norsk Hydro говорила о последствиях, не дожидаясь полной картины
19 марта 2019 года Norsk Hydro сообщила о масштабной кибератаке, перечислила состояние производственных направлений и объяснила переход части операций на ручные процедуры. Компания прямо указала, что ещё не знает полного масштаба, финансовых последствий и сроков решения проблемы, а также объявила время пресс-конференции.
Полезен не ярлык «образцовый PR», а конкретный приём. Сообщение одновременно содержало подтверждённые последствия, уже принятые меры и границы знания. Признание неопределённости не помешало компании дать аудитории полезную информацию.
Equifax нельзя объяснить только плохими заявлениями
Утечка Equifax 2017 года затронула приблизительно 147 млн человек. В 2019 году компания согласилась на урегулирование с американскими регуляторами и штатами на сумму не менее 575 млн долларов, потенциально до 700 млн. FTC в материалах дела описала претензии к обновлению систем, сегментации сети и другим мерам защиты.
Приписывать весь ущерб неудачной коммуникации неверно. Публичные заявления не исправляют пропущенное обновление и не возвращают похищенные сведения. Кризисный план должен соединять коммуникации с реальными мерами защиты, а не обещать заменить одно другим.
Британская библиотека объяснила, почему восстановление затянулось
После атаки октября 2023 года Британская библиотека в марте 2024 года опубликовала разбор инцидента. В апреле 2025 года британский регулятор ICO положительно оценил открытость библиотеки в вопросах уязвимостей, последствий атаки и принятых улучшений.
Такой подход показывает ценность содержательного отчёта после острой фазы. Пользователям полезно понимать причины длительных ограничений и реальные изменения. Но положительная оценка отдельного регулятора не означает, что публичный отчёт автоматически освобождает организацию от ответственности.
Проверьте готовность до следующего инцидента
План, который никто не пробовал выполнить, может оказаться набором правильных слов. Проверять нужно не только наличие документа, но и возможность быстро связаться, подтвердить факты, отправить уведомление и опубликовать сообщение.
- Назначьте руководителя реагирования, ответственных за сообщения и заместителей. Зафиксируйте, кто вправе принимать срочные решения.
- Составьте перечень обязательных уведомлений с основаниями, сроками, каналами отправки и порядком подтверждения приёма.
- Подготовьте резервную связь, доступную страницу обновлений и контакты, которые сохранятся при отключении корпоративных систем.
- Согласуйте основу сообщений для утечки данных, длительного простоя и пока не подтверждённого сообщения о взломе. Подготовьте отдельные инструкции для поддержки и сотрудников.
- Проведите учение с неудобными условиями, например недоступной почтой, отсутствующим руководителем и необходимостью исправить уже опубликованную оценку. По итогам измените процедуры.
Периодичность учений определяйте с учётом рисков и обязательных требований для своей организации. После смены ответственных, перестройки инфраструктуры или изменения законодательства план нужно пересматривать, не дожидаясь очередной календарной даты.
Заканчивайте кризис фактами, а не торжественным заявлением
Возвращение сервиса в работу ещё не означает, что все последствия устранены. Могут продолжаться проверка состава похищенных данных, помощь пострадавшим, работа с регуляторами и устранение причин проникновения. Разделяйте завершённые задачи и открытые вопросы.
Итоговое сообщение должно объяснять установленный масштаб, последствия для пользователей, выполненные меры и оставшиеся ограничения. Если причина пока не определена, не заполняйте пробел удобной версией. Если появились новые сведения о пострадавших, продолжайте адресные уведомления.
Вместо общего обещания «мы усилили безопасность» расскажите о проверяемых изменениях в допустимом объёме. Например, пересмотрели доступ подрядчиков, закрыли конкретный класс ошибок, проверили восстановление из резервных копий или изменили порядок контроля обновлений. Не раскрывайте при этом детали, которые упростят новую атаку.
Оценивать коммуникации полезнее по практическому результату. Получили ли пострадавшие инструкции. Смогла ли поддержка решить обращения. Выполнила ли компания обещанный график. Соблюдены ли сроки уведомлений. Сколько публичных утверждений пришлось исправить и почему.
Доверие не возвращается после фразы «инцидент исчерпан». Доверие появляется, когда компания перестаёт обещать больше, чем знает, помогает пострадавшим и выполняет сказанное. Во время киберинцидента такая дисциплина полезнее любого убедительного пресс-релиза.
