戦略リスクと運用リスクの管理
さまざまな Diligent One アプリを使って戦略リスクと運用リスクを管理する方法や、アプリ間に存在する関係、アプリによって 3 つのディフェンスラインがサポートされる方法を学習します。
ストラテジー アプリ
ストラテジーは、エンタープライズリスクマネジメント（ERM）を目的としており、業績の向上のほか、戦略的な目標のより経済的な達成に向けて、リスクと機会をバランスするうえで必要な洞察を組織に提供します。
戦略リスクの例
- 機密情報の情報漏洩
- 最高の人材の損失
- 大惨事の発生
プロジェクト
プロジェクト アプリ（その代表的な構成要素はプロジェクト アプリ自身とフレームワーク アプリ）は、運用リスク マネジメント（ORM）を目的としており、実施中の統制が効果的に設計され、運用していること、およびリスクが適切に軽減されていることの必要な保証を組織に提供します。
運用リスクの例
- 未承認の脆弱性評価ツールからのネットワークを検出し、保護するためのテクノロジーが実装されていない。
- 問題に対応する従業員の責任が明確でない、または文書化されていない。
- 機密データまたは会社情報を保管する施設に対して十分なセキュリティが施されていない。
コネクション
プロジェクト アプリでの統制の目標、セクション、またはサイクルとして知られる目標は、ストラテジー アプリの戦略リスクとリンクしています。
以下の図は、この関連性を説明し、どの情報を戦略リスクに戻して集約するのかについて示したものです。
- プロジェクトの目標を戦略リスクとリンクさせると、個別のプロジェクトからの情報を集約していることになります。
- フレームワークの目標を戦略リスクとリンクさせると、一般的には複数のプロジェクトからの情報を集約していることになります。
プロジェクトの目標にリンクされている戦略リスク
フレームワークの目標にリンクされている戦略リスク
ワークフロー
以下の図は、ストラテジーで作業をするリスクマネジメントチームと、プロジェクトおよびフレームワークで作業する保証チーム間で発生しうるワークフローを説明したものです。
リスクマネジメントチームは、共通の評価基準を使用して固有のリスクを評価することに加え、保証チームと一丸となって、リスク低減のために対策を定義、実施し、残余リスクを評価することができます。テスト結果は、レポート目的で、プロジェクトとフレームワークから、ストラテジーの戦略リスク評価にロール アップすることができ、戦略的レベルでリスクとプロジェクトの結果のダッシュボードを表示する機能を提供します。
基本的な例
リスク対策の定義
シナリオ
組織に次の戦略リスクがあることが分かりました。
主なサード パーティ ベンダーの失敗 サードパーティは、テクノロジー、製品、サービスを含む財政的営業基盤の主な部分を提供します。これらのサードパーティに変更があったり、現在またはより高いレベルの活動の対応が失敗したりすると、クライアントに製品とサービスを提供する能力が損なわれ、当社のビジネスが中断する場合があります。
このリスクの緩和に使用される、次のような一連の統制目標もあります。
- 選択と取得
- リスク、コンプライアンス、および実行可能性の管理
- パフォーマンスの監視
- 関係管理
- 移行と更新
- 新規顧客の登録成功
- 特定
プロセス
ストラテジーで戦略リスクを追加し、プロジェクトで統制目標を作成します。そこで、ストラテジーを使用して、統制目標を戦略リスクにリンクさせます。
結果
関係が戦略リスクと関連統制目標間で定義されることにより、保証とテスト結果を追跡し、残余リスクを評価することができます。
その他のコンポーネントと関係性
以下の図は、ストラテジー、リザルト、プロジェクト、フレームワーク、およびコンプライアンス マップのさまざまなコンポーネント間の関係を示したものです。コンポーネント一式はそれぞれ、特定チームまたは防衛線の機能に即しています。
戦略リスクの特定とリスク選好度の定義（取締役会/監査委員会）
ストラテジーを使用し、取締役会はまずリスク プロファイルを設定し、戦略リスクを特定します。取締役会は、ストラテジーを使用して、組織のリスク選好度を定義し、これを ERM プログラムの戦略に即したものにできます。
組織がリザルトを使用する場合、メトリクス（KPI または KRI）を戦略リスクにリンクして、固有のリスク評価を通知できます。
リスク対策の定義と統制のテスト（内部監査）
組織の戦略的リスクと目標が決定されると、内部監査ではプロジェクトとフレームワークを使用して、プログラムを開発し、リスクを軽減するための対策を実施できます。
内部監査では、対策を定義し、その設計（ウォークスルー経由）と、実施中の統制の運用効果（テスト経由）をテストし、適切な場合には問題に留意します。統制に合格すると、プロジェクト、フレームワーク、およびストラテジーの保証スコアが上昇します。統制のウォークスルーまたはテストのラウンドが 1 度でも不合格になると、その統制は "不合格" としてマークされ、保証のスコア全体から差し引かれます。
フレームワークを設定し、複数のプロジェクト間で共通の統制を管理するための中央のリポジトリとしての役割を果たせるほか、これらの統制は、関連プロジェクトにインポートし、個別にテストできます。これらのプロジェクトの1つで変更を行い、フレームワークに変更を戻して同期化できます。
要求の保証が達成されている（コンプライアンス チーム）
ビジネスに関連する仕様への組織の順守を示すために、コンプライアンス チームは、コンプライアンス マップを作成し、フレームワークの統制を要件にマッピングできます。
フレームワークの統制が要件にマッピングされると、そのフレームワークに関連付けられた複数のプロジェクトにわたるテスト結果と問題は、コンプライアンス マップに集約されるため、コンプライアンス チームは次のことができます。
- ギャップを特定する
- 問題を優先順位付けする
- コンプライアンスの進捗を追跡する
統制に合格するということは、コンプライアンスがより保証されていることを意味します。統制のウォークスルーまたはテストのラウンドが 1 度でも不合格になると、その統制は "不合格" としてマークされ、保証のスコアから差し引かれます。
高度な例
セキュリティ リスクの管理
次の図が説明するものは次のとおりです。
- ストラテジーで定義される戦略リスク（機密情報の情報漏洩)
- メトリクスの戦略リスクへのつながり（四半期あたりパッチが未割り当てのサーバーの %)
- プロジェクトでの統制目標への戦略リスクのつながり（セキュリティ）
- 3 つのプロジェクト（セキュリティの統制フレームワーク）（インフラストラクチャ監査、ユーザー アクセス監査、データベース管理監査）間で共通の統制を管理するための中央のリポジトリとして使用されるフレームワーク。
- フレームワークの統制間のマッピング（セキュリティ対策と関連する管理の手順を使用して、接続性に関する情報の包括的方法を保護する）およびコンプライアンス マップ内の特定の要件（セキュリティ管理）。
機能の仕組み
内部監査は統制をテストし、適切な場合には問題に留意します。
- 取締役会/監査は、ストラテジーで戦略リスクを評価する場合、集約されたテスト結果や、関連統制目標を元にした問題を含む、リスクとプロジェクトの結果のダッシュボードを見ます。
- テスト結果と問題は、コンプライアンス マップに集約されているため、コンプライアンス マップは、顧客とその他の関連第三者に、強力な統制環境が存在することを証明できます。
