Макроцели: нас просили, и мы сделали

Изменения законодательства часто требуют от DPO проявления творческих подходов.

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

В условиях, когда операторы ведут учет по 20+ целям, подача такого детального уведомления становится проверкой на внимательность и моральную устойчивость DPO. При этом такое «упражнение» DPO должен повторять регулярно, если в его процессах происходят изменения (вспоминаем требование ч. 7 ст. 22 152-ФЗ).

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

Макроцель – это условная категория, которая объединяет несколько целей обработки, имеющих схожую направленность. Например, цели «Подбор персонала», «Ведение кадрового учета», «Организация обучения сотрудников» можно объединить в одну макроцель – «Управление персоналом и кадровое администрирование».

Объединяя цели в макроцели, DPO может сложить несколько десятков целей в +- 10 позиций и заявить их в уведомлении именно в таком виде.

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

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

Что мы сделали в PrivacyLine:

⚫️Добавили возможность привязывать процессы (цели) к макроцелям. При этом каждый DPO сам решает, будет ли он группировать цели в макроцели, и если да, то какие именно.

⚫️Сделали централизованное изменение названий макроцелей.

⚫️Добавили три разных режима просмотра реестра процессов по макроцелям: в разрезе целей, в разрезе макроцелей с детальным и сводным отображением параметров обработки данных.

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

⚫️Дополнили обзоры по макроцелям функционалом текущих обзорных таблиц (фильтры, поиск, выгрузка и др.).

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

Об этом и других нововведениях в системе мы рассказали на мероприятии FinTech Club от RPPA.PRO х Цифра Банк.
Презентацию можно посмотреть ➡️здесь⬅️.

Впереди много планов по развитию описанных в презентации функций, и мы будем рады любой обратной связи. Если хотите попробовать соответствующие возможности на примере своих реестров, приходите на демо (@good_ks).

Законный интерес в массы

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

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

Удобство законного интереса как основания для обработки заключается в том, что он предъявляет к обработке данных, казалось бы, несложные для выполнения требования (п. 7 ч. 1 ст. 6 152-ФЗ):
⚫️персональные данные должны обрабатываться для осуществления прав и законных интересов оператора или третьих лиц либо для достижения общественно значимых целей;
⚫️обработка должна быть необходимой для достижения указанных выше целей;
⚫️не должны нарушаться права и свободы субъекта.

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

Почему? Не последнюю роль играет неуверенность в том, что инспектор Роскомнадзора оценит интересы оператора как законные, а права субъекта как не нарушенные.

Но дело не только в этом.

Один из типовых кейсов обработки персональных данных для любой коммерческой компании – ведение базы данных потенциальных клиентов (CRM): ФИО, контакты, реквизиты, история заказов и взаимодействия.

Попробуем разложить его по критериям законного интереса:

⚫️Есть ли законный интерес? Да, ведь каждый имеет право на свободное использование своих способностей и имущества для не запрещенной законом экономической деятельности (ст. 34 Конституции РФ). Вполне очевидно, что никакая экономическая деятельность не может существовать без взаимодействия ее участников.

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

⚫️Нарушает ли обработка данных в CRM-системе права и свободы субъекта? Не должна, при условии разумного и добросовестного использования данных (без навязчивого маркетинга и «серых» практик).

Получается, что нет никаких препятствий для ведения CRM-системы на основе законного интереса? Да, но как только компания начинает использовать для ведения CRM сторонний сервис (а для малого и среднего бизнеса это почти всегда так), то возникает проблема поручения обработки.

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

Отдельный слой проблемы проистекает из позиции провайдера. Так, на практике некоторые крупные (не будем показывать пальцем) CRM-провайдеры вообще не готовы подписывать с клиентом поручение на обработку. Аргументируется это тем, что провайдер якобы предоставляет лишь ПО, не имеет доступа к данным, размещенным на его серверных мощностях, и все операции по обработке данных осуществляет компания-пользователь.

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

Нет предела совершенству

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

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

Разберём один из самых популярных «источников» замечаний – cookie-баннеры.

Что обычно хочет увидеть инспектор (и к чему мы уже привыкли):

⚫️всплывающий баннер с информацией об использовании cookies (как это сделано, например, на сайте ГРЧЦ);

⚫️раздел об использовании файлов cookie в публичной политике обработки персональных данных (или отдельной политике, посвященной сбору именно технических данных);

⚫️упоминание о факте использования Яндекс Метрики прямо в тексте cookie-баннера;

⚫️поданное уведомление о намерении осуществлять трансграничную передачу данных, если оператор использует Google Analytics или другие иностранные сервисы.

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

1) Согласие как основание
Несмотря на декларируемое сокращение роли согласий как основания обработки персональных данных, в части метрических данных регулятор по-прежнему ожидает увидеть явное и недвусмысленное согласие. В этом смысле эксперименты с законным интересом следует проводить с осторожностью.

2) Сторонние сервисы сбора метрических данных
Если на сайте используются сторонние сервисы сбора метрических данных, помимо Яндекс Метрики, в идеале их все нужно обозначить прямо в cookie-баннере. Хотя именно сервис Яндекса неоднократно упоминался на публичных мероприятиях, его регулятор приводит лишь в качестве наиболее наглядного примера.

3) Сведения о cookies в реестре операторов
Упомянув о сборе данных с использованием cookies на сайте, следует добавить эту информацию и в уведомление об обработке персональных данных. Несоответствие между сайтом и уведомлением – одна из возможных причин получения запросов со стороны Роскомнадзора.

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

Обновления в PrivacyLine

Последние месяцы наша активность в канале немного снизилась. В основном потому, что мы активно работали над улучшением PrivacyLine 😊

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

В этот раз мы сосредоточились на удобстве работы с реестрами и сокращении ручной работы.

Что нового появилось в PrivacyLine:

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

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

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

Подробнее про обновления можно почитать ➡️здесь⬅️.

Благодарим наших пользователей за обратную связь, идеи и предложения. Многие из обновлений этой весной появились благодаря вам 💚

Переход с Excel на PrivacyLine больше не проблема

Один из частых вопросов, который мы слышим от новых пользователей:

«Что делать с реестром процессов, который мы ведём в Excel?»

И это действительно хороший вопрос.
Сегодня Excel – самый распространённый инструмент для ведения реестра процессов обработки персональных данных. За годы работы в таблицах накапливается большой объём информации. Мы понимаем, что перспектива переносить её вручную в новую систему нередко становится барьером для автоматизации.

Теперь этого делать не нужно.
В PrivacyLine появился импорт данных из Excel 🔥

Теперь все пользователи могут:
⚫️быстро перенести существующие реестры процессов в PrivacyLine;
⚫️сохранить уже проделанную работу;
⚫️начать пользоваться системой сразу после загрузки данных.

Если вы используете другой сервис, который поддерживает экспорт данных в Excel, переход на PrivacyLine также станет значительно проще.

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

Оставить заявку

Новые подходы к технической защите персональных данных
 
Судя по проекту приказа, который спешит на смену приказу ФСТЭК № 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) для каждого направления деятельности. Общий уровень зрелости организации определяется как среднее арифметическое текущих уровней по всем направлениям, а результаты визуализируются в виде «лепестковой» диаграммы, сопоставляющей текущий и целевой профили зрелости.
 
⚫️Документирование итогов. По итогам оценки обязательно составляется отчёт с описанием области оценки, участников (в том числе лиц, предоставлявших исходную информацию), методологии и исходных данных, результатов по каждому виду требований и направлению, а также с графической интерпретацией результатов. Методика также предполагает сравнение результатов в динамике и формирование плана мероприятий по достижению целевых показателей.
 
Похоже, что в регулировании технической защиты персональных данных нас ждёт довольно заметный сдвиг: от привычной модели «определили уровень защищённости → выбрали набор мер» к более комплексной оценке того, насколько системно эти меры реализованы и работают на практике. Также бросается в глаза многокомпонентный подход к оценке, который неизбежно повлечет за собой запрос на автоматизацию соответствующего процесса.

Комментарии к Дню открытых дверей Роскомнадзора

Наш скромный коллектив наконец добрался до изучения материалов Дня открытых дверей Роскомнадзора, который состоялся 14 августа 2026 года.

Мероприятие, как всегда, не разочаровало: на нём были озвучены и позиции, упрощающие жизнь операторов, и тезисы, сильно эту жизнь усложняющие. Без взаимоисключающих позиций тоже не обошлось – ведь зачем нужен DPO, если все и так понятно?

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

Делимся ими с вами и заодно спешим пополнить новыми материалами нашу Базу знаний.

🍿Документ с комментариями доступен ➡️здесь⬅️ и в файле, приложенном к посту.

О полезности однозначных разъяснений

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

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

Основные задачи, которые в таком проекте возникают у компании (и, конечно, у DPO), хорошо известны:

⚫️обеспечение требований о локализации при изменении потоков данных;

⚫️подготовка и подача уведомления о намерении осуществлять трансграничную передачу (с оперативной предварительной оценкой сопутствующих рисков);

⚫️внесение изменений в документы, выступающие основаниями для обработки данных (в том числе в части зарубежных провайдеров, привлекаемых к обработке);

⚫️отражение изменений в реестре операторов персональных данных.

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

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

Последние события также подсветили еще один достаточно прикладной вопрос.

Представим, что компания добросовестно локализует данные на российском сервере, также имея зеркальную зарубежную инфраструктуру. В какой-то момент российская база перестает существовать вместе с инфраструктурой её размещения по независящим от компании причинам. Может ли компания для обеспечения непрерывности сервиса временно переключиться на резервные мощности за рубежом и обрабатывать эти данные там, без их локализации (например, на период, пока не будет налажено функционирование новой российской базы)? И если да, то как долго такой режим будет извинителен для компании в глазах регулятора...