Защита персональных данных: тест на соответствие закону

При утечке компания сталкивается не только со штрафом, но и с расследованием, внеплановыми расходами, остановкой отдельных процессов и потерей доверия клиентов.

Регулирование персональных данных в РФ строится вокруг Федерального закона № 152-ФЗ от 27 июля 2006 года. Но проверка соответствия сегодня не сводится к наличию политики конфиденциальности на сайте. Компания должна понимать, какие данные собирает, на каком основании, где хранит, кто получает к ним доступ и какие действия выполняет при инциденте.

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

Эволюция 152-ФЗ: от базовых требований до оборотных штрафов

Базовая конструкция 152-ФЗ сохраняется: оператор определяет цели обработки, формирует состав данных, выбирает правовые основания и отвечает за безопасность информации. Но регуляторная нагрузка постепенно смещается от формального оформления документов к доказуемому контролю процессов.

Внутри компании должны быть связаны между собой как минимум четыре уровня:

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

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

Федеральный закон № 233-ФЗ от 8 августа 2024 года ввел статью 13.1 в 152-ФЗ. Она регулирует обращение с обезличенными персональными данными и их передачу в государственные информационные системы. Для бизнеса это означает появление дополнительного контура контроля: обезличивание должно быть не декларацией, а процедурой с понятными правилами, целями и ответственными лицами.

Федеральный закон № 420-ФЗ, подписанный 30 ноября 2024 года, внес изменения в КоАП РФ, усиливающие ответственность за нарушения в сфере персональных данных. Его положения вступали в силу поэтапно: отдельные нормы — с момента официального опубликования, другие — в установленные законом сроки. Среди наиболее чувствительных для бизнеса рисков — оборотные штрафы за повторные нарушения и усиленная ответственность за несвоевременное уведомление об утечке. Конкретные сроки действия отдельных положений, в том числе оборотных штрафов, впоследствии уточнялись последующими изменениями в законодательство, поэтому при оценке рисков нужно опираться на действующую редакцию КоАП, а не на исходный текст закона.

Защита персональных данных — это не один продукт и не один документ. Это управляемый процесс, в котором стоимость ошибки выше стоимости регулярного контроля.

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

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

Роль регуляторов: как Роскомнадзор, ФСТЭК и ФСБ контролируют операторов

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

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

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

ФСТЭК оценивает не красоту документа, а систему мер. В зависимости от информационной системы, состава данных, количества субъектов и актуальных угроз определяются уровень защищенности и набор необходимых организационных и технических решений. Приказ ФСТЭК № 21 остается одним из ключевых документов, на который ориентируются при выборе мер защиты.

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

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

Обязательства оператора: от политики конфиденциальности до уведомления об утечках

Проверка соответствия ФЗ-152 начинается не с закупки продукта. Сначала фиксируется карта обработки данных. Без нее невозможно оценить ни риск, ни бюджет, ни реальную отдачу от внедрения.

Компания определила, какие данные обрабатывает

В перечне должны быть не только очевидные категории вроде ФИО, телефона и электронной почты. В него часто попадают:

• данные учетных записей и идентификаторы пользователей;
• сведения о заказах, платежах и доставке;
• кадровая информация;
• записи звонков и обращения в службу поддержки;
• IP-адреса, cookie-файлы и технические журналы;
• биометрические или специальные категории данных, если они используются;
• данные представителей клиентов и контактных лиц в B2B-сегменте.

Для каждого типа данных нужно понимать цель обработки, срок хранения, основание, место размещения и набор сотрудников, которым доступна информация. Если эти параметры неизвестны, оценка уровня защищенности персональных данных будет формальной.

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

Полезно вести карту не только по приложениям, но и по жизненному циклу данных. Один и тот же номер телефона может попасть на сайт, затем в CRM, сервис рассылок, систему аналитики, контакт-центр и резервную копию. Если проверять только CRM, половина маршрута останется невидимой.

Определено правовое основание обработки

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

Поэтому формы на сайте нельзя строить по принципу «поставим одну галочку на все случаи». Для маркетинговой рассылки, оформления заказа, кадрового учета и передачи данных подрядчику могут действовать разные основания и цели. Смешивание этих целей затрудняет отзыв согласия и повышает риск претензий.

Рабочая форма согласия должна быть связана с конкретным сценарием. Если компания меняет CRM, подключает новый сервис аналитики или передает поддержку внешнему подрядчику, юридическую модель обработки нужно пересмотреть. Иначе технологическая интеграция опережает правовую.

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

Политика конфиденциальности совпадает с фактическими процессами

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

В ней должны отражаться:

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

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

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

Компания уведомила Роскомнадзор, если такая обязанность применяется

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

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

Важно контролировать не только сам факт подачи уведомления, но и внутреннего владельца этих сведений. В быстрорастущей компании маркетинг подключает новые сервисы, HR меняет кадровую платформу, а ИТ переносит базы в облако. Если ни один процесс не требует согласовать такие изменения с ответственным за ПДн, уведомление быстро перестает быть актуальным.

Отдельный сценарий — утечка. За неуведомление или нарушение сроков предусмотрены существенные штрафы, которые в отдельных случаях достигают от 1 до 3 млн рублей. Конкретная сумма зависит от обстоятельств нарушения, состава данных, повторности и других факторов. Для руководства это означает, что план реагирования должен быть подготовлен до инцидента, а не в момент, когда уже требуется формировать сообщение регулятору.

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

Уровень защищенности определен на основании анализа инфраструктуры

Уровень защищенности персональных данных нельзя назначить «по размеру компании». Он зависит от информационной системы и актуальных угроз.

При оценке обычно рассматриваются:

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

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

SLA в данном случае — не маркетинговая формулировка. Если сервис недоступен, данные потеряны или компания не может получить журнал действий администратора, это влияет на непрерывность бизнеса и расследование инцидента.

Подрядчики включены в контур контроля

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

До начала работы нужно определить:

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

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

Новые правила обращения с обезличенными данными и интеграция с ГИС

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

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

После принятия Федерального закона № 233-ФЗ вопросы обезличенных персональных данных получили отдельное законодательное регулирование. В частности, статья 13.1 касается обращения с такими данными и их передачи в государственные информационные системы.

Внутренний регламент обезличивания должен отвечать на несколько прикладных вопросов:

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

Слабое место многих проектов — псевдонимизация, которую называют обезличиванием. Замена ФИО на идентификатор не всегда исключает возможность определить человека, особенно если в наборе остаются телефон, адрес, точная дата события или уникальная комбинация характеристик.

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

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

Техническая защита: где чаще всего появляется вендор-лок

ИТ-департамент может предложить набор отдельных средств: антивирус, межсетевой экран, VPN, DLP, систему управления доступом, резервное копирование и SIEM. Каждый компонент решает свою задачу. Но набор лицензий сам по себе не формирует экосистему защиты.

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

Перед закупкой следует оценить не только функции продукта, но и полную стоимость владения:

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

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

Минимальный технический контур

Состав мер зависит от конкретной системы, но для первичной оценки можно использовать следующий ориентир:

1. Идентификация и управление доступом.

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

2. Многофакторная аутентификация.

Для администраторов, удаленного доступа, облачных консолей и критичных корпоративных систем одного пароля недостаточно. Особенно уязвимы учетные записи, которые дают доступ к резервным копиям и каталогам с клиентскими данными.

3. Шифрование и защищенная передача.

Шифрование должно применяться с учетом сценария: при передаче, хранении и резервном копировании. Необходимо заранее определить, кто управляет ключами и как восстанавливается доступ при сбое.

4. Журналирование.

Система должна фиксировать входы, изменения прав, выгрузки, удаление и массовое копирование данных. Логи, которые не просматриваются и не защищены от изменения, имеют ограниченную практическую ценность.

5. Резервное копирование и восстановление.

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

6. Защита рабочих станций и почты.

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

7. Контроль внешних каналов.

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

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

Как проверить защиту персональных данных без имитации аудита

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

Проверку удобно проводить по пяти потокам.

Документы и ответственность

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

Затем проверяются документы:

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

У каждого документа должна быть связь с реальным процессом. Если регламент требует ежеквартального пересмотра прав, но никто не может показать результаты такой проверки, документ существует только на бумаге.

Доступы и учетные записи

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

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

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

Сроки хранения и удаление

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

Проверка должна ответить на вопросы:

1. Для чего еще нужны эти данные?

2. Есть ли установленный срок хранения?

3. Кто принимает решение об удалении?

4. Удаляются ли копии из тестовых и резервных контуров?

5. Можно ли подтвердить факт удаления?

6. Что происходит с данными после окончания договора с подрядчиком?

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

Инциденты и уведомления

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

Для каждого сценария должны быть понятны:

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

Нельзя ограничиваться фразой «ИТ-служба проведет расследование». ИТ может остановить доступ и собрать технические сведения, но решение о юридической квалификации, уведомлении и коммуникации с субъектами требует участия других функций.

Подрядчики и облачные сервисы

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

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

Финансовые риски и ответственность за нарушение законодательства

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

Оборотная модель ответственности делает особенно опасными повторные и системные нарушения. Если компания однажды получила предписание, но не изменила процесс, следующая проверка будет оценивать не наличие новых документов, а устранение причины. Формальное закрытие замечания без изменения архитектуры доступа лишь переносит проблему.

Отдельно нужно учитывать стоимость ошибок в цепочке подрядчиков. Оператор может не контролировать внутреннюю инфраструктуру поставщика, но именно ему придется объяснять, какие данные были переданы, на каком основании и как отбирался исполнитель. Договорная оговорка о соблюдении законодательства не заменяет проверки фактических мер защиты.

Финансовую оценку полезно проводить по нескольким сценариям:

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

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

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

Что должно измениться после проверки

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

Приоритет обычно определяется сочетанием трех факторов:

• насколько чувствительны данные;
• насколько широк доступ к ним;
• насколько быстро можно использовать уязвимость.

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

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

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

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