IP-адрес устройства - число, которое сервер сайта видит при каждом обращении посетителя: при открытии страницы, отправке формы или клике по кнопке в мессенджере. Вопрос, является ли ip адрес персональными данными, встает у каждого, кто настраивает аналитику, антифрод-систему или просто открывает access.log хостинга и видит там строчки вида 91.235.213.44. Короткий ответ: в большинстве практических ситуаций да, ip адрес персональные данные, хотя прямой формулировки с таким текстом в законе нет, а позиция судов не всегда единообразна.
Определения ip адрес 152 фз отдельно не дает: статья 3 закона называет персональными данными любую информацию, которая относится к прямо или косвенно определенному физическому лицу. Сам по себе IP - просто набор цифр. Но в связке с логами сервера, личным кабинетом, номером заказа или cookie-файлом он почти всегда позволяет вычислить конкретного человека. Поэтому логи сервера персональные данные включают наравне с телефонами, почтой и ФИО - и обрабатывать их приходится по тем же правилам.
Что говорит закон о персональных данных
Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных» ни разу не упоминает IP-адрес напрямую. В статье 3 дано общее определение: персональные данные - любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу. Формулировка рассчитана на любые новые виды данных, которые появятся после принятия закона, и IP-адрес в этот список укладывается естественно, хотя в 2006 году о нем вряд ли думали отдельно.
Ключевое слово в определении - «определяемому». Закон не требует, чтобы данные сразу называли имя человека. Достаточно, чтобы с их помощью человека можно было идентифицировать - напрямую или через дополнительную информацию, которой располагает оператор или к которой у него есть доступ. Если сайт хранит IP вместе с email из формы заявки, номером заказа или логином личного кабинета, связка почти всегда позволяет выйти на конкретного человека. Отдельно взятый IP без такой связки идентифицирует слабее, и именно здесь начинаются расхождения в практике.
Отдельный нюанс - сайт становится оператором персональных данных не в момент, когда на нем появляется форма заявки или личный кабинет, а раньше, в момент запуска. Само наличие access.log с IP-адресами посетителей уже означает обработку персональных данных в понимании закона, даже если сайт представляет собой одностраничник без единой формы. Разница только в объеме обязанностей: сайту с логами и без форм проще соблюдать требования, но полностью выйти из-под действия 152-ФЗ не получится, пока сайт технически доступен в интернете и логирует обращения.
Позиция Роскомнадзора
Роскомнадзор в разъяснениях и в практике проверок последовательно относит IP-адрес к персональным данным, если он обрабатывается вместе с другой информацией о посетителе сайта - через CRM, форму заявки, личный кабинет или систему учета заказов. Логика простая: раз с помощью IP и других сведений сайта можно связать конкретное действие с конкретным человеком, IP работает как идентификатор наравне с email или телефоном.
На практике это значит, что оператор персональных данных - компания или ИП, которые определяют, зачем и как обрабатываются данные посетителей сайта, - не может просто исключить IP-адреса из списка обрабатываемых сведений на том основании, что это «просто технический параметр». Если IP-адреса попадают в логи и системы сайта, в уведомлении в Роскомнадзор об обработке персональных данных их стоит указать как один из видов обрабатываемых сведений вместе с остальными категориями.
На выездных и документарных проверках инспекторы РКН обычно интересуются не абстрактным вопросом, обрабатывает ли сайт IP-адреса, а конкретными вещами: какая система аналитики стоит на сайте, включена ли в ней анонимизация, сколько хранятся логи хостинга и куда уходят данные из форм заявок. Ответ «мы не думали, что IP - это персональные данные» инспектора не устроит и юридически ничего не меняет: обязанности оператора возникают по факту обработки, а не по факту осознания этого факта владельцем сайта.
Что говорят суды
Судебная практика по IP-адресам менее однородна, чем позиция регулятора. Часть споров касается динамических адресов, которые провайдер назначает устройству временно и может передать другому абоненту через несколько часов. В таких делах суды иногда отмечают: сам по себе динамический IP без содействия провайдера не позволяет ответчику установить личность человека, а значит обработка такого адреса в отрыве от остальных данных не всегда требует того же режима, что обработка паспортных данных.
Другая часть дел - о защите чести и достоинства, о доступе к перепискам, о блокировке аккаунтов за нарушения - решается иначе: суды исходят из того, что если оператор сайта технически может, например через регистрацию, платеж или сопоставление с личным кабинетом, связать IP с конкретным человеком, адрес входит в состав его персональных данных. Похожий подход встречается и в зарубежной практике: динамический IP признают персональными данными, если у оператора есть законная возможность обратиться к провайдеру и деанонимизировать пользователя, даже когда сам оператор этой возможностью не пользуется.
Показательны споры о защите деловой репутации и об удалении негативных отзывов, когда истец просит суд обязать площадку раскрыть данные автора комментария. В таких делах площадки нередко ссылаются на то, что располагают только IP-адресом без имени и телефона - но суды все чаще требуют этот IP раскрыть или использовать его для установления личности через провайдера, то есть фактически обращаются с адресом как с персональными данными, которые можно и нужно связать с конкретным автором.
Для сайта на практике это означает одно: рассчитывать, что IP-адрес точно не признают персональными данными, рискованно. Осторожная позиция - обрабатывать IP по тем же правилам, что и остальные ПДн: с законным основанием, ограниченным сроком хранения и упоминанием в документах компании.
Ставки в этом вопросе выросли с 30 мая 2025 года, когда заработали оборотные штрафы за нарушения при обработке персональных данных, введенные Федеральным законом от 30.11.2024 № 420-ФЗ, а для утечек с тяжелыми последствиями появилась уголовная ответственность по статье 272.1 УК РФ. Если при проверке или разборе утечки выяснится, что компания не учитывала IP-адреса и логи сервера как персональные данные, это не освобождает от ответственности: штраф считают исходя из факта нарушения, а не из того, знал оператор о статусе этих данных или нет.
Статический и динамический IP - есть ли разница
Статический IP закреплен за устройством или сервером постоянно - его используют, например, корпоративные клиенты, серверы и часть выделенных линий. Такой адрес легче связать с конкретной организацией или человеком просто по факту постоянства: если один и тот же IP раз за разом появляется в логах вместе с одним и тем же аккаунтом, идентификация не требует особых усилий.
Динамический IP провайдер выдает устройству на сессию или на сутки, а затем может передать другому абоненту. Формально один и тот же адрес в разное время принадлежит разным людям. Это снижает риск идентификации по одному лишь IP, но не снимает его полностью: если сайт хранит IP вместе с меткой времени и привязывает запись к аккаунту или заказу, разница между статическим и динамическим адресом для целей 152-ФЗ практически стирается - оператор все равно получает связку, которая указывает на конкретного человека в конкретный момент.
Отдельный частный случай - офисные и публичные сети, где десятки или сотни человек выходят в интернет через один и тот же внешний IP благодаря NAT. Здесь один адрес физически соответствует не одному человеку, а целой группе, и связать конкретное действие с конкретным сотрудником по одному IP невозможно без дополнительных данных, например логов прокси-сервера внутри компании. Это не делает такой IP автоматически неперсональными данными, но снижает точность идентификации и стоит учитывать при оценке риска.
Вывод для практики простой: делить IP-адреса на «опасные статические» и «безопасные динамические» не стоит. Правильнее смотреть не на тип адреса, а на то, с чем он хранится рядом - с обезличенной статистикой посещений или с данными конкретного человека.
Логи веб-сервера: что там на самом деле хранится
Файл access.log или его аналог в панели хостинга есть у каждого сайта, даже если владелец никогда его не открывал. Стандартная строка лога содержит IP-адрес посетителя, дату и время запроса, адрес запрошенной страницы, код ответа сервера, referrer, то есть страницу, с которой пришел переход, и user-agent - строку с названием браузера и операционной системы. Ни один из этих параметров сайт специально не собирает: их пишет веб-сервер автоматически, по умолчанию, часто без участия владельца сайта в настройке.
Именно поэтому сайт становится оператором персональных данных в части логов сервера уже в момент запуска, а не тогда, когда на нем появляется форма заявки. Хостинг обычно хранит логи от нескольких дней до нескольких месяцев в зависимости от тарифа - точный срок стоит уточнить у провайдера, а не полагаться на предположения. Если срок нигде не зафиксирован, разумно исходить из принципа: логи не нужно хранить дольше, чем требуется для технической диагностики и разбора инцидентов, обычно это недели, а не годы.
На интернет-магазине логи чаще всего пригождаются при разборе неудачных платежей и жалоб на списание без заказа - сопоставление IP, времени и номера заказа помогает разобраться, что произошло. В клинике с личным кабинетом пациента или у репетитора с онлайн-журналом логи иногда становятся единственным способом понять, кто и когда заходил в учетную запись при подозрении на утечку.
У кадровика, который принимает резюме и обращения сотрудников через форму на внутреннем портале, логи входа в систему часто оказываются даже важнее самой формы: именно они показывают, кто и когда просматривал личное дело коллеги. У самозанятого с сайтом-визиткой без единой формы обратной связи логи тоже есть - их создает хостинг автоматически, и мысль «у меня же нет форм, значит нет персональных данных» здесь не работает: сама доступность сайта в интернете уже приводит к обработке IP-адресов посетителей.
Cookie-идентификаторы и связка с IP
Cookie-файл сам по себе тоже не имя и не паспорт, а строка символов, которую браузер хранит и отправляет обратно сайту при каждом визите. Проблема та же, что с IP: в отрыве от остальных данных cookie мало что говорит о человеке, но в связке с IP, user-agent и историей посещений превращается в довольно точный отпечаток устройства, по которому можно узнавать посетителя между визитами и даже между разными сайтами, если cookie принадлежит рекламной сети.
Здесь работает та же логика, что и с IP: чем больше параметров сайт хранит рядом друг с другом, тем выше шанс, что вся связка в целом подпадает под определение персональных данных, даже если каждый параметр отдельно выглядит безобидно. Правила согласия на cookies по ФЗ-152 логично рассматривать вместе с вопросом об IP, а не отдельно: и то и другое - данные, которые сайт получает автоматически при каждом визите, и решение по одному почти всегда тянет за собой решение по другому.
Разница между собственными, first-party, cookie сайта и cookie сторонних сервисов - рекламных сетей, виджетов чата, видеоплееров - тоже имеет значение. Первые обычно работают в интересах самого сайта и укладываются в логику законного интереса или технической необходимости. Вторые передают данные посетителя за пределы сайта третьей компании, и здесь без явного согласия обойтись сложнее: пользователь должен понимать, что его IP и cookie увидит не только сайт, на который он зашел, но и сторонний сервис.
С 1 сентября 2025 года, после изменений, внесенных Федеральным законом от 24.06.2025 № 156-ФЗ, согласие на обработку персональных данных оформляется отдельным документом, а не обычным пунктом внутри пользовательского соглашения или политики. Это касается и согласия на использование cookie и данных аналитики, если сайт решает оформлять его именно как согласие субъекта, а не полагаться на законный интерес оператора.
Аналитика и IP-адрес: что настроить
Практически любая система веб-аналитики получает IP-адрес посетителя, чтобы определить город, устройство и построить отчеты по источникам трафика. Вопрос в том, что происходит с адресом дальше: хранится ли он в исходном виде, усекается до подсети или заменяется хешем.
Яндекс.Метрика
У Яндекс.Метрики есть настройка анонимизации IP, которая заменяет последний октет адреса до сохранения статистики. Это снижает точность идентификации отдельного посетителя, но не превращает данные в полностью обезличенные: остальные параметры, такие как устройство, время визита и набор просмотренных страниц, все равно позволяют выделить уникального пользователя в рамках сессии. Настройку стоит включить в любом случае - это одна из немногих бесплатных мер, которая реально снижает объем обрабатываемых ПДн без потери полезной статистики. Отдельно стоит помнить про Вебвизор: запись сессий фиксирует не только IP, но и движения курсора и заполнение полей форм - это более чувствительный вид обработки, и его стоит упомянуть в политике отдельной строкой, а не рассчитывать, что общая формулировка про аналитику покроет и его.
Зарубежные системы аналитики
С зарубежными системами сложнее: помимо вопроса об IP там встает вопрос о том, куда физически передаются данные и не нарушает ли это требование хранить базы персональных данных россиян на территории РФ. Эта тема шире одного вопроса про IP-адрес, но начинается она с того же самого - с признания, что аналитика обрабатывает персональные данные, а не абстрактную статистику, и решение просто поставить счетчик на сайт всегда тянет за собой вопрос о том, где эти данные в итоге оказываются.
Антифрод и защита от ботов: нужно ли согласие на обработку IP
Блокировка по IP, ограничение частоты запросов, проверка на признаки бота при оформлении заказа - обычные механизмы защиты сайта, и почти все они завязаны на IP-адрес. Спрашивать отдельное согласие у каждого, кто пытается оформить сотый заказ за минуту, никто на практике не будет - закон этого и не требует.
Дело в том, что согласие субъекта - не единственное законное основание для обработки. Закон описывает случаи обработки персональных данных без согласия, и среди них - обработка, необходимая для исполнения договора с субъектом, и обработка в законных интересах оператора при условии, что она не нарушает права и свободы человека сильнее, чем это нужно для цели. Защита от мошеннических операций и от автоматических атак обычно укладывается в эту логику: цель - обезопасить сервис и добросовестных пользователей, а объем обрабатываемых данных ограничен тем, что нужно для проверки конкретного запроса.
Границу задает не факт обработки IP, а то, что оператор делает с этим адресом дальше. Если IP используют только для решения пропустить или заблокировать запрос и не сохраняют надолго - риск минимален. Если же на основе IP строят долгосрочный профиль поведения конкретного человека - это уже другая по масштабу история, и здесь стоит отдельно продумать основание и срок хранения.
На практике разумный ориентир - хранить сырые данные антифрод-системы, список заблокированных IP и счетчики попыток, не дольше нескольких недель, а для долгосрочной статистики оставлять уже агрегированные, обезличенные цифры: сколько запросов заблокировано за месяц, а не какой конкретно IP и когда пытался оформить заказ.
Что требует согласия, а что нет
Однозначного перечня закон не дает, но по сложившейся практике и логике 152-ФЗ можно ориентироваться на такую разбивку. Она не заменяет юридическую оценку конкретной ситуации, но помогает быстро понять, в какую сторону смотреть.
| Ситуация | Нужно ли отдельное согласие | Комментарий |
|---|---|---|
| Логи сервера (access.log), хранение несколько недель для диагностики | Обычно нет | Законный интерес и техническая необходимость, стоит упомянуть в политике обработки ПДн |
| Яндекс.Метрика или Google Analytics с анонимизацией IP | Прямого требования нет, но риск выше, если ничего не сказано | Указать в политике и в уведомлении о cookies, что сайт использует аналитику |
| Антифрод-система: блокировка по IP без сохранения истории конкретного человека | Обычно нет | Законный интерес оператора, объем данных минимальный |
| CRM или личный кабинет: IP хранится вместе с ФИО, телефоном и историей заказов | Да, как часть общего согласия на обработку ПДн | IP входит в общий массив данных о клиенте |
| Передача IP и cookie рекламным сетям для ретаргетинга | Да | Отдельная категория обработки, нужно согласие на передачу третьим лицам |
| Уведомление в Роскомнадзор об обработке ПДн | Согласие не требуется, но IP стоит указать среди обрабатываемых категорий | Помогает избежать вопросов при проверке |
Таблица - ориентир, а не исчерпывающий список: в спорных случаях, например при накоплении подробной истории посещений отдельного пользователя, стоит исходить из более осторожного варианта и закладывать в документы то основание, которое реально соответствует происходящему на сайте.
Важно различать обработку и простое прохождение данных через сервер. Если сайт использует внешний CDN или защиту от атак, например прокси перед сервером, IP-адрес посетителя технически проходит через инфраструктуру третьей стороны, прежде чем попасть на сайт. Это тоже обработка персональных данных, и такой поставщик инфраструктуры обычно выступает как отдельный оператор или обработчик, с которым имеет смысл посмотреть условия использования на предмет того, как он обращается с логами.
Что сделать на сайте прямо сейчас
Проверить обработку IP-адресов можно за один рабочий день, не переписывая всю политику обработки персональных данных с нуля. Ниже - порядок, с которого разумно начать, от простого технического шага до документов.
- Уточнить у хостинг-провайдера, сколько времени хранятся логи сервера, и сократить срок, если он больше нескольких месяцев без явной причины.
- Включить анонимизацию IP в Яндекс.Метрике и проверить аналогичную настройку в других системах аналитики, если они установлены на сайте.
- Добавить в политику обработки персональных данных пункт о том, что сайт обрабатывает IP-адреса через логи сервера и системы аналитики, с указанием цели.
- Проверить уведомление в Роскомнадзор: указаны ли там IP-адреса и cookie-идентификаторы среди обрабатываемых категорий данных.
- Отделить в документах антифрод-обработку - законный интерес, минимальный срок хранения - от обработки IP в связке с личным кабинетом или CRM, которая требует согласия как часть общего массива ПДн.
- Проверить, не передает ли сайт IP-адреса и cookie сторонним рекламным сетям без указания этого в согласии на обработку персональных данных.
Если самостоятельно разбираться с логами, аналитикой и формулировками политики некогда, 152fzpro.ru дорабатывает сайты и документы под эти требования: приводит в порядок политику обработки персональных данных, формы согласий и настройки аналитики применительно к тому, что реально происходит на конкретном сайте.
Частые вопросы
Является ли IP-адрес персональными данными по закону?
В большинстве практических ситуаций да, хотя прямой формулировки об этом в законе нет. Статья 3 закона относит к персональным данным любую информацию об определяемом человеке, а IP в связке с логами сервера, личным кабинетом или cookie почти всегда позволяет вычислить конкретного посетителя.
Нужно ли согласие на обработку IP-адресов из логов сервера?
Обычно нет. Хранение логов несколько недель для технической диагностики укладывается в законный интерес оператора и не требует отдельного согласия, но стоит упомянуть эту обработку в политике обработки персональных данных. Согласие нужно, когда IP хранится в связке с ФИО и историей заказов в CRM.
Есть ли разница между статическим и динамическим IP для закона о персональных данных?
Формально да, но на практике эта разница почти стирается. Динамический адрес провайдер выдает на сессию и может передать другому абоненту, что снижает риск идентификации, но если сайт хранит IP вместе с меткой времени и привязывает запись к аккаунту, связка все равно указывает на конкретного человека в конкретный момент.
Нужно ли указывать IP-адреса в уведомлении в Роскомнадзор?
Да, если IP-адреса попадают в логи и системы сайта, их стоит указать как один из видов обрабатываемых сведений вместе с остальными категориями данных. Позиция Роскомнадзора в том, что IP работает как идентификатор наравне с email или телефоном, если обрабатывается вместе с другой информацией о посетителе.