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

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

OECD в докладе от 27 мая 2026 года называет регуляторную фрагментацию системной проблемой. Она увеличивает затраты и отвлекает людей и бюджет от реального снижения риска.

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

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

Зрелая архитектура состоит из пяти слоёв:

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

Единая библиотека мер. Как именно достигаются эти результаты, кто владелец меры и как оценивается её эффективность.

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

Локальные надстройки. Особые сроки уведомления и требования к данным, поставщикам и ответственности руководителей.

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

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

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

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

Я не верю в универсальную таблицу, которая полностью устранит противоречия между всеми режимами. Такое обещание обычно скрывает реальные расхождения.

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

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

Какое требование ИБ в вашей компании несколько подразделений реализуют по-разному только потому, что каждое работает со своим регулятором или стандартом?