Чтобы не строить догадки, лучше посмотреть на то, что уже произошло. Судебные прецеденты по 152-ФЗ и постановления регуляторов, это документально зафиксированные причины и следствия реальных утечек. Здесь нет теорий, только практика, по которой можно свериться.
Что на самом деле пишут в итоговых отчётах ФСТЭК и Роскомнадзора
Большинство публикаций об утечках данных ограничиваются сообщением «произошла утечка N записей». Ключевая информация — причина инцидента и последствия для оператора — остаётся за рамками. Однако документы по итогам проверок ФСТЭК и решения Роскомнадзора по фактам нарушений 152-ФЗ дают чёткую картину.
Типичные нарушения, ведущие к реальным утечкам, редко связаны со сложными кибератаками. Чаще это следствие накопленных уязвимостей в процессах. ФСТЭК в своих актах указывает не на конкретную брешь, а на системное несоблюдение требований. Например, отсутствие модели угроз и актуального паспорта системы, невыполнение порядка обновлений, недостаточный контроль доступа. Это создаёт среду, где утечка становится лишь вопросом времени.
Роскомнадзор, в свою очередь, оценивает соответствие действий оператора требованиям закона после факта утечки. Выносятся решения о назначении штрафов. Из решений видно, что даже при наличии технических средств защиты, нарушения в документации и процессах трактуются как прямое несоблюдение закона.
Примеры решений судов: какие штрафы и почему
Судебная практика по 152-ФЗ и КоАП показывает, какие аргументы принимаются, а какие — нет.
- Несоблюдение сроков уведомления. Оператор обнаружил утечку, но уведомил Роскомнадзор с задержкой в несколько дней, ссылаясь на внутреннее расследование. Суд назначил штраф, не приняв оправданием необходимость выяснения обстоятельств. Закон чётко устанавливает трёхдневный срок.
- Ненадлежащая защита персональных данных. Утечка произошла через публичный веб-интерфейс, не защищённый паролем. Оператор утверждал, что данные были техническими и не позволяли идентифицировать субъекта. Экспертиза и суд установили, что в совокупности с другими данными с сайта идентификация была возможна, и назначили штраф за неприменение необходимых мер защиты.
- Отсутствие согласия субъекта. Компания обрабатывала данные для рассылки, не получив явного согласия. В суде оператор не смог представить доказательств получения такого согласия. Штраф был назначен, несмотря на относительно небольшой объём данных.
Важный паттерн: попытки сослаться на незначительность объёма утекших данных или на отсутствие доказанного причинения вреда субъектам обычно не принимаются судами в качестве смягчающих обстоятельств при нарушении процедурных требований закона.
Общие проблемы, которые встречаются снова и снова
Некорректная классификация информационных систем
Операторы часто занижают уровень защищённости ИСПДн (например, присваивают УЗ-3 вместо УЗ-2), чтобы избежать затратных организационных мер. При проверке после инцидента ФСТЭК переклассифицирует систему, и все предыдущие меры защиты признаются несоответствующими. Это влечёт за собой штрафы не только за утечку, но и за длительное несоблюдение требований.
Формальный подход к организационной документации
Модель угроз, политика безопасности, приказы — документы есть, но они созданы по шаблону и не учитывают специфику конкретной компании и её инфраструктуры. В судебном разбирательстве такая документация легко признаётся фиктивной, если эксперт установит, что реальные процессы ей не соответствуют.
Передача данных субподрядчикам
Утечка происходит у облачного провайдера или сервисной компании. Оператор-заказчик полагает, что ответственность лежит на исполнителе. Однако Роскомнадзор и суд возлагают ответственность на оператора, который не обеспечил надлежащий договорной режим и контроль за обработкой данных у субподрядчика. Сам договор оказания услуг не снимает ответственности.
Как использовать эту информацию для построения защиты
Анализ прецедентов, это не история для общего развития, а инструмент для построения обоснованной и эффективной системы защиты.
- Провести аудит на соответствие типичным проблемам. Используйте перечень нарушений из актов ФСТЭК как чек-лист для внутренней проверки. Сосредоточьтесь не только на технике, но и на процессах: актуальность модели угроз, наличие доказательств получения согласий, порядок работы с инцидентами.
- Пересмотреть отношения с субподрядчиками. Убедитесь, что договоры на обработку ПДн содержат все обязательные условия, предусмотренные 152-ФЗ, и механизмы контроля их исполнения. Рассмотрите возможность проведения аудита безопасности субподрядчика.
- Готовить доказательную базу заранее. В случае спора нужно будет доказать, что все разумные меры были приняты. Система журналирования, акты обновлений, подписанные политики, записи о проведении инструктажей — всё это становится критически важным.
- Разработать реалистичный план реагирования на инциденты. В плане должен быть прописан не только технический ответ, но и юридические шаги: кто и в какие сроки уведомляет регулятора, как взаимодействовать с субъектами данных. Трёхдневный срок на уведомление начинает отсчёт с момента обнаружения, а не с момента завершения внутреннего расследования.
Стратегия, построенная на анализе чужих ошибок, позволяет сместить фокус с формального закрытия требований на управление реальными рисками. Цель — не просто пройти проверку, а создать среду, где инцидент либо не случится, либо его последствия будут предсказуемо и профессионально устранены.