Обработка и защита персональных данных: инструкция

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

Если компания работает с ФИО, телефоном, электронной почтой, адресами доставки, идентификаторами пользователей или IP-адресами, она, как правило, оказывается в сфере действия 152-ФЗ. При этом наличие персональных данных само по себе ещё не означает, что для любой операции нужен одинаковый набор документов. Важны цель обработки, правовое основание, состав данных, используемые информационные системы и роль конкретной компании в процессе.

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

Архитектура регулирования: что такое 152-ФЗ и почему 420-ФЗ изменил расчёт рисков

Базовый документ — Федеральный закон № 152-ФЗ «О персональных данных», принятый 27 июля 2006 года. Он определяет, что считать персональными данными и их обработкой, закрепляет принципы работы с информацией, права субъектов и обязанности оператора.

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

Ответственность за отдельные нарушения установлена, в частности, статьёй 13.11 КоАП РФ. Федеральный закон № 420-ФЗ, принятый 30 ноября 2024 года и вступивший в силу 30 мая 2025 года, изменил подход к ряду составов и размерам санкций. Теперь при оценке последствий имеют значение характер нарушения, категория данных, факт утечки, повторность и другие обстоятельства.

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

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

Какие элементы образуют систему

В большинстве компаний система обработки и защиты персональных данных складывается из нескольких контуров:

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

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

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

Уведомление о начале обработки: один оператор, а не отдельный канал на каждый экран

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

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

Здесь часто возникает неправильная логика: компания считает каждую форму, чат-бота, CRM и рассылку отдельным «каналом», который нужно указать в уведомлении самостоятельной строкой. Это не так. Уведомление относится к оператору и описывает его заявленные процессы обработки. Один документ может охватывать несколько каналов и информационных систем, если они действительно соответствуют указанным целям, категориям данных и операциям.

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

Практический порядок выглядит так:

1. Составить перечень процессов: продажи, доставка, поддержка, подбор персонала, маркетинг, аналитика, программа лояльности.

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

3. Проверить правовые основания и сроки хранения.

4. Сопоставить фактические операции с действующим уведомлением.

5. При необходимости направить уточнённые сведения в Роскомнадзор.

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

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

Отсутствие уведомления или несоответствие сведений фактической работе создаёт административный риск, но юридические последствия зависят от конкретного состава и обстоятельств. Нельзя автоматически утверждать, что любая неподача уведомления квалифицируется именно по ч. 1 ст. 13.11 КоАП РФ и всегда влечёт штраф для юридического лица от 150 000 до 300 000 рублей. Квалификацию определяют по фактам проверки, характеру нарушения и применимой норме.

Локализация данных: что именно нужно проверять

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

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

Проверка SaaS-инструмента должна включать несколько уровней:

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

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

Российская база и трансграничная передача — разные вопросы

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

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

Согласие субъекта: не любая обработка начинается с чекбокса

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

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

Рабочая форма обычно разделяет разные цели:

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

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

Не менее важна доказуемость. В системе должны сохраняться:

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

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

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

Реагирование на инциденты: 24/72 часа — это процедура, а не таймер на каждый сбой

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

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

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

Минимальный сценарий реагирования включает:

1. Фиксацию времени обнаружения события и лица, которое его выявило.

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

3. Определение затронутой системы и предварительного объёма данных.

4. Назначение ответственного за коммуникацию с руководством, юристами, ИТ-командой и подрядчиками.

5. Подготовку уведомления в установленный срок.

6. Проведение расследования и оформление его результатов.

7. Корректирующие меры: устранение уязвимости, пересмотр прав доступа, обновление регламентов и обучение сотрудников.

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

Штрафы 2025: почему таблица не заменяет юридическую оценку

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

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

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

Практика построения системы защиты

Шаг 1. Карта обработки

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

Для каждого процесса зафиксируйте:

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

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

Шаг 2. Документы оператора

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

Шаг 3. Формы и интерфейсы

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

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

Шаг 4. Подрядчики и SaaS

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

Проверьте договоры и фактические настройки:

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

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

Шаг 5. Локализация и доступы

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

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

Шаг 6. Реагирование и обучение

Закрепите ответственного за персональные данные и участников аварийной команды. Опишите, куда сотрудник сообщает о подозрительном письме, ошибочной отправке файла или необычной активности в учётной записи.

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

Типичные ошибки бизнеса: где ломается защита

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

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

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

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

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

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

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

Итоги: что считать рабочей системой защиты

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

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

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

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