Данные без ФИО: когда набор сведений становится персональным

Персональные данные без ФИО - не противоречие, а обычная ситуация для большинства сайтов и CRM. Клиент оставил заявку, не указав имени, cookie-идентификатор закрепился за браузером, форма записи сохранила только телефон и время визита. Кажется логичным: раз имени нет, то и персональных данных нет. Это ошибка, за которую в 2026 году можно получить не предупреждение, а реальный штраф. Косвенно определяемое лицо - отдельная категория в законе, и она работает даже тогда, когда в базе нет ни одного поля Фамилия Имя Отчество.

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

Что закон называет персональными данными без имени

Определение в части 1 статьи 3 152-ФЗ построено не вокруг конкретного набора полей, а вокруг результата: персональные данные - это любая информация, относящаяся к прямо или косвенно определенному либо определяемому физическому лицу. Слово косвенно здесь ключевое. Закон не требует, чтобы данные прямо называли человека по имени. Достаточно, чтобы совокупность признаков позволяла его выделить из группы других людей.

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

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

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

Какие данные считаются персональными, если в них нет ФИО

Список того, какие данные считаются персональными без прямого указания имени, шире, чем кажется на старте. Полный перечень с примерами разобран в отдельном материале о том, что такое персональные данные, а здесь - подборка полей, которые чаще всего недооценивают именно из-за отсутствия ФИО:

• номер паспорта, СНИЛС или ИНН без указания фамилии - каждый из этих номеров сам по себе уникален и привязан к одному человеку в государственных реестрах;
• номер телефона и email - формально не содержат имени, но почти всегда позволяют выйти на конкретного человека через оператора связи или почтовый сервис;
• фотография лица без подписи - биометрический идентификатор, который распознает человека сам факт изображения, а не текст рядом с ним;
• государственный номер автомобиля вместе с местом обычной парковки - привязан к собственнику через базу ГИБДД и одновременно указывает на адрес;
• номер медицинской карты или страхового полиса - открывает доступ к истории болезни конкретного пациента;
• cookie-идентификатор и рекламный ID устройства - привязаны к одному браузеру или гаджету и накапливают историю поведения одного и того же человека;
• точная геолокация - координаты дома или рабочего места сужают круг до одной квартиры или кабинета;
• домашний адрес без имени владельца - в доме на несколько квартир адрес почти всегда указывает на конкретную семью, а не на анонимную точку на карте.

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

Как безобидные поля соединяются в идентификацию

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

Разберем на примере интернет-магазина. Номер заказа - просто порядковый счетчик, по нему одному никого не найти. Модель телефона - характеристика товара, таких телефонов проданы тысячи. Адрес доставки - географическая точка, по адресу живут разные люди в разное время. Но строка заказ номер 48213, iPhone 15 Pro, доставлен по адресу такому-то - это уже другая история. В доме на этот адрес живет ограниченное число семей, среди которых владелец именно этой модели телефона обычно один. Три безобидных поля вместе выделяют конкретного человека почти так же надежно, как ФИО в паспорте.

Похожая логика работает с временем и устройством. Отметка о посещении сайта в 23:47 сама по себе ничего не говорит. Отпечаток браузера - разрешение экрана, версия ОС, установленные шрифты - тоже не редкость. Но связка время визита плюс уникальный отпечаток устройства плюс город из настроек геолокации на практике почти всегда указывает на одного и того же человека при повторных визитах, даже если он ни разу не вводил email или имя.

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

Четвертый пример - деловая переписка. Адрес корпоративной почты вида order48@company.ru формально не содержит имени. Но время отправки писем, стиль подписи и IP отправителя, который совпадает изо дня в день, вместе указывают на одного и того же сотрудника за этим ящиком, даже если реального имени в переписке ни разу не встретилось.

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

IP-адрес, cookie и геолокация - отдельный случай

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

Cookie-идентификаторы и рекламные ID устройства работают по похожей логике. Сами по себе они выглядят как случайный набор символов, но их смысл - в постоянстве. Один и тот же ID закрепляется за одним браузером или устройством и накапливает историю посещений, покупок, поисковых запросов. Эта история со временем становится настолько характерной, что де-факто заменяет имя: рекламная система знает про владельца ID больше, чем знал бы сосед по подъезду.

Частичное решение - анонимизация. В счетчиках вроде Яндекс.Метрики есть настройка, которая усекает или хэширует IP-адрес перед сохранением, и правильная настройка анонимизации IP снижает юридические риски аналитики. Но анонимизация снижает риск, а не снимает его полностью: если рядом с обезличенным IP в той же системе аналитики хранится email из формы обратной связи или номер заказа, связь восстанавливается за секунды простым сопоставлением двух таблиц. Анонимизировать нужно не одно поле, а всю цепочку, через которую поля можно сопоставить друг с другом.

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

Что идентифицирует само по себе, а что только в связке

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

Правая колонка не догма - в спорной ситуации решает не таблица, а конкретный набор данных, которым располагает именно ваш оператор.

Общедоступные данные не освобождают от ФЗ-152

Частое заблуждение - если данные взяты из открытого источника: профиль в соцсети, сайт компании, публичная страница в ЕГРЮЛ, то закон об их обработке будто бы не распространяется. Разбор того, что на самом деле считается общедоступным источником персональных данных, показывает: общедоступность снимает только часть обязанностей, а не все сразу.

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

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

Отдельно стоит риск утечки такой собранной базы. Она формально составлена из открытых данных, но как единый файл представляет собой куда более серьезную ценность для мошенников, чем разрозненные публикации, и последствия при утечке считаются по тем же правилам, что и для любых других персональных данных - вплоть до оборотных штрафов и уголовной ответственности по статье 272.1 УК РФ, если утечка окажется достаточно масштабной.

Когда мнения расходятся: спорные случаи

Не все ситуации укладываются в однозначный ответ да или нет, и честнее сразу это признать, а не изображать уверенность там, где ее нет даже у регулятора.

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

Агрегированная статистика тоже спорная зона. Отчет вида в группе от 25 до 34 лет из города N совершено 340 заказов не идентифицирует никого, пока группа достаточно большая. Но для маленького населенного пункта или узкой ниши та же формулировка при уменьшении размера выборки до нескольких человек фактически превращается в идентификацию, и формальной границы, где заканчивается статистика и начинаются персональные данные, закон не устанавливает - это оценочная категория, и при проверке решение будет зависеть от конкретных цифр.

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

Где бизнес чаще всего теряет бдительность

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

Интернет-магазин. Форма быстрого заказа в один клик часто не просит имя - только телефон и адрес. Кажется, что раз имени нет, то и защищать особо нечего. На деле телефон и адрес доставки в связке с историей покупок - это полноценный профиль клиента, который подпадает под все требования 152-ФЗ, включая согласие и политику обработки.

Клиника. Онлайн-запись на прием иногда обходится без ФИО на первом шаге - только телефон, дата и специальность врача. Но специальность врача - это уже информация о состоянии здоровья, специальная категория персональных данных с более строгими требованиями к обработке, и отсутствие имени в форме эту категорию не отменяет.

Школа. Фотографии с мероприятий на сайте школы обычно публикуются без подписей с именами - только класс и год. Ребенка на фото легко узнают одноклассники и учителя, а вместе с указанием класса круг сужается до конкретного человека. Это тоже персональные данные несовершеннолетнего, требующие отдельного согласия родителей.

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

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

Самозанятый. Ведение клиентской базы в мессенджере или простой таблице кажется неформальным процессом без персональных данных, потому что контакт сохраняется как имя из телефонной книги, а не паспортные данные. Но это тоже персональные данные - имя из мессенджера, номер телефона и история заказов уже образуют полноценный профиль клиента, на который распространяются обязанности оператора.

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

Что делать, если данные без ФИО оказались персональными

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

1. Провести инвентаризацию всех полей, которые собирает сайт, CRM и внутренние таблицы - не только явные (ФИО, паспорт, телефон), но и косвенные: cookie ID, номер заказа, геометки, отпечаток устройства, табельные номера.
2. Проверить, может ли ваша компания технически связать разные поля в одну запись об одном человеке. Если может - весь набор полей нужно рассматривать как персональные данные, даже если по отдельности ни одно поле имени не содержит.
3. Убедиться, что для каждого такого набора есть правовое основание обработки - согласие, договор или другое законное основание, и что оно оформлено, а не подразумевается по умолчанию.
4. Обновить политику обработки персональных данных и форму согласия так, чтобы они описывали реальный набор собираемых полей, включая косвенные идентификаторы, а не только классический ФИО и телефон из шаблона пятилетней давности.
5. Свериться с полным перечнем обязанностей оператора - они действуют одинаково для прямых и косвенных персональных данных: сроки ответа на запросы субъекта, уведомление РКН, порядок хранения и уничтожения.
6. Не полагаться на общедоступность источника или отсутствие поля ФИО как на автоматическое освобождение от требований закона - оба довода в 2026 году не работают ни перед Роскомнадзором, ни перед судом.

Разобраться, какие именно поля на конкретном сайте и в конкретной CRM образуют персональные данные, проще с посторонним взглядом на формы, таблицы и интеграции, а не по общей инструкции из интернета. Универсального ответа для всех сайтов не существует - структура форм, состав CRM и способ хранения логов у каждого бизнеса свои, и оценивать нужно именно свой набор данных, а не общий список из статьи. Сайт 152fzpro.ru занимается доработкой сайтов и документов под требования 152-ФЗ и разбирает именно такие пограничные случаи - когда данные вроде бы обезличены, а на деле идентифицируют человека не хуже паспорта.