GDPR vs 152-ФЗ: что общего и где различия для ITSM-систем

Краткое сравнение

Локализация — главное расхождение

Самое принципиальное отличие — требование локализации в 152-ФЗ (статья 18 ч.5). Первичная база, в которой ПДн граждан РФ собираются и обновляются, должна находиться на серверах в РФ.

На практике это означает:

• SaaS, который собирает ПДн пользователей из РФ, обязан иметь продакшен-БД в дата-центре в РФ.
• Зарубежные облака (AWS Frankfurt, Google Cloud Belgium) — нельзя, даже если данные шифрованы.
• Российские облака с регистрацией оператора в Реестре — да: Yandex Cloud, VK Cloud, Selectel, MTС Cloud.

Для ITSM это означает, что мультитенантный SaaS с серверами «глобально» не пройдёт. Либо российская инфраструктура, либо on-premise деплоймент у клиента в РФ. TIQQET, как и большинство российских ITSM, идёт по on-premise + российские облака.

GDPR такого требования не предъявляет — данные могут лежать где угодно, но трансфер в страны без «adequate decision» (вне whitelist Еврокомиссии) требует SCC (Standard Contractual Clauses) или BCR (Binding Corporate Rules). Россия в whitelist не входит.

Согласие на обработку

Обе нормы требуют явного согласия, но смысл различается:

• 152-ФЗ: согласие — это «формальный документ». Образец Роскомнадзора, подпись (физическая или электронная). Можно дать «общее» на широкий перечень целей, если они перечислены. Отзыв — письменное заявление.
• GDPR: согласие должно быть granular — отдельно по каждой цели. Маркетинг, аналитика, профилирование — каждое со своим чекбоксом. Чекбоксы по умолчанию галочкой = нарушение. Отзыв — должен быть «as easy as giving» (одна кнопка).

В UI helpdesk это значит:

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

Права субъекта данных

Оба закона дают пользователю права, но с разной полнотой:

Для ITSM-системы это значит обязательное наличие в админке экспорта всех данных по пользователю (для DSR), функции «удалить аккаунт» и audit log изменений в данных пользователя.

Утечки и уведомления

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

152-ФЗ: Поправки 2022 г. ввели обязательное уведомление Роскомнадзора в течение 24 часов с момента обнаружения утечки. В уведомлении: какие данные пострадали, число субъектов, предпринимаемые меры. Через 72 часа — повторное уведомление с уточнёнными данными расследования.

GDPR: Уведомление DPA — в течение 72 часов. Если утечка несёт high risk для прав субъектов — отдельное уведомление каждому субъекту, без отлагательства.

На практике 24 часа в РФ — это очень короткое окно. У системы должен быть:

• Audit log на всё, что касается ПДн (доступы, изменения, экспорты)
• Мониторинг аномалий доступа (массовый экспорт, unusual hours)
• Готовый шаблон уведомления для Роскомнадзора
• Дежурный DPO (или ответственный) 24/7

Если работаете на оба рынка

Дешевле сделать продукт «GDPR-by-default» — он автоматически удовлетворяет 152-ФЗ в большинстве пунктов (GDPR строже почти везде). Исключения:

1. Локализация: для российских клиентов — отдельный российский деплоймент. SaaS «один на всех» не подойдёт.
2. Срок уведомления: 24 часа vs 72 часа. Готовьтесь к российскому регламенту.
3. Согласия: в РФ оформлять Согласие в форме, утверждённой Роскомнадзором (или близкой к ней).
4. Уведомление Роскомнадзора об операторе: до начала обработки. В GDPR такого нет.

Технические требования к ITSM-системе на оба рынка:

• Audit log на ПДн (кто, когда, что смотрел/менял)
• Экспорт всех данных по пользователю (DSR в обе стороны)
• Удаление аккаунта с soft-delete + cron жёсткого удаления через 30/90 дней
• Granular permissions на доступ к ПДн (privacy mask для не-операторов)
• Согласия с историей (когда дано, когда отозвано, формулировка на момент дачи)
• Шифрование at-rest и in-transit
• Логи доступа к БД с ПДн отдельно — на холодное хранение