DLP и оборотный штраф: как внедрённая система влияет на правовую позицию

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

Разбираем, что работает.

Почему DLP оказывается в центре

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

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

Три сценария из практики

Мы видели три варианта того, как DLP влияет на позицию оператора.

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

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

Третий - DLP была, но канал утечки не покрывался. Система стояла на почте и USB, а данные ушли через Telegram-бот, который разработала та же внутренняя команда. Аргумент «у нас есть DLP» суд не принял: система не покрывала канал, по которому реально прошла утечка. Это ближе ко второму сценарию из наших февральских наблюдений - «есть антивирус и фаервол», которые ни к чему конкретному не привязаны.

Что нужно зафиксировать документально

Опыт этих дел даёт достаточно конкретный перечень того, что нужно иметь на руках. Не «настроить DLP», а именно задокументировать - потому что суд смотрит на бумагу, а не на интерфейс системы.

• Политика покрытия каналов - документ с явным перечислением: какие каналы контролируются, какие исключены и почему. Если Telegram или личная почта не покрываются - это должно быть осознанным решением с обоснованием, а не просто пробелом.
• Настройки режима работы - блокировка или аудит, для каких категорий данных какой режим. Если аудит - почему не блокировка и кто принимал это решение. Без этого документа режим аудита в суде читается как недонастроенная система.
• Журналы алертов и реакция на них - не просто лог событий, а история обработки: кто получил алерт, когда, что сделал. Если алерты уходят в почту дежурному и там и остаются - это видно и это плохо.
• Акт о покрытии персональных данных - внутренний документ, в котором явно сказано: такие-то категории ПДн, хранящиеся там-то, контролируются DLP-политикой такой-то. Связь между классификацией данных и конфигурацией системы.
• Отчёт об инциденте с данными DLP - если утечка произошла, документ расследования со ссылками на конкретные события в системе: когда, что, кто, куда. Даже если данные ушли - наличие этого документа показывает, что оператор понимал, что произошло, а не узнал из новостей.

Где документация разваливается

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

Когда инцидент происходит и надо собирать позицию - документов нет. DLP-вендор может выгрузить логи, но без контекста «что было настроено и зачем» это просто набор строк. Суд воспринимает такую доказательную базу слабо.

Это не уникальная для DLP история - то же самое было с SIEM и с ролевыми моделями. Технический инструмент работает, но правовую позицию держит только то, что зафиксировано в документах оператора.

Что с этим делать

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

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

Апелляционная практика по этим делам только формируется, и не исключено, что часть выводов скорректируется. Но общее направление - суд ожидает связки «система + документация + реакция» - выглядит устойчиво.