Cookie-баннер по 152-ФЗ в 2026: как сделать правильно и не получить штраф

У большинства сайтов баннер про cookie есть с 2018-2019 года. Обычно это фраза "Мы используем cookies для улучшения работы сайта" и одна кнопка где-то внизу экрана. Скопировано с иностранного шаблона, ни разу не редактировалось, юридического смысла не несёт - просто визуальный шум, к которому все привыкли.

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

Почему cookie теперь персональные данные

152-ФЗ прямо про cookie не говорит - в тексте закона этого слова просто нет. Но с 30 мая 2025 года, когда вступили в силу поправки закона 420-ФЗ от ноября 2024 года, Роскомнадзор закрепил на практике позицию, которую и раньше высказывал неофициально: cookie-файлы, включая идентификаторы устройства и данные счётчиков вроде Яндекс.Метрики, позволяют идентифицировать пользователя в сети - а значит, подпадают под определение персональных данных из ст. 3 закона.

Смотрите на это так. Cookie сами по себе - просто текстовый файл в браузере. Но связка "cookie + IP + история посещений + поведение на сайте" даёт достаточно данных, чтобы отличить одного посетителя от другого и при желании его деанонимизировать. Именно эта способность идентифицировать - критерий, а не технический факт наличия файла в браузере.

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

Активное, конкретное и осознанное согласие требует ст. 6 152-ФЗ для любой обработки персональных данных без иного законного основания. Прямого текста "разместите баннер" в законе нет, но на практике доказать факт согласия при проверке нечем ничем, кроме зафиксированного действия пользователя - клика по кнопке. Отсюда и появился баннер как единственный практичный способ выполнить требование закона.

Каким должен быть правильный cookie-баннер

Смысл в том, чтобы дать пользователю реальный выбор, а не иллюзию выбора. На практике это означает несколько конкретных требований.

• Баннер виден сразу при заходе на сайт - без прокрутки, без захода в футер, без поиска мелкой ссылки внизу страницы
• Кнопки "Принять" и "Отказаться" равнозначны по весу: одинаковый размер, контрастность, расположение. Прятать отказ бледным текстом на сером фоне, пока "Принять" горит зелёной кнопкой - типичный тёмный паттерн, который регулятор и юристы уже научились опознавать
• Есть возможность выбрать категории cookie отдельно - как минимум разделение на технические (обязательные для работы сайта), аналитические и рекламные
• Никаких предустановленных галочек ни в одном чекбоксе - согласие даёт сам пользователь активным действием, бездействие или закрытие баннера крестиком за согласие не считается
• Cookie, которые не являются строго необходимыми для работы сайта, не загружаются до момента, пока пользователь не нажал "Принять" или явно не согласился с конкретной категорией
• В политике конфиденциальности есть отдельный раздел про cookie: какие используются, зачем, на какой срок хранятся, кто ещё получает эти данные (например, Яндекс как оператор Метрики)

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

Ошибки, из-за которых баннер не спасает от проверки

Мы видим один и тот же набор проблем почти на каждом втором сайте, который приходит к нам на аудит после того, как клиент "вроде бы уже поставил баннер".

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

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

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

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

Один случай из практики. Клиент из сферы услуг заказал редизайн сайта у подрядчика, который добавил "модный" cookie-баннер - анимированный, с логотипом, красиво вписанный в дизайн. Кнопка была одна: "Согласен, продолжить". При аудите в феврале 2026 года выяснилось, что счётчик Метрики и виджет обратного звонка от стороннего сервиса грузились ещё до появления самого баннера - анимация просто не успевала отрисоваться раньше скриптов в head. Красивый баннер не спас бы от штрафа ни на день: технически согласие спрашивалось уже после того, как данные начали собираться.

Как внедрить технически

Правильная последовательность обратная привычной: сначала логика согласия, потом подключение трекинга, а не наоборот.

Технически задача сводится к трём частям. Первая - определить категории cookie и то, что конкретно в каждую входит: сессионные технические файлы всегда обязательны и не требуют согласия, Яндекс.Метрика и другие счётчики - аналитика, рекламные пиксели и ретаргетинг - реклама. Вторая - сверстать сам баннер с равнозначными кнопками и переключателями категорий, сохранить выбор пользователя в первом собственном (не стороннем) cookie или localStorage, чтобы не показывать баннер повторно при каждом визите. Третья, самая важная с точки зрения соответствия закону - обернуть загрузку скриптов Метрики, рекламных тегов и виджетов в условие: скрипт вставляется в DOM только после того, как в хранилище появился флаг согласия на соответствующую категорию.

На практике это несложный кусок vanilla JS без сторонних CDN-библиотек: одна функция проверяет сохранённое согласие при загрузке страницы, вторая - навешивает обработчики на кнопки баннера и создаёт нужные <script>-теги динамически. Готовые зарубежные CMP-платформы часто хранят согласие на собственных серверах за рубежом, что создаёт отдельный риск по требованию локализации персональных данных из ч. 5 ст. 18 152-ФЗ - поэтому для российского сайта логичнее свой лёгкий скрипт, чем импортный конструктор согласий.

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

Отдельно стоит подумать про срок хранения выбора пользователя. Год - разумный ориентир: дольше держать согласие без повторного запроса рискованно, если за это время менялся набор используемых cookie или подключались новые сервисы. Хорошая практика - фиксировать не только сам факт согласия, но и дату, версию текста баннера и перечень категорий, на которые согласился пользователь. Если через год-два регулятор спросит, на основании чего обрабатывались данные конкретного посетителя, такой лог отвечает на вопрос сразу, а не заставляет разбираться в логах сервера задним числом.

Кому это критичнее всего

Не для всех сайтов риск одинаков. Интернет-магазины и сервисы с ретаргетингом получают по полной: рекламные пиксели Яндекс.Директа, VK Рекламы и партнёрских сетей ставят cookie пачками, и без явного разделения на категории отследить, что именно грузится до согласия, а что после, руками почти невозможно - нужен технический аудит скриптов на странице.

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

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

Штрафы за нарушения с cookie

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

Суммы приведены по состоянию на 2026 год, точные размеры и составы уточняйте на consultant.ru - редакция КоАП периодически меняется. С 28 декабря 2025 года дела по ст. 13.11 КоАП рассматривают мировые судьи, что на практике означает более быстрые сроки разбирательства, чем раньше.

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

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

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