#009 【Domain4深掘り】ISACAが重視する「リスク最適化」日本の実務との深すぎる溝

📌 このテーマのCGEITドメイン：Domain 4（リスク最適化・配点19%）

▼ #008 実務活用編②はこちら

「リスク管理はやっています。」

クライアントにITリスクの話をすると、よくこう返ってくる。セキュリティ対策をしている、BCPを策定している、内部統制の仕組みがある。確かにやっている。

しかし「どのリスクをどのレベルで許容するか、経営として意思決定していますか？」と聞くと、答えが止まることが多い。

これがISACAのリスク最適化と、日本の実務の間にある「深すぎる溝」だ。リスクを「管理する」ことと、リスクを「最適化する」ことは全く別の話だ。

今回はCGEITの試験でも私が最も苦労したDomain 4を、実務の視点から正直に整理する。

1．「リスク管理」と「リスク最適化」の違い

多くの企業が行っている「リスク管理」は、リスクを特定して対策を講じることだ。これは必要なことだが、ISACAが求めるのはその先にある。

ISACAのリスク最適化とは、組織の目標達成のために「どのリスクをどのレベルで受け入れ、どこに対策を集中させるか」を戦略的に判断することだ。

つまりリスクは「なくすもの」ではなく「最適なレベルに調整するもの」だ。この発想の転換が、日本の実務では最も難しい部分だと感じている。

2．ISACAが定義するリスク最適化の構造

#005の用語解説でも触れたが、改めてリスク最適化の核心となる概念を整理する。

Risk Appetite（リスク選好）

組織が目標達成のために受け入れる準備があるリスクの量・レベルだ。これは経営層が戦略的に決定するものであり、IT部門が単独で決められるものではない。

「うちはリスクに保守的な会社だ」「成長のためにある程度のリスクは取る」という経営判断が、Risk Appetiteとして明文化される必要がある。

Risk Tolerance（リスク許容度）

Risk Appetiteの基準から一時的に逸脱しても許容できる変動の幅だ。予算と予算超過の許容範囲のような関係性だと理解するとわかりやすい。

Residual Risk（残留リスク）

対策を講じた後に残るリスクだ。対策を打てばリスクがゼロになるという考え方はISACAでは通用しない。残留リスクがRisk Appetite以内に収まっているかを確認することが重要だ。

この3つの関係性

Inherent Risk（固有リスク）
　↓ 対策を実施
Residual Risk（残留リスク）
　↓ Risk Appetiteと比較
許容範囲内か？→ Yes：受け入れる / No：追加対策

3．日本の実務との3つの溝

CGEIT試験でDomain 4のスコアが415と最も低かった。その原因を振り返ると、日本の実務との3つの溝が見えてきた。

溝①：リスクの意思決定が現場止まり

日本の実務では、ITリスクへの対応はIT部門や情報システム部門が判断することが多い。しかしISACAでは、Risk Appetiteの設定は経営層・取締役会の責任だ。

「このリスクはどこまで許容するか」という問いは、IT部門だけが答えるものではない。経営戦略と紐づいた判断が必要なため、経営会議のアジェンダになるべき話だ。

溝②：対策することがゴールになっている

「セキュリティパッチを適用した」「BCPを策定した」で終わっていないだろうか。ISACAが求めるのは、対策後の残留リスクがRisk Appetite以内に収まっているかの確認だ。

対策することがゴールではなく、リスクを最適なレベルに調整することがゴールだ。この視点が日本の実務では抜け落ちていることが多い。

溝③：リスクとビジネス機会がトレードオフとして議論されない

ISACAのリスク最適化では、リスクを取ることで得られるビジネス機会との天秤で考える。「このリスクを受け入れることで、このビジネス価値が得られる」という議論だ。

日本の実務では「リスクがあるからやらない」という判断になりがちで、リスクとリターンのバランスを経営として議論する文化が根付いていないケースが多い。

4．実務での落とし込み方

では実際にクライアント支援でどう使うか。

Risk Appetiteを言語化する支援をする

まず経営層に「どのリスクをどのレベルまで許容するか」を言葉にしてもらう。最初は「高・中・低」のような定性的な表現でも構わない。重要なのは経営として意思決定した記録を残すことだ。

「うちはシステム停止は4時間まで許容できる」「顧客データの漏洩リスクはゼロ許容」というような形で、具体的に言語化することを支援する。

残留リスクの「見える化」をする

対策を講じた後の残留リスクを定期的に評価し、経営層に報告する仕組みを作る。「対策しました」ではなく「対策後の残留リスクはこのレベルです。Risk Appetiteの範囲内です」という報告に変える。

リスクとビジネス機会をセットで議論する場を作る

経営会議でITリスクを議論する際、「このリスクを受け入れることで得られるビジネス価値」も合わせて提示する。リスクとリターンをセットで議論することで、経営層がリスクを「避けるもの」から「管理するもの」として捉え始める。

締め：リスクは「ゼロにする」ものではなく「最適化する」もの

CGEITの試験でDomain 4が最も難しかった理由が、今ならわかる。

ISACAのリスク最適化は、日本の実務で染み付いた「リスクは避けるもの・対策するもの」という発想とは根本的に違う。リスクを戦略的に選択し、最適なレベルに調整する。そのための意思決定を経営層が行う。

これは概念として理解するだけでは試験に通らないし、実務でも使えない。「CIOとして判断するなら何を優先するか」という問いを常に持ちながら、繰り返し考えることで初めて身につく視点だ。

あなたの組織では、ITリスクへの許容範囲を経営として明文化していますか？

次回：#010【実務活用編③】ベネフィット実現をどう測るか？KPI設計の実践。

この連載の全記録はマガジン「誰も書かなかったCGEIT挑戦記」にまとめています。参考になったらシェアやフォローで広めていただけると嬉しいです。