Разрешения на строительство в электронных реестрах: что изменить в системе управления проектами

Реестровая запись вместо бумаги — и новая нагрузка на PM-систему и СЭД застройщика

С 1 сентября 2026 года разрешение на строительство и разрешение на ввод объекта в эксплуатацию юридически существуют не как отдельный документ с печатью, а как запись в электронном реестре [1]. Постановление Правительства РФ от 25.05.2026 № 596 регламентирует ведение федеральных реестров — тех, что ведут уполномоченные федеральные органы, «Росатом» и «Роскосмос» [1]. Подавляющее большинство обычных разрешений — региональных и муниципальных — под это постановление не подпадает: они ведутся в региональных ГИСОГД по правилам, которые устанавливает каждый субъект РФ сам, и регион вправе отложить переход на новую модель до 1 сентября 2027 года [3]. Для системы управления проектами это означает одно: разрешение больше нельзя хранить как файл, который один раз загрузили и забыли. Нужна модель, которая различает объект, разрешение, реестровую запись, её статус, срок действия и подтверждающую выписку — и умеет их обновлять.

Почему это не абстрактная реформа, а рабочая проблема ваших систем

До сих пор разрешение на строительство было бумагой (позже — сканом бумаги): её получили, прикрепили к карточке проекта в СЭД или PM-системе, и на этом работа с документом заканчивалась. Актуальность подтверждалась печатью и подписью, а не тем, что происходит с документом дальше.

Реестровая модель ломает эту логику. Юридически значимым фактом становится не файл, а состояние записи в государственной информационной системе на текущий момент [1]. Запись может продлеваться, в неё может вноситься исправление, она может переходить в статус «архивный» — и всё это происходит без участия застройщика в самой системе управления проектами, если её специально не научили это отслеживать.

Для застройщиков, технических заказчиков, строительных компаний и разработчиков СЭД это значит: старые карточки «объект — прикреплённый PDF» перестают быть источником истины. Нужно перепроектировать, как в системе хранятся сведения о разрешении, кто их обновляет и как эти сведения используются при переходе проекта на следующий этап.

Как теперь устроено разрешение: от бумаги к реестровой записи

Что именно поменялось с 1 сентября 2026 года

Изменения запустил Федеральный закон от 31.07.2025 № 304-ФЗ, который дополнил Градостроительный кодекс РФ положениями о реестрах разрешений на строительство и на ввод объектов в эксплуатацию [4]. Постановление № 596 конкретизировало порядок для федерального уровня [1]:

• реестровая запись формируется в электронном виде и подписывается усиленной квалифицированной электронной подписью должностного лица уполномоченного органа [1];
• запись получает реестровый номер по формату Yxxx-xxxxx-xx/xxxxxxxx, который присваивается один раз и не может быть изменён или использован повторно [1];
• запись имеет статус «действует» или «архивный»; удаление записей не допускается в принципе [1];
• застройщика уведомляют о выдаче разрешения через портал госуслуг не позднее одного рабочего дня после внесения записи, направляя выписку из реестра [1].

Иными словами, подтверждением наличия разрешения выступает не документ с печатью, а сама реестровая запись, доступная для проверки [2].

Кого касается № 596, а кого — нет

Здесь стоит быть точным, потому что многие популярные пересказы этого не разделяют. Правила, утверждённые № 596, распространяются только на разрешения, которые выдают:

• уполномоченные федеральные органы исполнительной власти;
• госкорпорация «Росатом»;
• госкорпорация «Роскосмос» [1].

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

Все остальные разрешения — а это подавляющее большинство обычных РНС на жильё, коммерческую и промышленную недвижимость — выдают органы субъектов РФ и местного самоуправления. Порядок формирования и ведения этих реестров устанавливает не Правительство РФ, а высший исполнительный орган соответствующего субъекта РФ; ведутся они в региональной ГИСОГД, а не в федеральной части «Стройкомплекс.РФ» [3; 7]. Это разграничение закрепил Федеральный закон от 04.08.2026 № 299-ФЗ [3].

Практический вывод: нельзя проектировать интеграцию в PM-системе исходя из того, что «теперь все разрешения проверяются через один федеральный реестр по № 596». Для большинства проектов актуальным источником будет региональная ГИСОГД конкретного субъекта РФ, и правила работы с ней устанавливает не федеральное постановление, а региональный акт.

Почему у регионов может не быть единой даты перехода

Тот же № 299-ФЗ дал субъектам РФ право своим нормативным актом сохранить прежний, бумажный порядок оформления разрешений — по редакции статей 51, 51.1 и 55 ГрК РФ, действовавшей до 1 сентября 2026 года, — но не позднее 1 сентября 2027 года [3]. Решение принимает каждый регион самостоятельно; единой отсрочки для всей страны закон не вводит [3]. Разрешения, выданные в форме документа до 1 сентября 2026 года, продолжают действовать до истечения своего срока в любом случае [3].

Для застройщика или проектной организации, работающей в нескольких регионах, это означает необходимость отслеживать наличие такого регионального акта отдельно по каждой территории присутствия [3] — и, соответственно, закладывать это в справочник регионов внутри системы управления проектами, а не считать переход одномоментным для всей страны.

Российская специфика: два контура реестров

Чтобы не путать уровни, полезно развести две системы, которые внешне называются похоже.

Федеральный контур — «Стройкомплекс.РФ»

Единая государственная информационная система обеспечения градостроительной деятельности «Стройкомплекс.РФ» объединяет реестр требований в области инженерных изысканий и строительства, классификатор строительной информации, а также данные о разрешениях, которые выдают федеральные органы, «Росатом» и «Роскосмос» [7]. Доступ к общедоступным сведениям этой части обеспечивается через официальный сайт системы, а также в форме открытых данных, включающих файлы форматов XML и SIG [1].

Региональный контур — ГИСОГД субъектов РФ

Параллельно каждый субъект РФ обязан вести собственную региональную государственную информационную систему обеспечения градостроительной деятельности (ГИСОГД) — это требование статьи 56 ГрК РФ, действующее уже несколько лет и не связанное напрямую с № 596 [5; 6]. Именно в региональных ГИСОГД ведутся реестры разрешений, которые выдают органы субъектов РФ и органы местного самоуправления [3; 7]. Планируется, что федеральная ГИСОГД РФ будет интегрировать данные региональных систем через технологические интерфейсы, но это отдельная, более широкая задача, чем реестры разрешений по № 596 [6].

Для системы управления проектами практический смысл в том, что интеграция с «одной государственной системой» в реальности почти всегда означает интеграцию (или хотя бы регулярную сверку) с конкретной региональной ГИСОГД по месту строительства объекта, а для федеральных объектов — дополнительно с федеральным контуром «Стройкомплекс.РФ».

Главная ловушка для проектных систем: «актуальный статус» vs «однажды сохранённый файл»

Раньше практика хранения выглядела так: получили разрешение → отсканировали → прикрепили PDF к карточке объекта → на этом работа с документом в системе заканчивалась. Проблема в том, что такой PDF фиксирует состояние на момент выдачи и ничего не говорит о том, что происходит с разрешением дальше.

В реестровой модели состояние может меняться без переиздания документа:

• срок действия разрешения продлевается — статус записи может временно переводиться из «архивный» обратно в «действует» [1];
• в запись вносится исправление опечатки или ошибки по заявлению застройщика — в течение не более 5 рабочих дней [1; 2];
• разрешение прекращает действие или истекает срок — запись автоматически переводится в статус «архивный» [1];
• выдано разрешение на ввод объекта в эксплуатацию — предыдущая запись о разрешении на строительство переводится в архив [1].

Если PM-система или СЭД хранит только факт «разрешение получено, файл приложен», она физически не может отразить ни одно из этих событий. В результате отдел, отвечающий за приёмку работ или переход на следующий этап, продолжает ориентироваться на файл трёхлетней давности, в то время как реестровая запись уже давно поменяла статус. Отсутствие актуальной записи в реестре приравнивается к отсутствию разрешения [2] — то есть для контролирующих органов и заказчиков по 44-ФЗ/223-ФЗ формально не будет иметь значения, что когда-то бумага существовала.

Модель данных: объект → разрешение → запись → подтверждение → ответственный → действие

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

1. Объект — конкретный объект капитального строительства или этап строительства, к которому привязано разрешение.
2. Разрешение — сущность верхнего уровня: вид (на строительство или на ввод в эксплуатацию), уполномоченный орган, дата первичной выдачи.
3. Реестровая запись — реестровый номер, текущий статус («действует»/«архивный»), дата присвоения номера, дата последнего изменения. Это единственный источник истины по актуальности.
4. Подтверждение (выписка) — конкретный документ или ответ ГИС, полученный на определённую дату и подтверждающий состояние записи на этот момент. Важно: выписка — это снимок состояния, а не сама запись; она устаревает.
5. Ответственный — сотрудник или роль, которая обязана отслеживать изменения по конкретной записи (продление, исправление, архивацию) и инициировать повторную проверку перед ключевыми событиями проекта.
6. Действие — что делает система или человек при изменении статуса: уведомление, блокировка перехода на следующий этап, запрос обновлённой выписки, эскалация.

Такая модель отвечает на вопрос "а что если срок разрешения истёк, пока мы не смотрели" не постфактум, а как часть регулярного процесса — потому что у записи есть срок действия и ответственный, а не только прикреплённый файл.

Как обрабатывать жизненный цикл записи

Продление срока действия

Продление оформляется по заявлению застройщика уполномоченному органу; изменения вносятся не более чем за 5 рабочих дней [1; 2]. Если продление связано с изменением срока действия, ранее заархивированная запись может быть переведена оператором информационной системы обратно в статус «действует» [1]. Для проектной системы это значит: нельзя автоматически считать архивную запись «мёртвой» без проверки причины архивации — истечение срока и продление это разные события в одной и той же записи.

Исправление ошибки или опечатки

Исправление опечатки или ошибки в реестровой записи вносится по тому же механизму заявления от застройщика, с тем же сроком в 5 рабочих дней [1]. Важно закладывать в процесс приёмки этот временной люфт: если работы предъявлены к приёмке в момент, когда исправление ещё не отражено в реестре, формально действующей записи в актуальном виде может не быть [2].

Переход записи в архив

Запись переводится в статус «архивный» в трёх случаях: разрешение прекращено решением уполномоченного органа, истёк срок его действия, либо выдано разрешение на ввод объекта (или последнего этапа) в эксплуатацию [1]. Первый случай требует уведомления от органа власти оператору системы в течение 3 рабочих дней, второй и третий переводятся в архив автоматически [1]. Для проекта архивация по причине ввода в эксплуатацию — это штатное завершающее событие, а архивация по причине прекращения или истечения срока — сигнал, требующий немедленной эскалации на ответственного.

Кто отвечает за контроль изменений

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

• на этапе оформления — ответственный готовит заявление, отслеживает первичное внесение записи и получение выписки;
• на протяжении срока действия — ответственный (может быть другой человек, например технический заказчик или ПТО) периодически сверяет статус записи, особенно перед контрольными точками проекта — приёмкой этапа работ, техническим совещанием с подрядчиком, подачей документов на следующее разрешение;
• при получении уведомления от системы — если PM-система или СЭД настроена на автоматические напоминания о приближении срока действия записи, ответственный обязан инициировать продление заранее, а не по факту истечения.

Без этого разделения даже правильно спроектированная модель данных не спасает от ситуации, когда все поля в системе есть, но никто не смотрит на дату истечения до тех пор, пока подрядчик не встанет перед отказом в приёмке.

Где эти данные нужны дальше: переход на следующий этап и проверка подрядчиков

Реестровая запись — это не изолированный юридический факт, а условие для дальнейших шагов проекта:

• Переход проекта на следующий этап. Прежде чем строить последующий этап или подавать документы на разрешение на ввод в эксплуатацию, разумно встраивать в PM-систему проверку: актуален ли статус разрешения на текущий этап, не приближается ли срок его действия к истечению.
• Проверка подрядчиков. Заказчикам по 44-ФЗ и 223-ФЗ рекомендуется указывать в документации закупки и в проекте контракта, что подтверждением наличия разрешения является реестровая запись, а не бумажный документ, и требовать от подрядчика предоставления реестрового номера для самостоятельной проверки [2]. Отсутствие записи в реестре приравнивается к отсутствию разрешения и может стать основанием для отказа в приёмке работ или для штрафных санкций по контракту [2].

Именно здесь СЭД и PM-система перестают быть просто архивом документов и становятся инструментом контроля рисков: они должны не просто хранить номер разрешения, а уметь ответить на вопрос "действует ли оно прямо сейчас" в момент, когда принимается управленческое решение.

Хранение истории проверок и подтверждающих документов

Поскольку сама реестровая запись не может быть удалена и хранит полную историю изменений на стороне государства [1], у застройщика или подрядчика возникает симметричная задача — хранить историю собственных проверок этой записи. Это нужно по двум причинам.

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

Во-вторых, для гарантийных обязательств после завершения строительства: даже после ввода объекта в эксплуатацию архивная запись сохраняется [1], и к ней может понадобиться вернуться при разборе претензий по гарантии.

Практически это означает, что при каждой проверке статуса разрешения система должна сохранять не только текущий вывод («действует» / «архивный»), но и снимок данных на момент проверки: дату запроса, кто инициировал, что показала выписка. Такой журнал проверок — отдельная сущность, логически примыкающая к "подтверждению" в модели данных выше, но не заменяющая его: подтверждение относится к одному разрешению, журнал — ко всей истории обращений к реестру по проекту.

Варианты реализации: от ручной проверки до интеграции с ГИС

Не каждой компании нужна полноценная техническая интеграция с ГИСОГД или «Стройкомплекс.РФ» — набор решений здесь достаточно широкий:

• Ручная периодическая проверка. Ответственный сотрудник вручную сверяет статус записи на сайте нужной системы по установленному регламенту (например, раз в квартал и перед ключевыми точками проекта), результат фиксируется в СЭД. Подходит для компаний с небольшим числом объектов.
• Настройка регламента внутри существующей СЭД или PM-системы. Без прямой интеграции с ГИС, но с доработкой карточки объекта: добавляются поля реестрового номера, статуса, срока действия, ответственного, а также автоматические напоминания о приближающихся датах. Это относительно недорогой шаг, который снимает большую часть риска "забыли посмотреть".
• Интеграция через открытые данные. Если у используемой ГИС есть открытые данные или API (для федерального контура предусмотрены форматы XML и SIG [1]), можно настроить регулярную автоматическую сверку статуса без участия человека на каждом объекте.
• Полноценная интеграция с обменом данными. Для компаний с большим портфелем объектов в нескольких регионах имеет смысл выстраивать обмен данными между PM-системой/СЭД и профильными реестрами (там, где это технически доступно), с автоматическим обновлением статусов, уведомлениями ответственных и журналом проверок.

Наличие технической возможности подключения (открытых данных, API) не означает автоматического доступа для любой компании: нужно отдельно выяснять, требуется ли регистрация, доступна ли документация интерфейса, какие операции реализованы именно для внешних пользователей, а какие — только для органов власти. На момент подготовки статьи детальный технический регламент подключения сторонних информационных систем к региональным ГИСОГД и к федеральному контуру «Стройкомплекс.РФ» в открытых источниках не разбирался построчно — эти детали стоит уточнять по конкретному региону и системе перед проектированием интеграции.

Практические этапы внедрения

1. Провести аудит текущей практики. Определить, как сейчас в СЭД/PM-системе хранятся сведения о разрешениях: как файл, как отдельная карточка, как поле в общей карточке объекта.
2. Проверить региональный статус перехода. Для каждого субъекта РФ, где ведутся проекты компании, выяснить, принят ли региональный акт об отсрочке перехода на реестровую модель (право есть до 1 сентября 2027 года) [3], и какая система выступает актуальным источником — региональная ГИСОГД или прежний бумажный порядок.
3. Спроектировать модель данных по схеме "объект → разрешение → запись → подтверждение → ответственный → действие", описанной выше.
4. Назначить ответственных за первичное оформление и за периодический контроль статуса отдельно.
5. Настроить регламент проверки и уведомлений, синхронизированный со сроками действия конкретных разрешений и с 5-дневным сроком обновления записей после подачи заявления [1].
6. Обновить шаблоны договоров и закупочной документации, указав, что подтверждением наличия разрешения выступает реестровая запись, а не бумажный документ, и что подрядчик обязан предоставлять реестровый номер [2].
7. Внедрить журнал проверок как отдельный, неудаляемый лог обращений к реестру внутри компании.
8. Оценить целесообразность технической интеграции — от простой доработки существующей системы до полноценного обмена данными, исходя из числа объектов, регионов и частоты проверок.

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

• Ошибка "один PDF на весь срок проекта". Наиболее распространённая практика, которая перестаёт работать: прикрепить скан один раз и не возвращаться к вопросу до момента спора.
• Смешение федерального и регионального контуров. Ошибочно считать, что № 596 регулирует все разрешения в стране — оно касается только федеральных органов, «Росатома» и «Роскосмоса» [1]. Для большинства проектов актуальны правила конкретного субъекта РФ [3].
• Ошибочное заявление "все бумажные разрешения недействительны". Это неверно: разрешения, выданные в форме документа до 1 сентября 2026 года, сохраняют силу до истечения установленного срока [3]. Речь идёт о переходе на новую модель оформления и подтверждения, а не об аннулировании ранее выданных документов.
• Игнорирование регионального переходного периода. Субъект РФ может сохранить прежний порядок до 1 сентября 2027 года собственным актом [3] — компания, работающая в нескольких регионах, рискует спроектировать интеграцию под несуществующий "единый федеральный переход".
• Недооценка срока обновления записи. Изменения в реестре вносятся в течение до 5 рабочих дней [1] — если приёмка работ или контрольная точка проекта назначена без учёта этого люфта, формально актуальной записи может ещё не быть даже при фактически поданном заявлении.
• Отсутствие журнала проверок. Без сохранения истории собственных обращений к реестру компания не сможет доказать добросовестность проверки в случае споров, даже если сама реестровая запись доступна для просмотра постфактум.

Как выбрать подходящее решение

Выбор между ручной проверкой, доработкой существующей СЭД и полноценной интеграцией зависит прежде всего от масштаба портфеля объектов и числа регионов присутствия, а также от того, насколько критичны сроки для конкретного бизнеса (например, для застройщиков жилья с плотным графиком продаж риск пропущенного продления существеннее, чем для разовых промышленных объектов). Небольшой компании с несколькими проектами в одном регионе часто достаточно доработать существующую CRM или СЭД полями и напоминаниями, не строя техническую интеграцию с нуля. Компаниям с десятками объектов в разных субъектах РФ, где различаются и региональные правила, и сроки перехода, разработка или интеграция обычно себя окупает за счёт снижения риска пропущенных сроков и споров с контролирующими органами и подрядчиками.

Вывод

Постановление № 596 и Федеральные законы № 304-ФЗ и № 299-ФЗ переводят разрешительную документацию из состояния "бумага, которую один раз получили" в состояние "запись в государственной системе, которая живёт своей жизнью параллельно с проектом". Для федерального контура — федеральных органов, «Росатома» и «Роскосмоса» — правила уже закреплены и действуют с 1 сентября 2026 года. Для основной массы застройщиков, работающих с региональными и муниципальными разрешениями, актуальный контур — региональная ГИСОГД, а конкретные сроки перехода определяет каждый субъект РФ самостоятельно, вплоть до 1 сентября 2027 года. Компаниям, которые хотят снизить риск в этот переходный период, стоит не дожидаться единой федеральной команды "теперь всё через одну систему", а уже сейчас перестроить внутреннюю модель данных вокруг цепочки объект → разрешение → запись → подтверждение → ответственный → действие — независимо от того, произошёл ли формальный переход в конкретном регионе.

Источники

[1] pravo.ppt.ru — Постановление Правительства РФ от 25.05.2026 № 596 — https://pravo.ppt.ru/postanovlenie/pravitelstvo/n-596-338419

[2] pro-ability.ru — Реестры разрешений на строительство и ввод объектов в «Стройкомплекс.РФ» с 1 сентября 2026 года: что меняется для заказчиков по 44-ФЗ и 223-ФЗ — https://www.pro-ability.ru/tpost/h156xvlhr1-reestri-razreshenii-na-stroitelstvo-i-vv

[3] c-o-k.ru — До перехода на реестровые разрешения на строительство осталось две недели (о ФЗ № 299-ФЗ) — https://www.c-o-k.ru/market_news/do-perehoda-na-reestrovye-razresheniya-na-stroitelstvo-ostalos-dve-nedeli-regiony-mogut-otlozhit-ego-na-god

[4] kremlin.ru — Федеральный закон от 31.07.2025 № 304-ФЗ — http://www.kremlin.ru/acts/bank/52237/page/14

[5] xn--80aalw7afh.xn--80adxhks — В чём разница между ГИСОГД, ГИСОГД РФ и ЕГИСОГД — https://xn--80aalw7afh.xn--80adxhks/news/952

[6] it2region.ru — Что такое ГИСОГД: полное руководство для застройщиков, архитекторов и органов власти — https://it2region.ru/articles/chto-takoe-gisogd

[7] asergroup.ru — Стройкомплекс.РФ и иные новые информационные системы — https://asergroup.ru/news/gradostroitelnoe-regulirovanie-i-stroitelstvo-/stroykompleks-rf-i-inye-novye-informatsionnye-sistemy/

[8] buildingclub.ru — Разрешение на строительство МКД: порядок с 1 сентября 2026 — https://buildingclub.ru/razreshenie-na-stroitelstvo-mkd/