第1回｜なぜ委託先が金融機関のサイバーリスクの弱点になるのか

副題：自社の境界の外にあるリスクを、自社の責任として引き受ける

想定読者：CISO、委託先管理部門、調達、ITリスク、オペレーショナルリスク部門

勘定系の一部機能がシステム開発会社に、顧客対応がBPOに、認証基盤がSaaSに、基盤そのものがクラウドに。金融機関の業務は、いまや外部への依存の上に成り立っています。

そして侵害は、自社のファイアウォールではなく、その依存の先から入ってきます。委託先の管理端末が乗っ取られる、再委託先の開発環境から資格情報が漏れる、共通利用しているSaaSが停止する。いずれも「相手先の事故」ですが、業務が止まり、顧客に影響が出て、当局に説明するのは金融機関自身です。

本稿では、なぜ委託先が弱点になるのかを構造から整理し、規制がどこまでを求めているのかを確認します。

1. 依存は「見えているところ」で終わっていない

委託先管理の議論は、契約を結んでいる相手（サードパーティ）で止まりがちです。しかし実際の依存は、その先に続いています。

一次委託先はシステム開発を再委託し、その再委託先は共通のクラウド基盤を使い、そのクラウド上で動く監視ツールは別のSaaSに連携している。契約書に名前が出てくるのは最初の1社だけですが、業務が止まる原因はどの層にも潜んでいます。

バーゼル銀行監督委員会は、この連鎖を「nthパーティ」と呼び、主要なnthパーティについても台帳の維持と継続的なモニタリングを求めています。契約相手の1社だけを見ている限り、リスクの大半は視野の外にあります。

2. 委託先が弱点になる4つの理由

理由1：責任は移せるが、影響は移せない

業務を委託すれば、作業の責任は委託先に移ります。しかし顧客への影響、業務停止による損失、当局への説明責任は移りません。委託は「リスクの移転」ではなく「リスクの形の変化」です。ここを取り違えると、委託した瞬間に管理の手を離してしまいます。

理由2：見えない

自社のシステムであれば、ログを取り、脆弱性をスキャンし、設定を確認できます。委託先に対してできるのは、多くの場合、年1回の質問票と提出された報告書を読むことだけです。攻撃者から見れば、監視の薄い場所を経由するほうが合理的です。

理由3：契約に書かれていない

数年前に締結した委託契約に、インシデント発生時の通知期限、ログの保全義務、再委託の事前承認、監査への協力、契約終了時のデータ返却・消去が明記されているでしょうか。書かれていなければ、事故が起きてから交渉することになります。そして事故の最中に交渉する時間はありません。

理由4：みんな同じところに乗っている

業界内の多くの金融機関が、同じクラウド、同じ勘定系ベンダー、同じ認証サービスを使っています。1社の障害が業界全体に波及する構造です。バーゼル委はこれを個社レベルの集中リスクとシステミックな集中リスクに分けて整理しており、個社レベルの評価と監視は銀行自身の責務としています。

3. 規制はどこまで求めているか

サードパーティリスク管理は、この2年で各国・国際機関の要求水準がはっきりと上がりました。

DORAでは2025年11月、欧州監督当局（ESAs）が重要ICTサードパーティプロバイダーの初回指定を公表しました。大手のクラウド・ITサービス事業者が、金融機関を通じてではなく直接、当局の監督対象になったという点で、規制の考え方の転換を示しています。

日本の金融機関にとって、DORAは直接の適用法令ではありません。しかし欧州拠点を持つ場合の実務対応としてはもちろん、国内の枠組みが今後どこへ向かうかを読む材料としても、内容を押さえておく価値があります。

4. 「委託したら終わり」から抜け出す最初の3つ

いきなり全委託先の深度評価を始める必要はありません。順序があります。

第1に、台帳を作る

どの委託先に、どの業務を、どのデータを預けているか。再委託の有無と、その先の名前。これが分からなければ、優先順位の議論そのものが始まりません。網羅性より、まず重要業務に関わる委託先から埋めていくのが現実的です。

第2に、重要度を分ける

すべての委託先を同じ深さで評価することはできません。その委託先が止まったときに、どの業務がどれだけ止まるのか。この観点で重要度を分け、評価の深さと頻度を変えます。

第3に、契約の空白を埋める

重要度の高い委託先から順に、インシデント通知、再委託の承認、監査協力、契約終了時の措置が契約に入っているかを確認します。更新時期を待たず、覚書で追加できるものもあります。

まとめ ― このシリーズで扱うこと

委託先リスク管理の難しさは、技術ではなく構造にあります。見えない相手を、契約と評価とモニタリングという間接的な手段でどこまで管理できるか、という問題だからです。

• 第1回（本稿）：なぜ委託先が弱点になるのか
• 第2回：委託先セキュリティ評価を「質問票だけ」で終わらせない方法
• 第3回：4th Party・クラウド集中リスクまでどう管理するか

次回は、リスクベースの対象選定から証跡確認、契約条項、再評価までの評価プロセスを具体的に設計します。

主要出典

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

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