Рекомендации по процедуре уничтожения персональных данных

Многие знают о существовании приказа РКН № 179¹ (Приказ), но немногие понимают, как его внедрить в свою практику. Приказ, с одной стороны, невероятно обременителен для бизнеса, а с другой – несет сомнительную пользу субъектам ПД.

Вместе с тем представители РКН не забывают напоминать² на публичных мероприятиях, что акт об уничтожении ПД должен регулярно составляться, и инспектор обязательно запросит его у вас при проведении большинства контрольных мероприятий – будь то внеплановая проверка из-за утечки ПД или запрос РКН по жалобе субъекта ПД. Невозможность продемонстрировать эти документы или их неверное составление могут повлечь ответственность по ст. 13.11 КоАП РФ, то есть штраф до 1,5 млн. руб.

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

Требования in brief, отчего так оно обременительно?

Во-первых, факт уничтожения необходимо подтверждать документально:

• актом об уничтожении ПД и
• для ИТ-систем дополнительно выгрузкой из журнала регистрации событий (логов уничтожения).

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

• Данные, определяющие конкретного субъекта, чьи ПД уничтожены. То есть, если вы уничтожаете массив данных, то должны быть определены все субъекты ПД – каждый!
• В случае уничтожения бумажного документа в акте должно быть его наименование с количеством листов.

Наконец, не облегчает жизнь операторам и не всегда понятные позиции РКН. Так, например, по мнению регулятора документы в архиве, содержащие ПД, после достижения цели обработки ПД должны уничтожаться по процедуре, установленной Приказом³. При этом про нераспространение Закона о ПД на архивное хранение РКН тоже неоднократно говорил⁴. В итоге остается непонятным, надо ли активировать и журналировать уничтожение документов, выводимых из архивного хранения, по требованиям Приказа. Тем временем мы уверены, что не надо!

Актировать или не актировать, вот в чем вопрос…

И правда, ключевой вопрос, а когда вообще надо выполнять требования Приказа. Без сомнений актировать уничтожение придется в случае соответствующего обращения / запроса субъекта или РКН. Но что делать с рутинным уничтожением данных, например, технических логов, содержащих ПД? Ведь именно такие «уничтожения» происходя ежедневно в любой компании, в отличие от разовых требований субъектов ПД.

Согласно самому Приказу его требования применяются только в случаях, предусмотренных ч. 7 ст. 21 Закона о ПД. То есть, в основном, это случаи:

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

Поэтому все же предлагаем подойти аккуратнее к определению триггеров для формального уничтожения ПД в вашей компании. Такими триггерами точно являются:

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

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

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

Журналирование?

Далее разбираемся с выгрузкой из журнала регистрации событий в ИТ-системе (в одной из первых редакций приказа именовавшейся «лог-файлом»). Логи – это набор текстовой информации обо всех событиях, происходящих в системе. Современные системы обычно и так журналируют действия пользователей или автоматики, включая как внесение, так и удаление информации.

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

Даже неспециалисту в информационных системах очевидно, что, скорее всего, логирование не будет работать так, как этого желает РКН.

Часть из этих полей вовсе сомнительна. Например, откуда системе знать причину уничтожения ПД, чтобы записать это в лог? А если мы уничтожили ФИО, какой смысл переписывать их в лог? О каком уничтожении может идти речь, если мы намеренно оставляем уникальные идентификаторы субъектов для выгрузки? Какая из систем будет писать собственное название в лог операций? А по каким правилам хранить такие ПД, если они как бы уничтожены (например, ограничить доступ только для DPO)? Пока вопросов больше, чем ответов.

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

Кроме этого, важно предусмотреть и в акте, и в выгрузке поле для одного и того же ID, чтобы их можно было соотнести, и продемонстрировать РКН эту связку (акту + журнал по конкретному субъекту ПД).

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

Регулярность составления актов уничтожения

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

Самое время вспомнить про процедуру блокировки ПД. Так, при невозможности уничтожения ПД оператор вправе их заблокировать на срок до 6 месяцев, а затем уничтожить (ч. 6 ст. 21 152-ФЗ). Условия «невозможности» в законе не указаны, а значит оператор ПД может рискнуть самостоятельно их определить. Причины такой «невозможности» могут быть разные. Например, специфика ИТ-инфраструктуры оператора, ограничивающая или исключающая регулярную процедуру уничтожения.

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

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

Блокирование перед уничтожением упрощает саму процедуру уничтожения ПД, но не является лазейкой для продления срока использования ПД бизнесом. Компания не может использовать ПД в течение этих 6 месяцев в своих целях. Процедура блокирования должна по-настоящему существовать и выполняться по определенным правилам. Например, ПД должны быть перенесены во временную базу с ограничениями доступа / обработки или иным образом ограничены в доступе и обработке и / или должен проставляться дополнительный признак запрета обработки, т.е. «блокировки».

Итого, наши рекомендации

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

Внедрение полноценного реестра процессов обработки ПД (RoPA). Уже наконец-то не формального комплаенса ради, но для выстраивания реальных процедур:

• На базе такого реестра будет формироваться корректный процесс уничтожения ПД. Убедитесь, что для этого RoPA содержит указание на сроки обработки и триггер для уничтожения каждого типа данных для каждой ИТ-системы и каждого типа материального носителя, метод уничтожения (мануальный или автоматический), и др.
• Разработана и внедрена процедура его актуализации.
• Для каждой ИТ-системы или процесса должен быть назначен владелец / администратор. Именно они выступят первой линией комплаенса как для актуализации RoPA, так и для контроля фактического уничтожения ПД.

Издание ЛНА, устанавливающих следующее:

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

Простые и понятные мануалы (в зависимости от культуры компании) для обеспечения рабочей процедуры уничтожения:

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

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

Настраивание логирования так, чтобы:

• Логи содержали минимальную информацию об атрибутах субъекта ПД (дата уничтожения и ID).
• Хранились на протяжении 3-х лет и после уничтожались.

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

___________________________________________

¹ Приказ РКН № 179 «Об утверждении Требований к подтверждению уничтожения ПД» от 28.10. 2022

² См. по ссылке

³ См. по ссылке

⁴ См. по ссылке