152-ФЗ: как избежать предписаний Роскомнадзора - практический гид 2026 года
Прямой ответ. Предписание Роскомнадзора по 152-ФЗ почти всегда вырастает из трёх типовых ошибок: обработка данных без уведомления регулятора, документы о защите, не соответствующие реальной инфраструктуре, и пропуск 24-часового срока уведомления об утечке. Предписание нельзя «переиграть» постфактум - его предотвращают заранее: актуальным уведомлением в реестре операторов, мерами по приказу ФСТЭК № 21 и отработанным планом реагирования на инциденты.
Ключевые выводы
С 30 мая 2025 года, когда вступил в силу Федеральный закон № 420-ФЗ, за первичную утечку персональных данных организация платит от 3 до 15 млн рублей - в зависимости от масштаба, а за утечку специальных категорий и биометрии - до 20 млн рублей независимо от количества пострадавших.
За повторную утечку в течение года действует оборотный штраф: от 1% до 3% годовой выручки, но не менее 20 млн и не более 500 млн рублей; для биометрии нижний порог - 25 млн.
Об утечке Роскомнадзор нужно уведомить в течение 24 часов, а с результатами расследования - в течение 72 часов; за молчание - отдельный штраф от 1 до 3 млн рублей (ч. 11 ст. 13.11 КоАП РФ).
С 1 сентября 2025 года согласие на обработку персональных данных оформляется отдельным документом - «зашитое» в оферту согласие больше не работает.
Приказ ФСТЭК № 21 по-прежнему действует, но уже опубликован проект его замены с переходом на риск-ориентированную модель и показатель уровня зрелости (Узи); методика оценки зрелости утверждена ФСТЭК 7 августа 2026 года. Готовиться к новому ландшафту нужно уже сейчас.
Первые 72 часа после обнаружения утечки определяют исход дела: в моей практике компании, уведомившие регулятора в срок и показавшие работающий процесс реагирования, уходили с предупреждением вместо штрафа.
Почему об этом важно говорить именно сейчас
За двадцать пять лет работы в информационной безопасности я не помню периода, когда риск в области персональных данных менялся бы так быстро, как в 2025–2026 годах: фиксированные штрафы выросли на два порядка, появились оборотные санкции, привязанные к выручке, а Роскомнадзор перешёл от выборочных проверок к автоматизированному мониторингу сайтов без предупреждения и без визита инспектора. Вопрос о том, как избежать предписаний Роскомнадзора по 152-ФЗ, сегодня звучит на каждой второй встрече с клиентами «ЛЕГАС», и это не маркетинговое преувеличение, а новая рабочая реальность бизнеса. В этой статье я разберу угрозы с трёх позиций - руководителя ИБ, собственника бизнеса и внешнего аудитора, - приведу публичные инциденты и дела из практики, о которых можно рассказать в рамках наших соглашений о конфиденциальности, и дам готовые алгоритмы подготовки к проверке. Статью подготовил Олег Петухов, руководитель юридической компании «ЛЕГАС» (Москва, Санкт-Петербург, Вологда).
Как избежать предписаний Роскомнадзора: три взгляда на угрозы
Взгляд руководителя ИБ: технический контур обороны
Определение, с которого стоит начать. Уровень защищённости (УЗ) - это установленный постановлением Правительства РФ № 1119 режим защиты информационной системы персональных данных, который определяется категорией обрабатываемых данных, их объёмом, типами актуальных угроз и составом субъектов. Пункты 9–12 постановления № 1119 задают четыре уровня - от УЗ-1 (самый строгий) до УЗ-4 (минимальный). Механизм реализации этого режима - приказ ФСТЭК России от 18 февраля 2013 года № 21, который предписывает группы мер: идентификацию и учёт, управление доступом, ограничение программной среды, антивирусную защиту, регистрацию событий безопасности и другие.
Почему это критично именно сейчас. Отчёты Positive Technologies по ландшафту киберугроз в России показывают устойчивую картину последних лет: чаще всего атакующие входят не через экзотические нулевые дни, а через скомпрометированные учётные записи, непропатченные системы и открытые внешние периметры. Характерный публичный инцидент июня 2025 года, разбиравшийся в отраслевой аналитике: злоумышленники проникли в инфраструктуру онлайн-магазина через сервер «1С» - без двухфакторной аутентификации - зашифровали данные и частично уничтожили резервные копии, уничтожив порядка тридцати процентов резервов. Ни один экзотический вектор не понадобился: открылся административный интерфейс, и этого хватило.
Теперь кейс из практики «ЛЕГАС». По условиям соглашения о конфиденциальности я не могу назвать отрасль и регион клиента, но суть дела передам точно. В 2025 году мы принимали в сопровождение компанию, обрабатывавшую порядка трёхсот тысяч субъектов «иных» персональных данных, - с формально заявленным третьим уровнем защищённости. Первая же разведка показала знакомый набор: устаревшая CRM без обновлений, административный доступ из-за периметра без межсетевой фильтрации, а обмен файлами с подрядчиком шёл через общедоступный облачный диск, в договоре никак не отражённый. Мы перестроили контур по логике приказа № 21 - закрыли группы мер по управлению доступом и регистрации событий, заменили канал обмена защищённым хранилищем с криптографией по приказу ФСБ № 378, связали журналирование с процессом регистрации инцидентов. Через полгода компания прошла контрольное мероприятие без предписаний: проверяющие зафиксировали совпадение модели угроз с фактическим состоянием системы - редкий случай, если откровенно.
Пара слов о том, как на практике раскладываются группы мер приказа № 21, потому что в проектах я регулярно вижу путаницу. ИАФ (идентификация и учёт) - это инвентаризация активов и потоков данных: пока не знаешь, где живёт персональная информация, защищать нечего. УПД (управление доступом) - учётные записи, парольные политики, привилегии администраторов, двухфакторная аутентификация; по моему опыту, именно здесь прячется большинство реальных дыр. ОПС (ограничение программной среды) - whitelist приложений, контроль установленного ПО. РСБ (регистрация событий) - журналирование доступа и действий, причём журналы должны быть защищены от изменения самими администраторами. АВЗ и АНЗ - антивирусная защита и обнаружение вторжений, ОЦЛ - очистка памяти и контроль целостности, ЗИС - защита информации при подключении к общедоступным сетям. Полный перечень групп - в тексте приказа на сайте ФСТЭК (fstec.ru); его стоит распечатать и использовать как чек-лист при проектировании.
Отдельно замечу про регистрацию инцидентов. Многие руководители ИБ считают, что обязанность сообщать о компьютерных атаках касается только госструктур, - это ошибка. Национальный координационный центр по компьютерным инцидентам (НКЦКИ) и Роскомнадзор ожидают от операторов и уведомления об инцидентах, и уведомления об утечках, а сроки по утечкам жёсткие: 24 и 72 часа. Информацию о порядке взаимодействия публикуют НКЦКИ и профильные отраслевые ресурсы; я рекомендую встроить этот канал в регламент реагирования ещё до того, как он понадобится в бою.
И ещё один практический совет, который я даю почти каждому клиенту: не тратьте весь бюджет на периметр. Модель угроз по методике ФСТЭК подразумевает не только внешнего нарушителя, но и внутреннего с неограниченными полномочиями - типовую ошибку администратора, удалённого сотрудника, подрядчика с доступом к базе. Простой тест: попросите подрядчика показать, кто в его команде имеет доступ к вашей базе и как этот доступ логируется. В половине случаев ответ по существу отсутствует - а значит, у вас не работает ни ИАФ, ни УПД, и модель угроз фиктивна не по бумагам, а по сути.
Что сделать в первую очередь:
1. Актуализируйте модель угроз по методике ФСТЭК 2021 года - без неё нельзя корректно определить типы угроз и уровень защищённости.
2. Перепроверьте акт классификации ИСПДн: если база выросла с момента классификации, система должна была переехать на другой уровень, а документы - за ней.
3. Включите двухфакторную аутентификацию на все административные интерфейсы: «1С», CRM, панели управления хостингом и контейнерами.
4. Сведите журналы событий безопасности в единое место с ограниченным доступом - требование регистрации событий приказа № 21 должно быть исполняемым, а не декларативным.
5. Запустите регулярный процесс управления уязвимостями со сканированием и фиксированием результатов: и текущее регулирование, и готовящийся приказ требуют его явно.
Взгляд руководителя бизнеса: деньги, репутация и личная ответственность
Определение ключевого понятия. Оборотный штраф - санкция, размер которой привязан не к фиксированной сумме, а к выручке компании. С 30 мая 2025 года за повторную утечку персональных данных юридическое лицо платит от 1% до 3% совокупной годовой выручки за предшествующий календарный год, но не менее 20 млн рублей и не более 500 млн. Для биометрических данных нижний порог - 25 млн. К этому добавляются составы за несообщение об утечке (1–3 млн для юрлиц), за неуведомление о начале обработки (100–300 тыс.) и уголовная ответственность по статье 272.1 УК РФ за незаконный оборот баз данных, введённая Федеральным законом № 421-ФЗ с 11 декабря 2024 года.
Судебная практика 2026 года разницу между «есть документы» и «есть процесс» показывает нагляднее любых лекций. Публично разбиравшееся дело маркетплейса со второй за семь месяцев утечкой на восемь миллионов записей: компания узнала об инциденте через три недели после его начала и уведомила регулятора с опозданием - итог, оборотный штраф в 380 млн рублей. И противоположный случай: EdTech-платформа с утечкой четырнадцати тысяч записей зафиксировала аномалию за шесть часов, уведомила Роскомнадзор через восемнадцать часов, в тот же день закрыла уязвимый интерфейс API и к рассмотрению дела продемонстрировала завершённое устранение нарушений - получила предупреждение вместо штрафа по статье 4.1.1 КоАП РФ. Оба дела разошлись по профильным юридическим обзорам 2026 года, и я рекомендую показать их совету директоров любой компании, которая считает ИБ «статьёй расходов, которую можно ужать».
Пример из практики «ЛЕГАС» - на этот раз с отрицательным исходом, потому что такие кейсы учат лучше. Средняя компания из сферы логистики в Санкт-Петербурге получила предписание после того, как проверка установила обработку персональных данных клиентов через сайт без уведомления Роскомнадзора. Внутренняя позиция была типовой: «сайт-визитка, форма обратного звонка - о чём говорить». Санкция по части 10 статьи 13.11 КоАП составила 150 тыс. рублей - неприятно, но терпимо. Дорогой оказалась не санкция, а обвязка: срочное выправление документации, перенос сроков подписания дистрибьюторского контракта, потому что партнёр запросил подтверждение соответствия 152-ФЗ, и репутационный след в отраслевом чате закупщиков. После того как мы внедрили регламент «новая форма сбора данных - новая запись в уведомлении», повторных находок у клиента не было.
Как распределять бюджет, когда денег «на всё сразу» нет? Рекомендую матрицу приоритетов, отработанную на наших проектах. Первая строка - уведомление в реестре и соответствие сайта: это копейки, а риск исключает полностью. Вторая - двухфакторная аутентификация и управление доступом: максимальный эффект на вложенный рубль, потому что закрывает самый частый вектор. Третья - обучение персонала и фишинговые тренировки: человеческий фактор по-прежнему в верхних строчках любой статистики утечек. Четвёртая - внешний аудит и модель угроз. Пятая - специализированные средства: DLP, SIEM, мониторинг утечек. Именно в таком порядке, а не наоборот: я видел компании с дорогим SIEM, куда никто не смотрит, и без уведомления в реестре - это как бронированная дверь в доме без стен.
Отдельно про личную ответственность. Протоколы об административных правонарушениях по статье 13.11 выносятся не только в адрес компании: санкции по отдельным составам применяются и к должностным лицам. На практике это означает, что «ответственный за обработку», назначенный для галочки, при инциденте превращается в реального ответчика, а руководство не может ссылаться на незнание. Я рекомендую оформлять назначение ответственного так, чтобы человек понимал объём обязанностей, имел ресурсы на их исполнение и полномочия требовать их от ИТ и бизнеса - иначе вы не столько назначаете ответственного, сколько назначаете виноватого.
Что сделать руководителю в первую очередь:
1. Назначьте лицо, ответственное за организацию обработки персональных данных, и наделите его реальными полномочиями - не формальным приказом «на всякий случай» (статья 22.1 152-ФЗ).
2. Проверьте статус компании в реестре операторов: уведомление подаётся до начала обработки и актуализируется при каждом изменении целей и перечня данных.
3. Включите цифры информационной безопасности в бюджет как управленческое решение, а не как «пожелание ИТ»: стоимость минимально приемлемого контура несопоставима с нижней планкой оборотного штрафа в 20 млн рублей.
4. Требуйте от ИТ-команды не статусов «сделано», а проверяемых артефактов: журналы, отчёты о сканировании уязвимостей, протоколы учений по инциденту.
5. Раз в год заказывайте внешний аудит соответствия - документированная проактивность суды и регулятор оценивают как смягчающее обстоятельство.
Здесь многие ошибаются в обратную сторону: думают, что после мая 2025 года «всё уже знают» и проверок бояться нечего. Знать - не значит исполнять. Плановых проверок в классическом виде стало меньше, зато автоматизированный мониторинг и внеплановые мероприятия по жалобам субъектов никуда не делись - просто теперь они приходят внезапно и к подготовленным.
Взгляд внешнего аудитора: где проверка находит нарушения
Определение рабочего термина. Предписание - обязательное для исполнения требование об устранении выявленных нарушений с конкретным сроком; неисполнение влечёт повторное привлечение к ответственности и, как правило, повторную проверку. Предписание - это не «бумажка», а юридический факт, который потом всплывает при любом последующем инциденте как доказательство системности нарушений.
За годы аудиторской работы я научился находить нарушения почти всегда в одних и тех же трёх местах. Первое - расхождение между сведениями в реестре операторов и фактическим состоянием: на сайте одна форма сбора данных, в уведомлении - другая, в политике - третья. Три и более расхождения дают прямое основание для внепланового контрольного мероприятия. Второе - «мёртвые» документы: модель угроз написана в 2015 году, а система в 2024-м переехала в облако; формально бумаги есть, фактически модель описывает несуществующую систему. Третье - отсутствие доказательств получения согласий: без журналирования времени, IP-адреса и идентификатора пользователя согласие юридически уязвимо, а при споре - ничтожно.
Публичная статистика здесь красноречива. По данным аналитического центра InfoWatch, более половины утечек в торговой отрасли Российской Федерации приходится на маркетплейсы и интернет-магазины - свыше 51% инцидентов отрасли за 2025 год. Вывод прост и неприятен: если вы продаёте онлайн, вы находитесь в самой уязвимой когорте, и проверяющие это знают так же хорошо, как вы.
Кейс «ЛЕГАС» из аудиторской практики - с той же оговоркой о конфиденциальности, которая, честно говоря, и делает такие рассказы возможными: детали меняются, диагноз остаётся. Финтех-сервис обратился к нам за предаудитом перед плановым контрольным мероприятием. Обследование вскрыло цепочку, о которой руководство не догадывалось: данные клиентов уходили в CRM, размещённую на зарубежном хостинге, - прямое нарушение части 5 статьи 18 152-ФЗ о первичном сборе и хранении на территории России. За шесть недель мы мигрировали первичную базу на российскую инфраструктуру, переоформили договоры-поручения с обработчиками по части 3 статьи 6, обновили уведомление и политику. Проверка прошла без предписаний - регулятор зафиксировал проактивную позицию оператора, которая сама устранила нарушение до его выявления.
Небольшая региональная зарисовка из практики, потому что она показательна. В Москве и Санкт-Петербурге аудиторы чаще всего ловят компании на облачных интеграциях и зарубежных сервисах - там просто выше плотность цифрового бизнеса и больше точек входа. В Вологодской области и на Северо-Западе в целом моя типичная находка иная: локальные предприятия годами работают по «наследственным» документам, составленным ещё до первой реформы 152-ФЗ, при этом сами системы давно выросли - добавились CRM, мобильные приложения, обмен с федеральными контрагентами. Документы не догнали рост. Вывод один и для столиц, и для регионов: аудит надо привязывать не к календарю, а к изменениям в бизнесе.
Алгоритм аудита перед проверкой:
1. Сверьте сайт, реестр операторов и модель угроз между собой - именно на расхождения между этими тремя точками проверяющие ловят быстрее всего.
2. Проверьте фактическую географию хостинга и всех сторонних интеграций: серверы, CDN, сервисы рассылок, аналитика.
3. Убедитесь, что согласия собираются отдельными документами с фиксацией факта получения - журналирование здесь не опция.
4. Запросите у подрядчиков-обработчиков подтверждение уровня защищённости их систем: с развитием регулирования эта обязанность оператора только усиливается.
5. Проведите учения по инциденту: регламент, который ни разу не «проигрывался», в день реальной утечки не работает.
Изменения в ландшафте угроз и регулировании
Актуальность блока - октябрь 2026 года.
Регуляторная волна последних полутора лет беспрецедентна по скорости. 30 мая 2025 года вступил в силу Федеральный закон № 420-ФЗ: девять новых составов в статье 13.11 КоАП РФ, рост штрафов за первичную утечку до 15 млн рублей, оборотные штрафы за повторную и отмена привычной 50-процентной скидки при досрочной уплате. С 1 июля 2025 года действует прямой запрет хранить первичные базы персональных данных граждан России за пределами страны. С 1 сентября 2025 года согласие оформляется отдельным документом, а Роскомнадзор работает по риск-ориентированной модели надзора, утверждённой постановлением Правительства № 1286: операторы биометрии, специальных категорий и трансграничной передачи автоматически попадают в группу высокого риска. Отдельный пласт - трансграничная передача: с 1 марта 2025 года её порядок радикально ужесточён, для «недружественных» стран требуется предварительное уведомление и разрешение регулятора, и эта тема стабильно входит в топ запросов наших клиентов. Официальные разъяснения Роскомнадзор публикует на rkn.gov.ru в разделе «Персональные данные», тексты законопроектов - на pravo.gov.ru.
На технической стороне происходят не менее важные события. С 1 марта 2026 года действует приказ ФСТЭК России № 117 от 11 апреля 2025 года - новые требования к государственным информационным системам. Приказ № 21 продолжает действовать, но 24 июля 2026 года ФСТЭК опубликовала проект нового приказа, который должен его заменить: вместо фиксированного перечня мер - риск-ориентированный подбор с учётом архитектуры системы, отдельные требования к облачным и контейнерным средам, безопасной разработке, использованию искусственного интеллекта и обязательная передача сведений об атаках в ГосСОПКА. Ключевой новый показатель - уровень зрелости защиты информации (Узи), оцениваемый перед началом обработки, не реже одного раза в три года и после каждого компьютерного инцидента. Здесь важна точность: методика оценки зрелости утверждена ФСТЭК 7 августа 2026 года и уже применима, а сам заменяющий приказ пока существует в статусе проекта - на момент подготовки статьи он не вступил в силу. Приказ № 117, кстати, уже требует оценивать показатель зрелости (Пзи) не реже одного раза в два года, и новая методика закрывает методический пробел в его расчёте. Синхронно меняется и сам ландшафт угроз: Positive Technologies в прогнозе на 2026 год указывают на рост шантажа с использованием украденных баз персональных данных - утечка теперь «монетизируется» дважды, злоумышленником через вымогательство и регулятором через санкции, а в системе ФинЦЕРТ и ГосСОПКА фиксируется устойчивый рост инцидентов с компрометацией учётных записей и атаками на цепочки поставок.
Вопрос-ответ из практики
Что делать в первые 24 часа после обнаружения утечки?
Моё мнение жёсткое: всё решает скорость, и это не красивый оборот, а наблюдение из реальных дел. Часть 3.1 статьи 21 152-ФЗ требует уведомить Роскомнадзор в течение 24 часов с момента получения информации об инциденте, а в течение 72 часов - представить результаты внутреннего расследования. Опирайтесь на ГОСТ Р ИСО/МЭК 27001-2021, где управление инцидентами выделено в обязательную функцию системы менеджмента, и на структуру NIST Cybersecurity Framework 2.0 с её функцией Respond - оба документа дают понятную логику реагирования, которую регулятор воспринимает как профессиональную норму.
Кейс из практики: в одной из наших консультаций клиент обнаружил компрометацию учётной записи менеджера отдела продаж в вечер пятницы. По внутреннему регламенту, который мы внедряли за полгода до того, дежурный не ждал утра: изолировал учётную запись, зафиксировал время обнаружения, уведомил Роскомнадзор через личный кабинет в течение суток и направил повторное уведомление с результатами расследования через 72 часа. Утечка затронула около двух тысяч контактов, однако дело закончилось профилактическим разговором, а не штрафом, - регулятор увидел отработанный процесс. Имена и отрасль, как всегда, под конфиденциальностью.
Алгоритм:
1. Зафиксируйте факт и точное время обнаружения - с этой минуты начинают идти установленные сроки.
2. Уведомите Роскомнадзор первично через личный кабинет оператора; форма допускает свободное изложение, но факты должны быть конкретными.
3. Изолируйте источник компрометации и сохраните доказательства - ни в коем случае не «чистите» логи, это квалифицируется как отягчающее обстоятельство.
4. Оцените масштаб: категории данных, количество субъектов и идентификаторов - от этого зависит вменяемый состав правонарушения.
5. Уведомите затронутых субъектов, если обработка велась без согласования с конкретным лицом, допустившим нарушение.
6. Через 72 часа направьте повторное уведомление с результатами расследования и принятыми мерами.
Рекомендация: держите шаблоны уведомлений и контактные данные ответственных в печатном виде у дежурного - инциденты имеют свойство случаться в пятницу вечером.
Нужно ли уведомлять Роскомнадзор, если у меня маленькая база или сайт-визитка?
Да, обязательно, и здесь я бываю непреклонен с клиентами. С 30 мая 2025 года обязанность распространяется на организации, индивидуальных предпринимателей и даже самозанятых: сбор данных через любую форму обратной связи - уже обработка персональных данных, а уведомление подаётся до начала обработки в соответствии с частью 1 статьи 22 152-ФЗ. Штраф за неуведомление - от 100 до 300 тыс. рублей по части 10 статьи 13.11 КоАП. Форма уведомления утверждена приказом Роскомнадзора от 28 октября 2022 года № 180.
Типичный диалог на консультации выглядит так: «У нас пять контактов в месяц, вообще-то». Отвечаю: пять контактов - это пять субъектов персональных данных, а обязанность уведомить не зависит от их количества. Опасность малых компаний не в размере штрафа, а в том, что у них нет процессов: уведомление забыли, политика не опубликована, согласие собрано «как-нибудь». Ровно эту комбинацию Роскомнадзор находит автоматическим мониторингом сайтов - алгоритмы сканируют формы сбора данных на каждом втором домене, и человеческий фактор тут не спасает.
Алгоритм:
1. Инвентаризируйте все точки сбора данных: сайт, виджеты чатов, квизы, офлайн-анкеты, формы на выставках.
2. Определите цели и перечень данных для каждой точки отдельно - обобщение «прочие цели» проверку не проходит.
3. Подайте уведомление по форме приказа № 180 - процедура бесплатна и занимает дни, а не недели.
4. Заведите регламент актуализации уведомления при каждом изменении набора данных или целей - в течение десяти рабочих дней с момента изменения.
5. Раз в квартал сверяйте сведения в реестре с фактическим содержанием сайта.
Рекомендация: относитесь к уведомлению как к паспорту системы, который живёт вместе с ней, а не как к разовой бумаге из папки «сделано и забыто».
Что будет вместо приказа ФСТЭК № 21 и когда готовиться?
Ситуация здесь тоньше, чем её подают в некоторых обзорах, и я разберу её с максимальной точностью. Приказ № 21 действует; 24 июля 2026 года ФСТЭК опубликовала проект замещающего приказа с переходом на риск-ориентированную модель и показатель Узи, однако на момент подготовки этой статьи он не вступил в силу - не стоит строить решения на его тексте как на обязательном. При этом методика оценки уровня зрелости утверждена 7 августа 2026 года и уже работает, в том числе для операторов ИСПДн: она предусматривает оценку по 21 направлению деятельности - от управления уязвимостями и обновлениями до работы с подрядчиками и контроля защищённости. Для систем по приказу № 117 оценка зрелости уже обязательна не реже одного раза в два года. Методика рекомендует целевые значения зрелости в зависимости от уровня защищённости: не ниже единицы для УЗ-3 и УЗ-4, не ниже двух для УЗ-2 и не ниже трёх для УЗ-1.
Кейс из практики «ЛЕГАС»: одна производственная компания попросила нас провести «пилотную» самооценку зрелости по новой методике, ещё до того, как это станет обязательным. Результат был трезвым: по шести направлениям из двадцати одного показатель оказался нулевым - процессы существовали только на бумаге. Зато компания получила полтора года на планомерное закрытие пробелов вместо шести месяцев аврала. Такой «предварительный замер» я считаю одним из самых выгодных вложений в ИБ на текущий момент: цена вопроса - консультационные часы, а экономия - спокойный переход и отсутствие дедлайн-паники.
Алгоритм:
1. Оцените текущее состояние по «духу» нового регулирования, используя утверждённую методику, - это даст базовую линию без риска преждевременных обязательств.
2. Закройте пробелы по управлению уязвимостями и безопасной разработке - они присутствуют и в проекте приказа, и в методике, поэтому вложения в них не сгорят при любом сценарии.
3. Включите подрядчиков в программу оценки зрелости - методика прямо предусматривает установление требований к зрелости третьих лиц.
4. Заложите периодичность оценки в бюджет и регламент: раз в три года станет нормой, дешевле встроить её в процесс заранее.
5. Проработайте с юристами вопрос, как показатель зрелости будет фигурировать в договорах с заказчиками и страховыми - я ожидаю, что он станет стандартным пунктом тендерной документации.
Рекомендация: компании, которые пройдут первую самооценку зрелости заранее, окажутся в выигрышном положении по сравнению с теми, кто начнёт готовиться под дедлайн.
Как понять, попадёт ли компания под плановую проверку в 2026 году?
С 5 сентября 2025 года действует риск-ориентированная модель надзора по постановлению Правительства № 1286: каждой организации присваивается категория риска. В группу высокого и чрезвычайно высокого риска автоматически попадают операторы, обрабатывающие биометрию, специальные категории и осуществляющие трансграничную передачу, а также компании с историей нарушений. Внеплановые проверки запускаются по конкретным триггерам: три и более расхождения между реестром и сайтом, жалобы субъектов, публикации об утечках. По моему опыту, самый частый триггер - именно расхождение «сайт против реестра»: машина Роскомнадзора сканирует формы сбора данных автоматически, и человеческий фактор тут не спасает.
Кейс из практики: региональный медицинский центр из Вологодской области обратился к нам после того, как узнал о жалобе пациента, недовольного рассылкой. Проверка не была назначена, но риск был высокий: медцентр обрабатывал специальные категории данных, что автоматически относит его к повышенной категории риска. Мы за две недели привели в порядок согласия, опубликовали актуальную политику и разослали отписки всем, кто не дал согласия на рассылки. Жалобу закрыли досудебно, проверка так и не состоялась. Мораль проста: категория риска не обязательно означает проверку, но означает, что готовиться стоит.
Алгоритм:
1. Оцените свою категорию риска по критериям постановления № 1286, включая планы обработки данных на ближайший год.
2. Устраните расхождения «сайт - реестр - документы», начав с самых очевидных: неактуальные формы, забытые виджеты, старые политики.
3. Отработайте процесс приёма и ответа на запросы субъектов персональных данных - на них жалуются чаще, чем проверяют.
4. Проведите профилактический аудит своими силами или с внешним консультантом: внеплановая проверка разрешения не спрашивает.
5. Документируйте всё, что доказывает добросовестность: отчёты об обучении сотрудников, протоколы учений, история исправлений.
Рекомендация: проверьте прямо сейчас, что в реестре операторов указаны актуальные цели, перечни данных и применяемые средства защиты.
Что делать с cookie, системами аналитики и зарубежными сервисами?
Здесь многие ошибаются, считая аналитику «техническими данными», которые персональными не являются. Роскомнадзор рассматривает cookie с уникальными идентификаторами как персональные данные, поэтому использование аналитических систем требует согласия пользователя, отражения в уведомлении и описания в политике обработки. Зарубежные облачные сервисы для первичного хранения данных российских граждан - прямое нарушение части 5 статьи 18 152-ФЗ, а с 1 июля 2025 года - и запрета на хранение за рубежом. Отдельная тонкость: сервисы, перенаправляющие данные за границу, требуют регламентированного порядка трансграничной передачи с уведомлением регулятора по правилам статьи 12 152-ФЗ.
Кейс из практики: интернет-магазин из Санкт-Петербурга при подготовке к инвестраунду получил от юридического департамента покупателя требование подтвердить законность обработки данных. Аудит, который мы провели, показал: на сайте жили три счётчика аналитики, один из которых передавал данные за границу, плюс чат-поддержка на зарубежной платформе. Всё это было легализуемо, но требовало отдельного согласия, уведомления и правильно оформленной трансграничной передачи. Сделка не сорвалась, но пришлось ускоренно заниматься документами в момент, когда внимание руководства было приковано к цифрам раунда.
Алгоритм:
1. Инвентаризируйте все скрипты и интеграции на сайте, включая «встроенные подрядчиком» - именно они чаще всего становятся сюрпризом на проверке.
2. Опишите cookie в политике с возможностью отказа от отдельных категорий, а не «всё или ничего».
3. Включите баннер согласия с фиксацией выбора пользователя и хранением этой фиксации.
4. Переведите первичное хранение персональных данных на российскую инфраструктуру - это не дискуссионный вопрос, а прямое требование закона.
5. Обновите уведомление и договоры-поручения с актуальным перечнем обработчиков и их локаций.
Рекомендация: при любой замене сервиса аналитики или CRM пересматривайте всю юридическую обвязку - изменения в технологическом стеке почти всегда означают изменения в документах.
Сравнительная таблица: сценарии утечки и контрмеры
|
Сценарий утечки |
Типовой вектор |
Мера защиты (ссылка) |
Что проверит Роскомнадзор |
Риск без меры |
|
Компрометация админ-доступа в «1С»/CRM |
Кража учётных данных, отсутствие 2FA |
Управление доступом и регистрация событий (приказ ФСТЭК № 21) |
Журналы, парольные политики, наличие 2FA |
Штраф 3–5 млн ₽ и выше |
|
Публичное облачное хранилище |
Ошибка конфигурации бакета |
Контроль доступа и конфигураций (приказ № 21, методика ФСТЭК 2021) |
Политика, модель угроз, договор с обработчиком |
Предписание + риск оборотного штрафа |
|
Утечка через подрядчика |
Отсутствие договора-поручения |
Часть 3 статьи 6 152-ФЗ; контроль обработчиков |
Договоры, подтверждение уровня защищённости подрядчика |
До 1–3 млн ₽ + солидарные последствия |
|
Зарубежный сервис или хостинг |
Нарушение локализации |
Часть 5 статьи 18 152-ФЗ; запрет хранения с 01.07.2025 |
Фактическое размещение серверов, DNS-следы |
Штраф + ограничение сбора данных |
|
Инсайдер |
Избыточные права, выгрузка на личный диск |
Разграничение доступа, учёт носителей (приказ № 21) |
Перечень допущенных лиц, журналы доступа |
Штраф до 3 млн ₽, уголовный риск по ст. 272.1 УК |
Частые ошибки
Согласие «зашито» в оферту. С 1 сентября 2025 года оно должно быть отдельным документом - иначе вся обработка формально лишена правового основания. Как избежать: отдельная форма согласия на каждом канале сбора, с фиксацией факта получения.
Уведомление подано один раз и забыто. Изменение перечня данных без актуализации - самостоятельный состав; плюс три расхождения с сайтом дают внеплановую проверку. Как избежать: регламент квартальной сверки «сайт - реестр - документы».
Модель угроз не соответствует фактической архитектуре. Система переехала в облако, а модель описывает локальный сервер; проверяющие находят это за минуты. Как избежать: привязать актуализацию модели к любому изменению инфраструктуры, а не к календарю.
Нет плана реагирования на инциденты. Руководство узнаёт об утечке из СМИ - сроки 24 и 72 часа пропущены, максимум смягчающих обстоятельств потерян. Как избежать: регламент с ролями, шаблонами и хотя бы одним проведённым учением в год.
Зарубежные сервисы «просто для аналитики». Скрипты зарубежных систем и зарубежный хостинг без отражения в документах - готовое основание для санкций. Как избежать: инвентаризация всех внешних интеграций с документированием их локаций и целей.
Заключение
152-ФЗ перестал быть «бумажным» законом: штрафы выросли на порядок, проверки стали риск-ориентированными, а первая судебная практика показала, что кооперация с регулятором экономит сотни миллионов рублей. Защита персональных данных сегодня - это связка «документы, соответствующие реальности + технический контур по приказу ФСТЭК + отработанный процесс реагирования», и любой из трёх элементов, взятый отдельно, не спасает. Как избежать предписаний Роскомнадзора по 152-ФЗ - самый частый вопрос наших клиентов в 2026 году, и мой ответ всегда начинается с одного конкретного действия: сегодня же сверить сведения в реестре операторов с фактическим содержанием сайта и инфраструктуры. Если нужна помощь - от аудита соответствия до сопровождения при проверках и перехода на новые требования ФСТЭК - команда «ЛЕГАС» в Москве, Санкт-Петербурге и Вологде к вашим услугам.
Об авторе
Петухов Олег Анатольевич - руководитель юридической компании «ЛЕГАС» (офисы в Москве, Санкт-Петербурге и Вологде), эксперт по информационной безопасности с 25-летним стажем. Специализация: защита информации, комплаенс в области ИБ, реагирование на компьютерные инциденты, правовое сопровождение проектов защиты персональных данных и КИИ. За время практики руководил десятками проектов аудита соответствия и внедрения требований ФСТЭК и ФСБ в частном и государственном секторе. В «ЛЕГАС» развивает практику информационной безопасности - от первичного аудита до правового сопровождения ИБ-проектов и защиты интересов операторов во взаимодействии с Роскомнадзором. Авторская страница - на legascom.ru.
Поделитесь статьёй с коллегами - особенно с теми, кто отвечает за сайт, CRM и кадровое делопроизводство: именно в этих трёх местах я чаще всего нахожу нарушения.
Подпишитесь на обновления legascom.ru - разбираем сложное просто, без воды и страшилок.