Закон о защите персональных данных: что это простыми словами

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

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

Что считается персональными данными по закону № 152-ФЗ

Федеральный закон № 152-ФЗ «О персональных данных» работает по достаточно широкой логике: персональными считаются сведения, которые прямо или косвенно относятся к определённому или определяемому физическому лицу. Для этого не обязательно иметь одновременно паспорт, адрес и дату рождения. Иногда человека можно выделить из общей массы по комбинации менее очевидных признаков.

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

К персональным данным на практике могут относиться:

• фамилия, имя, отчество, дата и место рождения, пол, гражданство;
• номер телефона, адрес электронной почты, почтовый адрес;
• паспортные данные, СНИЛС, ИНН, номер полиса ОМС;
• сведения о месте работы, должности, доходах и профессиональном опыте;
• данные аккаунта, клиентский идентификатор, история обращений и заказов;
• cookie-файлы, рекламные идентификаторы и сведения об устройстве, если их можно связать с конкретным пользователем;
• фотографии, видеозаписи и аудиозаписи — в зависимости от того, как компания их использует и можно ли по ним определить человека.

Последний пункт требует отдельного пояснения. Биометрические персональные данные — это не любые сведения о внешности или голосе. Фотография сама по себе не становится биометрией автоматически. Если снимок размещён в профиле сотрудника или приложен к анкете как обычная иллюстрация, это персональные данные, но не обязательно биометрические. Иная ситуация возникает, когда изображение используется для установления личности: например, при автоматическом распознавании лица или сопоставлении с шаблоном в системе контроля доступа.

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

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

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

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

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

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

Масштаб ответственности: как работают дифференцированные штрафы

До ужесточения санкций штрафы за нарушения в сфере персональных данных многие компании воспринимали как неприятную, но ограниченную статью операционных расходов. Такой подход быстро устаревает. С 30 мая 2025 года начали действовать поправки Федерального закона № 420-ФЗ от 30.11.2024, после которых размер ответственности стал сильнее зависеть от масштаба утечки и количества затронутых субъектов.

Для юридических лиц градация штрафов за отдельные составы нарушения выглядит так:

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

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

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

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

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

Оборотные штрафы за повторные инциденты и риски для бизнеса

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

За повторную утечку персональных данных для юридических лиц и индивидуальных предпринимателей предусмотрены оборотные штрафы в размере от 1% до 3% от годовой выручки — с установленными минимальным и максимальным пределами. В зависимости от состава и обстоятельств дела речь может идти о сумме не менее 20–25 млн рублей и не более 500 млн рублей.

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

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

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

Практически полезный план после инцидента обычно включает несколько направлений:

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

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

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

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

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

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

Регламент реагирования: 24 часа на уведомление регулятора

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

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

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

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

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

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

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

6. Представить результаты в установленный срок. В отчёте нужно описать причины, последствия, принятые меры и дальнейший план устранения уязвимостей.

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

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

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

Почему аутсорсинг обработки данных не снимает ответственности с оператора

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

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

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

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

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

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

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

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

Как выстроить защиту данных так, чтобы это работало на бизнес

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

Работу можно начать с четырёх последовательных направлений.

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

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

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

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

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

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

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