КИИ: до дедлайна меньше 100 дней - финализируем план

Где-то в середине октября цифра стала конкретной: меньше ста дней. Не «конец года», не «в декабре», а конкретный трёхзначный отсчёт. Именно в этот момент у нескольких клиентов сработало что-то вроде позднего осознания - и в течение одной недели мы получили несколько запросов в духе «помогите понять, где мы сейчас и что реально успеть».

При этом ФСТЭК заметно активизировался: участились запросы о ходе перехода, регуляторные письма перешли из режима «информируем» в режим «просим предоставить». Несколько коллег с рынка рассказывали о внеплановых проверках. Картина не катастрофическая, но и не расслабляющая.

Первый вопрос: по каким объектам работаем

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

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

Поэтому первый шаг при финализации плана - расставить приоритеты именно по категории. Не по объёму работы, не по сложности стека, а по тому, где риск регуляторного инцидента наиболее острый прямо сейчас. Для объектов первой категории статус «в процессе» без конкретной даты закрытия - это риск. Для третьей - это пока управляемо.

Что можно успеть за сто дней

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

Но то, что можно и нужно успеть:

Закрыть все висящие «почти готово». ОС и СУБД у большинства клиентов уже на Astra Linux или РЕД ОС, на Postgres Pro или Tantor - но где-то остались хвосты: несколько узлов, тестовые стенды, которые никак не переведут в продуктив. Это нужно добить.

Зафиксировать статус по каждой позиции явно. Не «ведём работу», а конкретно: закрыто, закрывается к такой-то дате, не закрывается - вот почему. Последнее - самое важное, потому что именно оно становится основой для обоснования.

Подготовить обоснование там, где замена невозможна. Это отдельная работа, и мы к ней вернёмся ниже.

Обоснование для регулятора: как это устроено

ФСТЭК не требует стопроцентного перехода как условия «сдаться и забыть». Регулятор понимает, что в отраслевом и специализированном ПО реестр Минцифры закрывает далеко не всё. Механизм обоснования существует - но он требует оформления по форме.

Обоснование должно содержать несколько вещей. Факт отсутствия альтернативы - не «не нашли», а с конкретной ссылкой на реестр и указанием, какие позиции проверялись и почему не подходят (несовместимость с технологическим процессом, отсутствие сертификата, критичная функциональность не реализована). Технологическое обоснование - почему замена невозможна в текущей конфигурации без остановки критичного процесса. Дорожную карту - что и когда будет сделано, когда появится подходящая альтернатива или когда будет реализована собственная разработка.

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

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

Что не работает

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

Задним числом переписывать реестр ПО объекта - так, чтобы «чувствительные» позиции исчезли. Это работает ровно до первой проверки с запросом логов или конфигураций. Репутационный и правовой риск несопоставим с временным облегчением.

Ставить везде статус «в процессе» без содержания - регулятор это читает. Письма с запросами о конкретных сроках и ответственных - прямое следствие такой практики.

Делать обоснование «для галочки» без реальной технической аргументации. Форма без содержания легко разбирается при очном взаимодействии с проверяющим.

Где сейчас реально

Из того, что мы видим у клиентов: инфраструктурный слой (ОС, СУБД, мониторинг) закрыт у большинства или близок к закрытию. Прикладное и отраслевое ПО - пробелы есть почти везде, и часть из них объективно не закрывается к январю. Это нормальная и честная ситуация, если её правильно зафиксировать.

Сто дней - это не «почти ничего» и не «ещё много». Это конкретный горизонт, в котором одни задачи успеваются, другие нет. Главное - понимать разницу и работать с ней, а не делать вид, что всё в порядке.

Если нужна помощь с аудитом и финализацией плана - сейчас самый рабочий момент, чтобы это сделать.