
Согласие на обработку персональных данных: что изменилось с сентября 2025 и как это влияет на корпоративные процессы
1 сентября 2025 года вступил в силу пакет поправок к 152‑ФЗ. Большинство компаний обновили форму согласия на сайте и посчитали задачу выполненной.
Это ошибка.
Изменения касаются не только формы на сайте. Они меняют логику того как данные клиентов должны обрабатываться внутри компании — кто к ним имеет доступ, с какой целью и как это подтверждается.
Что именно изменилось
До сентября 2025 года согласие могло быть сформулировано широко. «Для улучшения сервиса», «для маркетинговых целей», «для обеспечения работы сайта» — эти формулировки воспринимались как достаточные.
Поправки ужесточили требования к конкретности.
Теперь в согласии нужно указывать конкретные цели обработки. Не «маркетинговые цели» — а что именно: рассылка новостей, персональные предложения, аналитика поведения на сайте.
Нужно перечислять конкретные категории данных. Не «персональные данные» — а что именно: имя, телефон, email, история покупок.
Нужно указывать третьих лиц которым данные могут передаваться. Сервис рассылок, CRM-провайдер, аналитическая платформа — всё это должно быть в согласии.
Усилились требования к уведомлению при изменении условий обработки. Если вы меняете цели или начинаете передавать данные новому партнёру — клиент должен быть уведомлён.
Соответствует ли круг сотрудников с доступом к данным клиентов целям обработки в вашем согласии?
RBAC в BearPass позволяет выстроить доступ к учётным данным систем с персональными данными строго по ролям. Журнал фиксирует каждое обращение. До 5 пользователей бесплатно навсегда.
Связь с управлением доступами: почему это не только юридический вопрос
Вот где большинство компаний допускают ошибку. Они обновляют форму согласия, но не пересматривают кто внутри компании имеет доступ к данным клиентов.
Логика 152‑ФЗ такая. Клиент дал согласие на обработку данных с конкретными целями. Это значит данные могут использоваться только для этих целей. Это значит доступ к ним должен быть только у тех сотрудников которые работают в рамках этих целей.
Если клиент дал согласие на обработку заявки — его данные должны видеть только те кто обрабатывает заявки. Не маркетологи. Не аналитики. Не весь офис.
Это принцип целевой обработки. Он в 152‑ФЗ с самого начала — но поправки 2025 года сделали его соблюдение более требовательным и более проверяемым.
При расследовании инцидента регулятор будет смотреть не только на форму согласия. Он будет выяснять кто фактически имел доступ к данным и соответствует ли это целям зафиксированным в согласии.
Что нужно пересмотреть в корпоративных процессах
Шаг первый: сопоставьте цели обработки из согласий с реальной практикой. Для каждой системы где хранятся клиентские данные — опишите с какой целью данные туда попадают. Сравните с тем что написано в согласии.
Шаг второй: проверьте матрицу доступов. Для каждой системы с клиентскими данными — кто имеет к ней доступ. Все ли из этого списка работают в рамках целей из согласия.
Если бухгалтер имеет доступ к CRM с данными клиентов — это нужно объяснить с точки зрения целей обработки. Если объяснения нет — это нарушение.
Шаг третий: выстройте журнал доступов к системам с персональными данными. При проверке или расследовании вопрос будет конкретным: покажите кто и когда обращался к данным клиентов, с какого IP, что именно делал. Без журнала этот вопрос остаётся без ответа.
Как это выглядит при проверке Роскомнадзора
Инспектор приходит после жалобы клиента или после обнаружения утечки. Он запрашивает согласие. Проверяет соответствие формулировок реальной практике. Смотрит кто имел доступ к данным.
Если в согласии написано «обработка заявок», а доступ к клиентской базе имели 30 сотрудников из разных отделов — это вопрос к оператору. Ответить «так исторически сложилось» не получится.
Если есть журнал доступов с гранулярными правами по ролям — это аргумент в пользу оператора. Журнал показывает что доступ был организован осознанно и в соответствии с принципом минимальных привилегий.
BearPass
Доступ к данным клиентов только по ролям — и журнал каждого обращения
RBAC · Журнал событий · Kill Switch · LDAP On-premise · Реестр РФ №15427 · Шифрование ГОСТ
Три практических вывода
Обновить согласие недостаточно. Нужно проверить что реальная практика обработки данных соответствует тому что написано в согласии.
Матрица доступов — это теперь юридический документ. Круг лиц имеющих доступ к данным клиентов должен соответствовать целям обработки. Избыточный доступ — это не просто неудобство, это нарушение.
Журнал доступов — доказательная база. При проверке или расследовании журнал который показывает что доступ был ограничен нужными ролями — это аргумент в пользу оператора.
Итог
Поправки к 152‑ФЗ с сентября 2025 года — это не только про форму на сайте. Это про то как данные обрабатываются внутри компании. Конкретное согласие с конкретными целями требует конкретного ограничения доступа к данным. Ролевая модель доступа и журнал событий — это технический ответ на юридическое требование.
BearPass — корпоративный менеджер паролей
RBAC и журнал доступов к данным клиентов. Готово к проверке РКН.
Ролевой доступ · Журнал событий · Kill Switch · LDAP On-premise · Данные на вашем сервере · Реестр РФ №15427 · ГОСТ Развёртывание за 1–2 часа · Поддержка: portal.bearpass.ru