Классификация данных в компании: как отделить ПДн, коммерческую тайну и технические данные в реальных процессах

Когда одно неверное слово в политике стоит 500 миллионов рублей

Зачем компании нужна классификация данных

Представьте: ваш аналитик выгружает из CRM отчёт «Клиенты по сегментам». Файл содержит имена, телефоны и email-адреса (ПДн), условия индивидуальных скидок (коммерческая тайна), сегментационные коды и идентификаторы (технические данные). Какой гриф поставить? Как хранить? Кому давать доступ? Что случится при утечке?

Большинство российских компаний не могут ответить на эти вопросы быстро и точно. По данным ЭАЦ InfoWatch, в 2024 году объём утекших персональных данных из российских организаций вырос на 31,7% — до 1,58 млрд записей [3]. При этом законодательное давление резко усилилось: с мая 2025 года вступили в силу оборотные штрафы за утечки ПДн [1], а с декабря 2024-го введена уголовная ответственность [2].

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

Статья адресована широкой аудитории: от руководителей, принимающих решения об инвестициях в ИБ, до специалистов по безопасности, разрабатывающих политики, и ИТ-архитекторов, проектирующих хранилища данных.

Правовой контекст: три разных закона — три разных режима

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

Персональные данные: статус субъекта превыше всего

Персональные данные — это любые сведения, прямо или косвенно относящиеся к идентифицированному или идентифицируемому физическому лицу [5]. Ключевой закон — №152-ФЗ «О персональных данных». Владелец прав здесь — сам субъект данных (физическое лицо), а компания-оператор несёт обязанности по его защите.

Закон 152-ФЗ выделяет несколько категорий:

1. Общедоступные ПДн — имя, место работы, контакты из открытых реестров.
2. Персональные данные общей категории — ФИО, паспортные данные, адрес, СНИЛС, ИНН.
3. Специальные категории ПДн (статья 10) — расовая, национальная принадлежность, политические взгляды, религиозные убеждения, состояние здоровья, сексуальная жизнь, сведения о судимостях. Обрабатываются только в строго определённых законом случаях.
4. Биометрические ПДн (статья 11) — физиологические и биологические характеристики, позволяющие идентифицировать личность: отпечатки пальцев, запись голоса, изображение лица [6].

С 30 мая 2025 года штрафы за нарушения с ПДн кратно выросли. За общие нарушения — до 300 000 рублей для организаций при первом нарушении. За утечку данных более 100 тысяч субъектов — от 10 до 15 млн рублей. При повторных нарушениях — оборотные штрафы: от 1 до 3% годовой выручки, но не менее 20 млн и не более 500 млн рублей [1][2]. С 11 декабря 2024 года введена статья 272.1 УК РФ — уголовная ответственность за нарушения с ПДн, вплоть до лишения свободы на срок до 5 лет [2].

Контролирующий орган — Роскомнадзор. Он ведёт реестр операторов ПДн, в котором обязана состоять любая компания, обрабатывающая персональные данные.

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

Коммерческая тайна — это режим конфиденциальности информации, позволяющий её обладателю увеличить доходы, избежать расходов, сохранить положение на рынке или получить иную коммерческую выгоду [7]. Ключевой закон — №98-ФЗ «О коммерческой тайне».

Принципиальное отличие: компания сама решает, что является её коммерческой тайной. Закон не устанавливает конкретный перечень — он лишь определяет, что не может быть коммерческой тайной (статья 5 98-ФЗ) [8].

В режим коммерческой тайны традиционно включают [9]:

1. Клиентскую базу и условия договоров с контрагентами.
2. Себестоимость и ценовую политику.
3. Технологии, ноу-хау, производственные процессы.
4. Бизнес-планы и стратегии развития.
5. Исходный код программного обеспечения.
6. Результаты маркетинговых исследований.
7. Конфигурации систем безопасности.

Важно: коммерческой тайной нельзя признать сведения из учредительных документов ЕГРЮЛ/ЕГРИП, данные о штате и системе оплаты труда, информацию о нарушениях законодательства и другие сведения из прямого перечня статьи 5 98-ФЗ [8].

Чтобы защита работала юридически, компания обязана ввести режим коммерческой тайны: утвердить перечень приказом руководителя, разграничить доступ, нанести грифы на носители и ознакомить сотрудников под подпись [9]. Без хотя бы одного из этих шагов суд может признать режим недействительным.

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

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

Технические данные — это информация, обеспечивающая работу IT-систем и бизнес-процессов: конфигурации серверов, схемы баз данных, API-ключи, логи, служебные идентификаторы, параметры интеграций. Часть из них может быть коммерческой тайной (например, уникальная архитектура платформы), часть — просто служебными сведениями для внутреннего использования.

Отдельную категорию составляют данные о критической информационной инфраструктуре (КИИ) — для организаций, попадающих под действие №187-ФЗ «О безопасности КИИ».

Правовой базис для технических данных — общее законодательство об информации (№149-ФЗ), плюс отраслевые требования ФСТЭК, ФСБ, ЦБ РФ и иных регуляторов в зависимости от сферы деятельности.

Почему различие имеет значение

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

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

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

Где живут данные

Типичные источники данных в средней российской компании:

1. Реляционные базы данных (1С, SAP, отраслевые ERP-системы) — транзакционные и мастер-данные.
2. CRM-системы — клиентские профили, история взаимодействий, условия сделок.
3. Почтовые серверы и корпоративные мессенджеры — переписка, часто содержащая ПДн и сведения КТ в неструктурированном виде.
4. Файловые хранилища и корпоративные порталы — документы, презентации, таблицы.
5. Active Directory/LDAP — учётные записи, роли, атрибуты пользователей.
6. API внешних сервисов и интеграций — данные передаются «на лету» и нередко нигде не документируются.
7. Облачные сервисы и SaaS — часто вне прямого контроля службы ИБ.
8. Архивы и резервные копии — данные «заморожены» в состоянии на дату бэкапа, но по-прежнему существуют.

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

Типология корпоративных данных

На практике данные компании распадаются на несколько больших классов:

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

Проблема пересечений: когда один файл — сразу три категории

Самый сложный практический случай — «гибридные» документы. Вот несколько реальных типов:

Договор с клиентом-физическим лицом

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

Зарплатная ведомость

Содержит ПДн (ФИО, банковские реквизиты, СНИЛС), сведения об условиях труда (часть из которых не может быть КТ согласно статье 5 98-ФЗ — информация о системе оплаты труда является публичной для надзорных органов), но конкретные суммы зарплат конкретных сотрудников являются и ПДн, и фактически конфиденциальными данными.

CRM-выгрузка для маркетинговой кампании

ФИО и контакты (ПДн), история покупок и предпочтения (могут быть ПДн, если персонализированы), сегментационные теги и скоринг-модели (КТ — алгоритм сегментации), технические идентификаторы клиента в системе.

Технический паспорт продукта с тест-данными

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

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

Методология классификации: от теории к практике

Международные подходы: ISO 27001 и матрица рисков

Международный стандарт ISO/IEC 27001:2022 в контроле Annex A 5.12 требует, чтобы информация классифицировалась на основе требований безопасности с учётом её ценности, чувствительности и критичности [4]. Стандарт не задаёт конкретные уровни — он оставляет это на усмотрение организации, — но большинство компаний используют три или четыре уровня [10]:

1. Публичная (Public) — информация, предназначенная для открытого распространения.
2. Внутренняя (Internal) — информация для внутреннего использования, не конфиденциальная, но не предназначенная для публики.
3. Конфиденциальная (Confidential) — информация с ограниченным доступом внутри организации.
4. Строго конфиденциальная (Restricted) — информация с минимальным кругом допущенных лиц.

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

Важный принцип ISO 27001: каждый информационный актив должен иметь владельца (data owner) — конкретного сотрудника, ответственного за определение уровня классификации, сроков хранения и допустимого круга доступа [4]. Это не служба ИБ — это бизнес-подразделение, которое лучше всего понимает ценность конкретных данных.

Адаптация к российскому законодательству

Российская специфика требует совместить международный подход с отечественной правовой рамкой. На практике это означает:

1. Уровень «Строго конфиденциально / Специальные ПДн» — биометрия, медицинские данные, данные о судимостях, финансовые данные в сочетании с личностью.
2. Уровень «Конфиденциально / ПДн» — стандартные персональные данные сотрудников и клиентов; здесь же — коммерческая тайна.
3. Уровень «Для служебного использования / Внутренний» — служебная информация, технические данные, рабочая документация без персональных данных и без явной коммерческой ценности.
4. Уровень «Открытый / Публичный» — информация из открытых реестров, публичная отчётность, маркетинговые материалы.

Важно: один документ может одновременно требовать применения режима ПДн (152-ФЗ) и режима коммерческой тайны (98-ФЗ). В этом случае применяются оба режима, причём более строгие требования имеют приоритет.

Практическая схема принятия решений

Для каждой единицы данных (поле в БД, тип документа, категория записей) рекомендуется проверить следующую цепочку:

1. Относится ли эта информация к идентифицированному или идентифицируемому физическому лицу? Если да — это ПДн, применяется 152-ФЗ.
2. Является ли эта информация биометрической или специальной категорией? Если да — применяется усиленный режим статьей 10-11 152-ФЗ.
3. Имеет ли эта информация коммерческую ценность и не является ли она публичной? Если да — может быть коммерческой тайной, при условии введения режима по 98-ФЗ.
4. Может ли эта информация раскрыть технические уязвимости системы? Если да — технические данные с ограниченным доступом.
5. Ни один из вышеуказанных критериев не применим — публичная или внутренняя информация общего пользования.

Как строить политику классификации: пошаговый подход

Шаг 1: Инвентаризация информационных активов

Классификацию невозможно начать без инвентаризации. Вы не можете защитить то, чего не видите. Инвентаризация включает:

1. Составление реестра информационных систем и хранилищ (базы данных, файловые серверы, облачные сервисы, почтовые системы, архивы).
2. Для каждого хранилища — перечень типов данных с описанием содержимого.
3. Определение владельцев данных по каждому хранилищу или категории.
4. Описание потоков данных: кто создаёт, кто использует, куда передаёт.

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

Шаг 2: Разработка политики классификации

Политика классификации должна быть написана языком, понятным не только ИБ-специалистам [11]. Она включает:

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

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

Шаг 3: Маркировка данных

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

Ручная маркировка применяется к сложным документам — аналитическим отчётам, презентациям, нестандартным материалам. Ответственный сотрудник проставляет метку в названии файла, в свойствах документа или через специальный шаблон [11].

Автоматическая маркировка применяется для структурированных данных в базах, массивов электронных документов, потоков данных. Используются системы класса DAG (Data Access Governance) и DLP (Data Loss Prevention), а также специализированные инструменты классификации данных [12].

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

Шаг 4: Управление доступом на основе классификации

Классификация становится управляющим параметром для политик доступа. Принцип наименьших привилегий (least privilege) и принцип «need to know» означают, что сотрудник получает доступ только к тем данным, которые необходимы для его задач. Уровень классификации определяет, какие технические меры применяются: шифрование при хранении и передаче, ведение журнала доступа, обязательное согласование при передаче за пределы контура.

Шаг 5: Обучение персонала

Техническая классификация бесполезна без осведомлённости сотрудников. Одним из самых трудных уроков является то, что классификация не работает, если люди не видят в ней ценности. Говорить сотруднику помечать документы как «Конфиденциально», не объясняя почему — верный способ быть проигнорированным.

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

Шаг 6: Аудит и актуализация

Классификация — не разовый проект. IT-ландшафт меняется: появляются новые сервисы, новые интеграции, новые поля в базах данных. Рекомендуемая периодичность пересмотра — минимум раз в год, а также при любых существенных изменениях инфраструктуры или регуляторных требований [4].

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

По персональным данным (152-ФЗ)

1. Ваша компания включена в реестр операторов ПДн Роскомнадзора.
2. Есть действующая Политика обработки персональных данных.
3. Определены все системы, в которых хранятся ПДн: базы данных, CRM, HR-системы, почта, архивы.
4. Для каждой системы определены: цель обработки, категории субъектов, сроки хранения.
5. Заключены соглашения об обработке ПДн с подрядчиками-обработчиками.
6. Настроено разграничение доступа к ПДн по принципу минимальных привилегий.
7. Есть процедура реагирования на утечку (уведомление РКН в течение 24 часов о факте, 72 часа — о результатах расследования).
8. Проведено обучение сотрудников по работе с ПДн.
9. Определены специальные категории ПДн и введены усиленные меры их защиты.
10. Есть процедура реализации прав субъектов (удаление, исправление, доступ к данным).

По коммерческой тайне (98-ФЗ)

1. Утверждён перечень сведений, составляющих коммерческую тайну, — отдельным приказом или положением.
2. Перечень конкретный, без расплывчатых формулировок типа «вся информация компании».
3. Сотрудники с доступом к КТ ознакомлены с перечнем под подпись.
4. На носителях (документах, файлах, хранилищах) нанесены грифы «Коммерческая тайна».
5. Заключены NDA с контрагентами, которым передаётся КТ.
6. Ведётся журнал лиц, имеющих доступ к КТ.
7. Перечень актуален — пересматривался в течение последнего года.
8. Трудовые договоры содержат обязательство о неразглашении КТ.

По технической документации и архитектурным данным

1. Документы с описанием архитектуры, схем БД, конфигураций систем имеют гриф ограниченного доступа.
2. API-ключи, пароли, сертификаты хранятся в защищённых хранилищах (vault), а не в файлах и репозиториях.
3. Тестовые среды не используют реальные ПДн без обезличивания.
4. Документация по критической инфраструктуре имеет усиленные меры защиты.

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

Ошибка 1: «Засекретим всё»

Некоторые компании в попытке перестраховаться присваивают гриф «Конфиденциально» буквально всему — вплоть до корпоративных поздравлений. Результат: классификация теряет смысл, сотрудники перестают воспринимать её всерьёз, реально конфиденциальные данные тонут в потоке «формально секретных» материалов.

Решение: строгие критерии для каждого уровня, регулярный аудит с понижением классификации устаревших данных.

Ошибка 2: Классификация без владельцев

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

Решение: каждый информационный актив должен иметь именованного владельца (data owner) с зафиксированной ответственностью. Владелец данных отвечает за определение классификации, сроков хранения и уровня защиты для своих данных и является единственным лицом, уполномоченным одобрять или отзывать доступ на основе принципа «need to know».

Ошибка 3: Режим КТ без соблюдения всех формальностей

Суды неоднократно признавали режим коммерческой тайны недействительным из-за пропуска формальных требований: нет подписи сотрудника, нет грифа на носителе, нет актуального перечня. Привлечь виновного к ответственности при этом невозможно даже при наличии NDA [9].

Решение: чек-лист введения режима КТ, юридическая проверка пакета документов, регулярный аудит соответствия.

Ошибка 4: Тестовые данные из продакшена

Разработчики часто используют «маскированные» копии реальных данных для тестирования. На практике маскировка нередко оказывается недостаточной — данные остаются идентифицируемыми.

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

Ошибка 5: Классификация как разовый проект

Самая распространённая ошибка. Компания тратит несколько месяцев на инвентаризацию и классификацию, получает красивый реестр, а через год он устаревает: появились новые микросервисы, новые интеграции с маркетплейсами, новые поля в CRM.

Решение: непрерывный мониторинг, автоматизированное обнаружение новых источников данных, обязательная процедура «Data Classification Review» при любых изменениях IT-ландшафта.

Ошибка 6: Игнорирование гибридных документов

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

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

Кейсы и примеры из практики

Кейс 1: Утечка базы клиентов телекоммуникационной компании

Классический пример из судебной практики: сотрудник компании связи передавал абонентские номера, персональные данные абонентов и данные лицевых счетов постороннему лицу за вознаграждение. Все переданные сведения являлись одновременно ПДн и коммерческой тайной [13]. Суд вынес обвинительный приговор. Ключевой урок: данные клиентской базы телеком-оператора охраняются как минимум двумя режимами, и нарушение любого из них влечёт ответственность.

Кейс 2: Инсайдерская утечка к конкурентам

По данным специалистов Infosecurity, ключевой сотрудник компании передал конкурентам коммерческую тайну в процессе поиска новой работы. Конкуренты успели воспользоваться информацией до того, как инцидент был обнаружен. Урон включал как прямые финансовые потери, так и репутационный ущерб [14]. Компания смогла добиться ответственности сотрудника только благодаря правильно оформленному режиму КТ и NDA в трудовом договоре.

Кейс 3: Рост доли коммерческой тайны в утечках

В общем объёме утекшей информации в России в 2024 году вдвое выросла доля скомпрометированных данных категории «коммерческая тайна» — с 8,9% до 20%. По оценкам аналитиков InfoWatch, это связано с существенно возросшей ценностью этого типа данных для злоумышленников. Это сигнал к тому, что компании, сосредоточившиеся исключительно на защите ПДн, могут недооценивать угрозу в отношении бизнес-данных.

Будущее: автоматизация классификации и новые вызовы

Тренд 1: Автоматизированные DSPM и DAG-решения

Ручная классификация не масштабируется. Компании всё активнее используют инструменты класса DSPM (Data Security Posture Management) и DAG (Data Access Governance), которые автоматически обнаруживают чувствительные данные в хранилищах, сканируют файловые системы и базы данных, обнаруживают аномалии в доступе и предлагают классификационные метки.

Тренд 2: Privacy by design как обязательная практика

Принцип privacy by design — встраивание требований защиты данных в архитектуру систем на этапе проектирования — постепенно становится не опцией, а стандартом. Он подразумевает, что классификация данных встраивается в процесс разработки новых продуктов и систем, а не добавляется задним числом.

Тренд 3: Ужесточение требований к локализации

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

Тренд 4: Рост инцидентов с участием ИИ-систем

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

Инструментарий: на что обратить внимание при выборе решений

Рынок предлагает несколько классов инструментов для поддержки классификации данных в компании:

1. DLP-системы (Data Loss Prevention) — контролируют передачу данных по каналам, применяют политики на основе классификации. Российский рынок: InfoWatch Traffic Monitor, Solar Dozor, SearchInform, КИБ «СерчИнформ», Ростелеком-Солар [15].
2. DAG/DCAP-системы (Data Access Governance / Data-Centric Audit and Protection) — обнаруживают чувствительные данные в неструктурированных хранилищах, анализируют права доступа. Работают с файловыми системами, SharePoint, почтой.
3. Инструменты обнаружения и инвентаризации ПДн (Data Discovery) — автоматически сканируют базы данных, API, хранилища на предмет персональных данных и предлагают их классификацию.
4. On-prem платформы управления ПДн — обеспечивают непрерывный контроль над всем ландшафтом данных без необходимости передавать сырые данные на внешние серверы.

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

Роль автоматизации: «живая карта данных» вместо статичного реестра

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

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

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

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

В условиях, когда аудит занимает недели, а регулятор требует уведомления об инциденте в течение 24 часов, разрыв между «статичным реестром» и «живой картой данных» становится критическим.

Заключение: классификация данных как основа информационной гигиены

Классификация данных — это не модный проект для галочки перед проверкой Роскомнадзора. Это фундамент управления информационными рисками компании.

Правильно выстроенная классификация позволяет:

1. Понять, что именно вы защищаете и от чего — вместо того чтобы пытаться защитить всё.
2. Применять пропорциональные меры: максимальная защита — там, где максимальный риск.
3. Реагировать быстро: при инциденте сразу понятно, какие данные затронуты и каковы последствия.
4. Снижать стоимость аудитов: актуальная «карта данных» в разы сокращает время на подготовку к проверкам.
5. Доказывать регулятору добросовестность: задокументированные процессы — это аргумент в случае административного разбирательства.

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

Что делать дальше: начните с инвентаризации хотя бы трёх ключевых систем с наибольшей концентрацией чувствительных данных (как правило, это CRM, HR-система и корпоративная почта), определите владельцев этих данных, и внедрите минимальную классификацию по четырём уровням. Это займёт не больше месяца — и даст вам реальное понимание вашего профиля рисков.

Источники

[1] Консультант Плюс — Штрафы за ПДн с 30 мая 2025 года (420-ФЗ) — https://www.consultant.ru/legalnews/28492/

[2] Контур.КЭДО — Новые штрафы и уголовная ответственность за нарушения с ПДн 2025 — https://kontur.ru/kedo/spravka/53645-shtrafy_za_narushenie_zakona_o_pd

[3] InfoWatch — Россия на 2-м месте по утечкам данных в мире, 2024 — https://www.infowatch.ru/company/presscenter/news/rossiya-zanyala-vtoroye-mesto-po-kolichestvu-utechek-dannykh-v-mire

[4] Konfirmity — ISO 27001 Data Classification Guide 2026 — https://www.konfirmity.com/blog/iso-27001-data-classification-guide

[5] portal-yug.ru — Виды персональных данных по закону №152-ФЗ — https://portal-yug.ru/blog/vidy-personalnyh-dannykh-po-zakonu-152-fz/

[6] law.ru — Категории персональных данных — https://www.law.ru/article/21946-kategorii-personalnyh-dannyh

[7] КонсультантПлюс — ФЗ №98-ФЗ «О коммерческой тайне», статья 3 — https://www.consultant.ru/document/cons_doc_LAW_48699/ea6f7bb32cdb797dc30aca18be2a215cd0211ad2/

[8] КонсультантПлюс — ФЗ №98-ФЗ «О коммерческой тайне», статья 5 — https://www.consultant.ru/document/cons_doc_LAW_48699/1baefc3a58183ff7712fb7baf06689440ed24c98/

[9] Кибероснова — Перечень сведений, составляющих коммерческую тайну — https://152fz.cyberosnova.ru/documents/perechen-svedenij-kommercheskoj-tajny

[10] Copla — ISO 27001 data classification levels explained — https://copla.com/blog/compliance-regulations/iso-27001-data-classification-levels-explained-and-policy-template-guide/

[11] SprutMonitor — Типы данных и их классификация в компании — https://sprutmonitor.ru/blog/tipy-dannyh-i-ih-klassifikacija-v-kompanii-dlja-zashhity-ot-kiberugroz/

[12] HighTable — ISO 27001 Annex A 5.12 Classification of Information — https://hightable.io/iso-27001-annex-a-5-12-classification-of-information/

[13] Право.ру — Введение режима коммерческой тайны — https://xn--b1afkisbcjmk.xn--p1ai/01-rezhim-kommercheskoj-tajny

[14] Infosecurity — Insider threat: когда сотрудник становится угрозой — https://in4security.com/news/xaslpz4ft1-kak-poterya-loyalnosti-odnogo-sotrudnika

[15] SecurityMedia — Обзор российских DLP-систем — https://securitymedia.org/analytics/obzor-rossiyskikh-dlp-sistem.html

[16] InfoWatch — Коммерческая тайна финансовых компаний: утечки 2024 — https://www.infowatch.ru/company/presscenter/news/zloumyshlenniki-zainteresovalis-kommercheskoy-taynoy-finkompaniy

[17] Falcongaze — Перечень сведений, относящихся к коммерческой тайне — https://falcongaze.com/ru/pressroom/publications/informacionnaya-bezopasnost-v-otraslyah/perechen-svedenij-otnosyashchihsya-k-kommercheskoj-tajne.html

[18] Hightable — ISO 27001 Information Classification and Handling Policy — https://hightable.io/information-classification-and-handling-policy/

[19] InfoWatch — Утечки информации ограниченного доступа в России, 2024 — https://ict.moscow/analytics/utechki-informatsii-ogranichennogo-dostupa-v-rossii-v-2024-godu/

[20] Solar/Ростелеком-Солар — Классификация данных для защиты от утечек — https://rt-solar.ru/products/solar_dozor/blog/5715/