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

Собирайте меньше — теряйте меньше. Принцип минимизации ПДн в эпоху оборотных штрафов

Почему 2025 год — переломный для работы с данными

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

Именно эта логика теперь стоит компаниям до 500 миллионов рублей.

С 30 мая 2025 года в России вступили в силу поправки в Кодекс об административных правонарушениях (Федеральный закон № 420-ФЗ от 30.11.2024), которые радикально изменили масштаб ответственности за нарушения при работе с персональными данными [2]. Параллельно с декабря 2024 года в Уголовном кодексе появилась статья 272.1, криминализирующая незаконное обращение с персональными данными — до 10 лет лишения свободы за особо тяжкие случаи [5].

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

Материал будет полезен: директорам по ИТ и ИБ, DPO (ответственным за защиту данных), юристам, руководителям бизнеса, разработчикам и всем, кто строит процессы работы с данными.

Раздел 1. Что такое минимизация персональных данных и откуда она взялась

1.1. Правовая основа в России

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

Там же, в статье 5, установлены смежные принципы, образующие единую систему:

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

В 2025 году эти требования получили новое измерение: с 1 сентября 2025 года согласие на обработку персональных данных стало обязательно оформляться отдельным документом — «вшивать» его в общие пользовательские соглашения или договоры больше нельзя [6]. Кроме того, Роскомнадзор утвердил требования к методам обезличивания персональных данных (Приказ № 140 от 19.06.2025), что фактически вводит стандарты для технической реализации минимизации [7].

1.2. Международный контекст: GDPR и концепция Privacy by Design

На международном уровне принцип минимизации данных (data minimisation) закреплён в статье 5(1)(c) Общего регламента о защите данных ЕС (GDPR): персональные данные должны быть «адекватными, релевантными и ограниченными тем, что необходимо в отношении целей, для которых они обрабатываются» [8].

Но ещё глубже уходит корнями концепция Privacy by Design («конфиденциальность как проектное решение»), разработанная в 1990-х годах Энн Кавукян, тогдашним Уполномоченным по вопросам информации и конфиденциальности провинции Онтарио [9]. Её семь принципов включают проактивный подход, встроенную конфиденциальность по умолчанию и ориентацию на функциональность. Именно минимизация данных называется в академическом сообществе «необходимым и фундаментальным первым шагом» в инженерии приватных систем [9].

GDPR, принятый в 2018 году, закрепил Privacy by Design на законодательном уровне в статье 25: контролёр обязан с самого начала проектирования системы внедрять технические и организационные меры, включая псевдонимизацию, для обеспечения минимизации данных [8]. В 2024 году к этому добавился Акт об искусственном интеллекте ЕС (EU AI Act), Recital 69 которого специально оговаривает, что принципы минимизации и Privacy by Design применимы ко всему жизненному циклу ИИ-системы, включая обучение моделей [10].

1.3. Почему «собирать меньше» — это буквально безопаснее

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

Исследования подтверждают: организации, практикующие минимизацию данных, реже страдают от утечек и легче проходят проверки регуляторов [11]. Средняя стоимость одного инцидента с утечкой данных в мире в 2024 году составила 4,88 млн долларов по данным IBM Cost of a Data Breach Report [12]. Это число растёт с каждым годом. Сокращение объёма хранимых данных прямо влияет на снижение потенциального ущерба в случае взлома.

Есть и операционный эффект: компании используют в среднем лишь около 12% собранных данных, тогда как остальные 88% занимают место, требуют защиты и создают правовые риски без какой-либо бизнес-ценности [13].

Раздел 2. Масштаб проблемы: что происходит в России прямо сейчас

2.1. Статистика утечек: цифры, от которых сложно отмахнуться

По данным Роскомнадзора, опубликованным в феврале 2025 года, в 2024 году в России зафиксировано 135 фактов утечек персональных данных, содержащих более 710 миллионов записей [3]. Наибольшее число инцидентов — в торговле и сфере услуг. В 2025 году количество зафиксированных утечек сократилось до 118, однако в открытый доступ всё равно попало более 52 млн записей [3].

Важный нюанс: суммарные штрафы, начисленные за все эти нарушения в 2024 году, составили всего около 2 млн рублей [3]. Это не потому что проблемы не было — а потому что до мая 2025 года размеры штрафов были символическими. РЖД и «Почта России» как крупнейшие оштрафованные получили по 150 тысяч рублей каждая [14].

Ситуация кардинально изменилась с 30 мая 2025 года. Теперь та же утечка, затронувшая от 1 000 до 10 000 человек, грозит штрафом от 3 до 5 млн рублей для организации [2]. Утечка данных более 100 000 физических лиц — от 10 до 15 млн рублей. А повторная крупная утечка влечёт оборотный штраф: от 1 до 3% годовой выручки, но не менее 20 млн и не более 500 млн рублей [2].

Отдельно следует выделить:

• Штраф за неуведомление РКН об утечке в течение 24 часов — от 1 до 3 млн рублей для организаций [2].
• Штраф за отсутствие регистрации в реестре операторов персональных данных — от 100 до 300 тысяч рублей [6].
• Уголовная ответственность по статье 272.1 УК РФ — до 10 лет лишения свободы в особо тяжких случаях [5].

2.2. Кто в зоне риска

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

По словам эксперта по развитию МСБ Тимура Либермана, опубликованным на РБК, «есть ложное ощущение, что до малого бизнеса Роскомнадзор не дотянется. Но это вопрос времени» [15]. Регулятор планирует расширять круг проверок, и к 2026 году, по прогнозам специалистов, волна взысканий может накрыть и средний бизнес [7].

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

Раздел 3. Четыре измерения минимизации: что именно нужно ограничивать

Согласно руководящим документам Европейского совета по защите данных (EDPB, Guidelines 4/2019 по статье 25 GDPR) [8], минимизация распространяется на четыре ключевых измерения. Эта логика полностью применима и в российском правовом контексте.

3.1. Объём собираемых данных

Собирайте только те поля, без которых конкретная цель обработки недостижима. Если для оформления рассылки нужен только email — не берите телефон и дату рождения. Если для доставки заказа нужен адрес — не берите паспортные данные. Каждое дополнительное поле — это дополнительная ответственность, дополнительная площадь атаки и дополнительный риск штрафа.

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

3.2. Охват обработки

Минимизация означает не только ограничение сбора, но и ограничение того, что вы делаете с уже собранными данными. Данные, собранные для одной цели, не должны использоваться в других целях — это называется принципом ограничения цели (purpose limitation). Например, email, оставленный при оформлении заказа, нельзя автоматически использовать для маркетинговых рассылок без отдельного согласия.

3.3. Срок хранения

Большинство компаний создают базы данных, которые только растут. Никто никогда ничего не удаляет: «вдруг понадобится». Но статья 5 закона № 152-ФЗ прямо требует хранить данные не дольше, чем это необходимо для достижения заявленной цели [1]. Данные уволенного сотрудника должны быть удалены через срок, определённый законодательством. Данные потенциального клиента, который так ничего и не купил, — через разумный период.

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

3.4. Доступность: кто имеет доступ к данным

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

Согласно руководящим документам EDPB, при распределении доступа сотрудникам с разными ролями организация должна с самого начала проектировать систему так, чтобы обрабатывался минимально необходимый объём данных [8].

Раздел 4. Техническая и организационная реализация: пошаговое руководство

4.1. Шаг 1. Инвентаризация: что у вас вообще есть

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

Согласно методологии аудита ПДн [16], инвентаризация должна охватывать:

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

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

По данным юридической компании ЭБР, угроза крупных оборотных штрафов привела к тому, что российские компании стали вдвое чаще проводить аудит своих систем информационной безопасности в 2025 году по сравнению с весной 2024 года [17].

4.2. Шаг 2. Картирование потоков данных (Data Flow Mapping)

После инвентаризации необходимо понять, куда данные движутся внутри и за пределами организации. Типичная карта потоков данных для среднего бизнеса включает несколько десятков точек: форма на сайте → CRM → почтовый клиент → колл-центр → 1С → бухгалтерия → банк → архив. На каждом из этих этапов данные могут копироваться, трансформироваться и оседать в «тёмных углах» инфраструктуры.

Картирование помогает обнаружить:

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

4.3. Шаг 3. Определение необходимости каждого поля

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

1. Для какой конкретной цели нужны эти данные?
2. Какое правовое основание существует для их обработки (согласие, договор, закон)?
3. Как долго они должны храниться?

Этот документ — основа реестра обрабатываемых персональных данных, который теперь обязателен для всех операторов [6]. Реестр должен быть живым документом, а не архивной справкой: каждое изменение в ИТ-системах должно отражаться в нём.

4.4. Шаг 4. Технические меры: псевдонимизация, обезличивание и шифрование

Когда от хранения некоторых данных отказаться невозможно (например, они нужны для аналитики), применяют технические методы снижения рисков.

Псевдонимизация — замена прямых идентификаторов (имя, email, телефон) на псевдонимы или внутренние идентификаторы. Данные остаются полезными для анализа, но при утечке не позволяют немедленно идентифицировать конкретного человека. Псевдонимизация прямо упоминается как ключевой инструмент в статье 25 GDPR и в международных стандартах ISO/IEC 27701 [8].

Обезличивание идёт дальше: данные трансформируются так, что идентификация становится невозможной. С 1 сентября 2025 года в России введены стандартизированные методы обезличивания (Приказ РКН № 140 от 19.06.2025), и обезличенные данные могут передаваться в государственные информационные системы без согласия субъектов [7].

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

4.5. Шаг 5. Политика хранения и автоматическое удаление

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

Примеры конкретных сроков, которые должны быть регламентированы:

• данные кандидатов, не принятых на работу: как правило, не более 3 лет с момента отказа;
• данные клиентов после расторжения договора: согласно нормам гражданского и налогового законодательства (обычно 5 лет для документации);
• данные для маркетинговых рассылок: до отзыва согласия или достижения цели.

4.6. Шаг 6. Принцип минимальных привилегий в управлении доступом

Каждый сотрудник должен иметь доступ только к тем персональным данным, которые необходимы для выполнения его конкретных рабочих обязанностей. Это называется принципом наименьших привилегий (least privilege).

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

Раздел 5. Типичные ошибки и как их избежать

Ошибка 1. «Пусть лежит, вдруг пригодится»

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

Ошибка 2. Одно согласие на все случаи жизни

До сентября 2025 года многие компании практиковали единое согласие, в котором перечислялось всё подряд. Теперь согласие должно быть отдельным документом — не встроенным в договор, не «зашитым» в кнопку при регистрации, не предварительно проставленным чекбоксом [6]. Каждая самостоятельная цель обработки требует отдельного согласия.

Ошибка 3. Забытые интеграции и подрядчики

Интеграция с аналитическим сервисом, маркетинговой платформой или CRM-системой подрядчика означает, что данные клиентов передаются за пределы вашей инфраструктуры. Если договор поручения на обработку ПДн не заключён или заключён формально, ответственность за нарушения не снимается с оператора. Это особенно актуально для облачных сервисов, серверы которых могут быть расположены за пределами РФ — что с июля 2025 года прямо запрещено [3].

Ошибка 4. Статичный реестр

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

Ошибка 5. Имитация обезличивания

Удаление только имени или телефона из записи при сохранении остальных атрибутов (дата рождения + адрес + пол + история покупок) может не считаться реальным обезличиванием: совокупность признаков всё равно позволяет идентифицировать человека. Это называется проблемой квазиидентификаторов. Обезличивание должно проводиться в соответствии с утверждёнными методами [7].

Ошибка 6. Отсутствие проверки у новых разработчиков

При разработке нового функционала программисты нередко добавляют в базу данных поля, не задумываясь о правовых последствиях. Принцип Privacy by Design требует, чтобы вопрос «нужны ли нам эти данные?» задавался на этапе проектирования, а не после запуска в производство [9].

Раздел 6. Практический чек-лист по минимизации ПДн

Следующий чек-лист помогает провести первичную самооценку. Ответ «нет» на любой из пунктов — сигнал к немедленным действиям.

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

• ☐ Для каждого массива ПДн определены конкретные цели обработки
• ☐ Для каждой цели есть правовое основание (согласие, договор, закон)
• ☐ Согласия оформлены отдельными документами (требование с 01.09.2025)
• ☐ Нет согласий с предварительно проставленными галочками
• ☐ Компания внесена в реестр операторов РКН (обязательно с 30.05.2025)

Организационные меры:

• ☐ Ведётся актуальный реестр обрабатываемых персональных данных
• ☐ Определены и задокументированы сроки хранения каждой категории данных
• ☐ Назначен ответственный за организацию обработки ПДн
• ☐ Сотрудники обучены правилам работы с ПДн
• ☐ Есть процедура реагирования на утечку (включая уведомление РКН в течение 24 часов)

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

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

Контроль:

• ☐ Проводится регулярный (не реже раза в год) аудит соответствия
• ☐ Есть процедура для учёта изменений в ИТ-системах, влияющих на ПДн
• ☐ Карта потоков данных актуализирована

Раздел 7. Кейсы и примеры из практики

Кейс 1. Форма на сайте

Интернет-магазин при оформлении заказа собирал 12 полей: ФИО, email, телефон, дату рождения, пол, адрес доставки, паспортную серию, рост, вес и предпочтения по стилю. Из них для доставки и оформления договора реально нужны пять: имя, email, телефон, адрес. Остальные семь — «пусть лежат для аналитики».

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

Кейс 2. Медицина: аналитика без идентификации

Частная клиника хотела анализировать загруженность врачей и эффективность процедур. Первоначальная идея — выгружать из МИС (медицинской информационной системы) полные данные пациентов для BI-системы. Реализация принципа Privacy by Design предложила другой путь: агрегированные данные без привязки к конкретным пациентам (количество приёмов по специальностям, средняя продолжительность, процент повторных обращений). Цель аналитики достигается, персональные данные пациентов в BI-систему не попадают.

Кейс 3. SaaS-платформа и Privacy by Design

По данным SecurePrivacy, одна SaaS-компания реализовала минимизацию следующим образом: при регистрации пробного аккаунта запрашивались только email и название компании; неактивные пробные данные автоматически удалялись через 30 дней; для внутренней аналитики использовались псевдонимизированные идентификаторы. Результат: регистрация ускорилась на 40%, при этом соответствие требованиям GDPR сохранялось в полном объёме [4].

Раздел 8. Минимизация в контексте искусственного интеллекта и больших данных

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

EU AI Act 2024 года прямо признаёт это противоречие и предлагает выход: методы, позволяющие «приносить алгоритмы к данным» вместо переноса данных в единое хранилище — в частности, федеративное обучение (federated learning), при котором модель обучается на данных, не покидающих исходных систем [10]. Это позволяет совместить аналитические возможности с принципами минимизации.

В российском контексте организации, работающие с большими данными, должны отделять обезличенные массивы (с которыми можно работать свободнее) от массивов с прямыми идентификаторами. Новая статья 13.1 закона № 152-ФЗ, вступившая в силу с 1 сентября 2025 года, именно это и формализует: операторы могут передавать обезличенные данные в государственные информационные системы, где они используются для аналитики [6].

Раздел 9. Тренды и ближайшее будущее

Несколько тенденций, за которыми стоит следить в контексте минимизации ПДн в России:

Ужесточение проверок в 2026 году. По прогнозам экспертов ComNews, в 2026 году следует ожидать значительного роста числа штрафов — как по числу, так и по размерам, поскольку в 2025 году правоприменительная практика только формировалась [14]. Роскомнадзор и силовые структуры будут активнее использовать расширенные полномочия.

Стандартизация методов обезличивания. Приказ РКН № 140 от 19.06.2025 — начало формирования технических стандартов в России. В перспективе следует ожидать уточнения и расширения этих требований, сближения с международными практиками.

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

Персональная ответственность менеджеров. Введение уголовной ответственности (статья 272.1 УК РФ) и ужесточение штрафов для должностных лиц сигнализируют о постепенном переходе от корпоративной к персональной ответственности. DPO и директора по ИБ становятся реальными субъектами уголовного риска.

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

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

Именно эту проблему — «слепоту» в отношении собственного периметра персональных данных — решает платформа «Пятый фактор» (5factor.ru).

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

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

Для компаний, которые всерьёз занялись минимизацией ПДн, это означает:

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

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

Три принципа, которые меняют подход

Минимизация персональных данных — это не задача для юриста, которую нужно закрыть «пакетом документов». Это операционная дисциплина, требующая:

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

Второе: знать, что у вас есть прямо сейчас. Не год назад. Не в момент последнего аудита. Сегодня. Инфраструктура живёт, данные накапливаются, интеграции появляются. Непрерывная видимость — не роскошь, а гигиена.

Третье: создавать процессы, а не документы. Политика хранения, работающая только на бумаге, не защищает от штрафа. Нужны автоматические механизмы удаления, технические ограничения сбора, встроенные в разработку принципы Privacy by Design.

В России 2025–2026 годов цена бездействия измеряется не в теоретических рисках, а в конкретных суммах: до 500 миллионов рублей штрафа, до 10 лет лишения свободы за тяжкие нарушения, миллиарды — в репутационных потерях. Собирайте ровно то, что нужно. Это и есть минимизация.

Источники

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

[2] КонсультантПлюс: Новые штрафы за утечку персональных данных с 30 мая 2025 года — https://www.consultant.ru/legalnews/28492/

[3] TAdviser: Утечки данных в России, 2024–2025 — https://www.tadviser.ru/index.php/Статья:Утечки_данных_в_России

[4] SecurePrivacy: Privacy by Design GDPR Implementation Strategy (2025) — https://secureprivacy.ai/blog/privacy-by-design-gdpr-2025

[5] БУХ.1С: Штрафы за персональные данные с 30 мая 2025 года — https://buh.ru/articles/shtrafy-za-personalnye-dannye-s-30-maya-2025-goda-utechka-v-internet-neuvedomlenie-rkn-o-nachale-obr.html

[6] Клерк: 152-ФЗ о персональных данных — требования закона для бизнеса в 2026 году — https://www.klerk.ru/blogs/roskom24/674017/

[7] Русская Школа Управления: Новые правила работы с персональными данными с 1 сентября 2025 года — https://uprav.ru/blog/novye-pravila-raboty-s-personalnymi-dannymi/

[8] GDPR-Text.com: Guidelines on Article 25 Data Protection by Design and by Default — https://gdpr-text.com/guidelines/pbd/

[9] Wikipedia: Privacy by Design — https://en.wikipedia.org/wiki/Privacy_by_design

[10] IAPP: Data minimization: An increasingly global concept — https://iapp.org/news/a/data-minimization-an-increasingly-global-concept

[11] PDTN.org: Data Minimization Strategies: A Comprehensive Guide (2025) — https://pdtn.org/data-minimization-strategies/

[12] Business.com: How to Apply Data Minimization to Your Business (IBM Cost of a Data Breach 2024, ссылка в тексте) — https://www.business.com/articles/how-to-apply-data-minimization/

[13] WinZip / Nuix: Understanding Data Minimization (исследовательские данные о % используемых данных и поведении потребителей) — https://winzip.com/blog/enterprise/understanding-data-minimization/

[14] ComNews: В 2025 г. шесть компаний получили штрафы за утечки — в 2026 г. штрафов будет больше — https://www.comnews.ru/content/243497/2026-01-29/2026-w05/1008/2025-g-shest-kompaniy-poluchili-shtrafy-za-utechki-2026-g-shtrafov-budet-bolshe

[15] РБК Отрасли: Как новые законы изменят подход бизнеса к персональным данным — https://www.rbc.ru/industries/news/686fabc99a79472e5a66a3c5

[16] Cortel Blog: Как провести аудит защиты персональных данных — https://blog.cortel.cloud/2024/08/27/kak-provesti-audit-zashhity-personalnyh-dannyh-poshagovaya-instrukcziya/

[17] KSB-Soft: Как провести идеальный аудит (данные о росте спроса на аудит) — https://ksb-soft.ru/blog/ekspertiza/kak-provesti-idealnyy-audit/

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

[19] GDPR-Text.com: Article 5 GDPR — Principles relating to processing of personal data — https://gdpr-text.com/read/article-5/

[20] SEC.USSC.RU: Планируемые изменения Федерального закона № 152-ФЗ (сентябрь 2025) — https://sec.ussc.ru/152fz-changes