План действий при обнаружении утечки персональных данных
Пошаговый сценарий на случай, когда данные уже утекли. Не описание процесса, а чек-лист с часами и фамилиями: что делается в первые минуты, что к концу первых суток и что к исходу третьих.
Зачем нужен документ
У утечки есть особенность, которая отличает её от всех остальных проблем с персональными данными: правильные действия нужны немедленно, а способность думать в этот момент минимальна. Люди в первые часы делают предсказуемые ошибки — перезаливают сервер, стирая следы вместе с уязвимостью; начинают с поиска виновного вместо остановки утечки; уходят в тишину, чтобы «не поднимать шум».
План существует, чтобы эти решения были приняты заранее, в спокойном состоянии. Он отвечает не на вопрос «как у нас устроено реагирование» — это задача регламента, — а на вопрос «что конкретно делает вот этот человек в ближайшие пятнадцать минут». Поэтому в нём фамилии, телефоны и часы, а не формулировки про ответственные подразделения.
Второе назначение — календарь внешних сроков. Двадцать четыре часа на первое уведомление и семьдесят два на результаты расследования идут от одного и того же момента выявления. План раскладывает эти сроки по внутренним контрольным точкам, чтобы к моменту подачи документы были готовы, а не писались в последний час.
Чем грозит отсутствие
За отсутствие плана не наказывают. Наказывают за последствия его отсутствия: пропущенные сроки уведомления и сама утечка, размер которой прямо зависит от того, как быстро её остановили.
Как ещё называют этот документ
Что должно быть в документе
План строится по времени, а не по разделам. Ниже — контрольные точки, которые в нём должны быть; часы указаны от момента обнаружения.
Требования законодательства
Как связан с другими документами
План — прикладная часть инцидентного кластера. Он опирается на роли из регламента и заканчивается двумя уведомлениями.
Когда обновлять документ
План стареет через контакты и системы: в нём больше конкретики, чем в любом другом документе комплекта, а значит и устаревает он быстрее.
Что спросит проверяющий
План проверяют по последнему реальному случаю: сравнивают, что написано, с тем, что происходило на самом деле.
Разбор эксперта
Порядок первых действий важнее их полноты. За годы разборов мы видели одну и ту же последовательность ошибок: сначала пытаются понять, кто виноват, потом спорят, «утечка ли это вообще», потом на всякий случай перезаливают сервер — и только к вечеру вспоминают про регулятора. К этому моменту потеряны и следы, и половина срока. Правильный порядок противоположный: зафиксировать время, остановить утечку, сохранить следы. Виновных найдёте потом, у вас на это есть двое суток.
Про перезаливку стоит сказать отдельно, потому что это самая дорогая техническая ошибка. Инстинкт администратора — быстро вернуть систему в рабочее состояние из резервной копии. После этого установить причину невозможно: журналы затёрты, следы доступа исчезли, уязвимость, скорее всего, вернулась вместе с копией. В отчёте за семьдесят два часа появляется «причины не установлены», а в глазах регулятора — организация, которая не управляет своей безопасностью.
И то, что почти всегда упускают: план должен работать в неудобное время. Утечки обнаруживаются вечером в пятницу и в новогодние праздники, потому что именно тогда за системами меньше следят. Если в плане один ответственный без заместителя и единственный способ принять решение — дозвониться руководителю, план не сработает. Проверяется это одним учебным прогоном в субботу — и почти всегда обнаруживает разрыв.
Сделайте план одностраничным чек-листом с часами, фамилиями и телефонами — его должно быть возможно прочитать целиком за минуту. Первыми тремя пунктами поставьте фиксацию времени, остановку утечки и сохранение следов, и явно запретите восстановление систем до снятия журналов. Укажите заместителей для каждой роли и один раз прогоните сценарий в нерабочее время: это единственная проверка, которая показывает реальную готовность.
Частые вопросы
Три действия подряд: письменно зафиксировать дату и точное время обнаружения, остановить утечку — закрыть доступ или изолировать сервис, сохранить следы, то есть выгрузить журналы и снять образы до любых восстановительных работ. Выяснение причин и поиск виновных идут после этого.
До снятия журналов — нельзя. Перезаливка затирает следы доступа, и установить причину к отчёту за 72 часа становится невозможно. Кроме того, копия часто возвращает ту же уязвимость, из-за которой всё случилось.
Отдельного требования иметь такой план в 152-ФЗ нет. Обязательны сроки уведомления регулятора и меры защиты, а план — способ их выполнить. Без него организации, как правило, не укладываются в 24 часа.
Регламент описывает постоянный процесс: роли, классификацию инцидентов, эскалацию. План — конкретный сценарий с таймлайном и фамилиями. На практике план прикладывают к регламенту приложением.
Прямой обязанности уведомлять субъектов при каждой утечке в 152-ФЗ нет, но в комплекте есть типовая форма такого уведомления. Информирование снижает вред людям и заметно улучшает позицию организации при разборе.
По перечню персональных данных: он показывает, какие категории и примерно сколько субъектов обрабатывается в каждой системе. Если перечня нет, оценка масштаба превращается в многочасовое расследование, которого в сутках попросту нет.
Срок уже идёт: закон считает инцидент выявленным, если его обнаружил оператор, регулятор или иное заинтересованное лицо. В этом случае план запускается с той же первой минуты, но времени остаётся меньше, поэтому мониторинг внешних источников имеет практический смысл.