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

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

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

Что считается утечкой персональных данных

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

Нарушения обычно связаны с одним или несколькими последствиями:

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

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

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

Что должна сделать компания после обнаружения инцидента

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

Зафиксировать обстоятельства обнаружения

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

Ограничить распространение инцидента

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

Определить объем затронутых данных

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

Установить роль компании

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

Оценить риск и зафиксировать решение

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

С какого момента рассчитываются 72 часа

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

Если обработку выполняет внешний подрядчик, он сообщает контролеру об утечке без неоправданной задержки. Для обработчика GDPR не устанавливает отдельный срок в 72 часа. Конкретный период обычно закрепляется в DPA, поскольку контролеру нужно успеть провести собственную оценку.
Отсутствие всех деталей не позволяет откладывать сообщение до завершения расследования. GDPR допускает поэтапное предоставление информации. В первоначальном уведомлении можно указать доступные сведения, а затем направить дополнения. При пропуске срока контролер должен объяснить причину задержки.

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

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

Оценка последствий Уведомление регулятора Уведомление пользователей Что должна сделать компания
Риск для людей маловероятен Не требуется Не требуется Зафиксировать инцидент, оценку риска и принятые меры во внутреннем реестре
Существует вероятность риска Требуется в течение 72 часов, когда это возможно Обычно не требуется Сообщить регулятору и продолжить расследование
Вероятен высокий риск Требуется в течение 72 часов, когда это возможно Требуется без неоправданной задержки Уведомить регулятора и людей, предоставив рекомендации по защите

 

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

Как оценить риск для субъектов данных

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

При оценке учитываются:

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

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

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

Что включить в уведомление надзорному органу

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

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

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

Когда нужно уведомлять пользователей

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

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

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

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

Нужно ли документировать инцидент без уведомления

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

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

Типичные ошибки при реагировании на утечку

Компании часто начинают отсчитывать 72 часа после завершения внутреннего расследования. Такой подход может привести к просрочке, поскольку срок связан с моментом получения разумной уверенности в наличии нарушения.

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

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

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

Как подготовиться к утечке заранее

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

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

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

Чем может помочь Wolja Digital

Wolja Digital помогает IT-компаниям подготовить процедуру реагирования на утечки, распределить ответственность между командами и согласовать договорные условия с обработчиками.

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

Казахстан для IT-бизнеса: Astana Hub и AIFC — в чем разница
03 апр 2026
Подробнее
Как выбрать страну для регистрации IT-компании в 2026 году
03 авг 2026
Подробнее
Удаление данных по GDPR в SaaS: что делать с резервными копиями, логами и данными у подрядчиков
18 сен 2026
Подробнее