ФЗ-152 — закон, который большинство IT-директоров считают «юридической формальностью». До первого штрафа. В конце 2025 года крупный ретейлер из топ-20 получил оборотный штраф в 47 млн рублей за утечку клиентской базы из внутренней CRM-системы. Причина — разработчики не заложили шифрование персональных данных at rest. Система прошла функциональное тестирование, но compliance-требования «отложили на потом».

Знакомая ситуация? Поскольку штрафы за нарушения ФЗ-152 выросли в 10 раз с 2024 года, «потом» стало слишком дорогим. Для компании с оборотом от 1 млрд рублей оборотный штраф в 1% — это минимум 10 млн рублей. При повторном нарушении — до 5% оборота.

В этой статье разбираем, что конкретно изменилось в ФЗ-152 для IT-разработки в 2025–2026 году, какие требования обязательны на уровне архитектуры и как подготовиться к проверке Роскомнадзора — не постфактум, а на этапе проектирования системы. Материал для CIO и CDO, которые не хотят объяснять совету директоров, почему запуск продукта заблокирован.

Что изменилось в ФЗ-152 для IT-разработки в 2025–2026

До 2024 года штрафы за нарушения ФЗ-152 были, мягко говоря, символическими. Компания могла заплатить 60–300 тысяч рублей за утечку миллионов записей. С ноября 2024 года ситуация изменилась кардинально: Федеральный закон N 420-ФЗ ввёл оборотные штрафы, привязанные к выручке компании.

Вот что это означает на практике:

Нарушение До 2024 С 2025

Утечка данных (первичная) 60–300 тыс. руб. 1–3% оборота (до 500 млн руб.)

Повторное нарушение до 500 тыс. руб. до 5% оборота (до 500 млн руб.)

Нет уведомления об инциденте до 100 тыс. руб. до 3 млн руб.

Обработка без согласия до 75 тыс. руб. до 700 тыс. руб. (должностные лица)

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

Для IT-директора крупной компании это меняет приоритеты: compliance перестаёт быть задачей юристов. Следовательно, это задача архитектуры.

Почему ФЗ-152 — это задача архитектуры, а не юристов

Вот наша позиция, основанная на опыте десятков корпоративных проектов: compliance нельзя «прикрутить» к готовому продукту. Его нужно закладывать в архитектуру с первого спринта. Звучит очевидно, но на практике 80% проектов, которые приходят к нам на аудит, имеют одну и ту же проблему: сначала написали код, потом вспомнили про ФЗ-152.

Что происходит в таком случае? Рефакторинг data layer, переделка модели хранения, добавление consent management, перестройка логирования. По нашим оценкам, стоимость «приделывания» compliance к готовому продукту составляет 30–60% от бюджета основной разработки. А иногда — и все 100%, когда архитектура не предусматривала разделение персональных и неперсональных данных.

В отличие от этого подхода, Security by Design обходится в 5–8 раз дешевле. Причина проста: когда требования ФЗ-152 — это часть технического задания, разработчики закладывают правильную архитектуру с самого начала. Нет рефакторинга, нет переделок, нет «сюрпризов» на этапе аудита.

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

Чек-лист: 8 требований ФЗ-152 к IT-системе

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

Требование ФЗ-152 Техническая реализация Этап

1 Локализация данных в РФ Серверы в российском ЦОД, geo-routing для CDN Архитектура

2 Получение согласия Consent management module + audit log Проектирование

3 Минимизация данных Data model review: обоснование каждого поля с ПДн Проектирование

4 Шифрование at rest AES-256 или ГОСТ 34.12-2018 для БД и бэкапов Разработка

5 Шифрование in transit TLS 1.3, mTLS для микросервисов Разработка

6 Логирование доступа Immutable audit log + SIEM-интеграция Разработка

7 Уведомление об инциденте Мониторинг 24/7, алертинг, incident response plan Инфраструктура

8 Право на удаление Soft/hard delete с audit trail и подтверждением Разработка

Обратите внимание: 5 из 8 пунктов закладываются на этапах архитектуры и проектирования. Именно поэтому compliance — это не задача последнего спринта. Если ваш подрядчик обещает «добавить ФЗ-152 потом» — это первый тревожный сигнал.

Подробнее о полном цикле безопасной разработки ПО — в нашем развёрнутом руководстве.

Как внедрить ФЗ-152 в процесс разработки: 5 шагов

Окей, а что делать на практике? Ниже — пошаговый план, который мы используем в корпоративных проектах.

Шаг 1. Data mapping до начала разработки

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

Шаг 2. Privacy by Design в архитектуре

Заложите разделение персональных и неперсональных данных на уровне базы данных. Спроектируйте consent management как отдельный модуль. Определите политики retention — сколько данных хранить и когда удалять.

Шаг 3. Шифрование как инфраструктурное требование

TLS 1.3 для всех соединений, AES-256 для данных at rest, secrets management через HashiCorp Vault или аналог. Ключи шифрования — отдельно от данных. Это не «дополнительная функция», а базовая инфраструктура.

Шаг 4. Мониторинг и incident response

Настройте structured logging для всех операций с персональными данными. Интегрируйте с корпоративным SIEM. Напишите incident response plan: кто звонит в Роскомнадзор, в какой срок, по какому шаблону. Помните: 24 часа на уведомление.

Шаг 5. SSDLC и автоматические проверки

Встройте проверки безопасности в CI/CD: SAST для анализа кода, SCA для проверки зависимостей, pre-commit hooks для обнаружения секретов в коде. Таким образом, каждый коммит автоматически проверяется на соответствие требованиям безопасности.

При разработке корпоративного MVP все 5 шагов можно реализовать за 22 рабочих дня, если заложить их в план с первого дня. Проблемы начинаются, когда compliance пытаются добавить к уже написанному коду.

Когда ФЗ-152 не так страшен, как кажется

Справедливости ради, не каждый IT-проект требует полного набора мер. Вот что важно учитывать:

• Внутренние системы без ПДн. Если система не обрабатывает персональные данные (например, аналитический дашборд на агрегированных данных), требования ФЗ-152 к ней не применяются напрямую. Тем не менее корпоративные стандарты безопасности всё равно нужно соблюдать.
• Обезличенные данные. Данные, которые невозможно связать с конкретным человеком без дополнительной информации, не считаются персональными. Правильная анонимизация может значительно упростить compliance.
• Согласие — не единственное основание. ФЗ-152 предусматривает несколько оснований для обработки: исполнение договора, законные интересы оператора, требования закона. Не всё требует отдельного согласия пользователя.

Однако если ваша система обрабатывает ФИО, телефоны, email, адреса или любые другие данные, позволяющие идентифицировать человека, — полный набор мер обязателен. Это относится к 90% корпоративных IT-продуктов: CRM, HR-системы, клиентские порталы, внутренние сервисы с аутентификацией.

Как подготовиться к проверке Роскомнадзора

Проверки Роскомнадзора бывают плановыми и внеплановыми. С 2025 года количество внеплановых проверок значительно выросло — регулятор реагирует на жалобы субъектов данных и сообщения об утечках. Вот что нужно подготовить:

• Уведомление Роскомнадзора. Оператор персональных данных обязан уведомить регулятора до начала обработки. Проверьте, что ваша компания в реестре операторов.
• Политика обработки ПДн. Документ должен быть опубликован на сайте и доступен пользователям.
• Согласия на обработку. Должны быть получены, зафиксированы в системе и доступны для предъявления.
• Техническая документация. Описание мер защиты: шифрование, контроль доступа, логирование, резервное копирование.
• Журнал инцидентов. Если были утечки или попытки несанкционированного доступа — должны быть задокументированы с описанием принятых мер.

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

FAQ о ФЗ-152 в IT-разработке

Какие штрафы за нарушение ФЗ-152 в 2026 году?

С 2025 года действуют оборотные штрафы: от 1% до 3% годовой выручки за утечку (максимум 500 млн рублей), до 5% при повторном нарушении. Для компании с оборотом 1 млрд рублей минимальный штраф за утечку — 10 млн рублей. Кроме того, до 3 млн рублей за несвоевременное уведомление Роскомнадзора об инциденте.

Можно ли добавить соответствие ФЗ-152 к уже готовому продукту?

Технически — да, но стоимость доработок составит 30–60% от бюджета основной разработки. В отдельных случаях, когда архитектура не предусматривала разделение данных, дешевле переписать систему с нуля. Поэтому мы всегда закладываем compliance на этапе проектирования — это обходится в 5–8 раз дешевле.

Распространяется ли ФЗ-152 на внутренние корпоративные системы?

Да, если система обрабатывает персональные данные сотрудников, клиентов или контрагентов. HR-система с ФИО и паспортными данными, CRM с контактами клиентов, внутренний портал с аутентификацией — всё это подпадает под ФЗ-152. Исключение — системы, работающие только с обезличенными или агрегированными данными.

За сколько дней можно привести IT-систему в соответствие ФЗ-152?

Если закладывать compliance с первого дня разработки, дополнительного времени не требуется — требования встраиваются в стандартный цикл. В пакете ITESCO соответствие ФЗ-152 включено в 22 рабочих дня разработки MVP. Если нужно доработать существующую систему, сроки зависят от масштаба: от 2 недель для точечных доработок до 3–6 месяцев для полного рефакторинга.

Нужно ли привлекать юристов для IT-части compliance?

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

Итого

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

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

Если вы планируете запуск корпоративного IT-проекта и хотите заложить соответствие ФЗ-152 с первого дня — запишитесь на 30-минутную Zoom-консультацию. Разберём ваши требования к compliance, оценим объём работ и покажем, как это реализуется в стандартном пакете разработки.