Приказ модель не задаёт, отсылает к методике анализа защищённости от 25 ноября 2025 года. Там работы делятся на внешний и внутренний анализ, а исполнителю передают состав ПО, карту сети и учётные данные. Чёрного ящика методика не предполагает, нарушитель берётся из модели угроз системы.
Сама она при этом про анализ уязвимостей, пентест в ней не описан. Отдельной методики под него не нашёл.
Про время критерия нет вообще: либо доступ получен или привилегии повышены, либо нет.
Вы правы, и на два вопроса из трёх ответ в документе всё же есть.
Про то чья поддержка: пункт 1.6 требует учитывать «сроки технической поддержки со стороны производителей». Думаю, и в 1.7 речь про вендорскую.
Про community-каналы прямого ответа нет, но есть критерий. Пункт 7.3 требует оповещать ИБ об обновлениях «из непредусмотренных источников», а пункт 7.2 велит писать в журнал источник обновления, вплоть до URL или репозитория, и подтверждённые подписи либо контрольные суммы. Выходит, источник может быть любым, если он заранее предусмотрен и проверяем. Поддержкой в смысле пункта 1.7 это не становится, компенсирующие меры всё равно нужны.
А про облака да, возразить нечем. Про облако, VPN туннель и удалённую работу - ноль вхождений. Аварийного доступа тоже нет, пункт 3.4 обрывается на оговорке «при сохранении основных функций ядра сети».
Пункт 1.8 строже, чем кажется: там «исключить удалённое администрирование», а публикация SSH, RDP и VNC идёт через «в том числе», то есть частным случаем. По букве ваш доступ под него подпадает и без публикации наружу.
Но пункт 6.2 говорит другое. Он требует MFA при административном доступе к инфраструктуре, с которой идёт доступ к пограничным устройствам. Если бы администратор сидел за АРМ физически, эта MFA была бы не нужна.
Выходит, удалённый доступ к самому АРМ документ допускает, запрещая удалённое администрирование устройств напрямую. Это ваш случай. Плюс пункт 1.4 называет PAM средством разграничения такого доступа.
Справедливо. Пометка «0 ₽» отвечала ровно на один вопрос: надо ли идти в бюджет за новой закупкой. Труд администратора в неё не заложен, хотя именно он и есть основная стоимость.
Про snmpv3 согласен: после каждого обновления железа настраивать заново, разовой такую работу не назовёшь.
«Ноль рублей сверх зарплаты» сформулировано точнее, чем у меня. Я исходил из того, что администраторы в организации уже есть, а рост задач конвертируется в деньги косвенно, через нагрузку и зарплаты, минуя счёт от вендора. В тексте этого не было, претензия честная.
Про резервные копии тут прямая ошибка. Пункт 4.2 требует три копии на двух типах носителей, одну из них обособленно, это место и железо. «0 ₽» там стоять не должно.
Поправил: у 4.2 теперь «зависит», в легенде оговорка про «ноль сверх зарплаты», в конце деление на капитальные затраты и операционные. Капитальных четыре, остальное операционные, и нулевыми они не бывают. Про капасити принимаю тоже: когда специалист один на всю инфраструктуру, разница между «не нужна закупка» и «некому делать» исчезает. Спасибо за ваши комменты, теперь стало точнее!
Спасибо за референс! У нас что-то похожее. Шаблон сами собрали по требованиям. И сейчас работаем над тем, чтобы связать это с управлением требованиями и мерами в GRC.
Про сохранённые суммы и даты. Выше в комментариях вы говорите, что не трогаете их намеренно, иначе база теряет ценность. Но связка «оклад, дата приёма, подразделение» в компании на полсотни человек указывает на сотрудника не хуже фамилии, а статья 3 152-ФЗ считает персональными данными информацию о прямо или косвенно определяемом лице. Такие сценарии считали?
Второе: ФИО в базе живут не только в справочниках. Журнал регистрации, комментарии в документах, присоединённые файлы. Ваш сканер их обходит или там остаются реальные значения?
И на будущее: то, что вы зовёте псевдонимизацией, в постановлении № 1154 называется введением идентификаторов. Ссылаться на него на проверке проще, чем на GDPR.
Нет, рядового пользователя это не касается. В пункте 1.2 методдока перечислены адресаты: госорганы, ГУПы, государственные учреждения, организации и субъекты КИИ. Это юрлица. Личный аккаунт гражданина под документ не подпадает ни при каком прочтении.
Отдельного списка нет, есть общий Государственный реестр сертифицированных СЗИ на reestr.fstec.ru, обновлён на прошлой неделе. Искать надо по типу средства, строчки «FIDO2» там не будет.
Дальше арифметика приказа 117. Пункт 71: средства должны быть сертифицированные и обеспечены поддержкой безопасности со стороны разработчика. Пункт 72 привязывает класс средства к классу системы: для первого класса защищённости не ниже четвёртого класса защиты и уровня доверия, для второго не ниже пятого, для третьего шестой.
И развилка: сам приказ 117 работает только с некриптографическими методами, а по пункту 7, если задействованы шифровальные средства, применяются требования ФСБ России по части 5 статьи 16 149-ФЗ. Другое ведомство, другой реестр.
Про пункт 28 вы правы: отсылка к одиннадцатому, а направления лежат в двенадцатом.
Механика такая. Таблица 2 применяется к каждому направлению отдельно: 8 видов требований со своими весами (выполнение 0,2, документирование и контроль по 0,15, остальные по 0,1), внутри вида градация 0, 0,5 или 1.
Пункт 29: вес умножить на градацию.
Пункт 30: сложить восемь чисел.
Пункт 31 и таблица 3: сравнить сумму с порогами 0,225, 0,35, 0,65, 0,9, плюс минимумы по отдельным требованиям.
Так рождается уровень направления, а пункт 10 сводит все направления в Узи организации.
Графика описана в пунктах 16 и 17: направления с целевыми значениями образуют профиль, по нему строится диаграмма с двумя величинами на каждое направление. Образец нарисован в самой методике, рисунок 1.
Про примеры согласен полностью. 21 направление на 8 требований дают 168 решений оценщика, и ни одного сквозного расчёта с цифрами в документе нет.
Хороший вопрос: passkey выводит из-под требования целиком. Мера ИАФ.3 начинается словами «при использовании простой (парольной) аутентификации», и все её цифры, 12 символов и смена через 90 дней, висят именно на пароле. Нет пароля, нет и ротации.
Аппаратный ключ в методдоке описан почти дословно. Второй фактор там определён как «владения физическим (аппаратным) устройством, знание секрета, подтверждающего право владения (распоряжения) этим устройством и (или) его биометрия». Это FIDO2, только без названия стандарта.
Засада не в нормативке, а в инвентаре. Пароль остаётся в резервных сценариях входа, на консолях и в сервисных учётных записях, и ротация тихо переезжает туда, где её никто не проверяет до первого аудита.
Спасибо за прямой ответ, особенно за второй сценарий. Валидация записи в учёте прямо при подключении устройства это то, к чему пункт 37 и ведёт: контроль конфигураций там опирается на результаты учёта ИТ-активов, а список внутри средства защиты остаётся вторичным.
Оговорка для госсектора. Сноска 12 к этому пункту адресует к Положению об учёте ИТ-активов из постановления Правительства № 900 от 1 июля 2024 года, там свои правила ведения. Заменить учёт не выйдет. Для коммерческой компании ваш базовый сценарий уже более применим, у них учёта часто нет вообще.
И практический вопрос. Когда AxelNAC видит устройство, которого в учёте нет, что происходит дальше: карантин, блокировка, оповещение? Пункт 37 требует ещё и выяснить причину изменения, а её обычно выясняет человек.
Мы такой расчёт сейчас доводим у себя в SGRC, поэтому смотрю на скриншот с профессиональным интересом.
Vinni37, это своя разработка или готовый продукт? По второй картинке видно, что собран уже и отчёт, то есть пройден весь шестой раздел методики.
У нас в личном кабинете мастер самооценки: 21 направление, формулы пунктов 29 и 30, пороги таблицы 3, профиль текущих уровней против целевых. Историю оценок добавляем в ближайшем релизе, без неё не работает пункт 33 про динамику.
Проверил первоисточник. Документ есть: «Рекомендации по защите сетевого периметра информационных (автоматизированных) систем», ФСТЭК, 10 марта 2026 года. Цифра 15 стоит в пункте 1.2, вы точны.
Дальше три оговорки. Это рекомендации, тогда как обязательная планка живёт в методическом документе, обязательном через пункт 68 приказа 117, и в мере ИАФ.3 там стоит 12 символов. Сам пункт 1.2 написан про сетевые пограничные устройства и включается только «в случае отсутствия возможности» авторизации по сертификатам, то есть до учётных записей пользователей в информационной системе он не дотягивается вовсе.
По теме статьи главное другое. Плановой смены пароля в рекомендациях нет: слово «ротация» встречается там дважды, оба раза про журналы событий. Документ полезный, спасибо.
Хороший вопрос, но, кажется, такая статистика на него бы и не ответила. Часть 3.1 статьи 21 отсчитывает 24 часа «с момента выявления такого инцидента оператором, уполномоченным органом по защите прав субъектов персональных данных или иным заинтересованным лицом» — то есть уведомление бывает и добровольным, и вынужденным, когда регулятор пришёл сам. В отчётности они неразличимы.
Косвенный индикатор всё же есть: часть 11 статьи 13.11, где молчание наказывается отдельно от утечки, 1–3 млн на юрлицо. Пойдут дела по ней — станет видно, сколько молчали. Если попадётся такая практика, буду признателен за наводку.
Про методику согласен, на 117-м это видно по датам: приказ вступил в силу 1 марта 2026-го, методика оценки вышла 11 ноября 2025-го, а методдок с составом мер — 12 апреля 2026-го, уже после. В проекте то же: показатель вводит пункт 9, считать его положено по методическим документам ФСТЭК. Методика от ноября считает защищённость, апрельский методдок — состав мер. Зрелость не считает ни один.
Занятно и с обозначениями: в 117-м показатель уровня зрелости обозначен Пзи, в проекте показатель с тем же названием — Узи. Считают их с разной периодичностью: раз в два года и раз в три.
Про подрядчиков вы попали в самое неудобное место. По пункту 10 оператор устанавливает требование к значению Узи для обработчика, и оценка идёт по той же схеме: перед началом обработки, раз в три года, после инцидента у него. Что делать, если он значение не подтверждает, в тексте проекта я не нашёл.
Вы были правы, а я нет. Пошёл проверять вашу развилку про статус методичек и нашёл требование к ротации.
Сам статус приказ решает, пункт 68: меры «должны реализовываться оператором с использованием методических документов ФСТЭК России». Отсылка обязывающая.
А 12 апреля 2026 ФСТЭК утвердила методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах», которым отменён документ 2014 года по мерам в ГИС. Мера ИАФ.3: длина пароля не менее 12 символов, алфавит не менее 70, пять неудачных попыток до блокировки, «смена паролей не более чем через 90 дней», повторно использовать пароль запрещено. Для мобильных устройств мера ЗМУ.1 жёстче: 30 дней и запрет на 12 последних паролей. ИАФ.3 обязательна для всех классов защищённости, К3, К2 и К1.
Границу очерчу сам, чтобы не расширять лишнего. Пункт 1.2 адресует документ госорганам, ГУПам, госучреждениям и субъектам КИИ. Для обычной коммерческой компании вне этого контура ничего не поменялось, ваш разбор там работает целиком.
Так что мой факт про приказ верен, а вывод из него нет. Ротацию переставили этажом ниже, в методический документ.
Согласен, действия при отзыве касаются исходной базы. Хочу уточнить одну деталь, она недавно стала нормой.
С 1 сентября 2025 действует постановление Правительства № 1154, там перечислены методы обезличивания. Первый в списке: «метод введения идентификаторов - замена части сведений (значений персональных данных) идентификаторами с созданием таблицы (справочника) соответствия идентификаторов исходным персональным данным». То есть таблица соответствия обезличиванию не мешает, метод законный. Требование другое, пункт 2 «б»: раздельное хранение персональных данных и обезличенных данных.
Отсюда и практический вывод. Обезличенный массив живёт своей жизнью, вы правы. А таблица соответствия остаётся персональными данными, потому что пункт 9 статьи 3 152-ФЗ определяет обезличивание как невозможность установить принадлежность «без использования дополнительной информации», и эта таблица ей и является. При отзыве согласия чистить надо и её, иначе исходную базу вы удалили, а ключ к деперсонализированной остался.
Про две крайности точно подмечено. По моему опыту они растут из одного корня. Пока в компании нет человека, который сам читал требования, решение принимается по ощущению: у кого ощущение тревожное, тот заказывает всё подряд с запасом, у кого спокойное, тот не делает вообще ничего.
Со второй группой интересно то, как она обычно узнаёт о требованиях. Не от Роскомнадзора и не из новостей про штрафы. Приходит крупный заказчик, присылает анкету по защите данных перед подписанием договора, а ответить на половину вопросов нечем. Сделка встаёт. Работает это заметно лучше страха проверки.
Про 76-й спасибо, я его упустил, а он сюда правда просится. Сроки там даже интереснее: 72 часа на доведение информации о недостатке и компенсирующих мерах для 5 уровня доверия (п. 22.2), 48 часов для 4 уровня (п. 22.3), доработка средства в срок не более 60 дней (п. 22.2).
Предмет там другой: у вас про изготовителя сертифицированного средства, у меня про оператора и пункт 38. Обязанности идут параллельно, и вместе картина полнее. Забавно, что обе нормы ссылаются на один и тот же подпункт 21 пункта 8 Положения о ФСТЭК, то есть в БДУ сведения стекаются с двух сторон.
А вот второй ваш абзац бьёт сильнее, чем весь мой пост. Если вендор находит общеизвестную уязвимость только на продлении сертификата, то оператор про неё узнаёт последним, а пятидневный срок по пункту 38 у него уже тикает с момента собственного выявления. Две нормы про одну уязвимость живут в разных календарях, и крайним оказывается тот, кто эксплуатирует.
Про «кто только не хайпит» спорить не буду, поток статей про 117 плотный, сам в него и добавил.
Приказ модель не задаёт, отсылает к методике анализа защищённости от 25 ноября 2025 года. Там работы делятся на внешний и внутренний анализ, а исполнителю передают состав ПО, карту сети и учётные данные. Чёрного ящика методика не предполагает, нарушитель берётся из модели угроз системы.
Сама она при этом про анализ уязвимостей, пентест в ней не описан. Отдельной методики под него не нашёл.
Про время критерия нет вообще: либо доступ получен или привилегии повышены, либо нет.
Вы правы, и на два вопроса из трёх ответ в документе всё же есть.
Про то чья поддержка: пункт 1.6 требует учитывать «сроки технической поддержки со стороны производителей». Думаю, и в 1.7 речь про вендорскую.
Про community-каналы прямого ответа нет, но есть критерий. Пункт 7.3 требует оповещать ИБ об обновлениях «из непредусмотренных источников», а пункт 7.2 велит писать в журнал источник обновления, вплоть до URL или репозитория, и подтверждённые подписи либо контрольные суммы. Выходит, источник может быть любым, если он заранее предусмотрен и проверяем. Поддержкой в смысле пункта 1.7 это не становится, компенсирующие меры всё равно нужны.
А про облака да, возразить нечем. Про облако, VPN туннель и удалённую работу - ноль вхождений. Аварийного доступа тоже нет, пункт 3.4 обрывается на оговорке «при сохранении основных функций ядра сети».
Пункт 1.8 строже, чем кажется: там «исключить удалённое администрирование», а публикация SSH, RDP и VNC идёт через «в том числе», то есть частным случаем. По букве ваш доступ под него подпадает и без публикации наружу.
Но пункт 6.2 говорит другое. Он требует MFA при административном доступе к инфраструктуре, с которой идёт доступ к пограничным устройствам. Если бы администратор сидел за АРМ физически, эта MFA была бы не нужна.
Выходит, удалённый доступ к самому АРМ документ допускает, запрещая удалённое администрирование устройств напрямую. Это ваш случай. Плюс пункт 1.4 называет PAM средством разграничения такого доступа.
Справедливо. Пометка «0 ₽» отвечала ровно на один вопрос: надо ли идти в бюджет за новой закупкой. Труд администратора в неё не заложен, хотя именно он и есть основная стоимость.
Про snmpv3 согласен: после каждого обновления железа настраивать заново, разовой такую работу не назовёшь.
«Ноль рублей сверх зарплаты» сформулировано точнее, чем у меня. Я исходил из того, что администраторы в организации уже есть, а рост задач конвертируется в деньги косвенно, через нагрузку и зарплаты, минуя счёт от вендора. В тексте этого не было, претензия честная.
Про резервные копии тут прямая ошибка. Пункт 4.2 требует три копии на двух типах носителей, одну из них обособленно, это место и железо. «0 ₽» там стоять не должно.
Поправил: у 4.2 теперь «зависит», в легенде оговорка про «ноль сверх зарплаты», в конце деление на капитальные затраты и операционные. Капитальных четыре, остальное операционные, и нулевыми они не бывают. Про капасити принимаю тоже: когда специалист один на всю инфраструктуру, разница между «не нужна закупка» и «некому делать» исчезает. Спасибо за ваши комменты, теперь стало точнее!
Спасибо за референс! У нас что-то похожее. Шаблон сами собрали по требованиям. И сейчас работаем над тем, чтобы связать это с управлением требованиями и мерами в GRC.
Про сохранённые суммы и даты. Выше в комментариях вы говорите, что не трогаете их намеренно, иначе база теряет ценность. Но связка «оклад, дата приёма, подразделение» в компании на полсотни человек указывает на сотрудника не хуже фамилии, а статья 3 152-ФЗ считает персональными данными информацию о прямо или косвенно определяемом лице. Такие сценарии считали?
Второе: ФИО в базе живут не только в справочниках. Журнал регистрации, комментарии в документах, присоединённые файлы. Ваш сканер их обходит или там остаются реальные значения?
И на будущее: то, что вы зовёте псевдонимизацией, в постановлении № 1154 называется введением идентификаторов. Ссылаться на него на проверке проще, чем на GDPR.
Нет, рядового пользователя это не касается. В пункте 1.2 методдока перечислены адресаты: госорганы, ГУПы, государственные учреждения, организации и субъекты КИИ. Это юрлица. Личный аккаунт гражданина под документ не подпадает ни при каком прочтении.
Отдельного списка нет, есть общий Государственный реестр сертифицированных СЗИ на reestr.fstec.ru, обновлён на прошлой неделе. Искать надо по типу средства, строчки «FIDO2» там не будет.
Дальше арифметика приказа 117. Пункт 71: средства должны быть сертифицированные и обеспечены поддержкой безопасности со стороны разработчика. Пункт 72 привязывает класс средства к классу системы: для первого класса защищённости не ниже четвёртого класса защиты и уровня доверия, для второго не ниже пятого, для третьего шестой.
И развилка: сам приказ 117 работает только с некриптографическими методами, а по пункту 7, если задействованы шифровальные средства, применяются требования ФСБ России по части 5 статьи 16 149-ФЗ. Другое ведомство, другой реестр.
Кзи и Узи в одном интерфейсе это сильно.
А отчёт по пункту 35 выводите свой? Там тринадцать подпунктов, из них графическая интерпретация и план мероприятий со сроками и ответственными.
Спасибо за прямой ответ, особенно за второй сценарий. Валидация записи в учёте прямо при подключении устройства это то, к чему пункт 37 и ведёт: контроль конфигураций там опирается на результаты учёта ИТ-активов, а список внутри средства защиты остаётся вторичным.
Оговорка для госсектора. Сноска 12 к этому пункту адресует к Положению об учёте ИТ-активов из постановления Правительства № 900 от 1 июля 2024 года, там свои правила ведения. Заменить учёт не выйдет. Для коммерческой компании ваш базовый сценарий уже более применим, у них учёта часто нет вообще.
И практический вопрос. Когда AxelNAC видит устройство, которого в учёте нет, что происходит дальше: карантин, блокировка, оповещение? Пункт 37 требует ещё и выяснить причину изменения, а её обычно выясняет человек.
Мы такой расчёт сейчас доводим у себя в SGRC, поэтому смотрю на скриншот с профессиональным интересом.
Vinni37, это своя разработка или готовый продукт? По второй картинке видно, что собран уже и отчёт, то есть пройден весь шестой раздел методики.
У нас в личном кабинете мастер самооценки: 21 направление, формулы пунктов 29 и 30, пороги таблицы 3, профиль текущих уровней против целевых. Историю оценок добавляем в ближайшем релизе, без неё не работает пункт 33 про динамику.
Проверил первоисточник. Документ есть: «Рекомендации по защите сетевого периметра информационных (автоматизированных) систем», ФСТЭК, 10 марта 2026 года. Цифра 15 стоит в пункте 1.2, вы точны.
Дальше три оговорки. Это рекомендации, тогда как обязательная планка живёт в методическом документе, обязательном через пункт 68 приказа 117, и в мере ИАФ.3 там стоит 12 символов. Сам пункт 1.2 написан про сетевые пограничные устройства и включается только «в случае отсутствия возможности» авторизации по сертификатам, то есть до учётных записей пользователей в информационной системе он не дотягивается вовсе.
По теме статьи главное другое. Плановой смены пароля в рекомендациях нет: слово «ротация» встречается там дважды, оба раза про журналы событий. Документ полезный, спасибо.
Хороший вопрос, но, кажется, такая статистика на него бы и не ответила. Часть 3.1 статьи 21 отсчитывает 24 часа «с момента выявления такого инцидента оператором, уполномоченным органом по защите прав субъектов персональных данных или иным заинтересованным лицом» — то есть уведомление бывает и добровольным, и вынужденным, когда регулятор пришёл сам. В отчётности они неразличимы.
Косвенный индикатор всё же есть: часть 11 статьи 13.11, где молчание наказывается отдельно от утечки, 1–3 млн на юрлицо. Пойдут дела по ней — станет видно, сколько молчали. Если попадётся такая практика, буду признателен за наводку.
Про методику согласен, на 117-м это видно по датам: приказ вступил в силу 1 марта 2026-го, методика оценки вышла 11 ноября 2025-го, а методдок с составом мер — 12 апреля 2026-го, уже после. В проекте то же: показатель вводит пункт 9, считать его положено по методическим документам ФСТЭК. Методика от ноября считает защищённость, апрельский методдок — состав мер. Зрелость не считает ни один.
Занятно и с обозначениями: в 117-м показатель уровня зрелости обозначен Пзи, в проекте показатель с тем же названием — Узи. Считают их с разной периодичностью: раз в два года и раз в три.
Про подрядчиков вы попали в самое неудобное место. По пункту 10 оператор устанавливает требование к значению Узи для обработчика, и оценка идёт по той же схеме: перед началом обработки, раз в три года, после инцидента у него. Что делать, если он значение не подтверждает, в тексте проекта я не нашёл.
Вы были правы, а я нет. Пошёл проверять вашу развилку про статус методичек и нашёл требование к ротации.
Сам статус приказ решает, пункт 68: меры «должны реализовываться оператором с использованием методических документов ФСТЭК России». Отсылка обязывающая.
А 12 апреля 2026 ФСТЭК утвердила методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах», которым отменён документ 2014 года по мерам в ГИС. Мера ИАФ.3: длина пароля не менее 12 символов, алфавит не менее 70, пять неудачных попыток до блокировки, «смена паролей не более чем через 90 дней», повторно использовать пароль запрещено. Для мобильных устройств мера ЗМУ.1 жёстче: 30 дней и запрет на 12 последних паролей. ИАФ.3 обязательна для всех классов защищённости, К3, К2 и К1.
Границу очерчу сам, чтобы не расширять лишнего. Пункт 1.2 адресует документ госорганам, ГУПам, госучреждениям и субъектам КИИ. Для обычной коммерческой компании вне этого контура ничего не поменялось, ваш разбор там работает целиком.
Так что мой факт про приказ верен, а вывод из него нет. Ротацию переставили этажом ниже, в методический документ.
Согласен, действия при отзыве касаются исходной базы. Хочу уточнить одну деталь, она недавно стала нормой.
С 1 сентября 2025 действует постановление Правительства № 1154, там перечислены методы обезличивания. Первый в списке: «метод введения идентификаторов - замена части сведений (значений персональных данных) идентификаторами с созданием таблицы (справочника) соответствия идентификаторов исходным персональным данным». То есть таблица соответствия обезличиванию не мешает, метод законный. Требование другое, пункт 2 «б»: раздельное хранение персональных данных и обезличенных данных.
Отсюда и практический вывод. Обезличенный массив живёт своей жизнью, вы правы. А таблица соответствия остаётся персональными данными, потому что пункт 9 статьи 3 152-ФЗ определяет обезличивание как невозможность установить принадлежность «без использования дополнительной информации», и эта таблица ей и является. При отзыве согласия чистить надо и её, иначе исходную базу вы удалили, а ключ к деперсонализированной остался.
Про две крайности точно подмечено. По моему опыту они растут из одного корня. Пока в компании нет человека, который сам читал требования, решение принимается по ощущению: у кого ощущение тревожное, тот заказывает всё подряд с запасом, у кого спокойное, тот не делает вообще ничего.
Со второй группой интересно то, как она обычно узнаёт о требованиях. Не от Роскомнадзора и не из новостей про штрафы. Приходит крупный заказчик, присылает анкету по защите данных перед подписанием договора, а ответить на половину вопросов нечем. Сделка встаёт. Работает это заметно лучше страха проверки.
Про 76-й спасибо, я его упустил, а он сюда правда просится. Сроки там даже интереснее: 72 часа на доведение информации о недостатке и компенсирующих мерах для 5 уровня доверия (п. 22.2), 48 часов для 4 уровня (п. 22.3), доработка средства в срок не более 60 дней (п. 22.2).
Предмет там другой: у вас про изготовителя сертифицированного средства, у меня про оператора и пункт 38. Обязанности идут параллельно, и вместе картина полнее. Забавно, что обе нормы ссылаются на один и тот же подпункт 21 пункта 8 Положения о ФСТЭК, то есть в БДУ сведения стекаются с двух сторон.
А вот второй ваш абзац бьёт сильнее, чем весь мой пост. Если вендор находит общеизвестную уязвимость только на продлении сертификата, то оператор про неё узнаёт последним, а пятидневный срок по пункту 38 у него уже тикает с момента собственного выявления. Две нормы про одну уязвимость живут в разных календарях, и крайним оказывается тот, кто эксплуатирует.
Про «кто только не хайпит» спорить не буду, поток статей про 117 плотный, сам в него и добавил.