Утечка персональных данных у подрядчика: действия компании в первые 72 часа

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

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

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

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

Именно эта карта ролей определит последующие уведомления, коммуникацию и распределение расходов.

Часть 3.1 статьи 21 закона № 152-ФЗ предусматривает уведомления уполномоченного органа при установленном факте неправомерной или случайной передачи, предоставления, распространения либо доступа к персональным данным, повлекшем нарушение прав субъектов. Закон предусматривает первоначальное уведомление в течение 24 часов и представление результатов внутреннего расследования в течение 72 часов с момента выявления соответствующего инцидента. Это не универсальное правило для любой технической ошибки без установленных условий нормы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Размер ответственности и административные составы зависят от характера нарушений и редакции закона на дату события. Судебная и административная практика меняется, поэтому сумму потенциальных потерь оценивайте отдельно, а не указывайте универсальный штраф в типовом алгоритме.