DPIA / Оценка воздействия на приватность: когда проводить и как правильно документировать

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

Зачем эта тема важна именно сейчас

В первом полугодии 2024 года в России было зафиксировано почти 1 млрд утечек персональных данных, а страна вошла в топ-2 мирового рейтинга по количеству инцидентов [17]. Ответом законодателя стали радикальные изменения в ответственности операторов: Федеральный закон № 420-ФЗ от 30.11.2024 увеличил штрафы в разы и ввёл оборотные санкции, вступившие в силу 30 мая 2025 года [5]. Теперь за массовую утечку общих данных организация может получить штраф до 500 млн руб., а за утечку специальных категорий — уголовную ответственность сроком до пяти лет [18].

На этом фоне оценка воздействия на приватность (Privacy / Data Protection Impact Assessment) из инструмента «европейского комплаенса» превращается в обязательный элемент риск-менеджмента для любого российского оператора, работающего с чувствительными данными. Понять, что именно ты обрабатываешь, какие риски это создаёт для людей и как их снизить — не просто добросовестная практика, но и документальная защита при проверке регулятора.

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

Что такое DPIA и как он соотносится с PIA

DPIA расшифровывается как Data Protection Impact Assessment — оценка воздействия на защиту данных. Это систематический процесс, который помогает определить, создаёт ли запланированная обработка персональных данных существенный риск для прав и свобод физических лиц, и разработать меры снижения этого риска до приемлемого уровня [1].

Термин DPIA закреплён в статье 35 GDPR (Общего регламента по защите данных ЕС, 2016/679), а его методологическую основу составляют руководящие принципы, разработанные в 2017 году рабочей группой WP29 (сейчас — Европейский совет по защите данных, EDPB) [2].

DPIA vs PIA: в чём разница

Термины DPIA и PIA (Privacy Impact Assessment) нередко используются как синонимы, хотя между ними есть нюансы. PIA — более широкое понятие, исторически использовавшееся в США, Канаде и Австралии с конца 1990-х годов; оно описывает любую структурированную оценку влияния проекта на приватность. DPIA — это специфический термин из GDPR, более строго регламентированный по составу и условиям проведения [20].

Международный стандарт ISO/IEC 29134:2023 использует термин PIA, но при этом его структура и методология полностью совместимы с требованиями GDPR к DPIA [3]. Для целей этой статьи мы будем использовать оба термина как взаимозаменяемые, уточняя контекст там, где это важно.

Место DPIA в системе Privacy by Design

DPIA — это не самостоятельный документ, существующий в вакууме. Он является ключевым инструментом реализации принципа Privacy by Design («приватность через проектирование»), который требует встраивать защиту данных в архитектуру систем и процессов с самого начала, а не добавлять её после [2].

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

Если обнаруженные риски не поддаются снижению до приемлемого уровня собственными силами, организация обязана проконсультироваться с надзорным органом до начала обработки — в терминологии GDPR это называется prior consultation, предварительная консультация (статья 36 GDPR) [1].

Когда DPIA обязательна: критерии высокого риска

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

Три безусловных случая по GDPR

Статья 35(3) GDPR устанавливает три типа обработки, при которых DPIA требуется всегда, без дополнительных условий [1]:

1. Систематическая и масштабная оценка личностных аспектов физических лиц, основанная на автоматизированной обработке, включая профилирование, если на её основании принимаются решения с юридическими или аналогичными значимыми последствиями для человека (например, автоматическое кредитное скоринг, HR-системы с алгоритмическим отбором кандидатов).
2. Масштабная обработка специальных категорий данных (состояние здоровья, генетические, биометрические, расовые, религиозные данные и т.д.) или данных о судимостях и правонарушениях.
3. Систематический масштабный мониторинг общедоступных публичных пространств (видеонаблюдение с распознаванием лиц, системы слежения за транспортом в городском масштабе).

Девять критериев WP29: логика «двух из девяти»

Помимо трёх безусловных случаев, рабочая группа WP29 разработала список из девяти дополнительных критериев. Как правило (но не абсолютно), наличие двух или более критериев говорит о высоком риске и необходимости DPIA [2]:

1. Оценка или скоринг физических лиц (составление профилей, оценка поведения, кредитная история, предпочтения, интересы).
2. Автоматизированное принятие решений с юридическим или существенным эффектом.
3. Систематический мониторинг (отслеживание и профилирование субъектов данных в интернете или в офлайн-пространстве).
4. Чувствительные данные или данные личного характера (специальные категории по GDPR, но также финансовые данные, местонахождение, персональная переписка).
5. Обработка в большом масштабе (по количеству субъектов, объёму данных, географическому охвату или продолжительности).
6. Сопоставление или объединение наборов данных (данные из разных источников, собранных с различными целями, объединяются в единый профиль).
7. Данные уязвимых субъектов (дети, пожилые люди, психически больные, пациенты, работники — как зависимая от работодателя категория).
8. Инновационные технологии или новые способы применения существующих технологий (IoT-устройства, ИИ, распознавание лиц, нейроинтерфейсы).
9. Обработка, которая лишает субъекта возможности воспользоваться услугой или реализовать право (например, биометрия как единственный способ входа).

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

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

Ситуация в России: 152-ФЗ и отсутствие прямого аналога

Главное, что нужно понимать российскому оператору: ФЗ-152 «О персональных данных» не содержит понятия DPIA и не обязывает проводить оценку воздействия на приватность в формате, закреплённом GDPR [2]. Это существенное отличие от европейской системы.

Тем не менее несколько норм 152-ФЗ фактически требуют аналогичного анализа. Пункт 4 части 2 статьи 19 закона обязывает операторов обеспечивать «оценку эффективности принимаемых мер по обеспечению безопасности персональных данных до ввода в эксплуатацию информационной системы персональных данных» [6]. По сути — это требование провести предпусковую оценку рисков, то есть выполнить ключевой элемент DPIA.

Для государственных и муниципальных учреждений обязательна «Методика оценки угроз безопасности информации», утверждённая ФСТЭК России 5 февраля 2021 года. Коммерческие операторы вправе применять её добровольно, и многие DPO-специалисты рекомендуют именно такой подход [2].

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

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

Биометрия и специальные категории ПДн в российском контексте

Российское законодательство устанавливает особый режим для биометрических персональных данных (отпечатки пальцев, изображение лица, радужная оболочка глаза, голосовые параметры). Для их обработки требуется явное письменное согласие субъекта; за обработку биометрии без согласия работника должностным лицам грозит штраф от 100 до 300 тыс. руб., а организации — от 500 тыс. до 1 млн руб. по ст. 13.11.3 КоАП РФ [14].

Ассоциация юристов России прямо указывает: для большинства проектов с биометрией «DPIA должна быть документирована и учитывать риски ошибок распознавания, дискриминации и масштабных утечек» [14]. Это де-факто делает аналог DPIA обязательным не из GDPR, а из здравого смысла управления рисками при работе с биометрическими данными в России.

Аналогичный подход применим к специальным категориям данных по 152-ФЗ — сведениям о здоровье, политических взглядах, религиозных убеждениях и судимостях. Масштабная обработка таких данных без структурированной оценки рисков оставляет организацию уязвимой как с регуляторной точки зрения, так и с репутационной.

Из чего состоит DPIA: обязательные разделы документа

Статья 35(7) GDPR определяет четыре обязательных элемента DPIA. Это минимальный состав, который надзорные органы ожидают увидеть в документе [1]:

Описание операций обработки

Систематическое описание запланированных операций и их целей, включая законные основания обработки. Этот раздел должен включать: какие ПДн собираются, у кого, для каких целей, кто имеет к ним доступ, куда они передаются, как и как долго хранятся. Хорошая практика — дополнять описание диаграммой потоков данных (data flow diagram).

Именно этот раздел является наиболее трудоёмким и занимает бо́льшую часть документа [22]. Без детального понимания того, как устроен процесс обработки, оценить риски невозможно.

Оценка необходимости и соразмерности

Анализ того, действительно ли запланированная обработка необходима для достижения заявленной цели и не является ли она избыточной. Здесь оцениваются: принцип минимизации данных (собирается ли только то, что действительно нужно?), основание обработки (согласие, договор, законный интерес и т.д.), соответствие декларируемым целям.

Этот раздел — внутренняя проверка на принцип Privacy by Default: если задачу можно решить с меньшим объёмом данных, организация обязана выбрать этот путь.

Оценка рисков для прав и свобод субъектов

Оценке подлежат риски именно для людей, чьи данные обрабатываются, — не для организации [22]. Стандартно используется матрица «вероятность × тяжесть последствий» для трёх базовых типов рисков: незаконный или несанкционированный доступ к данным, нежелательное изменение данных, исчезновение или уничтожение данных [24].

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

Меры по снижению рисков

Технические и организационные меры, принимаемые для снижения выявленных рисков до приемлемого уровня. Примеры технических мер: шифрование, псевдонимизация, контроль доступа, логирование, резервное копирование. Примеры организационных мер: обучение персонала, политики доступа, соглашения об обработке данных с подрядчиками, процедуры реагирования на инциденты [19].

Документ должен фиксировать «остаточный риск» — риск, который сохраняется даже после применения всех мер. Если остаточный риск по-прежнему высок, требуется предварительная консультация с регулятором.

Пошаговый процесс проведения DPIA

Ниже представлен восьмишаговый процесс, основанный на руководстве MG Software и рекомендациях WP29 [19, 2]:

Шаг 1 — Скрининг: нужна ли DPIA?

До начала полноценной оценки проведите быстрый скрининг: проверьте запланированную обработку по трём безусловным критериям GDPR и девяти критериям WP29. Если совпадают два и более критерия — DPIA обязательна. Если ни одного — зафиксируйте это решение и причины письменно. Документированный скрининг важен даже тогда, когда его вывод «DPIA не нужна».

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

Шаг 2 — Подготовка: команда и данные

Сформируйте рабочую группу. В неё, как правило, входят: владелец процесса (бизнес-сторона), специалист по информационной безопасности, юрист или DPO (ответственный за обработку ПДн), IT-архитектор или разработчик [24]. DPO не проводит DPIA самостоятельно — он консультирует и проверяет качество оценки, а ответственным является контролёр (оператор ПДн).

Соберите исходные данные: техническую документацию, договоры с подрядчиками, схемы систем, политики доступа.

Шаг 3 — Описание процесса обработки

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

Для сложных систем рекомендуется использовать диаграммы потоков данных (DFD). Это самый трудоёмкий этап, но его качество определяет качество всей последующей оценки [22].

Шаг 4 — Тест необходимости и соразмерности

Ответьте на вопросы: какова законная цель обработки? Достигается ли эта цель именно таким составом данных? Нельзя ли достичь её с меньшим объёмом ПДн (принцип минимизации)? Соответствует ли срок хранения цели обработки? Каково правовое основание?

Шаг 5 — Идентификация и оценка рисков

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

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

Шаг 6 — Меры снижения рисков

Для каждого риска с оценкой «средний» или «высокий» разработайте конкретные меры снижения. Определите ответственного и срок реализации. Зафиксируйте остаточный риск после применения мер. Если остаточный риск по-прежнему высок — требуется консультация с регулятором до начала обработки.

Шаг 7 — Документирование и утверждение

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

Шаг 8 — Мониторинг и пересмотр

DPIA — живой документ, а не разовое мероприятие [24]. Его необходимо пересматривать:

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

Ключевые роли в DPIA: кто за что отвечает

Правильное распределение ролей — обязательное условие качественной DPIA. Регуляторные органы неоднократно указывали, что DPIA не должна быть задачей только юридического отдела или только ИБ-специалистов [15].

Оператор (контролёр) несёт полную ответственность за проведение DPIA и её результаты. Он принимает итоговое решение о начале или отказе от обработки на основе оценки.

DPO (ответственный за обработку ПДн) обязан быть привлечён к консультации при проведении DPIA. Его задача — оценить методологию, проверить полноту оценки рисков и адекватность мер снижения. DPO не проводит DPIA вместо оператора.

CISO (директор по информационной безопасности), если назначен, может инициировать проведение DPIA для конкретных операций и участвует в оценке технических рисков [18].

IT-команда и разработчики отвечают за точное описание технической реализации и предложение конкретных технических мер снижения рисков.

Бизнес-владелец процесса несёт ответственность за описание целей обработки и обоснование необходимости использования конкретных данных.

Внешние подрядчики (процессоры/операторы по поручению) обязаны предоставлять информацию о своей части обработки и содействовать в документировании [13].

Типичные ошибки при проведении DPIA

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

1. DPIA как формальность, а не инструмент. Самая распространённая проблема: оценка проводится для «галочки», рекомендации остаются на бумаге, корректирующие меры не внедряются. Такая DPIA не только бесполезна, но и юридически опасна — при проверке регулятор увидит задокументированный риск без принятых мер [24].
2. Проведение DPIA после запуска. DPIA, проводимая после того как система уже работает, теряет ключевую ценность: найденные риски несравнимо дороже устранять в рабочей системе, чем на этапе проектирования.
3. Неправильный объект оценки. Частая ошибка — оценивать риски для организации (штрафы, репутация), а не для субъектов данных. GDPR и хорошая практика требуют оценивать риски для людей [22].
4. Недостаточное описание обработки. Без детальной карты потоков данных невозможно качественно оценить риски. Многие DPIA страдают от того, что в разделе описания обработки присутствует общая информация вместо конкретной картины.
5. Отсутствие пересмотра. Разовое проведение DPIA при запуске проекта без последующих обновлений не отражает изменившиеся риски — новые интеграции, новые категории данных, новые угрозы.
6. Привлечение только одного отдела. DPIA, подготовленная исключительно юристами или исключительно ИБ-специалистами без участия бизнеса и IT, неизбежно содержит слепые пятна.
7. Игнорирование подрядчиков. Операторы нередко описывают только собственную обработку, упуская риски, связанные с передачей данных облачным провайдерам, CRM-системам и другим подрядчикам.

Практические кейсы: когда нужна и не нужна DPIA

Чтобы перевести критерии из теории в практику, приведём примеры, основанные на материалах Европейской комиссии и ICO [7, 12]:

Примеры, когда DPIA нужна:

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

Примеры, когда DPIA, вероятно, не нужна:

• Врач общей практики ведёт записи о пациентах в системе небольшой частной клиники (малый масштаб, нет систематического мониторинга) [7].
• Интернет-магазин обрабатывает данные клиентов (ФИО, адрес, телефон) исключительно для оформления и доставки заказов, без профилирования и автоматических решений.
• Компания ведёт стандартный кадровый учёт сотрудников без биометрии и без автоматизированного принятия решений о карьере.

Важная оговорка: приведённые примеры — не исчерпывающие правила. Каждая ситуация требует индивидуального скрининга. Граница между «нужна» и «не нужна» нередко зависит от масштаба, применяемых технологий и конкретного контекста.

Инструменты и стандарты: ISO 29134, CNIL PIA, ICO-шаблон

Для проведения DPIA существует ряд признанных методологических основ и практических инструментов.

ISO/IEC 29134:2023 — международный стандарт «Информационные технологии — Методы защиты — Руководство по оценке воздействия на приватность» [3]. Обновлённая в 2023 году версия содержит руководство по процессу PIA и структуре отчёта, применима к организациям любого размера и типа. Это наиболее универсальная методологическая база, не привязанная к конкретному законодательству.

CNIL (французский регулятор) разработал наиболее детальную методологию DPIA в мире — четыре руководства общим объёмом около 200 страниц, а также бесплатное открытое ПО «PIA Software» [22]. Инструмент регулярно обновляется и позволяет структурированно задокументировать все разделы DPIA.

ICO (регулятор Великобритании) опубликовал шаблон DPIA, который поэтапно проводит организацию через весь процесс от скрининга до документирования результатов [12]. Шаблон бесплатен и доступен на сайте ICO.

ISO 27001 и ISO 27701 (система управления информационной безопасностью и расширение для приватности) дополняют ISO 29134 операционной основой и помогают проверять эффективность внедрённых мер [19].

RPPA (Российская ассоциация по персональным данным) публикует шаблоны DPIA и RoPA (реестра операций обработки), адаптированные под российскую практику [13].

Будущее DPIA: тренды 2025–2026

Несколько значимых тенденций меняют ландшафт оценки воздействия на приватность.

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

Ужесточение российского законодательства делает оценку рисков обязательным элементом корпоративной гигиены. Рост штрафов до 500 млн руб. и введение оборотных санкций [18] означают, что стоимость необнаруженного риска многократно выросла. В этих условиях DPIA из «европейской экзотики» превращается в базовый инструмент риск-менеджмента для любого крупного российского оператора.

Требование локализации данных (с 1 июля 2025 года запрещено хранить ПДн граждан РФ в зарубежных базах данных) [4] порождает волну миграционных проектов, каждый из которых технически является существенным изменением условий обработки и требует пересмотра действующих DPIA или проведения новых.

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

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

Одна из главных практических сложностей при проведении DPIA — это этап описания обработки (шаг 3). Без актуальной, точной карты того, где и какие персональные данные хранятся, как они передаются и кто имеет к ним доступ, DPIA превращается в упражнение по воспроизведению желаемой картины, а не реальной.

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

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

Ключевая особенность платформы — принцип privacy-by-design в самой архитектуре: система работает с метаданными, структурой и агрегатами, не передавая и не сохраняя «сырые» значения ПДн. Это означает, что инструмент, призванный снижать риски, сам не становится источником нового риска.

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

Для DPO и команд комплаенса это означает сокращение трудозатрат на подготовительный этап DPIA и повышение точности документируемой картины обработки — именно того раздела, от качества которого зависят все последующие выводы оценки.

Заключение: что делать дальше

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

Конкретные шаги для начала работы:

1. Проведите инвентаризацию всех процессов обработки ПДн в организации и составьте реестр операций (RoPA).
2. Для каждого процесса выполните скрининг по критериям WP29 — определите, какие требуют DPIA.
3. Для высокоприоритетных процессов (биометрия, специальные категории, масштабное профилирование) начните с полноценного DPIA прямо сейчас.
4. Выберите методологическую основу: ISO/IEC 29134:2023, шаблон ICO или ПО CNIL.
5. Сформируйте кросс-функциональную команду с участием бизнеса, IT, ИБ и юристов.
6. Установите процесс регулярного пересмотра DPIA — минимум ежегодно для высокорисковых операций.
7. Рассмотрите внедрение инструментов автоматической инвентаризации ПДн, чтобы поддерживать актуальность карты данных между ревизиями.

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

Источники

[1] Art. 35 GDPR — Data protection impact assessment — https://gdpr-info.eu/art-35-gdpr/

[2] WP29 Guidelines on DPIA (Article 35 GDPR commentary) — GDPRhub — https://gdprhub.eu/Article_35_GDPR

[3] ISO/IEC 29134:2023 — Information technology — Security techniques — Guidelines for privacy impact assessment — https://www.iso.org/standard/86012.html

[4] ФЗ-152 «О персональных данных», редакция 2025 — https://www.business.ru/article/5705-152-fz-o-personalnyh-dannyh-gg

[5] Штрафы за персональные данные в 2026 году — data-sec.ru — https://data-sec.ru/personal-data/fines/

[6] SecurityVision — Практическая защита ПДн: оценка эффективности мер — https://www.securityvision.ru/blog/prakticheskaya-zashchita-personalnykh-dannykh-provodim-otsenku-effektivnosti-prinimaemykh-mer-po-obe/

[7] European Commission — When is DPIA required? — https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/when-data-protection-impact-assessment-dpia-required_en

[8] CNIL — Guidelines on DPIA — https://www.cnil.fr/en/guidelines-dpia

[9] VC.ru — Персональные данные 2025: штраф до 15 млн и запрет зарубежных баз — https://vc.ru/legal/2186769-personalnye-dannye-2025-izmeneniya-i-shtrafy

[10] RPPA — Документы: шаблон DPIA и RoPA — https://rppa.pro/doku.php?id=rppa/docs

[11] McCann FitzGerald — GDPR Data Protection Impact Assessment Guidelines — https://www.mccannfitzgerald.com/knowledge/privacy/data-protection-impact-assessment-guidelines

[12] ICO — When do we need to do a DPIA? — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/data-protection-impact-assessments-dpias/when-do-we-need-to-do-a-dpia/

[13] Data Privacy Office — Что такое DPIA и как создать — https://data-privacy-office.com/what-is-a-dpia-data-protection-impact-assessment-and-how-to-create-one-according-to-gdpr/

[14] Ассоциация Юристов России — Приватность данных и биометрия — https://alrf.ru/articles/privatnost-dannykh-i-biometriya/

[15] TrustArc — EU GDPR Article 35: DPIA Cheat Sheet — https://trustarc.com/resource/data-protection-impact-assessment-article35/

[16] Microsoft Learn — Оценка влияния на защиту данных (GDPR) — https://learn.microsoft.com/ru-ru/compliance/regulatory/gdpr-data-protection-impact-assessments

[17] Habr / МойСклад — Роскомнадзор и штрафы за персданные с 30.05.2025 — https://habr.com/ru/companies/moysklad/articles/994568/

[18] Главбух — Штрафы за персональные данные с 30 мая 2025 — https://www.glavbukh.ru/art/391377-shtrafy-za-obrabotku-rasprostranenie-i-utechku-personalnyh-dannyh-11xx-news

[19] MG Software — Privacy Impact Assessment Template — https://www.mgsoftware.nl/en/templates/privacy-impact-assessment-template

[20] Bamboo Data Consulting — Basics of Privacy Impact Assessments — https://www.bamboodataconsulting.com/blog/privacy-impact-assessment-guide

[21] CDTO РАНХиГС — 4.4 Оценка воздействия обработки данных (DPIA) — https://cdto.ranepa.ru/reports/ethics/2021/4-4-ocenka-vozdejstviya-obrabotki-dannyh-dpia

[22] SecurityLab — DPIA на практике — https://www.securitylab.ru/blog/personal/80na20/347261.php

[23] IdeaPlan — Privacy Impact Assessment (PIA/DPIA) Template — https://www.ideaplan.io/templates/privacy-impact-assessment-template

[24] Data Privacy Office — Проведение DPIA (сервис) — https://data-privacy-office.com/services/provedenie-dpia/

[25] GDPR.eu — Data Protection Impact Assessment Template — https://gdpr.eu/data-protection-impact-assessment-template/