Документы для доверенного статуса ПО: полный перечень

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

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

Структура документального пакета

Группа 1: документы о правообладателе

Эта группа подтверждает соответствие требованию российского контроля, состав зависит от организационно-правовой формы и корпоративной структуры. Актуальная выписка из ЕГРЮЛ или ЕГРИП не старше 30 дней на момент подачи подтверждает регистрацию в России, состав участников и виды деятельности — при многоуровневой структуре владения могут потребоваться выписки по нескольким юридическим лицам цепочки. Устав организации нужен в действующей редакции с отметкой налогового органа: проверяется порядок принятия решений и права участников, включая наличие или отсутствие нестандартных прав у иностранных участников. Корпоративный договор, если он заключён между участниками, подлежит предоставлению — его отсутствие при фактическом наличии становится основанием для вопросов, а нестандартные права иностранных участников в договоре требуют проработки до подачи. При многоуровневой структуре владения нужна схема корпоративной структуры с указанием долей на каждом уровне и документы, подтверждающие российский контроль по всей цепочке.

Для правообладателей с государственным участием (доля государства более 50%) к стандартному пакету добавляется справка о выручке от реализации продукта с разбивкой по заказчикам и указанием их аффилированности — расчёт доли аффилированной выручки должен подтвердить соответствие правилу 30% за последний завершённый финансовый год, а справку подписывают руководитель и главный бухгалтер.

Группа 2: документы о программном продукте

Группа 3: технические документы для центра тестирования

Эти документы не подаются в Минцифры — они передаются напрямую в центр тестирования по условиям договора, и именно на их основании проводится техническая экспертиза, так что их качество прямо влияет на результат. Установочный дистрибутив должен точно совпадать по версии с тем, о чём написана вся документация: расхождение версий — типичный источник вопросов на экспертизе. Руководство пользователя нужно актуальным и с пошаговыми инструкциями для типовых сценариев — именно по ним эксперты тестируют функциональность, а руководство администратора для серверного ПО и СУБД должно описывать кластерные конфигурации, резервное копирование и управление доступом, поскольку центр использует его при развёртывании тестовой среды.

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

Специфика документов в зависимости от истории прав

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

Технические требования к оформлению документов

Типичные ошибки при подготовке пакета

Реестровая запись, не обновлённая под текущую версию продукта, — частая проблема: центр тестирования проверяет продукт в актуальном состоянии, и расхождение с реестровой записью создаёт вопросы, поэтому запись нужно привести в соответствие ещё до подачи. Договоры с разработчиками без условия об отчуждении прав — стандартный трудовой договор без конкретного служебного задания или договор ГПХ без условия передачи прав — оставляют права на код формально не принадлежащими компании, и это нужно выявить и исправить заранее. Неполный перечень компонентов и зависимостей, ограниченный только основными библиотеками без транзитивных зависимостей, ведёт к запросу дополнений и задержке экспертизы. Отсутствие документации по архитектуре безопасности и модели угроз при наличии обычных руководств пользователя и администратора — одна из самых частых недостач, добавляющая одну-две недели к сроку. Несоответствие версий дистрибутива и документации, когда инструкции написаны для одной версии, а на экспертизу передан дистрибутив следующей, приводит к тому, что шаги из документации не воспроизводятся и эксперт фиксирует замечание. Устаревшая выписка из ЕГРЮЛ обнаруживается обычно уже после подготовки всего пакета, и приходится заново её получать, теряя время перед самой подачей.

Источники

• КонсультантПлюс, порядок формирования перечня доверенного ПО: состав документов и требования к их оформлению по постановлению №1937.
• Реестр российского программного обеспечения, Минцифры России: подача заявления через ФГИС и реестровая запись как предварительное условие.