Первое. Для кого этот приказ:

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

То есть, формально под требования попадает любая 1с, любой линукс (даже русифицированный, то есть импортозамещенный), и так далее.
Попадает даже в муниципальных информационных системах.

Второе. Уже не только про бюрократию.

14. Организация деятельности по защите информации должна включать:

.. перечень разрешенного и (или) запрещенного для использования программного обеспечения;

..  разработку и утверждение внутренних регламентов по защите информации.

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

На десерт. Для тех, кто любит «поставил и работает» - то есть МТС, Аэрофлоту, СДЭК, судам, кого еще взломали за последние 4 года, и кто не ставил обновления .

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

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

в отношении уязвимостей критического уровня опасности[13] - в срок не более 24 часов;

в отношении уязвимостей высокого уровня опасности - в срок не более 7 календарных дней.

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

Тем, кому не хватило, добавили пункт 50

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

В случае самостоятельной разработки оператором (обладателем информации) программного обеспечения, предназначенного для использования в информационных системах, должны быть реализованы меры, предусмотренные разделами 4 и 5 ГОСТ Р 56939-2024.

Не забыли и ИИ

60. Посредством проведения мероприятий по обеспечению защиты информации при использовании для функционирования информационных систем искусственного интеллекта[20] должна быть обеспечена возможность исключения несанкционированного доступа к информации или воздействия на информационные системы, несанкционированного распространения и модификации информации, а также использования информационных систем не по их назначению за счет воздействия на наборы данных[21], применяемые модели искусственного интеллекта[22] и их параметры[23], процессы и сервисы по обработке данных и поиску решений[24].

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

Если смотреть верхнеуровнево, то ничего особенного в приказе нет.
Прежде всего, нет штрафов и наказаний для должностных лиц. Без этого наказывать будут стрелочников, и специалистов по устранению замятия бумаги второго разряда. 274.1 УК РФ распространяется только на КИИ, которыми разного рода гос.органы не являются.

Большая часть описанных внедрений относится к бюрократии, а не к ИТ – посчитать, издать приказ, оформить регламент, вывесить на дверь таблички «не влезать».

Меньшая часть относится к тому, что и так должно было бы быть у тех, кто читал MBSA и Security Compliance , или , хотя бы, Windows 11 книга безопасности (издание 2025).

Но это Microsoft, там читать и думать надо. Для Linux достаточно прочитать шпаргалку. Для остальных есть маленькая красная книжка и книжка с пауком.

Литература

ФСТЭК №117: изменения в защите информации с 1 марта 2026
https://bearpass.ru/blog/fstec-117-nepreryvnyy-kontrol-ib-20...

PS. Приказ, в первую очередь, направлен на угнетение тех свободных личностей, которые считают ниже своего достоинства выполнить две команды
echo apt update && apt upgrade -y && reboot now -f>> /path/to/your_script.sh
(crontab -l 2>/dev/null; echo "0 2 * * * /path/to/your_script.sh") | crontab -

https://www.interfax.ru/world/1085783

Второй источник: Пресс-релиз правительства Норвегии

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

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

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

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

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

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

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

Четвертый камень — это базовая вещь, про которую почему-то все забывают, несоответствие самому статусу правообладателя. Минцифры указывают требования к заявителю: для физлица – гражданство РФ, для организации – регистрации в РФ и доля российского участия 50%. Если структура владения, корпоративная цепочка или сам заявителя не проходят по этим критериям, это уже системная проблема, а не «исправимая мелочь».

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

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

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

Шестое, это скорее не проблема, а просто незнание людей, которые часто путают регистрации программы в Роспатенте и включение в реестр российского ПО. Это не одно и то же. Свидетельство Роспатента может быть полезным подтверждающим документом, но само по себе не гарантирует включение в реестр Минцифры. Практические разборы ошибок специально подчеркивают, что одной «бумажки из Роспатента» часто недостаточно без полного комплекта документов по правам и самому продукту.

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

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

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

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

Вам просто надо, перед подачей провести внутренний «предаудит» по чек-листу: права, заявитель, полномочия подписанта, комплект документов, описание продукта, корректность сведений в форме. Это особенно важно, потому что на сайте реестра есть отдельная стадия подачи и регистрации заявления, а значит часть ошибок может сработать еще до содержательного рассмотрения.

Краткий гайд, что у кого спрашивать и что делать в тех или иных ситуациях:

- Если вы юрист, не надо ограничиваться общим вопросом «у нас все в порядке с правами на ПО?». Лучше идти о цепочку и спрашивать предметно. У руководителя или собственника стоит уточнить, о том, кто именно считается правообладателем продукта сейчас, на какую компанию или на какое лицо оформлены права, была ли передача продукта, реструктуризация, смена юрлица, привлечение подрядчиков или внешней команды. У HR или у того, кто ведет кадровые документы, нужно спрашивать, как были оформлены разработчики: работали ли они по трудовому договору, были ли служебные задания, акты, допсоглашения, положения о служебных произведениях. У бухгалтерии или корпоративного юриста имеет смысл уточнить, какая структура участников в компании, нет ли проблемы с долей российского участия, все ли сведения по юрлицу актуальны. У технической команды или СТО нужно прямо спрашивать: из чего собран продукт, есть ли open source, сторонние библиотеки, платные движки, чужие модули, код подрядчиков, облачные зависимости.

- Если вы разработчик, вам тоже не стоит писать юристу или руководителю что-то вроде «посмотрите, можно ли нас включить в реестр». Лучшее задавать вопросы по-простому и по делу: наша компания вообще является правообладателем этого ПО или нет?; весь код написан внутри компании или что-то делали подрядчики?; есть ли документы, по которым права на код перешли компании?; можем ли мы подтвердить, что используемые библиотеки и open source не мешают подаче?; на кого оформлен продукт юридически – на компанию, на основателя или вообще частично на команду?

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

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

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

Краткий чек-лист по включению в реестр российского ПО выложил в Telegram (https://t.me/+8GorHm8GP7kwODRi) и VK (https://vk.com/invite/l79QjWL) — можно сохранить и использовать перед подачей. Там же регулярно публикую другие разборы и материалы по цифровому праву, практические кейсы и подводные камни, о которых обычно не пишут в инструкциях.

Европа: бюрократический пир во время чумы

В ЕС ситуация напоминает театр абсурда. С одной стороны, Еврокомиссия провалила дедлайн по публикации списков высокорисковых ИИ-систем, оставив бизнес в неведении. С другой — правозащитники бьют тревогу, что новая инициатива по "дерегуляции" (Digital Omnibus) на самом деле уничтожает цифровые права граждан. Регуляторы (EDPB и EDPS) в открытую критикуют предложения Еврокомиссии, обвиняя её в размывании GDPR. Европа увязла в междоусобных войнах, пока остальной мир движется вперед.

США: федеральная пауза и штатовская самодеятельность

Америка демонстрирует классический раскол: федеральная FTC официально заявила, что у неё "нет аппетита" регулировать ИИ, сосредоточившись на защите детей (COPPA). Но отдельные штаты, как Кентукки, пытаются в одиночку прорубать окно в цифровое будущее с законом о "цифровом выборе" и совместимости данных. Отсутствие единой стратегии приводит к лоскутному одеялу регулирования, где каждый штат сам за себя.

https://t.me/AIb_na_trube

В видео рассмотрен процесс отправки декларации 3-НДФЛ через госуслуги. Такая возможность появилась совсем недавно. Проверок декларации и прилагаемых файлов происходит гораздо меньше, чем в личном кабинете налогоплательщика. То есть, если декларация у Вас правильно заполнена, документы в правильном формате, но всё равно не получается отправить 3-НДФЛ, то можно рассмотреть альтернативный вариант отправки - через госуслуги.

Также хотел бы обратить внимание на несколько существенных ошибок при отправке:

1.
Не печатаются цифры в декларации. Эту ошибку заметил только на Windows 8. На 7 и 10 версии Windows такая ошибка не возникала. Также можно копировать цифры из блокнота. Подробнее можно посмотреть здесь:
https://dzen.ru/a/aVwcY0EgrWjmSReb

2.

Значение "" имеет недопустимую длину "0", допустимая длина: "1": строка 1, колонка

Данная ошибка была исправлена в последней версии программы декларации (2.0.0001). То есть надо просто обновить программу (скачать с сайта разработчика последнюю версию). Но если нет такой возможности, то суть ошибки в том, что из программы выгружается лишний элемент "Номер платёжной карты", хотя его Вы не заполняли. Надо просто удалить этот элемент (атрибут). Подробнее здесь:

https://dzen.ru/a/aWATY0PBn05vK3Rh

3. Необходимо загрузить скан-образ справки об оплате в одном из форматов файлов: pdf, png, jpg, jpeg, tif, tiff.

Эта ошибка возникает при отправке деклараций с социальными расходами (обучение, лечение и т.д.), если количество прилагаемых документов не равно количеству справок об оплате услуг. Чтобы исправить эту ошибку надо или отправить документы после отправки декларации, или сделать одинаковым количество файлов прилагаемых документов и справок об оплате:

https://dzen.ru/a/aWdwDF73hWNCi4B_

Вероятно, это не все ошибки. Но пока других новых ошибок (появившихся в этом году) не видел, а по прошлогодним ошибкам уже есть множество статей и видео.