Реестр дата-центров в 2026 году: как проверить не название провайдера, а реальную площадку

Зачем разбираться, где физически стоят ваши серверы, если в договоре написано только имя вендора

С марта 2026 года в России действует официальный реестр центров обработки данных, который ведёт Минцифры на основании постановления Правительства №1932 от 28.11.2025 [8][9]. Дата-центр — это не сайт, не программа и не облачный сервис, а физическая инфраструктура, на которой такие сервисы работают [14]. Реестр фиксирует именно эту физическую инфраструктуру — здание, кадастровый номер, класс надёжности, электроснабжение [4], а не поставщика услуги. Для заказчика облака или колокейшн-услуги это повод разделить три разные вещи: юрлицо, с которым подписан договор; бренд, под которым продаётся сервис; и реальный ЦОД, где стоит оборудование и хранятся резервные копии. Ниже — как это проверить на практике, что реестр не покрывает и как оформить результат так, чтобы его можно было предъявить при продлении договора.

Кому и зачем это нужно

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

Повод для темы конкретный: операторы дата-центров уже отчитываются о включении своих площадок в реестр — например, «Атомдата» сообщила о регистрации дата-центров «Москва-2» и Xelent [6], а РТК-ЦОД — о включении флагманского дата-центра «Медведково-2» [5]. Пресс-релизы называют юрлицо и бренд площадки, но заказчику для проверки нужны более точные данные: адрес, кадастровый номер, реестровый номер записи — то, что реестр как раз фиксирует [4].

Что такое реестр ЦОД и чем он не является

Понятие «центр обработки данных» впервые закреплено в законе именно 244-ФЗ от 23.07.2025: это совокупность зданий, частей зданий или помещений с общим назначением, включающая инженерно-техническое обеспечение для размещения оборудования, которое обрабатывает и хранит данные [8]. Правила формирования и ведения реестра таких объектов утверждены отдельным постановлением — №1932 от 28.11.2025, а вести реестр поручено Минцифры [1][2]. Отдельные положения обоих актов вступили в силу с 1 марта 2026 года [3][5].

Важно понимать три ограничения по смыслу реестра.

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

Во-вторых, реестр ЦОД — это не реестр значимых объектов критической информационной инфраструктуры (КИИ). Тот реестр ведётся по 187-ФЗ, включает только объекты, которым присвоена категория значимости, и относится к системам безопасности, а не к зданиям [12]. Дата-центр может попадать в контур КИИ лишь тогда, когда на нём держатся государственные сервисы, платёжная инфраструктура или отраслевые диспетчерские системы — оценивается не тип ЦОДа, а последствия простоя [11].

В-третьих, это не реестр аттестованных площадок для хостинга ГИС и не замена аттестации по требованиям ФСТЭК (уровень защищённости, УЗ по 152-ФЗ, класс защищённости ГИС). Наличие записи в реестре ЦОД говорит о физическом объекте и его владельце, а не о том, что на нём аттестована конкретная информационная система заказчика.

Что фиксирует реестровая запись — и что из этого проверять

По правилам, утверждённым ПП №1932, запись состоит из двух блоков сведений [4]:

О самом ЦОД:

• адрес и кадастровый номер недвижимости;
• категория электроснабжения;
• документы, подтверждающие право собственности на объект;
• сведения о недвижимости — дата ввода в эксплуатацию, назначение помещений, площадь;
• возможность работы с ГосСОПКА;
• проектное число мест на стойках и технологическая мощность;
• класс надёжности.

О собственнике:

• для физлиц — ФИО, ИНН, ОГРНИП;
• для юрлиц — полное наименование, адрес, ОГРН.

Заявление на включение подаётся через портал госуслуг (с УНЭП) либо через сайт Минцифры (с УКЭП), рассматривается 5 рабочих дней, а сама запись подтверждается ежегодно — иначе в ней появляется отметка о том, что подтверждение не поступило [4]. Основания для исключения из реестра: заявление самого владельца, смерть или недееспособность физлица-владельца, ликвидация юрлица, а также выявленный факт майнинга на мощностях ЦОД — размещение майнинговой инфраструктуры прямо запрещено законом для ЦОД из реестра [4][8].

Доступ к сведениям реестра прямо ограничен кругом получателей: госорганы, суды, Центробанк, территориальные сетевые организации, системный оператор энергосистем, сами владельцы и операторы ЦОД [2]. Открытого публичного поиска по реестру, аналогичного порталу reestr.digital.gov.ru для российского ПО [13], в открытых источниках на момент подготовки материала не обнаружено. Практический вывод: заказчику, скорее всего, придётся запрашивать подтверждение записи не через самостоятельный публичный поиск, а напрямую у поставщика услуги — в виде выписки, номера записи или официального ответа Минцифры по запросу.

Как запросить у поставщика фактическую площадку размещения

Первый практический шаг — не верить бренду в маркетинговых материалах, а запросить у поставщика конкретный документ или набор данных:

1. Точный адрес и наименование ЦОД, где размещается инфраструктура заказчика (не юрлицо-владельца бренда, а именно объект).
2. Номер и дату записи в реестре ЦОД либо подтверждение, что заявление на включение подано и находится на рассмотрении.
3. Класс надёжности площадки и категорию электроснабжения — эти параметры входят в состав сведений реестра и напрямую влияют на доступность сервиса [4][7].
4. Указание, кто является собственником недвижимости ЦОД — сам поставщик услуги или третье лицо, у которого он арендует мощности.

Если поставщик работает через партнёрскую сеть или white-label модель, отдельно уточняйте, чей ЦОД фактически используется — договор часто заключается с одним юрлицом, а инфраструктура арендуется у другого владельца площадки.

Как сопоставить договор, продукт, регион и конкретный ЦОД

Даже когда поставщик назвал конкретный ЦОД, стоит свести данные в одну таблицу и сверить четыре элемента:

• договор — какой юрисдикции и какое юрлицо подписывает соглашение об оказании услуги;
• продукт — конкретный тарифный план или SLA, под который выделяются ресурсы (иногда более дешёвые тарифы физически размещаются на другой, менее защищённой площадке той же компании);
• заявленный регион — то, что указано в личном кабинете или консоли облака (например, «Москва» или «Северо-Запад»);
• конкретный ЦОД — реальный адрес и реестровая запись.

Расхождение в любой из этих точек — сигнал для уточнения у поставщика. Например, регион в консоли может быть общим («Россия», «Москва»), а не конкретной площадкой, при этом фактическое размещение может со временем меняться в рамках внутренней балансировки нагрузки провайдера — это нормальная практика, но заказчику стоит знать её условия заранее, а не постфактум.

Резервные копии и вторая площадка: отдельная проверка

Наличие записи в реестре по основной площадке ничего не говорит о том, где хранятся резервные копии. Здесь стоит отдельно уточнить у поставщика:

• находится ли резервная копия физически на другом объекте (и если да — тоже ли он в реестре ЦОД);
• не выгружаются ли бэкапы за пределы России — это уже вопрос не реестра ЦОД, а требований 242-ФЗ о локализации персональных данных, которые обязывают хранить и обрабатывать персональные данные россиян на территории РФ [15];
• как часто выполняется резервное копирование и кто отвечает за его целостность — сама возможность делать бэкапы в системах управления инфраструктурой входит в перечень требований к ЦОД для попадания в реестр, но это требование к возможности, а не к фактическому расписанию копирования конкретного заказчика [4];
• есть ли у поставщика вторая независимая площадка для аварийного восстановления или резервирование ограничено дублированием оборудования внутри одного здания.

Если у поставщика единственная площадка, а «резервирование» на деле означает второй ряд серверов в том же зале, это принципиально иной уровень отказоустойчивости, чем геораспределённая пара ЦОД — и в реестровой записи это напрямую не отражается: класс надёжности говорит про инженерную инфраструктуру конкретного объекта, а не про архитектуру резервирования у конкретного заказчика.

Как оценить резервирование, восстановление и доступность отдельно от реестра

Запись в реестре подтверждает физические параметры площадки, но не отвечает на три практических вопроса, которые важны именно для конкретного заказчика и конкретного сервиса:

• Резервирование. Сколько независимых площадок реально задействовано под сервис заказчика и по какой схеме — активно-активной или холодного резерва. Класс надёжности из реестра описывает инженерную инфраструктуру здания (электропитание, охлаждение), а не то, задублирован ли конкретно ваш сервис между двумя объектами.
• Восстановление. Какие у поставщика зафиксированы RTO (время восстановления) и RPO (допустимая потеря данных) именно для вашего тарифа, и когда в последний раз проводилось тестовое переключение на резервную площадку — регулярность таких тестов реестр не фиксирует и не проверяет.
• Доступность. Какой процент доступности (SLA) закреплён в договоре, как он считается (по факту простоя всей инфраструктуры или только вашего сервиса) и какая компенсация предусмотрена при его нарушении.

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

Что поставщик обязан сообщать при переносе сервиса и субподряде

Прямых норм именно в постановлении №1932, обязывающих поставщика услуги уведомлять заказчика о переезде между ЦОД или о привлечении субподрядчика, в открытых источниках по этой теме найти не удалось: правила реестра регулируют отношения владельца ЦОД и Минцифры, а не отношения поставщика услуги и его клиента. Это значит, что обязанность информировать заказчика о смене площадки или подключении субподрядной инфраструктуры нужно закреплять отдельно — в самом договоре или SLA, а не полагаться на факт существования реестра.

Разумный минимум для включения в договор или его продление:

• обязанность поставщика письменно уведомлять о переносе инфраструктуры заказчика на другой физический объект в согласованный срок (например, за 30 дней, кроме аварийных ситуаций);
• обязанность раскрывать, если часть инфраструктуры или резервного копирования передаётся субподрядчику, и называть конкретную площадку субподрядчика;
• право заказчика запросить актуальную реестровую запись или её номер по первому требованию, а не только при подписании договора.

Ограничения, ошибки и риски

• Ошибка «реестр = аттестация системы». Запись в реестре ЦОД подтверждает параметры здания и владельца, а не то, что конкретная информационная система заказчика соответствует требованиям по защите информации или аттестована для конкретного класса ГИС.
• Ошибка «раз ЦОД в реестре — резервная копия тоже там». Реестровая запись относится к площадке, а не к конкретному размещению данных заказчика на ней; резерв нужно проверять отдельно.
• Ошибка «нет обязанности — нет смысла проверять». Даже если для конкретного частного бизнеса включение поставщика в реестр не обязательно, сам факт наличия официальной регистрации — дополнительный источник проверяемых фактов (кадастровый номер, класс надёжности), которые иначе взять неоткуда.
• Риск смешения реестров. Реестр ЦОД, реестр значимых объектов КИИ и перечни площадок для хостинга государственных систем — разные механизмы с разными операторами и разными критериями [12]; путать их в закупочной документации может привести к формальным ошибкам техзадания.
• Риск устаревших данных у поставщика. Ежегодное подтверждение записи означает, что статус может измениться в течение года — стоит закладывать периодическую повторную проверку, а не разовую при подписании договора.

Как хранить результат: карточка размещения системы

Практический результат проверки удобно оформлять в виде карточки на каждую систему или контракт со следующими полями:

• поставщик услуги (юрлицо и бренд);
• фактический ЦОД (адрес, собственник объекта);
• номер и дата записи в реестре ЦОД (либо статус «заявление подано», либо «не проверялось»);
• расположение резервной копии и наличие второй независимой площадки;
• договорные гарантии по SLA, доступности и уведомлению о переносе/субподряде;
• дата последней проверки и дата следующей плановой сверки (рекомендуется — не реже раза в год, синхронно с ежегодным подтверждением записи в реестре).

Такую карточку разумно прикладывать к пакету документов при продлении договора или при запуске нового проекта — это заменяет устную договорённость письменной проверяемой историей.

Вывод

Реестр ЦОД — полезный, но узкий инструмент: он подтверждает физические параметры конкретного объекта и его владельца, а не безопасность или отказоустойчивость услуги, которую покупает заказчик. Наличие реестровой записи не означает обязанность любого частного бизнеса выбирать только включённые площадки, не заменяет аудит информационной безопасности и не совпадает с реестром значимых объектов КИИ или перечнями хостинга для государственных систем. Чтобы реестр реально помогал в закупке, его данные нужно сверять с договором, продуктом и фактическим размещением резервных копий, отдельно оценивать резервирование, восстановление и доступность, а результат — фиксировать в понятной карточке и обновлять при каждом продлении.

Источники

[1] pravo.gov.ru — Постановление Правительства РФ от 28.11.2025 № 1932 — http://publication.pravo.gov.ru/document/0001202511290019

[2] garant.ru — Обзор постановления № 1932 — https://www.garant.ru/products/ipo/prime/doc/413066761/

[3] iksmedia.ru — «Реестру ЦОДов быть!» — https://www.iksmedia.ru/articles/6073058-Reestru-CZODov-byt.html

[4] savecons.ru — Гайд по включению в реестр ЦОД Минцифры — https://savecons.ru/news/gayd-po-vklyucheniyu-v-reestr-tsod-mintsifry

[5] cnews.ru — «РТК-ЦОД вошёл в число первых участников реестра ЦОД Минцифры» — https://www.cnews.ru/news/top/2026-04-14_rtk-tsod_voshel_v_chislo_pervyh

[6] tadviser.ru — «Реестр дата-центров в России» — https://www.tadviser.ru/index.php/Продукт:Реестр_дата-центров_в_России [7] novostiitkanala.ru — «Отечественная классификация ЦОД» — https://www.novostiitkanala.ru/news/detail.php?ID=198042

[8] garant.ru — Обзор Федерального закона № 244-ФЗ — https://www.garant.ru/products/ipo/prime/doc/412278214/

[9] pravdaosro.ru — «Минцифры сформирует реестр ЦОД» — https://pravdaosro.ru/sro/law/mincifry-sformiruet-reestr-cod/

[10] habr.com — «Минцифры предложило создать реестр ЦОД» — https://habr.com/ru/post/952216

[11] blog.infra-tech.ru — «Объекты КИИ: категорирование, безопасность, значимость» — https://blog.infra-tech.ru/obekty-kii-kategorii-zashchita/

[12] consultant.ru — Статья 8, Федеральный закон № 187-ФЗ — https://www.consultant.ru/document/cons_doc_LAW_220885/b66a091e0e40a9d6e432750ee185d09a224b60d1/

[13] cdo-global.ru — «Реестр российского ПО Минцифры: как проверить и попасть» — https://cdo-global.ru/science/glossary/reestr-po-mincifry/

[14] sberbusiness.live — «Дата-центр (ЦОД): что это и как работает простым языком» — https://sberbusiness.live/publications/data-centr

[15] habr.com — О требованиях 242-ФЗ по локализации персональных данных — https://habr.com/en/articles/266689