Персональные данные в сервис-деске: как настроить поля, маскирование и хранение по российским требованиям

Практическое руководство для ИТ-директоров, администраторов helpdesk и специалистов по ИБ

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

Служба технической поддержки и сервис-деск давно перестали быть просто инструментом учёта сломавшихся принтеров. Сегодня helpdesk — это центральная точка сбора данных о сотрудниках и клиентах: ФИО, корпоративные email-адреса, номера телефонов, сведения о занимаемых должностях и подразделениях, а в ряде отраслей — данные о здоровье, финансовые реквизиты, номера удостоверений личности. Всё это появляется в полях заявок, во вложениях, в комментариях к тикетам и в теле переписки.

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

С 30 мая 2025 года штрафная среда принципиально изменилась: вступил в силу Федеральный закон № 420-ФЗ, который ввёл оборотные санкции и многократно увеличил размер фиксированных штрафов [4]. Роскомнадзор ведёт автоматический мониторинг 24/7, а в 2025 году зафиксировал 118 случаев компрометации баз персональных данных [5]. При этом треть всех утечек ПДн в мире происходит по внутренним случайным причинам — именно там, где процессы работы с данными не структурированы [5].

Эта статья — практическое руководство для тех, кто отвечает за настройку и эксплуатацию helpdesk-систем в российских компаниях. Материал будет полезен ИТ-директорам, администраторам ITSM-платформ, специалистам по информационной безопасности и DPO (ответственным за обработку персональных данных).

Часть 1. Регуляторный фундамент: что говорит 152-ФЗ о helpdesk

1.1. Helpdesk как ИСПДн: юридическая квалификация

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

Таким образом, helpdesk-система автоматически становится ИСПДн, как только в ней появляются данные, позволяющие идентифицировать физическое лицо. Это не только имя и фамилия — это также корпоративный email (если он содержит имя сотрудника), IP-адрес рабочей станции, должность в связке с ФИО, внутренний идентификатор пользователя [6].

Оператором ИСПДн в данном контексте является компания, которая эксплуатирует helpdesk-платформу. Если helpdesk предоставляется по SaaS-модели от иностранного поставщика — это немедленно создаёт проблему трансграничной передачи и локализации данных [1]. С 1 июля 2025 года вступили в силу изменения, прямо запрещающие первичное размещение баз данных с ПДн россиян за рубежом [7].

1.2. Принципы обработки ПДн применительно к helpdesk

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

1. Принцип законности и справедливости — основание для обработки ПДн в тикетах должно быть явно определено. Как правило, это исполнение трудового договора (для внутреннего helpdesk), договора оказания услуг (для внешней поддержки) или законный интерес оператора.
2. Принцип ограничения цели — данные, собранные для решения заявки по настройке принтера, не могут быть использованы в маркетинговых целях или переданы в HR-аналитику без отдельного основания.
3. Принцип минимизации данных — helpdesk не должен запрашивать больше информации, чем необходимо для решения конкретного типа обращения. Номер паспорта не нужен для заявки о замене картриджа. Домашний адрес не нужен для сброса пароля.
4. Принцип точности — неактуальные данные (уволенные сотрудники, изменившиеся контакты) должны обновляться или удаляться.
5. Принцип ограничения хранения — закрытый тикет не должен храниться бессрочно. После достижения цели обработки (решения проблемы) данные подлежат уничтожению или обезличиванию [10].

Эти принципы полностью соответствуют концепции data minimisation, закреплённой в статье 5(1)(c) европейского GDPR [11]. Таким образом, российские требования не менее строги, чем западные стандарты, а в ряде аспектов — строже.

1.3. Новые штрафы 2025 года: масштаб ответственности

С 30 мая 2025 года действует принципиально новая шкала штрафов (Федеральный закон № 420-ФЗ от 30.11.2024) [4]:

1. За утечку ПДн от 1 000 до 10 000 физлиц — от 3 до 5 млн рублей.
2. За утечку ПДн от 10 000 до 100 000 физлиц — от 5 до 10 млн рублей.
3. За утечку ПДн более 100 000 физлиц — от 10 до 15 млн рублей.
4. За утечку биометрических данных — от 15 до 20 млн рублей.
5. За повторную утечку — оборотный штраф от 1% до 3% годовой выручки, но не менее 20 млн и не более 500 млн рублей.
6. За неуведомление Роскомнадзора об утечке в 24-часовой срок — от 1 до 3 млн рублей для организаций [4].

Дополнительно с декабря 2024 года действует статья 272.1 УК РФ, предусматривающая уголовную ответственность вплоть до 10 лет лишения свободы за незаконные операции с ПДн [2]. Это напрямую касается ситуаций, когда агент поддержки экспортирует базу тикетов или передаёт данные клиентов третьим лицам.

По данным Роскомнадзора, за 2024 год в России зафиксировано 135 утечек персональных данных, большинство из которых произошло в сфере торговли и услуг [3]. В 2025 году выявлено 118 случаев компрометации, в результате которых скомпрометировано более 52 млн записей [5].

Часть 2. Инвентаризация ПДн в helpdesk: что и где хранится

2.1. Карта персональных данных в типичной helpdesk-системе

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

Данные инициатора заявки (заявителя):

1. ФИО — прямой идентификатор.
2. Корпоративный email — идентификатор, позволяющий установить личность.
3. Номер телефона (мобильный или рабочий).
4. Подразделение и должность.
5. Местонахождение (офис, город, страна).
6. Логин в корпоративных системах (Active Directory, LDAP).

Данные, попадающие в тело тикета:

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

Технические метаданные:

1. IP-адрес рабочей станции заявителя.
2. Идентификатор устройства.
3. Временные метки действий.

Данные исполнителей:

1. ФИО агентов поддержки, участвовавших в обработке тикета.
2. Комментарии агентов, которые могут содержать ПДн.

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

2.2. Классификация полей по чувствительности

Для целей управления рисками рекомендуется разделить все поля helpdesk-системы на три группы.

Группа А — прямые идентификаторы (высокий риск):

1. ФИО, адрес электронной почты, телефон.
2. Номер паспорта, СНИЛС, ИНН (если присутствуют).
3. Биометрические данные (фото в профиле).

Группа Б — косвенные идентификаторы (средний риск):

1. Подразделение + должность + дата (комбинация может идентифицировать человека).
2. IP-адрес в связке с другими данными.
3. Корпоративный идентификатор (логин, табельный номер).

Группа В — нейтральные поля (низкий риск):

1. Тип заявки, приоритет, статус.
2. Категория оборудования или ПО.
3. Время создания тикета (без привязки к конкретному лицу).

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

Часть 3. Принцип минимизации: как правильно спроектировать поля заявки

3.1. Методология «цель — поля»

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

Регулятор ICO (Великобритания) в своём руководстве по принципу data minimisation формулирует это так: «вы должны идентифицировать минимальное количество персональных данных, необходимых для достижения вашей цели. Держите ровно столько — не больше» [11]. Российский 152-ФЗ содержит аналогичное требование в статье 5.

Практическая методология «цель — поля» выглядит следующим образом:

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

3.2. Примеры правильной и неправильной конфигурации полей

Тип заявки: «Сброс пароля Active Directory».

Обоснованные поля:

1. Логин пользователя — необходим для поиска учётной записи.
2. Email для получения временного пароля — необходим для уведомления.
3. Подразделение — для маршрутизации к ответственной команде.

Избыточные поля (нарушение принципа минимизации):

1. Домашний телефон.
2. Дата рождения.
3. Должность с детализацией до грейда.

Тип заявки: «HR-запрос на оформление командировки».

Обоснованные поля:

1. ФИО сотрудника.
2. Табельный номер.
3. Даты командировки и пункт назначения.

Избыточные поля:

1. Паспортные данные — для внутренней системы не нужны, оформляются отдельно в HR-системе.
2. Семейное положение.

Тип заявки: «Запрос на предоставление доступа к системе».

Обоснованные поля:

1. ФИО сотрудника.
2. Название системы и требуемый уровень доступа.
3. Обоснование (должность, проект).
4. Согласование руководителя.

Избыточные поля:

1. Личный email.
2. Адрес проживания.

3.3. Особые категории ПДн: повышенная осторожность

Статья 10 152-ФЗ выделяет особые категории персональных данных: сведения о состоянии здоровья, расовой или национальной принадлежности, политических взглядах, религиозных убеждениях, судимостях [9]. Их обработка допускается только в строго ограниченных случаях и требует отдельного согласия.

В контексте helpdesk эти данные могут появиться, например, в заявках HR-service-desk (запрос больничного листа, оформление инвалидности, учёт религиозных праздников для графика отпусков). Для таких типов заявок необходимо:

1. Создать отдельную, изолированную очередь с максимально ограниченным доступом.
2. Не отображать содержимое таких тикетов в общих дашбордах и отчётах.
3. Обеспечить отдельное хранение в базе данных с усиленным шифрованием.
4. Установить сокращённые сроки хранения.

Часть 4. Маскирование персональных данных в helpdesk

4.1. Что такое маскирование и чем оно отличается от обезличивания

Важно разграничить два понятия, которые нередко смешивают.

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

Маскирование (data masking) — более широкое понятие, включающее как статическое (постоянное изменение копии данных), так и динамическое (скрытие данных «на лету» при выводе пользователю без изменения хранилища) маскирование [13]. Маскирование не обязательно приводит к обезличиванию — часть методов оставляет данные реидентифицируемыми при наличии ключа.

С 1 сентября 2025 года введена новая статья 13.1 в 152-ФЗ, закрепляющая регуляторный статус обезличенных данных [12]. Роскомнадзор получил полномочия контролировать соответствие применяемых методов обезличивания утверждённым нормативам.

4.2. Сценарии применения маскирования в helpdesk

Сценарий 1: Передача данных подрядчикам и внешней технической поддержке.

Если вы передаёте тикеты внешнему исполнителю для анализа или устранения инцидента, это является передачей ПДн третьему лицу. Требования:

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

Сценарий 2: Тестовые и staging-среды.

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

1. Никогда не использовать реальные ПДн в dev/test/staging-окружениях.
2. Применять генерацию синтетических данных или статическое маскирование.

Сценарий 3: Аналитика и отчётность.

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

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

Сценарий 4: Интеграции с внешними системами.

Если helpdesk интегрирован с CRM, ERP, мессенджерами или внешними API, каждая такая интеграция — потенциальный канал несанкционированного распространения ПДн. Требования:

1. Проинвентаризировать все интеграции и документировать, какие поля передаются.
2. Для каждой интеграции применять принцип «передавать только то, что запрашивается и не больше».
3. С 1 июля 2025 года особое внимание уделять интеграциям с зарубежными SaaS-сервисами [7].

4.3. Технические методы маскирования

Для реализации маскирования в helpdesk-системах применяются следующие технические подходы:

1. Замена (substitution) — замена реального значения на синтетическое того же формата (имя «Иван Петров» → «Алексей Смирнов»). Сохраняет структуру данных и позволяет работать с аналитикой.
2. Символьное маскирование (character masking) — частичное скрытие значения (телефон «+7 916 123-45-67» → «+7 916 XXX-XX-XX»). Применяется для динамического маскирования при отображении в интерфейсе.
3. Токенизация — замена реального значения на уникальный токен, который хранится в защищённом хранилище и позволяет восстановить исходное значение при наличии прав. Применяется там, где нужна возможность разэскалации при необходимости.
4. Псевдонимизация (pseudonymisation) — замена прямых идентификаторов на условные, при хранении ключа соответствия отдельно. Псевдонимизированные данные остаются персональными по 152-ФЗ, но несут меньший риск в случае утечки.
5. Агрегирование — вместо хранения данных о конкретных лицах хранятся только статистические агрегаты (количество тикетов по категориям, среднее время решения по отделам).

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

Часть 5. Разграничение доступа к ПДн в helpdesk

5.1. Ролевая модель как обязательный контроль

Статья 19 152-ФЗ требует обеспечить разграничение доступа к персональным данным [9]. Применительно к helpdesk это означает обязательное внедрение ролевой модели доступа (RBAC — Role-Based Access Control).

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

Типовые роли для helpdesk:

1. Агент первой линии поддержки — видит имя заявителя, тему тикета, описание проблемы. Не видит историю предыдущих обращений по персональным вопросам, не имеет доступа к закрытым тикетам других команд.
2. Агент второй/третьей линии — расширенный доступ в рамках своей компетенции. Может видеть технические детали, но не данные HR-категории.
3. Аналитик — доступ к статистике и отчётам, но только к обезличенным или агрегированным данным.
4. Администратор helpdesk — полный доступ к настройкам системы, но его действия должны логироваться.
5. Аудитор (ответственный за ПДн / DPO) — доступ к реестру полей, логам изменений, отчётам о нарушениях. Доступ к сырым ПДн — только при проведении расследований и с документированием.

5.2. Практические рекомендации по настройке доступа

Разграничение на уровне полей:

1. В большинстве зрелых helpdesk-систем (ITSM 365, SimpleOne, 1С:ITSM, Jira Service Management) можно настроить видимость отдельных полей в зависимости от роли пользователя [6, 15].
2. Поля с прямыми идентификаторами (телефон, email) должны быть скрыты для ролей, которым они не нужны для работы.
3. Вложения и скриншоты следует ограничивать по доступу отдельно от текстовых полей.

Разграничение на уровне очередей:

1. Тикеты по HR-вопросам, медицинским запросам, запросам на уровне руководства должны находиться в изолированных очередях с ограниченным кругом исполнителей.
2. Автоматическая маршрутизация должна учитывать категорию тикета и назначать только тех агентов, которые прошли соответствующий инструктаж по ПДн.

Логирование и мониторинг:

1. Все действия с тикетами, содержащими ПДн (просмотр, экспорт, изменение, удаление), должны журналироваться с указанием пользователя, времени и характера действия.
2. Экспорт тикетов в файлы (Excel, CSV, PDF) — операция повышенного риска, должна требовать дополнительной авторизации и логироваться.

5.3. Проблема Jira и облачных систем: кейс с публичными проектами

Исследование, опубликованное в материалах Anti-Malware.ru [15], описывает характерную проблему: из-за неправильной настройки параметров видимости в Jira Service Management проекты с персональными данными становились публично доступными в интернете. Аналогичная история произошла с данными Google, NASA и ООН — из-за ошибки конфигурации в открытом доступе оказались 26 ГБ персональных данных [16].

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

Для российских компаний дополнительная проблема — использование облачных версий зарубежных helpdesk-систем с 1 июля 2025 года противоречит требованиям локализации данных [7].

Часть 6. Сроки хранения данных в тикетах и порядок удаления

6.1. Правовое регулирование сроков хранения

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

Статья 21 152-ФЗ устанавливает конкретные процессуальные сроки:

1. 30 дней — на уничтожение ПДн, цель обработки которых достигнута.
2. 30 дней — на удаление данных, согласие на обработку которых отозвано.
3. 10 дней — на удаление при выявлении нарушений принципов обработки.
4. 7 дней — при обоснованном требовании субъекта об уничтожении данных [10].

Применительно к helpdesk это означает следующее: если заявка закрыта и цель её обработки (решение технической проблемы) достигнута, хранить персональные данные заявителя в полном объёме нет оснований. Максимальный практический срок хранения персонализированных тикетов определяется сроком исковой давности (3 года по общему правилу ГК РФ) плюс разумный запас.

Исключение — тикеты, связанные с трудовыми отношениями: кадровые документы хранятся согласно Приказу Росархива № 236 от 20.12.2019, минимальный срок для большинства документов по личному составу — 50 лет.

6.2. Практическая политика хранения для helpdesk

Рекомендуемая политика хранения данных в helpdesk-системе:

1. Открытые и активные тикеты — данные хранятся в полном объёме с применением необходимых мер защиты.
2. Закрытые ИТ-тикеты (инциденты, запросы на обслуживание) — персональные данные заявителя маскируются или обезличиваются через 90–180 дней после закрытия. Техническая история тикета может храниться дольше в обезличенном виде.
3. HR-тикеты — хранятся в соответствии со сроками архивного хранения кадровых документов. Требуют особого режима хранения и доступа.
4. Тикеты с особыми категориями ПДн (здоровье, финансы) — минимальные сроки хранения, максимальные меры защиты, отдельная база данных.
5. Журналы аудита и логи действий — могут храниться дольше (как правило, 1–3 года), но в обезличенном виде или с маскированием ПДн.

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

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

6.3. Право на удаление: как helpdesk должен его обеспечить

С принятием поправок к 152-ФЗ в 2022–2025 годах субъект ПДн получил усиленное право требовать прекращения обработки своих данных [10]. В контексте helpdesk это означает: если бывший сотрудник или клиент направил запрос на удаление своих данных, оператор обязан в течение 10 рабочих дней либо удалить данные из всех систем (включая helpdesk), либо предоставить обоснование для отказа.

Для корректного исполнения этого права helpdesk-система должна поддерживать:

1. Поиск по субъекту ПДн — возможность быстро найти все тикеты, связанные с конкретным физическим лицом.
2. Массовое обезличивание или удаление — применение операции ко всем найденным записям.
3. Документирование операции — запись факта выполнения запроса с датой и объёмом данных.
4. Уведомление смежных систем — если тикет создал записи в связанных системах (CRM, мониторинг), они также должны быть обработаны [8].

Часть 7. Практический чек-лист: 25 шагов к compliant helpdesk

Шаг 1. Инвентаризация и классификация

1. Составить реестр всех полей helpdesk-системы с указанием типа данных (ПДн / не ПДн) и категории (А/Б/В по приведённой классификации).
2. Проверить, какие поля являются обязательными, какие — опциональными.
3. Для каждого типа заявки задокументировать цель обработки ПДн и обоснование необходимости каждого поля.
4. Включить helpdesk-систему в реестр информационных систем персональных данных организации и уведомить Роскомнадзор при необходимости.

Шаг 2. Минимизация

1. Удалить или сделать необязательными поля, которые не требуются для решения конкретного типа заявки.
2. Настроить разные формы заявки для разных типов обращений — не использовать одну универсальную форму «с запасом полей».
3. Ограничить возможность агентов добавлять произвольные поля без согласования с DPO.

Шаг 3. Ролевая модель

1. Описать матрицу ролей и прав доступа (RBAC) для всех пользователей helpdesk.
2. Настроить видимость полей в зависимости от роли.
3. Ввести отдельные очереди для HR и других чувствительных категорий тикетов.
4. Обеспечить журналирование всех действий с ПДн.

Шаг 4. Маскирование

1. Определить сценарии, при которых ПДн покидают контур helpdesk-системы (экспорт, интеграции, тестовые среды, передача подрядчикам).
2. Для каждого сценария выбрать и реализовать соответствующий метод маскирования.
3. Никогда не использовать реальные данные в тестовых и staging-окружениях.

Шаг 5. Хранение и удаление

1. Разработать и утвердить политику хранения данных в helpdesk с конкретными сроками для каждой категории тикетов.
2. Настроить автоматическое обезличивание закрытых тикетов через заданный период.
3. Реализовать механизм исполнения запросов субъектов на удаление/обезличивание данных.
4. Ввести квартальный аудит соответствия фактических сроков хранения задекларированным.

Шаг 6. Интеграции и облако

1. Проинвентаризировать все интеграции helpdesk с внешними системами, перечислить передаваемые поля.
2. Проверить локализацию данных: если helpdesk работает через облако, убедиться, что ПДн хранятся на серверах в РФ [7].
3. Заключить договоры поручения обработки ПДн со всеми внешними поставщиками, имеющими доступ к данным.

Шаг 7. Организационные меры

1. Провести инструктаж агентов поддержки по правилам работы с ПДн, задокументировать.
2. Разработать и ввести регламент реагирования на инциденты (в том числе 24-часовое уведомление РКН).
3. Назначить ответственного за обработку ПДн в helpdesk с документально закреплёнными полномочиями.
4. Ежегодно проводить внешний или внутренний аудит helpdesk на предмет соответствия требованиям 152-ФЗ.

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

Ошибка 1: «У нас только корпоративные данные, это не ПДн»

Корпоративный email сотрудника — это персональные данные, поскольку позволяет идентифицировать конкретное физическое лицо. Это прямо подтверждается судебной практикой и позицией регуляторов [9]. Аргумент «у нас только данные сотрудников, а не клиентов» не освобождает от требований 152-ФЗ.

Ошибка 2: Одна универсальная форма заявки

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

Ошибка 3: Хранение закрытых тикетов бессрочно

Это одна из наиболее распространённых проблем. База тикетов годами растёт, содержит данные уволившихся сотрудников и ушедших клиентов. Всё это — нарушение принципа ограничения хранения и создаёт огромную поверхность риска при утечке [10].

Ошибка 4: Неконтролируемый экспорт тикетов

Агент экспортирует список тикетов в Excel для составления отчёта — и в его ноутбуке оказывается неконтролируемая копия базы ПДн. По данным компании СерчИнформ, 55% уголовных дел об утечках данных в России связаны с действиями сотрудников [5].

Ошибка 5: Игнорирование интеграций

Helpdesk интегрирован с мессенджером (например, Telegram-бот для подачи заявок) или с внешней CRM — и данные из тикетов автоматически утекают в системы без надлежащего правового основания и мер защиты. С учётом ограничений 2025 года на использование иностранных сервисов это также создаёт риск нарушения требований локализации [7].

Ошибка 6: Тестирование на реальных данных

Распространённая практика — скопировать продуктивную базу в тестовую среду, чтобы «разработчики могли нормально тестировать». Результат: неконтролируемая копия ПДн с ослабленными мерами защиты [13].

Ошибка 7: Отсутствие процедуры реагирования на инциденты

С 30 мая 2025 года организация обязана уведомить Роскомнадзор о произошедшей утечке ПДн в течение 24 часов [4]. Если процедура не отработана заранее, компания нарушит этот срок и получит дополнительный штраф в 1–3 млн рублей.

Часть 9. Кейсы и реальные примеры

Кейс 1: Утечка через неправильно настроенную Jira (2019)

В 2019 году исследователи обнаружили, что из-за ошибок конфигурации в Jira Service Desk в открытом доступе оказались данные Google, NASA, ООН и других организаций. Утечка произошла не из-за взлома, а из-за неверной настройки прав доступа к проектам [16]. В открытый доступ попали 26 ГБ персональных данных.

Урок: настройка видимости проектов и полей — это критическая операция безопасности, которая требует регулярного аудита, а не только первоначальной настройки при внедрении.

Кейс 2: РЖД и Почта России — первые штрафы за утечки

В 2025 году среди шести организаций, получивших штрафы за утечки ПДн, оказались РЖД и Почта России — по 150 тыс. рублей [5]. Это были штрафы по старому закону (до вступления в силу № 420-ФЗ). По новым нормам, действующим с 30 мая 2025 года, аналогичные инциденты влекут санкции в десятки раз больше.

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

Кейс 3: Автоматические проверки РКН

В 2025 году Роскомнадзор выявил около 84% нарушений во время автоматического мониторинга — без проведения плановых или внеплановых проверок [1]. Это означает, что «мы небольшая компания, до нас не дойдут» — уже не работающий аргумент. Регулятор выявляет нарушения в режиме реального времени.

Часть 10. Тренды и будущее регулирования

10.1. Ужесточение надзора продолжается

Согласно Распоряжению Правительства от 14.08.2025 № 2207-р, регуляторы должны представить предложения об увеличении срока давности по административным делам о нарушении 152-ФЗ и дополнительном усилении ответственности [2]. В III квартале 2027 года ожидаются изменения в КоАП, которые ещё более ужесточат санкции.

10.2. Обязательная передача обезличенных данных в ГИС

С 1 сентября 2025 года операторы обязаны передавать обезличенные персональные данные в государственную информационную систему по требованию Минцифры (Федеральный закон № 233-ФЗ от 08.08.2024) [12]. Это создаёт новый стимул для качественного обезличивания данных в корпоративных системах, включая helpdesk.

10.3. Privacy by design как стандарт

Международная тенденция состоит в том, что принципы privacy by design (встраивание защиты ПДн в проектирование систем с самого начала) становятся нормой, а не исключением. Рекомендация ICO по data minimisation [11] и требования статьи 25 GDPR [17] формируют единый подход: защита данных должна быть встроена в процессы и системы, а не добавляться как «заплатка» постфактум.

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

10.4. Автоматизация контроля ПДн

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

Что делать дальше

Управление персональными данными в helpdesk — это не разовый проект, а непрерывный процесс. ИТ-ландшафт постоянно меняется: появляются новые интеграции, создаются новые типы заявок, меняются роли сотрудников. Каждое такое изменение потенциально создаёт новый риск в сфере ПДн.

Три главных вывода из этой статьи:

1. Начните с инвентаризации — прежде чем что-то защищать, нужно понять, что у вас есть. Составьте карту всех полей helpdesk-системы, классифицируйте данные, задокументируйте цели обработки.
2. Минимизация — самый эффективный способ снизить риски. Данные, которые вы не собираете, нельзя потерять. Пересмотрите формы заявок и удалите всё лишнее.
3. Непрерывный мониторинг важнее периодического аудита. Еженедельный аудит раз в квартал не обнаружит новое поле в базе данных, которое появилось после последнего обновления системы.

Новые штрафы и уголовная ответственность 2025 года превращают несоблюдение требований по ПДн из юридической формальности в реальный операционный риск для любой организации — независимо от её размера.

О платформе «Пятый фактор»

Одной из актуальных проблем, которую описывает эта статья — отсутствие единой, актуальной картины того, где и какие персональные данные хранятся в корпоративных системах. Helpdesk — лишь одна из десятков систем, которые накапливают ПДн. Рядом с ней — CRM, 1С, Active Directory, почта, файловые хранилища, облачные сервисы.

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

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

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

Для helpdesk-систем, которые являются одним из наиболее динамичных источников ПДн в компании, этот подход особенно актуален: платформа видит появление новых полей в БД и новых интеграций сразу, а не через квартал при следующем плановом аудите.

Источники

[1] Klerk.ru — «152-ФЗ о персональных данных: требования закона для бизнеса в 2026 году» — https://www.klerk.ru/blogs/roskom24/674017/

[2] Klerk.ru — «Закон о персональных данных: что нас ждет в 2026 году» — https://www.klerk.ru/blogs/fedresurs/680031/

[3] Habr.com — «В первой половине 2025 года РКН выявил 35 фактов утечек персональных данных» — https://habr.com/ru/news/924602/

[4] Habr.com — «Роскомнадзор ужесточил штрафы за персданные: 300 тысяч за неуведомление, миллион за утечку» — https://habr.com/ru/companies/moysklad/articles/994568/

[5] ComNews.ru — «В 2025 г. шесть компаний получили штрафы за утечки — в 2026 г. штрафов будет больше» — https://www.comnews.ru/content/243497/2026-01-29/2026-w05/1008/2025-g-shest-kompaniy-poluchili-shtrafy-za-utechki-2026-g-shtrafov-budet-bolshe

[6] ITSM365 — «Политика в отношении обработки персональных данных ITSM 365» — https://itsm365.com/privacy/

[7] Business.ru — «152-ФЗ о персональных данных в 2025–2026 годах» — https://www.business.ru/article/5705-152-fz-o-personalnyh-dannyh-gg

[8] Gendalf.ru — «Как запрашивать персональные данные на сайте» — https://gendalf.ru/news/marketing/kak-zaprashivat-personalnye-dannye-na-sa/

[9] Consultant.ru — «Федеральный закон от 27.07.2006 № 152-ФЗ "О персональных данных"» (актуальная редакция) — https://www.consultant.ru/document/cons_doc_LAW_61801/

[10] Consultant.ru — «Статья 21. Обязанности оператора по уточнению, блокированию и уничтожению персональных данных» — https://www.consultant.ru/document/cons_doc_LAW_61801/d3fe43a7c415353b17faab255bc0de92bea127da/

[11] ICO.org.uk — «Principle (c): Data minimisation» — https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/data-protection-principles/a-guide-to-the-data-protection-principles/data-minimisation/

[12] Law.ru — «Обезличивание персональных данных: новые правила с 1 сентября 2025 года» — https://www.law.ru/article/28041-obezlichivanie-personalnyh-dannyh-novye-pravila-s-1-sentyabrya-2025-goda

[13] OvalEdge.com — «Data Masking Techniques Explained: Methods, Compliance & Best Practices» — https://www.ovaledge.com/blog/data-masking-techniques

[14] Uplab.ru — «Ролевая модель разграничения прав» — https://www.uplab.ru/blog/rolevaya-model-razgranicheniya-prav/

[15] Anti-malware.ru — «Как настройки конфиденциальности сливают ваши данные (на примере Atlassian Jira и Trello)» — https://www.anti-malware.ru/analytics/Threats_Analysis/How-privacy-settings-leak-your-data

[16] CNews.ru — «Из-за неправильных настроек Jira в сеть утекли данные Google, НАСА и ООН» — https://safe.cnews.ru/news/top/2019-08-05_vnutrennie_dannye_googleoon_i_nasa_okazalis

[17] GDPR-info.eu — «Art. 5 GDPR – Principles relating to processing of personal data» — https://gdpr-info.eu/art-5-gdpr/

[18] Selectel.ru — «Обезличивание персональных данных: цели, методы, схема» — https://selectel.ru/blog/personal-data-anonymization/

[19] Data-sec.ru — «Сроки уничтожения персональных данных по 152 ФЗ» — https://data-sec.ru/personal-data/destruction-deadline/

[20] Codeby.net — «ФЗ-152, GDPR, PCI DSS: техгайд по комплаенсу для IT» — https://codeby.net/threads/fz-152-gdpr-pci-dss-prakticheskii-modul-po-komplayensu-dlya-tekhnarei.91593/