Классификация данных и метки документов: модель за 60 дней

Зачем вообще вводить метки и что хотим исправить

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

Метки решают несколько практичных задач.

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

Во-вторых, помогают навести порядок с доступами. Если у файла есть понятный уровень, проще настроить правила хранения, пересылки и печати.

В-третьих, уменьшают влияние обычных ошибок: «не тому отправил», «положил не в ту папку», «забыл поставить пароль», «переслал подрядчику старую версию».

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

Успех - не «все все пометили», а измеримые изменения: правил меньше, они понятнее, и ими реально пользуются. Через 60 дней стоит ожидать снижения ручных ошибок и роста доли документов, которые сотрудники маркируют без подсказок и споров.

Границы проекта на 60 дней лучше поставить заранее. За это время обычно успевают согласовать 3-5 уровней с простыми названиями, включить маркировку в 1-2 ключевых сценариях (например, почта и офисные файлы), запустить пилот на одной функции и одном типе данных, настроить базовый контроль и отчетность для ИБ.

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

Начинать логичнее с команд и документов, где цена ошибки выше. Чаще всего это финансы, юристы, HR, закупки, проектные офисы, а также подразделения, которые работают с данными клиентов и пациентов. В организациях с регулированием (госсектор, банки, медицина, образование) эффект заметен быстрее: требования к доступу и хранению обычно уже есть, но они не подкреплены удобными правилами в инструментах.

Метки документов простыми словами: что это и как работает

Метка документа - это понятное имя, которое вы присваиваете файлу или письму, чтобы система знала, как с ним обращаться. Например: «Публично», «Внутренне», «Конфиденциально», «Строго конфиденциально». Метка имеет смысл только тогда, когда она меняет поведение системы, а не просто отображается как надпись.

Похожие термины часто путают. Удобно разделять так:

• Классификация - решение, к какому уровню относится информация (по смыслу и риску).
• Метка - выбранный уровень, закрепленный за конкретным файлом, письмом или сообщением.
• Политика - правила, что делать с объектами с этой меткой (например, можно ли пересылать наружу).
• Шифрование - защита, чтобы содержимое открывали только разрешенные люди.
• DLP (предотвращение утечек) - контроль попыток отправить или вынести данные, с блокировкой или предупреждением.

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

Разметка бывает ручная и автоматическая. Ручная - когда сотрудник выбирает метку сам (идеально, если система подсказывает и не заставляет долго думать). Автоматическая - когда система предлагает или ставит метку по признакам: тип документа, шаблон, наличие ИИН/номера договора, ключевые слова, медданные и т.д.

Пример: бухгалтер отправляет отчет подрядчику. Если отчет помечен как «Внутренне», политика может предупредить при отправке на внешнюю почту. Если «Строго конфиденциально» - запретить пересылку и включить шифрование. Тогда метка становится инструментом безопасности и управляемости, а не формальностью.

Как выбрать модель меток: уровни, названия, логика

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

Для старта обычно хватает 3-5 уровней. Меньше - сложно различать риски, больше - тяжело помнить и применять. Самый понятный вариант - «лестница» от открытого к чувствительному.

Пример, который легко объяснить на коротком вводном обучении:

• Публично (можно публиковать вне компании)
• Внутренне (для сотрудников и подрядчиков по договору)
• Конфиденциально (для ограниченного круга, есть риск ущерба)
• Строго конфиденциально (критично: финансы, персональные данные, ключевые проекты)

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

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

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

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

Если вы работаете в регулируемых отраслях (госорганы, финансы, здравоохранение), полезно согласовать модель с ИБ и юристами до пилота. Интеграторы вроде GSE.kz часто помогают провести такую сверку быстро, без лишних уровней и сложных формулировок.

Роли и ответственность: кто за что отвечает

Метки работают только тогда, когда ясно, кто принимает решения и кто поддерживает систему ежедневно. Иначе проект быстро превращается в спор между отделами и длинные переписки.

Базовые роли и их зона ответственности

Обычно хватает 5-6 ролей, но с четкими границами.

Владелец данных (data owner) в бизнесе решает, насколько информация чувствительная и кому она реально нужна для работы. ИБ задает требования защиты (шифрование, ограничения пересылки, контроль общего доступа) и следит, чтобы правила были выполнимы. ИТ настраивает инструменты (например, Microsoft Purview или аналог), шаблоны, политики и интеграции, а также отвечает за стабильность.

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

Чтобы не усложнять, закрепите простую схему:

• Утверждает модель меток: ИБ и юридический блок, финальное слово - за руководителем по рискам/ИБ или уполномоченным комитетом.
• Определяет смысл меток (что означает каждая): владельцы данных в бизнесе.
• Внедряет и поддерживает технически: ИТ.
• Обучает и напоминает правила: HR и ИБ.
• Инициирует изменения: любой владелец данных через понятную заявку.

Кто решает спорные случаи

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

Рабочая практика такая: первая линия (сотрудник или руководитель) выбирает метку по короткому правилу. Если сомневается - эскалирует владельцу данных. Если владелец данных не уверен - решение принимает связка ИБ и юристов (иногда с финдиректором для финансовых документов).

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

Поддержка сотрудников: куда писать и сколько ждать

Если поддержки нет, люди начинают ставить метки наугад или избегают их.

Сделайте один канал для вопросов (например, сервис-деск) и договоритесь о сроках: быстрый ответ на простой вопрос в течение рабочего дня, сложные случаи с проверкой у ИБ и юристов - за 2-3 рабочих дня. ИТ ведет короткие инструкции, ИБ и владельцы данных пополняют базу примеров: «договор с поставщиком», «результаты обследований», «зарплатные ведомости», «проектная документация».

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

UX для сотрудников: чтобы метки не мешали работать

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

Первое правило: сократите набор меток, которые видит конкретный человек. Даже если у вас 10 уровней, большинству ролей нужны 3-4 варианта. Остальное лучше держать в правилах и исключениях, а не в интерфейсе.

Подсказки: когда выбирать метку и почему

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

Подсказка должна отвечать на два вопроса простыми словами: «что это меняет» и «почему мне это показали». Хорошая подсказка короткая: «В документе есть ИИН и данные сотрудника. Рекомендуем: Конфиденциально (персональные данные)». Плохая - длинный текст с выдержками из политики.

Настройки по умолчанию и автоподсказки без шума

Большую часть проблем решают разумные значения по умолчанию. Например, для HR метка по умолчанию может быть «Внутренне» или «Конфиденциально», а для маркетинга - «Публично» или «Внутренне». То же касается типов документов: договор, счет, медкарта, служебная записка.

Чтобы авторазметка не раздражала, настройте ее как помощника:

• Автопредложение вместо принудительной метки там, где возможны ошибки.
• Более высокий порог уверенности для чувствительных уровней.
• Кнопка «Почему?» с коротким объяснением (1-2 причины).
• Возможность исправить метку за пару кликов, без заявок.
• Исключения для шаблонов и системных документов, чтобы не было постоянных всплывающих окон.

Пример: бухгалтер сохраняет договор с контрагентом и банковскими реквизитами. Система предлагает «Конфиденциально (финансы)» и показывает причину: найден ИИН/БИН и номер счета. Если это черновик без реальных данных, сотрудник выбирает «Внутренне» и продолжает работу, а вы получаете сигнал для донастройки правила.

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

Пошаговый план внедрения на 60 дней

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

Недели 1-2: подготовка и черновик правил

В первую неделю соберите инвентаризацию: какие типы данных у вас есть (договоры, счета, персональные данные, техдокументация, переписка), где они живут (почта, сетевые папки, SharePoint/файловые сервисы), кто владелец. Проведите 6-10 коротких интервью по 20 минут с владельцами данных. Вопрос простой: какие документы чаще всего «утекают» не туда или теряются, и где сотрудники чаще всего боятся ошибиться.

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

Недели 3-8: пилот, обучение, масштабирование

Недели 3-4 посвятите пилоту в одной функции, где много чувствительных документов (часто финансы или HR). Выберите 20-30 «эталонных» документов и договоритесь, какие метки должны стоять. В пилоте проверяйте не теорию, а поведение: где люди путаются, где правила мешают закрывать задачи.

Неделя 5 - короткое обучение. Вместо одного большого вебинара лучше 3-4 сессии по 25 минут и памятки на реальных кейсах: «как отправить счет подрядчику», «как поделиться резюме с руководителем», «как выгрузить отчет для аудитора». Добавьте один канал для вопросов и быстрых ответов.

Недели 6-7 - расширение на 2-3 подразделения и настройка исключений. Исключения должны быть редкими и документированными, иначе они быстро становятся нормой. Типовой пример: закупки часто обмениваются файлами с поставщиками, и там важны понятные условия внешнего обмена.

На неделе 8 зафиксируйте то, что работает, и оформите следующую волну.

К 60-му дню полезно иметь: простую модель меток, 2-3 проверенных правила, инструкции на 1 страницу, список исключений и владельцев. Плюс договоренности, кто утверждает изменения, кто отвечает за обучение и кто принимает обратную связь. И отдельный план продолжения: какие типы данных и подразделения идут следующими, что улучшаете по итогам пилота.

Microsoft Purview и аналоги: как сравнить без лишней теории

Microsoft Purview обычно выбирают, когда у вас уже есть Microsoft 365 и нужна единая политика для документов, почты и совместной работы. Тогда метки, правила DLP и отчеты живут в одном месте, а пользователям не нужно привыкать ко второму интерфейсу.

Сравнивая Purview с аналогами, держитесь практики: где именно будут применяться метки и кто это будет поддерживать. Важно, чтобы решение закрывало основные каналы и давало понятные отчеты для контроля прогресса.

Что стоит сравнивать в первую очередь:

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

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

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

Перед покупкой и масштабированием проверьте решение на пилоте по 5 сценариям:

• Пользователь создает документ «Внутренне» и отправляет его внешнему адресату.
• Финансовый файл с персональными данными попадает в общий ресурс и должен автоматически получить метку.
• Сотрудник пытается снизить уровень метки, а система должна объяснить причину и зафиксировать действие.
• Руководитель просит исключение для проекта, и вы проверяете, как оно оформляется и контролируется.
• ИБ получает недельный отчет, по которому ясно, что исправлять и кого обучать.

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

Проверяемые показатели результата через 60 дней

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

Начните с простого: измеряйте только пилотные команды и только выбранные хранилища (например, почта и OneDrive/SharePoint или сетевые папки). Так вы сравниваете одно и то же каждый период.

5 цифр для руководства (и для проверки через 90 дней)

1. Охват маркировки: доля документов/писем в пилоте с любой меткой. Формула: помеченные / все созданные (или измененные) за период. Реалистичная цель на 60 дней для активных команд - 60-80%.

2. Качество меток: доля исправлений (понижений/повышений) от всех помеченных. Отдельно фиксируйте, кто исправил: сотрудник, руководитель, админ. Если исправлений больше 10-15%, названия или подсказки, скорее всего, непонятны.

3. Поведение без напоминаний: доля пользователей, которые ставят метку в момент создания/отправки без ручных напоминаний. Практичный прокси-показатель: сколько людей применили метку хотя бы 5 раз за неделю.

4. Риск и предотвращение: сколько раз политика сработала (блокировка, предупреждение, запрос обоснования) и сколько было реальных инцидентов (отправили не туда, открыли доступ «всем», попытались вынести данные). Важно разделять «политика сработала» и «ущерб случился».

5. Стабильность процесса: среднее время реакции на запрос по метке (например, «почему заблокировало») и число обращений в поддержку на 100 пользователей. Это показывает, стала ли маркировка привычной, а не раздражающей.

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

Как оформить отчет на 1 страницу

Соберите 5 показателей выше, добавьте сравнение «30 дней vs 60 дней» и по одному выводу на каждый: что меняем в UX, что меняем в правилах, что оставляем как есть. Тогда отчет можно повторить через 90 дней и увидеть динамику, а не разовую активность.

Типичные ошибки и ловушки при запуске

Самая частая проблема - начать с красивой схемы и закончить тем, что никто не понимает, какую метку ставить и зачем.

Ошибка 1: слишком много уровней и непонятные названия

Если у вас 8-12 уровней и названия вроде «Уровень 3B» или «Внутренний расширенный», люди будут угадывать. Часть документов получит «на всякий случай» самый строгий уровень, а часть останется без метки.

Практичнее стартовать с 3-4 уровней, которые понятны без долгого обучения: «Публично», «Внутренне», «Конфиденциально», «Строго конфиденциально». Название должно подсказывать действие: можно ли пересылать, можно ли хранить в общем доступе, кому можно показывать.

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

Проект с лозунгом «разметим все» обычно тонет в деталях. Сильнее работает выбор 2-3 приоритетных потоков, где риск и ценность очевидны: договоры и счета, кадровые документы, коммерческие предложения. В госсекторе и медицине часто отдельно выделяют документы с персональными данными.

Чтобы не расползаться, используйте простой фильтр: что чаще всего утекает или пересылается не туда; что критично для регуляторики и проверок; что создается каждый день и реально может быть размечено; где можно быстро показать пользу (меньше ошибок, меньше ручных согласований).

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

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

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

Ошибка 4: штрафной тон и давление

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

Ошибка 5: нет процесса обновления, метки устаревают

Через квартал меняются процессы, появляются новые шаблоны, внедряются новые системы, и модель перестает совпадать с реальностью. С самого начала задайте ритм пересмотра: раз в 4-8 недель короткая встреча с решениями по изменениям и списком «что добавить, что убрать, что переименовать». Это дешевле, чем потом переделывать весь проект.

Короткий чек-лист и следующие шаги

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

Быстрый чек-лист готовности

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

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

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

Проверьте пилот на приземленность. Выберите 5-7 реальных сценариев вместо абстрактного «все документы». Например: договор с поставщиком, счет, HR-справка, презентация для клиента, выгрузка из CRM, отчет для регулятора.

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

Следующие шаги

1. Согласуйте финальную версию меток и правил на пилот (3-5 меток, без «зоопарка»).

2. Утвердите владельцев данных и процесс исключений: кто может менять метку и в каких случаях.

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

4. Через 2 недели соберите обратную связь и поправьте то, что мешает: названия меток, подсказки, настройки автоприменения, обучение.

Если нужна помощь с настройкой Microsoft Purview или выбором альтернатив, обучением и сопровождением пилота, это часто удобнее делать с интегратором. Например, GSE.kz (gse.kz) как производитель и системный интегратор в Казахстане помогает увязать модель меток с реальными процессами, а затем настроить политики и отчетность так, чтобы результат можно было измерить через те же 60 дней.