Ранним утром, в приёмную падает уведомление: плановая проверка Роскомнадзора через десять рабочих дней. CISO вызывает DPO, тот открывает каталог с документацией - реестр обработки ПДн актуализировался в прошлом году, согласия на обработку для нового мобильного приложения не оформлены, договор с облачным провайдером подписан без поручения на обработку. За десять дней нужно закрыть дыру, которая копилась полтора года.
Ситуация до боли знакомая. По моим наблюдениям, в семи из десяти организаций внутренний аудит персональных данных либо не проводился вообще, либо проводился для галочки - без привязки к реальным бизнес-процессам. Ниже - рабочий чеклист из 12 пунктов, detection-правила для мониторинга ИСПДн в SIEM и план подготовки к визиту инспектора.
Что инспектор РКН запрашивает в первые 30 минут проверки
Проверка оператора персональных данных начинается не с серверной и не с SIEM-консоли. Инспектор Роскомнадзора работает по типовому плану, и первые полчаса - чисто документарная часть. Вот что запрашивают практически в каждой плановой проверке, в порядке приоритета:- Уведомление в реестре операторов. Инспектор открывает pd.rkn.gov.ru и сверяет данные: зарегистрирован ли оператор, актуальны ли цели обработки, перечислены ли все категории ПДн и субъектов. Расхождение между реестром и действительностью - первое замечание в акте. Обязанность уведомить регулятора закреплена в ст. 22 ФЗ-152, исключения (обработка исключительно для трудовых отношений, для пропусков) трактуются узко.
- Приказ о назначении ответственного за организацию обработки ПДн. Не "ответственного за ИБ" вообще, а конкретного лица по ст. 22.1 ФЗ-152. Нет приказа - нарушение фиксируется мгновенно.
- Политика обработки персональных данных. Документ должен висеть на сайте и быть доступен без авторизации. Инспектор проверяет содержание: цели, правовые основания, категории субъектов, сроки хранения, порядок уничтожения. Формальная "болванка" с общими фразами - самостоятельный повод для замечания.
- Согласия субъектов. Проверяются конкретные экземпляры: бумажные формы или электронные логи. Инспектор запрашивает 5–10 случайных согласий и сверяет с фактическим объёмом обрабатываемых данных. В согласии указан один набор полей, а CRM хранит расширенный - нарушение.
- Поручения на обработку ПДн. Облачный провайдер, колл-центр на аутсорсе, HR-платформа - каждый требует отдельного поручения с описанием целей, объёма, мер защиты и обязанности уничтожить данные по завершении.
Чеклист ФЗ-152: пошаговый внутренний аудит персональных данных
12 пунктов ниже можно включить в отчёт или передать ответственному за обработку ПДн как есть. Каждый привязан к конкретной норме.
Инвентаризация ИСПДн и картирование потоков данных
Перед тем как лезть в документы, зафиксируйте, что именно вы защищаете. Это стартовая точка аудита соответствия ФЗ-152 - и здесь чаще всего вскрывается разрыв между задекларированными целями обработки и тем, что происходит на самом деле.Пункт 1. Составить или актуализировать реестр ИСПДн. Перечислить все информационные системы, в которых обрабатываются персональные данные: CRM, ERP, HR-платформа, сайт с формами сбора, мобильное приложение, 1С:ЗУП, почтовый сервер с резюме кандидатов. Для каждой ИСПДн зафиксировать: категории субъектов (сотрудники, клиенты, контрагенты), категории ПДн (ФИО, паспортные данные, биометрия, специальные категории), объём записей (до 100 000 субъектов или более), тип актуальных угроз (1, 2 или 3 по ПП-1119). Этот шаг напрямую маппится на ID.AM-01 (NIST CSF v2.0) - инвентаризация активов, обрабатывающих данные.
Пункт 2. Определить уровень защищённости (УЗ) для каждой ИСПДн. Классификация - по Постановлению Правительства №1119 на основании категории данных, объёма и типа угроз. Результат - УЗ от 1 до 4, и от него зависит набор обязательных технических мер по Приказу ФСТЭК №21.
Типичная ошибка, которую я встречаю раз за разом: классификация проведена один раз при запуске системы, а с тех пор добавились новые поля (ИНН, данные о здоровье) - уровень защищённости никто не пересмотрел. Класс СрЗИ должен соответствовать УЗ: для УЗ2 - не ниже 5-го класса защиты, для УЗ1 - не ниже 4-го (Приказ ФСТЭК №76).
Пункт 3. Построить карту потоков ПДн. Откуда данные поступают (веб-форма, бумажная анкета, API партнёра), где хранятся, куда передаются (подрядчику, в облако, за рубеж), когда уничтожаются. По сути - Data Flow Map из практики GDPR. По данным GDPR.eu, картирование потоков стоит первым пунктом их compliance checklist. Без этой карты невозможно проверить, все ли передачи покрыты поручениями на обработку.
Проверка документации оператора персональных данных
Пункт 4. Уведомление в реестр РКН. Зайти на pd.rkn.gov.ru, найти свою организацию, сверить: все ли цели обработки перечислены, совпадают ли категории субъектов и ПДн с реестром ИСПДн из пункта 1. Расхождения есть - подать корректирующее уведомление до проверки.Пункт 5. Политика обработки ПДн на сайте. Проверить, что документ опубликован без авторизации и содержит все реквизиты по ст. 18.1 ФЗ-152: цели обработки, правовые основания, перечень действий с ПДн, сроки, порядок реагирования на запросы субъектов. Главное - чтобы текст описывал сегодняшний бизнес, а не тот, что был при первоначальном оформлении.
Пункт 6. Согласие на обработку персональных данных. Для каждой ИСПДн определить правовое основание: согласие, договор, нормативный акт. Где основание - согласие, проверить: форму (содержит ли обязательные реквизиты по ст. 9 ФЗ-152), механизм фиксации факта получения (лог, скан, электронная подпись), возможность отзыва. По данным Self-Assessment Checklist ирландской DPC, механизм получения consent - один из самых проблемных элементов: согласие должно быть «свободным, конкретным, информированным и однозначным». Формулировка практически идентична требованиям ст. 9 ФЗ-152.
Пункт 7. Поручения на обработку. Для каждого подрядчика с доступом к ПДн - договор поручения или соответствующий раздел в основном договоре по ч. 3 ст. 6 ФЗ-152. Проверить: цели обработки, перечень действий, обязанность обеспечить конфиденциальность, обязанность уничтожить данные по завершении.
Пункт 8. Локальные акты. Приказ о назначении ответственного по ст. 22.1, перечень лиц с допуском к ПДн, журнал учёта обращений субъектов, регламент реагирования на инциденты, акты уничтожения ПДн.
Оценка соответствия технических мер защиты ПДн
Пункт 9. Меры по Приказу ФСТЭК №21. Для УЗ3 и УЗ4 (большинство коммерческих организаций) базовый набор: идентификация и аутентификация (PR.AA-01 по NIST CSF), управление доступом, регистрация событий безопасности, антивирусная защита, контроль целостности. Для УЗ1 и УЗ2 добавляются защита среды виртуализации и обнаружение вторжений.Пункт 10. Сертифицированные СрЗИ. Для государственных ИС - обязательно. Для коммерческих - ФСТЭК допускает «оценку соответствия в любой форме», но на практике проверяющие ожидают сертификат или письменное обоснование, почему его нет. По документам - можно обойтись, на практике - лучше иметь.
Пункт 11. Процедура реагирования на инциденты. Оператор обязан уведомить Роскомнадзор об утечке в течение 24 часов и предоставить результаты расследования в течение 72 часов. Проверить: есть ли playbook, назначен ли ответственный за уведомление, протестирован ли процесс хотя бы на tabletop exercise. Маппинг на RS.AN-01 (NIST CSF): уведомления от систем обнаружения расследуются.
Пункт 12. Реагирование на обращения субъектов. Субъект вправе запросить информацию об обработке своих ПДн, потребовать уточнения, блокирования или уничтожения. Срок ответа - 10 рабочих дней. Проверить: форма приёма обращений, журнал учёта, соблюдение сроков. Для сравнения: GDPR-аналог (DSAR) по данным Vanta обязывает организации отвечать в течение месяца. Российский закон жёстче.
Нарушения ФЗ-152 и штрафы: финансовый контекст для CISO
До 2024 года штрафы по ст. 13.11 КоАП были смешными - десятки тысяч рублей за эпизод. Ситуация изменилась с введением оборотных штрафов за утечки персональных данных. Для повторных нарушений при масштабных утечках санкции привязаны к проценту от годовой выручки, верхняя планка - сотни миллионов рублей.
Для CISO аудит защиты персональных данных - процесс с прямым финансовым импактом. Одна неучтённая ИСПДн, одно отсутствующее поручение, один необновлённый реестр - при проверке каждый пробел фиксируется как отдельное нарушение с отдельным штрафом. Оборотные штрафы применимы именно к утечкам, а нарушения порядка обработки (отсутствие согласий, неуведомление РКН) караются по фиксированной шкале. Но десятки эпизодов складываются в сумму, которую финдиректор уже не проигнорирует.
Отдельный вектор - уголовный: ст. 137 УК РФ (нарушение неприкосновенности частной жизни) и ст. 272 УК РФ (неправомерный доступ к компьютерной информации) применимы, если утечка произошла из-за умышленных действий или грубой халатности сотрудника.
Мониторинг обработки ПДн в SIEM: detection для соответствия требованиям ФЗ-152
Приказ ФСТЭК №21 требует регистрации событий безопасности для ИСПДн всех уровней защищённости. На практике это значит, что SIEM (MaxPatrol SIEM, KUMA, ELK или другой стек) должен покрывать системы с персональными данными, а правила корреляции - учитывать специфику обращений с ПДн.Базовые алерты для ИСПДн
Массовый экспорт записей. Пользователь за одну сессию выгружает более N записей из таблиц с ПДн - алерт. Порог N определяется baseline (DE.AE-01 по NIST CSF): для HR-системы на 500 сотрудников запрос на 50+ записей за 5 минут - это аномалия, а не работа.
YAML:
title: Mass PD Export Detection
logsource:
category: database
product: postgresql
detection:
selection:
query_type: "SELECT"
table_name|contains:
- "employees"
- "customers"
- "personal_data"
rows_returned|gte: 50
timeframe: 5m
condition: selection
level: highДоступ из нетипичного источника. Обращение к базе ПДн с IP-адреса или от сервисного аккаунта, не входящего в baseline - алерт. Покрывает сценарий компрометации легитимного хоста и инсайдера с чужими учётными данными.
Изменение прав доступа к ИСПДн. Любое изменение ACL, добавление пользователя в группу с доступом к ПДн-таблицам, создание сервисного аккаунта с правами чтения - отдельный алерт. Корреляция: если изменение произошло за пределами change window или без тикета в ITSM - severity повышается.
Серия неуспешных попыток доступа. Более 5 failed login к ИСПДн за 10 минут от одного источника - индикатор bruteforce или misconfiguration. В обоих случаях - повод для расследования. При инциденте с ПДн эти логи становятся доказательной базой для уведомления РКН в рамках 72-часового дедлайна.
Подготовка к проверке Роскомнадзора: план действий на 30 дней
Дни 26–30: финальная ревизия. Все документы подписаны, датированы, размещены. Реестр ИСПДн, акты классификации и модель угроз не содержат дат «из прошлой жизни». Документация отражает сегодняшнее состояние, а не то, что было три года назад.
Оценку соответствия закону о персональных данных стоит проводить минимум раз в год. Запустили новый продукт, сменили подрядчика, провели реорганизацию - повторная оценка обязательна, иначе реестр устаревает за квартал.
Я провёл внутренние аудиты в нескольких десятках организаций - от банков до маркетплейсов. Главный вывод, который формулирую каждому CISO: проблема не в ФЗ-152 как таковом, а в том, что compliance-процесс живёт отдельно от реального IT-хозяйства. Реестр ИСПДн утверждён приказом трёхлетней давности, а за это время запущены три сервиса, прошла миграция в другое облако и сменилась HR-платформа. Документы не врут - они описывают организацию, которой больше не существует.
Единственный способ это починить - встроить проверку соответствия ФЗ-152 в change management: любое изменение в обработке ПДн триггерит обновление реестра, пересмотр УЗ и проверку поручений. Пока этого нет, каждый аудит будет авральным, а каждая проверка РКН - лотереей. На codeby.net коллеги обсуждают практику внутренних аудитов ПДн и готовят чеклисты под конкретные отрасли - если строите свой процесс, есть смысл сверить подход.
Последнее редактирование модератором:
