Права субъектов персональных данных: как обрабатывать запросы на доступ, исправление и удаление и укладываться в сроки

Субъект нажал «хочу удалить мои данные» — у вашей компании есть 30 дней. Вы готовы?

Зачем это важно и кому полезна статья

Когда в 2022 году в 152-ФЗ были внесены существенные поправки через принятие Федерального закона № 266-ФЗ [1, 5], многие компании восприняли их как очередную административную нагрузку. Однако за последние два года правоприменительная практика изменилась радикально: Роскомнадзор перешёл от предупреждений к реальным штрафам, субъекты ПДн стали активнее использовать свои права, а резонансные утечки данных обострили общественное внимание к теме.

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

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

Что изменилось: краткая история реформы прав субъектов в России

От 152-ФЗ 2006 года к поправкам 266-ФЗ 2022 года

Базовый Федеральный закон № 152-ФЗ «О персональных данных» был принят в 2006 году [1]. С тех пор он существенно менялся несколько раз, но ключевым водоразделом стал 2022 год: Федеральный закон № 266-ФЗ от 14 июля 2022 года [5] существенно расширил права субъектов и ужесточил требования к операторам.

До 2022 года формулировки закона были достаточно размытыми: субъект имел право обратиться к оператору, но механизм, сроки и ответственность оставались слабо детализированными. Именно 266-ФЗ [5]:

• конкретизировал сроки ответа на различные типы запросов;
• ввёл обязанность отвечать в электронной форме, если запрос поступил электронно;
• усилил требования к подтверждению личности субъекта без создания избыточных барьеров;
• ввёл понятие «запрет на обработку» как отдельного права субъекта;
• расширил перечень оснований, при которых оператор обязан прекратить обработку.

Что добавили, ужесточили и упростили

Среди ключевых изменений 266-ФЗ — новая редакция статей 14, 20, 21 и ряда других [1]. Закон теперь прямо указывает, что оператор не вправе требовать от субъекта предоставления «излишних» документов для верификации: достаточно данных, позволяющих идентифицировать субъекта. Это изменение направлено против практики «заваливания» субъектов требованиями нотариально заверенных копий паспортов.

Одновременно были ужесточены санкции: поправки к КоАП через ст. 13.11 [3] подняли верхние планки штрафов до 300 000 рублей за первичное нарушение и до 500 000 рублей за повторное для юридических лиц. Важно: каждое нарушение (например, отказ в удалении + просрочка ответа) может рассматриваться как самостоятельный состав.

Какие права есть у субъекта ПДн по российскому закону

Право на доступ (ст. 14 152-ФЗ)

Субъект персональных данных имеет право запросить у оператора подтверждение факта обработки своих данных, а также получить их перечень, цели обработки, сроки хранения, сведения о передаче третьим лицам [1]. Это право аналогично «праву на доступ» (right of access) по GDPR [7] и является базовым.

Оператор обязан предоставить запрошенные сведения в течение 10 рабочих дней с момента получения запроса [1, 2]. Ответ должен быть исчерпывающим и понятным — не юридически перегруженным, а реально информативным.

Что важно: право на доступ не означает обязанность оператора предоставить «сырые» записи из базы данных в табличном виде. Субъект вправе получить сведения о том, какие данные обрабатываются и как, — в удобочитаемой форме. Однако практика показывает, что компании нередко злоупотребляют этой размытостью, предоставляя формальные ответы без реального содержания.

Право на исправление и дополнение (ст. 21 152-ФЗ)

Если данные субъекта неточны, неполны или устарели, он вправе потребовать их исправления или дополнения [1]. Оператор обязан внести изменения в течение 7 рабочих дней с момента предоставления субъектом сведений, подтверждающих неточность [1, 2].

Технически это может быть непростой задачей: данные о субъекте нередко хранятся в нескольких системах одновременно — в CRM, 1С, почтовых архивах, внешних аналитических системах. Исправление в одной системе без синхронизации с остальными создаёт риск появления «противоречивых» записей.

Право на удаление («право быть забытым», ст. 21 152-ФЗ)

Право на удаление в российском праве закреплено в ст. 21 152-ФЗ [1] и охватывает следующие основания:

• данные обрабатываются незаконно;
• цель обработки достигнута и данные более не нужны;
• субъект отозвал согласие на обработку;
• оператор нарушил требования закона.

Срок исполнения — 30 дней с момента получения запроса [1]. На практике это самый трудоёмкий тип запроса: он требует физического уничтожения или обезличивания данных во всех системах, в том числе в резервных копиях (с оговорками — подробнее в разделе про технические аспекты).

Важно: право на удаление не абсолютно. Оператор вправе отказать или продолжить обработку, если это необходимо для исполнения законодательства, для защиты жизни и здоровья, для выполнения договорных обязательств [1, 6].

Право на отзыв согласия (ст. 9 152-ФЗ)

Если обработка основана на согласии субъекта, он вправе его отозвать в любой момент [1]. Отзыв согласия не означает автоматического удаления данных: оператор должен прекратить обработку, но если есть иное законное основание (например, договор или закон), данные могут быть сохранены.

После отзыва согласия оператор обязан прекратить обработку и/или уничтожить данные в течение 30 дней [1], если нет иных оснований для хранения.

Право на ограничение обработки

Субъект вправе потребовать временного ограничения обработки своих данных — например, пока оспаривается их точность. В этом случае оператор может продолжать хранить данные, но не использовать их в активных операциях. Данное право в 152-ФЗ прямо не терминировано как «ограничение», однако аналогичный механизм реализуется через запрет на обработку по отдельным целям [1, 6].

Что не является обязательным: ограничения и исключения

Закон устанавливает ряд оснований, при которых оператор вправе отказать в удалении или исправлении:

• исполнение судебного акта;
• противодействие незаконным действиям третьих лиц;
• использование ПДн в исследовательских или статистических целях (при обезличивании);
• исполнение требований другого федерального закона [1, 3].

Отказ должен быть мотивированным и направлен субъекту в письменной или электронной форме в установленные сроки.

Сроки: таблица обязательств оператора

Соблюдение сроков — это та зона, где большинство нарушений происходят не из-за злого умысла, а из-за отсутствия процессов. Закон устанавливает несколько ключевых временных рамок [1, 5]:

1. Запрос на доступ (ст. 14) — 10 рабочих дней (152-ФЗ, ст. 20)
2. Запрос на исправление — 7 рабочих дней (152-ФЗ, ст. 21)
3. Запрос на удаление — 30 дней (152-ФЗ, ст. 21)
4. Отзыв согласия — 30 дней (152-ФЗ, ст. 9)
5. Запрет на обработку — 10 рабочих дней (152-ФЗ, ст. 21)
6. Уничтожение при незаконной обработке — 3 рабочих дня (152-ФЗ, ст. 21)

10 рабочих дней — для чего

Именно этот срок применяется к запросам на доступ и на запрет обработки [1]. Рабочие дни — это календарные дни за вычетом выходных и нерабочих праздничных дней. При поступлении запроса в пятницу вечером «счётчик» начинается со следующего рабочего дня (понедельника).

30 дней — для чего

Этот срок применяется к запросам на удаление и отзыву согласия [1]. В исключительных случаях (технически сложные ситуации, большие объёмы данных) закон позволяет продлить срок ещё на 30 дней с уведомлением субъекта [6] — однако это не «автоматическое» право: оператор должен уведомить субъекта до истечения первоначального срока.

3 рабочих дня — когда требуется экстренная реакция

С 2022 года в случае выявления незаконной обработки ПДн оператор обязан немедленно (в течение 3 рабочих дней) уничтожить незаконно обрабатываемые данные [1, 5]. Это требование чаще всего возникает по результатам собственной проверки или при выявлении инцидента.

Как правильно считать сроки

Срок начинает течь с даты получения запроса оператором. Дата получения — это дата поступления письма (если запрос письменный), дата поступления электронного сообщения (если электронный) или дата устного обращения с составлением соответствующей записи. Оператор обязан вести реестр входящих запросов субъектов с датами: это и доказательная база в споре с регулятором, и инструмент контроля сроков [2, 6].

Пошаговый процесс обработки запроса субъекта

Зрелые компании выстраивают обработку DSR (Data Subject Request — запрос субъекта данных) как сквозной операционный процесс. Вот как он должен выглядеть.

Шаг 1. Приём и регистрация запроса

Запрос может поступить по любому каналу: электронная почта, форма на сайте, обычная почта, лично в офисе. Оператор обязан обеспечить доступность каналов подачи запросов и назначить ответственное лицо (как правило, это ответственный за обработку ПДн или DPO, если таковой назначен) [2].

При поступлении запроса:

• фиксируется дата и способ получения;
• присваивается уникальный идентификатор (номер обращения);
• запускается счётчик срока.

Многие компании ошибочно начинают считать срок с момента, когда запрос «попал к нужному человеку», а не с момента его получения организацией. Это неправильно и является распространённой причиной просрочки.

Шаг 2. Верификация личности

Оператор вправе и обязан убедиться, что запрос поступил именно от субъекта данных или его уполномоченного представителя [1, 2]. Однако требования к верификации должны быть соразмерны: нельзя требовать нотариально заверенных документов там, где достаточно e-mail, с которого субъект ранее взаимодействовал с компанией.

Практические подходы к верификации:

• для электронных запросов — ответ на ранее зарегистрированный e-mail + подтверждающий код;
• для личного обращения — предъявление паспорта;
• для запросов через нотариуса — нотариально заверенное обращение.

Важно: избыточные требования к верификации сами по себе могут быть квалифицированы как воспрепятствование реализации прав субъекта [2, 6].

Шаг 3. Классификация запроса

Определяется тип запроса (доступ / исправление / удаление / отзыв согласия / иное) и применимый срок. Если запрос включает несколько требований одновременно — они рассматриваются в совокупности, но срок берётся максимальный из применимых.

Шаг 4. Внутренняя маршрутизация и поиск данных

Это самый трудоёмкий шаг. Необходимо:

• определить, в каких системах хранятся данные субъекта;
• выгрузить или проверить эти данные;
• в случае запроса на удаление — подготовить технический план уничтожения.

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

Шаг 5. Формирование ответа

Ответ должен быть:

• содержательным (не формальным);
• написанным понятным языком;
• направленным в той же форме, что и запрос (если запрос электронный — ответ электронный) [5];
• подписанным уполномоченным лицом оператора.

В случае отказа — в ответе должно быть указано мотивированное обоснование со ссылкой на конкретную норму закона.

Шаг 6. Исполнение

Для запроса на доступ — ответ с перечнем данных и условий обработки.

Для запроса на исправление — внесение изменений во все системы, содержащие соответствующие данные, с уведомлением субъекта о результатах.

Для запроса на удаление — уничтожение или обезличивание данных во всех системах, уведомление субъекта, документирование факта уничтожения (включая дату и перечень систем).

Шаг 7. Документирование

Каждый запрос субъекта и результат его обработки должны быть задокументированы [2, 6]:

• входящий запрос (оригинал или копия);
• дата получения;
• принятые меры;
• дата и форма ответа;
• в случае отказа — обоснование.

Документация хранится в течение срока, установленного внутренними политиками или требованиями регулятора — как правило, не менее 3 лет.

Технические аспекты: что реально сложно

Удаление из резервных копий и архивов

Это самая болезненная техническая проблема при реализации права на удаление. Резервные копии по определению создаются для восстановления данных: их структура не предусматривает «точечного» удаления отдельных записей без восстановления всего снимка и последующей перезаписи [13].

Российский закон прямо требует уничтожения ПДн, однако не устанавливает конкретного технического метода. Европейский регулятор (EDPB) разъяснял [7, 16], что в отношении резервных копий допустимо применять «обоснованный подход»: если резервные копии хранятся в соответствии с установленным регламентом, не используются в оперативных целях и будут уничтожены в плановые сроки — это может быть достаточным при условии немедленного удаления из активных систем. В России аналогичные официальные разъяснения на уровне РКН на момент написания статьи в открытом доступе не найдены: компаниям рекомендуется руководствоваться общим требованием закона и фиксировать в политике резервного копирования процедуру «отложенного удаления» с указанием сроков.

Практические решения:

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

Данные в сторонних системах и у подрядчиков

Операторы нередко передают ПДн подрядчикам — облачным провайдерам, аналитическим платформам, колл-центрам. При получении запроса на удаление оператор обязан потребовать удаления данных и от них [1]. Для этого необходимо:

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

На практике цепочка «оператор → подрядчик → подподрядчик» может быть длинной, и сроки в 30 дней становятся крайне жёсткими.

Псевдонимизация как альтернатива удалению

В ряде случаев полное удаление данных невозможно или нецелесообразно (например, требования налогового учёта, бухгалтерии, исполнения договора). Псевдонимизация — замена прямых идентификаторов (ФИО, ИНН, e-mail) на суррогатные ключи — может быть применима как альтернатива при условии, что обратная реидентификация исключена или существенно затруднена [7, 12].

В российском праве псевдонимизация как механизм исполнения права на удаление прямо не упоминается: это создаёт правовую неопределённость. Тем не менее часть экспертов считает обезличивание (не псевдонимизацию, а именно обезличивание) допустимой альтернативой уничтожению [6].

Логи и аудит-треки: удалять или нет

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

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

Организационные аспекты

Кто отвечает за DSR-процесс

В крупных компаниях ответственность за обработку запросов субъектов возлагается на специально назначенное должностное лицо — ответственного за организацию обработки ПДн (аналог DPO в европейской терминологии). В компаниях без специализированного специалиста эту роль нередко выполняет юрист или сотрудник HR/комплаенс. Ключевая проблема: отсутствие единого «окна» для входящих запросов и размытие ответственности между ИТ, юристами и бизнесом.

Зрелая модель предполагает:

• единый канал (e-mail, форма на сайте) для приёма запросов субъектов;
• назначенного владельца процесса DSR;
• SLA для каждого типа запроса (внутренний срок должен быть короче законодательного — как минимум на 2–3 дня буфер);
• эскалационный путь при нестандартных ситуациях.

Политики и регламенты

Компания обязана иметь [1, 2, 6]:

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

Обучение сотрудников

Любой сотрудник, контактирующий с клиентами или обрабатывающий ПДн, должен знать:

• как принять запрос субъекта и куда его направить;
• какие данные нельзя сообщать по телефону без верификации личности;
• что запрос не может быть проигнорирован — даже если он кажется необоснованным.

Типичные ошибки и риски

Просрочка ответа

Самая частая причина нарушений — отсутствие процесса отслеживания сроков. Запрос поступает, передаётся «кому-нибудь», теряется во входящей почте и всплывает уже после истечения срока. Роскомнадзор при проверках запрашивает журнал обращений субъектов: его отсутствие само по себе является нарушением [2, 3].

Неполный или некорректный ответ

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

Отказ без законного основания

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

Избыточные требования к верификации

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

Отсутствие уведомления о третьих лицах

Если данные субъекта были переданы третьим лицам и субъект запрашивает исправление или удаление — оператор обязан уведомить этих третьих лиц о необходимости внести соответствующие изменения [1]. Отсутствие такого уведомления — самостоятельное нарушение.

Штрафы и правоприменение в России

Административная ответственность по ст. 13.11 КоАП РФ

Статья 13.11 КоАП РФ [3] содержит несколько составов нарушений в сфере ПДн. Применительно к правам субъектов наиболее релевантны:

• ч. 4: непредоставление субъекту информации о его ПДн — штраф для юрлиц от 40 000 до 80 000 рублей;
• ч. 5: обработка ПДн без согласия субъекта — от 60 000 до 100 000 рублей (первичное), до 300 000 (повторное);
• ч. 1: обработка ПДн в случаях, не предусмотренных законом — до 100 000 рублей для юрлиц.

Важно: с 2022 года ряд нарушений был переведён в категорию, допускающую более значительные санкции, а проект нового закона об оборотных штрафах (в % от выручки) обсуждается в профессиональном сообществе [8, 10].

Прецеденты и дела РКН

По данным открытых источников и отчётов РКН [8], в 2023–2024 годах регулятор существенно активизировал проверочную деятельность. Характерные случаи: штрафы за непредоставление субъекту информации о его данных, за обработку данных без актуального согласия, за непринятие мер по удалению данных после отзыва согласия. Конкретные суммы штрафов по отдельным делам в открытых источниках ограниченно раскрыты: рекомендуем отслеживать официальную практику на сайте РКН [2] и в базах арбитражных решений.

Тренды ужесточения

Профессиональное сообщество фиксирует устойчивый тренд: регулятор переходит от «предупредить и исправить» к «оштрафовать сразу» [8, 10, 11]. Обсуждение законопроекта об оборотных штрафах в случае крупных утечек ПДн — ещё один сигнал об ужесточении режима. Даже без его принятия текущий КоАП позволяет накапливать множество штрафов по одному инциденту, если нарушений зафиксировано несколько.

Международный контекст: GDPR и другие режимы

Сравнение с GDPR

Европейский GDPR [7] традиционно считается эталоном в сфере прав субъектов. Ключевые отличия от российского режима:

Срок ответа на запрос: по GDPR — 30 календарных дней с возможностью продления до 90; по 152-ФЗ — 10 рабочих дней на доступ, 30 дней на удаление.

Право на переносимость данных: в GDPR прямо закреплено (ст. 20); в 152-ФЗ прямо не закреплено.

Штрафы: по GDPR — до 4% от глобальной годовой выручки; по 152-ФЗ — до 500 тыс. руб. за отдельное нарушение.

Право возражения против обработки: в GDPR прямо закреплено (ст. 21); в 152-ФЗ реализуется через механизм запрета на обработку.

Ответственный за защиту данных (DPO): в GDPR обязателен для ряда организаций (госорганы, крупная обработка); в 152-ФЗ «ответственный за организацию обработки» обязателен для всех операторов.

Что полезно перенять

Европейская практика предлагает ряд полезных инструментов, не противоречащих российскому праву:

• «privacy portal» — специализированный онлайн-портал для подачи запросов субъектами, автоматизирующий верификацию и трекинг сроков;
• стандартизированные шаблоны ответов с версиями для разных типов запросов;
• метрики: процент ответов в срок, среднее время исполнения запроса, количество эскалаций.

GDPR также активнее разрабатывает разъяснения по сложным техническим ситуациям (резервные копии, данные у подрядчиков): документы EDPB [16] могут служить ориентиром даже в российском контексте.

Как автоматизировать DSR-процессы

Когда ручной режим перестаёт работать

Компания с 10 000 клиентов, получающая даже 0,1% запросов субъектов в год, имеет дело с 10 обращениями. Это управляемо вручную. Но крупный интернет-ретейлер, банк или телеком-оператор получает сотни запросов ежемесячно — и при ручной обработке неизбежны просрочки, ошибки и неполнота ответов.

Критерии перехода на автоматизированный процесс DSR:

• более 20–30 запросов субъектов в месяц;
• данные хранятся в 5+ системах;
• ПДн регулярно передаются подрядчикам;
• компания работает в высокорегулируемой отрасли (финансы, медицина, телеком).

Инструменты и подходы

Мировой рынок предлагает специализированные платформы управления правами субъектов — OneTrust, Securiti.ai, TrustArc [14, 15]. Они автоматизируют приём запросов, верификацию, маршрутизацию к ИТ-системам, трекинг сроков и формирование ответов. Однако для большинства российских компаний критична локализация данных (данные нельзя передавать за рубеж в облачные SaaS-решения) и соответствие требованиям 152-ФЗ — что существенно сужает выбор.

Ключевым техническим фундаментом любой автоматизации DSR является не сам «DSR-инструмент», а актуальная карта данных (data map): без понимания того, где и какие ПДн хранятся, любая автоматизация работает вхолостую. Компания может принять запрос автоматически, но всё равно вынуждена «вручную» обзванивать владельцев систем, чтобы выяснить, есть ли там данные конкретного субъекта.

Пятый фактор: непрерывный контроль ПДн для быстрого исполнения запросов

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

«Пятый фактор» работает как on-premise платформа (данные не покидают инфраструктуру компании), автоматически обнаруживает и инвентаризирует ПДн в корпоративных системах — базах данных, хранилищах, почте, AD/LDAP, CRM, 1С, API — и поддерживает актуальную «живую карту» данных. Принципиально важно: платформа работает с метаданными, структурой и агрегатами, не передавая и не сохраняя «сырые» значения ПДн. Это означает, что она сама не становится источником риска утечки.

Как это помогает при работе с правами субъектов:

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

Проблема, которую «Пятый фактор» помогает решить, звучит так: компании часто не видят новые риски вовремя — новые поля в БД, новые сервисы, новые интеграции с подрядчиками появляются постоянно. Без непрерывного мониторинга компания узнаёт об их существовании только при инциденте или при поступлении запроса субъекта, когда реагировать уже сложно. Непрерывная карта ПДн превращает DSR из «пожарного режима» в управляемый процесс.

Выводы и чек-лист

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

Три главных вывода:

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

Второй: сроки жёсткие и короткие. 10 рабочих дней на доступ, 7 рабочих дней на исправление, 30 дней на удаление — при ручных процессах эти сроки легко нарушить даже при добросовестном намерении.

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

Чек-лист: готовность к обработке запросов субъектов ПДн

Правовая основа:

• ☐ Политика обработки ПДн актуализирована и публично доступна
• ☐ Внутренний регламент обработки запросов субъектов утверждён
• ☐ Перечень законных оснований обработки для каждой категории данных задокументирован

Организация процесса:

• ☐ Назначен ответственный за обработку запросов субъектов
• ☐ Единый канал приёма запросов определён и доведён до субъектов
• ☐ Реестр входящих запросов субъектов ведётся
• ☐ Внутренние SLA установлены с буфером к законодательным срокам

Технические меры:

• ☐ Инвентаризация систем, содержащих ПДн, проведена и актуальна
• ☐ Процедура удаления из резервных копий определена и задокументирована
• ☐ Реестр подрядчиков, которым переданы ПДн, ведётся
• ☐ Договоры с подрядчиками содержат обязательство исполнять запросы субъектов

Контроль и мониторинг:

• ☐ Метрики процесса DSR отслеживаются (% в срок, среднее время, количество отказов)
• ☐ Периодический аудит полноты ответов проводится
• ☐ Журнал обращений субъектов хранится не менее 3 лет

Источники

[1] Федеральный закон № 152-ФЗ «О персональных данных» — https://www.consultant.ru/document/cons_doc_LAW_61801/

[2] Роскомнадзор — права субъектов персональных данных — https://rkn.gov.ru/personal-data/p888/

[3] КоАП РФ ст. 13.11 — https://www.consultant.ru/document/cons_doc_LAW_34661/

[4] Приказ Роскомнадзора № 178 — https://rkn.gov.ru

[5] Федеральный закон № 266-ФЗ от 14.07.2022 — https://www.consultant.ru/document/cons_doc_LAW_420800/

[6] Методические рекомендации РКН по реализации прав субъектов ПДн — https://rkn.gov.ru/personal-data/p889/

[7] GDPR, Regulation (EU) 2016/679 — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679

[8] Отчёт РКН о правоприменении в сфере ПДн 2023 — https://rkn.gov.ru/press/publications/

[9] IAPP «Data Subject Rights: A Global Overview» — https://iapp.org/resources/article/data-subject-rights-global-overview/

[10] TAdviser — «Персональные данные в России 2023–2024» — https://www.tadviser.ru/index.php/Статья:Персональные_данные_(Россия)

[11] «Коммерсантъ» — «Штрафы за утечки ПДн» — https://www.kommersant.ru

[12] NIST SP 800-188 «De-Identifying Government Datasets» — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-188.pdf

[13] Gauthier, C. «Right to Erasure Compliance» — https://ssrn.com

[14] OneTrust «Data Subject Request Management Guide» — https://www.onetrust.com/blog/data-subject-requests/

[15] Securiti.ai «Automating DSR workflows» — https://securiti.ai/blog/

[16] EDPB Guidelines on data portability — https://edpb.europa.eu/our-work-tools/general-guidance/guidelines-recommendations-best-practices_en

[17] Habr — «Как построить процесс обработки запросов на удаление ПДн» — https://habr.com

[18] Positive Technologies — «Угрозы ИБ и ПДн 2024» — https://www.ptsecurity.com/ru-ru/research/analytics/