Можно ли использовать реальные ПДн в тестовой базе данных?

Правовой и технический разбор: как компании проводят тестирование, не нарушая 152-ФЗ, и почему «боевые» данные в тесте — это всегда риск

Почему вопрос актуален именно сейчас

Вопрос «можно ли залить в тест копию продовой базы?» кажется техническим. На практике это один из наиболее частых способов, которым компании неосознанно создают серьёзный правовой риск.

Разработчик хочет воспроизвести реалистичный сценарий. QA-инженер нуждается в данных, идентичных боевым. DBA делает дамп, переносит его на тестовый сервер — и в этот момент компания начинает нарушать законодательство. Звучит жёстко, но логика здесь прямая.

С 2025 года ситуация изменилась кардинально. Реформа ответственности за нарушения с ПДн сделала подобные «технические» решения финансово опасными: штрафы стали сопоставимы с годовой выручкой небольших компаний [1], а уголовная ответственность за незаконное использование компьютерной информации с ПДн введена с декабря 2024 года [2].

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

Что говорит закон: формальная сторона вопроса

Тестирование как «обработка» ПДн

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

Иными словами, как только реальные ПДн попали в тестовую базу — началась их обработка. Неважно, что среда называется «dev» или «staging»: с точки зрения закона это информационная система персональных данных, подпадающая под все требования.

Принцип целевой обработки и минимизации

Статья 5 152-ФЗ устанавливает базовые принципы обработки, два из которых напрямую относятся к ситуации с тестовыми базами [4]:

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

Второй принцип: не допускается обработка ПДн, несовместимая с целями сбора. Разработка и тестирование ПО — это новая, самостоятельная цель. Субъект данных о ней не знает и согласия не давал.

Пункт 4 статьи 5 прямо указывает: «Обработке подлежат только персональные данные, которые отвечают целям их обработки» [4]. Тестирование системы не входит в перечень стандартных целей, на которые субъект дал согласие.

Нет специальной нормы — есть общая

В законе отсутствует статья «о тестовых средах», которая разрешала бы или запрещала использование реальных данных. Это создаёт ложное ощущение «серой зоны». Но отсутствие специальной нормы не означает разрешения — оно означает, что применяются общие нормы в полном объёме.

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

Чем это грозит: ответственность в 2025–2026 годах

Административная ответственность

С 30 мая 2025 года вступил в силу Федеральный закон № 420-ФЗ, который кардинально ужесточил ст. 13.11 КоАП РФ [6]. Теперь штрафы напрямую зависят от масштаба нарушения:

1. Незаконная передача ПДн (в том числе из боевой базы в тестовую без оснований) от 1 до 10 тыс. человек — штраф для юрлиц от 3 до 5 млн руб.
2. Незаконная передача данных от 10 до 100 тыс. человек — от 5 до 10 млн руб.
3. Свыше 100 тыс. субъектов — от 10 до 15 млн руб.
4. При повторном нарушении — оборотный штраф: 1–3% от годовой выручки, но не менее 20 млн и не более 500 млн руб. [7]

Первые реальные судебные решения по новым нормам уже появились в начале 2026 года [8]: онлайн-школа получила штраф в диапазоне 10–15 млн руб. за утечку данных более 300 000 пользователей.

Уголовная ответственность

С 11 декабря 2024 года действует ст. 272.1 УК РФ, которая вводит уголовную ответственность за незаконное использование компьютерной информации с ПДн [2]. Санкция — штраф до 300 000 руб. или лишение свободы до 4 лет. Если нарушение касается данных несовершеннолетних или биометрии — до 5 лет.

Репутационные и операционные риски

Помимо штрафов, компания рискует уведомлением Роскомнадзора об утечке (если тестовый стенд был скомпрометирован), судебными исками субъектов ПДн о возмещении морального вреда и блокировкой деятельности.

Почему тестовые базы — это «слепое пятно»

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

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

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

В-третьих, «дублирование» данных в нескольких средах. Если дамп боевой базы копируется в dev, staging, pre-prod и тестовую среду нагрузочного тестирования — фактически создаётся четыре незадокументированные ИСПДн. Контроль за ними, как правило, отсутствует.

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

Обезличивание как законный путь: старый подход и новые правила

Что такое обезличивание

Обезличивание персональных данных — это действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность ПДн конкретному субъекту (ст. 3 152-ФЗ) [3]. После качественного обезличивания данные выходят из-под режима персональных данных.

Важное следствие: с 1 сентября 2025 года обезличенные данные можно обрабатывать без согласия субъекта (Федеральный закон № 233-ФЗ от 08.08.2024) [10]. Это принципиальное изменение открыло законный путь для тестирования: взять реальные данные, качественно обезличить — и использовать результат без ограничений, типичных для ПДн.

Методы обезличивания

Роскомнадзор разработал требования и методы по обезличиванию персональных данных. Приказ № 996, действовавший с 2013 года, с 1 сентября 2025 года заменён новым приказом РКН № 140 от 19 июня 2025 года [11], который устанавливает более детальные и строгие требования к процессу обезличивания.

Методы, применяемые на практике:

1. Метод введения идентификаторов (псевдонимизация): реальное имя «Мария Петрова» заменяется кодом «B7-K12», создаётся отдельная таблица соответствия. Таблица хранится в изолированной системе. Этот метод обратим — наиболее подходит для внутреннего использования, когда может потребоваться восстановление.
2. Метод изменения состава или семантики: вместо точного адреса — только город или округ; числовые значения заменяются статистическими агрегатами. Этот метод практически необратим и лучше защищает от де-анонимизации.
3. Метод декомпозиции: массив ПДн разбивается на несколько частей, хранящихся раздельно. Каждая часть по отдельности не позволяет идентифицировать субъекта.
4. Метод перемешивания: значения одного атрибута переставляются между разными записями. Данные остаются статистически достоверными, но связь с конкретным человеком разрывается [12].

Подводные камни обезличивания

Обезличивание кажется простым, но на практике имеет несколько серьёзных сложностей [9]:

• Как автоматически определить, какие поля в базе содержат ПДн? Поля с нетипичными названиями (например, comment_text, где пользователи иногда указывают телефон) остаются в «серой зоне».
• Как сохранить ссылочную целостность данных после обезличивания? Если изменить ID клиента, вся связанная история заказов «рассыплется».
• Как не допустить повторного появления реальных данных при очередном обновлении тестового стенда?

Именно для решения этих задач крупные компании разрабатывают специализированные решения — платформы управления тестовыми данными (Test Data Management, TDM) [13].

Синтетические данные: альтернатива без рисков

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

Когда синтетика предпочтительнее обезличивания

Обезличивание не всегда решает задачу. Например:

• При нагрузочном тестировании нужны миллионы записей — создать их обезличиванием из реальной базы невозможно, если реальная база меньше.
• При тестировании крайних случаев (edge cases) нужны данные с нетипичными значениями, которых в реальной базе нет.
• При передаче тестовых данных внешним подрядчикам синтетические данные полностью исключают риск раскрытия реальных ПДн.

Инструменты генерации

На рынке доступен широкий набор инструментов — как зарубежных, так и разработанных в России [14]. Сбербанк создал Platform V Works:TDM [13] — систему, которая позволяет генерировать синтетические тестовые данные по клику, сохраняя ссылочную целостность. По данным разработчиков, внедрение инструмента сократило время подготовки тестовых данных с одного дня до одного часа.

Среди популярных подходов: библиотека Faker для Python (генерация реалистичных имён, адресов, телефонов, email); инструменты на базе генеративных нейросетей (CTGAN, Synthetic Data Vault), которые воспроизводят статистические распределения реальных данных без их копирования; специализированные решения типа DATPROF и Mockaroo для структурированных баз данных.

Что делать: пошаговый алгоритм перехода

Шаг 1. Провести инвентаризацию тестовых сред

Составить реестр всех сред (dev, staging, pre-prod, нагрузочное тестирование, демо-стенды) и проверить, есть ли в них данные, позволяющие идентифицировать реальных людей. Это должно делаться регулярно, а не только в момент первоначального аудита.

Шаг 2. Определить подход: обезличивание или синтетика

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

• Функциональное тестирование с реалистичными данными → обезличивание или синтетика
• Нагрузочное тестирование → синтетические данные (требуются большие объёмы)
• Тестирование на внешнем стенде или у подрядчика → только синтетика или максимальное обезличивание

Шаг 3. Выбрать и внедрить инструмент

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

Если нужна синтетика: использовать генераторы случайных данных для небольших объёмов или ML-инструменты для сохранения статистических характеристик при больших объёмах.

Шаг 4. Включить тестовые среды в систему управления ПДн

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

Шаг 5. Выстроить процесс обновления тестовых стендов

Если тестовые стенды периодически обновляются данными из продакшена, процедура обезличивания должна быть встроена в ETL-пайплайн и выполняться автоматически при каждом обновлении [9]. Это исключает ситуацию, когда старая тестовая база очищена, а новая — нет.

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

Ошибка 1: «Это внутренние данные, никуда они не уйдут»

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

Ошибка 2: «Мы взяли выборку, а не всю базу»

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

Ошибка 3: «Мы заменили имена, этого достаточно»

Частичная замена имён при сохранении остальных атрибутов (дата рождения, адрес, телефон) не является обезличиванием. Сочетание квазиидентификаторов позволяет де-анонимизировать данные. Роскомнадзор оценивает результат, а не факт применения «какого-то метода».

Ошибка 4: «Срок хранения тестовых данных не важен»

Тестовые базы часто существуют годами без переоценки необходимости хранения. Между тем, согласно ст. 5 152-ФЗ, данные должны уничтожаться по достижении целей обработки [4]. Устаревший тестовый дамп — это нарушение, даже если активного тестирования уже нет.

Ошибка 5: «Документации по тестовым средам не нужно»

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

Отраслевые кейсы и практический опыт

Российский банковский сектор столкнулся с проблемой тестовых данных одним из первых — в силу объёмов клиентских баз и строгих требований регулятора (ЦБ РФ, Банк России). Один из типичных примеров: при разработке нового модуля интернет-банкинга команда копировала выборку из боевой базы для воспроизведения реалистичных сценариев авторизации. После внутреннего аудита это было квалифицировано как нарушение — и заменено на обезличенные данные [12].

В здравоохранении проблема острее: медицинские данные относятся к специальным категориям ПДн (ст. 10 152-ФЗ) и требуют усиленной защиты. Использование реальных медицинских записей в тестовой среде МИС — одно из наиболее частых нарушений, выявляемых при проверках [15].

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

Тренды: что будет дальше

Обезличивание становится обязательным этапом

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

Рост рынка синтетических данных

По оценкам аналитиков, рынок генерации синтетических данных вырастет с 209 млн долларов в 2022 году до 1,5 млрд долларов к 2028 году [16]. Российский рынок развивается в том же направлении: инвестиции в платформы управления тестовыми данными растут вместе со штрафами за нарушения с ПДн.

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

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

Заключение: что делать прямо сейчас

Использование реальных ПДн в тестовой базе данных — это не «серая зона» и не технический вопрос. Это нарушение принципов 152-ФЗ, которое с 2025 года влечёт реальные многомиллионные штрафы.

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

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

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

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

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

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

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

Источники

[1] КонсультантПлюс — Новые штрафы за утечку персональных данных — https://www.consultant.ru/legalnews/27142/

[2] ЕМЧД — Новые штрафы при работе с ПДн с 30 мая 2025 — https://emchd.ru/blog/stati/novye-shtrafy-pri-rabote-s-pdn-s-30-maya-2025/

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

[4] КонсультантПлюс — Статья 5. Принципы обработки персональных данных — https://www.consultant.ru/document/cons_doc_LAW_61801/96fbc469f91f57235cc842a85e0516a99f23dc85/

[5] КонсультантПлюс — Статья 6. Условия обработки персональных данных — https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/

[6] Law.ru — Утечка персональных данных: уведомление Роскомнадзора, оборотные штрафы — https://www.law.ru/article/28376-utechka-personalnyh-dannyh-shtrafy-v-2025-godu

[7] InfoWatch — Оборотные штрафы за утечку ПДн — https://www.infowatch.ru/resursy/blog/korporativniy-blog/kak-snizit-riski-oborotnykh-shtrafov-za-utechku-pdn-v-dve-tysyachi-dvadtsat-pyatom-godu

[8] ГАРАНТ.РУ — В России назначены первые штрафы за крупные утечки персональных данных — https://www.garant.ru/news/2026629/

[9] Хабр / СберТех — Как мы упростили подготовку данных для тестирования — https://habr.com/ru/companies/sberbank/articles/668160/

[10] Хабр — Новые правила обезличивания персональных данных с 1 сентября 2025 года — https://habr.com/ru/articles/931348/

[11] ГАРАНТ — Приказ Роскомнадзора от 05.09.2013 N 996 (утратил силу с 1 сентября 2025 г.) — https://base.garant.ru/70451476/

[12] Delo-Press — Когда и зачем нужно обезличивать персональные данные — https://delo-press.ru/journals/law/trudovoe-zakonodatelstvo/48637-kogda-i-zachem-nuzhno-obezlichivat-personalnye-dannye/

[13] Platform V Works / СберТех — На этой планете время идёт быстрее. Здесь мы и будем тестировать — https://works.sbertech.ru/media/na-etoj-planete-vremya-idyot-bystree-zdes-my-i-budem-testirovat

[14] QARocks — 18 лучших инструментов для генерации тестовых данных — https://qarocks.ru/test-data-generation-tools/

[15] КиберЛенинка — Обезличивание персональных данных в здравоохранении — https://cyberleninka.ru/article/n/obezlichivanie-personalnyh-dannyh-v-zdravoohranenii

[16] Habr / Skillfactory — Синтетические данные в 2025: волшебная таблетка для нейросетей или темная лошадка? — https://habr.com/ru/companies/skillfactory/articles/887884/