副題：見えない依存の連鎖と、止まったときの備え

想定読者：CISO、ITリスク、BCP/BCM、クラウドガバナンス担当

第2回で、委託先の評価プロセスを設計しました。しかしそのプロセスが届くのは、契約を結んでいる相手までです。

その先 ― 再委託先、そのまた先のクラウド基盤、業界で共用されている決済や認証のサービス ― は、契約関係がないため直接の管理手段がありません。それでも、止まれば自社の業務は止まります。本稿はこの領域を扱います。

1. 4th Partyはなぜ見えないのか

理由は単純で、教えてもらわない限り分からないからです。そして多くの委託契約には、再委託先を開示する義務が書かれていません。

バーゼル銀行監督委員会の諸原則は、主要なnthパーティについても台帳の維持と継続的モニタリングを求めています。DORAでは、再委託の判断・評価基準を定めた規則（委任規則(EU)2025/532）において、「下請事業者の連鎖の長さおよび複雑さ」を考慮すべき要素として挙げています。連鎖が長いほどリスクが高まるという認識が、規制の側でも明文化されつつあります。

可視化の入口は、技術ではなく契約です。第2回で挙げた「再委託の事前承認」「再委託先の一覧提供」という条項が入っていれば、情報は入ってきます。入っていなければ、まずそこから始めることになります。

2. 依存マップを作る

集めた情報は、委託先の一覧ではなく重要業務を起点としたマップにします。

作り方の順序は次のとおりです。

  1. 重要業務を10前後に絞って列挙する（すべての業務を対象にすると完成しません）
  2. 各業務を支えているシステム・サービスを紐づける
  3. 各システムの運用・開発・基盤を誰が担っているかをたどる
  4. その先の再委託・クラウド・共用サービスを、分かる範囲で記入する
  5. 複数の経路が集まっている点に印を付ける

最初から精緻なものを目指す必要はありません。「分からない」と記入された箇所そのものが、次に手を打つべき場所を示しています。

3. 集中リスクの2つの見方

バーゼル委は集中リスクを個社レベルとシステミックの2種類に分けて整理し、個社レベルの評価とモニタリングは銀行自身の責務としています。

種類

何が問題か

誰が見るか

自社でできること

個社レベルの集中

自社の複数の重要業務が、同じ事業者・同じ基盤に依存している

金融機関自身

依存マップで結節点を特定し、代替手段・縮退運用を用意する

システミックな集中

業界の多くの金融機関が同じ事業者に依存し、1社の障害が市場全体に波及する

監督当局・中央銀行

自社単独では解消できない。前提として受け止め、停止時の対応計画に織り込む

DORAが重要ICTサードパーティプロバイダーを欧州監督当局の直接監督下に置き、2025年11月に初回指定を公表したのは、後者に対する制度側の回答です。個社の努力では解けない問題は、監督の枠組みで扱うという整理になります。

裏返せば、金融機関に求められているのは前者 ― 自社の中の集中を把握し、手を打つことです。

4. 停止許容度（Impact Tolerance）を決める

集中が分かっても、そこからどこまで対策するかの基準がなければ議論が止まります。基準になるのが停止許容度です。

これは復旧目標（RTO）とは異なります。RTOが「自社として目指す復旧時間」であるのに対し、停止許容度は「これを超えたら顧客・市場への影響が受容できなくなる限界」です。目標ではなく、越えてはならない線として設定します。

決め方の手順

  1. 重要業務ごとに、停止が続いたときに何が起きるかを時間軸で書き出す（顧客影響、資金決済、法令・契約上の義務、レピュテーション）
  2. 「ここを超えると受容できない」という時点を特定する
  3. その時間を、経営会議または取締役会で承認する
  4. 依存マップ上の各経路について、実際にその時間内に復旧または代替運用へ移行できるかを検証する

4番目で「できない」と分かった箇所が、投資判断の対象です。停止許容度を決める本当の意味は、この検証を可能にすることにあります。

5. Exit StrategyとExit Planは別物

バーゼル委の諸原則は、計画的な終了に向けた出口計画（Exit Plan）と、計画外の終了に備えた出口戦略（Exit Strategy）の双方を維持すべきとしています。実務ではこの2つが混同されがちですが、備えるべき内容が違います。

区分

想定する状況

備えるべきこと

出口計画（Exit Plan）

契約満了、ベンダー変更、内製化など、こちらの都合で計画的に移行する

移行手順、移行期間、データの引き渡し形式、並行稼働の設計、移行費用の見積り

出口戦略（Exit Strategy）

事業者の破綻、重大インシデント、サービス廃止、規制上の問題など、突然使えなくなる

縮退運用の手順、代替手段の事前確保、データの自社側保持、判断基準と発動権限

計画外終了への備えで要になるのは、データが自社側にあるかという一点です。移行先が決まっていなくても、データさえ手元にあれば選択肢が残ります。逆にデータが事業者側にしかなければ、どれだけ手順書を整備しても実行できません。

ここは技術ではなく契約と運用の問題です。定期的なエクスポート、標準的な形式での保持、契約終了時の返却義務。第2回で挙げた出口条項が効いてくる場面です。

6. 継続モニタリングをどう回すか

4th Partyと集中リスクは、一度マップを作って終わりにはできません。現実的な更新の回し方は次のとおりです。

  • 年1回：重要業務の依存マップを全面的に見直す。重要度の変更と停止許容度の妥当性もあわせて確認する
  • 契約更新時：再委託の開示条項が入っているかを確認し、入っていなければ追加する
  • 随時：委託先からの再委託変更通知、事業者の重大インシデント公表、大規模なクラウド障害の発生時にマップを部分更新する
  • 演習時：サイバー演習やBCP訓練のシナリオに、集中している結節点の停止を必ず1つ入れる

最後の項目が、机上の管理と実際の対応力を結びつけます。Series 04（サイバーレジリエンス）では、この演習の設計を詳しく扱います。

管理設計チェックリスト（10項目）

  1. 重要委託先の契約に、再委託の事前承認と一覧提供が入っているか
  2. 重要業務を10前後に絞って特定したか
  3. 重要業務を起点とした依存マップを作成したか
  4. マップ上で複数経路が集まる結節点を特定したか
  5. 個社レベルの集中とシステミックな集中を区別して扱っているか
  6. 重要業務ごとに停止許容度を設定し、経営が承認しているか
  7. 停止許容度の時間内に復旧・代替できるかを経路ごとに検証したか
  8. 出口計画と出口戦略を別々に用意しているか
  9. 重要なデータを自社側で保持できているか
  10. 集中している結節点の停止を演習シナリオに入れているか

シリーズのまとめ

3回にわたり、サードパーティリスクを「なぜ弱点になるのか」「どう評価するか」「見えない先とどう向き合うか」という順で扱いました。

この領域の管理は、相手を完全に見通すことはできないという前提から出発します。だからこそ、契約で情報を得る経路を作り、業務影響から優先順位を決め、止まったときに何ができるかを先に用意しておく。この3つが、間接的な手段しか持たない立場でできる最大限だと考えています。

主要出典

  1. 金融庁・日本銀行「バーゼル銀行監督委員会による『健全なサードパーティリスク管理のための諸原則』の公表について」（2026年2月／原文公表 2025年12月10日）
  2. 欧州連合「デジタル・オペレーショナル・レジリエンス法（DORA、規則(EU)2022/2554）」および再委託に関する委任規則(EU)2025/532
  3. ESAs「European Supervisory Authorities designate critical ICT third-party providers under DORA」（2025年11月18日）
  4. 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月、2025年7月一部改正）
  5. NIST SP 800-161 Rev.1「Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations」（2022年5月）

本記事は公開情報に基づく一般的な解説です。制度・標準の改訂に応じて定期的に見直します。