Автор: Артем Курнев. Материал актуален на 3 августа 2026 года.

• Что изменилось с 1 июля 2025 года
• Согласие пользователя не отменяет локализацию
• Зарубежный сервер и трансграничная передача — разные юридические вопросы
• Можно ли сначала записать данные в России, а затем отправить за рубеж
• Правила трансграничной передачи изменились 26 июля 2026 года
• Зарубежные CRM, облака и SaaS
• Можно ли держать резервную копию за границей
• А если зарубежный сервис работает на серверах в России
• Собственный сервер компании за рубежом
• Удаленный доступ иностранной техподдержки
• Что с e-mail, мессенджерами и зарубежными AI-сервисами
• Что считается персональными данными
• Ответственность за зарубежную базу
• Правоприменение в 2026 году
• Как безопасно построить IT-архитектуру
• Что проверить в договоре с хостингом или облаком
• Частые вопросы
• Вывод

Федеральный закон от 28 февраля 2025 года № 23-ФЗ изменил часть 5 статьи 18 Закона № 152-ФЗ. До поправок бизнес часто строил модель «первичная запись в России, затем рабочая копия за рубежом» и трактовал локализацию достаточно широко. Новая редакция стала жестче: при сборе нельзя использовать зарубежные базы для записи, систематизации, накопления, хранения, уточнения и извлечения данных российских граждан.

Минцифры в письме от 12 мая 2025 года № П25-44929 отдельно разъяснило применение поправок. Ведомство указало, что последующая трансграничная передача данных, которые были ранее собраны с использованием баз в России, сама по себе не запрещена. Но хранение и уточнение персональных данных граждан РФ, включая их копии, должны осуществляться с использованием баз данных, расположенных в Российской Федерации.

Одна из самых частых ошибок — включить в согласие фразу «разрешаю хранить данные за пределами Российской Федерации» и считать вопрос решенным. Это не работает.

Часть 5 статьи 18 делает исключения только для пунктов 2, 3, 4 и 8 части 1 статьи 6 Закона № 152-ФЗ. Обычное согласие субъекта находится в пункте 1 статьи 6, а исполнение договора с клиентом — в пункте 5. Следовательно, согласие покупателя, клиента или работника само по себе не позволяет перенести первичную базу на зарубежный сервер.

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

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

Да, сама последующая передача ранее локализованных данных за границу законом не исключена. Это прямо следует из разъяснения Минцифры от 12 мая 2025 года. Но такая операция должна одновременно отвечать требованиям статьи 12 Закона № 152-ФЗ о трансграничной передаче.

До начала трансграничной передачи оператор обязан направить в Роскомнадзор отдельное уведомление. Оно не заменяет обычное уведомление об обработке персональных данных по статье 22 и подается именно как самостоятельная процедура.

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

С 26 июля 2026 года статья 12 Закона № 152-ФЗ действует в обновленной редакции Федерального закона № 265-ФЗ. Ключевое практическое значение имеет перечень иностранных государств, обеспечивающих адекватную защиту прав субъектов персональных данных, который утверждает Роскомнадзор.

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

Самый высокий риск возникает, когда иностранный сервис по своей архитектуре хранит рабочую клиентскую базу за пределами России. Это типично для CRM, helpdesk, систем рассылки, облачных таблиц, HR-платформ, сервисов аналитики и некоторых конструкторов сайтов.

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

• форма заявки сразу отправляет телефон клиента в иностранную CRM;
• зарубежный helpdesk хранит обращения пользователей с ФИО и контактами;
• HR-система иностранной группы содержит личные дела российских работников;
• облачная таблица на зарубежной инфраструктуре используется как постоянная клиентская база;
• резервная копия российской CRM автоматически выгружается в иностранное облако;
• зарубежный AI-сервис получает промпты с ФИО, телефонами, паспортными или медицинскими данными клиентов.

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

После разъяснения Минцифры 2025 года резервная копия с персональными данными граждан РФ на зарубежном сервере стала особенно рискованной конструкцией. В письме прямо указано, что хранение, в том числе копий, должно осуществляться с использованием баз данных в России.

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

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

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

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

При этом вопрос о трансграничной передаче нужно анализировать отдельно, поскольку определение статьи 3 Закона № 152-ФЗ связывает ее с передачей данных на территорию иностранного государства иностранному органу, физическому или юридическому лицу. То есть одна и та же архитектура может нарушать локализацию независимо от того, возникает ли дополнительно трансграничная передача конкретному иностранному получателю.

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

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

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

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

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

• ФИО, телефон, e-mail, адрес доставки;
• данные работника, резюме и сведения о зарплате;
• IP-адрес и иные идентификаторы — если в конкретной системе они позволяют связать данные с пользователем;
• идентификатор клиента в CRM в совокупности с иными сведениями;
• история заказов, обращения в поддержку, записи разговоров;
• медицинские, биометрические и иные специальные категории данных — с дополнительными требованиями закона.

Нарушение локализации образует отдельный состав по части 8 статьи 13.11 КоАП РФ. Для юридического лица штраф за первое нарушение составляет от 1 до 6 млн рублей. Повторное нарушение по части 9 — от 6 до 18 млн рублей.

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

Требование о локализации применяется не только к российским компаниям. В 2026 году Роскомнадзор активизировал дела против зарубежных игровых издателей, которые собирают данные российских пользователей.

По опубликованным в мае 2026 года сведениям, суды уже признали виновными в невыполнении требований о локализации Electronic Arts, Take-Two Interactive Software, NetEase Interactive Entertainment и Battlestate Games Limited; каждой компании назначался штраф 2 млн рублей. Роскомнадзор также направлял в суд материалы в отношении других зарубежных игровых компаний.

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

1. Составить карту всех точек сбора: сайт, приложение, CRM, телефония, чат, рассылка, HR, аналитика, формы и боты.
2. Для каждой точки определить, где создается первая запись о пользователе и где физически расположена база.
3. Перенести первичную и рабочую базу персональных данных россиян в российский дата-центр.
4. Проверить резервные копии, логи и технические хранилища: они не должны незаметно создавать зарубежную копию базы.
5. Определить все иностранные сервисы, которым передаются данные или предоставляется доступ.
6. Проверить правовое основание для каждой передачи и минимизировать состав передаваемых данных.
7. До начала трансграничной передачи подать отдельное уведомление в Роскомнадзор и собрать сведения об иностранном получателе.
8. Обновить политику обработки ПД, согласия, договоры поручения обработки и внутренний реестр информационных систем. Для комплексной договорной и регуляторной работы см. юридические услуги для бизнеса.
9. Ввести запрет на самостоятельную загрузку сотрудниками клиентских и кадровых данных в неутвержденные зарубежные облака и AI-сервисы.
10. Хранить доказательства локализации: договор с хостером, адрес ЦОД, спецификацию облака, схему потоков данных и настройки резервирования.

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

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

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

Обычное согласие не является исключением из требования локализации. Пункт 1 части 1 статьи 6, где предусмотрено согласие субъекта, не включен в перечень исключений части 5 статьи 18.

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

Если информация действительно перестала относиться к прямо или косвенно определенному или определяемому человеку, она может перестать быть персональными данными. Но простая замена ФИО на внутренний ID не всегда дает реальное обезличивание, если человека можно восстановить по доступным оператору данным.

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

Да. Статья 12 прямо требует отдельного уведомления до начала такой деятельности. Оно направляется отдельно от общего уведомления об обработке персональных данных по статье 22.

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

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

• Федеральный закон № 152-ФЗ, статья 18 — локализация персональных данных, редакция от 26.07.2026
• Федеральный закон № 152-ФЗ, статья 12 — трансграничная передача, редакция от 26.07.2026
• Федеральный закон № 152-ФЗ, статья 6 — основания обработки и исключения из локализации
• Федеральный закон от 28.02.2025 № 23-ФЗ — поправки к правилам локализации
• Письмо Минцифры России от 12.05.2025 № П25-44929 о локализации и последующей трансграничной передаче
• КоАП РФ, статья 13.11 — ответственность за нарушение законодательства о персональных данных
• Федеральный закон № 152-ФЗ — действующая редакция от 26.07.2026
• Роскомнадзор: портал для уведомления о трансграничной передаче (ссылка приведена в письме Роскомнадзора № 08ВМ-98928)
• Практика 2026 года: дела о локализации данных зарубежных игровых компаний

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

Артем Курнев, юрист. Консультация и анализ IT-архитектуры и документов возможны дистанционно.

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

• есть ли отдельная публичная Политика обработки персональных данных;
• есть ли отдельное согласие под веб-формами, где оно используется как основание обработки;
• отделено ли согласие на рекламу от обязательной записи на прием;
• описаны ли cookies, Метрика, коллтрекинг и технические идентификаторы;
• учтены ли CRM, телефония, мессенджеры и подрядчики;
• не собирает ли сайт медицинские сведения через незащищенные формы.

1. 1. Что обязательно опубликовать на сайте клиники
2. 2. Что должна содержать политика обработки персональных данных
3. 3. Какие данные и цели лучше перечислить отдельно
4. 4. Согласие под каждой формой сайта
5. 5. Почему согласие нельзя прятать в пользовательском соглашении
6. 6. Данные о здоровье как специальная категория
7. 7. Медицинская тайна и персональные данные — не одно и то же
8. 8. Запись на прием и форма обратного звонка
9. 9. Онлайн-анкеты, симптомы и результаты анализов
10. 10. Cookies, Яндекс Метрика и другие счетчики
11. 11. CRM, телефония, электронная почта и подрядчики
12. 12. Telegram, WhatsApp и другие мессенджеры
13. 13. Рассылки, акции и реклама
14. 14. Отзывы пациентов, фотографии и кейсы «до/после»
15. 15. Детская клиника и данные несовершеннолетних
16. 16. Личный кабинет и онлайн-запись
17. 17. Локализация баз данных и трансграничная передача
18. 18. Уведомление Роскомнадзора
19. 19. Сроки хранения и удаление данных
20. 20. Что проверить в футере и формах сайта
21. 21. Типичные ошибки медицинских сайтов
22. 22. Пошаговый аудит сайта клиники
23. 23. Частые вопросы
24. Минимальный комплект документов для сайта медицинской клиники

Часть 2 статьи 18.1 Федерального закона № 152-ФЗ требует обеспечить неограниченный доступ к документу, определяющему политику оператора в отношении обработки персональных данных, и к сведениям о реализуемых требованиях к их защите.

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

Пользователь знакомится с политикой, но сам факт размещения ссылки на нее не заменяет согласие там, где закон требует согласия субъекта. Политика объясняет правила обработки; согласие фиксирует волеизъявление конкретного человека.

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

• полное наименование медицинской организации, ОГРН/ИНН, адрес и контакты оператора;
• контакты лица или подразделения для обращений по персональным данным;
• категории субъектов: посетители сайта, пациенты, потенциальные пациенты, законные представители, пользователи личного кабинета;
• конкретные цели обработки;
• перечень или категории обрабатываемых данных по каждой цели;
• правовые основания обработки;
• перечень операций: сбор, запись, систематизация, накопление, хранение, уточнение, использование, передача, блокирование, удаление, уничтожение;
• способы обработки — автоматизированная, неавтоматизированная или смешанная;
• условия передачи подрядчикам и иным получателям;
• сроки обработки и критерии их определения;
• порядок прекращения обработки, удаления и уничтожения данных;
• права субъекта и порядок направления запросов и отзыва согласия;
• описание применяемых организационных и технических мер без раскрытия уязвимостей;
• правила использования cookies, аналитики и технических идентификаторов, если они применяются;
• сведения о трансграничной передаче, если она реально осуществляется;

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

Для клиники безопаснее разнести обработку по реальным процессам.

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

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

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

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

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

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

Статья 10 Закона № 152-ФЗ относит сведения о состоянии здоровья к специальным категориям персональных данных.

Для сайта это имеет практическое последствие: обычная форма «Имя + телефон» и анкета «Опишите диагноз, симптомы, результаты анализов и лечение» имеют разный уровень правового риска.

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

Статья 13 Федерального закона № 323-ФЗ относит к врачебной тайне сведения о факте обращения гражданина за медицинской помощью, состоянии его здоровья, диагнозе и иные сведения, полученные при медицинском обследовании и лечении.

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

Клиника должна одновременно соблюдать режим персональных данных и врачебной тайны.

Для первичной записи обычно достаточно минимального набора: имя, номер телефона, врач/специальность и удобное время.

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

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

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

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

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

Сайт клиники обычно использует технические cookies, аналитику, коллтрекинг, виджеты обратного звонка, карты и иные сервисы.

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

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

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

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

До публикации политики полезно составить карту потоков данных: форма сайта → сервер → CRM → администратор → телефония → медицинская система.

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

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

Для чувствительных медицинских материалов безопаснее предусмотреть защищенный канал и не стимулировать передачу таких документов через публичный чат.

Согласие на обработку персональных данных не равно согласию на рекламу.

Если клиника планирует направлять рекламные сообщения по SMS, электронной почте, мессенджерам или осуществлять рекламные звонки, нужно учитывать статью 18 Закона о рекламе № 38-ФЗ и получать предварительное согласие адресата.

Лучше использовать отдельный необязательный чекбокс «Согласен получать информационные и рекламные сообщения». Отказ от рекламы не должен блокировать запись на прием.

Для медицинских сайтов это один из самых рискованных блоков.

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

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

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

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

Для записи ребенка разумно собирать минимальные сведения и данные родителя/представителя. Не следует проектировать форму так, чтобы ребенок самостоятельно загружал медицинские документы или давал сложные согласия, если по закону требуется волеизъявление законного представителя.

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

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

В публичной политике не нужно раскрывать технические детали защиты, но внутренние документы и фактическая инфраструктура должны соответствовать требованиям статьи 19 Закона № 152-ФЗ.

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

Если клиника использует иностранный SaaS, зарубежную аналитику, облачное хранилище или иной сервис, необходимо отдельно проверить режим трансграничной передачи по статье 12 Закона № 152-ФЗ и уведомительные обязанности.

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

По статье 22 Закона № 152-ФЗ оператор до начала обработки персональных данных обязан уведомить Роскомнадзор, если не применяется предусмотренное законом исключение.

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

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

В политике нельзя писать «персональные данные хранятся бессрочно» без правового основания.

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

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

Для веб-лидов, которые так и не стали пациентами, срок хранения желательно определить отдельно от медицинской документации действующих пациентов.

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

Если документ говорит одно, а формы, CRM, аналитика и сотрудники делают другое, сама публикация политики не защищает клинику. При проверке оценивается фактическая обработка данных.

1. Составить перечень всех страниц и форм, где пользователь может передать данные.
2. Для каждой формы записать точный набор полей и реальную цель обработки.
3. Отдельно отметить, где могут появляться сведения о здоровье и иные чувствительные данные.
4. Проверить, куда технически уходит каждая заявка: почта, CRM, медицинская система, телефония, мессенджер.
5. Составить список всех подрядчиков, виджетов, аналитики, коллтрекинга и облачных сервисов.
6. Проверить локализацию баз и возможную трансграничную передачу.
7. Сверить фактические процессы с уведомлением Роскомнадзора.
8. Переписать Политику под реальные цели, категории данных, сроки и получателей.
9. Разместить отдельные согласия под формами и отделить рекламу от обязательной обработки.
10. Проверить отзывы, фото пациентов и медицинские кейсы на наличие отдельных согласий.
11. Настроить механизм работы с cookies и необязательной аналитикой.
12. Проверить внутренние договоры поручения обработки, сроки удаления, реагирование на запросы субъектов и инциденты.

Это один из самых рискованных вариантов. Политика должна соответствовать реальным формам, информационным системам, подрядчикам, целям и срокам обработки.

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

Не рекомендуется. Согласие на рекламу должно быть самостоятельным и добровольным; отказ от рекламы не должен препятствовать записи на прием.

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

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

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

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

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

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

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

1) публичная Политика обработки персональных данных; 2) отдельное согласие для форм записи/обратной связи, где оно используется как основание; 3) отдельное согласие на рекламные сообщения; 4) правила cookies/аналитики; 5) отдельные согласия для публикации отзывов, фотографий, видео и медицинских кейсов; 6) корректные внутренние договоры с CRM, хостингом, телефонией и другими обработчиками; 7) актуальное уведомление Роскомнадзора; 8) внутренние документы по доступу, хранению, уничтожению и реагированию на инциденты.

• Юридические услуги для бизнеса: клиники, IT и персональные данные
• Политика в отношении обработки персональных данных на kurnev.ru
• Согласие на обработку персональных данных на kurnev.ru

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

Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»

Федеральный закон от 21.11.2011 № 323-ФЗ «Об основах охраны здоровья граждан в Российской Федерации»

Федеральный закон от 13.03.2006 № 38-ФЗ «О рекламе»

Постановление Правительства РФ от 01.11.2012 № 1119 о требованиях к защите персональных данных в информационных системах

Роскомнадзор — портал персональных данных и реестр операторов

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

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

Пункт 11 статьи 3 Закона № 152-ФЗ определяет трансграничную передачу как передачу персональных данных на территорию иностранного государства органу власти иностранного государства, иностранному физическому лицу или иностранному юридическому лицу.

• передача базы клиентов иностранной материнской компании;
• загрузка персональных данных в зарубежный SaaS, CRM, HR-систему или helpdesk;
• направление данных иностранному подрядчику или партнёру;
• передача идентификаторов пользователя зарубежной системе веб-аналитики;
• использование иностранной платформы рассылок, если в неё передаются e-mail, телефоны или иные персональные данные;
• размещение файлов с персональными данными в зарубежной облачной инфраструктуре.

26 июля 2026 года вступил в силу Федеральный закон № 265-ФЗ. Он изменил статью 12 Закона № 152-ФЗ и убрал прежнюю конструкцию, при которой государство - сторона Конвенции Совета Европы № 108 учитывалось как отдельное самостоятельное основание для более льготного режима передачи.

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

На 3 августа 2026 года приказ Роскомнадзора от 05.08.2022 № 128, которым утверждён действующий перечень, формально сохраняет действие. Однако его структура была сформирована под прежнюю редакцию закона. После вступления № 265-ФЗ компаниям особенно важно проверять актуальную редакцию перечня непосредственно перед началом новой передачи, поскольку критерии его формирования уже изменены.

Да. Часть 3 статьи 12 Закона № 152-ФЗ требует направить отдельное уведомление о намерении осуществлять трансграничную передачу до начала такой деятельности. Оно не заменяет обычное уведомление оператора об обработке персональных данных по статье 22.

Часть 5 статьи 12 требует сначала собрать информацию об иностранном получателе. Это не формальность: оператор должен провести оценку до уведомления Роскомнадзора.

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

Роскомнадзор вправе запросить эти материалы для проверки достоверности уведомления. На ответ оператору даётся 10 рабочих дней; при мотивированном уведомлении срок можно продлить не более чем на пять рабочих дней.

1. Наименование или Ф.И.О. оператора и его адрес.

2. Данные ранее направленного уведомления об обработке персональных данных по статье 22.

3. Сведения об ответственном за организацию обработки персональных данных и его контакты.

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

5. Категории и конкретный перечень передаваемых персональных данных.

6. Категории субъектов, чьи данные передаются.

7. Перечень иностранных государств, куда планируется передача.

8. Дату проведённой оператором оценки иностранного получателя.

Электронная форма размещена на Портале персональных данных Роскомнадзора. Уведомление можно подать и на бумажном носителе в установленном законом порядке.

Статья 12 и Постановление Правительства РФ № 24 предусматривают как общий государственный блок оснований, так и основания, связанные с защитой прав граждан.

• иностранный получатель не принимает меры по защите передаваемых данных или не определил условия прекращения обработки;
• деятельность иностранной организации запрещена в Российской Федерации;
• организация признана нежелательной на территории РФ;
• передача или дальнейшая обработка несовместимы с первоначальными целями сбора данных;
• у оператора отсутствует законное основание обработки по статье 6 Закона № 152-ФЗ;
• передаваемые категории или объём данных не соответствуют заявленной цели — в зависимости от обстоятельств возможны ограничения;
• передача затрагивает интересы обороны, безопасности, экономические и финансовые интересы РФ либо иные охраняемые законом государственные интересы.

Если передача запрещена или ограничена, оператор обязан обеспечить уничтожение иностранным получателем ранее переданных персональных данных в случаях, предусмотренных частью 14 статьи 12.

Это одна из самых частых ошибок. Локализация регулируется частью 5 статьи 18 Закона № 152-ФЗ, а трансграничная передача — статьёй 12. Выполнение одного требования не заменяет другое.

На практике архитектура должна разделять два этапа:

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

Минцифры в письме от 12.05.2025 № П25-44929 также указало, что хранение и уточнение персональных данных граждан РФ, включая их копии, оператором, осуществляющим сбор, должно выполняться с использованием баз данных на территории России. Поэтому модель, в которой иностранная CRM или облако фактически является единственной основной базой для сбора, хранения и обновления данных российских пользователей, несёт высокий риск нарушения локализации.

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

• IP-адрес, cookie-ID, рекламный идентификатор, user-ID или иной идентификатор может быть персональными данными, если позволяет прямо или косвенно определить физическое лицо;
• формы обратной связи, подключённые прямо к иностранной CRM, могут одновременно создавать риск нарушения локализации и трансграничной передачи;
• зарубежная аналитика может получать идентификаторы посетителей даже тогда, когда пользователь не заполняет форму;
• встраиваемые виджеты, чат, видео, карты и системы антифрода нужно оценивать по фактическому сетевому обмену, а не только по названию сервиса.

Статья 12 сама по себе не устанавливает универсального требования получать отдельное согласие с названием «согласие на трансграничную передачу» для любой передачи. Сначала определяется правовое основание обработки по статье 6 Закона № 152-ФЗ.

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

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

Если иностранное лицо обрабатывает данные по поручению российского оператора, дополнительно необходимо соблюдать требования части 3 статьи 6 Закона № 152-ФЗ к поручению обработки.

1. Составить карту данных: какие сведения сервис получает от российских граждан, клиентов и сотрудников.

2. Определить юридическое лицо-получателя и страны фактической обработки.

3. Проверить, есть ли эти государства в актуальном перечне Роскомнадзора.

4. Проверить российскую локализацию первичного сбора и хранения.

5. Определить правовое основание обработки по статье 6.

6. Получить от иностранного получателя сведения, предусмотренные частью 5 статьи 12.

7. Провести и документировать оценку получателя.

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

9. Направить отдельное уведомление о трансграничной передаче.

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

11. После запуска периодически проверять изменение стран обработки, субпроцессоров и перечня Роскомнадзора.

Требования статьи 12 действуют с 2023 года, но в 2025–2026 годах одновременно усилились смежные обязанности и ответственность операторов.

• с 1 июля 2025 года часть 5 статьи 18 сформулирована как прямой запрет использовать зарубежные базы для перечисленных операций при сборе данных граждан РФ;
• за нарушение локализации по части 8 статьи 13.11 КоАП РФ штраф для юридических лиц составляет от 1 до 6 млн руб., за повторное нарушение — от 6 до 18 млн руб.;
• с 30 мая 2025 года существенно расширена административная ответственность за нарушения в сфере персональных данных, в том числе за нарушения уведомительных обязанностей и утечки;
• с 26 июля 2026 года изменён сам критерий адекватности иностранных государств: решающим является включение государства в перечень Роскомнадзора, а не его формальный статус участника Конвенции № 108.

В практике 2024–2025 годов уже есть дела, где основанием проверки становилось использование иностранных метрических систем и отсутствие своевременного уведомления о трансграничной передаче. Это показывает, что проверка не ограничивается договорами с иностранными контрагентами: регулятор оценивает технический функционал сайта и сервисов.

В частности, в деле АО «Ньюс Медиа» 2024 года использование метрических систем на интернет-ресурсах было связано судом с передачей пользовательских данных за рубеж; уведомление было направлено уже после начала такой деятельности. В 2025 году в судебной практике также фиксировались дела об отсутствии уведомления при передаче данных иностранным организациям.

• считать, что страна из «дружественного» списка автоматически обеспечивает адекватную защиту;
• после 26 июля 2026 года ориентироваться только на участие страны в Конвенции № 108;
• подавать только общее уведомление оператора и забывать отдельное уведомление по статье 12;
• не получать от иностранного получателя сведения о мерах защиты и условиях прекращения обработки;
• использовать иностранную CRM как первичную базу для форм сайта российских пользователей;
• считать технические cookie и IP-адрес заведомо неперсональными;
• указывать в уведомлении только одну страну, когда SaaS фактически использует несколько регионов и субпроцессоров;
• не обновлять документы после изменения инфраструктуры иностранного сервиса;
• считать, что согласие пользователя автоматически легализует любую архитектуру обработки.

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

Да, само по себе нахождение государства в ЕАЭС не отменяет определение трансграничной передачи: территория другого государства является иностранной. Отличаться может режим статьи 12 в зависимости от включения государства в перечень Роскомнадзора.

Нужно анализировать архитектуру. Первичный сбор российских граждан напрямую в зарубежную базу и использование её как базы для хранения/обновления создают риск нарушения части 5 статьи 18. Последующая трансграничная передача данных, ранее собранных в российской базе, сама по себе этой нормой не запрещена, но должна соответствовать статье 12.

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

Обычно до истечения 10 рабочих дней после поступления уведомления передавать данные нельзя. Если Роскомнадзор запросил дополнительные сведения, рассмотрение приостанавливается до их предоставления.

Минцифры прямо разъяснило, что использование Google Analytics, если его функционал предполагает обработку персональных данных, является трансграничной передачей.

Нет. Нужно одновременно иметь законное основание обработки, соблюдать локализацию и выполнить процедуру статьи 12, включая специальное уведомление Роскомнадзора.

Да. С 26 июля 2026 года статья 12 ориентируется на включение государства в перечень Роскомнадзора. Для новых и действующих процессов разумно повторно сверить страны обработки с актуальным перечнем и при необходимости пересмотреть оценку риска.

В 2026 году трансграничная передача персональных данных — это не отдельная галочка в политике конфиденциальности, а совокупность технических и юридических условий. Оператор должен сначала обеспечить российскую локализацию сбора данных, определить реальных иностранных получателей и страны обработки, получить от них сведения о защите данных, проверить актуальный перечень Роскомнадзора, иметь основание обработки и до начала передачи направить специальное уведомление. После поправок от 26 июля 2026 года особенно важно отказаться от старого подхода «страна участвует в Конвенции — значит всё в порядке»: теперь статья 12 прямо привязывает режим передачи к актуальному перечню Роскомнадзора.

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

1. Федеральный закон № 152-ФЗ «О персональных данных», статья 12 (ред. от 26.07.2026)
2. Федеральный закон от 26.07.2026 № 265-ФЗ — изменения статьи 12
3. Федеральный закон № 152-ФЗ, статья 18 — локализация при сборе данных
4. Федеральный закон от 28.02.2025 № 23-ФЗ
5. Письмо Минцифры России от 12.05.2025 № П25-44929
6. Приказ Роскомнадзора от 05.08.2022 № 128 — перечень государств с адекватной защитой
7. Постановление Правительства РФ от 16.01.2023 № 24 — запрет/ограничение передачи по результатам уведомления
8. Постановление Правительства РФ от 10.01.2023 № 6
9. Постановление Правительства РФ от 29.12.2022 № 2526
10. КоАП РФ, статья 13.11 — ответственность в области персональных данных

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

С 1 сентября 2025 года часть 1 статьи 9 Федерального закона № 152-ФЗ действует в новой редакции: согласие на обработку персональных данных должно быть оформлено отдельно от иной информации и документов, которые подтверждает или подписывает пользователь.

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

Политика и согласие — разные документы. Политика объясняет, как оператор обрабатывает данные. Согласие — это волеизъявление конкретного пользователя на конкретную обработку, если именно согласие выбрано или требуется как правовое основание.

Очевидные данные:

• имя и фамилия;
• номер телефона;
• адрес электронной почты;
• адрес доставки или объекта;
• текст обращения, если в нем содержатся сведения о человеке;
• данные аккаунта и история заказов.

Неочевидные данные:

• IP-адрес и сетевые идентификаторы;
• cookie-идентификаторы;
• данные об устройстве, браузере и операционной системе;
• источник перехода, история действий и посещенные страницы;
• идентификаторы рекламных и аналитических систем;
• запись действий пользователя в Вебвизоре.

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

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

Практически безопасная конструкция формы:

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

Рабочая логика: отдельный чекбокс «Я даю согласие на обработку персональных данных на условиях Согласия» со ссылкой на отдельный документ. Рядом — самостоятельная ссылка «Политика обработки персональных данных».

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

Если после заявки компания хочет направлять человеку рекламные SMS, сообщения в мессенджеры, email или иные рекламные сообщения по сетям электросвязи, действует не только 152-ФЗ, но и статья 18 Закона о рекламе.

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

Часть 2 статьи 18.1 Закона № 152-ФЗ требует от оператора, который собирает персональные данные через интернет, опубликовать политику на страницах сайта, где осуществляется сбор, и обеспечить к ней доступ.

В политике имеет смысл прямо описать:

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

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

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

Статья 22 предусматривает общее правило: оператор уведомляет Роскомнадзор до начала обработки. Для типичного сайта исключение «обработка исключительно без автоматизации» неприменимо, потому что формы, CMS, CRM и аналитика работают автоматически.

В уведомлении по каждой цели указываются, в частности:

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

Если сведения изменились, например подключилась новая CRM, изменился адрес базы, цели или появилась трансграничная передача, уведомление нужно актуализировать в сроки статьи 22.

В российском законодательстве нет отдельной нормы с формулировкой «каждый сайт обязан установить cookie-баннер с кнопками Принять и Отклонить». Юридический вопрос другой: являются ли конкретные cookies и связанные с ними идентификаторы персональными данными, для чего они обрабатываются и какое правовое основание применяет оператор.

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

Практическая архитектура cookie-баннера:

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

В актуальных условиях Яндекс Метрики от 19 мая 2026 года прямо указано, что счетчик собирает данные о посещениях и устройствах. В отношении данных посетителей, включая активность на сайте, cookies и сведения об устройстве, владелец сайта является оператором, а Яндекс — лицом, действующим по поручению оператора по смыслу части 3 статьи 6 Закона № 152-ФЗ.

Отсюда для владельца сайта следуют практические задачи:

• отразить Метрику в политике и документах об обработке;
• иметь законное основание для обработки и передачи данных Яндексу;
• проверить, соответствует ли договор/условия сервиса требованиям к поручению обработки;
• не передавать в Метрику больше данных, чем нужно для заявленной цели;
• при использовании CRM-импорта, Advanced Matching и иных функций отдельно оценить передаваемые клиентские данные.

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

Поэтому поля с Ф.И.О., телефоном, email, адресом, текстом обращения и иными чувствительными сведениями нужно проверять на маскирование. Не стоит исходить из того, что система «сама всё скроет».

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

Когда внешний сервис обрабатывает данные по поручению владельца сайта, часть 3 статьи 6 Закона № 152-ФЗ требует определить в договоре или ином поручении перечень данных и операций, цели, конфиденциальность, меры безопасности, требования локализации и обязанность сообщать об инцидентах.

Практический аудит должен ответить на четыре вопроса:

• куда уходит заявка после нажатия кнопки;
• в какой стране находится первичная база;
• кто имеет доступ к данным;
• какие сервисы получают идентификаторы пользователя до отправки формы.

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

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

Локализация и трансграничная передача — разные требования. Даже если первичная база находится в России, последующая передача персональных данных иностранному получателю регулируется статьей 12 Закона № 152-ФЗ.

До начала трансграничной передачи оператор направляет в Роскомнадзор отдельное уведомление. С 26 июля 2026 года Федеральный закон № 265-ФЗ уточнил критерии перечня государств, обеспечивающих адекватную защиту персональных данных.

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

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

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

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

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

• в течение 24 часов — первичное уведомление об инциденте, причинах, предполагаемом вреде и принятых мерах;
• в течение 72 часов — результаты внутреннего расследования и сведения о виновных лицах, если они установлены.

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

Федеральный закон № 420-ФЗ усилил административную ответственность по статье 13.11 КоАП РФ. Для владельцев сайтов особенно важны следующие составы.

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

1. Составить карту всех точек сбора данных: формы, чат, мессенджеры, Метрика, Вебвизор, коллтрекинг, рекламные пиксели, CRM.
2. Для каждой цели определить правовое основание: согласие, договор/преддоговорные действия, закон или другое основание статьи 6.
3. Проверить, что согласие, если оно используется, оформлено отдельно и имеет доказуемое активное подтверждение.
4. Разделить согласие на обработку данных и рекламные коммуникации.
5. Опубликовать актуальную Политику обработки персональных данных и обеспечить ссылку на нее возле форм.
6. Описать cookies, аналитику и внешние сервисы; настроить баннер и категории cookies в соответствии с выбранным правовым основанием.
7. Проверить настройки Яндекс Метрики и маскирование полей в Вебвизоре.
8. Проверить договоры/условия с CRM, хостингом, почтой, формами, коллтрекингом и другими обработчиками по ч. 3 ст. 6.
9. Убедиться, что первичный сбор данных граждан РФ соответствует требованиям локализации.
10. Проверить наличие трансграничных передач и отдельного уведомления по статье 12.
11. Проверить регистрацию/актуальность сведений в реестре операторов Роскомнадзора.
12. Установить сроки хранения и правила удаления лидов и обращений.
13. Подготовить процедуру реагирования на утечку с дедлайнами 24/72 часа.

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

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

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

Закон не устанавливает универсальную HTML-форму согласия. Он требует, чтобы согласие было конкретным, предметным, информированным, сознательным и однозначным, а оператор мог подтвердить факт его получения. Отдельный неотмеченный заранее чекбокс с журналированием события — практичный способ доказать эти требования для веб-форм.

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

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

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

Да, если аналитика обрабатывает идентификаторы и иные сведения, относящиеся к определяемому посетителю. Отсутствие поля «Ф.И.О.» само по себе не выводит аналитику из режима персональных данных.

В 2026 году соответствие сайта 152-ФЗ — это не один документ в футере. Нужна согласованная система: карта данных, корректные правовые основания, отдельные согласия, актуальная политика, уведомление Роскомнадзора, локализация, договоры с обработчиками, прозрачная аналитика и технические настройки.

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

1. Федеральный закон № 152-ФЗ «О персональных данных» — действующая редакция от 26.07.2026.
2. Статья 6 Закона № 152-ФЗ — условия обработки и поручение другому лицу.
3. Статья 9 Закона № 152-ФЗ — требования к согласию.
4. Федеральный закон от 24.06.2025 № 156-ФЗ — отдельное оформление согласия с 01.09.2025.
5. Статьи 18 и 18.1 Закона № 152-ФЗ — локализация и публичная политика.
6. Минцифры России: редакция локализации по Закону № 23-ФЗ действует с 01.07.2025.
7. Статья 22 Закона № 152-ФЗ — уведомление Роскомнадзора.
8. Статья 12 Закона № 152-ФЗ — трансграничная передача персональных данных.
9. Федеральный закон от 26.07.2026 № 265-ФЗ — изменения правил трансграничной передачи.
10. Статья 21 Закона № 152-ФЗ — уведомление об инциденте в течение 24/72 часов.
11. Статья 19 Закона № 152-ФЗ — меры безопасности.
12. Статья 13.11 КоАП РФ — ответственность за нарушения законодательства о персональных данных.
13. Условия использования Яндекс Метрики и AppMetrica от 19.05.2026.
14. Статья 18 Федерального закона № 38-ФЗ «О рекламе» — предварительное согласие на рекламу по сетям электросвязи.
15. Рекомендации Роскомнадзора по составлению политики обработки персональных данных.