Закон о защите данных: пошаговый план для ИТ-компаний

Первый промпт «найди персональные данные» вернул предсказуемую галлюцинацию: модель заметила email и телефоны, но пропустила IP-адреса в логах, историю платежных попыток, идентификаторы устройств и файлы, которые пользователи прикладывают в тикеты.

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

С 30 мая 2025 года эта ошибка перестала быть просто неудобством для юриста или службы безопасности. Новые нормы КоАП, введённые Федеральным законом № 420-ФЗ, кратно повысили цену утечки. Для ИТ-компаний, которые обрабатывают данные пользователей, сотрудников, лидов и клиентов, 152-ФЗ теперь требует не папки документов на корпоративном диске, а воспроизводимого процесса: знать, где находятся данные, кто к ним имеет доступ, как обнаруживается инцидент и кто нажимает кнопку уведомления Роскомнадзора в первые 24 часа.

Новая экономика утечек: почему SaaS-компаниям нельзя жить «на доверии»

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

Даже у небольшого B2B-сервиса быстро появляется сложный набор данных:

• ФИО, корпоративные и личные email, номера телефонов;
• IP-адреса, идентификаторы сессий, сведения об устройствах и события авторизации;
• данные сотрудников клиентов, заведённые в рабочее пространство SaaS;
• резюме кандидатов, данные работников и подрядчиков;
• записи звонков, переписка в тикетах, вложения к обращениям;
• сведения, поступающие из CRM, рекламных кабинетов и аналитических платформ;
• резервные копии, где удалённая из продакшена запись может продолжать существовать неделями.

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

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

Это особенно чувствительно для SaaS-бизнеса. Компания может не считать себя «большой», но обслуживать десятки тысяч сотрудников клиентов. В одном инциденте окажутся не только собственные лиды, а весь пользовательский массив в нескольких корпоративных тенантах.

Утечка в SaaS — это редко один скомпрометированный email. Чаще это ошибка границы доступа, которая масштабируется на всех клиентов сразу.

Отдельная ловушка — данные, которые команда не считает персональными, потому что они кажутся техническими. В логах, аналитике и системах поддержки персональная информация часто лежит в смешанном виде: идентификатор пользователя рядом с IP, email, пользовательским действием, географией, историей входов. Для инцидента не имеет значения, что поле назвали metadata и спрятали в JSON.

Первые 24 часа: как собрать регламент уведомления Роскомнадзора

После обнаружения утечки у оператора есть 24 часа на предварительное уведомление Роскомнадзора. На результаты внутреннего расследования отведено 72 часа. Нарушение этих сроков само по себе грозит штрафом от 1 до 3 млн рублей.

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

Рабочий регламент должен быть коротким, доступным круглосуточно и проверенным на учебном сценарии. Не на красивой презентации, а в реальной имитации: например, команда обнаруживает публичный объект в облачном хранилище или выгрузку клиентской базы в открытом репозитории.

Минимальный сценарий реагирования

1. Зафиксировать момент обнаружения.

Не время, когда инцидент окончательно подтвердил CISO, а момент, когда сотрудник или система впервые выявили подозрительную активность. Запишите источник сигнала, затронутую систему, аккаунт, временной диапазон и первичную оценку.

2. Остановить распространение, не уничтожив следы.

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

3. Определить состав данных и круг субъектов.

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

4. Поднять цепочку принятия решения.

В ней должны быть не только ИБ-специалисты. Обычно нужны владелец продукта или системы, юрист по персональным данным, ответственный за организацию обработки ПДн, руководитель ИТ и коммуникационный контур. Их роли назначают до инцидента, а не в чате «Срочно!!!».

5. Направить предварительное уведомление в пределах 24 часов.

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

6. Завершить внутреннее расследование и передать результаты в срок до 72 часов.

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

Как не провалить уведомление из-за организационной мелочи

В тестах инцидент-реагирования чаще всего ломаются на банальных параметрах:

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

Я бы добавил в календарь хотя бы одну тренировку в квартал. Не ради отчёта. За 45–60 минут команда должна пройти путь от сигнала до черновика уведомления, не собирая телефоны коллег по памяти.

Инвентаризация: сначала данные, потом «соответствие 152-ФЗ»

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

Первый артефакт, который стоит собрать ИТ-компании, — реестр обработки персональных данных. Его удобно вести в таблице, GRC-системе или внутренней базе знаний. Главное — не формат, а полнота и поддерживаемость.

На этом шаге ИИ действительно экономит время, если не поручать ему юридическое решение. Модель можно использовать для первичного разбора схем БД, документации API, экспортов из IAM и описаний интеграций. Но результат надо проверять человеком: нейросеть хорошо группирует поля и ищет паттерны, однако способна уверенно перепутать технический идентификатор с обезличенным и не увидеть данные внутри произвольного текстового поля.

Рабочий промпт для такой задачи должен содержать параметры, а не магические слова вроде «проверь на 152-ФЗ»:

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

Уровни защищённости — не декоративная маркировка УЗ-1, УЗ-2, УЗ-3, УЗ-4

После инвентаризации нужно определить уровень защищённости информационных систем персональных данных. Постановление Правительства № 1119 устанавливает четыре уровня: от УЗ-1 до УЗ-4. Выбор нельзя делать по принципу «мы небольшой стартап, поставим УЗ-4».

Уровень связан с категориями обрабатываемых данных, количеством субъектов и типом актуальных угроз. Поэтому классификацию проводят по конкретным ИСПДн, а не по бренду компании целиком. У кадровой системы, публичного сайта, облачной платформы и внутренней CRM может быть разный профиль обработки и разная модель угроз.

Практическая ошибка здесь выглядит так: команда защищает основную продуктовую БД, но не включает в границы ИСПДн сервис поддержки или систему аналитики. В результате доступы, логи, интеграционные токены и резервное копирование остаются за периметром модели угроз — то есть именно там, где потом появляется инцидент.

Локализация, доступы и облака: технический слой без самообмана

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

Нужно разложить маршрут данных по этапам:

1. Пользователь вводит данные в веб-форме или приложении.

2. API принимает и записывает их в основную базу.

3. События уходят в логи, мониторинг и продуктовую аналитику.

4. Контакты и заявки синхронизируются с CRM или сервисом рассылок.

5. Вложения попадают в объектное хранилище.

6. Бэкапы и реплики получают отдельные политики хранения.

7. Саппорт выгружает фрагменты данных в тикеты и внутренние чаты.

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

Техническая защита не начинается и не заканчивается шифрованием. Шифрование снижает риск компрометации, но не исправляет публичный доступ, чрезмерные роли или токен, который годами лежит в CI-переменных без ротации.

В базовом контуре я бы проверял следующие параметры:

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

Комплаенс ломается не там, где нет политики. Он ломается там, где старый токен даёт доступ к бэкапу, а никто не знает, кому этот токен принадлежит.

Инвестиции в ИБ и оборотный штраф: условия, которые нельзя собрать задним числом

Закон предусматривает возможность снизить оборотный штраф за повторную утечку до 0,1 от минимального размера, но не менее 15 млн рублей. Это не автоматическая скидка и не аргумент «мы купили антивирус после инцидента».

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

• компания ежегодно инвестировала в информационную безопасность не менее 0,1% выручки в течение последних трёх лет;
• ежегодно проводилась оценка соответствия требованиям 152-ФЗ с привлечением лицензиата ФСТЭК;
• отсутствуют отягчающие обстоятельства, в том числе сокрытие инцидента.

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

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

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

Документы должны отражать реальную систему, а не существовать рядом с ней

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

Обычно ИТ-компании нужен как минимум такой набор:

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

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

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

С чего начать, если сейчас есть только политика на сайте

Не пытайтесь за неделю «закрыть 152-ФЗ». Такой рывок обычно производит много PDF-файлов и ни одного работающего контроля. Лучше провести несколько последовательных итераций.

Сначала выберите один наиболее критичный продуктовый контур: личный кабинет, основную базу пользователей, CRM или HR-систему. Соберите реестр данных, назначьте владельцев систем, проверьте маршруты в облака и внешние сервисы. Затем протестируйте один сценарий утечки с лимитами 24 и 72 часа. После этого станет видно, какие документы, доступы, логи и договоры существуют только в воображении команды.

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

Закон о защите данных в 2025 году — это уже не отдельная задача юриста и не «страховка от проверки». Для ИТ-компании он встроен в архитектуру продукта: в схему БД, IAM, бэкапы, логи, API, подрядчиков и скорость реакции команды. Граница здесь простая: либо вы можете за часы показать, какие данные были затронуты и что сделали для остановки инцидента, либо эта картину за вас будет восстанавливать регулятор — по последствиям утечки.