Объединяем реестр обработок ПДн и DPIA в один рабочий инструмент

«Нужно одновременно соблюдать регуляторные требования и иметь рабочий инструмент. Бумажный реестр только для проверки, это неполно. Живой DPIA, который реально помогает принимать решения,, это другое. Попробуем совместить формальное и практическое в одном документе»

Зачем нужен реестр обработок, если есть DPIA

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

Второй вид учёта, это анализ. Когда инвентаризация проведена, нужно понять, какие из выявленных обработок несут повышенные риски для прав и свобод субъектов данных. Для этого проводится оценка воздействия на защиту персональных данных (DPIA). Это уже не просто список, а исследование конкретной обработки, её целей, законности, угроз и мер защиты.

Проблема в том, что эти процессы часто ведут отдельно. Реестр заполняет юрист или специалист по compliance, чтобы «поставить галочку». DPIA проводит специалист по информационной безопасности, когда этого требует внутренняя процедура или регулятор. В итоге получается два несвязанных документа, данные дублируются, а общая картина рисков размыта.

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

Из чего состоит интегрированный шаблон

Шаблон, объединяющий реестр и DPIA, строится по принципу «от общего к частному». Его основу составляет реестр обработок, каждая запись в котором, это карточка с ключевыми атрибутами.

Блок реестра (инвентаризация)

Наименование обработки. Не техническое название системы, а бизнес-процесс: «Подбор персонала», «Обслуживание клиентов по договору», «Ведение корпоративного портала».
Цели и правовые основания. Чёткое описание, для чего нужны данные, со ссылкой на конкретные пункты статьи 6 152-ФЗ (согласие, договор, законный интерес и т.д.).
Категории субъектов и данных. Кто эти люди (сотрудники, клиенты, соискатели) и какие именно данные обрабатываются. Важно указывать, являются ли данные биометрическими, специальными категориями или данными о судимости.
Операторы и процессоры. Кто является оператором (ваша организация) и привлекаются ли третьи лица (процессоры) для обработки, например, хостинг-провайдер или CRM-платформа.
Сроки хранения и условия прекращения. На какой период данные хранятся и что с ними происходит после достижения цели или истечения срока.
Общие сведения о системе. Название ИС, где происходит обработка, её местонахождение (юрисдикция).

Блок DPIA (оценка рисков)

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

Необходимость проведения DPIA. Обоснование, почему для этой обработки оценка обязательна. Критерии могут включать: автоматизированное принятие решений с правовыми последствиями, обработку специальных категорий данных в больших масштабах, систематический мониторинг публично доступных зон, совмещение данных из разных источников.
Описание обработки. Более детальное, чем в реестре: потоки данных, вовлечённые стороны, технологические особенности.
Оценка необходимости и соразмерности. Анализ, действительно ли предлагаемая обработка необходима для заявленной цели, и нет ли менее инвазивных для приватности способов её достижения.
Идентификация рисков для прав субъектов. Систематический поиск угроз: несанкционированный доступ, утечка, ошибка в данных, невозможность исправить или удалить свои данные, дискриминация.
Меры по снижению рисков. Конкретные меры, которые планируется или уже применяются: шифрование, псевдонимизация, строгий контроль доступа, регулярные аудиты, процедуры исполнения прав субъектов.
Выводы и остаточный риск. Заключение о допустимости обработки с учётом принятых мер. Если остаточный риск высок, может потребоваться консультация с регулятором до начала обработки.

Как определять, когда DPIA обязателен

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

Очевидные триггеры:

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

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

Пример заполнения: обработка «Онлайн-запись к врачу»

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

Раздел реестра:

Наименование: Приём онлайн-записей пациентов в поликлинику.
Цель: Обеспечение возможности дистанционной записи на приём к врачу для удобства пациентов и оптимизации нагрузки специалистов.
Правовое основание: Необходимость для исполнения договора на оказание медицинских услуг (ст. 6 152-ФЗ). Также может потребоваться отдельное согласие на обработку данных о здоровье.
Категории данных: Пациенты. Данные: ФИО, дата рождения, контактный телефон, данные полиса ОМС, данные о здоровье (симптомы, выбранный специалист, дата и время приёма). Данные о здоровье — специальная категория.
Оператор: Медицинская организация.
Процессоры: Провайдер облачной платформы для хостинга сервиса записи.
Критерий риска: Обработка специальных категорий данных (здоровье) в электронном виде. Триггер для DPIA.

Раздел DPIA (сокращённо):

Необходимость: Обработка специальных категорий ПДн (данные о здоровье) в информационной системе.
Детальное описание: Пациент через веб-сайт или мобильное приложение заполняет форму, выбирает врача и время. Данные поступают в базу данных, доступную администраторам и врачам. Используется внешний облачный хостинг.
Выявленные риски:
- Несанкционированный доступ к базе данных с медицинскими записями со стороны сотрудников или через уязвимости в ПО.
- Утечка данных при передаче между браузером пациента и сервером.
- Некорректное хранение резервных копий.
- Отсутствие у пациента возможности удалить свою запись после посещения врача.
Меры по снижению:
- Шифрование соединения по протоколу TLS 1.3.
- Шифрование данных в базе на стороне сервера.
- Строгая модель разграничения доступа (роли: пациент, администратор, врач). Врач видит только записи к нему.
- Регулярный пересмотр прав доступа.
- Договор с хостинг-провайдером, обязывающий его выступать в роли процессора с соблюдением требований 152-ФЗ.
- Внедрение функции «Отмена и удаление записи» для пациента в течение определённого срока до приёма.
Вывод: При реализации указанных мер остаточный риск обработки является приемлемым. Обработка может быть начата. Список мер фиксируется и становится частью технического задания на доработку сервиса.

Техническая реализация: от Excel до специализированных систем

Начинать можно с простого. Многие организации ведут первичный реестр в Excel или Google Sheets. Для интегрированного подхода достаточно добавить несколько столбцов: «Критерий высокого риска (Да/Нет)», «Ссылка на документ DPIA», «Статус DPIA», «Ответственный за оценку». Это уже создаёт связь.

Следующий шаг — использование low-code платформ или систем управления бизнес-процессами (BPMS), где можно создать форму для заполнения реестра, настроить марш>>>>рутизацию карточки на согласование и автоматически генерировать шаблон документа DPIA, если в форме отмечен соответствующий критерий.

Для крупных организаций или операторов, чья основная деятельность связана с обработкой ПДн, имеет смысл рассматривать специализированные программные решения класса GRC (Governance, Risk and Compliance) или Data Privacy Management. В таких системах реестр обработок и модуль DPIA часто встроены изначально, предусмотрены workflows, интеграция с системами управления инцидентами и каталогами активов. Преимущество — централизованное управление, автоматические отчёты и всегда актуальная картина для аудита.

Независимо от выбранного инструмента, принцип остаётся единым: реестр, это источник данных и точка входа, а DPIA, это углублённое исследование, результаты которого возвращаются в реестр, закрывая цикл управления рисками для конкретной обработки.

Распространённые ошибки при внедрении

Создать шаблон — полдела. Важно избежать типичных ошибок, которые превращают его в мёртвый документ.

Неактуальность реестра. Самая частая проблема. Реестр составляется один раз для проверки и не обновляется при появлении новых процессов или систем. Необходимо закрепить процедуру регулярного (например, ежеквартального) пересмотра и обязательного включения в реестр любых новых ИС или бизнес-процессов, связанных с ПДн.
DPIA как формальность. Оценка проводится «для галочки», выводы носят общий характер («риски минимизированы»), а конкретные меры защиты не прописываются и, как следствие, не реализуются. DPIA должен иметь практический выход — список корректирующих действий, которые берутся на контроль.
Отсутствие связи с реальными системами. В реестре указано «CRM-система», но неясно, о какой конкретно платформе идёт речь, кто администратор, где физически расположены серверы. Это затрудняет и оценку рисков, и реагирование на инциденты. Нужна интеграция с IT-инвентаризацией.
Игнорирование процессоров. В реестре не указываются третьи лица, или указываются, но без анализа договоров с ними на соответствие 152-ФЗ. Оператор остаётся ответственным за действия процессора. DPIA для обработки с привлечением процессора должна включать оценку рисков, связанных с этим внешним исполнителем.

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