Кратко

  • Запрос предложений ICANN от 5 августа предусматривает интегрированный SaaS для политик, корпоративных и сторонних рисков, внутреннего аудита, соответствия, панелей и автоматического сбора доказательств. Срок подачи — 11 сентября; выбор поставщика, контракт или внедрение не установлены.
  • Центральная запись должна различать владельца риска, оператора контроля, сборщика доказательств, проверяющего, ответственного за исправление и надзорный орган. Переносимое соответствие полномочий и доказательств сохранило бы за каждым статусом роль, основание, происхождение, возражения и исправления.

Надпись «закрыто» на экране сообщает о состоянии записи. Она не наделяет экран правом закрыть вопрос.

Именно эту границу затрагивает тендер ICANN на платформу Governance, Risk, and Compliance. В документах от 5 августа описан глобально доступный размещённый сервис, который должен объединить политики, реестры рисков, проверки третьих сторон, внутренний аудит, карты соответствия, отчёты и автоматический сбор материалов. ICANN характеризует нынешнюю работу как распределённую между функциями, преимущественно ручную и использующую отдельные хранилища. По её оценке, это ограничивает эффективность, сквозную видимость и последовательность и повышает риск управления документами и версиями.

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

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

Закупка остаётся закупкой

Публичный обзор задаёт широкий объём. Жизненный цикл политик включает создание, рассмотрение, утверждение, публикацию и автоматизацию. Управление рисками должно соответствовать COSO и ISO 31000 и поддерживать центральные реестры для децентрализованных команд. Сторонние риски включают оценку, наблюдение и документацию. Внутренний аудит охватывает планирование, проведение, замечания, отслеживание исправлений и отчёты. Соответствие связывает ISO/IEC 27001, SOC 2, SOC 3 и требования к приватности. Интеграции могут при уместности непрерывно наблюдать контроли и собирать доказательства.

Среди верхнеуровневых требований — полностью размещённый глобальный SaaS, среда с сертификацией ISO 27001, высокая доступность, ролевые права, аудиторские следы, API, внедрение, поддержка и обучение. Критерии выбора включают функциональность, автоматизацию, отчётность, удобство, поддержку, финансовую устойчивость, цену, рекомендации и смягчение конфликтов интересов.

Это условия конкурса, а не достигнутые результаты. Предложения принимаются до 23:59 UTC 11 сентября. Оценка запланирована на 14 сентября — 13 ноября, а проверка, переговоры и возможное присуждение — с 16 ноября. ICANN вправе изменить график, отклонить предложения, отозвать процедуру или ничего не присуждать. Проверенные материалы не называют победителя и не показывают работающую платформу.

Публичный обзор — лишь часть RFP. Дополнительные материалы размещены в SciQuest/Jaggaer. Поэтому переносимость, помощь при выходе, права на данные, хранение, инциденты и происхождение доказательств следует проверять. Их отсутствие в обзоре не доказывает отсутствия в закрытых материалах, предложениях или будущем контракте.

Карта полномочий существует до программы

Обзор риск-менеджмента ICANN за октябрь 2022 года говорит, что President and CEO владеет всеми организационными рисками и делегирует функциональное владение соответствующему руководителю. Функция Risk Management помогает работе рамки, но не владеет рисками. Подразделения отвечают за риски, близкие к их деятельности. Исполнительный комитет рассматривает отчёты и планы действий; Совет и его Risk Committee надзирают за рамкой и уровнем принимаемого риска.

Документ описывает 2022 год и не доказывает неизменность каждой операции. Но действующий устав Board Risk Committee, утверждённый 20 июля 2026 года, подтверждает основные нынешние границы: надзор за выявлением, оценкой, приоритетами, снижением, риск-аппетитом и допусками. Во внутреннем аудите комитет утверждает объём, планы и бюджет, оценивает независимость внешних исполнителей, получает замечания и сведения о состоянии корректирующих действий руководства.

Протокол февраля 2025 года прямо зафиксировал тогдашнее разделение: комитет надзирал за планом, выполнением и результатами аудита, а руководство отвечало за исправления.

Эти позиции нельзя свести к общему «пользователю». Управлять процессом — не значит владеть риском. Тестировать контроль — не значит выполнять его. Надзирать за исправлением — не значит исправлять. Закрыть задачу — не значит отменить аудиторский вывод. Централизация должна сделать различия видимее.

Автоматическое доказательство всё равно доказывает конкретный тезис

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

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

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

Каждому статусу — соответствие полномочия и доказательства

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

Каждый существенный риск, контроль, исключение, аудиторское замечание или исправление получает устойчивый идентификатор, ответственную функцию и роль. Запись различает владение, оценку, утверждение, принятие, тестирование, возражение, надзор и исправление. Она указывает на политику, заявление о риск-аппетите, план аудита или решение, создающее полномочие.

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

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

Такое соответствие — предложение Daniel Kade, а не объявленное требование ICANN. Оно делает платформу сильной в хранении, процессе и поиске, но намеренно слабой в присвоении полномочий обслуживаемых ею органов.

Публиковать устройство, а не содержание риска

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

Просроченные меры можно агрегированно сообщать надлежащему надзорному органу. Главное публичное заверение уже: состояние в программе не подменяет ответственное решение.

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

Источники

  1. ICANN — объявление RFP на GRC-решение, 5 августа 2026 года
  2. ICANN — обзор проекта RFP на решение Governance, Risk, and Compliance
  3. ICANN — обзор организационной рамки управления рисками, октябрь 2022 года
  4. ICANN — устав Board Risk Committee, утверждённый 20 июля 2026 года
  5. ICANN — решение Совета о принятии обновлённого устава Risk Committee, 20 июля 2026 года
  6. ICANN — протокол Board Risk Committee, 10 февраля 2025 года