Лицензия ФСБ для ИТ-компании: когда нужна и как это проверить

📅 👁 1,034 просмотров ⏱ 19 мин чтения

Лицензия ФСБ для ИТ-компании нужна не из-за отраслевого статуса или самого факта использования шифрования. Решение зависит от того, выполняет ли организация лицензируемые работы, связанные с разработкой, производством, распространением криптографических средств или оказанием услуг в области шифрования. Проверять нужно

Лицензия ФСБ для ИТ-компании: кому нужна в России и как определить необходимость

Лицензия ФСБ для ИТ-компании нужна не из-за отраслевого статуса или самого факта использования шифрования. Решение зависит от того, выполняет ли организация лицензируемые работы, связанные с разработкой, производством, распространением криптографических средств или оказанием услуг в области шифрования. Проверять нужно функции продукта, роль компании и фактические процессы.

Коротко о главном

  • Статус ИТ-компании сам по себе не создаёт обязанности получать лицензию ФСБ России.
  • Проверке подлежит фактический состав работ, а не только название продукта или слово «шифрование» в документации.
  • Разработчик, поставщик, системный интегратор и оператор облачного сервиса могут работать с одним решением, но выполнять разные с правовой точки зрения действия.
  • Нотификация ФСБ относится к характеристикам определённой продукции с криптографическими функциями в контексте внешнеэкономических операций. Она не заменяет лицензию на деятельность.
  • Лицензия ФСТЭК России касается другого регулируемого направления и не подменяет лицензию ФСБ России.
  • До запуска проекта стоит сопоставить функции продукта, техническую документацию, договорную модель и способы распространения.
Основной критерий. Наличие HTTPS, VPN, электронной подписи, защищённого соединения или готовой криптографической библиотеки не даёт однозначного ответа. Юридическая оценка должна учитывать назначение криптографической функции и действия, которые компания выполняет для себя, партнёра или заказчика.

Что такое лицензия ФСБ для ИТ-компании и что именно лицензируется

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

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

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

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

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

Когда ИТ-компании стоит проверить необходимость лицензии ФСБ

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

Ситуация Что проверить Практический вывод
Разработка программного обеспечения Есть ли собственные криптографические функции, отдельные модули, операции с ключевой информацией и самостоятельное назначение криптографического компонента Оценивать нужно состав решения и фактическую роль разработчика, а не бренд или категорию продукта
SaaS-сервис Какие функции выполняет серверное программное обеспечение, как защищаются данные, кто управляет компонентами и оказывает ли оператор работы или услуги в области шифрования Облачная модель сама по себе не подтверждает и не исключает необходимость лицензии
Интеграционный проект Поставляет ли компания готовое решение, внедряет, монтирует, настраивает или обслуживает средства криптографической защиты информации Поставку, интеграцию и последующее сопровождение следует квалифицировать раздельно
Дистрибуция ПО или оборудования Кто производит товар, что входит в поставку, какие права получает дистрибьютор и присутствует ли внешнеэкономическая операция Вопрос лицензирования деятельности нужно отделить от нотификации характеристик товара
Стартап с MVP Как криптографические функции описаны в техническом задании, архитектуре, презентации, пользовательской документации и договоре Противоречивые формулировки мешают установить реальный состав разработки

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

Отдельного внимания требуют формулировки «собственная система шифрования», «криптографическая защита на стороне сервиса», «внедрение СКЗИ» и «обслуживание защищённой инфраструктуры». Такие выражения в коммерческом предложении или техническом задании должны совпадать с архитектурой решения и предметом договора.

Правовая рамка и риски неправильной квалификации

Федеральный закон от 4 мая 2011 года № 99-ФЗ «О лицензировании отдельных видов деятельности» устанавливает общие правила лицензирования. В перечень лицензируемых направлений входит деятельность по разработке, производству, распространению шифровальных средств, защищённых с их использованием информационных и телекоммуникационных систем, а также выполнению работ и оказанию услуг в области шифрования информации.

Постановление Правительства Российской Федерации от 16 апреля 2012 года № 313 регулирует лицензирование этой деятельности и содержит перечень выполняемых работ и оказываемых услуг. Положение предусматривает исключение для деятельности, которую юридическое лицо или индивидуальный предприниматель ведёт исключительно для обеспечения собственных нужд. Применимость исключения нужно устанавливать по реальной модели работы, а не по формальному заявлению компании.

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

Если компания ведёт предпринимательскую деятельность без специального разрешения, когда оно требуется, обстоятельства могут получить квалификацию по части 2 статьи 14.1 Кодекса Российской Федерации об административных правонарушениях. Конкретные последствия зависят от состава действий, участников, договоров и других обстоятельств. Само обнаружение в продукте криптографической функции ещё не доказывает наличие правонарушения.

Внимание. Ошибка в квалификации может повлечь не только административное производство. Компания рискует столкнуться с отклонением заявки на закупку, претензиями заказчика к составу разрешительных документов, пересмотром договора, ограничением отдельных работ и необходимостью менять схему поставки.

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

В контексте внешнеэкономических операций применяется Решение Коллегии Евразийской экономической комиссии от 21 апреля 2015 года № 30. Оно относится, в частности, к порядку работы с товарами, содержащими шифровальные или криптографические функции, включая нотификацию их характеристик. Этот порядок не превращает нотификацию в лицензию на деятельность.

Что собрать до консультации или внутренней проверки

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

Сценарии для разных ИТ-компаний

Разработчик ПО с криптографическими функциями

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

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

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

Облачный провайдер и SaaS-сервис

Хранение информации в облачной инфраструктуре и передача данных через защищённый канал не служат самостоятельными критериями лицензирования. Для SaaS нужно установить, какие операции выполняет платформа, где размещены криптографические компоненты, кто ими управляет и входит ли настройка защиты в услугу для клиента.

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

А что будет, если сервис использует шифрование только для защиты собственных административных соединений? Такой факт нужно учитывать вместе с исключением для собственных нужд и остальной моделью деятельности. Если оператор одновременно настраивает криптографические средства для клиентов или оказывает связанные с ними услуги, анализ потребуется расширить.

Системный интегратор

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

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

Тендерное требование «исполнитель должен иметь лицензию ФСБ» тоже требует расшифровки. Компания должна проверить предмет закупки, перечень операций, состав поставки и ожидаемый результат работ. Избыточное требование можно обсуждать с заказчиком в установленном для закупки порядке, а обоснованное требование нужно учитывать при выборе исполнителей и субподрядчиков.

Стартап и команда, создающая MVP

На раннем этапе продукт часто описывают быстрее, чем формируют техническую документацию. В презентации появляется «собственное шифрование», хотя команда использует системную библиотеку, стандартный протокол или внешний сервис. Такая формулировка влияет на вопросы заказчиков и инвесторов, но не подтверждает характер разработки.

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

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

Поставщик оборудования или программного продукта из-за рубежа

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

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

Лицензия ФСБ, нотификация ФСБ и лицензия ФСТЭК: в чём разница

Процедура или документ Для чего применяется Что оценивают Важное уточнение
Лицензия ФСБ России Для ведения предусмотренных законодательством видов деятельности в области шифрования Фактическую деятельность организации, выполняемые работы, процессы и соответствие лицензионным требованиям Не служит разрешением на ввоз каждого отдельного товара
Нотификация ФСБ Для определённой продукции с криптографическими функциями в контексте внешнеэкономических операций Характеристики конкретного товара, программного продукта или оборудования Не заменяет лицензию на деятельность и не является лицензией на товар
Лицензия ФСТЭК России Для деятельности по технической защите конфиденциальной информации Работы, услуги, персонал, процессы и другие условия в отдельном регулируемом направлении Не заменяет лицензию ФСБ России

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

Терминологическая граница. Лицензия относится к деятельности компании. Нотификация содержит сведения о характеристиках продукции с криптографическими функциями и используется в предусмотренном для таких товаров порядке. Назвать нотификацию «лицензией на товар» некорректно.

Как самостоятельно провести первичную оценку

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

  1. Зафиксировать действия компании. Укажите отдельно разработку, производство, поставку, распространение, внедрение, монтаж, настройку, сопровождение и эксплуатацию. Общего слова «интеграция» недостаточно.
  2. Составить карту криптографических функций. Отразите шифрование данных, защищённую передачу, электронную подпись, операции с ключевой информацией, аутентификацию и формирование защищённых каналов связи.
  3. Определить происхождение компонентов. Разделите собственный код, сторонние библиотеки, готовые продукты партнёров, функции операционной системы и внешние облачные сервисы.
  4. Проверить документы. Сопоставьте техническое задание, архитектуру, пользовательское руководство, спецификации, коммерческие предложения и договоры. Одни и те же функции должны быть описаны без смысловых противоречий.
  5. Разграничить собственные нужды и услуги клиентам. Укажите, какие средства компания применяет внутри своей инфраструктуры, а какие поставляет, внедряет, настраивает или обслуживает для других лиц.
  6. Сопоставить модель с регулируемыми работами. Квалифицируйте каждый вид деятельности отдельно. Если описание продукта не позволяет сделать вывод, сначала дополните технические материалы.

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

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

Какие документы обычно проверяют при оценке проекта

Состав материалов зависит от продукта и роли компании. Разработчику потребуется документация на программное обеспечение, импортёру нужны сведения о товаре и цепочке поставки, а интегратору важно подробно описать работы на площадке заказчика. Запрашивать одинаковый комплект у всех ИТ-компаний нет оснований.

  • Техническое описание программного продукта или оборудования.
  • Техническое задание на разработку, внедрение или сопровождение.
  • Архитектурная либо функциональная схема.
  • Описание криптографических функций и операций с ключевой информацией.
  • Сведения о применяемых библиотеках, модулях и внешних компонентах.
  • Документы о правах на программное обеспечение и отдельные компоненты.
  • Договоры с заказчиками, подрядчиками, разработчиками, вендорами и поставщиками.
  • Спецификации поставляемого оборудования или программного обеспечения.
  • Регламенты внедрения, настройки, обновления и технической поддержки.
  • Описание модели распространения, поставки и предоставления доступа к сервису.

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

Пример из практики: почему нотификацию нельзя смешивать с лицензией ФСБ

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

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

Объём информации от завода был ограничен. В такой ситуации нельзя заменять отсутствующие технические сведения предположениями, составленными по рекламному описанию. Сначала нужно получить документы производителя либо подготовить согласованное техническое описание, которое отражает фактические характеристики продукции.

Запрос касался нотификации конкретного товара. Он не подтверждал, что компании автоматически нужна лицензия ФСБ России, и не позволял сделать обратный вывод. Для лицензирования пришлось бы отдельно изучить роль заявителя: ввозит ли он товар, распространяет, модифицирует, интегрирует, настраивает или оказывает связанные услуги.

Какие материалы фигурировали при первичной оценке

  • Техническое описание продукции.
  • Сведения о наличии и назначении функции шифрования.
  • Заявка с данными о товаре и участниках процедуры.
  • Доверенность для совершения предусмотренных процедурных действий.

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

Частые сложности и как их решить

В документах указано шифрование, но функция не описана

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

Компания использует готовую библиотеку, но заявляет о собственной криптографии

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

Продукт поставляется как ПО, SaaS и интеграционный проект

Разделите модели предоставления продукта. Для устанавливаемого ПО анализируют разработку и распространение, для SaaS изучают функции сервиса и роли участников, а для интеграционного проекта проверяют конкретные работы на инфраструктуре заказчика.

Заказчик требует лицензию без указания вида работ

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

Документы подготовили разные подразделения

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

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

В техописании требуется функция шифрования?

Если продукт использует криптографические функции, техническое описание должно отражать их корректно. Для оценки важны назначение функции, способ реализации, используемые компоненты и роль компании. Слов «шифрование» или «защищённое соединение» без технического пояснения недостаточно.

Вы занимаетесь нотификацией ФСБ?

«Реестр Гарант» сопровождает подготовку документов для нотификации продукции с криптографическими функциями. Сначала специалисты определяют, относится ли запрос к конкретному товару и внешнеэкономической операции или к лицензируемой деятельности компании.

Нужна ли лицензия ФСБ, если в программе используется HTTPS или VPN?

Само наличие HTTPS, VPN или иного защищённого канала не даёт автоматического ответа. Нужно оценить функции продукта, происхождение криптографических компонентов, действия разработчика или оператора и условия договоров с заказчиками.

Лицензия ФСТЭК России заменяет лицензию ФСБ?

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

Можно оформить через Россию?

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

Какой срок готовности?

Единого срока для лицензии ФСБ России и нотификации нет, поскольку это разные процедуры. Продолжительность зависит от предмета обращения, полноты технических сведений, готовности документов и действий уполномоченных органов. До анализа продукта называть срок некорректно.

Что нужно зафиксировать перед началом процедуры

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

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

Нужна сертификация по этой теме?

Получите бесплатную оценку сроков и стоимости за 15 минут. Расскажите о продукции — подберём оптимальную схему сертификации.

1500+ сертификатов оформлено В работе с 2015 года Ответ за 15 мин

Читайте также

📰
Новости сертификации

Отказное письмо Роспотребнадзора и СГР: когда регистрация не нужна и как получить письмо

«Отказное письмо Роспотребнадзора» обычно означает информационное письмо о том, что товару не нужна государственная регистрация (СГР). Разбираем, по какому перечню это проверяют, кто оформляет письмо и почему оно не заменяет декларацию или сертификат.

📅 18.10.2026
📰
Новости сертификации

Отказное письмо и «Честный знак»: нужна ли маркировка, если сертификация не требуется

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

📅 18.10.2026
«СЕТЕРЕ ПДФ Редактор» получил сертификат «Сделано в России»
Новости сертификации

«СЕТЕРЕ ПДФ Редактор» получил сертификат «Сделано в России»

Программный комплекс «СЕТЕРЕ ПДФ Редактор» получил сертификат добровольной системы «Сделано в России» по критерию «Уникальность». Продукт работает на российских ОС и включен в реестр отечественного ПО.

📅 15.10.2026