
Когда руководитель говорит «у нас все данные критичные, защищайте всё», я заранее знаю, чем это закончится: бюджет распылится на одинаково слабую защиту всего, DLP захлебнётся в алертах, а реальная утечка всплывёт через полгода из новостей. Классификация информации — не бюрократическая галочка из требований ФСТЭК, а способ не утонуть в собственной инфраструктуре. В этой статье разберём, как провести её на практике: без внедрения «платформы за миллион», зато с понятным результатом.
Почему «всё критично» — это «ничего не защищено»
Логика «защищаем всё одинаково» убивает безопасность с двух сторон. Во-первых, стоимость: максимальный уровень защиты каждого актива — это шифрование всего, DLP на все каналы, SIEM на все источники и команда, которая это администрирует. Малый и средний бизнес такой бюджет не потянет, поэтому в итоге защита всех данных оказывается одинаково дырявой.
Во-вторых, шум. Когда всё считается критичным, мониторинг выдаёт тысячи событий в день, аналитик привыкает и перестаёт замечать аномалии. По данным IBM Cost of a Data Breach 2024, средняя стоимость утечки достигла $4,88 млн, а время обнаружения инцидента — около 194 дней. Чем больше мусора в алертах, тем дольше вы ищете настоящий инцидент.
Классификация не защищает сама по себе. Она отвечает на вопрос «что именно мы защищаем и сколько готовы на это потратить»: 10% данных, которые при утечке убьют бизнес, получают 70% бюджета безопасности, а остальное — адекватный базовый уровень, а не «как получится».

Шаг 1. Инвентаризация: нельзя классифицировать то, чего вы не нашли
Классификация начинается не с политики, а с карты данных. Не знаете, где живут персональные данные и исходники, — любой класс, присвоенный на бумаге, останется бумагой. Пройдитесь по инфраструктуре и составьте реестр информационных активов: базы данных, файловые хранилища, почта, корпоративные мессенджеры, SaaS-сервисы, ноутбуки, бэкапы.
На каждый актив заполните минимум пять полей:
- владелец — конкретный человек из бизнеса, а не «отдел ИТ»;
- где хранится и в каком виде (СУБД, Excel, архив);
- кто имеет доступ и как он выдаётся;
- как данные обрабатываются: собираются, передаются, уничтожаются;
- срок жизни и количество копий.
Не забудьте про теневые данные: личные мессенджеры, сторонние облака, флешки. Сотрудник, который отправил клиентскую базу себе в Telegram, создал ещё одну копию вашего актива — и она тоже должна попасть в реестр и получить класс.
Инвентаризацию можно автоматизировать средствами data discovery — они сканируют хранилища и находят данные по сигнатурам: номера паспортов, ИНН, банковские карты, ключевые слова. Но даже ручной реестр в таблице, собранный за неделю опросов владельцев, лучше, чем ничего. Главное — зафиксировать, а не идеализировать.
Шаг 2. Критерии: по каким признакам присваивать класс
Реестр готов — теперь нужно отличить «просто важное» от «критичного». Единой формулы нет, но есть четыре рабочих критерия, покрывающих 90% случаев.
Правовые обязательства
Первое, что нельзя игнорировать, — требования регуляторов. Персональные данные по 152-ФЗ и Постановлению Правительства № 1119 уже имеют градацию: от категории ПДн зависит уровень защищённости. Отдельно стоят коммерческая тайна, банковская и врачебная тайна, PCI DSS для платёжных данных. Если данные попадают под регуляторику, минимальный класс вам уже задан — спорить с законом бессмысленно.
Ущерб по CIA
Для каждого актива оцените последствия по трём осям: конфиденциальность (данные утекли), целостность (данные изменены), доступность (данные недоступны). Оценка от 0 до 3 по каждой оси, сумма даёт класс. Пример:
- публичные маркетинговые материалы: 0/1/1 — сумма 2, базовый класс;
- клиентская база с ПДн: 3/2/2 — сумма 7, конфиденциальный;
- ключи доступа к платёжному шлюзу: 3/3/3 — сумма 9, критичный.
Цифры условные, но подход рабочий: он заставляет спорить о конкретике, а не о «ну это же важно».
Стоимость восстановления
Отдельно посчитайте, во сколько обойдётся восстановление данных из бэкапов или воссоздание с нуля. Для доступности это часто важнее утечки: три дня простоя интернет-магазина могут стоить дороже, чем публикация базы лояльности.
Жизненный цикл
Данные стареют. Контракт трёхлетней давности стоит копейки, а база клиентов растёт с каждым месяцем. Класс должен пересматриваться вместе с жизненным циклом, а не присваиваться один раз навсегда.
Шаг 3. Уровни классификации: сколько их нужно
Три-четыре уровня — оптимум. Десять уровней никто не поддержит: сотрудники перестанут их различать уже на третьем. Рабочий пример для типичной компании:
- Уровень 0 — общедоступный: пресс-релизы, публичные отчёты. Защита минимальная, доступ без ограничений;
- Уровень 1 — внутренний: оргструктура, регламенты, служебная переписка. Доступ — все сотрудники, защита базовая: пароли, антивирус, контроль внешних носителей;
- Уровень 2 — конфиденциальный: персональные данные, договоры, исходный код, коммерческая тайна. Доступ по ролям, шифрование, журналирование, запрет на вынос;
- Уровень 3 — ограниченный: ключи, токены, данные платёжных карт, бэкапы с ПДн, планы сделок. Разделение доступа, 2FA, усиленный мониторинг.
После присвоения класса введите маркировку: гриф в шапке документа, метка в свойствах файла, автоматическая пометка классификатором. Маркировка без enforcement бесполезна, но без неё enforcement невозможен: сотрудник должен видеть класс, чтобы не отправить конфиденциальное во «внутренней» переписке.
Кто назначает класс: владельцы данных, а не отдел ИБ
Самая частая ошибка — когда классы придумывает служба безопасности. ИБ не знает, сколько стоит клиентская база и какой договор завтра спасёт компанию. Класс назначает владелец данных — человек из бизнеса, который отвечает за актив и понимает его ценность. Роль ИБ — предложить меры защиты под класс и проверить внедрение.
Зафиксируйте зоны ответственности: владелец решает класс и пересматривает его, ИБ определяет технические меры, руководитель утверждает политику, сотрудники соблюдают маркировку. Политика классификации утверждается приказом — иначе это просто презентация.
Автоматизация: что реально работает, а что — маркетинг
На рынке есть инструменты data discovery и классификаторы, в том числе российские — SearchInform, InfoWatch, Solar Dozor. Они сканируют хранилища, находят данные по сигнатурам и ставят метки по вашим правилам. Это реально экономит недели ручной работы.
Но будьте честны: автоматический классификатор не понимает контекст. Он найдёт ИНН в тестовой базе и пометит её как ПДн, а договор с уникальными условиями без ключевых слов пропустит. Автоматика — это черновик для владельца данных, а не замена ему. И главное: класс должен управлять политиками — DLP, правами доступа, шифрованием. Классификация ради классификации, без enforcement, ничего не защищает.
Пять ошибок, которые убивают классификацию
- Классифицировали и забыли: данные меняются, активы появляются — пересматривайте классы минимум раз в год;
- Классифицируют документы, но не базы, бэкапы и логи: копия клиентской базы в Excel на ноутбуке маркетолога относится к тому же классу, что и оригинал в CRM;
- Слишком много уровней: если сотрудник не отличает уровень 5 от уровня 6, он выберет «попроще»;
- Класс назначает ИБ без бизнеса — получаются «важные для ИБ» данные вместо важных для компании;
- Маркировка без контроля: пометка «конфиденциально» без запрета отправки по почте и на флешки — просто наклейка.
Чек-лист: с чего начать в понедельник
- Составьте реестр информационных активов: хранилище, формат, владелец, доступ;
- Назначьте владельца данных на каждый актив — из бизнеса, с фамилией;
- Оцените каждый актив по CIA от 0 до 3 и правовым требованиям;
- Введите 3–4 уровня классификации с примерами и маркировкой;
- Утвердите политику классификации приказом и познакомьте с ней сотрудников;
- Подключите автоматическое обнаружение и маркировку данных;
- Свяжите класс с политиками DLP, доступа и шифрования;
- Назначьте дату пересмотра классов — через год или при крупных изменениях;
- Проверьте, что копии и бэкапы классифицированы вместе с оригиналами;
- Измеряйте результат: доля активов с классом и применёнными мерами защиты.
Классификация не сделает вас неуязвимыми — она сделает вас осознанными. Вы будете знать, что спасать в первую очередь, и не станете тратить последний миллион на защиту презентаций, пока клиентская база лежит в открытом доступе. Это самое честное, что может сделать ИБ в условиях ограниченного бюджета.