Скриншоты, демо‑стенды и обучающие материалы: как не светить реальные ПДн в презентациях и тикетах

Когда привычные рабочие инструменты становятся каналом утечки персональных данных

Невидимые утечки повседневной работы

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

Эти ситуации не воспринимаются как нарушение. Люди делают свою работу: готовят демо, объясняют баг, создают обучающие материалы. Именно поэтому они особенно опасны — нет осознания проблемы, нет процессов защиты, нет контроля.

Между тем российское законодательство не делает исключений для «учебных» или «вспомогательных» контекстов. Оператор несёт полную ответственность за каждую копию персональных данных вне зависимости от того, где она хранится и зачем была создана [5]. А наказание за нарушения с 2025 года стало существенно жёстче.

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

Масштаб проблемы: цифры, которые стоит знать

Утечки в России растут, и не только из баз данных

По данным аналитиков F6 (Threat Intelligence), в 2025 году в открытый доступ попало в полтора раза больше персональных данных россиян, чем годом ранее: публичный объём строк с конфиденциальной информацией вырос с 457 млн в 2024 году до 767 млн [6]. Роскомнадзор за первое полугодие 2025 года выявил 35 фактов утечек, содержащих более 39 млн записей [7].

При этом исследование Positive Technologies показывает, что персональные данные составили 31% от всех похищенных данных у организаций в первом полугодии 2024 года [8]. Важно понимать: значительная доля этих утечек происходит не через взлом основной БД, а через периферийные хранилища — тестовые среды, документацию, задачи в трекерах.

Непроизводственные среды — главная слепая зона

Исследование Perforce/Delphix (2025 State of Data Compliance and Security Report) зафиксировало: 60% организаций столкнулись с инцидентами, связанными с данными именно в непроизводственных средах (dev, QA, staging, обучение) за последний год [3]. При этом 100% опрошенных компаний имеют персональные данные в таких средах. Другими словами, почти каждая организация хранит ПДн там, где защита заведомо слабее.

Типичная крупная компания поддерживает от 5 до 10 копий производственных данных в разных тестовых и аналитических средах [9]. Каждая копия — это дополнительная поверхность атаки и дополнительный объект регуляторного риска.

Тикеты и совместные инструменты: «тихое» накопление данных

Исследование Nightfall AI, охватившее 5 000 Jira-инстансов, обнаружило: в 273 из них задачи были публично доступны. При этом ПДн, учётные данные и конфиденциальная информация попадают в тикеты не из злого умысла, а как часть обычного рабочего процесса [2]:

1. Специалист поддержки вставляет email клиента в задачу для контекста
2. Разработчик указывает API-токен в описании бага, чтобы воспроизвести проблему
3. QA-инженер оставляет тестовые учётные данные в комментарии для коллеги
4. HR-менеджер записывает данные подрядчика в задачу, пока основная система недоступна

Ни один из этих шагов не ощущается как нарушение — каждый просто делает свою работу эффективно. Но за месяцы и годы Jira-инстанс превращается в обширный нераспознанный архив чувствительных данных [10].

Правовой контекст: что говорит российское законодательство

152-ФЗ и понятие обработки

Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» определяет обработку ПДн широко: любое действие с данными, включая сбор, хранение, передачу, изменение, обезличивание и уничтожение [5]. Скриншот с данными клиента, сохранённый в папке «Обучение», — это хранение. Презентация с такими данными, отправленная коллеге — передача. Обе операции требуют правового основания.

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

Новый штрафной режим с 30 мая 2025 года

Федеральный закон № 420-ФЗ от 30.11.2024 существенно ужесточил ответственность за нарушения с персональными данными [1]. С 30 мая 2025 года действуют новые размеры штрафов по ст. 13.11 КоАП РФ, привязанные к масштабу утечки и составу скомпрометированных данных. При повторной утечке применяется оборотный штраф: 1–3% годовой выручки, но не менее 20 млн и не более 500 млн рублей [11]. Помимо административной, введена уголовная ответственность — вплоть до 10 лет лишения свободы — для тех, кто умышленно создаёт или администрирует каналы распространения похищенных ПДн [9].

Кроме того, оператор обязан уведомить Роскомнадзор об инциденте в течение 24 часов с момента обнаружения и представить результаты расследования в течение 72 часов [11].

Требования к обезличиванию: Приказ РКН № 140

С 1 сентября 2025 года вступил в силу Приказ Роскомнадзора от 19.06.2025 № 140, который заменил устаревший Приказ № 996 от 2013 года и утвердил новые требования и методы обезличивания персональных данных [4]. Документ закрепляет пять методов:

1. Введение идентификаторов — замена ПДн на символы, номера или другие обозначения, не позволяющие установить личность
2. Изменение состава или семантики персональных данных — удаление или искажение отдельных атрибутов (например, вместо точной даты рождения оставлять только год)
3. Перемешивание (декорреляция) — перестановка значений между записями так, чтобы нарушить связь атрибутов
4. Декомпозиция — разбиение массива на части, хранящиеся отдельно
5. Агрегация — обобщение атрибутов с установлением заданного количества допустимых значений

Приказ также запрещает совместное хранение обезличенных и исходных данных. Локальные акты об используемых методах не должны быть доступны третьим лицам [4].

Где прячутся реальные ПДн: анатомия типичных каналов

Скриншоты и записи экрана

Скриншот — наиболее распространённый и наименее контролируемый канал. Он возникает во множестве сценариев:

1. Фиксация бага: разработчик делает снимок экрана с ошибкой, на котором видны ФИО пользователя из интерфейса
2. Демонстрация UI: дизайнер или менеджер продукта показывает новый экран с реальными данными из тестовой среды, подключённой к продакшн-БД
3. Иллюстрация для обучения: специалист вставляет скриншот рабочего приложения в обучающую презентацию
4. Видеозапись демо: экранная запись вебинара или онбординга, где ведущий работает в реальной системе
5. Скриншот чата поддержки: переписка с клиентом, содержащая его данные, добавляется как вложение к тикету

Проблема состоит в том, что изображения сложнее поддаются автоматическому сканированию на ПДн, чем текст. Современные DLP-системы используют компьютерное зрение для анализа содержимого скриншотов, однако многие компании такими средствами ещё не располагают [2].

Тикеты в системах управления задачами (Jira, YouTrack, Redmine)

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

1. Email-адреса и имена клиентов в задачах поддержки
2. Номера телефонов и паспортные данные в задачах HR-отдела
3. ИНН и реквизиты в задачах финансового департамента
4. Фрагменты логов с идентификаторами пользователей
5. Скриншоты интерфейсов с видимыми данными клиентов в вложениях

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

Демо-стенды и тестовые среды

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

1. Тестовая среда подключена к копии продакшн-базы без маскирования
2. Демо-стенд для продажников содержит реальные данные клиентов из пилотного проекта
3. Среда для обучения создавалась «быстро» — просто скопировали дамп продакшна
4. Доступ к демо-стенду предоставлен внешним партнёрам или потенциальным клиентам

Европейский регулятор (EDPB) в своих разъяснениях 2024 года прямо указал: немаскированные производственные данные в dev/test-средах являются нарушением принципа законности обработки (аналог — ст. 5 GDPR), если данные не псевдонимизированы или не анонимизированы [12]. Российское законодательство содержит аналогичные требования к основаниям обработки и минимизации данных.

Обучающие материалы и документация

Учебные пособия, инструкции, онбординг-материалы создаются часто в спешке и редко проходят проверку на наличие ПДн. Характерные проблемы:

1. Скриншоты реального интерфейса с данными клиентов в руководстве пользователя
2. Пример заполнения формы с реальными ФИО и адресами в инструкции
3. Обучающее видео, на котором инструктор работает в реальной системе с реальными данными
4. Шаблоны документов с «примерами», взятыми из реальных договоров

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

Презентации для стейкхолдеров и инвесторов

Часто встречающийся, но редко осознаваемый риск — слайды с бизнес-метриками. Типичные примеры:

1. Таблица топ-100 клиентов с именами контактных лиц, оборотами, историей взаимодействия
2. Пример работы алгоритма с реальными данными пользователя в качестве иллюстрации
3. Скриншот CRM с данными конкретных сделок и участников

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

Методы защиты: от технических до организационных

Маскирование данных (Data Masking)

Маскирование данных — это метод защиты, при котором реальные значения заменяются на правдоподобные, но фиктивные: например, имя «Иванов Иван Иванович» заменяется на «Петров Пётр Петрович», реальный номер телефона — на корректно отформатированный случайный. Структура данных и форматы сохраняются, что позволяет использовать маскированные данные для тестирования, обучения и демонстраций [13].

Различают два основных типа:

1. Статическое маскирование (Static Data Masking, SDM) — создаётся постоянная маскированная копия базы данных. Подходит для dev/test-сред, обучения и демо-стендов. По данным исследования Perforce, 81% организаций оценивают статическое маскирование как высокоэффективный метод защиты [3].
2. Динамическое маскирование (Dynamic Data Masking, DDM) — данные маскируются в режиме реального времени при каждом запросе. Не требует создания отдельной копии БД, подходит для сценариев, где разные роли должны видеть разный уровень детализации.

Ключевое ограничение: маскированные данные по российскому праву всё ещё могут считаться псевдонимизированными ПДн, а не полностью обезличенными. Это означает, что они продолжают подпадать под требования 152-ФЗ. Для полного исключения из-под действия закона требуется необратимая анонимизация [5].

Синтетические данные

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

Gartner прогнозировал, что к 2025 году синтетические данные позволят организациям избежать 70% санкций за нарушения приватности в аналитических и ML-проектах [15]. Основное ограничение синтетических данных — они могут недостаточно точно воспроизводить статистические свойства реальных данных и не всегда подходят для нагрузочного или интеграционного тестирования.

Обезличивание по Приказу РКН № 140

В контексте российского законодательства с 1 сентября 2025 года обезличивание должно проводиться по методам из Приказа РКН № 140 [4]. Для практических нужд (скриншоты, обучение, демо) наиболее применимы:

1. Введение идентификаторов — для замены имён и контактов в документации
2. Изменение состава — например, убрать отчество, заменить точную дату рождения на год
3. Агрегация — для аналитических данных (показывать диапазоны вместо точных значений)

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

Редактирование скриншотов: инструменты и ограничения

Ручное заблюривание или закрашивание ПДн на скриншотах — наиболее распространённый, но наименее надёжный метод. Типичные ошибки:

1. Использование полупрозрачных прямоугольников, сквозь которые текст всё равно читается
2. Закрашивание видимого текста, но не метаданных файла, в которых могут содержаться те же данные
3. Пропуск отдельных полей (например, заблокировали имя, но оставили email или ИНН)
4. Некорректное заблюривание, которое можно отменить при обработке изображения

Более надёжный подход — использование специализированных инструментов с постоянным (необратимым) закрашиванием, а лучше — изначально работать с маскированными или синтетическими данными, исключая необходимость последующей обработки скриншотов.

Организационные меры: политики, процессы и культура

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

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

1. Производственные данные не попадают в dev/test-среды без прохождения процедуры маскирования или обезличивания
2. Скриншоты с ПДн допустимы только для внутреннего расследования инцидентов и хранятся в строго контролируемом месте
3. Обучающие материалы проходят обязательную проверку на наличие ПДн перед публикацией
4. Демо-стенды работают только на синтетических или маскированных данных

Российское законодательство обязывает операторов разрабатывать и соблюдать внутренние регламенты по обработке ПДн — ст. 18.1 152-ФЗ [5]. Наличие такой политики снижает риски при проверке Роскомнадзора.

Обучение сотрудников

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

Эффективное обучение должно включать:

1. Конкретные примеры недопустимых действий (что именно нельзя вставлять в тикет, как выглядит нарушение)
2. Практические инструменты и инструкции — как замаскировать данные перед скриншотом, где взять синтетические данные для демо
3. Регулярное повторение (хотя бы раз в год): законодательство и угрозы меняются
4. Личную ответственность: каждый сотрудник с доступом к ПДн должен понимать, что несёт личную ответственность за соблюдение правил

Согласно требованиям 152-ФЗ, все работники с доступом к ПДн должны проходить инструктаж по вопросам конфиденциальности и информационной безопасности [5].

Контроль доступа и принцип минимальных привилегий

Ограничение доступа к данным снижает риск их появления в неправильных местах. Практические меры:

1. Разграничение доступа к задачам в Jira по ролям и проектам
2. Ограничение прав на создание скриншотов в системах с ПДн (технически возможно в ряде корпоративных решений)
3. Регулярная ревизия прав доступа: особенно при изменениях в команде, подрядчиках, увольнениях
4. Контроль подрядчиков: они нередко имеют широкий доступ, но не всегда понимают внутренние политики

Разделение сред

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

Практический чек-лист: проверьте себя прямо сейчас

Проверка текущего состояния

1. Есть ли у вас задокументированная политика о работе с ПДн в тестовых средах и обучающих материалах?
2. Все ли демо-стенды и тестовые среды работают на маскированных или синтетических данных, а не на копии продакшна?
3. Проверяются ли обучающие материалы (слайды, видео, инструкции) на наличие реальных ПДн перед публикацией?
4. Есть ли регламент работы с баг-репортами, запрещающий включение ПДн в описание задач?
5. Знают ли сотрудники, как заблокировать ПДн на скриншоте или как запросить синтетические данные?
6. Существует ли процедура регулярного сканирования Jira/Confluence/других систем на наличие чувствительных данных?
7. Контролируются ли вложения к задачам (в том числе скриншоты) на предмет наличия ПДн?
8. Когда в последний раз проводился аудит обучающих материалов на наличие реальных данных?

Немедленные действия при обнаружении проблемы

1. Удалите или замените ПДн в найденном документе или задаче
2. Оцените, могли ли эти данные быть переданы третьим лицам (просмотрены, скачаны, отправлены)
3. Если передача имела место — оцените необходимость уведомления Роскомнадзора (ч. 3.1 ст. 21 152-ФЗ)
4. Зафиксируйте инцидент внутри компании
5. Проверьте, нет ли аналогичных данных в других местах того же хранилища

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

Ошибка 1: «Это тестовая среда, туда можно»

Многие команды убеждены, что тестовые среды — это «не продакшн» и поэтому правила защиты данных к ним не применяются. Это заблуждение. Любое хранение ПДн без надлежащих оснований является нарушением вне зависимости от типа среды. Тестовые среды, как правило, имеют более слабую защиту — меньше мониторинга, более широкий доступ, менее строгие политики [9].

Ошибка 2: Заблюривание вместо маскирования

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

Ошибка 3: Игнорирование «старых» данных

Задачи в Jira трёхлетней давности с ПДн клиентов — не менее рискованный объект, чем свежие. Регуляторы не устанавливают срока давности для нарушений хранения. При этом исторические данные сложнее обнаружить и зачастую имеют более широкий доступ (проекты расширяются, роли меняются). Необходима периодическая «инвентаризация» исторических данных в коллаборационных инструментах [10].

Ошибка 4: Одноразовое обучение

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

Ошибка 5: Полупрозрачные оверлеи как «защита»

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

Ошибка 6: Доступ подрядчиков к непроизводственным средам без контроля

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

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

Современные DLP-системы и специализированные инструменты (такие как Nightfall AI) используют компьютерное зрение и машинное обучение для обнаружения ПДн непосредственно в изображениях, включая скриншоты, прикреплённые к задачам. Модели распознают паттерны, характерные для номеров телефонов, email-адресов, ИНН, СНИЛС даже в форматированном тексте внутри картинки [2].

Для российских компаний практически значимо: при выборе DLP-решения или плагина для Jira/Confluence следует проверять наличие поддержки форматов российских идентификаторов (ИНН, СНИЛС, серия и номер паспорта, ОГРН) и кириллицы.

Тренды и будущее

Регуляторное давление усилится

Введение оборотных штрафов в России [11] и планомерное ужесточение GDPR в Европе [12] означают, что стоимость нарушений будет расти. Компании, которые сегодня не выстраивают процессы работы с данными в непроизводственных средах, рискуют столкнуться с нарастающими санкциями.

ИИ и синтетические данные выходят на первый план

Использование генеративного ИИ для создания синтетических наборов данных быстро развивается. Современные подходы (комбинация LLM и табличных генеративных моделей) позволяют создавать данные, статистически близкие к реальным, но не содержащие ни одной реальной записи [15]. Это делает синтетические данные перспективным решением не только для тестирования, но и для обучения ML-моделей и демонстраций.

Автоматическое обнаружение ПДн в неструктурированных данных

Рынок инструментов для обнаружения ПДн в неструктурированных данных (изображениях, PDF, видео, логах) активно растёт. Технологии NLP и компьютерного зрения достигли зрелости, при которой автоматический поиск ПДн в скриншотах и документах становится практичным и доступным [19].

Требования к обезличиванию войдут в стандарты разработки

Тенденция к внедрению privacy-by-design — учёту требований приватности на этапе проектирования систем — неизбежно затронет процессы разработки программного обеспечения. Обязательное использование маскированных или синтетических данных в dev/test-средах становится частью baseline для аудитов [12].

Решение для непрерывного контроля: «Пятый фактор»

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

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

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

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

Заключение: что делать дальше

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

Практические шаги, которые можно сделать уже сегодня:

1. Провести быстрый аудит: посмотреть несколько задач в Jira/Confluence за последний год на предмет наличия ПДн — скорее всего, они там есть
2. Определить, используются ли реальные данные в демо-стендах и тестовых средах
3. Проверить последние обучающие материалы на наличие скриншотов с данными клиентов или сотрудников
4. Инициировать разработку или актуализацию политики использования данных в непроизводственных контекстах
5. Запланировать обучение команды: конкретные правила, конкретные примеры, конкретные инструменты

Подходы к защите зрелые и доступны прямо сейчас: маскирование данных, синтетические данные, обезличивание по методам Приказа РКН № 140, DLP-инструменты для коллаборационных платформ, автоматическое сканирование хранилищ. Выбор конкретного решения зависит от ИТ-ландшафта компании и объёма обрабатываемых данных. Но начать нужно с понимания, где именно ПДн сейчас находятся за пределами контролируемого периметра.

Источники

[1] Федеральный закон от 30.11.2024 № 420-ФЗ «О внесении изменений в Кодекс Российской Федерации об административных правонарушениях» — consultant.ru

[2] Nightfall AI. The Essential Guide to Data Loss Prevention in Jira — nightfall.ai/guide/the-essential-guide-to-data-loss-prevention-dlp-jira

[3] Perforce/Delphix. 2025 State of Data Compliance and Security Report — perforce.com/resources/pdx/data-masking-techniques-methods

[4] Приказ Роскомнадзора от 19.06.2025 № 140 «Об утверждении требований к обезличиванию персональных данных» — normativ.kontur.ru

[5] Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» — consultant.ru

[6] F6 (Threat Intelligence). Аналитика по утечкам персональных данных россиян в 2025 году — kommersant.ru/doc/8293551

[7] Хабр. В первой половине 2025 года РКН выявил 35 фактов утечек, содержащих более 39 млн записей — habr.com/ru/news/924602/

[8] Positive Technologies. Утечки конфиденциальных данных из организаций — первое полугодие 2024 — ptsecurity.com

[9] Positive Technologies. Утечки конфиденциальных данных из организаций — второе полугодие 2024 — ptsecurity.com

[10] miniOrange. Is Your Jira a DLP Liability? How to Scan & Fix PII Leaks — miniorange.com

[11] PR-CY. Персональные данные 2026: локализация, уведомления Роскомнадзора и штрафы за утечки — pr-cy.ru

[12] Accutive Security. GDPR Data Masking: PII Protection & Compliance Guide 2025 — accutivesecurity.com

[13] TechTarget. What is Data Masking? Techniques, Types and Best Practices — techtarget.com

[14] Accutive Security. Guide to Synthetic Data Generation — accutivesecurity.com

[15] K2View. Synthetic test data generation: Scalable, reliable, and powerful — k2view.com/blog

[16] SecurityMedia. Утечка данных: как случается и что с ними делать — securitymedia.org

[17] Nubes. Персональные данные в 2025 году: новые правила обработки и защиты для бизнеса — nubes.ru/blog

[18] miniOrange. How to Prevent Accidental Data Leaks in Jira & Confluence with DLP — miniorange.com

[19] OvalEdge. Best Data Masking Tools for Secure Data in 2026 — ovaledge.com

[20] Klerk.ru. Обезличивание персональных данных: новые правила с 1 сентября 2025 года — klerk.ru