Вы были правы, а я нет. Пошёл проверять вашу развилку про статус методичек и нашёл требование к ротации.
Сам статус приказ решает, пункт 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 плотный, сам в него и добавил.
Для государственных систем у этой картины появился нормативный якорь, и он ближе к NAC, чем кажется.
Приказ ФСТЭК № 117 действует с 1 марта 2026 года. Пункт 37: контроль конфигураций должен «осуществляться на основе анализа результатов учёта ИТ-активов и (или) сведений, содержащихся в автоматизированных системах хранения и управления данными об информационных системах и их конфигурациях». Со сноской на Положение об учёте ИТ-активов, утверждённое постановлением Правительства № 900 от 1 июля 2024 года.
Требование тут шире, чем «знайте свои устройства». Контроль строится поверх учёта активов, и отдельно оговорено: подразделению по защите информации нужен доступ к этим сведениям. NAC даёт живой слой таких данных, если его инвентаризацию не держат в отрыве от учётной системы.
Интересно, как у ваших внедрений с этим стыком: NAC ведёт свой список устройств или подтягивает его из учёта ИТ-активов?
К механике стоит добавить одну обязанность, про которую вспоминают в последнюю очередь.
Если авторизация уводит данные пользователя в зарубежный сервис, это трансграничная передача, а по части 3 статьи 12 152-ФЗ оператор обязан уведомить Роскомнадзор до начала такой передачи. Норма прямо оговаривает: это уведомление направляется отдельно от уведомления о намерении обрабатывать данные по статье 22. Два разных документа, и второй не заменяет первого.
На практике это чаще всего и всплывает: уведомление об обработке подано пять лет назад, кнопка входа через внешний сервис появилась позже, отдельного уведомления никто не отправлял.
Кто-нибудь уже получал ответ регулятора на такое уведомление и в какой срок?
Каталог полей с ПДн — это ровно та вещь, которой обычно не хватает в самый неудобный момент.
Когда приходит требование субъекта об уничтожении, оператору нужно подтвердить его двумя документами, если обработка автоматизированная: приказ Роскомнадзора № 179 требует акт об уничтожении и выгрузку из журнала регистрации событий в ИСПДн. В выгрузке среди прочего должны быть перечень категорий уничтоженных данных и наименование системы, а это как раз то, что из журнала само не берётся: движок знает учётную запись и таблицу, а не «категорию ПДн».
С вашим каталогом на 5500 полей эта графа перестаёт быть ручной работой: категории уже разложены, остаётся связать их с записями журнала. Плюс п. 6 того же приказа: чего в выгрузке нет, вносится в акт, так что закрывать все пять полей логами не обязательно.
Интересно, дошли ли вы до сроков хранения по каждому полю. По моему опыту это следующий вопрос, который задаёт проверяющий после «а где у вас перечень».
У молчаливой потери 4% журнала есть неожиданное юридическое продолжение.
Если оператор уничтожает персональные данные автоматизированно, подтверждением служат два документа: акт и выгрузка из журнала регистрации событий (приказ Роскомнадзора № 179). Причём выгрузка там понимается узко. Это конкретный набор сведений: субъект, категории данных, наименование системы, причина и дата уничтожения.
Парсер, который тихо пропускает часть записей и не считает это ошибкой, ломает как раз доказательство. На проверке предъявляют не журнал целиком, а выборку из него.
Разница между «прочитали 96%» и «прочитали всё» тут не про качество данных. Она про то, чем оператор докажет уничтожение конкретной записи.
Ваш подход с явным различением «не прочитано» и «прочитано пусто» для такой задачи как раз то, что нужно. Пробовали прогонять на выгрузках, где записи удаляли по ротации?
Спасибо за разбор, тут нечего добавить по фактуре дела. Добавлю то, что начинается для работодателя на следующий день.
В файле были фамилии и зарплаты, то есть персональные данные, и они ушли во внешний сервис без основания. Для оператора это инцидент по части 3.1 статьи 21 152-ФЗ, а там сроки: 24 часа на уведомление РКН о самом инциденте и 72 часа на результаты внутреннего расследования, со сведениями о лицах, действия которых стали его причиной. Отсчёт идёт с момента выявления, а не с момента, когда юристы договорились о позиции.
Забавная сторона этого кейса в том, что служебное расследование как раз собрало всё, что требует пункт 2: и лицо, и обстоятельства, и объём. Материалы для суда и материалы для регулятора здесь почти совпадают, только адресаты разные.
Молчание тарифицируется отдельно от самой утечки: часть 11 статьи 13.11 КоАП, от одного до трёх миллионов для юрлица.
Интересно, попадают ли такие эпизоды в статистику уведомлений вообще. Подозреваю, что через суд их видно чаще, чем через РКН.
Про «мера существует потому, что есть угроза» есть ещё один аргумент, нормативный, и он на вашей стороне сильнее, чем кажется.
В приказе ФСТЭК № 117 слова «пароль» нет вообще, ни разу, ни в каком склонении. Проверял и по тексту из КонсультантПлюс, и по PDF самого приказа. Есть пункт 14 «д»: во внутреннем регламенте оператор устанавливает «порядок создания, изменения, блокирования, контроля, удаления аутентификационной информации и средств аутентификации». Ни срока, ни периодичности, ни самого понятия ротации.
Оговорюсь честно: отчасти дело в смене формата. В 117 нет таблицы мер с кодами, где в 17 и 21 жила АНЗ.5 «контроль правил генерации и смены паролей пользователей». Но и в тех приказах требования менять пароли по календарю не было, был контроль правил, которые оператор устанавливает сам.
Получается, довод «мы обязаны менять раз в 90 дней, так требует ФСТЭК» проверяется поиском по тексту приказа за минуту. Требования нет. Есть обязанность иметь порядок и его соблюдать, а содержание порядка выводит оператор, из своей модели угроз. Ровно тот путь, который вы описали в разделе 1.1.
Отдельно любопытно, что аудиторы спрашивают про сроки ротации по привычке. Попадался ли вам после марта отказ в аттестации именно из-за отсутствия плановой смены?
Супер, вы разложили ещё точнее, чем я писал! И я как раз про п. 6 хотел написать следующим ходом. Понравилась ваша формула: лог обязан быть тем, «из чего акт заполняется не по памяти».
Тогда добавлю последнее, что осталось: п. 4 признаёт акт в электронной форме, подписанный по 63-ФЗ, равнозначным бумажному. Подписант остаётся человеком, но сам акт может жить в том же цифровом контуре, что и ваш процесс. Бумага из схемы уходит, ответственность нет.
Было бы здорово, если разберёте «Чем доказать, что удалил». С удовольствием почитаю, спасибо.
Пункт 38 и правда даёт альтернативу прямым текстом: «устранение уязвимостей... или исключение возможности их использования за счёт применения компенсирующих мер». Патч в 24 часа не обязателен, если риск закрыт иначе.
Добавлю в вашу пользу: п. 39 привязывает сроки обновлений к срокам устранения «и рисков, связанных с применением обновлений». Риск самого патча норма учитывать разрешает, так что плановый цикл имеет право быть длиннее.
Тогда вопрос возвращается туда, где он у вас в статье и стоял. Связь между двумя регламентами должна быть где-то прописана.
Подстановка идентификатора из результата предыдущего узла работает лучше любого регламента, тут соглашусь.
Удаление учётки сотрудника это ещё и уничтожение его персональных данных. Подтверждать его надо документом, и на проверке спрашивают именно его. Приказ РКН № 179: при обработке с использованием средств автоматизации подтверждающих документов два, акт об уничтожении и выгрузка из журнала регистрации событий в ИСПДн.
Ваш движок к этому ближе типовой инструкции: он и результат узла сохраняет, и текст ошибки не теряет, так что выгрузку он фактически уже формирует, вопрос только в том, попадает ли в лог нужное. Кто, что именно, когда и на каком основании.
Резервная копия уходящего, кстати, тоже не бессрочная. У неё должны быть цель и срок хранения.
Про конфликт двух регламентов. Если система государственная, это уже не только вопрос договорённости ИБ с ИТ.
Приказ 117, п. 39: сроки применения обновлений «устанавливаются во внутреннем регламенте по защите информации в зависимости от сроков устранения уязвимостей соответствующих уровней опасности». Получается, если в регламенте обновлений стоит 90 дней, а критические уязвимости закрываются за 24 часа, то ломается уже само требование пункта: сроки обновлений должны выводиться из сроков устранения, а не жить отдельной жизнью. Стыковка двух документов тут вторична.
Из того же п. 38: если уязвимость нашли, а в БДУ её нет, есть встречная обязанность отправить сведения во ФСТЭК за 5 рабочих дней. Про БДУ помнят как про источник, откуда берут.
Вы были правы, а я нет. Пошёл проверять вашу развилку про статус методичек и нашёл требование к ротации.
Сам статус приказ решает, пункт 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 плотный, сам в него и добавил.
Для государственных систем у этой картины появился нормативный якорь, и он ближе к NAC, чем кажется.
Приказ ФСТЭК № 117 действует с 1 марта 2026 года. Пункт 37: контроль конфигураций должен «осуществляться на основе анализа результатов учёта ИТ-активов и (или) сведений, содержащихся в автоматизированных системах хранения и управления данными об информационных системах и их конфигурациях». Со сноской на Положение об учёте ИТ-активов, утверждённое постановлением Правительства № 900 от 1 июля 2024 года.
Требование тут шире, чем «знайте свои устройства». Контроль строится поверх учёта активов, и отдельно оговорено: подразделению по защите информации нужен доступ к этим сведениям. NAC даёт живой слой таких данных, если его инвентаризацию не держат в отрыве от учётной системы.
Интересно, как у ваших внедрений с этим стыком: NAC ведёт свой список устройств или подтягивает его из учёта ИТ-активов?
К механике стоит добавить одну обязанность, про которую вспоминают в последнюю очередь.
Если авторизация уводит данные пользователя в зарубежный сервис, это трансграничная передача, а по части 3 статьи 12 152-ФЗ оператор обязан уведомить Роскомнадзор до начала такой передачи. Норма прямо оговаривает: это уведомление направляется отдельно от уведомления о намерении обрабатывать данные по статье 22. Два разных документа, и второй не заменяет первого.
На практике это чаще всего и всплывает: уведомление об обработке подано пять лет назад, кнопка входа через внешний сервис появилась позже, отдельного уведомления никто не отправлял.
Кто-нибудь уже получал ответ регулятора на такое уведомление и в какой срок?
Каталог полей с ПДн — это ровно та вещь, которой обычно не хватает в самый неудобный момент.
Когда приходит требование субъекта об уничтожении, оператору нужно подтвердить его двумя документами, если обработка автоматизированная: приказ Роскомнадзора № 179 требует акт об уничтожении и выгрузку из журнала регистрации событий в ИСПДн. В выгрузке среди прочего должны быть перечень категорий уничтоженных данных и наименование системы, а это как раз то, что из журнала само не берётся: движок знает учётную запись и таблицу, а не «категорию ПДн».
С вашим каталогом на 5500 полей эта графа перестаёт быть ручной работой: категории уже разложены, остаётся связать их с записями журнала. Плюс п. 6 того же приказа: чего в выгрузке нет, вносится в акт, так что закрывать все пять полей логами не обязательно.
Интересно, дошли ли вы до сроков хранения по каждому полю. По моему опыту это следующий вопрос, который задаёт проверяющий после «а где у вас перечень».
У молчаливой потери 4% журнала есть неожиданное юридическое продолжение.
Если оператор уничтожает персональные данные автоматизированно, подтверждением служат два документа: акт и выгрузка из журнала регистрации событий (приказ Роскомнадзора № 179). Причём выгрузка там понимается узко. Это конкретный набор сведений: субъект, категории данных, наименование системы, причина и дата уничтожения.
Парсер, который тихо пропускает часть записей и не считает это ошибкой, ломает как раз доказательство. На проверке предъявляют не журнал целиком, а выборку из него.
Разница между «прочитали 96%» и «прочитали всё» тут не про качество данных. Она про то, чем оператор докажет уничтожение конкретной записи.
Ваш подход с явным различением «не прочитано» и «прочитано пусто» для такой задачи как раз то, что нужно. Пробовали прогонять на выгрузках, где записи удаляли по ротации?
Спасибо за разбор, тут нечего добавить по фактуре дела. Добавлю то, что начинается для работодателя на следующий день.
В файле были фамилии и зарплаты, то есть персональные данные, и они ушли во внешний сервис без основания. Для оператора это инцидент по части 3.1 статьи 21 152-ФЗ, а там сроки: 24 часа на уведомление РКН о самом инциденте и 72 часа на результаты внутреннего расследования, со сведениями о лицах, действия которых стали его причиной. Отсчёт идёт с момента выявления, а не с момента, когда юристы договорились о позиции.
Забавная сторона этого кейса в том, что служебное расследование как раз собрало всё, что требует пункт 2: и лицо, и обстоятельства, и объём. Материалы для суда и материалы для регулятора здесь почти совпадают, только адресаты разные.
Молчание тарифицируется отдельно от самой утечки: часть 11 статьи 13.11 КоАП, от одного до трёх миллионов для юрлица.
Интересно, попадают ли такие эпизоды в статистику уведомлений вообще. Подозреваю, что через суд их видно чаще, чем через РКН.
Про «мера существует потому, что есть угроза» есть ещё один аргумент, нормативный, и он на вашей стороне сильнее, чем кажется.
В приказе ФСТЭК № 117 слова «пароль» нет вообще, ни разу, ни в каком склонении. Проверял и по тексту из КонсультантПлюс, и по PDF самого приказа. Есть пункт 14 «д»: во внутреннем регламенте оператор устанавливает «порядок создания, изменения, блокирования, контроля, удаления аутентификационной информации и средств аутентификации». Ни срока, ни периодичности, ни самого понятия ротации.
Оговорюсь честно: отчасти дело в смене формата. В 117 нет таблицы мер с кодами, где в 17 и 21 жила АНЗ.5 «контроль правил генерации и смены паролей пользователей». Но и в тех приказах требования менять пароли по календарю не было, был контроль правил, которые оператор устанавливает сам.
Получается, довод «мы обязаны менять раз в 90 дней, так требует ФСТЭК» проверяется поиском по тексту приказа за минуту. Требования нет. Есть обязанность иметь порядок и его соблюдать, а содержание порядка выводит оператор, из своей модели угроз. Ровно тот путь, который вы описали в разделе 1.1.
Отдельно любопытно, что аудиторы спрашивают про сроки ротации по привычке. Попадался ли вам после марта отказ в аттестации именно из-за отсутствия плановой смены?
Супер, вы разложили ещё точнее, чем я писал! И я как раз про п. 6 хотел написать следующим ходом. Понравилась ваша формула: лог обязан быть тем, «из чего акт заполняется не по памяти».
Тогда добавлю последнее, что осталось: п. 4 признаёт акт в электронной форме, подписанный по 63-ФЗ, равнозначным бумажному. Подписант остаётся человеком, но сам акт может жить в том же цифровом контуре, что и ваш процесс. Бумага из схемы уходит, ответственность нет.
Было бы здорово, если разберёте «Чем доказать, что удалил». С удовольствием почитаю, спасибо.
Справедливо, я сформулировал слишком широко.
Пункт 38 и правда даёт альтернативу прямым текстом: «устранение уязвимостей... или исключение возможности их использования за счёт применения компенсирующих мер». Патч в 24 часа не обязателен, если риск закрыт иначе.
Добавлю в вашу пользу: п. 39 привязывает сроки обновлений к срокам устранения «и рисков, связанных с применением обновлений». Риск самого патча норма учитывать разрешает, так что плановый цикл имеет право быть длиннее.
Тогда вопрос возвращается туда, где он у вас в статье и стоял. Связь между двумя регламентами должна быть где-то прописана.
Подстановка идентификатора из результата предыдущего узла работает лучше любого регламента, тут соглашусь.
Удаление учётки сотрудника это ещё и уничтожение его персональных данных. Подтверждать его надо документом, и на проверке спрашивают именно его. Приказ РКН № 179: при обработке с использованием средств автоматизации подтверждающих документов два, акт об уничтожении и выгрузка из журнала регистрации событий в ИСПДн.
Ваш движок к этому ближе типовой инструкции: он и результат узла сохраняет, и текст ошибки не теряет, так что выгрузку он фактически уже формирует, вопрос только в том, попадает ли в лог нужное. Кто, что именно, когда и на каком основании.
Резервная копия уходящего, кстати, тоже не бессрочная. У неё должны быть цель и срок хранения.
Про конфликт двух регламентов. Если система государственная, это уже не только вопрос договорённости ИБ с ИТ.
Приказ 117, п. 39: сроки применения обновлений «устанавливаются во внутреннем регламенте по защите информации в зависимости от сроков устранения уязвимостей соответствующих уровней опасности». Получается, если в регламенте обновлений стоит 90 дней, а критические уязвимости закрываются за 24 часа, то ломается уже само требование пункта: сроки обновлений должны выводиться из сроков устранения, а не жить отдельной жизнью. Стыковка двух документов тут вторична.
Из того же п. 38: если уязвимость нашли, а в БДУ её нет, есть встречная обязанность отправить сведения во ФСТЭК за 5 рабочих дней. Про БДУ помнят как про источник, откуда берут.