ФЗ-152 в разработке: что встроить с первого дня

Фз-152 в разработке — тема, которая определяет успех IT-проекта. В марте 2024 года небольшой FinTech стартап получил предписание Роскомнадзора. Приложению было три месяца. Пользователей — около 800 человек.

Нарушение: персональные данные хранились на серверах в Германии. Не потому что основатели хотели нарушить закон. Просто разработчики привычно задеплоили на AWS eu-west, никто не задал вопрос о compliance, а «посмотрим потом» стало «платим сейчас». Вопрос фз-152 в разработке заслуживает детального анализа.

Миграция инфраструктуры заняла три недели. Приложение работало в деградированном режиме. Несколько корпоративных клиентов отказались от сотрудничества — именно потому что увидели предписание в публичном реестре РКН.

ФЗ-152 — это не сложно. Это 8 конкретных вещей, которые нужно встроить в приложение с первого дня разработки. Вот они.

Кого касается ФЗ-152 — коротко

Рассмотрим, как фз-152 в разработке работает на практике.

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

Если ваше приложение просит пользователя ввести имя и телефон при регистрации — вы оператор персональных данных. ФЗ-152 распространяется на вас с первого пользователя.

Для FinTech к ФЗ-152 добавляется 115-ФЗ (KYC/AML) и требования ЦБ. Но начнём с основы.

8 технических требований ФЗ-152 — с деталями реализации

Вопрос фз-152 в разработке заслуживает детального анализа.

1. Согласие на обработку персональных данных

Что требует закон: обрабатывать персональные данные только с согласия пользователя. Согласие должно быть конкретным, информированным и добровольным.

Как реализовать:

• Чекбокс при регистрации с текстом «Согласен на обработку персональных данных» + ссылка на Политику
• Чекбокс не должен быть заранее отмечен (pre-checked — нарушение)
• Хранить в базе данных: user_id, timestamp согласия, версия Политики, IP-адрес
• Логировать: дата, время, текст согласия, на которое дал разрешение пользователь

Архитектурный паттерн: таблица consent_log с полями: user_id, consent_type, consented_at, policy_version, ip_address, revoked_at (NULL если не отозвано).

2. Политика конфиденциальности

Что требует закон: оператор обязан опубликовать документ о политике обработки персональных данных в открытом доступе.

Как реализовать:

• Отдельная страница на сайте и в приложении (/privacy-policy/)
• Доступна без авторизации
• Содержит: кто оператор, какие данные собираются, цели обработки, сроки хранения, права субъекта, контакты для запросов
• При изменении Политики — уведомить пользователей и запросить повторное согласие

Минимальный объём для FinTech — 2–3 страницы. Не нужно копировать 20-страничный документ с юридическим языком — главное, чтобы пользователь реально мог понять, что происходит с его данными.

3. Хранение персональных данных на серверах в РФ

Что требует закон: первичная запись, систематизация, накопление и хранение персональных данных граждан РФ должны осуществляться с использованием баз данных, расположенных на территории РФ (ст. 18.1 152-ФЗ).

Как реализовать:

• Yandex Cloud — российский ЦОД, сертификация ФСТЭК, подходит для персональных данных 1–4 уровней защищённости
• Selectel — российский ЦОД, также сертифицирован ФСТЭК
• VK Cloud — ещё один вариант с российской юрисдикцией

Нельзя: AWS, Google Cloud, Azure как основное хранилище персональных данных. Можно использовать для CDN (изображения, статика), но не для БД с ПДн.

Важный нюанс: для трансграничной передачи данных (например, KYC-провайдер с серверами за рубежом) нужно отдельное основание — согласие субъекта или договор с третьей страной. С 2024 года штраф за нарушение — до 18 млн ₽. При правильном подходе фз-152 в разработке становится конкурентным преимуществом.

4. Шифрование персональных данных

Что требует закон: обеспечение защиты ПДн от несанкционированного доступа. Технические меры защиты — ответственность оператора.

Как реализовать:

• В базе данных: шифрование чувствительных полей (ФИО, паспортные данные, финансовая информация) с помощью pgcrypto (PostgreSQL) или аналогичных средств. Алгоритм — AES-256.
• В транзите: TLS 1.2+ для всех соединений API. TLS 1.0 и 1.1 — устарели и небезопасны.
• Пароли: хранить только bcrypt-хеш с salt, никогда plaintext или MD5.
• Токены и ключи: хранить в переменных окружения (секретах), не в коде репозитория.

Шифрование — это не просто compliance. Это защита пользователей в случае утечки. Если злоумышленник получит зашифрованные данные без ключей — они бесполезны.

5. Аудит-лог операций с персональными данными

Что требует закон: оператор должен обеспечить возможность отчёта о своих действиях с ПДн — в случае проверки или запроса субъекта.

Как реализовать:

• Таблица audit_log: action_type (read/update/delete), entity_type, entity_id, user_id (кто сделал), admin_id (если действие администратора), timestamp, ip_address
• Логировать: доступ к карточке пользователя, изменение данных, выгрузку отчётов с ПДн, удаление записей
• Срок хранения лога — минимум 3 года
• Доступ к логу — только выделенная роль (compliance-офицер, системный администратор)

Аудит-лог нужен не только для регулятора. При инциденте безопасности именно по нему восстанавливают картину произошедшего.

6. Права субъекта: удаление, исправление, доступ к своим данным

Что требует закон: субъект ПДн имеет право на доступ к своим данным, их исправление и удаление (право на «забвение»). Оператор обязан ответить на запрос в течение 30 дней.

Как реализовать:

• Доступ к данным: раздел «Мои данные» в личном кабинете — пользователь видит, какие ПДн хранятся
• Исправление: форма редактирования профиля с логированием изменений
• Удаление: кнопка «Удалить аккаунт» → мягкое удаление (soft delete) с анонимизацией ПДн; через 30 дней — физическое удаление. Транзакционная история может храниться в анонимизированном виде для финансовой отчётности.
• Отзыв согласия: пользователь может отозвать согласие на обработку — это останавливает обработку ПДн и инициирует удаление

Для FinTech важный нюанс: удаление данных не всегда возможно сразу — финансовые операции должны храниться по требованию 115-ФЗ. Аккаунт удаляется, транзакционные записи анонимизируются.

7. Уведомление Роскомнадзора (регистрация оператора ПДн)

Что требует закон: перед началом обработки персональных данных оператор обязан уведомить Роскомнадзор (есть исключения — ст. 22 152-ФЗ).

Как реализовать:

• Подать уведомление через портал РКН: pd.rkn.gov.ru — процедура бесплатная, занимает около 30 минут
• В уведомлении: наименование организации, цели обработки, перечень ПДн, категории субъектов, меры защиты
• После подачи — организация вносится в реестр операторов ПДн (публичный)
• При изменении состава обрабатываемых данных — подавать обновлённое уведомление

Исключение из обязанности уведомлять: если ПДн обрабатываются только для исполнения договора с субъектом и не передаются третьим лицам. Для большинства FinTech-продуктов с KYC и аналитикой это исключение не применяется.

8. Retention policy — сроки хранения и удаление по истечении

Что требует закон: ПДн хранятся не дольше, чем требуется для достижения целей обработки. По истечении срока — уничтожение или обезличивание.

Как реализовать:

• Определить сроки для каждой категории данных: активные пользователи, удалённые аккаунты, транзакционная история, лог событий
• Типичный retention для FinTech: активные ПДн — бессрочно (пока аккаунт активен); удалённые аккаунты — 30 дней до физического удаления; транзакции (анонимизированные) — 5 лет по требованию 115-ФЗ; аудит-логи — 3 года
• Автоматизированные задачи (cron) для очистки устаревших данных
• Документирование политики хранения — входит в Политику конфиденциальности

Штрафы по ФЗ-152 в 2025 году

Именно фз-152 в разработке определяет результат для бизнеса.

Штрафы выросли в 2024–2025 годах. Раньше максимальный штраф составлял 75 000 ₽ — символическую сумму, которую многие игнорировали. Теперь иначе.

Для стартапа с оборотом 10 млн ₽ штраф в 3% — это 300 000 ₽. Плюс репутационный ущерб: предписания РКН публичны, корпоративные клиенты их проверяют.

Как ФЗ-152 усложняется в FinTech

При правильном подходе фз-152 в разработке становится конкурентным преимуществом.

Если ваш продукт собирает финансовые данные, добавляется несколько дополнительных уровней требований.

Специальные категории ПДн. Биометрия (фото документа, селфи для KYC) — специальная категория, требует дополнительных мер защиты и отдельного согласия.

115-ФЗ (KYC/AML). Сбор и хранение документов, удостоверяющих личность. Срок хранения — 5 лет после прекращения отношений с клиентом. Отчётность в Росфинмониторинг при подозрительных операциях.

Трансграничная передача. KYC-провайдеры (Sumsub, IDX) могут обрабатывать данные за рубежом. Для этого нужно: основание (согласие субъекта или договор), уведомление РКН о трансграничной передаче, проверка страны назначения.

PCI DSS. Если приложение принимает карточные платежи — ещё один стандарт безопасности. Большинство FinTech MVP решают это через платёжный шлюз (ЮKassa, Тинькофф): шлюз берёт на себя PCI DSS, вы не храните данные карт. Далее — о ключевых аспектах фз-152 в разработке.

О полном compliance-аудите для FinTech стартапа — в нашем разделе «Compliance FinTech», где разбираем 115-ФЗ, KYC/AML и требования ЦБ.

Чек-лист: ФЗ-152 в вашем MVP

Далее — о ключевых аспектах фз-152 в разработке.

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

Юридические требования:

• Политика конфиденциальности опубликована и доступна без авторизации
• Форма согласия на обработку ПДн с незаранее отмеченным чекбоксом
• Подано уведомление в Роскомнадзор (pd.rkn.gov.ru)
• Определены сроки хранения для каждой категории данных (retention policy)
• Прописан порядок ответа на запросы субъектов (30 дней)

Технические требования:

• База данных с ПДн размещена на серверах в РФ (Yandex Cloud / Selectel)
• Чувствительные поля зашифрованы (AES-256, pgcrypto)
• Все API-соединения только по TLS 1.2+
• Пароли хранятся в bcrypt-хеше
• Реализована таблица consent_log с timestamp и версией Политики
• Реализован audit_log операций с ПДн
• Реализован механизм soft delete + анонимизации
• Реализован раздел «Мои данные» с возможностью запроса на удаление
• Настроен автоматический cron для очистки устаревших данных
• Логи хранятся минимум 3 года

Для FinTech (дополнительно):

• Отдельное согласие на обработку биометрии (если есть KYC с фото)
• Уведомление РКН о трансграничной передаче данных (если KYC-провайдер зарубежный)
• Срок хранения KYC-документов — 5 лет по 115-ФЗ
• Карточные данные пользователей не хранятся на ваших серверах (платёжный шлюз)

Главный принцип: compliance встраивается, а не добавляется

Опыт показывает: фз-152 в разработке требует системного подхода.

Встроить ФЗ-152 в архитектуру на старте — это 3–5 дней работы в рамках обычного MVP. Переделать готовое приложение под ФЗ-152 — это 3–6 недель, остановка продукта и потенциально потерянные клиенты. Опыт показывает: фз-152 в разработке требует системного подхода.

Разница не только в деньгах. Compliance-риски в FinTech — это буквально риск потерять B2B-партнёров и инвесторов. Корпоративный клиент перед подписанием договора проверяет публичный реестр РКН. Инвестор в процессе due diligence смотрит на security-архитектуру.

Подход IT2BE: безопасность и compliance закладываются в архитектуру в первый день Discovery-сессии, а не добавляются «потом». Все 8 пунктов выше — часть стандартной разработки FinTech MVP в IT2BE.

Если хотите проверить, все ли compliance-требования учтены в вашем проекте — расскажите о нём через форму на сайте. Разберём на Discovery за один день.