GDPR Article 33: процедура уведомления об утечке ПДн за 72 часа

До 25 мая остаётся чуть больше месяца, и клиенты, которые разбирались с шифрованием и правовыми основаниями, теперь приходят с вопросом, который раньше откладывали на потом: «А что вообще делать, если всё-таки утечка?» Статья 33 GDPR - это 72 часа с момента обнаружения инцидента до уведомления надзорного органа. Статья 34 добавляет: если риск для субъектов высокий - уведомить ещё и самих людей, без лишних задержек. Вот как мы это формализуем.

Почему 72 часа - это мало

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

Инцидент обычно обнаруживает не тот, кто понимает что это значит с точки зрения GDPR. Это может быть дежурный sysadmin в пятницу вечером, разработчик, который нашёл подозрительный запрос в логах, или вообще сторонний исследователь, который написал на info@. Пока информация доходит до человека, способного оценить масштаб - уходит время. Дальше нужно разобраться, что именно утекло, данные каких субъектов затронуты, есть ли риск для их прав. Потом собрать достаточно фактов для уведомления. Потом написать само уведомление на языке, который примет надзорный орган. В отсутствие заранее написанной процедуры всё это легко занимает больше 72 часов - и нарушение возникает не из-за самой утечки, а из-за организационного хаоса вокруг неё.

Цепочка эскалации

Первое, что мы делаем для клиента, - это формализация цепочки: кто кому звонит, в каком порядке, с какой информацией.

Она выглядит примерно так:

Первый уровень - обнаружение. Любой сотрудник или система мониторинга фиксирует аномалию, которая может быть инцидентом с ПДн. Задача - не расследовать самому, а немедленно уведомить ответственного за ИБ. Это должно быть в должностных инструкциях явно, не «в случае подозрений обратитесь к руководству».

Второй уровень - первичная оценка. Ответственный за ИБ или DPO (там, где он есть) оценивает: действительно ли произошла утечка данных, какие категории ПДн затронуты, сколько субъектов. На это - не более нескольких часов. Даже предварительная оценка лучше, чем ожидание полной картины.

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

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

Шаблон уведомления регулятора

Статья 33 перечисляет, что должно быть в уведомлении:

• природа инцидента - что произошло, каким образом, какие системы затронуты;
• категории и примерное число субъектов - кто пострадал;
• категории и примерное число записей - что именно утекло;
• контакты DPO или точки контакта - к кому обращаться регулятору;
• вероятные последствия - оценка рисков для субъектов;
• меры, принятые или планируемые - что делается для устранения и минимизации ущерба.

Важный момент: уведомление можно подавать поэтапно, если вся информация сразу недоступна. Регламент прямо это допускает - статья 33(4). Это снимает ложную дилемму «либо ждём полной картины, либо уведомляем вслепую».

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

Само уведомление направляется в надзорный орган той страны ЕС, где находится «главная организация» (main establishment) оператора. Для российских компаний без европейского офиса это сложнее: скорее всего, уведомлять нужно орган той страны, где находятся затронутые субъекты, или где совершается обработка. Этот момент для каждого клиента уточняем индивидуально.

Коммуникации с субъектами данных

Статья 34 требует уведомить самих людей, если утечка «с высокой вероятностью повлечёт высокий риск» для их прав. Это не то же самое, что уведомление регулятора - здесь язык должен быть человеческим, не юридическим.

В плане коммуникаций фиксируем три вещи:

Первое - канал. Email, если есть; личный кабинет, если есть; push-уведомление в приложении, если есть. Нет универсального ответа - зависит от того, как организация обычно общается с пользователями. Главное - канал определён заранее, а не придумывается в момент инцидента.

Второе - содержание. Что произошло, какие данные затронуты, что субъект может сделать для защиты (сменить пароль, отозвать карту, мониторить кредитную историю - зависит от типа утечки), контакт для вопросов. Без корпоративного водолива про «мы высоко ценим вашу конфиденциальность».

Третье - исключения. Статья 34(3) допускает не уведомлять субъектов, если данные были зашифрованы стойким шифрованием, если последующие меры гарантировали что риск не реализуется, или если уведомление потребует несоразмерных усилий - тогда вместо этого публичное объявление. Каждое из оснований нужно уметь документально обосновать.

Где сейчас

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

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