DPO отвечает

Новые подходы к технической защите персональных данных   Судя по проекту приказа, который спешит на смену приказу ФСТЭК № 21, в ближайшие годы нормативно одобренные подходы к технической защите персональных данных будут определять три основных документа:   ⚫️новый приказ об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в ИСПДн (общественное обсуждение проекта завершено 8 августа 2026 года); ⚫️Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах (методический документ ФСТЭК от 12 апреля 2026 года); ⚫️Методика оценки уровня зрелости деятельности в области технической защиты информации в информационных системах и обеспечения безопасности значимых объектов КИИ (методический документ ФСТЭК от 7 августа 2026 года).   Формально нормативным правовым актом из этой троицы является только первый документ. Но его текущий проект содержит очевидные отсылки к методическим документам ФСТЭК.   В частности, проект предусматривает оценку достаточности и эффективности реализованных мер по обеспечению безопасности персональных данных через показатель уровня зрелости, определяемый в соответствии с методическими документами ФСТЭК (п. 9). Содержание самих мер для соответствующего уровня защищённости предлагается определять также с использованием методических документов ФСТЭК (п. 12).   В связи с вышеизложенным опубликованная на днях Методика оценки уровня зрелости представляет большой интерес для всех DPO и им сочувствующих. Рекомендуем ознакомиться с первоисточником, но для первого знакомства отметим главное.   ⚫️Внутренняя и внешняя оценки. Оператор может провести оценку самостоятельно или привлечь подрядчика с лицензией на техническую защиту конфиденциальной информации. Внешняя оценка считается более объективной, но обязательной не является. ⚫️Пять уровней зрелости: 0 – нулевой (требования не выполняются, мероприятия не реализованы) 1 – начальный 2 – системный 3 – контролируемый 4 – верифицируемый (наивысший уровень, предполагающий соответствие установленным требованиям и периодическую внешнюю проверку их эффективности). ⚫️21 направление деятельности. Именно по этому числу направлений по общему правилу оценивается техническая защита информации. Перечень должен быть конкретизирован оператором с учетом применимых отраслевых требований (в том числе с учётом требований нового приказа, который придет на смену приказу ФСТЭК № 21 и установит состав мер по обеспечению безопасности персональных данных).   ⚫️Требования к направлениям и их весовые коэффициенты. Деятельность внутри каждого направления оценивается по 8 видам требований: - документирование - выполнение - инструменты - квалификация персонала - контроль - обучение - внешний аудит - актуализация У каждого требования есть весовой коэффициент (от 0,1 до 0,2), а степень выполнения оценивается по шкале значений 0 / 0,5 / 1. Итоговое значение по виду требования определяется по формуле [весовой коэффициент х степень выполнения]. Cумма значений по всем требованиям даёт текущий уровень зрелости направления.   ⚫️Расчет итоговых значений. Числовое значение, рассчитанное по итогам оценки требований, сопоставляется с нормированными диапазонами, что даёт итоговый уровень зрелости (0–4) для каждого направления деятельности. Общий уровень зрелости организации определяется как среднее арифметическое текущих уровней по всем направлениям, а результаты визуализируются в виде «лепестковой» диаграммы, сопоставляющей текущий и целевой профили зрелости.   ⚫️Документирование итогов. По итогам оценки обязательно составляется отчёт с описанием области оценки, участников (в том числе лиц, предоставлявших исходную информацию), методологии и исходных данных, результатов по каждому виду требований и направлению, а также с графической интерпретацией результатов. Методика также предполагает сравнение результатов в динамике и формирование плана мероприятий по достижению целевых показателей.   Похоже, что в регулировании технической защиты персональных данных нас ждёт довольно заметный сдвиг: от привычной модели «определили уровень защищённости → выбрали набор мер» к более комплексной оценке того, насколько системно эти меры реализованы и работают на практике. Также бросается в глаза многокомпонентный подход к оценке, который неизбежно повлечет за собой запрос на автоматизацию соответствующего процесса.

Переход с Excel на PrivacyLine больше не проблема Один из частых вопросов, который мы слышим от новых пользователей: «Что делать с реестром процессов, который мы ведём в Excel?» И это действительно хороший вопрос. Сегодня Excel – самый распространённый инструмент для ведения реестра процессов обработки персональных данных. За годы работы в таблицах накапливается большой объём информации. Мы понимаем, что перспектива переносить её вручную в новую систему нередко становится барьером для автоматизации. Теперь этого делать не нужно. В PrivacyLine появился импорт данных из Excel 🔥 Теперь все пользователи могут: ⚫️быстро перенести существующие реестры процессов в PrivacyLine; ⚫️сохранить уже проделанную работу; ⚫️начать пользоваться системой сразу после загрузки данных. Если вы используете другой сервис, который поддерживает экспорт данных в Excel, переход на PrivacyLine также станет значительно проще. Мы хотим, чтобы внедрение системы начиналось не с ручного переноса информации, а с решения задач, ради которых вы её выбираете. Оставить заявку

Обновления в PrivacyLine Последние месяцы наша активность в канале немного снизилась. В основном потому, что мы активно работали над улучшением PrivacyLine 😊 Без революций и переписывания с нуля, просто продолжаем последовательно развивать сервис и выпускать обновления, которые действительно ускоряют работу DPO. В этот раз мы сосредоточились на удобстве работы с реестрами и сокращении ручной работы. Что нового появилось в PrivacyLine: ⚫️мастер копирования данных из процессов в карточку информационной системы – теперь в реестрах будет меньше ошибок, а скорость их заполнения вырастет в несколько раз; ⚫️единый справочник категорий субъектов оператора; ⚫️полное копирование карточки оператора; ⚫️новый режим отображения макроцелей. Помимо нового функционала, не забываем и об удобстве работы пользователей. Поэтому добавили drag&drop, возможность настраивать ширину колонок в таблицах и ряд других UX-улучшений. И, конечно, продолжаем развивать Базу знаний. За последнее время добавили новые материалы и обновили существующие статьи свежей судебной практикой и актуальными позициями регулятора. Подробнее про обновления можно почитать ➡️здесь⬅️. Благодарим наших пользователей за обратную связь, идеи и предложения. Многие из обновлений этой весной появились благодаря вам 💚

Чей железный занавес выше Профильные каналы и чаты облетела новость о том, что голландский регулятор вынес решение о штрафе в 100 млн евро в отношении MLU B.V. (Yango) за передачу данных пользователей в Россию. Дело не новое: ещё в 2023 году финский, норвежский и нидерландский регуляторы разбирали трансфер данных Yango в Россию и риски доступа российских органов к данным пользователей. Помимо очевидных выводов (передавать данные из Европы в Россию без нарушения законодательства ЕС было сложно и станет ещё сложнее), возникают резонные опасения относительно судьбы обратного движения персональных данных. Как известно, российские операторы перед трансграничной передачей данных должны уведомить об этом Роскомнадзор и по запросу последнего передать ему результаты оценки того, насколько хорошо будут защищены интересы субъектов в стране получателе. На практике подавляющее большинство уведомлений о трансграничной передаче проходят без каких-либо вопросов со стороны регулятора (в том числе уведомления о передаче данных в «недружественные» страны). Пока нельзя сказать, что Роскомнадзор завтра начнёт массово направлять запросы и выдавать ограничения по трансграничным потокам данных. Однако инструменты для этого есть, и вероятность их применения повысилась. Продолжаем наблюдение.

Нет предела совершенству Операторы регулярно получают от Роскомнадзора требования об устранении нарушений, информация о которых получена ведомством в ходе автоматизированного мониторинга сайтов без какого-либо взаимодействия с оператором. Большинство из требований регулятора не являются неожиданными и уже не раз озвучивались им. Тем не менее, многие из них со временем получают развитие, поэтому даже опытному DPO полезно периодически перепроверять сайт на соответствие ожиданиям регулятора. Разберём один из самых популярных «источников» замечаний – cookie-баннеры. Что обычно хочет увидеть инспектор (и к чему мы уже привыкли): ⚫️всплывающий баннер с информацией об использовании cookies (как это сделано, например, на сайте ГРЧЦ); ⚫️раздел об использовании файлов cookie в публичной политике обработки персональных данных (или отдельной политике, посвященной сбору именно технических данных); ⚫️упоминание о факте использования Яндекс Метрики прямо в тексте cookie-баннера; ⚫️поданное уведомление о намерении осуществлять трансграничную передачу данных, если оператор использует Google Analytics или другие иностранные сервисы. Последние требования и запросы Роскомнадзора позволяют немного дополнить эту картину следующими рекомендациями: 1) Согласие как основание Несмотря на декларируемое сокращение роли согласий как основания обработки персональных данных, в части метрических данных регулятор по-прежнему ожидает увидеть явное и недвусмысленное согласие. В этом смысле эксперименты с законным интересом следует проводить с осторожностью. 2) Сторонние сервисы сбора метрических данных Если на сайте используются сторонние сервисы сбора метрических данных, помимо Яндекс Метрики, в идеале их все нужно обозначить прямо в cookie-баннере. Хотя именно сервис Яндекса неоднократно упоминался на публичных мероприятиях, его регулятор приводит лишь в качестве наиболее наглядного примера. 3) Сведения о cookies в реестре операторов Упомянув о сборе данных с использованием cookies на сайте, следует добавить эту информацию и в уведомление об обработке персональных данных. Несоответствие между сайтом и уведомлением – одна из возможных причин получения запросов со стороны Роскомнадзора. Набор замечаний, которые получают операторы от управлений Роскомнадзора, может немного отличаться от региона к региону, но основные вопросы повторяются достаточно стабильно.

Законный интерес в массы Вместе с девальвацией ценности согласий на обработку данных (по крайней мере, на словах) второе дыхание получила тема законного интереса. Помимо исполнения договора и требований законодательства, «законный интерес» – это одно из ключевых правовых оснований, на которое может опереться оператор при отсутствии согласия субъекта. Удобство законного интереса как основания для обработки заключается в том, что он предъявляет к обработке данных, казалось бы, несложные для выполнения требования (п. 7 ч. 1 ст. 6 152-ФЗ): ⚫️персональные данные должны обрабатываться для осуществления прав и законных интересов оператора или третьих лиц либо для достижения общественно значимых целей; ⚫️обработка должна быть необходимой для достижения указанных выше целей; ⚫️не должны нарушаться права и свободы субъекта. Несмотря на кажущееся удобство, законный интерес редко используется за рамками наиболее «безопасных» кейсов, вроде контрольно-пропускного режима, проверки благонадежности контрагентов или выдачи доверенностей. Почему? Не последнюю роль играет неуверенность в том, что инспектор Роскомнадзора оценит интересы оператора как законные, а права субъекта как не нарушенные. Но дело не только в этом. Один из типовых кейсов обработки персональных данных для любой коммерческой компании – ведение базы данных потенциальных клиентов (CRM): ФИО, контакты, реквизиты, история заказов и взаимодействия. Попробуем разложить его по критериям законного интереса: ⚫️Есть ли законный интерес? Да, ведь каждый имеет право на свободное использование своих способностей и имущества для не запрещенной законом экономической деятельности (ст. 34 Конституции РФ). Вполне очевидно, что никакая экономическая деятельность не может существовать без взаимодействия ее участников. ⚫️Необходима ли обработка? Да, переговоры, подготовка и направление оферты, а также прочие преддоговорные коммуникации невозможны без идентификации контрагента и использования контактов его представителей. ⚫️Нарушает ли обработка данных в CRM-системе права и свободы субъекта? Не должна, при условии разумного и добросовестного использования данных (без навязчивого маркетинга и «серых» практик). Получается, что нет никаких препятствий для ведения CRM-системы на основе законного интереса? Да, но как только компания начинает использовать для ведения CRM сторонний сервис (а для малого и среднего бизнеса это почти всегда так), то возникает проблема поручения обработки. Согласно ч. 3 ст. 6 152-ФЗ, поручение обработки допускается только с согласия субъекта, кроме случаев, прямо предусмотренных федеральным законом. В таком случае конструкция начинает рушиться, потому что формально оператор может опираться на законный интерес, но фактически не может обойтись без согласия из-за использования внешнего сервиса. Отдельный слой проблемы проистекает из позиции провайдера. Так, на практике некоторые крупные (не будем показывать пальцем) CRM-провайдеры вообще не готовы подписывать с клиентом поручение на обработку. Аргументируется это тем, что провайдер якобы предоставляет лишь ПО, не имеет доступа к данным, размещенным на его серверных мощностях, и все операции по обработке данных осуществляет компания-пользователь. Этот кейс по сути является еще одной иллюстрацией проблем, описанных в нашем недавнем посте про «культ согласий». Проблема не столько в практике применения, а в самой конструкции закона: пока поручение обработки требует согласия, альтернативные основания, в том числе законный интерес, так и будут ограничены в практическом применении.

Макроцели: нас просили, и мы сделали Изменения законодательства часто требуют от DPO проявления творческих подходов. В 2022 году поменялись требования к подаче сведений в реестр операторов персональных данных. С этого момента операторы должны детально описывать цели обработки персональных данных по ряду параметров: перечень данных, категории субъектов, правовые основания обработки, способы обработки и действия с данными. В условиях, когда операторы ведут учет по 20+ целям, подача такого детального уведомления становится проверкой на внимательность и моральную устойчивость DPO. При этом такое «упражнение» DPO должен повторять регулярно, если в его процессах происходят изменения (вспоминаем требование ч. 7 ст. 22 152-ФЗ). Для сокращения трудозатрат на этапе подачи уведомления и последующей подачи информационного письма наиболее творческие представители нашей профессии придумали «макроцели». Макроцель – это условная категория, которая объединяет несколько целей обработки, имеющих схожую направленность. Например, цели «Подбор персонала», «Ведение кадрового учета», «Организация обучения сотрудников» можно объединить в одну макроцель – «Управление персоналом и кадровое администрирование». Объединяя цели в макроцели, DPO может сложить несколько десятков целей в +- 10 позиций и заявить их в уведомлении именно в таком виде. Как умеренные консерваторы, мы относились к этой практике с осторожностью. В особенности потому, что цели, которые указываются в уведомлениях, политике обработки, согласиях и реестре процессов должны быть согласованными. Но признаем, что при понимании этих нюансов и связанных рисков макроцели использовать можно, что нам и демонстрируют крупные операторы персональных данных. Мы не стали делать вид, что макроцелей не существует, раз они используются рынком, и подошли к этой задаче комплексно. Что мы сделали в PrivacyLine: ⚫️Добавили возможность привязывать процессы (цели) к макроцелям. При этом каждый DPO сам решает, будет ли он группировать цели в макроцели, и если да, то какие именно. ⚫️Сделали централизованное изменение названий макроцелей. ⚫️Добавили три разных режима просмотра реестра процессов по макроцелям: в разрезе целей, в разрезе макроцелей с детальным и сводным отображением параметров обработки данных. Последний режим оказался особенно важным, поскольку без средства автоматизации DPO вынуждены вручную вычищать дубли (например, в перечнях данных). ⚫️Дополнили обзоры по макроцелям функционалом текущих обзорных таблиц (фильтры, поиск, выгрузка и др.). По итогу подготовка этой части информации для уведомления по макроцелям сократилась с часов до пары кликов. Об этом и других нововведениях в системе мы рассказали на мероприятии FinTech Club от RPPA.PRO х Цифра Банк. Презентацию можно посмотреть ➡️здесь⬅️. Впереди много планов по развитию описанных в презентации функций, и мы будем рады любой обратной связи. Если хотите попробовать соответствующие возможности на примере своих реестров, приходите на демо (@good_ks).

Алексей Лукацкий выложил на своем канале распознанный файл списка компаний, к которым придут с профилактическим визитом, за что мы ему бесконечно благодарны! Делимся этим файлом с вами👇🏻

А вы точно с профилактическим визитом? Роскомнадзор опубликовал приказ от 19.12.2025 № 390 с перечнем операторов, к которым в 2026 году придут с профилактическими визитами. Перечень получился внушительный, почти на 200 страниц (см. стр. 67–240). В целом логично, ведь как-то необходимо компенсировать длящийся не первый год мораторий на проверки. По сферам бизнеса картина тоже ожидаемая: больше всего визитов у медицинских, образовательных и туристических организаций, компаний сферы ЖКХ. Местами попадаются бухгалтерские и юридические фирмы. После вступления в силу ФЗ № 540 отказаться от обязательного профилактического визита больше нельзя (ст. 52.1 Закона № 248-ФЗ), так что проверят всех. Что такое профилактический визит Формально – это профилактическое мероприятие. Но по содержанию оно стало похоже на полноценную проверку. Визит может проходить очно, по ВКС или через приложение «Инспектор». Срок проведения – до 10 рабочих дней. Что может запросить Роскомнадзор Раньше список был небольшим: ⚫️цели и правовые основания обработки; ⚫️документы о назначении ответственного; ⚫️политики и локальные акты; ⚫️подтверждение локализации баз данных; ⚫️типовые формы документов; ⚫️URL-адреса сайтов. ❗️Важно: ранее в рамках визита оценивалось «состояние деятельности оператора по обработке персональных данных». Сейчас в правилах проведения профилактических визитов прямо указано, что инспектор оценивает уровень соблюдения оператором обязательных требований. На практике это может означать использование проверочного листа. С учетом этого есть риск, что в ходе визита может быть запрошена более детальная информация по каждому направлению обработки, фактически как в процессе проверки. Подходы станут понятны после того, как будут проведены первые визиты по новым правилам. Кроме запроса документов в ходе визита инспектор вправе проводить осмотр (например, могут быть осмотрены информационные системы, используемые оператором для обработки персональных данных) и выполнять ряд иных действий. Чем может закончиться визит По итогам визита составляется акт. А если в ходе визита выявлены нарушения обязательных требований, и они не устранены до завершения визита, то оператору может быть выдано предписание об их устранении. Как подготовиться, если вы в списке Программа минимум – обеспечить наличие следующих документов: ⚫️реестр процессов обработки; ⚫️локальные акты и политика; ⚫️актуальные уведомления; ⚫️формы согласий; ⚫️подтверждение локализации баз данных; ⚫️документы об обучении/ознакомлении сотрудников. Важно, чтобы документы были синхронизированы между собой и с фактическими процессами. Лайфхак: подготовка к визиту заметно упростится, если делать это с PrivacyLine. 👉 Полную версию статьи со ссылками на полезные материалы разместили на сайте.

Критикуешь – предлагай Начало года выдалось не менее горячим, чем его окончание, в связи с чем DPO не отвечал отвечал чуть реже, чем обычно. В прошлом году мы выразили некоторый скепсис по поводу широко обсуждаемой инициативы по разработке «стандартов» обработки персональных данных. Теперь хотелось бы поговорить о том, что, на наш взгляд, действительно могло бы упростить жизнь DPO без ущемления интересов субъектов. «Культ согласий» В последнее время на разных площадках много говорят о так называемом «культе согласий». Это ситуация, когда согласия берутся «для галочки» и используются для формальной легализации обработки там, где они не нужны или в принципе не могут служить корректным основанием (например, при явно избыточной обработке). При этом часто умалчивается важный момент: многие операторы собирают эти многочисленные согласия не от хорошей жизни. Хрестоматийный пример – десятки согласий, которые собираются у работников на передачу их данных третьим лицам. Эта практика является результатом причудливого симбиоза ст. 88 ТК РФ («…не сообщать персональные данные работника третьим лицам без его письменного согласия») и ч. 4 ст. 9 152-ФЗ (требующей указывать в письменном согласии «цель» обработки персональных данных, что регулятор толкует как запрет указания в таком согласии нескольких целей). Кто-то скажет, что проблема преувеличена, т.к. тут и тут Роскомнадзор разъяснил, что во многих случаях можно опираться на требования закона, если передача данных работника связана с трудовыми отношениями. Однако есть мероприятия (28.11.2020 [1:02:45], 27.07.2023 [2:43:15], 28.01.2021 [31:18]), и, что важнее, судебные решения, где регулятор и суды занимали куда более консервативную позицию (один, два, три) по ситуациям, связанным с трудовыми отношениями ничуть не меньше. Говоря о ст. 88 ТК РФ, нельзя не вспомнить и ч. 3 ст. 6 152-ФЗ, которая требует получать согласие субъекта на поручение обработки его персональных данных третьему лицу во всех случаях, кроме прямо предусмотренных федеральным законом. Эта норма существенно усложняет жизнь операторам (и DPO). Во многих ситуациях, когда оператор мог бы опереться на иные основания (в том числе на законный интерес), даже банальное размещение данных на стороннем хостинге делает это невозможным без согласия субъекта. Кроме того, норма создаёт множество блокирующих ситуаций. Например, при каждой смене подрядчика требуется новое согласие, а вернуться к субъекту за ним удаётся далеко не всегда. Что можно сделать? ⚫️Проблему множественности согласий работников можно было бы решить исключением слова «письменного» из текста ст. 88 ТК РФ. Даже эта минимальная мера позволила бы снизить требования к форме согласия работника и избежать огромного массива бумажной работы. ⚫️Имеет смысл полностью исключить из ч. 3 ст. 6 152-ФЗ условие о необходимости получения согласия субъекта на поручение обработки его данных. Дополнительную прозрачность для субъектов можно обеспечить более жесткими требованиями к раскрытию информации о получателях данных и нормативным регулированием порядка привлечения субобработчиков. Оператор в любом случае отвечает за обработчика перед субъектом – независимо от того, давал субъект согласие или нет. Это во многом лишает такое согласие практического смысла. Все же для борьбы с «культом» нужны изменения в нормативных актах, а не «мягкое» регулирование в виде стандартов. Без таких изменений DPO и дальше будут тратить время на составление, сбор и анализ во многом бессмысленных согласий, а также на изобретение всё более изощрённых конструкций, вроде модульных согласий и динамично меняющихся списков подрядчиков, спрятанных где-нибудь в недрах сайта.

Итоги года: PrivacyLine и DPO отвечает 21 декабря исполнился год с момента, когда мы запустили канал. У нас была простая идея – делиться тем, с чем мы сами живём каждый день: практикой DPO, сложными вопросами регулирования, интересными судебными кейсами и нашими наработками по теме автоматизации. Что можно сказать... Это был очень плотный и по-хорошему рабочий год. PrivacyLine Весь год мы непрерывно развивали PrivacyLine, много общались с DPO из самых разных компаний, слушали, задавали вопросы, проверяли гипотезы, улучшали существующий функционал, делая его чище и удобнее, много работали над оптимизацией и безопасностью. Внедрили и новые функции, например, теги, макроцели и, главное, генератор документов, который стал не просто еще одним шаблонизатором, а инструментом подготовки документов на основе реальных процессов, с логикой и подсказками. В следующем году мы точно не сбавим темп. У нас есть чёткое видение продукта и огромный бэклог, сформированный не из абстрактных идей, а на основе обратной связи от действующих и потенциальных пользователей. В этом году мы также усилили команду. Это, пожалуй, одно из самых важных наших достижений уходящего года, которое позволит двигаться быстрее и увереннее. Этой осенью у нас появился первый логотип, а недавно мы запустили новый сайт PrivacyLine. Там собрали всё, что нужно, чтобы быстро понять, как сервис может быть полезен именно вам. DPO отвечает За этот год канал стал местом, где можно разбирать новые требования, говорить о странностях правоприменения без прикрас и лукавства и иногда вместе недоумевать над тем, что происходит в практике. В этом году мы много писали про: ⚫️изменения в контроле и надзоре ⚫️уголовную ответственность ⚫️локализацию ⚫️согласия ⚫️темные паттерны ⚫️практику арбитражных судов и прокуратуры ⚫️утечки (наш самый популярный материал в канале, который не утратил актуальности) ⚫️и, конечно, автоматизацию в работе DPO Если быть до конца честными, мы могли бы вести канал и поактивнее. Именно к этому и будем стремиться в следующем году 😊 Спасибо, что вы с нами❤️С наступающим Новым годом! Пусть он будет спокойным, тёплым и предсказуемым, хотя бы в части практики и регулирования. Увидимся в следующем году 🎄

Юристу без IT уже сложно (проверено на себе) Ключевая команда PrivacyLine (и канала по совместительству) – в первую очередь юристы, у которых за плечами значительный опыт работы в IP/IT и privacy (а кто-то продолжает трудиться в этой сфере и сейчас!). Когда мы начали создавать сервис для DPO, довольно быстро стало понятно, что жизнь внутри IT-продукта требует гораздо более глубокого погружения в техническую специфику. Мы по себе знаем, что без понимания того, как работают IT-коллеги, как выглядит реальный процесс разработки, что стоит за облачными технологиями и API, а также какие риски связаны с разными техническими подходами, в этих вопросах сложно уверенно ориентироваться. Для DPO такое понимание важно в той же степени. Именно поэтому нам показался полезным курс «Level UP: IT» от коллег из RPPA. Курс короткий (1 месяц), прикладной и рассчитан именно на тех, кто работает на стыке права, комплаенса и технологий (в том числе на DPO) и хочет нарастить «базу». Преподают коллеги по цеху, которые говорят не только на юридическом, но и на IT-языке (Positive Technologies, Whoosh, Самокат). 🔥Старт курса 15 января 2026 года. Кажется, хороший способ начать год с полезного обучения! ➡️ Подробнее о курсе: https://rppaedu.pro/levelupit

Неподача уведомления: разбор судебной практики арбитражных судов Похоже, эксперимент с арбитражными судами по делам о персональных данных подходит к завершению: дела по ст. 13.11 КоАП РФ планируют вернуть мировым судьям (см. подп. «б» п. 12 ст. 1 законопроекта № 913233-8). Практика арбитражных судов прожила недолго и, судя по всему, не особенно всем понравилась (остается гадать, какие ставки изначально на нее делали, если таковые вообще были...). В недавнем посте мы отмечали, что суды начали применять ч. 10 ст. 13.11 КоАП РФ (неподача или несвоевременная подача уведомления о намерении осуществлять обработку в Роскомнадзор). Во всех рассмотренных делах инициатором возбуждения производства выступала прокуратура, что накладывает определенную специфику. И до 30 мая дела с участием прокуратуры нередко отличались более «творческими» позициями по сравнению с делами, инициированными Роскомнадзором. Тем не менее пугающих штрафов по ч. 10 ст. 13.11 КоАП РФ не случилось. Суды признавали нарушителей виновными, но с учетом совершения правонарушения впервые заменяли штрафы на предупреждения (ст. 4.1.1 КоАП РФ). Ключевые выводы: ⚫️Неподача уведомления как длящееся правонарушение. Ранее мы задавались вопросом, изменится ли подход к срокам давности с появлением нового состава. Напомним, что до 30 мая подходы судов по этому вопросу различались: в делах с участием Роскомнадзора нарушение чаще не признавалось длящимся, а в делах с участием прокуратуры – наоборот. Пока мы видим, что в делах с участием прокуратуры эта логика сохранилась. Например, в деле Спортивной школы №1 суд указал, что это правонарушение выражается в длительном непрекращающемся невыполнении обязанности, т.е. является длящимся. Нарушение было выявлено 2 июля 2025 года, поэтому срок давности на момент рассмотрения дела не истек. ⚫️Привлечение директора коммерческой организации по ч. 10 ст. 13.11. Суд привлек к ответственности директора ООО как должностное лицо по ч. 10 ст. 13.11. Такое решение тоже вызывает вопросы. Согласно примечанию 2 к ст. 13.11 КоАП РФ, по частям 10–18 под должностными лицами понимаются только лица государственных или муниципальных органов либо некоммерческих организаций. С учётом этого не вполне понятно, что имел в виду суд, привлекая директора. Впрочем, судя по тексту судебного решения, никто на это примечание и не ссылался. ⚫️Устранение нарушения как основание для предупреждения (дело 1, дело 2, дело 3). В этих делах операторы подали уведомления почти сразу после проверок прокуратуры, не дожидаясь рассмотрения дела в суде. Во втором деле суд прямо указал на данный факт как на смягчающее обстоятельство. В двух других делах этот факт в качестве смягчающего не назван, но был явно учтен судом при вынесении решения. Таким образом, оперативная подача уведомления – это реальный шанс получить предупреждение вместо штрафа. ⚫️Квалификация неуведомления о трансграничной передаче по ч. 10 ст. 13.11 (небольшой update). В недавнем посте мы разбирали дело, где директора компании привлекли по ч. 10 ст. 13.11 за неподачу уведомления о трансграничной передаче. Пытаясь найти логику, мы обратили внимание, что компания на момент проверки, судя по всему, не подала и основное уведомление о начале обработки (что образует «чистый» состав ч. 10). Возможно, это и стало фактическим основанием для привлечения к ответственности. Между тем, однозначно установить это из буквального текста решения невозможно, в связи с чем данный кейс останется в архивах судебной практики как пример неоднозначного применения ч. 10 ст. 13.11 КоАП.

Каждому оператору по стандарту Представители Роскомнадзора неоднократно озвучивали идею о том, что для разных типов операторов необходимо разработать стандарты обработки персональных данных (например, здесь и здесь). Общая задумка – разработать некие правила, которые определят допустимые параметры обработки данных (какие данные можно собирать, на каком основании, как долго их хранить и т.д.). Судя по всему, эта инициатива имеет все шансы быть реализованной на практике. В связи с этим хотелось бы высказать несколько соображений. Какими могут быть «стандарты» Юридический формат будущих «стандартов» пока неизвестен, поэтому можно представить два основных сценария: ⚫️Устанавливаются обязательные требования к параметрам обработки персональных данных для операторов определенных отраслей. ⚫️Разрабатываются рекомендации, описывающие «одобренные» регулятором подходы к обработке, но не являющиеся обязательными. На наш взгляд (который совпадает с мнением известных нам DPO), первый сценарий – негативный, а второй – нейтральный или умеренно позитивный (в зависимости от подхода к статусу стандартов и их содержания). Почему обязательные «стандарты» – это плохо? Обработка данных пронизывает практически все бизнес-процессы компании: от найма до маркетинга и продаж. Даже внутри одной отрасли, будь то ритейл или фарма, эти процессы существенно отличаются и зависят от масштаба, структуры и иных особенностей компании. Если собрать представителей десяти компаний одной отрасли и предложить им договориться о единых обязательных для всех требованиях к целям обработки данных, составу собираемых данных и срокам их обработки, то вероятность достижения консенсуса будет стремиться к нулю. Если добавить к ним представителя регулятора, который должен будет одобрить избранные бизнесом подходы, то вероятность успеха окажется еще ниже. Попробуйте спросить любого бухгалтера о разумных сроках обработки данных бывших работников в системе кадрового учета, а клиентского менеджера – когда можно удалять данные представителя клиента из CRM-системы. Затем сравните их ответы с позициями регулятора по тем же вопросам. Уже здесь станет очевидно, что разработка обязательных правил, которые устроят и рынок, и регулятора, крайне маловероятна. Любые обязательные «стандарты» неизбежно будут отставать от технологий и бизнес-практик, а значит – мешать развитию соответствующих отраслей. Поэтому попытка описать допустимые практики работы с персональными данными в виде обязательных правил (помимо уже закрепленных в законе) обречена на провал. Если, конечно, цель не состоит в создании правил, которые невозможно выполнить. Почему необязательные стандарты – это тоже не всегда хорошо? Разработка стандартов рекомендательного характера – это достаточно нейтральная инициатива. Но чтобы они принесли реальную пользу отрасли, бизнес должен видеть понятные стимулы к их внедрению. Самый очевидный стимул – снижение рисков привлечения к ответственности. То есть оператор, внедривший стандарт и подтвердивший это, должен рассматриваться как заведомо выполняющий требования законодательства. Готов ли регулятор придать стандартам такое значение? Есть и другая проблема: стандарт должен быть реалистичным. Чем он дальше от реальных бизнес-практик, тем ниже вероятность его внедрения. Бизнес не будет внедрять стандарт, снижающий комплаенс-риски, если одновременно понизится эффективность бизнес-процессов, от которых зависит его выживание. Это вновь возвращает нас к проблеме, связанной с очевидной удаленностью позиций регулятора и операторов. Что вместо стандартов? Если обязательные стандарты – плохо, а необязательные – хорошо, но не всегда, то какие альтернативы могут повысить эффективность регулирования? Об этом в следующих публикациях.

🍿Важные обновления в PrivacyLine: мы запустили Генератор документов Хронический дефицит времени и избыток ручной работы – это лишь пара аспектов, которые объединяют всех DPO. И мы давно поняли, что DPO нужен инструмент, который действительно помогает, а не создаёт новые рутинные задачи. Сегодня мы сделали еще один важный шаг: запустили Генератор документов. Это не просто шаблонизатор, который «вставляет значения в квадратные скобки». Мы сделали инструмент, который учитывает логику документа, сверяется с вашим реестром процессов, подсказывает недостающие данные и помогает избегать ошибок. Что умеет первая версия: ✔️Согласие на обработку (две формы: письменная и обычная) Система автоматически собирает сведения из реестра процессов, проверяет обязательные поля и учитывает разные категории получателей. ✔️Поручение на обработку Система автоматически формирует документ на основе реестра получателей данных и параметров передачи. Как и с согласиями, она подскажет, если в реестре заполнены не все нужные значения. ✔️6 ЛНА – положения, инструкции, приказы. Все самое важное. Впереди большой путь развития этого модуля, в который мы будем добавлять новые документы и возможность работать со своими шаблонами, а не только встроенными. Хотите попробовать сами? ➡️ Записывайтесь на демо на нашем сайте: privacyline.ru ➡️Или пишите напрямую @good_ks Мы покажем вам систему и после дадим 2 недели бесплатного доступа, чтобы вы могли опробовать её на своих процессах.

Серия судебных дел по жалобам субъектов: выводы для операторов Мы проанализировали серию арбитражных дел (А68-13378/2024, A68-3697/2025, A68-3650/2025), в которых гражданка судилась с Роскомнадзором. Суть споров: заявительница пожаловалась регулятору на крупный банк (СМС-рассылки, выпуск карт, передача данных), требуя оштрафовать банк. РКН не нашел нарушений и отказал в возбуждении административных дел. Гражданка не согласилась с позицией регулятора и пошла в суд оспаривать отказы в возбуждении дел. Несколько практических моментов, которые значимы для операторов: ✔️ Неотправленная веб-форма не создает факта обработки, если персональные данные не сохраняются в системах оператора Заявительница получила СМС с кодом подтверждения заявки на кредитную карту и утверждала, что банк незаконно обрабатывает её данные, так как она заявку не подавала. Суд установил, что если пользователь не подтвердил заявку кодом из СМС, то заявка не сохраняется в системах банка. В логах сайта идентификаторы клиентов не хранятся. Следовательно, событие административного правонарушения отсутствует, так как факт обработки данных конкретного лица не доказан. ❓В договоре стоит прямо указывать на разграничение обязанностей по получению согласия Банк получил от работодателя персональные данные гражданки для выпуска зарплатной банковской карты. Когда банк попытался вручить карту, гражданка заявила, что не давала банку согласие на обработку данных. После этого она обратилась в РКН с жалобой на наличие в действиях банка признаков состава по ч. 2 ст. 13.11 КоАП РФ (отсутствие письменного согласия). РКН отказал в возбуждении дела, сославшись на договор между банком и работодателем, в котором была гарантия работодателя о том, что он получил все необходимые согласия субъектов на передачу данных банку. Кроме того, РКН не усмотрел причин для получения банком согласия именно в письменной форме – отметим, что необходимость в получении такого согласия работодателем в решении не рассматривалась. Суд с позицией РКН согласился. ❗️Отказ в возбуждении дела: грани обязанностей РКН по мотивировке решения Гражданка обратилась в РКН с жалобой на банк, который не уничтожил ее персональные данные после отзыва согласия. После изучения жалобы и ответов банка, РКН отказал в возбуждении дела. Суд признал отказ незаконным, поскольку РКН не запросил у банка документы об уничтожении данных. Кроме того, отказ РКН не был должным образом мотивирован: хотя банк указывал, что данные гражданки не были уничтожены в связи с наличием судебных споров (т.е. банк был вправе не прекращать обработку), РКН не сослался на эти обстоятельства в определении об отказе в возбуждении дела. Вывод: при ответе на запрос регулятора об уничтожении целесообразно сразу прикладывать подтверждающие документы (а лучше проект определения об отказе в возбуждении дела), а также аргументировать причины, по которым оператор вправе продолжить обработку, если это применимо. Это не только снимет вопросы у регулятора, но и снизит риски последующего оспаривания его решения со стороны субъекта.

Арбитражные суды и персональные данные: первые итоги (и сюрпризы) «переезда» дел по ст. 13.11 КоАП Прошло несколько месяцев с момента, как дела об административных правонарушениях по ст. 13.11 КоАП РФ перешли в компетенцию арбитражных судов. Мы изучили 17 свежих решений за 2025 год из разных регионов — от Карелии до Забайкалья — и готовы поделиться первыми выводами. 📊 Статистика: в нашей выборке 11 дел о привлечении к ответственности (и ещё 6 — об оспаривании отказов в возбуждении дел). ⚫️Кого привлекают: 10 из 11 возбуждено против бюджетных учреждений, НКО, госорганов или их сотрудников. Бизнес в судах пока редкий гость — РКН чаще отказывает в возбуждении дел против коммерческих организаций (что граждане потом пытаются оспорить). ⚫️ Инициатор: Основной драйвер — активность граждан. Большинство дел возбуждено РКН (6 из 11) или прокуратурой (5 из 11) именно после жалоб сотрудников, клиентов или соседей. ⚫️ Наказание: Арбитражные суды пока настроены лояльно. В 8 из 11 суды заменили штрафы на предупреждения (ст. 4.1.1 КоАП). Что интересного мы увидели в решениях: ⚫️Опасные галочки: В Москве суд поддержал жесткий подход прокуратуры. В тексте согласия под галочкой были указаны только ФИО и телефон, а в профиле можно было загрузить фото. Суд квалифицировал это как обработку без письменного согласия (ч. 2 ст. 13.11). Итог — штраф 150 000 руб. (и это еще сниженный в 2 раза!). Квалификация, конечно, вызывает некоторые вопросы. ⚫️DPO — должностное лицо: В Алтайском крае суд привлёк к ответственности специалиста по кадрам (т.е. не директора) в качестве должностного лица. Суд поднял документы и увидел, что именно этот сотрудник приказом был назначен ответственным за организацию обработки ПДн. Итог — предупреждение. ⚫️ Субъект или гражданин?: В Пскове Перинатальный центр пытался доказать: сотрудник уволен, составлен акт о прекращении обработки, значит, отвечать на его запросы можно как обычному гражданину (по 59-ФЗ, в течение 30 дней). Суд эту логику отверг: обработка персональных данных не заканчивается с расторжением трудового договора, хранение = обработка, вы — оператор и обязаны соблюдать сроки 152-ФЗ (10 рабочих дней). Из дела не совсем ясно, какие данные хранил оператор, но, может, он посчитал их архивными и поэтому не применял 152-ФЗ (по заветам дела Аэрофлота)? ⚫️ Суд советует РКН не стесняться использовать полномочия: В Калуге гражданин оспаривал отказ РКН в возбуждении дела и заявлял ходатайство об опросе свидетелей нарушения. РКН проигнорировал эту просьбу. Суд признал отказ незаконным и указал на грубое процессуальное нарушение: ходатайство по ст. 24.4 КоАП нужно либо удовлетворить, либо вынести мотивированное определение об отказе . «Не заметить» его нельзя. Также суд напомнил, что у регулятора есть право запрашивать информацию, и он обязан им пользоваться для расследования (в том числе в форме запроса к свидетелям). В следующих постах детально разберем: 🕓 Новую практику по ч. 10 ст. 13.11 (уведомления): почему суды считают это нарушение длящимся (срок давности не сгорает!) и как эту статью применяют к трансграничной передаче. 🕓 Судебную сагу в 5 делах одной семьи против крупного банка: как доказать, что номер телефона и почта — не ПДн, защититься от жалоб на СМС-спам и правильно подтверждать уничтожение данных.

ITSEC 2025: что можно (и нельзя) автоматизировать в работе DPO На прошлой неделе прошёл форум ITSEC 2025. Мы приняли участие в сессии «Персональные данные в 2026 году: новые требования и инструменты» и рассказали о нашем опыте автоматизации функции DPO. Основные хайлайты: ⚫️ Из чего на практике состоит работа ответственного ⚫️ Почему задачи DPO сложно автоматизировать «под ключ» ⚫️Что уже хорошо поддаётся автоматизации и где есть потенциал для её расширения (с учетом нашего опыта) ⚫️Какие задачи пока лучше выполняет человек 🎁 Подробности в прикреплённой презентации, а по этой ссылке можно посмотреть видео с секции и презентации других спикеров!

DPO vs зарубежные провайдеры LLM: возможно ли оформить поручение на обработку по ч. 3 ст. 6 152-ФЗ В последнее время операторы активно прибегают к использованию ИИ, поэтому DPO приходится применять свой естественный интеллект, чтобы легализовать такое использование. Один из частых вопросов, который получают практикующие участники нашей команды: как выполнить требования п. 3 ст. 6 152-ФЗ. Иными словами, как оформить поручение на обработку персональных данных при использовании зарубежных LLM? Дополнительную актуальность вопросу придаёт потенциальный штраф по ч.1 ст.13.11 КоАП РФ за передачу данных в отсутствие поручения в тех случаях, когда оно должно быть оформлено. Бывалые DPO помнят времена, когда большинство провайдеров облачных сервисов на предложение оформить поручение на обработку данных отвечали «сам ты обработчик» и отрицали любую причастность к обработке персональных данных. Сейчас DPO встречают в этом вопросе больше понимания, но порядок оформления поручений с крупными ИТ-провайдерами все еще вызывает вопросы, особенно если речь идет об иностранных контрагентах. Что может хоть как-то помочь DPO? Действительно, сложно представить сценарий обсуждения с международным ИТ-гигантом условий обработки персональных данных, которые планирует передать в его систему отдельно взятая российская организация. Но ситуация не безнадежна: рынок ЕС остается одним из самых привлекательных (если не самым привлекательным) для большинства провайдеров LLM, поэтому почти все они стремятся соответствовать требованиям GDPR. В практической плоскости это означает разработку и опубликование провайдерами типовых условий обработки персональных по поручению. Такие условия обычно являются приложением к основному договору (Data Processing Addendum или DPA) и включают в себя основные параметры поручения на обработку персональных данных. DPA основан на требованиях GDPR, которые являются во многом более строгими, чем отечественное законодательство, поэтому чаще всего такой документ закрывает значительную часть требований ч. 3 ст. 6 152-ФЗ. Пример того, как выглядят DPA некоторых популярных провайдеров LLM, можно увидеть здесь: OpenAI Chat GPT, Anthropic Claude. Конечно, чаще всего мы не найдем в DPA зарубежного провайдера LLM обязательств выполнять российские требования по локализации персональных данных (как того требует ч. 3 ст. 6 152-ФЗ). Также нельзя забывать о том, что сфера действия DPA может быть ограничена определенной территорией или не охватывать российский рынок по иным причинам. В этом смысле решение, безусловно, не является идеальным, однако, неидеальное решение - лучше, чем его полное отсутствие.