Как сообщить клиентам о кибератаке: инструкция для бизнеса

«Чистые алгоритмы и надёжные протоколы не помогают, когда приходится говорить с людьми. Коммуникация при инциденте, это не протокол восстановления, а протокол доверия. Здесь нет тильды, зато есть паника, слухи и юридические последствия. Ошибка в тексте письма обходится дороже, чем ошибка в конфигурации файрвола.»

Когда нужно говорить, а когда молчать

Первый и самый трудный вопрос: сообщать клиентам вообще или нет. Решение зависит не от степени вашего испуга, а от характера данных и масштаба воздействия. Если атака затронула персональные данные клиентов — ФИО, паспорта, телефоны, почту, платежные реквизиты — молчать уже не получится. 152-ФЗ обязывает оператора персональных данных уведомлять Роскомнадзор и субъектов данных о произошедшем нарушении. Задержка или сокрытие, это штрафы и репутационный урон, который потом не исправить.

Но если атака была на внутренние сервисы, не затронула клиентскую зону, и вы быстро локализовали угрозу, формальных оснований для массового уведомления может и не быть. В этом случае ключевое — оценка рисков. Даже косвенное воздействие, например, DDoS на ваш сайт, который привел к недоступности личного кабинета, уже причина для короткого техуведомления. Молчание в эпоху мониторинговых сервисов вроде Downdetector или публичных отчетов CERT, это гарантия, что клиенты узнают об инциденте из третьих рук, в самой неприглядной форме.

Создание единого голоса: кто и что говорит

Перед первым публичным заявлением должен быть сформирован штаб. В него входят:

Технический директор или руководитель ИБ — для фактов: что произошло, какую систему задело, какие меры приняты.
Юрист — для оценки регуляторных последствий и формулировок, которые не создадут лишних обязательств.
PR-специалист или руководитель коммерции — для тона и каналов коммуникации.
Представитель первого лица компании — для итогового решения и финального утверждения сообщений.

Этот штаб должен выпустить внутренний меморандум — единую версию событий для всех сотрудников. Никаких «технических подробностей» в корпоративном чате от сисадминов. Любая утечка внутренней переписки с паникой или неверными оценками станет доказательством халатности для регулятора и основой для медийного скандала.

Что входит в «единую версию»

Это не детальный отчёт для ФСТЭК, а скелет для всех будущих сообщений:

Факт: Да, мы обнаружили несанкционированную активность.
Объём: Под угрозой оказались [конкретные системы, например, база данных клиентов личного кабинета]. Другие сервисы не затронуты.
Действия: Мы изолировали систему, начали расследование, привлекли внешних экспертов (если это так).
Статус: Угроза локализована. Работа над восстановлением ведётся.
Что клиентам делать сейчас: Рекомендуем сменить пароль, включить двухфакторную аутентификацию, быть внимательны к фишингу.
Что клиентам делать не нужно: Не паниковать, не переводить деньги по звонкам «из службы безопасности банка».

Каналы коммуникации: иерархия доверия

Порядок и способ сообщения так же важны, как и текст.

Личный кабинет / email на привязанный адрес. Первый и главный канал для затронутых клиентов. Письмо должно приходить с официального, узнаваемого адреса (например, security@ваша-компания.ру). Тема — чёткая, без сенсационности: «Важная информация о безопасности вашего аккаунта».
Официальный сайт, раздел «Новости» или «Безопасность». Публичное заявление размещается одновременно или сразу после рассылки. Это создаёт точку достоверности, куда будут ссылаться СМИ и клиенты.
Социальные сети и мессенджеры. Здесь — короткая, сухая выдержка из основного заявления с ссылкой на полную версию на сайте. Задача — перехватить панические обсуждения и направить их в официальное русло. Обязательно модерировать комментарии, давать однотипные ответы по заранее заготовленному шаблону.
Телефонная поддержка. Скрипт для операторов должен быть готов до публикации новости. Операторы не дают оценок, не обсуждают детали, а лишь констатируют факт наличия официального заявления и направляют к нему.

Текст сообщения: между холодными фактами и человеческим пониманием

Сообщение об инциденте, это не пресс-релиз о запуске нового продукта. Здесь действуют свои правила.

Без извинений за «временные неудобства». Фраза звучит фальшиво и обесценивает проблему. Вместо этого — прямое признание: «Мы столкнулись с кибератакой, которая затронула часть наших систем».
Без технического жаргона. «Обнаружена эксплуатация уязвимости нулевого дня в модуле аутентификации» — так писать нельзя. «Злоумышленники получили возможность войти в систему без пароля» — так уже ближе.
С указанием временных рамок: «Инцидент произошёл 15 октября между 14:00 и 18:00 по московскому времени. Мы обнаружили его в 19:30 и сразу приступили к реагированию».
С фокусом на действиях, а не на угрозе. Не расписывайте мощь и изощрённость хакеров. Опишите, что сделали вы: «Мы отключили затронутые серверы от сети, запустили анализ логов, развернули резервные копии на чистой инфраструктуре».
С чёткими инструкциями для клиента. Не просто «будьте бдительны», а конкретика: «Пожалуйста, перейдите по ссылке и смените пароль. Рекомендуем использовать комбинацию из не менее 12 символов. Внимание: мы никогда не звоним с просьбой сообщить код из SMS».

Что делать после первого сообщения

Типичная ошибка — бросить один пост и уйти в техническое расследование на неделю. В вакууме информации моментально рождаются слухи. Нужен план последующих сообщений.

Обновление №1 (через 6–12 часов): «Расследование продолжается. Мы подтверждаем, что утечка данных не вышла за рамки, указанные в первом сообщении. Работа по восстановлению сервисов идёт по графику».
Обновление №2 (через 24 часа): «Основные сервисы восстановлены. Мы проводим дополнительную проверку безопасности всех систем. Приносим искренние извинения за доставленные неудобства» (извинения уместны здесь, когда видна работа).
Итоговый отчёт (через 1–2 недели). Когда расследование закончено и все риски минимизированы, можно выпустить развёрнутый, но всё ещё доступный отчёт. Что это даёт: показывает прозрачность, демонстрирует контроль над ситуацией и становится финальной точкой в медийной истории. В нём можно чуть больше деталей: тип атаки (например, фишинг сотрудника), но без имён и конкретных IP-адресов.

Работа с последствиями: от жалоб до регуляторов

После уведомления начнут поступать вопросы, гневные письма и, возможно, претензии. Нужно быть готовым.

Подготовьте шаблоны ответов на частые вопросы: «Мои данные продали?», «Мне теперь менять паспорт?», «Кто будет компенсировать моральный ущерб?». Ответы должны быть вежливыми, но не создавать новых юридических фактов. Не пишите «вашим данным ничего не угрожает», если это нельзя гарантировать. Лучше: «Мы предприняли все меры для защиты данных и не видим признаков их дальнейшего распространения».
Ведите лог всех обращений. Это понадобится для отчёта перед Роскомнадзором, который может запросить информацию о количестве уведомлённых субъектов и полученных от них обращениях.
Не вступайте в публичные споры с особенно агрессивными клиентами в соцсетях. Один уничижительный ответ от лица компании может перечеркнуть всю работу по восстановлению доверия. Стандартная фраза: «Мы понимаем ваше беспокойство. Все детали изложены в официальном заявлении по ссылке. По персональным вопросам просим писать на security@…».

Как не надо делать: классические ошибки

Замалчивание до последнего, пока информация не всплывёт сама. Это путь к катастрофе доверия.
Панический тон или, наоборот, неуместный оптимизм. «Всё ужасно, мы все умрём» или «Пустяк, небольшие технеполадки» — оба варианта убивают доверие.
Перекладывание ответственности. «Виноват хостинг-провайдер» или «Это атака иностранных спецслужб» звучит как попытка оправдаться. Фокус должен оставаться на ваших действиях.
Отсутствие конкретных инструкций для людей. Люди в стрессе не знают, что делать. Если им не дать простой алгоритм действий (сменить пароль, проверить счета), их паника будет только нарастать.
Нарушение собственных дедлайнов по обновлениям. Если обещали сообщить новости к вечеру — сообщите, даже если новостей нет. Молчание в назначенный час воспринимается как усугубление проблемы.

Коммуникация при кибератаке, это управление хаосом. Вы не можете контролировать действия злоумышленников, но можете контролировать нарратив вокруг инцидента. Чёткость, последовательность и человечность в сообщениях не исправят уязвимость в коде, но сохранят то, что зачастую ценнее данных — репутацию и доверие клиентов. В конечном счёте, именно это определяет, переживёт ли компания инцидент или начнёт необратимо терять почву под ногами.