要約

  • ICANNが8月5日に公表したRFPは、方針管理、組織・第三者リスク、内部監査、コンプライアンス、可視化、自動証拠収集を統合するSaaSを求める。提案期限は9月11日であり、現時点で事業者選定、契約、導入は確認されていない。
  • 中央の記録は、リスク所有者、統制実施者、証拠収集者、検証者、是正責任者、監督者を区別し続けるべきだ。各状態に、役割、権限根拠、証拠の来歴、異議、更正を結び付けた可搬型の対応記録が必要になる。

画面が「完了」と表示しても、画面そのものに完了を決める権限が生まれるわけではない。

ICANNのGovernance, Risk, and Compliance基盤の調達は、この当たり前の区別を問う。8月5日の資料によると、ICANNは方針、企業リスク台帳、第三者評価、内部監査、コンプライアンス対応、報告、自動証拠収集を世界から利用できる一つのホステッドサービスに統合したい。現状については、複数部門にまたがる作業が主に手作業で、文書も別々の保管場所にあり、効率、部門横断の可視性、一貫性を制約し、文書と版の管理リスクを高めていると説明する。

共通台帳の利点は理解しやすい。同じ統制が複数の表で別名になることを防げる。監査指摘と是正責任者のつながりを保てる。承認済み方針のどの版が正しいかを追い回さずに済む。離れた部門が同じリスク識別子を使える。

問題は、統合された状態が判断そのものに見え始めるときだ。「受容済み」「有効」「是正完了」「リスク選好内」は単なる入力値ではない。定められた権限を持つ者が、一定の対象と期間について、不完全かもしれない証拠を評価して下す結論である。

システムは記録係になれる。依頼人にはなれない。

まだ入札の段階にある

公開概要の対象は広い。方針の作成、レビュー、承認、公表、ワークフロー、COSOとISO 31000に沿うリスク管理、分散チームが使う中央リスク台帳、第三者リスクの評価と監視、内部監査の計画・実施・指摘・是正追跡、ISO/IEC 27001、SOC 2、SOC 3、プライバシー要件の対応付けを挙げる。適切な場合には、統合機能による継続的な統制監視と証拠収集も想定する。

上位要件には、世界で使える完全ホステッド型SaaS、ISO 27001認証環境、高可用性、役割ベースの権限、監査証跡、API、導入、保守、研修が含まれる。選定では、機能、統合・自動化、報告、使いやすさ、支援、財務健全性、価格、参照実績、利益相反対策などを見る。

これは期待条件であって達成結果ではない。提案期限は9月11日23時59分（UTC）。評価は9月14日から11月13日、デューデリジェンス、契約、選定は11月16日以降の予定だ。ICANNは予定を変え、提案を退け、RFPを撤回し、選定しないこともできる。確認した資料に落札者や稼働中の製品はない。

また、公開概要はRFP全体ではない。追加資料はSciQuest/Jaggaerの調達ツール内に置かれる。そのため、移行性、契約終了時の支援、データの帰属、保存・削除、インシデント対応、証拠来歴をどう守るかは確認事項になる。一方、概要に記述がないだけで、非公開資料、提案、将来の契約にも要件がないとは断定できない。

権限の配置は製品より先に存在する

ICANNの2022年10月版リスク管理概要では、President and CEOが組織の全リスクを所有し、関係する幹部に機能上の所有を委ねる。Risk Management部門は枠組みを促進するが、リスクを所有しない。各機能は、自らの活動に近いリスクに責任を持つ。経営側の委員会は報告と行動計画を確認し、理事会とRisk Committeeは枠組みと受け入れるリスクの種類・程度を監督する。

この資料は2022年時点の説明であり、全ての運用が2026年も同一だという証拠ではない。ただし、2026年7月20日に承認された現行のBoard Risk Committee憲章は、現在の主要な線を示す。委員会はリスクの特定、評価、優先付け、軽減、リスク選好と許容度を監督する。内部監査については、範囲、計画、予算を承認し、外部事業者の独立性を確認し、指摘事項と経営側の是正状況を受け取る。

2025年2月の議事録も、当時の分担を明記した。委員会は監査計画、実施、結果を監督し、指摘に基づく是正は経営側が担う。

これらを一つの「ユーザー」権限に潰してはならない。手順を管理することとリスクを所有すること、統制を試験することと実施すること、是正を監督することと行うことは別である。中央で見えるようにするなら、差異も見えなければならない。

自動証拠にも立証対象が要る

自動収集には実務上の意味がある。手作業の画面保存やファイル転記は遅く、対象期間や元データとの結び付きも失いやすい。ID管理、チケット、クラウド環境との接続は、時刻、範囲、反復測定をより安定して残せる。

それでも、証拠は何かを立証するためにある。無効化アカウント一覧は退職者アクセスの一部を示せても、残る特権が全て適切に承認されたことまでは示さない。設定値は仕組みの存在を示せても、例外環境を含むとは限らない。チケットの完了は作業を示すが、是正の有効性を単独では証明しない。最新画面が古い前提を映すこともある。

したがって、何の主張を、どの母集団・期間について、どの照会や変換で支え、例外は何で、誰がどの権限で十分と判断したかを残す必要がある。収集頻度が上がっても、関連性と判断は自動生成されない。

状態と権限を結ぶ対応記録

必要なのは、機微なリスク台帳の公開ではない。保護された記録の中で、各状態を、それを有効にした行為に接続することだ。

重要なリスク、統制、例外、監査指摘、是正には安定した識別子を付ける。責任部門と役割を示し、所有、評価、承認、受容、試験、異議、監督、是正のどれを行ったのかを区別する。さらに、その権限を生む方針、リスク選好声明、監査計画、決定記録へ結ぶ。

同じ記録に、判断の対象と期間、証拠の来歴を残す。元システム、収集器または照会、変換、時刻、版、範囲、レビュー担当者が必要だ。例外と反証を消してはならない。状態変更には、誰がどの役割で、いつ、何を根拠に動き、その後どんな異議や更正があったかを残す。

事業者の特権アクセス、設定変更、証拠変換も監査対象になる。退出時のエクスポートは、識別子、関係、決定、更正履歴を別のシステムと独立レビュー担当者が理解できる形で保つべきだ。関係を失ったPDFの山は可搬性ではない。

この「権限と証拠の対応記録」はDaniel Kadeの提案であり、ICANNが公表した要件ではない。製品を保管、手順、検索には強く、権限の吸収には弱く保つための設計である。

公開するのは権限図であってリスク内容ではない

説明責任のために、リスク台帳、脆弱性、監査調書、生の統制証拠、第三者の安全情報、個人情報、法的助言、機微な是正内容を公開する必要はない。公開層では、権限図が承認されたか、所有者と手順管理者が分離されているか、内部監査が独立して異議を示せるか、来歴と更正が検証されたか、現行画面なしで履歴を再構成できるかを示せる。

期限超過の是正を適切な監督機関に集計報告することもできる。重要なのは、ソフトウェア状態が責任ある判断を無言で置き換えないという保証だ。

事実を結ぶ集約は有用である。意図的に分けた役割を結合すれば危険になる。導入後、あるいは製品から退出した後にも、誰が権限を持ち、何を決め、どの証拠に依拠し、誰が異議・更正できたかを説明できるか。それが本当の試験だ。答えが画面の外でも残るなら、製品はガバナンスに従っている。現在の表示にしか残らないなら、記録係が制度を書き換え始めている。

出典

  1. ICANN：GRCソリューションRFPの発表、2026年8月5日
  2. ICANN：Governance, Risk, and ComplianceソリューションRFPのプロジェクト概要
  3. ICANN：組織リスク管理フレームワーク概要、2022年10月
  4. ICANN：2026年7月20日承認のBoard Risk Committee憲章
  5. ICANN：Risk Committee改定憲章を採択した理事会決議、2026年7月20日
  6. ICANN：Board Risk Committee議事録、2025年2月10日