Главная/Методология/План перехода на российское ПО: структура…
Переход КИИ на российские ПАК

План перехода на российское ПО: структура документа

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

Обновлено: 8 сентября 2026 г. · Автор: Евгений Теленков · ≈ 7 мин чтения

Что требует регулятор

По проекту постановления о порядке перехода уполномоченный орган (для отрасли это министерство, для финансового сектора Банк России, для атомной отрасли Росатом) утверждает отраслевой план и направляет его субъектам КИИ. Субъект в течение месяца составляет собственный план и согласовывает его с регулятором. В плане должны быть:

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

Копии утвержденных планов идут в Минпромторг, Минцифры, ФСТЭК и ФСБ, мониторинг закреплен за Минцифры. Это означает, что план читают минимум четыре ведомства, и расхождение между планом и тем, что стоит на площадке, будет видно.

Что требует регуляторПеречень значимых объектовДоли российского и иностранного ПОПрогноз затратПредельный срок завершенияОтветственный не ниже заместителяруководителяЧто защищает переездДопустимое время простоя по процессамОкна переключения и пикиКритерии «переезд не удался»План отката и параллельная работаСценарий учений и отчет советуПервую часть проверят, вторая не даст остановиться
Рис. 1. Две части плана перехода

Чего в этом плане не хватает

Перечисленные разделы отвечают на вопрос «что и когда заменим». Они не отвечают на вопрос «что будет с процессами, пока меняем». Из плана, составленного строго по требованиям, не видно:

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

Именно эти пробелы дают остановки. Регулятор их не спросит, но они проявятся в ночь переключения.

Структура плана: десять разделов

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

РазделСодержаниеИсточник
1. ОбъектыПеречень значимых объектов, категории, состав систем и оборудования, кто эксплуатируетАкты категорирования, реестр ФСТЭК
2. Текущее состояниеДоли российского и иностранного ПО и ПАК по каждому объекту, сроки поддержки и амортизацииИнвентаризация
3. Целевое состояниеЧем заменяется каждый компонент, наличие в реестрах, заключения об отсутствии аналогаРеестры Минцифры и Минпромторга
4. Сроки и затратыПредельный срок по каждому объекту, этапы, бюджет по годам, обоснование отсрочекОтраслевой план, календарь
5. ОтветственныеОтветственный не ниже заместителя руководителя, руководитель проекта, владельцы процессовПриказ
6. Зависимые процессыКакие процессы компании зависят от каждого объекта, допустимое время простоя и потери в часАнализ воздействия
7. Окна переключенияДаты и длительность окон, исключенные пики, резервные окнаПроизводственный календарь
8. Риски переходаРеестр рисков перехода с мерами и ответственными, пороги эскалацииРеестр рисков
9. Откат и параллельная работаКритерии неудачи, порядок возврата, режим двух систем, сверка данных, кто решаетПлан непрерывности
10. Учения и отчетностьСценарии учений до переезда, показатели после, форма доклада советуПрограмма учений, дашборд

Разделы 6-10 не обязательно писать заново, если в компании есть система непрерывности: они берутся из анализа воздействия, реестра рисков и планов, которые уже существуют. Если системы нет, эти разделы становятся ее первым содержанием. Реестр рисков для раздела 8 можно взять за основу здесь: двенадцать типовых рисков перехода.

План есть, а системы непрерывности нет. Это работает?

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

Система непрерывности под ключ, включая проект перехода на российские ПАК →

Кто пишет и кто подписывает

Разделы 1-5 обычно пишет служба ИТ вместе со службой информационной безопасности: у них есть инвентаризация и реестры. Разделы 6-7 не могут написать ни ИТ, ни ИБ: допустимое время простоя знает только владелец процесса, а пики знает производство или коммерция. Разделы 8-10 пишет тот, кто отвечает за непрерывность, а если такой роли нет, руководитель проекта перехода с владельцами процессов.

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

Частые вопросы

Есть ли утвержденная форма плана перехода?

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

Можно ли сделать один план на все объекты?

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

Что показать проверяющему, если план еще не выполнен?

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