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

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

Почему это важно прямо сейчас

Представьте: команда разработчиков обновила форму регистрации — добавила поле «дата рождения» для возрастной верификации. Дизайн, фронтенд, backend — задача закрыта, тест пройден, деплой состоялся. Через три месяца приходит предписание Роскомнадзора: новое поле не отражено в политике обработки ПДн, для него нет правового основания, уведомление в реестр операторов не обновлено. Штраф, запрос документов, аудит — всё это из-за одного поля, которое никто не посчитал проблемой.

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

Ситуацию резко обострил 2025 год. В 2024–2025 годах в законодательство о персональных данных были внесены масштабные изменения — крупнейшие за последнее десятилетие [1]. Параллельно Роскомнадзор запустил ИИ-мониторинг веб-ресурсов, перейдя от ручных проверок к автоматическому непрерывному сканированию [24].

Эта статья — для технических специалистов, product-менеджеров, ДПО, специалистов по ИБ и руководителей, которые хотят понять: как устроен риск пропустить новый сбор ПДн после релиза, почему классические подходы не работают и что нужно сделать, чтобы контроль стал непрерывным, а не реактивным.

Что такое «новый сбор ПДн» и почему он возникает незаметно

Типичные сценарии появления нового сбора ПДн после релиза

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

Сценарий 1: добавление нового поля в существующую форму. Добавляется поле «профессия» в анкету подписки, «регион» — в форму обратной связи, «возраст» — в форму регистрации. Каждое из этих полей расширяет состав собираемых данных, что требует обновления политики и уведомления регулятора. Если у организации появится новый сайт или изменится деятельность, а документы не будут обновлены — за это налагаются штрафы [7].

Сценарий 2: подключение новой интеграции или виджета. Маркетинговая команда подключает CRM-систему, call-back виджет, чат-поддержку. Технически — несколько строк JavaScript, однако данные пользователей начинают уходить к третьей стороне. Интеграции сайта с зарубежными CRM-системами или почтовыми сервисами нарушают правила трансграничной передачи, если данные первично не обрабатываются в России: нарушением считается, например, форма обратного звонка, подключённая к иностранному сервису [19].

Сценарий 3: изменение схемы базы данных. Backend-разработчик добавляет новую колонку в таблицу пользователей: mobile_phone_secondary, passport_series, health_status. Новое поле появляется в БД, начинает заполняться через API, но в реестре операторов и внутренних регламентах его нет [18].

Сценарий 4: обновление SDK или библиотеки. Библиотека аналитики или A/B-тестирования обновляется до версии, в которой расширен список собираемых идентификаторов: добавляется fingerprint браузера, геолокация или хэш email. Frontend-приложения являются слепой зоной в информационной безопасности и практически всегда содержат персональные данные пользователей [23]. Команда не заметила изменений в changelog — никто не обновил юридические документы.

Сценарий 5: подключение нового подрядчика или API. Логистическая компания, колл-центр, платёжный шлюз — каждый новый получатель данных требует отдельного договора поручения и обновления политики. В случае передачи персональных данных третьим лицам оператор обязан получить отдельное согласие от субъекта [3].

Что считается персональными данными — шире, чем кажется

Распространённое заблуждение: персональные данные — это только ФИО, паспорт, СНИЛС. На практике понятие значительно шире. По 152-ФЗ персональными данными является любая информация, относящаяся прямо или косвенно к определённому или определяемому физическому лицу; обработкой — любое действие с такими данными, включая сбор, запись, систематизацию, хранение, передачу и уничтожение [11].

Под это определение подпадают: номер телефона, адрес электронной почты, IP-адрес при его возможной привязке к конкретному лицу, cookies и идентификаторы браузера, геолокация, история покупок в сочетании с другими данными, поведенческие паттерны на сайте [9]. Отдельную категорию составляют специальные данные: сведения о здоровье, биометрия, религиозные убеждения, судимости — к ним применяются повышенные требования [3]. Добавление даже «технического» поля, позволяющего идентифицировать человека, автоматически создаёт новый объём ПДн, требующий правового основания.

Регуляторный контекст: что изменилось в 2024–2025 годах

Новые штрафы и оборотная ответственность

Начиная с конца 2024 года регуляторное давление на операторов персональных данных в России резко возросло. Федеральный закон № 420-ФЗ от 30 ноября 2024 года внёс масштабные изменения в КоАП и УК РФ, вступившие в силу с 30 мая 2025 года [1].

С 30 мая 2025 года штрафы за утечки персональных данных составляют до 15 млн рублей; при повторных нарушениях — оборотный штраф в размере до 3% от годовой выручки, но не менее 20 млн и не более 500 млн рублей [5]. Штраф за нарушение обязанности уведомить о намерении обрабатывать ПДн составляет от 100 000 до 300 000 рублей; за неподачу уведомления об утечке — от 1 до 3 млн рублей [5, 6].

С декабря 2024 года в УК РФ появилась статья 272.1, устанавливающая уголовную ответственность за неправомерное обращение с персональными данными — например, их продажу или незаконное распространение [1].

Принципиально важно: с 2025 года ответственность оператора наступает независимо от того, кто технически виновен в утечке. Неважно, утекли данные из-за подрядчика, техподдержки или бывшего сотрудника — отвечать будет оператор [13]. Мораторий на внеплановые проверки прекратился с 1 января 2025 года; у Роскомнадзора появился широкий арсенал инструментов для выявления нарушений, включая мониторинг сайтов и обработку жалоб субъектов [8].

Автоматический мониторинг Роскомнадзора

Одно из ключевых изменений, которое многие компании ещё не осознали в полной мере: Роскомнадзор перешёл от ручных проверок к автоматическому ИИ-сканированию сайтов. Нейросеть самостоятельно находит нарушения и формирует отчёты [24].

С 1 июля 2025 года РКН автоматически проверяет сайты на наличие запрещённых виджетов, форм, чат-ботов и скриптов — Google Analytics, Google Карты, reCAPTCHA, виджеты мессенджеров и другие иностранные SaaS-элементы [19]. По словам заместителя руководителя РКН Вадима Субботина, автоматизированная система в среднем ежесуточно скачивает около 0,5 млн релевантных материалов; после последовательного анализа выявляется около 2000 материалов с нарушениями [25]. При этом эффективность нейросетей в тестовом режиме составила около 60% — технология продолжает развиваться [25].

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

Уведомление РКН при изменении состава обрабатываемых данных

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

Если после релиза на сайте появляется новая форма сбора данных или подключается сервис, передающий данные пользователей, уведомление в РКН необходимо обновить до начала такой обработки. Расхождение между реальным составом обрабатываемых данных и содержанием уведомления является самостоятельным составом нарушения [27].

Архитектура риска: почему компании пропускают новый сбор ПДн

Разрыв между разработкой и compliance

Корневая проблема не техническая — она организационная. В большинстве компаний DevOps/разработка и юридическая/ИБ-функции живут в параллельных мирах. Вопрос «создаём ли мы новый сбор ПДн?» в стандартный процесс разработки не включён.

Secure SDLC встраивает безопасность в каждый этап разработки с самого начала — это системный процесс, где каждый участник, от аналитика до DevOps-инженера, отвечает за безопасность своей части продукта; DevSecOps — прямое развитие этого подхода [14]. В рамках реализации концепции DevOps необходим анализ актуального среза законодательно-правовых актов с точки зрения обеспечения безопасности процесса непрерывной разработки и интеграции программных продуктов [21].

Проблема в том, что DevSecOps в российских компаниях чаще всего понимается как безопасность кода (SAST, DAST, проверка уязвимостей), но не как privacy-контроль — проверка на появление нового сбора ПДн. Это слепая зона [21].

Теневые данные (Shadow Data): поля, которых нет в реестре

«Теневые данные» в контексте ПДн — это поля, таблицы, хранилища, API, которые де-факто содержат или передают персональные данные, но не отражены в реестре оператора, политике обработки и согласиях. Они возникают органично:

1. Разработчик добавляет техническое поле для логирования — туда попадают IP, user agent, cookies.
2. Аналитик настраивает event-трекинг — события включают email или ID пользователя.
3. Backend добавляет индексированную колонку с телефоном — данные дублируются в новое место.
4. Интеграция с внешним сервисом начинает передавать расширенный профиль клиента.

Типовая задача: у компании десятки баз данных, тысячи таблиц, постоянно появляются новые и меняются имеющиеся — необходимо реализовать мониторинг того, где лежат персональные данные [18]. Без инструментов автоматического обнаружения ответ на вопрос «где у нас ещё есть ПДн?» занимает недели ручной работы и никогда не бывает полным.

Интеграции как слепая зона

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

Оператор не может просто собрать данные и забыть о них — необходимо постоянно следить за ними, обновлять способы защиты, вести документацию, готовиться к проверкам [22]. Штрафы за нарушение правил трансграничной передачи ПДн через непроверенные интеграции достигают до 6 млн рублей за первичное нарушение и до 18 млн рублей — за повторное [8].

Privacy by Design и DevSecOps — как встроить контроль в процесс разработки

Принципы Privacy by Design применительно к CI/CD

Privacy by Design (PbD) — концепция, разработанная Аннт Кавукян и получившая международное признание в 2010 году; в российском контексте она соответствует принципу минимизации данных из 152-ФЗ. Концепция предполагает, что операторы ПДн будут продумывать механизмы обеспечения приватности ещё на этапе планирования — и должна быть внедрена в процессы жизненного цикла разработки, в управление изменениями и в проектное управление [15].

Согласно философии Privacy by Design, лучший способ снизить риски, связанные с приватностью, — это не создавать их [15].

Применительно к CI/CD это означает: проверка на появление нового сбора ПДн должна быть встроена в пайплайн как обязательный gate — точно так же, как проверка безопасности кода или автоматические тесты. Релиз не должен происходить без прохождения privacy-checkpoint'а [16].

Shift Left: куда в процессе девелопмента встроить проверку ПДн

«Shift Left» в безопасности означает перенос контрольных точек как можно раньше в цикле разработки. SDLC реализует принцип Security by Design и является основой для DevSecOps, где ответственность за безопасность распределяется между всеми участниками цикла, а проверки автоматизированы и встроены в конвейер CI/CD. Внедрение SDLC позволяет перенести решение проблем безопасности «влево», что в десятки раз дешевле, чем исправление уязвимостей в готовом продукте или после инцидента [17].

В контексте ПДн «Shift Left» означает:

1. На этапе планирования (тикет, user story) — задать вопрос: затрагивает ли эта задача сбор, хранение или передачу ПДн?
2. На этапе проектирования — провести Privacy Impact Assessment для изменений, затрагивающих ПДн [12].
3. На этапе разработки — разработчик проверяет по чек-листу наличие нового сбора.
4. На этапе code review — ревьюер обращает внимание на новые поля, параметры API, изменения схемы БД.
5. На этапе CI/CD — автоматическое сканирование изменений схемы данных [16].
6. Перед релизом — обязательное согласование с ДПО или ответственным за ПДн.

Что должен содержать чек-лист ПДн-проверки перед релизом

Типовой чек-лист для разработчика или product manager перед деплоем, составленный на основе требований 152-ФЗ и актуальной правоприменительной практики [2, 12, 27]:

1. Добавляется ли в этом релизе новое поле, форма или параметр, содержащий данные пользователя?
2. Подключается ли новый внешний сервис, виджет или SDK, который получает данные пользователей?
3. Изменяется ли состав данных, передаваемых в существующие интеграции?
4. Появляется ли новый получатель ПДн (третья сторона)?
5. Затрагивает ли изменение специальные категории данных (здоровье, биометрия)?
6. Отражены ли все изменения в политике обработки ПДн?
7. Обновлено ли уведомление в Роскомнадзоре, если состав обрабатываемых данных меняется?
8. Оформлено ли согласие пользователя на новый вид обработки, если оно требуется?
9. Заключён ли договор поручения с новым получателем ПДн?
10. Проверено ли, что новый внешний сервис не передаёт данные на зарубежные серверы без уведомления РКН?

Практика: как выстроить контроль изменений на сайте и в интеграциях

Инвентаризация и карта ПДн как основа контроля

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

Карта ПДн должна как минимум включать:

1. Перечень всех точек сбора ПДн на сайте (формы, чат-боты, pop-up, личный кабинет, мобильное приложение).
2. Перечень всех таблиц и полей в БД, содержащих ПДн, с указанием владельца данных.
3. Перечень всех внешних интеграций с указанием передаваемых данных и правового основания.
4. Карту потоков данных: откуда, куда, через какие системы движутся ПДн.
5. Список подрядчиков и договоров поручения.
6. Сроки хранения по каждому виду данных.

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

Процесс контроля изменений: шаги и роли

Зрелый процесс контроля изменений выглядит следующим образом:

1. Каждый тикет, связанный с формами, БД или интеграциями, автоматически тегируется меткой privacy-review.
2. В шаблон pull request добавляется секция «Влияние на ПДн» — разработчик обязан её заполнить.
3. PR с меткой privacy-review требует дополнительного approve от ответственного за ПДн.
4. Перед релизом автоматическая проверка схемы БД сравнивает её с предыдущим состоянием и алертит об изменениях в таблицах, содержащих ПДн [18].
5. После релиза мониторинг новых endpoint'ов API проверяет передаваемые параметры на наличие чувствительных данных.
6. Результаты ежеквартально сверяются с действующим уведомлением в РКН и политикой обработки ПДн [4, 27].

Роли в процессе:

• Разработчик — заполняет секцию privacy-review в PR, знаком с чек-листом.
• Product manager — помечает задачи с потенциальным влиянием на ПДн на этапе планирования.
• ДПО / ответственный за ПДн — approve для PR с меткой privacy-review, ведёт карту ПДн.
• ИБ — настраивает автоматическое сканирование, получает алерты.
• DevOps — встраивает privacy-gates в CI/CD пайплайн [16].

Технические инструменты обнаружения и мониторинга

Ручной контроль не масштабируется при еженедельных релизах. Без автоматизации любой чек-лист превращается в формальность. Технический стек контроля должен включать несколько уровней.

На уровне кода: статический анализ (SAST) с правилами обнаружения работы с ПДн — добавление полей типа email, phone, passport, birth_date в миграции БД, появление новых API-параметров с чувствительными именами, подключение новых внешних зависимостей (SDK, npm-пакеты), которые известны как собирающие данные [14, 16].

На уровне инфраструктуры: мониторинг изменений схем данных, появления новых объектов сбора, хранения и передачи ПДн — стандартная задача инструментов корпоративного data discovery [18]. DCAP-система сканирует файловые ресурсы организации и уведомляет специалиста ИБ о конфиденциальной информации в неположенном месте; режим быстрого сканирования позволяет анализировать только новые файлы [20].

На уровне трафика: мониторинг исходящих запросов приложения для выявления передачи ПДн в новые домены или endpoint'ы. Инструменты класса DAM (Database Activity Monitoring) фиксируют обращения к таблицам с ПДн и выявляют аномальную активность.

На уровне внешнего периметра: периодическое автоматическое сканирование страниц сайта для выявления новых форм, скриптов и виджетов — аналог того, что делает РКН, только раньше регулятора. Важно проводить такой мониторинг после каждого релиза, а не по расписанию [24].

Типичные ошибки и риски — и как их избежать

Ошибка 1: «Это просто техническое поле, не ПДн». Разработчики нередко считают, что поле без явного ФИО не является ПДн. IP-адрес, cookie-идентификатор, device fingerprint могут быть признаны персональными данными в контексте их использования для идентификации пользователя [9, 11].

Ошибка 2: «Юристы узнают на следующем аудите». В модели непрерывной разработки ежеквартальный аудит создаёт окно уязвимости от нескольких недель до нескольких месяцев. За это время новый сбор ПДн может быть обнаружен РКН раньше, чем внутренней командой [7, 24].

Ошибка 3: «Подрядчик сам несёт ответственность». Ответственность оператора не делегируется договором поручения. Если произойдёт утечка через подрядчика — штраф получит оператор [22].

Ошибка 4: «Мы уже зарегистрированы в РКН, нового делать не нужно». Уведомление содержит конкретный перечень целей, категорий данных и получателей. Расхождение между реальностью и уведомлением — самостоятельный состав нарушения [27].

Ошибка 5: «Иностранный сервис только аналитику собирает». Нельзя использовать иностранные сервисы при работе с ПДн российских пользователей, в том числе Google Analytics для сбора информации на сайте [19]. Аналитические идентификаторы в сочетании с другими данными могут быть признаны ПДн [9].

Ошибка 6: «Мы используем Privacy by Design, так что всё под контролем». Принципы без инструментов — это декларация. Frontend-приложения являются слепой зоной в информационной безопасности [23]. Без технического мониторинга даже хорошо написанная политика безопасности остаётся документом.

Ошибка 7: «У нас нет утечек, значит нет нарушений». Нарушением является сам факт несоответствия обработки данных законодательству — без утечки. Неправильно оформленное согласие, избыточный сбор данных, отсутствие уведомления в РКН — всё это нарушения, обнаруживаемые при автоматическом сканировании [2, 6].

Кейсы: когда контроль подводит

Кейс 1. Маркетплейс не подал уведомление в РКН об обработке ПДн (ст. 22 152-ФЗ) и «всплыл» после утечки Excel-файла с телефонами клиентов. Получил два протокола: за отсутствие уведомления и за неуведомление об утечке. Примечательно, что утечка произошла не из-за взлома, а из-за некорректного контроля доступа к файлу — рутинная ошибка при разработке нового функционала экспорта [12].

Кейс 2. Небольшой D2C-бренд собирал e-mail для рассылок, но считал: «мы маленькие — уведомление не надо». По жалобе потребителя РКН запросил уведомление — его не было. Протокол по ч. 10 ст. 13.11 КоАП РФ [12].

Кейс 3. После аудита интернет-магазин убрал «скрытые согласия», внедрил баннер, прописал SDK, заключил допсоглашения с колл-центром и логистами, подал и обновил уведомление в РКН — прошёл контроль без протокола. Этот кейс показывает: проактивный подход работает [12].

Статистика масштаба проблемы. Согласно данным ГК «ИнфоВотч», в период с 2013 по 2024 год в российских организациях зафиксировано почти 5 000 утечек, в результате которых в открытый доступ попало около 4 млрд записей [10]. По информации Роскомнадзора, только в 2024 году зарегистрировано 135 инцидентов, в сеть утекло более 710 млн записей о россиянах [10]. Значительная часть инцидентов связана не с внешними атаками, а с внутренними процессами — некорректными настройками, избыточным сбором, несанкционированным доступом [10].

Что будет дальше: тренды регулирования и автоматизации

Тренд 1: дальнейшая автоматизация надзора. ИИ-мониторинг РКН только начинается — эффективность нейросетей в тестовом режиме составила около 60%, и ведётся работа над расширением обучающих датасетов [25]. По мере роста точности скорость реакции регулятора будет возрастать.

Тренд 2: обязательная передача обезличенных данных в государственную систему. Федеральный закон № 233-ФЗ от 08.08.2024 ввёл с 1 сентября 2025 года обязанность операторов передавать обезличенные данные в государственную информационную систему по запросам Минцифры [1].

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

Тренд 4: ужесточение требований к локализации. Запрещено использовать зарубежные CRM, облачные сервисы и другие инструменты для первичного сбора и обработки данных российских пользователей [6]. Штраф за несоблюдение — до 6 млн рублей за первое нарушение и до 18 млн рублей — за повторное [8].

Тренд 5: рост требований к документированию изменений. Роскомнадзор при проверках всё активнее запрашивает не только актуальные документы, но и историю изменений: когда обновлялась политика, как часто проводился аудит, есть ли журналы контроля [27]. История изменений состава ПДн должна быть зафиксирована.

«Пятый фактор» — непрерывный контроль ПДн без хранения сырых данных

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

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

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

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

В итоге компании получают:

1. Живую «карту ПДн» — актуальный реестр того, где и какие данные обрабатываются, с историей изменений.
2. Раннее обнаружение новых рисков — новые поля, интеграции, источники видны до того, как они превратились в инцидент или нарушение.
3. Непрерывный контроль как процесс — вместо разрозненных ручных проверок.
4. Готовность к проверке Роскомнадзора — документально подтверждённый аудиторский след изменений [7, 27].
5. Сокращение времени аудита — с недель до часов.

Это особенно актуально для компаний с частыми релизами, множеством интеграций и распределённой командой разработки — именно там разрыв между реальным состоянием ПДн и задокументированным наиболее велик [21].

Заключение

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

Вывод 1. Каждый релиз несёт риск нового сбора ПДн. В условиях автоматического мониторинга со стороны Роскомнадзора окно между релизом и выявлением нарушения сокращается до дней [24, 25].

Вывод 2. Privacy by Design и DevSecOps дают правильную методологию, но без инструментов остаются декларацией [14, 15]. Нужна живая карта ПДн, обновляемая автоматически при каждом изменении [18].

Вывод 3. Проактивность дешевле реактивности. При оборотных штрафах до 3% выручки цена бездействия для среднего бизнеса составляет десятки миллионов рублей [5, 9].

Что делать прямо сейчас: провести инвентаризацию точек сбора ПДн на сайте и в интеграциях, проверить актуальность уведомления в РКН, добавить privacy-checkpoint в процесс разработки и рассмотреть внедрение инструмента автоматического обнаружения изменений в составе ПДн.

Источники

[1] Новые требования Роскомнадзора по закону 152-ФЗ (на 30 мая 2025 года) — http://linkodium.com/news/novye-trebovaniya-roskomnadzora-po-zakonu-152-fz-na-30-maya-2025-goda/

[2] Персональные данные на сайте: новые правила с сентября 2025 (Гендальф) — https://gendalf.ru/news/marketing/kak-pravilno-zaprashivat-personalnye-dan/

[3] Согласие на обработку персональных данных с 1 сентября 2025 года (ГАРАНТ.РУ) — https://www.garant.ru/article/1862510/

[4] Изменения в работе с персональными данными в 2025 году (MIP Expert) — https://mip-expert.ru/articles/personalnye-dannye/izmeneniya-v-rabote-s-personalnymi-dannymi-v-2025-godu-/

[5] Персональные данные: новые штрафы с 30 мая 2025 года (КонсультантПлюс) — https://www.consultant.ru/legalnews/28492/

[6] Персональные данные 2025: новые правила для бизнеса (Пассворк) — https://passwork.ru/blog/piersonalnyie-dannyie-2025/

[7] Регистрация в Роскомнадзоре: изменения с 30 мая 2025 года (ГАРАНТ.РУ) — https://www.garant.ru/article/1814228/

[8] Локализация и трансграничная передача персональных данных. Что изменилось с 1 июля 2025 года (Comply) — https://comply.ru/tpost/c43ezsout1-lokalizatsiya-i-transgranichnaya-peredac

[9] Персональные данные 2026: локализация, уведомления Роскомнадзора и штрафы за утечки (PR-CY) — https://pr-cy.ru/news/p/10608-novye-trebovaniya-personal-dannye

[10] Утечки персональных данных в России 2025 (CISOclub) — https://cisoclub.ru/utechki-dannyh-realnye-kejsy-i-ih-posledstvija-dlja-reputacii/

[11] Как избежать штрафов в связи с поправками к закону о ПДн (Tilda Education) — https://tilda.education/articles-personal-data-law

[12] Что изменилось с 1 сентября 2025 года в области персональных данных для онлайн-бизнеса (HARANT) — https://harant.ru/blog/internet-pravo/chto-izmenilos-s-1-sentyabrya-2025-goda-v-oblasti-personalnyh-dannyh-dlya-onlajn-biznesa/

[13] Персональные данные: правила хранения и ответственность (UniSender) — https://www.unisender.com/ru/blog/personalnye-dannye-hranenie-i-nakazanie/

[14] Руководство по разработке безопасного ПО (Selectel) — https://selectel.ru/blog/secure-software-development/

[15] Privacy by Design: способы обеспечения приватности (РАНХИГС) — https://cdto.ranepa.ru/reports/ethics/2021/4-1-sposoby-obespecheniya-privatnosti

[16] DevSecOps в CI/CD: как встроить безопасность без замедления разработки (SecurityMedia) — https://securitymedia.org/info/devsecops-v-ci-cd-kak-vstroit-bezopasnost-bez-zamedleniya-razrabotki.html

[17] SDLC: безопасная разработка (SecPost) — https://secpost.ru/dictionary/sdlc

[18] Data discovery в корпоративном секторе (Begtin Substack) — https://begtin.substack.com/p/corporate-data-discovery-1

[19] Обработка персональных данных: новые требования с 01.07.2025 и 01.09.2025 (Клерк) — https://www.klerk.ru/blogs/fedresurs/658225/

[20] DCAP-система InfoWatch Data Discovery — https://www.infowatch.ru/products/dcap-sistema-data-discovery

[21] Проблемы реализации концепции DevSecOps в нормативно-правовом поле (ITSEC) — https://www.itsec.ru/articles/problemy-realizacii-koncepcii-devsecops-v-dejstvuyushchem-normativno-pravovom-pole

[22] Персональные данные в 2025 году: новые правила обработки и защиты для бизнеса (Nubes) — https://nubes.ru/blog/articles/personal-data-2025

[23] Secure software development lifecycle — SSDLC, DevSecOps (DPA Analytics) — https://dpa-analytics.ru/secure-software-development-lifecycle-SSDLC-DevSecOps

[24] Роскомнадзор и проверка сайтов (Клерк, data-sec) — https://www.klerk.ru/blogs/data-sec/677999/

[25] Алгоритмические упражнения: РКН и машинное обучение (Forbes) — https://www.forbes.ru/tekhnologii/553640-algoritmiceskie-upraznenia-rkn-budet-fil-trovat-trafik-s-pomos-u-masinnogo-obucenia

[26] Инвентаризация источников данных и карта данных (Datafinder) — https://datafinder.ru/products/inventarizaciya-istochnikov-dannyh-i-karta-dannyh

[27] Проверка Роскомнадзора в 2025 году: как подготовиться и избежать штрафов (Роском.Онлайн) — https://roskom.online/articles/proverki-roskomnadzora-na-chto-nuzhno-obratit-vnimanie/