DLP vs контроль «поверхности ПДн»: что выбрать и как закрыть разрыв между ИБ и комплаенсом

Почему одной системы предотвращения утечек больше не достаточно — и что делать компаниям в эпоху оборотных штрафов

Почему тема стала срочной

Российские компании оказались в непростой ситуации. С одной стороны, Роскомнадзор в 2024 году выявил 135 утечек, в которых содержалось более 710 млн записей о гражданах [3]. С другой — с 30 мая 2025 года за нарушение правил обработки персональных данных общей категории можно получить штраф до 500 млн рублей, а за специальную категорию предусмотрено лишение свободы на срок до пяти лет [4].

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

Именно здесь и формируется «разрыв» — между тем, что делает ИБ-служба (предотвращает утечки через каналы), и тем, что требует комплаенс (знать, где данные есть, обосновать их обработку, иметь актуальный реестр).

Статья адресована директорам по ИБ, DPO, руководителям ИТ и всем, кто отвечает за соответствие требованиям 152-ФЗ в условиях динамичного ИТ-ландшафта. Материал будет полезен как крупным корпорациям, так и среднему бизнесу, которому предстоит впервые выстроить системный подход к управлению ПДн.

Часть 1. Что такое DLP и почему её «маловато»

Архитектура и сильные стороны DLP

DLP (Data Loss Prevention) — класс решений, предназначенных для контроля и предотвращения несанкционированной передачи конфиденциальной информации. DLP-системы обеспечивают контроль за такими данными, как коммерческая тайна, интеллектуальная собственность, персональные данные клиентов; они отслеживают все попытки передачи защищаемой информации через электронную почту, мессенджеры, облачные хранилища и другие каналы [5].

Технически DLP-системы работают по нескольким принципам:

Контентный анализ — система исследует содержимое документов, сообщений и файлов на наличие конфиденциальной информации, используя поиск по ключевым словам, регулярным выражениям и шаблонам (например, форматы СНИЛС, ИНН, номера паспорта). Для распознавания персональных данных DLP-системы используют определители структуры данных: почти у каждого типа ПДн есть свой формат [6].

Цифровые отпечатки (Digital Fingerprinting) — система создаёт цифровой слепок с эталонного конфиденциального документа и распознаёт его фрагменты даже в изменённом виде.

Контекстный анализ — анализируется не только содержимое, но и метаданные: кто отправил, куда, в какое время, с какого устройства.

В России DLP-системы имеют и правовую основу. Использование DLP-систем в России законно: статья 214.2 Трудового кодекса РФ разрешает их применение, а ФСТЭК — Федеральная служба по техническому и экспортному контролю — определяет разрешение на их использование [7].

Крупнейшие российские DLP-решения: InfoWatch Traffic Monitor, СёрчИнформ КИБ, Solar Dozor, Falcongaze SecureTower, Кибер Протего (бывший DeviceLock DLP), Гарда DLP. По оценке ГК «Солар», сегмент защиты данных, в который входит DLP, составляет 10% от всего продуктового рынка ИБ, или около 21 млрд рублей [8].

Что DLP не умеет — критика и ограничения

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

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

Второе: DLP не отслеживает права доступа. Кто имеет право читать папку с данными клиентов? Кто фактически её читает? DLP не отслеживает права доступа к важной информации, в отличие от DCAP-систем [9].

Третье: масштаб и архитектура DLP ограничены рабочими станциями. Архитектура большинства DLP-систем не адаптирована под массивы данных, счёт которых идёт на десятки-сотни терабайт, — она ограничивается сканированием рабочих станций [9].

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

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

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

Часть 2. Что такое «поверхность ПДн» и почему её нужно контролировать

Понятие поверхности атаки применительно к данным

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

В типичной крупной компании эта поверхность огромна и постоянно меняется: реляционные базы данных (Oracle, PostgreSQL, MS SQL), файловые хранилища (NAS, SharePoint, S3), почтовые серверы с историей переписки, ERP-системы (1С, SAP), CRM (Bitrix24, AmoCRM), Active Directory и LDAP, системы документооборота, API и интеграционные шины, тестовые окружения с копиями продуктивных данных, ноутбуки и мобильные устройства сотрудников.

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

Почему инвентаризация ПДн — не разовое мероприятие

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

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

Именно поэтому контроль «поверхности ПДн» должен быть непрерывным процессом, а не периодическим событием. По аналогии с тем, как периметр сети контролируется непрерывно, так и «периметр данных» должен мониториться в режиме реального времени.

Часть 3. DCAP — недостающее звено между DLP и комплаенсом

Что такое DCAP и как он появился

DCAP (Data-Centric Audit and Protection) — класс решений, сфокусированных на защите самих данных, а не периметра сети или каналов передачи. По Gartner, DCAP-системы должны решать три основные задачи: поиск и классификацию данных; аудит файловых операций и прав доступа к ним; контентное разграничение доступов к файлам [11].

Термин был введён Gartner в 2017 году. Российские разработчики стали массово предлагать свои DCAP-продукты с 2019 года [12]. На российском рынке сегодня представлены: СёрчИнформ FileAuditor, Makves DCAP, Zecurion DCAP, InfoWatch Data Discovery, Solar DAG, «Спектр DCAP» от Innostage.

Важный факт: за последние 5 лет в РФ рынок систем контроля и управления доступом к неструктурированным данными (DCAP/DAG) вырос в 18 раз [13]. Это отражает реальный спрос: компании осознали, что без понимания того, где лежат данные, невозможно выстроить ни эффективную ИБ, ни корректный комплаенс.

Ключевые отличия DCAP от DLP

Если попытаться провести чёткую границу, она проходит по объекту контроля. DLP контролирует движение (Data in Motion) — то, что передаётся. DCAP контролирует хранение (Data at Rest) — то, что лежит. Цель DLP — предотвращение утечек информации, что подразумевает активное реагирование на действия пользователей при отправке конфиденциальной информации по почте или записи на флешку. DCAP работает иначе: система сканирует файловые хранилища и классифицирует содержимое [9].

DCAP видит то, что DLP не видит: где именно хранятся ПДн (конкретные директории, таблицы, поля), кто имеет к ним доступ (не обязательно злоупотребляя этим), какие данные избыточны или хранятся без законного основания, как изменялся состав данных с течением времени.

DLP видит то, что DCAP не видит: попытки передачи данных по каналам (email, USB, мессенджеры), конкретные действия конкретного сотрудника в момент нарушения, перехваченное содержимое для расследования инцидента.

Отсюда ключевой вывод, который признают и ИБ-практики, и вендоры: по мере роста компании DCAP можно объединить с DLP в функциональную связку, где первая система обеспечивает безопасность «покоящихся» данных, а вторая — «движущихся» [11].

Часть 4. Разрыв между ИБ и комплаенсом: анатомия проблемы

Почему ИБ и комплаенс говорят на разных языках

В типичной крупной организации отдел ИБ и DPO/юридический отдел решают разные задачи, используют разные метрики и, часто, разные инструменты.

Отдел ИБ думает категориями: заблокированных инцидентов, алертов, уязвимостей, векторов атак. Его метрики — количество срабатываний DLP, время реакции на инцидент, процент покрытия конечных точек агентами.

DPO/комплаенс думает категориями: реестра операторов, правовых оснований обработки, согласий, сроков хранения, уведомлений Роскомнадзора. Его метрики — число несоответствий требованиям, готовность к проверке, актуальность документации.

На стыке этих двух логик и возникает разрыв. DPO спрашивает: «Где у нас хранятся ПДн клиентов из CRM?» — ИБ-служба не может ответить. ИБ настраивает политику DLP на «не передавать ИНН» — но не знает, насколько полно она покрывает все источники ИНН в инфраструктуре.

Три типовых сценария, где разрыв становится проблемой

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

Сценарий второй — появление нового сервиса. Команда разработки запустила новую функцию в мобильном приложении, которая собирает геолокацию. Никто не уведомил DPO и ИБ своевременно. Данные начали собираться и обрабатываться без включения в реестр и без необходимых правовых оснований. DLP это не видит — данные не «утекают», они просто обрабатываются неправомерно.

Сценарий третий — инцидент и расследование. Произошла утечка. Роскомнадзор требует уведомление в течение 24 часов и отчёт о внутреннем расследовании в течение 72 часов (требования ст. 21 152-ФЗ). DLP зафиксировала инцидент, но не может сказать, из какой именно системы ушли данные, сколько субъектов затронуто и было ли правовое основание для обработки. Ответить регулятору корректно и быстро невозможно.

Регуляторный контекст: что требует 152-ФЗ в части «знания данных»

152-ФЗ, Приказ ФСТЭК №21 и Постановление Правительства №1119 формируют набор требований, которые по сути описывают именно контроль «поверхности ПДн». Статья 18.1 152-ФЗ обязывает оператора вести актуальный перечень мест хранения ПДн. Статья 22 обязывает уведомлять Роскомнадзор об изменениях в обработке. Статья 21 устанавливает обязанность выявлять и устранять нарушения в обработке ПДн. Статья 19 требует технических мер, включающих «установление правил доступа к персональным данным в информационной системе» [14].

На практике операторы используют: описание архитектуры, перечень ПО с версиями, результаты обследования, инвентаризацию интеграций, данные об уязвимостях и отчётность тестов на проникновение [15]. Но всё это — разрозненные артефакты, которые устаревают сразу после составления.

Часть 5. Новый регуляторный контекст: оборотные штрафы и их последствия

Что изменилось с 30 мая 2025 года

С конца мая 2025 года в России вступили в силу изменения в правовом регулировании обработки персональных данных. Поправки, внесённые Федеральным законом №420-ФЗ от 30 ноября 2024 года в КоАП РФ, ужесточили последствия утечек ПДн [16].

Ключевые изменения: для юрлиц предусмотрен штраф от 150 тыс. до 300 тыс. рублей за первичное нарушение; при неоднократных утечках предусмотрены оборотные штрафы — фиксированный процент от выручки [17]. Максимальный штраф за нарушение правил обработки персональных данных общей категории достигает 500 млн рублей [4].

Параллельно, Федеральный закон №421-ФЗ ввёл уголовную ответственность за утечки персональных данных для физических лиц [18].

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

Смягчающие обстоятельства — как они связаны с «картой ПДн»

Законодательство предусматривает возможность снижения оборотного штрафа при наличии ряда условий. Одно из ключевых условий — наличие документально подтверждённого комплекса мер по защите ПДн. Оборотные штрафы предусматривают возможность снижения их размера при наличии ряда условий [19].

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

Часть 6. Как выстроить контроль «поверхности ПДн»: практический подход

Шаг 1. Провести первоначальное обнаружение («Data Discovery»)

Первый шаг — понять, где в инфраструктуре реально находятся ПДн. Это не ручное анкетирование владельцев систем (оно даёт лишь то, что люди помнят), а автоматическое сканирование всех возможных источников: реляционных БД, файловых хранилищ, почтовых серверов, CRM, 1С, Active Directory.

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

Шаг 2. Классифицировать и атрибутировать данные

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

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

Шаг 3. Настроить политики DLP на основе реальной карты

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

Шаг 4. Выстроить непрерывный мониторинг изменений

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

Шаг 5. Закрыть документальный комплаенс

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

Часть 7. Типичные ошибки и как их избежать

Ошибка первая: считать, что DLP = полная защита ПДн. DLP — необходимый, но недостаточный элемент. Она не заменяет инвентаризацию, не даёт «карту данных» и не закрывает вопросы комплаенса. При защите персональных данных самые мощные аналитические инструменты DLP-систем — контентный анализ и «цифровые отпечатки» — недостаточно эффективны [6].

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

Ошибка третья: хранить «карту ПДн» только в голове или в Excel-таблице без автоматического обновления. Актуальность такой карты быстро падает до нуля.

Ошибка четвёртая: разделять ИБ и комплаенс как «два разных мира». Это создаёт организационные разрывы, которые и становятся главным источником риска.

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

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

Часть 8. Примеры и практика рынка

Как DCAP уже применяется в России

Использование DCAP-системы для поиска персональных данных на файловых серверах компании стало первым опытом эксплуатации СЗИ в ряде инфраструктур; это позволило снизить стратегические риски для бизнеса [20]. На практике DCAP-системы сейчас активно применяются в финансовом секторе, здравоохранении и госсекторе — отраслях с наиболее строгими требованиями к обработке ПДн.

В 2024 году по результатам опроса аудитории AM Live о подходах к защите неструктурированных данных: 30% предпочитают DLP-системы, 21% полагается на встроенные функции ОС и других ИТ-систем, 13% отдают предпочтение DCAP-системам [21]. Цифры показывают, что рынок ещё находится в процессе осознания необходимости DCAP.

Тренды рынка: движение к связке DLP + Discovery

Ведущие российские вендоры DLP уже выпускают DCAP-компоненты или встраивают функции обнаружения данных в свои продукты: InfoWatch выпустил InfoWatch Data Discovery, Zecurion — Zecurion DCAP, ГК «Солар» — Solar DAG. Это подтверждает тезис о конвергенции двух классов решений.

В 2025 году концепция «периметр защищён — данные в безопасности» окончательно умерла; конфиденциальные данные теперь повсюду: в облаках, в мессенджерах, в руках подрядчиков [20].

Часть 9. Будущее: куда движется контроль ПДн

Privacy by Design как стандарт

В мировой практике всё активнее распространяется принцип Privacy by Design — встраивание требований по защите ПДн в архитектуру систем изначально, а не «по факту» нарушения. В контексте контроля данных это означает, что новые ИТ-системы проектируются так, чтобы их воздействие на «поверхность ПДн» было автоматически видно и управляемо.

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

Автоматизация и AI в управлении данными

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

Рынок ИБ в России прогнозируется к росту до 681 млрд рублей, или 14% от общего объёма ИТ-рынка, к 2030 году, со среднегодовыми темпами роста около 15% [22]. Защита данных и управление ПДн — один из наиболее быстрорастущих сегментов.

Чек-лист для CISO и DPO

Ниже — практический чек-лист для организаций, которые хотят закрыть разрыв между ИБ и комплаенсом в части ПДн:

• Провести автоматическое сканирование всей инфраструктуры для обнаружения ПДн (включая БД, файловые хранилища, почту, 1С, CRM, API).
• Построить актуальную «карту ПДн»: где, какие данные, кто владелец, какое правовое основание.
• Настроить непрерывный мониторинг изменений — новые поля, новые источники, новые интеграции.
• Связать техническую карту с реестром ИСПДн и документацией 152-ФЗ.
• Настроить DLP-политики на основе реальной карты, а не общих шаблонов.
• Выстроить процесс уведомления Роскомнадзора: знать, из какой системы ушли данные и сколько субъектов затронуто — в течение 24 часов.
• Проверить, что инструменты для обнаружения ПДн не хранят сырые значения и не создают дополнительных рисков.
• Провести ревизию прав доступа к данным — особенно у подрядчиков и привилегированных пользователей.

«Пятый фактор»: платформа для непрерывного контроля поверхности ПДн

Описанный выше разрыв — именно та проблема, которую решает «Пятый фактор». Это on-prem платформа для автоматического обнаружения, инвентаризации и контроля персональных данных в корпоративных системах: базах данных, файловых хранилищах, почте, AD/LDAP, CRM, 1С, API.

Ключевое отличие платформы — принцип «privacy-by-design»: система работает только с метаданными, структурой и агрегатами, без передачи и хранения «сырых» значений ПДн. Это означает, что «Пятый фактор» не становится источником дополнительного риска — он не создаёт новую «поверхность» с реальными данными.

Что даёт платформа на практике:

• Живую «карту ПДн» — где и какие данные есть, кто владелец, что изменилось с момента последней проверки.
• Раннее обнаружение новых рисков — новые поля, новые интеграции, новые источники, пока они не превратились в инцидент.
• Непрерывный контроль вместо периодических ручных аудитов — время аудита сокращается, готовность к проверкам регулятора повышается.
• Понятный комплаенс-статус — нарушения, владельцы, статусы согласований в едином интерфейсе.

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

Подробнее: https://5factor.ru

Источники

[1] Роскомнадзор — статистика утечек персональных данных, 2024 — https://rkn.gov.ru

[2] Обзор DLP-систем, SecurityMedia — статистика Роскомнадзора и штрафов — https://securitymedia.org/analytics/obzor-rossiyskikh-dlp-sistem.html

[3] F.A.C.C.T. — статистика утечек первое полугодие 2024 — https://spectrumdata.ru/blog/proverka-soiskatelya/dlp-sistemy-chto-eto-takoe-i-kak-oni-rabotayut/

[4] Штрафы за персональные данные с 30 мая 2025 — https://www.rnk.ru/article/217361-shtrafy-za-personalnue-dannye

[5] ИНФАРС — роль DLP-систем в защите данных — https://infars.ru/blog/rol-dlp-sistem-v-borbe-s-utechkami-dannykh/

[6] ITSEC.ru — DLP: маловато будет — https://www.itsec.ru/articles/dlp-malovato-budet-zashchita-personalnyh-dannyh-na-protyazhenii-vsego-zhiznennogo-cikla

[7] GENDALF — DLP и 152-ФЗ — https://gendalf.ru/news/all/kak-dlpsistemy-predotvrashchayut-utechki/

[8] Comply.ru — «Большой брат» или инструмент: что такое DLP — https://comply.ru/tpost/byyzhym501-bolshoi-brat-ili-instrument-predotvrasch

[9] Cyberpeak — DCAP-системы: всё внимание на данные — https://cyberpeak.ru/strong-dcap-sistemy-vsjo-vnimanie-na-dannye-strong/

[10] Positive Technologies — Российский рынок ИБ: итоги 2024 и прогнозы на 2025 — https://ptsecurity.com/ru-ru/research/analytics/rossijskij-rynok-ib-i-ego-rol-v-mirovoj-industrii-itogi-2024-goda-i-prognozy-na-2025/

[11] Anti-Malware.ru — DCAP как самостоятельный продукт — https://www.anti-malware.ru/analytics/Technology_Analysis/Data-Centric-Audit-and-Protection-FileAuditor

[12] TAdviser — DCAP Data-Centric Audit and Protection — https://www.tadviser.ru/index.php/Статья:DCAP_Data-Centric_Audit_and_Protection

[13] Anti-Malware.ru — DCAP/DAG: обзор систем управления доступом к неструктурированным данным — https://www.anti-malware.ru/analytics/Technology_Analysis/DCAP-DAG-systems

[14] КонсультантПлюс — Федеральный закон от 27.07.2006 N 152-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_61801/

[15] b-152.ru — Как определить уровень защищённости персональных данных — https://b-152.ru/kak-opredelit-uroven-zashchishchennosti-personalnyh-dannyh

[16] RTM Group — Изменения в законе о персональных данных с 2025 года — https://rtmtech.ru/articles/novye-shtrafy-za-utechki-pdn/

[17] КонсультантПлюс — С 30 мая 2025 значительно ужесточена ответственность за нарушения в области персональных данных — https://www.consultant.ru/document/cons_doc_LAW_490308/

[18] Центр нормативного регулирования — Ужесточение ответственности за нарушение 152-ФЗ — https://sec.ussc.ru/152fz

[19] data-sec.ru — Штрафы за персональные данные в 2026 году — https://data-sec.ru/personal-data/fines/

[20] Habr / Innostage — Не DLP единым: как DCAP закрывает слепую зону — https://habr.com/ru/companies/innostage/articles/1003920/

[21] Anti-Malware.ru AM Live — Как защитить неструктурированные данные и выбрать DCAP в 2024 — https://www.anti-malware.ru/analytics/Technology_Analysis/How-to-choose-DCAP-system-in-2024-AMLive

[22] Б1 — Российский рынок информационной безопасности 2025 — https://b1.ru/insights/news/media-center/b1-russian-information-security-market-survey-press-release-19-march-2025/

[23] SecurityVision — DCAP Data-Centric Audit and Protection — https://www.securityvision.ru/blog/data-centric-audit-and-protection-dcap/

[24] Anti-Malware.ru — Как выбрать DCAP-систему — https://www.anti-malware.ru/practice/methods/How-to-choose-DCAP

[25] ITSEC.ru — Защита персональных данных в 2026 году — https://www.itsec.ru/news/personal-data-protection-in-2026-how-to-ensure-compliance-with-the-law