Privacy by Design в разработке: чек-лист для product/tech перед релизом

Зачем встраивать приватность с первого коммита, а не добавлять её потом

1. Почему 2025 год изменил ставки

Если вы пишете бэкенд, разрабатываете продукт или принимаете архитектурные решения в российской компании, вам уже недостаточно знать, что «нельзя хранить паспорт в открытом виде». Регуляторная реальность изменилась кардинально.

Федеральный закон № 420-ФЗ от 30 ноября 2024 года внёс изменения в КоАП РФ, которые вступили в силу 30 мая 2025 года [1]. Теперь за утечку персональных данных, затронувшую от 1 до 10 тысяч субъектов, организации грозит штраф до 5 млн рублей. За утечку свыше 100 тысяч субъектов — до 15 млн рублей. Повторная утечка влечёт оборотный штраф от 1 до 3% годовой выручки, но не менее 20 млн рублей и не более 500 млн рублей [2]. За утечку биометрии штраф стартует от 15 до 20 млн рублей уже при первом инциденте [3].

Параллельно с 1 июля 2025 года вступила в силу новая редакция части 5 статьи 18 Федерального закона № 152-ФЗ, полностью запрещающая хранение, запись и изменение персональных данных российских граждан в базах данных, расположенных за пределами РФ [4]. Это значит, что использование зарубежных CRM, аналитических систем, корпоративных мессенджеров без российского экземпляра базы стало прямым нарушением.

На фоне европейского GDPR — штрафы которого к январю 2025 года суммарно превысили 5,88 млрд евро [5] — российское законодательство всё активнее движется по схожей траектории. Разница в том, что у российских компаний меньше времени на адаптацию, а методологической поддержки со стороны регулятора пока значительно меньше.

Privacy by Design (PbD) — это ответ на этот вызов. Не набор формальных документов, а способ мышления, при котором вопрос «а как мы обрабатываем персональные данные?» задаётся не на этапе аудита, а на этапе написания технического задания.

2. Что такое Privacy by Design: история и суть

Концепцию Privacy by Design разработала Энн Кавукян, комиссар по вопросам информации и приватности провинции Онтарио (Канада), в 1990-х годах — совместно с голландским регулятором по защите данных [6]. Ключевой документ с семью базовыми принципами вышел в 2009 году и в октябре 2010 года был единогласно принят Международной конференцией уполномоченных по защите данных в качестве глобального стандарта [7].

С тех пор принципы переведены на 37 языков и легли в основу статьи 25 европейского GDPR («Защита данных посредством проектирования и по умолчанию»), а также вдохновили множество национальных регуляторных систем.

Ключевая идея проста: приватность не должна быть функциональностью, которую добавляют перед релизом по требованию юридического отдела. Она должна быть встроена в архитектуру системы так же органично, как безопасность или отказоустойчивость [8].

2.1 Семь базовых принципов

Все семь принципов были сформулированы Кавукян [9] и представляют собой не юридические требования, а инженерное и организационное мировоззрение.

1. Проактивность, а не реактивность — предотвращение инцидентов, а не реагирование на них после факта.
2. Приватность как настройка по умолчанию — без действий пользователя его данные защищены максимально.
3. Приватность встроена в архитектуру — не надстройка, а часть ядра системы.
4. Полная функциональность (positive-sum) — приватность не должна конфликтовать с безопасностью или бизнес-функциями.
5. Сквозная безопасность — защита от сбора до уничтожения данных.
6. Прозрачность и подотчётность — система работает так, как декларирует; поддаётся проверке.
7. Ориентация на пользователя — интересы субъекта данных в приоритете.

2.2 PbD в российском праве

Российское законодательство не использует термин «Privacy by Design», но принципы Федерального закона № 152-ФЗ, особенно в редакции после изменений 2024–2025 годов, фактически воспроизводят его логику. Статья 5 закрепляет принципы обработки ПДн: законность, справедливость, ограничение целью, минимизация, точность, ограничение хранения, целостность и конфиденциальность [10]. Статья 18.1 требует от операторов принять меры, необходимые и достаточные для обеспечения выполнения обязанностей, предусмотренных законом. Это и есть отечественный аналог требования «data protection by design».

В отличие от GDPR, российский закон не детализирует технические меры — он оставляет выбор на усмотрение оператора с учётом характера обработки. Конкретные технические требования к защите ПДн устанавливает ФСТЭК России через приказ № 21 от 18 февраля 2013 года [11].

3. Почему «добавить потом» не работает

Одна из наиболее цитируемых оценок в сфере software engineering гласит, что исправление дефекта безопасности или приватности на этапе проектирования стоит примерно в 10–15 раз меньше, чем после релиза [12]. Это объясняется рядом причин.

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

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

В-третьих, культурный фактор. Команда, которая с первого дня думает «зачем нам это поле?», выстраивает иные инженерные привычки, нежели та, которая собирает «всё пригодится».

Согласно данным исследований в сфере GDPR, 97% приложений в ЕС по состоянию на 2024 год по-прежнему содержали так называемые dark patterns — интерфейсные решения, манипулирующие согласием пользователя [5]. Это свидетельствует о том, что даже в зрелой регуляторной среде приватность нередко остаётся декоративным элементом.

4. Архитектурные принципы: от теории к коду

4.1 Минимизация данных

Принцип: собирать только те данные, которые действительно необходимы для конкретной цели. Статья 5 Федерального закона № 152-ФЗ прямо закрепляет его как «обработка персональных данных, адекватных и не избыточных по отношению к целям» [10].

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

При разработке форм — запрашивать у пользователя только то, что нужно для выполнения конкретного действия. Если для регистрации достаточно email, номер телефона не запрашивается. Если профиль можно создать без даты рождения — дата рождения не запрашивается [13].

В API — response-модели не должны «утекать» лишние поля. Практика «вернуть весь объект и пусть клиент возьмёт что нужно» — антипаттерн с точки зрения PbD.

4.2 Псевдонимизация

Псевдонимизация — это процесс замены идентифицирующих атрибутов (имя, номер телефона, email, паспортные данные) на искусственные идентификаторы, при котором соответствие между псевдонимом и оригиналом хранится отдельно и защищённо [14].

В европейской трактовке (ст. 4(5) GDPR) псевдонимизированные данные остаются персональными, поскольку при наличии «дополнительной информации» субъект может быть идентифицирован. Однако их обработка существенно менее рискованна. Российский Федеральный закон № 152-ФЗ в статье 3 вводит понятие «обезличивание» — операция, после которой определить принадлежность данных конкретному субъекту становится невозможным. Это строже псевдонимизации и ближе к анонимизации [10].

Практические паттерны: хранение разных атрибутов субъекта в разных базах (разделение данных), использование UUID вместо реальных идентификаторов, токенизация — замена чувствительного значения на токен, при которой соответствие хранится в отдельной защищённой системе [13].

Важное предостережение: псевдонимизация не является самодостаточным методом. Она должна сочетаться с контролем доступа, шифрованием и организационными мерами [15].

4.3 Шифрование

Минимальный современный стандарт для передачи данных — TLS 1.3. Для хранения чувствительных данных в российских системах ФСТЭК рекомендует алгоритмы ГОСТ Р 34.10-2021 и ГОСТ Р 34.11-2021 [13]. Биометрические данные требуют дополнительного уровня защиты — рекомендуется рассмотреть использование специализированных HSM-модулей.

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

4.4 Контроль доступа

Принцип минимальных привилегий (least privilege principle): каждый сервис, каждый сотрудник, каждый подрядчик должен иметь доступ только к тем данным, которые ему реально нужны для выполнения своих функций.

На уровне БД это означает выделенные роли с ограниченным набором разрешений — никаких учётных записей с правами SELECT * FROM * для всего приложения. На уровне API — разграничение эндпоинтов по ролям и scope. На уровне логов — логирование фактов доступа к ПДн с возможностью последующего аудита. На уровне подрядчиков — явное описание доступа в договоре поручения обработки ПДн (статья 6 Федерального закона № 152-ФЗ) [10].

4.5 Lifecycle management — управление жизненным циклом данных

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

Политика хранения (retention policy) должна быть закреплена: для каждой категории ПДн — конкретный срок, по истечении которого данные удаляются или обезличиваются автоматически [16]. Для продуктов с неактивными пользователями — определённый порог (например, 2 года отсутствия активности), после которого аккаунт и связанные данные удаляются [17].

Механизм «права на удаление» (right to erasure) должен работать: запрос субъекта должен физически удалять или обезличивать данные во всех системах, включая бэкапы (с учётом сроков ротации бэкапов), логи и аналитические хранилища.

5. DPIA: оценка воздействия на приватность перед релизом

Data Protection Impact Assessment (DPIA) — это структурированный процесс выявления и оценки рисков для субъектов данных, возникающих при планируемой обработке [18]. В европейском GDPR он обязателен при высоком риске (ст. 35); в российском праве прямого аналога нет, но дух DPIA закреплён в требовании проводить оценку вреда субъектам ПДн в соответствии с методическими рекомендациями Роскомнадзора.

Ключевые случаи, когда DPIA необходима:

1. Масштабная обработка специальных категорий ПДн (здоровье, биометрия, политические взгляды).
2. Систематический мониторинг физических лиц в общедоступных местах.
3. Профилирование с автоматизированным принятием решений, влияющих на права субъектов.
4. Внедрение новых технологий обработки данных.
5. Любая операция с данными детей.

DPIA — не документ «для галочки». Распространённая ошибка: провести DPIA, получить список рекомендаций и забыть о нём. По словам специалистов Data Privacy Office, «важно воспринимать DPIA не как просто документ, а как процедуру, которая запускает переработку процессов изнутри и выявляет критические риски» [19].

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

6. Privacy by Default: что это значит для UX и бэкенда

Privacy by Default — это второй компонент концепции, тесно связанный с PbD. Он означает, что настройки системы по умолчанию должны обеспечивать максимальную защиту приватности. Пользователь не должен совершать никаких действий, чтобы быть защищённым: защита должна работать без его вмешательства [21].

На практике это значит следующее.

В UX — кнопка «принять только необходимые cookie» должна быть столь же заметна и доступна, как «принять все». Европейский совет по защите данных (EDPB) прямо указывает, что асимметрия в дизайне, при которой кнопка отказа скрыта или замаскирована, является нарушением принципа Privacy by Default [5].

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

В аналитике — по умолчанию не собирать данные сессий, если пользователь не дал на это явного согласия. Аналитические скрипты не должны инициализироваться до получения согласия на соответствующую категорию cookie.

В профилях — поля, которые пользователь не заполнил, не должны автоматически агрегироваться из других источников без его ведома.

7. Мастер-чек-лист: Privacy by Design перед релизом

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

Этап 1: Discovery (до написания ТЗ)

1. Определены ли категории персональных данных, которые будут обрабатываться (обычные, специальные, биометрические, данные детей)?
2. Для каждой категории ПДн определена конкретная, явная и законная цель обработки?
3. Определено правовое основание обработки каждой категории (согласие, договор, законный интерес, выполнение правового обязательства)?
4. Оценена необходимость проведения DPIA? Если да — инициирована ли процедура до начала разработки?
5. Определены ли третьи стороны (подрядчики, SaaS-сервисы, аналитические платформы), которые будут иметь доступ к ПДн?
6. Проверено ли, что серверы хранения данных находятся на территории РФ (в соответствии с ч. 5 ст. 18 Федерального закона № 152-ФЗ в редакции с 01.07.2025)?
7. Оценены ли риски для субъектов данных, а не только для компании?

Этап 2: Design (проектирование архитектуры)

1. Минимизирована ли схема данных — нет ли полей, добавленных «на всякий случай» без чёткого бизнес-обоснования?
2. Разделены ли идентифицирующие атрибуты (имя, телефон, email) и функциональные атрибуты в схеме БД?
3. Определена ли политика хранения (retention policy) для каждой таблицы/хранилища с ПДн?
4. Предусмотрен ли механизм удаления (и каскадного удаления) данных по истечении срока хранения или по запросу субъекта?
5. Спроектирован ли контроль доступа по принципу минимальных привилегий: роли БД, scope API, разграничение между микросервисами?
6. Определены ли алгоритмы шифрования для хранения и передачи чувствительных данных?
7. Предусмотрено ли разделение токена авторизации и данных пользователя?
8. Задокументированы ли потоки данных (data flow diagram) с указанием, где и какие ПДн обрабатываются?

Этап 3: Development (разработка)

1. Не хранятся ли ПДн в логах (application logs, access logs, error logs)?
2. Не передаются ли ПДн в URL-параметрах (query string)?
3. Реализован ли механизм согласия на сбор данных, разделённый по категориям?
4. Реализован ли механизм отзыва согласия с полным удалением данных?
5. Реализован ли экспорт данных по запросу субъекта (DSAR — Data Subject Access Request)?
6. Реализовано ли шифрование резервных копий?
7. Настроена ли ротация ключей шифрования?
8. Реализован ли аудит-лог доступа к ПДн с возможностью расследования инцидентов?
9. Не содержат ли тестовые окружения реальные ПДн (для тестов используются синтетические данные или обезличенные копии)?
10. Заключены ли договоры поручения обработки ПДн с подрядчиками, которые получают доступ к данным?

Этап 4: Pre-release (перед выходом в продакшн)

1. Проведён ли security review / penetration testing с фокусом на доступ к ПДн?
2. Обновлена ли политика конфиденциальности в соответствии с реальными практиками обработки?
3. Подана ли уведомление в Роскомнадзор об обработке ПДн (обязательно с 30 мая 2025 года в соответствии с Федеральным законом № 421-ФЗ)?
4. Разработан ли план реагирования на инциденты с ПДн (notification plan), включая требование уведомить Роскомнадзор в течение 24 часов, а субъектов — в течение 72 часов?
5. Прошли ли обучение члены команды, имеющие доступ к ПДн?
6. Соответствует ли UX принципу Privacy by Default: настройки по умолчанию — наиболее приватные?
7. Проверено ли, что аналитические скрипты и пиксели отслеживания не инициализируются без согласия?

Этап 5: Post-release (операционный контроль)

1. Есть ли процедура регулярного (не реже раза в год) пересмотра политики обработки данных?
2. Есть ли процесс отслеживания изменений в IT-ландшафте (новые поля в БД, новые сервисы, новые подрядчики)?
3. Есть ли актуальная карта данных (data map / RoPA), отражающая реальное состояние систем, а не только то, что было задокументировано при запуске?

8. Типичные ошибки и как их избежать

Ошибка 1: DPIA как разовый документ, а не процесс

Симптом: DPIA проведена на этапе запуска продукта и с тех пор не обновлялась, хотя продукт активно развивается.

Решение: DPIA — это живой документ. Любое существенное изменение обработки данных (новая фича, новый подрядчик, новый источник данных) должно триггерить пересмотр оценки [19].

Ошибка 2: ПДн в логах

Симптом: в строках лога встречаются email, имена, IP-адреса, токены сессий. Логи доступны широкому кругу разработчиков и хранятся в открытом виде.

Решение: фильтрация ПДн на уровне логгера; использование структурированного логирования с явным указанием полей; отдельные политики доступа и хранения для логов.

Ошибка 3: Согласие как юридическая формальность, а не технический контракт

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

Решение: согласие должно быть связано с конкретными операциями обработки на уровне кода. Если пользователь не согласился на аналитические cookie — скрипт аналитики не должен инициализироваться. Если пользователь отозвал согласие на email-рассылку — он должен автоматически удаляться из очереди рассылки.

Ошибка 4: Права субъекта не реализованы или реализованы «частично»

Симптом: по запросу на удаление данные удаляются из основной БД, но остаются в аналитической витрине, DWH, CDP и резервных копиях.

Решение: при проектировании права на удаление нужно составить карту всех мест хранения данного субъекта. Бэкапы требуют отдельного подхода: пока они не перезаписаны, данные формально присутствуют — это допустимо, если задокументировано и сроки ротации бэкапов разумны.

Ошибка 5: Зависимость от зарубежных SaaS без анализа последствий

Симптом: CRM, сервис email-рассылки, CDP, виджет поддержки — в иностранных юрисдикциях; российская база только «для галочки».

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

Ошибка 6: Тестирование на реальных данных

Симптом: для тестирования используется prod-дамп базы с реальными пользователями. Он передаётся разработчикам, попадает на личные ноутбуки, хранится в незашифрованных архивах.

Решение: тестовые данные — только синтетические или обезличенные. Это не только требование PbD, но и снижение поверхности атаки: большинство «инсайдерских» утечек происходит именно через dev/staging-среды.

Ошибка 7: Игнорирование подрядчиков как источника риска

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

Решение: договор поручения обработки ПДн (статья 6 Федерального закона № 152-ФЗ) должен содержать конкретный перечень операций, состав данных, требования по безопасности и обязательство незамедлительно уведомить оператора об инцидентах [10].

9. Примеры и кейсы

Кейс: Европейский опыт — Amazon и Meta

Штраф Amazon в размере 746 млн евро (2021) был выдан в том числе за отсутствие прозрачных механизмов согласия и неприменение принципа Privacy by Default в настройках обработки данных. Штраф Meta в 1,2 млрд евро (2023) — за трансграничную передачу данных без надлежащих правовых инструментов [5]. Оба случая демонстрируют: нарушения PbD — это не абстрактные риски, а миллиардные потери.

Кейс: Российский контекст — локализация данных

С 1 июля 2025 года популярные зарубежные инструменты — Google Analytics, Mailchimp, Notion, ряд CRM-систем — фактически не могут применяться без настройки буферных серверов на территории РФ [4]. Компании, не перестроившие инфраструктуру заблаговременно, оказались перед выбором: срочная миграция или нарушение законодательства.

Кейс: Тестовые среды как слабое звено

Согласно отраслевой практике и рекомендациям каталонского регулятора APDCAT, использование реальных ПДн в тестовых средах является одним из наиболее распространённых нарушений принципа минимизации [22]. Разработчики нередко имеют более широкий доступ к данным, чем сотрудники, непосредственно работающие с клиентами.

10. Тренды и будущее

AI Act и приватность по дизайну в системах ИИ

Европейский Акт об искусственном интеллекте (EU AI Act), вступивший в силу в августе 2024 года и вводящийся в действие поэтапно до 2026 года, прямо требует встраивания принципов приватности в системы ИИ высокого риска [5]. Это означает, что для российских компаний, экспортирующих продукты в ЕС или использующих зарубежные ИИ-компоненты, требования PbD становятся частью регуляторной нагрузки уже сегодня.

Privacy Engineering как профессия

Запрос на специалистов, способных встраивать приватность в реальные технические решения — а не просто пересказывать требования GDPR, — активно формируется. По данным профессиональных платформ, именно эта экспертиза — понимание шифрования, контроля доступа, архитектуры систем и управления рисками одновременно — становится востребованной дисциплиной [23].

Обезличивание как инструмент регуляторного соответствия

С 1 сентября 2025 года в России вступила в силу статья 13.1 Федерального закона № 152-ФЗ (введённая Федеральным законом № 233-ФЗ от 08.08.2024), регулирующая особенности обработки обезличенных ПДн. Операторы обязаны по запросу регулятора передавать обезличенные массивы данных в государственные информационные системы [24]. Это означает, что технические возможности обезличивания перестают быть опциональным улучшением — они становятся операционной необходимостью.

11. Как «Пятый фактор» помогает реализовать PbD в операционном режиме

Описанный выше чек-лист — это хорошая отправная точка. Но в реальности компании сталкиваются с другой проблемой: они не знают, что у них есть.

IT-ландшафт современной компании — десятки баз данных, CRM, 1С, почтовые серверы, API-интеграции с подрядчиками. Каждый день в схемах появляются новые поля, подключаются новые источники, добавляются новые сервисы. Провести разовый аудит и задокументировать «карту данных» — можно. Поддерживать её актуальной вручную — практически невозможно.

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

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

Для команд, которые выстраивают процессы в соответствии с чек-листом из этой статьи, Пятый фактор закрывает пункты 34 и 35: обеспечивает непрерывный мониторинг изменений в IT-ландшафте и поддерживает актуальную карту данных (RoPA), не требуя ручных проверок. Это позволяет раньше замечать новые риски — пока они не превратились в инцидент.

Заключение

Privacy by Design — это не проверочный список юридических требований, который нужно пройти перед сдачей в Роскомнадзор. Это инженерная дисциплина, начинающаяся с вопроса «зачем нам это поле?» и заканчивающаяся автоматическим удалением данных по истечении срока хранения.

В контексте российского законодательства 2025 года эта дисциплина обрела новое измерение: оборотные штрафы до 500 млн рублей делают стоимость игнорирования PbD конкретной и ощутимой. Требование локализации закрывает лазейки в виде «мы просто используем зарубежный облачный сервис».

Что делать дальше:

1. Пройтись по чек-листу применительно к текущему продукту — честно, без «мы это как-нибудь покроем».
2. Провести или обновить DPIA для ключевых операций с ПДн.
3. Составить реальную карту данных — где именно в вашей инфраструктуре живут персональные данные.
4. Внедрить retention policy с автоматическим удалением.
5. Проверить все подрядческие отношения с точки зрения договоров поручения.
6. Перевести тестовые среды на синтетические данные.

Приватность не конкурирует с функциональностью. Она конкурирует только с привычкой откладывать «скучные» вопросы на потом.

Источники

[1] КонсультантПлюс. Федеральный закон от 30.11.2024 № 420-ФЗ. Новые штрафы за нарушения в области персональных данных с 30 мая 2025 года — https://www.consultant.ru/legalnews/28492/

[2] RTM Group. Изменения в законе о персональных данных с 2025 года: новые штрафы за утечки — https://rtmtech.ru/articles/novye-shtrafy-za-utechki-pdn/

[3] Case Group. Новые штрафы за утечку персональных данных в 2025 году — https://case-group.ru/posts/novye-shtrafy-za-utechku-personalnyh-dannyh/

[4] B-152.ru. Закон о персональных данных: что изменилось в 2025 году — https://b-152.ru/zakon-o-personalnyh-dannyh-2025

[5] Secure Privacy. Privacy by Design & Default (GDPR): Implementation Guide — https://secureprivacy.ai/blog/privacy-by-design-gdpr-2025

[6] Wikipedia. Privacy by design — https://en.wikipedia.org/wiki/Privacy_by_design

[7] Global Privacy and Security by Design Centre. The Seven Foundational Principles — https://gpsbydesigncentre.com/the-seven-foundational-principles/

[8] OneTrust. The 7 Principles of Privacy by Design — https://www.onetrust.com/blog/principles-of-privacy-by-design/

[9] Ann Cavoukian. Privacy by Design: The 7 Foundational Principles (SFU) — https://www.sfu.ca/~palys/Cavoukian-2011-PrivacyByDesign-7FoundationalPrinciples.pdf

[10] КонсультантПлюс. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» (актуальная редакция) — https://www.consultant.ru/document/cons_doc_LAW_61801/

[11] Gendalf. Требования к документации по обработке ПД в 2024: руководство по ФЗ-152 — https://gendalf.ru/news/zpdn/zashchita-personalnyh-dannykh-v-2024-go/

[12] ComplyDog. Privacy by Design: GDPR Implementation Strategy — https://complydog.com/blog/privacy-by-design-gdpr-implementation-strategy

[13] Tproger. Что нужно знать о приватности данных в 2025, если вы разработчик — https://tproger.ru/articles/chto-nuzhno-znat-o-privatnosti-dannyh-v-2025--esli-vy-razrabotchik

[14] Центр цифровых прав. Privacy by Design и Privacy by Default по GDPR — https://drc.law/blog/privacy-by-design-i-privacy-by-default/

[15] КиберЛенинка. Проблематика применения метода псевдонимизации для защиты персональных данных — https://cyberleninka.ru/article/n/problematika-primeneniya-metoda-psevdonimizatsii-dlya-zaschity-personalnyh-dannyh-v-obrazovatelnom-uchrezhdenii-vysshego

[16] Piiano. Privacy by Design Checklist for Developers — https://www.piiano.com/blog/privacy-by-design-checklist

[17] Strac. Guide to GDPR Privacy by Design and Default: Checklist — https://www.strac.io/blog/guide-to-gdpr-privacy-by-design-and-default-checklist

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

[19] Data Privacy Office. DPIA на практике — https://data-privacy-office.com/services/provedenie-dpia/

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

[21] РАНХиГС ЦТДО. Способы обеспечения приватности (PbDD) — https://cdto.ranepa.ru/reports/ethics/2021/4-1-sposoby-obespecheniya-privatnosti

[22] APDCAT. Privacy by Design and Privacy by Default: A Guide for Developers — https://apdcat.gencat.cat/web/.content/03-documentacio/documents/guiaDesenvolupadors/GUIA-PDDD_EN.pdf

[23] Dev.by. Privacy Engineering: как строить системы, за которые не стыдно и не страшно — https://devby.io/news/privacy-engineering-v-2026-adviser-2026-03-09

[24] Business.ru. 152-ФЗ о персональных данных в 2025–2026 годах — https://www.business.ru/article/5705-152-fz-o-personalnyh-dannyh-gg