Поправки к 152-ФЗ по биометрии в 2026: что HR и финтех должны перенастроить в ИС
Новый порядок обработки биометрических ПДн по 152-ФЗ затронет HR и финтех уже сейчас. Разбираем, что нужно пересмотреть в информационных системах до вступления в силу.
Поправки к 152-ФЗ в части биометрических персональных данных и требований к локализации вступают в силу в 2026
В этом месяце вступают в силу поправки к 152-ФЗ, которые касаются биометрических персональных данных и требований к их обработке. Документ циркулировал в разных редакциях с прошлого года, и у операторов было время подготовиться - но по нашим наблюдениям, большинство не успело. Особенно это касается двух категорий заказчиков: HR-компаний с пропускными системами и лицевой идентификацией и финтеха с удалённой верификацией клиентов.
Мы занимаемся аудитом операторов ПДн и сейчас разбираем, что конкретно изменилось и что нужно сделать в информационных системах.
Что изменилось по существу
Поправки не переписывают 152-ФЗ целиком - они уточняют несколько блоков, которые давно вызывали вопросы.
Биометрия обособлена жёстче. Ранее биометрические ПДн были специальной категорией с повышенными требованиями, но граница между «обычным» фото в личном деле и биометрией, обрабатываемой для идентификации, была размытой. Теперь закон прямо разграничивает: биометрические данные, используемые для установления личности субъекта, - отдельный режим с отдельными требованиями к ИС, согласию и хранению. Фото в паспортных данных сотрудника и шаблон лица в системе контроля доступа - разные категории с разным правовым основанием.
Согласие на биометрию - только письменное и отзываемое с техническим механизмом. Устная форма и галочка в интерфейсе больше не работают. Оператор обязан обеспечить субъекту возможность отозвать согласие, причём это должно быть реализовано технически: отзыв - не просто запись в журнале, а реальное прекращение обработки и удаление биометрического шаблона в разумный срок. Что такое «разумный срок» - поправки определяют как не более 30 дней.
Локализация биометрических данных. Биометрические шаблоны (не исходные изображения, а именно шаблоны для идентификации) должны храниться исключительно на территории РФ. Для большинства российских операторов это и так было очевидно, но поправки закрывают сценарий, когда шаблоны вычислялись в облачном API иностранного вендора и кэшировались за рубежом.
Ограничение на передачу третьим лицам. Биометрические данные для идентификации нельзя передавать третьим лицам без отдельного явного согласия - даже в рамках группы компаний. Договор поручения на обработку ПДн недостаточен.
Где это бьёт больнее всего
В HR это пропускные системы с распознаванием лиц - их внедряли активно в 2023-2024 годах. Типичная архитектура: камера на входе, локальный сервер или облачный API для вычисления шаблона, СКУД, которая получает результат идентификации. Проблемы обычно в нескольких местах.
- Форма согласия. В большинстве случаев согласие на биометрию было вшито в трудовой договор или общее согласие на обработку ПДн - без явного указания на биометрию как отдельную категорию. Это нужно переделывать.
- Механизм отзыва. СКУД не умеет «удалить шаблон по запросу сотрудника» - это не функционал, который закладывается по умолчанию. Нужна доработка или замена.
- Обработчик шаблонов. Если API для идентификации - сторонний сервис (а таких много), нужно проверить, где он хранит шаблоны и есть ли договор поручения с явным указанием на биометрию.
В финтехе похожая история с удалённой верификацией клиентов при открытии счёта или оформлении кредита. Там биометрические данные часто передаются в Единую биометрическую систему (ЕБС/ГБД) или в сервисы банков-партнёров. Новый порядок требует пересмотра оснований для каждого из этих потоков.
Что нужно пересмотреть в ИС
Мы сейчас идём по этому чеклисту с несколькими заказчиками - для понимания масштаба задачи.
Инвентаризация систем с биометрией. Не документация - реальный опрос ИТ: где вычисляются шаблоны, где хранятся, куда передаются результаты. Часто оказывается, что шаблоны оседают в нескольких местах сразу: на локальном сервере СКУД, в логах API и в базе самого сервиса идентификации.
Ревизия согласий. Для каждой системы нужно понять, на каком основании обрабатываются биометрические данные. Если основание - согласие, смотрим форму: письменное ли оно, явно ли указана биометрия, есть ли механизм отзыва. Если нет - готовим новые формы и техническое решение для отзыва.
Технический механизм удаления шаблонов. Это самая трудоёмкая часть. Нужно не просто помечать запись как «отозванную» - нужно реальное удаление биометрического шаблона из всех мест хранения. Если СКУД или система верификации не умеют этого делать по API - либо доработка, либо замена вендора.
Договоры с обработчиками. Проверить все договоры поручения на обработку ПДн, где есть биометрия. Поручение должно явно называть биометрические данные и содержать ограничения на их передачу.
Реестр и уведомление. Если биометрические данные не выделены в уведомлении оператора как отдельный вид - обновить. Мы в марте писали о том, как РКН находит расхождения между реестровой записью и реальными системами - с биометрией цена такого расхождения выросла.
Что пока остаётся неясным
Поправки не дают чёткого ответа на несколько вопросов. Что считать биометрическим шаблоном - только математический вектор признаков или любой файл, из которого можно его вычислить? Как трактовать ситуацию, когда биометрию обрабатывает государственный орган в рамках межведомственного взаимодействия? Надеемся, что РКН даст разъяснения - но исходим из того, что их придётся ждать.
Для наших заказчиков ближайший практический шаг - инвентаризация систем с биометрией и ревизия форм согласия. Без этой картины разговор о соответствии абстрактный, а дедлайн уже наступил.