Локализация ПДн и «первичная запись»: как проверить реальный маршрут данных

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

Почему «где хранятся данные» — это уже не теоретический вопрос

До 2025 года большинство юридических директоров и DPO отвечали на вопрос о локализации данных примерно так: «У нас есть уведомление в Роскомнадзоре, политика конфиденциальности на сайте и договор с облачным провайдером с российскими серверами». Это считалось достаточным.

Сегодня такой ответ влечёт реальный риск штрафа. Правила изменились по трём направлениям одновременно: появилось требование о первичной записи именно в России (а не просто наличии российской копии), резко выросли санкции — оборотные штрафы до 3% годовой выручки за повторные утечки [1], — и регулятор перешёл от плановых проверок к постоянному мониторингу через технические системы [2].

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

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

Материал будет полезен: ИТ-директорам, DPO, специалистам по информационной безопасности, юристам, отвечающим за compliance, и руководителям компаний, которые работают с данными граждан РФ.

Часть 1. Что изменилось: от «российской копии» к «первичной российской записи»

Краткая история требования о локализации

Требование хранить персональные данные граждан России на территории России появилось ещё в 2014 году — с принятием Федерального закона № 242-ФЗ, который вступил в силу 1 сентября 2015 года [3]. Тогда закон говорил о необходимости «записи, систематизации, накопления, хранения, уточнения (обновления, изменения), извлечения персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации».

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

Переломным стал 2025 год. 28 февраля 2025 года был опубликован Федеральный закон № 23-ФЗ, который изменил формулировку ч. 5 ст. 18 152-ФЗ. Поправки вступили в силу 1 июля 2025 года [4].

Что изменила новая редакция ч. 5 ст. 18 152-ФЗ

Суть изменения — в явном запрете первичного сбора персональных данных граждан РФ с использованием иностранных баз данных. Теперь в законе императивно установлено: первичная обработка (включая запись, систематизацию, накопление, хранение) должна происходить только на серверах, физически расположенных в России [5].

Ключевое отличие от прежней нормы: раньше компании могли спорить о том, считается ли создание российской копии выполнением требования. Теперь первая точка входа данных обязана находиться в России. Если пользователь заполнил форму, и данные сначала ушли в Salesforce (США), а потом скопировались в российскую базу — это нарушение, даже если российская копия существует [6].

Что считается «сбором» и «первичной записью»

Разъяснения Роскомнадзора от 24.03.2025 № 08-134789 и Минцифры от 12.05.2025 № П25-44929 уточнили: под «сбором» понимается первое получение данных оператором или его системами [7]. Это означает:

Если веб-форма на сайте отправляет данные напрямую в зарубежный SaaS — это нарушение. Если мессенджер-виджет принимает имя и телефон клиента и хранит их на иностранных серверах — нарушение. Если скрипт Google Analytics получает IP-адрес и поведенческие данные посетителя — нарушение [8].

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

Часть 2. Анатомия маршрута данных: где и как «первичная запись» может оказаться за рубежом

Типичные «точки утечки» в ИТ-архитектуре

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

Рассмотрим ключевые зоны риска.

Сайт и веб-аналитика. Это самая распространённая точка риска. Компания размещает на сайте скрипт аналитики (например, Google Analytics), и при каждом посещении страницы данные (IP-адрес, cookies, поведенческие паттерны) уходят напрямую на серверы в США. Пользователь ещё не нажал «Отправить» в форме — а его данные уже за рубежом [9]. Аналогичная ситуация с Google Tag Manager, Google Maps API, reCAPTCHA, Hotjar.

CRM-системы с иностранным хостингом. Форма обратного звонка или регистрации, подключённая напрямую к Salesforce, HubSpot или Bitrix24 с иностранными серверами, отправляет данные туда же, где находится основная база [10]. Даже если компания «знает», что данные потом копируются — первичная запись уже произошла за рубежом.

Чат-боты и виджеты поддержки. Виджет Intercom, Drift, Zendesk на сайте — при отправке первого сообщения имя и email пользователя уходят на серверы этих сервисов, которые физически находятся за пределами России.

Корпоративная почта. Использование Gmail, Outlook.com или других зарубежных почтовых сервисов для приёма заявок от клиентов означает, что данные из этих заявок первично хранятся за рубежом [11].

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

Плагины и расширения браузеров у сотрудников. Если сотрудник использует AI-ассистента для работы с базой клиентов, этот ассистент может через API передавать данные в зарубежный сервис [12]. Компания де-факто нарушает закон, хотя сотрудник действовал из лучших побуждений.

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

Скрытые потоки: почему «мы это не настраивали» не помогает

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

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

Часть 3. Инструменты проверки: как увидеть реальный маршрут данных

Уровень 1. Документарная инвентаризация

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

Реестр информационных систем ПДн. Каждая организация должна знать, в каких системах обрабатываются персональные данные: CRM, HR-система, бухгалтерия (1С), сайт, корпоративная почта, файловые хранилища, Active Directory/LDAP. Для каждой системы нужно знать: где физически расположены серверы (страна, ЦОД), какой провайдер, есть ли подтверждение локализации в договоре.

Карта потоков данных (Data Flow Diagram). Документ, который показывает, кто собирает данные, куда они передаются и в каком порядке. В отличие от реестра систем, карта потоков фиксирует именно движение — не хранение.

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

Уведомление в Роскомнадзоре. Текущая версия уведомления должна отражать актуальный состав обрабатываемых ПДн, системы, цели и трансграничные передачи. При смене хостинга или появлении новых интеграций уведомление нужно актуализировать [13].

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

Уровень 2. Технический анализ трафика

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

Анализ исходящего трафика сети. Инструменты класса NTA (Network Traffic Analysis) позволяют увидеть, с какими внешними IP-адресами и доменами устанавливаются соединения от корпоративных систем. Коммерческие решения уровня предприятий (ntopng, PRTG, SolarWinds, российские аналоги) формируют картину трафика в разрезе приложений и хостов [14]. Для точечных проверок можно использовать Wireshark.

По IP-адресам и доменам, с которыми устанавливаются соединения, можно определить географию серверов и идентифицировать потоки в иностранные сети. Особое внимание — на исходящие соединения в момент получения данных пользователей (заполнение форм, авторизация, транзакции).

Анализ веб-приложений. Для сайтов используется методология: открыть DevTools браузера, перейти на вкладку Network, имитировать заполнение форм и отслеживать все запросы, возникающие при отправке данных. Для каждого запроса нужно проверить: домен получателя, IP-адрес (геолокация), передаваемые параметры.

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

Облачные логи. Если инфраструктура размещена в облаке, провайдеры предоставляют журналы VPC Flow, которые фиксируют все сетевые соединения между компонентами системы и с внешним миром. Анализ этих логов позволяет увидеть нежелательные потоки данных за периметр [15].

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

Уровень 3. Аудит конкретных точек сбора данных

Помимо мониторинга всей сети, необходима точечная проверка каждой «точки сбора» ПДн.

Для каждой формы на сайте: куда отправляется POST-запрос при нажатии «Отправить», какие скрипты инициируются до отправки (могут передавать данные по мере ввода), есть ли интеграция с внешними сервисами.

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

Для корпоративных инструментов: какие SaaS-продукты используют сотрудники, имеют ли они доступ к персональным данным клиентов, какова политика хранения в каждом из этих продуктов.

Уровень 4. Контроль изменений

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

Постоянный контроль предполагает:

• Реестр изменений с обязательным согласованием для всех новых интеграций.
• Автоматический мониторинг новых внешних соединений (NTA-системы могут оповещать при появлении соединений с новыми доменами).
• Периодические технические аудиты (минимум раз в год или при значимых изменениях инфраструктуры) [16].
• Обучение сотрудников: понимание того, что установка нового плагина или расширения может быть нарушением закона.

Часть 4. Трансграничная передача после первичной записи: что разрешено

Принцип «сначала Россия»

Новая редакция закона не запрещает трансграничную передачу данных. Она запрещает первичную запись за рубежом. Это принципиальное различие [7].

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

Для легальной трансграничной передачи необходимо [17]:

• Наличие правового основания (согласие, договор, международный договор и т.д.).
• Уведомление Роскомнадзора о намерении осуществлять трансграничную передачу (до её начала).
• Для стран без «адекватного» уровня защиты — оценка мер защиты у иностранного получателя.

Роскомнадзор ведёт перечень стран с адекватным уровнем защиты. Для передачи в эти страны процедура упрощена. Для «неадекватных» юрисдикций (США, большинство стран без ратифицированной Конвенции о защите физических лиц в отношении автоматизированной обработки данных) требуется более детальное обоснование.

Типичные ошибки в трансграничной передаче

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

Другая ошибка — неактуальное уведомление. При добавлении нового иностранного сервиса или изменении состава передаваемых данных уведомление в РКН нужно актуализировать. С 1 августа 2024 года в перечень индикаторов риска добавлены факты неуведомления о трансграничной передаче [4].

Часть 5. Санкции: почему это важно именно сейчас

Новый масштаб штрафов

С 30 мая 2025 года вступили в силу поправки, внесённые Федеральным законом № 420-ФЗ от 30.11.2024. Размер штрафов вырос кратно [18]:

За нарушение требований о локализации (хранение данных за рубежом): первое нарушение — от 1 до 6 млн рублей, повторное — от 6 до 18 млн рублей.

За утечку персональных данных: размер штрафа зависит от объёма данных и числа пострадавших субъектов. За повторную утечку — оборотные штрафы от 1% до 3% годовой выручки в пределах от 20 до 500 млн рублей [19].

За неуведомление Роскомнадзора об утечке: для организаций — от 1 до 3 млн рублей.

Введена уголовная ответственность за незаконное использование и распространение персональных данных: лишение свободы до 5 лет, а за создание специализированных ресурсов для незаконного хранения данных — до 10 лет [20].

Практика контроля

Роскомнадзор использует систему «Ревизор», которая отслеживает местоположение серверов и анализирует маршруты трафика [21]. Мораторий на внеплановые проверки завершился 1 января 2025 года, и регулятор получил расширенные инструменты обнаружения нарушений: мониторинг сайтов, направление запросов, работа с жалобами субъектов.

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

Часть 6. Практический чек-лист: как проверить реальный маршрут данных

Шаг 1. Инвентаризация точек сбора ПДн

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

• Формы на сайте (регистрация, обратный звонок, подписка, заказ).
• Мобильные приложения.
• Корпоративная почта.
• Офлайн-точки сбора (бумажные анкеты, терминалы).
• API-интеграции с партнёрами.
• Рекрутинговые порталы и HR-системы.
• Системы аналитики и веб-трекеры.

Шаг 2. Для каждой точки — определить первую точку записи

Для веб-форм: открыть DevTools, вкладку Network, имитировать отправку → проверить все запросы, возникающие при нажатии кнопки. Для каждого запроса: куда идёт (домен/IP), какие данные передаются. Геолокация IP — через whois или IP-геолокационные сервисы.

Для CRM и SaaS: проверить в договоре с провайдером, где физически хранятся данные. Если договор молчит — искать в документации провайдера «data residency» или «data storage location». Если данные хранятся не в России — необходимо настроить промежуточный российский слой.

Для корпоративной почты: если используется Gmail, Outlook.com или аналоги — данные из писем физически хранятся за рубежом. Для первичного приёма данных клиентов это нарушение.

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

Шаг 3. Технический мониторинг исходящего трафика

Настроить анализ исходящего трафика сети на предмет соединений с иностранными хостами, которые возникают в момент обработки пользовательских данных. Особое внимание — на порты 443 (HTTPS) и нестандартные порты, которые могут использоваться для передачи данных.

Зафиксировать базовый список «легитимных» внешних соединений и настроить оповещения при появлении новых.

Шаг 4. Проверка облачной инфраструктуры

Если данные хранятся в облаке — убедиться, что выбран регион российского ЦОД, а не иностранный регион с последующей репликацией. Запросить у провайдера подтверждение (в виде документа или технического заключения) о том, что данные физически не покидают территорию России.

Проверить настройки резервного копирования: резервные копии тоже должны храниться в России [22].

Шаг 5. Аудит подрядчиков и интеграций

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

Шаг 6. Документарное закрепление

Актуализировать уведомление в Роскомнадзоре с учётом всех обнаруженных систем и потоков. Если выявлена трансграничная передача — подать или обновить уведомление о трансграничной передаче. Обновить политику обработки персональных данных. Зафиксировать архитектуру потоков данных в виде схемы и поддерживать её актуальной.

Часть 7. Частые ошибки и как их избежать

Ошибка 1. «Мы сделали российскую копию — значит, всё в порядке»

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

Ошибка 2. «У нас есть уведомление о трансграничной передаче»

Уведомление о трансграничной передаче легализует движение данных из России за рубеж. Оно не легализует первичный сбор за рубежом.

Ошибка 3. «Мы используем только российские сервисы»

Российские SaaS-сервисы могут иметь иностранные компоненты (CDN, зарубежные субпроцессоры, резервное копирование за рубежом). Нужно проверять не только юридическую прописку провайдера, но и физическое расположение серверов, где хранятся данные.

Ошибка 4. «Сотрудники — это не оператор»

Сотрудник, использующий личный инструмент (AI-ассистент, зарубежный Notion для работы с контактами клиентов), де-факто обрабатывает персональные данные от имени работодателя. Ответственность несёт организация.

Ошибка 5. «Cookie — это не персональные данные»

Роскомнадзор на практике признаёт cookies персональными данными, если они позволяют идентифицировать пользователя. Сервисы, получающие cookies первично за рубежом, создают риск нарушения [23].

Ошибка 6. «Мы маленькие — нас не проверят»

Автоматический мониторинг сайтов системой «Ревизор» не зависит от размера компании. Жалобы субъектов тоже не зависят от размера. С 2025 года под зону видимости регулятора попадают и небольшие сайты [24].

Ошибка 7. «Аудит сделан — можно успокоиться»

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

Часть 8. Сложные случаи и спорные ситуации

Гибридные облака и geo-distributed системы

Крупные облачные провайдеры (AWS, Microsoft Azure, Google Cloud) имеют регионы в России. Но недостаточно просто выбрать «регион Россия» — нужно убедиться, что конкретные данные не реплицируются автоматически в другие регионы по умолчанию. Это технический вопрос конфигурации, который требует проверки у провайдера и документального подтверждения.

API-интеграции и «обратный» поток

Сложный случай: данные поступают от иностранного партнёра к российскому оператору. Разъяснения регуляторов указывают: если данные касаются граждан РФ и направляются в Россию от иностранного партнёра, оператор должен обеспечить их локальную фиксацию в российской базе данных [6]. Таким образом, обратный поток также требует анализа.

Сервисы обмена сообщениями

Использование Telegram, WhatsApp (запрещён в России как организация, но его сервисы доступны) или других мессенджеров для приёма обращений от клиентов означает, что данные первично сохраняются на серверах этих сервисов, расположенных за рубежом. Решение: настройка интеграции через webhook на российский промежуточный сервер, который принимает данные первым.

Server-side tagging

Практическое решение для сохранения функциональности инструментов аналитики при соблюдении требований локализации — server-side tagging. Вместо того чтобы скрипты аналитики напрямую отправляли данные в иностранный сервис, браузер отправляет данные на российский промежуточный сервер (Tag Server), который уже затем ретранслирует их в нужные сервисы. Это законная схема при наличии уведомления о трансграничной передаче [25].

Часть 9. Тренды и что ожидать дальше

Усиление технического мониторинга

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

Обезличивание и ГИС Минцифры

С 1 сентября 2025 года операторы обязаны по запросу регулятора передавать обезличенные персональные данные в государственную информационную систему Минцифры [22]. Для выполнения этого требования операторы должны применять только методы обезличивания из приказа Роскомнадзора № 140: введение идентификаторов, изменение состава и семантики, перемешивание, декомпозиция, преобразование.

Новое требование о раздельном хранении

Приказ Роскомнадзора № 140 вводит требование о раздельном хранении исходных ПДн — резервные копии и DR-сайты не могут быть единым хранилищем. Необходимо три разных сегмента с разными правами доступа [22]. Это существенно меняет архитектурные требования к инфраструктуре хранения данных.

Рост требований к непрерывному контролю

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

Часть 10. Как выстроить устойчивый процесс контроля над ПДн

Разовый аудит и «приведение в порядок» документов — это реакция на изменившийся закон. Устойчивое соответствие требует другого: постоянного, автоматизированного контроля.

Что это означает на практике:

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

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

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

Непрерывный мониторинг рисков. Вместо квартальных или годовых аудитов — постоянный контроль с оповещениями о новых рисках.

Именно здесь на помощь приходит технология класса DSPM (Data Security Posture Management) — автоматизированное обнаружение, инвентаризация и контроль персональных данных в корпоративных системах.

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

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

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

Конкретные следующие шаги:

1. Провести инвентаризацию всех точек сбора персональных данных — сайт, приложения, CRM, почта, мессенджеры.
2. Для каждой точки технически проверить первую точку записи данных (DevTools, анализ трафика, проверка договоров с провайдерами).
3. Идентифицировать все интеграции с иностранными сервисами и оценить, является ли первичная запись в них нарушением.
4. Устранить нарушения: настроить server-side tagging, перевести первичный сбор на российский слой, заменить или реструктурировать опасные интеграции.
5. Обновить уведомление в Роскомнадзоре и, при необходимости, подать уведомление о трансграничной передаче.
6. Выстроить процесс непрерывного контроля над изменениями ИТ-ландшафта, затрагивающими персональные данные.

«Пятый фактор»: непрерывный контроль над картой персональных данных

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

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

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

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

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

Источники

[1] Федеральный закон от 30.11.2024 № 420-ФЗ «О внесении изменений в Кодекс Российской Федерации об административных правонарушениях» — https://www.consultant.ru

[2] Riverstart — Разбор поправок в 152-ФЗ: новые требования к персональным данным с 30 мая 2025 — https://riverstart.ru/blog/novyie-trebovaniya-kpersonalnyim-dannyim-v2025-pravila-rabotyi-dlya-biznesa-s152-fz

[3] КонсультантПлюс — Федеральный закон от 21.07.2014 N 242-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_165838/

[4] Б1 — Новые правила по локализации персональных данных граждан РФ — https://b1.ru/insights/law-messenger/localization-of-personal-data-of-russian-citizens-6-march-2025/

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

[6] b-152.ru — Хранение персональных данных за границей: что разрешено, что запрещено и как соблюсти локализацию в 2025 году — https://b-152.ru/hranenie-personalnyh-dannyh-za-granicej

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

[8] roskom24.ru — Что запрещено на сайте с 1 июля 2025 — https://roskom24.ru/chto_zapreshcheno_na_sayte_s_1_iyulya_2025/

[9] Kickidler — Трансграничная передача ПДн в 2025: что именно под запретом — https://www.kickidler.ru/info/transgranichka-v-2025-godu-kak-gotovitsya-k-novyim-pravilam-po-googlemeta-skriptam-i-inostrannyim-crm

[10] KT Team — Новые правила обработки ПДн в 2025 году: штрафы, согласие, уведомление Роскомнадзора — https://www.kt-team.ru/blog/personal-data-processing-2025-avoid-fines

[11] HostInside — Проверка сайта на 152-ФЗ — полное руководство 2025 — https://hostinside.ru/blog/152fz/

[12] IC-Tech — Трансграничная передача персональных данных: как соблюдать 152-ФЗ — https://ic-tech.ru/blog/knowledge-base/transgranichnaya-peredacha-personalnyh-dannykh-kak-soblyudat-152-fz/

[13] vc.ru — Как уведомить Роскомнадзор об обработке персональных данных — https://vc.ru/life/2019058-uvedomlenie-roskomnadzora-ob-obrabotke-personalnyh-dannyh

[14] Blog.infra-tech.ru — Мониторинг трафика: архитектура, NetFlow/PCAP, обнаружение угроз и NDR-системы — https://blog.infra-tech.ru/monitoring-setevogo-trafika/

[15] DLP-Блог — Что такое анализ сетевого трафика и зачем бизнесу этот инструмент — https://sprutmonitor.ru/blog/chto-takoe-analiz-setevogo-trafika-i-zachem-biznesu-jetot-instrument/

[16] RTM Group — Аудит на соответствие 152-ФЗ — https://rtmtech.ru/services/audit-152-fz/

[17] CisoClub — Трансграничная передача персональных данных: правовые основания — https://cisoclub.ru/transgranichnaja-peredacha-pdn-pravovye-osnovanija/

[18] IC-Tech — Штрафы за нарушения 152-ФЗ с 30 мая 2025 года — https://ic-tech.ru/blog/knowledge-base/shtrafy-za-narusheniya-152-fz-s-30-maya-2025-goda/

[19] DialogNauka — Штрафы выросли, 152-ФЗ прежний: топ ошибок в персональных данных — https://dialognauka.ru/press-center/posts/articles/shtrafy-vyrosli-152-fz-prezhniy-top-oshibok-v-personalnykh-dannykh-i-kak-ikh-predotvratit/

[20] Правовест Аудит — Обработка персональных данных: изменения с 30.05.2025 — https://pravovest-audit.ru/nashi-statii-nalogi-i-buhuchet/izmeneniya-v-obrabotke-personalnykh-dannykh-s-30-maya-2025-goda/

[21] vc.ru — Новые требования РКН в 2025: как пройти проверку и избежать штрафов за локализацию — https://vc.ru/legal/2149867-novye-trebovaniya-rkn-2025-kak-izbezhat-shtrafov-za-lokalizatsiyu-dannyh

[22] РБК Компании — Как работать с персональными данными в 2025 году: изменения с 1 сентября — https://companies.rbc.ru/news/BSZ231iAod/kak-rabotat-s-personalnyimi-dannyimi-v-2025-godu-izmeneniya-s-1-sentyabrya/

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

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

[25] Lidings — С 01.07.2025 г. вступает в силу закон, ужесточающий требования о локализации персональных данных граждан РФ — https://www.lidings.com/ru/media/legalupdates/localization_pd_update/