Утечка ПДн: что делать компании

В этой статье:

• Что считать утечкой ПДн
• Первые ошибки после инцидента
• Что сделать в первые часы
• Что проверить в первые дни
• Уведомление Роскомнадзора: что важно помнить
• Почему нельзя ограничиться только техническим закрытием
• Как навести порядок после инцидента

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

Даже небольшой бизнес может столкнуться с инцидентом: выгрузка клиентской базы ушла не тому адресату, подрядчик получил лишний доступ, на сайте оказалась открыта форма с заявками, сотрудник скачал данные перед увольнением, взломали почту или CRM. Это не всегда выглядит как “большая хакерская атака”, но последствия могут быть серьезными.

Что считать утечкой ПДн

В практическом смысле утечка ПДн - это ситуация, когда персональные данные случайно или неправомерно стали доступны не тем людям, были переданы, раскрыты, опубликованы, скачаны, скопированы или оказались в системе, где их не должно быть.

Персональные данные - это не только паспортные данные. Для бизнеса часто важны имя, телефон, email, адрес, заказ, должность, сведения о сотруднике, резюме кандидата, переписка с клиентом, данные из CRM, записи заявок и любые комбинации сведений, по которым можно определить человека.

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

Первые ошибки после инцидента

Самая опасная ошибка - сразу “зачистить следы”: удалить файлы, очистить логи, переустановить систему, закрыть доступы без фиксации исходного состояния. Так компания может потерять данные, которые нужны для понимания масштаба и причин инцидента.

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

Третья ошибка - обещать клиентам, сотрудникам или партнерам то, в чем компания еще не уверена. Лучше говорить аккуратно: факт выявлен, проводится проверка, принимаются меры. Сначала факты, потом выводы.

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

Что сделать в первые часы

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

Второе - ограничить последствия. Заблокировать подозрительные учетные записи, закрыть публичные ссылки, остановить лишние интеграции, временно ограничить выгрузки, отозвать токены и ключи, сменить пароли там, где это оправдано. Делать это лучше так, чтобы сохранить логи и доказательства.

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

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

Что проверить в первые дни

После срочных мер нужно разобраться в масштабе. Какие базы или файлы затронуты? Сколько записей могло быть раскрыто? Это данные клиентов, сотрудников, соискателей или контрагентов? Были ли специальные категории данных, платежные сведения, документы, логины, пароли, внутренние комментарии?

Дальше важно восстановить путь инцидента. Как именно данные стали доступны: через сайт, CRM, почту, облачную папку, подрядчика, учетную запись сотрудника, резервную копию, тестовую базу? Была ли ошибка разовой или это системная проблема в настройках?

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

Уведомление Роскомнадзора: что важно помнить

Если произошел инцидент в области персональных данных, оператору может потребоваться уведомить Роскомнадзор. По действующему порядку первичная информация направляется в течение 24 часов с момента выявления инцидента, а результаты внутреннего расследования - в течение 72 часов.

На практике это означает: не нужно ждать, пока компания узнает абсолютно всё. В первичном уведомлении фиксируют известные сведения и меры, которые уже приняты или планируются. После внутреннего расследования направляют дополнительную информацию.

Срок считается не с предполагаемой даты атаки или ошибки, а с момента выявления инцидента. Поэтому так важно сразу зафиксировать, когда и кем он был обнаружен. Если есть сомнения, попадает ли ситуация под обязательное уведомление, лучше быстро подключить специалиста по ПДн и ИБ, чтобы не потерять время.

Отправка уведомления - это не замена расследованию. Регулятору важно видеть, что компания не просто отреагировала формально, а действительно ограничивает последствия и разбирается в причинах.

Почему нельзя ограничиться только техническим закрытием

Техническая мера закрывает конкретную дыру: патч, отключение публичной ссылки, блокировка аккаунта, настройка прав. Но утечка часто показывает более глубокую проблему: нет владельцев систем, доступы выдаются без учета ролей, подрядчики работают по устным договоренностям, выгрузки никто не контролирует, документы по ПДн не соответствуют реальным процессам.

Если ограничиться только “мы закрыли доступ”, компания рискует повторить тот же сценарий в другом месте. Например, убрали открытую таблицу, но не запретили публичные ссылки; сменили пароль, но не включили двухфакторную аутентификацию; закрыли старый сайт, но оставили тестовую базу на сервере подрядчика.

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

Как навести порядок после инцидента

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

Затем стоит провести аудит систем, где обрабатываются персональные данные: сайт, CRM, почта, облачные хранилища, телефония, сервисы рассылок, HR-системы, бухгалтерия, архивы, резервные копии. Часто именно в старых или вспомогательных системах находятся неожиданные риски.

После этого обновляют процессы и документы: политику обработки персональных данных, перечень систем, матрицу доступов, договоры с подрядчиками, порядок реагирования на инциденты, инструкции для сотрудников. Документы должны описывать реальную работу, а не жить отдельно “для галочки”.

Отдельный шаг - обучение сотрудников. Не нужно превращать его в страшную лекцию. Достаточно объяснить, как передавать файлы, где нельзя хранить клиентские базы, как распознавать подозрительные письма, кому сообщать о случайной отправке данных и почему лучше признать ошибку сразу.

Утечка ПДн - это не только проверка на прочность, но и возможность привести в порядок то, что давно откладывали: доступы, сайт, CRM, облака, подрядчиков, регламенты и техническую защиту. Чем спокойнее и системнее компания действует, тем меньше риск повторного инцидента и тем проще объяснить свои действия клиентам, сотрудникам и регулятору.

FAQ (4– 6 вопросов и ответов)

Любой инцидент — это “утечка”?

В юридической логике ключевой критерий — факт неправомерной/случайной передачи или доступа к ПДн, повлекший нарушение прав субъектов. 

С какого момента считать 24 часа и 72 часа?

В законе указано “с момента выявления такого инцидента” (оператором, уполномоченным органом или иным заинтересованным лицом). Это значит: важно фиксировать время выявления и действия. 

Где подать уведомление об инциденте?

На портале уполномоченного органа есть специальная форма для направления информации об инциденте (утечке). 

Нужно ли сразу знать точное количество пострадавших?

Не всегда. В первые 24 часа обычно есть предварительная оценка, а уточнение приходит в ходе расследования (которое вы обязаны описать в срок до 72 часов). 

Почему после утечки часто “поднимают” доступы подрядчиков?

Потому что подрядчики часто имеют широкие доступы “на время проекта”, которые потом забывают отозвать. Закон определяет ответственность оператора и требования к поручению обработки. 

Чем мы можем помочь

• Если у вас сейчас инцидент или подозрение на инцидент — можем подключиться как ИТ/ИБкоманда: зафиксировать факты, ограничить последствия, помочь подготовить уведомление и пройти первые 72 часа без хаоса.
• После утечки почти всегда нужен “второй этап”: доступы, подрядчики, места хранения, регламенты. Можем провести аудит и собрать план доработок, чтобы ситуация не повторилась.
• Если хотите подготовиться заранее (лучший вариант) — можем помочь настроить базовый план реагирования: кто делает что, где лежат логи, какие контакты и шаблоны нужны.