Государства по всему миру переходят от разовых уведомлений о киберинцидентах к модели непрерывной осведомленности — с быстрыми сигналами, регулярными обновлениями и централизованным сбором данных. Это меняет не только требования регуляторов, но и саму логику работы бизнеса с инцидентами, превращая уведомление в отдельную управленческую функцию. О том, к чему ведет эта трансформация и какие риски она несет, — в материале IT-World.
Когда-то уведомление об инциденте было скорее исключением: произошло что-то серьезное, компания разобралась, составила письмо, сообщила регулятору и начала устранять последствия или не замечать их. Эта логика стремительно уходит в прошлое. На наших глазах возникает другая модель: государству уже недостаточно узнать о факте инцидента задним числом. Ему нужен более ранний сигнал, более частые обновления, единый формат, а в идеале — почти непрерывное понимание происходящего. И это касается уже не только классической кибербезопасности, но и регулирования искусственного интеллекта.
Именно поэтому так показателен сдвиг, который виден в регулировании ИИ. В Евросоюзе AI Act требует для высокорискованных ИИ-систем не просто соответствия «на момент вывода на рынок», а непрерывного мониторинга, то есть постоянного сбора и анализа данных о работе системы после ее внедрения, а также отдельного информирования о серьезных инцидентах. Иными словами, регулятору важен не только момент допуска технологии до граждан, но и ее поведение в эксплуатации. Точно такая же норма зафиксирована в отечественном законопроекте о регулировании и доверенности ИИ, которая требует непрерывного мониторинга последствий применения ИИ на основе данных от самих операторов ИИ. Все это очень близко к тому, что уже давно происходит в кибербезопасности: от разового уведомления мы движемся к постоянно действующему каналу наблюдаемости.
Уведомление как новая регуляторная дисциплина
В России этот поворот особенно заметен, потому что у нас уже складывается не один режим уведомления, а целая мозаика параллельных обязательств. Оператор персональных данных обязан уведомить Роскомнадзор о нарушении безопасности персональных данных в течение 24 часов с момента выявления инцидента, а затем в течение 72 часов направить результаты внутреннего расследования. То есть даже в сфере персональных данных модель уже не одноактная: сначала ранний сигнал, потом уточнение. Эта двухтактность — важный симптом нового подхода, которого начинают придерживаться и другие регуляторы, и от него всего один шаг до непрерывного контроля, а то до и полного доступа регуляторов в ИТ-контуры российских организаций.
Если смотреть шире, российская компания в ряде отраслей и режимов вынуждена жить не с одной обязанностью сообщать, а сразу с несколькими. Помимо Роскомнадзора есть контуры критической информационной инфраструктуры (КИИ) и ГосСОПКА (государственной системы обнаружения, предупреждения и ликвидации последствий компьютерных атак), есть отраслевые требования финансового сектора и взаимодействие с ФинЦЕРТ Банка России, который объединяет почти две тысячи организаций, включая все российские банки, для обмена информацией об инцидентах и угрозах. А ведь у нас еще есть недавно запущенная государственная система противодействия правонарушениям, совершаемым с использованием информационно-коммуникационных технологий (ГИС «Антифрод»), у которой свои требования об уведомлениях о мошеннических действиях. Это уже не просто почтовый ящик регулятора, а инфраструктура постоянного обмена сигналами о грядущей или случившейся беде в киберпространстве.
Для субъектов, владеющих значимыми объектами КИИ, регламенты еще жестче. По требованиям ГосСОПКА, организации из сферы КИИ должны информировать ФСБ не позднее трех часов после обнаружения компьютерного инцидента, связанного со значимым объектом КИИ; для иных объектов срок дольше, но не превышает 24 часов; независимо от того, произошел инцидент в выходные дни или в длинные новогодние праздники. Неуведомление является административным правонарушением и влечет за собой штраф (за каждое нарушение). Даже если оставить за скобками детали правоприменения, сам принцип очевиден: здесь речь идет уже не о «спокойном постфактум-отчете», а о фактическом включении компании в контур государственного ситуационного реагирования.
Это важно понимать: российская картина уже сейчас подталкивает компании к мысли, что инцидент нельзя больше рассматривать только как внутреннее дело собственной ИБ-службы. Один и тот же эпизод может затрагивать персональные данные, критическую инфраструктуру, финансовые сервисы, биометрию (кстати, если инцидент затронул биометрические персональные данные, то сообщать нужно не только в Роскомнадзор, но и в Минцифры), договорные обязательства перед клиентами и требования внутреннего кризисного управления. И чем больше таких режимов наслаивается, тем сильнее уведомление превращается в отдельную дисциплину — не юридическое приложение к расследованию, которым оно завершается, а самостоятельный управленческий процесс.
Мировой тренд на централизованную осведомленность
При этом Россия здесь вовсе не уникальна. По сути, она движется в общем русле с другими юрисдикциями, которые кто раньше, а кто позже, включил в свое законодательство аналогичные требования. В ЕС директива NIS2 закрепила многоэтапную схему: сначала ранее предупреждение в течение 24 часов после того, как организация узнала о значимом инциденте, затем более полное уведомление в течение 72 часов и, наконец, финальный отчет не позднее одного месяца. Это уже не точечное уведомление, а сопровождение инцидента по всем стадиям его развития.
Еще показательнее финансовый сектор. В рамках регулирования DORA европейские надзорные органы выстраивают унифицированный режим сообщения о серьезных инцидентах, связанных с ИТ и ИБ: первоначальное уведомление — в течение 4 часов после классификации инцидента как серьезного, и не позднее 24 часов после его выявления, промежуточный отчет — через 72 часа, финальный — через месяц. Здесь государство, а точнее надгосударственное агентство ENISA, действующее для всего Евросоюза, фактически встраивается в жизненный цикл киберкризиса почти в реальном времени; почти как НКЦКИ в России.
Великобритания идет в том же направлении. В опубликованной правительством пояснительной записке к реформе кибербезопасности, наследующей правила Евросоюза (NIS), указано, что компании должны будут делать «легкое» первоначальное уведомление в течение 24 часов, а затем полный отчет в течение 72 часов, причем Национальный центр кибербезопасности Его Величества будет получать информацию одновременно с отраслевыми регуляторами. Аргументация там предельно понятная: это нужно, чтобы государство быстрее поддерживало пострадавшие организации, формировало общую картину угроз и видело системные уязвимости, приводящие к недопустимым событиям с катастрофическими последствиями. Хотя, вспоминая, как в той же Великобритании под соусом защиты детей и борьбы с экстремизмом и терроризмом вводят ограничения на использование VPN и внедряют деанонимизацию в социальных сетях, такая забота о пострадавших от инцидентов организациях вызывает определенные сомнения в истинных мотивах установления контроля.
США разворачивают похожую логику через регулирование CIRCIA: для большинства инцидентов уведомление должно быть реализовано в течение 72 часов, а для событий, связанных с выплатой выкупа вымогателям (ransomware), срок втрое меньше — 24 часа, плюс обязательство быстро подавать дополнительные сообщения по мере появления новой информации. Особенно показательно, что CIRCIA прямо предусматривает механизмы согласования отчетности между ведомствами, если компании и так уже сообщают в другой федеральный орган. Иными словами, государство понимает проблему фрагментации и пытается не просто собирать больше сведений, а строить единый обменный контур.
А на глобальном уровне ту же тенденцию отражает работа Financial Stability Board. В 2025 году FSB финализировал FIRE — Format for Incident Reporting Exchange, стандартизированный, но адаптируемый формат обмена сведениями об операционных и киберинцидентах. Цель сформулирована достаточно открыто — снизить фрагментацию, упростить трансграничную отчетность и улучшить коммуникацию между бизнесом и государством. Правда, пока задачу унификации решить не удалось, и я, положа руку на сердце, не очень верю, что всем удастся договориться. Несколько лет назад схожую задачу у нас пытался реализовать Банк России в рамках только своей многочисленной отчетности, но, к сожалению, не осилил ее. Говорить же об унификации правил уведомления об инцидентах на уровне всех отечественных регуляторов (РКН, ФСБ, ФСТЭК, МинЦифры, Банк России и т. п.) не приходится.
Если попытаться описать общий вектор одной фразой, он будет таким: мир движется от уведомления об инцидентах к ситуационной осведомленности национального уровня. То есть от обязанности сообщить о происшествии к построению у государства непрерывной и машиночитаемой картины цифровых рисков. Отдельные государства пытаются ее сделать еще и межведомственно сопоставимой, то есть унифицированной, но в России об этом сейчас никто и не заикается.
Обратная сторона централизации
Это развитие имеет рациональные причины. Быстрое уведомление позволяет регулятору увидеть хакерскую кампанию раньше, предупредить другие организации (если не обращать внимания на бюрократию, которую не победить, и неспособность самого регулятора быть примером «как надо делать» для других; достаточно вспомнить постоянные проблемы Минцифры с сертификатами PKI у головного и национального удостоверяющих центров), связать между собой разрозненные сигналы, заметить уязвимость поставщика, выявить отраслевой эффект домино и предотвратить каскадные недопустимые события. Для финансового сектора, критической инфраструктуры и крупных платформ это действительно может уменьшать системный риск. Но у такой модели есть и обратная сторона, о которой пока говорят гораздо меньше.
Первый риск — концентрация чувствительных данных. Чем больше данных государство собирает в одном или нескольких контурах почти в реальном времени, тем ценнее становится сам этот массив: для внешних атакующих, для инсайдеров, для несанкционированного вторичного использования. Массовая централизация уведомлений неизбежно порождает вопрос: а кто и как защищает уже не отдельную компанию, а сам государственный «мета-SOC», в который стекается картина атак по стране? Да, предположить, что кто-то взломает ГосСОПКУ, сложно. Но все-таки утечки данных из госорганов происходят регулярно, а регулярная недоступность централизованных сервисов, от Госуслуг и Национальной системы доменных имен до централизованно управляемых ТСПУ или НСПК, в условиях непрерывных кибератак давно уже не редкость.
Второй риск — иллюзия управляемости. Большой поток уведомлений еще не означает качественную осведомленность. Если критерии завышены — государство утонет в шуме, если занижены — будет видеть только вершину айсберга. Если форматы неудобны, компании начнут отправлять юридически безопасные, но операционно бесполезные сообщения. Тот факт, что FSB отдельно занялся стандартизацией FIRE ради снижения фрагментации и повышения сопоставимости данных, сам по себе показывает: проблема не в отсутствии отчетов как таковых, а в их несогласованности и низкой пригодности для совместного анализа. Об этом же, кстати, говорит и английский ICO, регулирующий среди прочего и тему персональных данных. Если в России не будет аналогичной системы, то рост числа требований об уведомлениях приведет только к ухудшению ситуации и потемкинским деревням, как это уже было, когда Банк России только начинал вводить свою отчетность об уровне безопасности кредитных организаций по стандарту ГОСТ 57580.1.
Третий риск — административная перегрузка компаний во время кризиса. Один и тот же инцидент может одновременно запускать «часы» Роскомнадзора, Минцифры, контуров КИИ, отраслевых требований Банка России или платежных систем, а также внутренних обязательств перед советом директоров, клиентами и страховщиками. В похожем ключе мыслит и зарубежное регулирование: CIRCIA специально предусматривает исключения и механизмы координации с другими федеральными режимами, потому что иначе компании будут тратить силы не на реагирование, а на многократную упаковку одного и того же факта для разных адресатов (чем не тема для стартапа, который бы автоматизировал эту задачу, снизив нагрузку на уведомляющих).
Почему «дописать в конце» больше не получится
Отсюда следует главный практический вывод для бизнеса. Уведомление об инциденте больше нельзя «дописать руками» в конце расследования. Если сроки исчисляются часами, если требуются первичное уведомление, уточнение, финальный отчет и, возможно, последующие дополнения, значит, у компании должна существовать специальная архитектура, которая превращает сырые события безопасности в юридически и управленчески пригодный сигнал.
Минимум, который для этого нужен, выглядит так. Во-первых, матрица режимов уведомления: какой тип инцидента кому, когда и в каком формате сообщается. Во-вторых, заранее согласованные критерии эскалации и классификации. В-третьих, единая карточка инцидента, куда в режиме реального времени стекаются факты, артефакты, решения, хронология и черновики уведомлений. В-четвертых, слой оркестрации отчетности: шаблоны, таймеры, маршруты согласования, контроль сроков, история версий. В-пятых, защищенное хранилище доказательств и журнал аудита, чтобы потом можно было объяснить, почему именно такой инцидент был квалифицирован именно так и почему конкретные сведения были переданы именно в таком объеме.
На технологическом уровне это почти всегда означает связку из SIEM/XDR/NDR/EDR, журналов облаков, IAM, ITSM, DLP и, где применимо, OT/АСУТП-мониторинга, поверх которых работает слой корреляции и управления инцидентами. Для ИИ-систем к этому добавляется мониторинг качества модели, дрейфа, аномалий результатов, жалоб пользователей и признаков вредных или вредоносных последствий. Иначе требование «непрерывного наблюдения» останется красивой фразой на бумаге, но не превратится в работающий процесс. Хотя, если не будет ответственности за неуведомление, это может быть и неплохо для регулируемых.
Когда уведомления берет на себя внешний SOC
При этом не все компании обязаны строить такую фабрику уведомлений собственными силами. Для многих реалистичнее другая модель: постоянный мониторинг, первичную квалификацию инцидента, сбор минимально достаточной фактуры, запуск часов уведомления и подготовку проектов сообщений берет на себя внешний центр мониторинга, построенный по схеме MDR, MSSP или SOC-as-a-Service. Это особенно логично там, где у компании нет зрелого и круглосуточного функционирующего SOC, но есть жесткие регуляторные сроки. Да, ответственность перед регулятором все равно остается у самой организации. Но операционно внешний поставщик может стать единственным способом уложиться в три, 24 или 72 часа без хаоса и импровизации.
Пожалуй, именно здесь и проходит настоящая граница новой эпохи регуляторной ИБ. Речь уже не о том, нужно ли сообщать об инцидентах или нет. Этот спор фактически завершен. Вопрос теперь в другом: станет ли новая система уведомлений инструментом коллективной киберустойчивости, о которой все упорно твердят, или превратится в бюрократический конвейер массово собираемой телеметрии без последующего ее использования? Я пока больше верю во второй исход, но чем шайтан не шутит, вдруг это сподвигнет наших регуляторов объединить усилия или хотя бы синхронизировать требования и форматы уведомлений о противоправных действиях в ИТ-пространстве.
Ответ зависит от трех вещей. От того, смогут ли государства защитить и разумно использовать собранные массивы данных. От того, сумеют ли регуляторы договориться об унификации форматов и устранении дублирования. И от того, поймут ли компании, что уведомление об инцидентах — это уже не хвост расследования, а самостоятельная функция киберустойчивости, требующая архитектуры, процессов, людей и, конечно же, экспертизы.
Потому что следующий этап зрелости — это не просто обязанность вовремя отправить письмо регулятору (если Интернет не заблокирован, конечно). Это способность в непрерывном режиме превращать события безопасности в технически достоверные, юридически значимые и управленчески полезные сигналы —для себя, для отрасли и для государства. Так что будем наблюдать…