副題：リスクベースの対象選定から証跡確認・契約・再評価まで
想定読者：2線部門、セキュリティ企画、調達・契約担当、内部監査
第1回では、委託先が金融機関の弱点になる構造を整理しました。では、どう評価すればよいのか。
多くの金融機関で行われているのは、年1回、数十問の質問票を配り、返ってきた回答をファイルに保管する運用です。これ自体は間違いではありません。問題は、そこで止まっていることです。
1. 質問票だけでは何が分からないのか
質問票が確認できるのは、基本的に「相手がそう回答した」という事実までです。3つの限界があります。
- 規程の有無しか分からない：「脆弱性管理の手順はありますか」に「はい」と返ってきても、直近で何件の脆弱性をいつ修正したかは分かりません
- 回答者が実態を知らないことがある：営業担当が本社のテンプレートを転記して返してくる例は珍しくありません
- 1年間、何も分からない：評価と評価のあいだに起きた構成変更、再委託の追加、インシデントは捕捉されません
バーゼル委の諸原則も、デューデリジェンス（原則4）と継続的モニタリング（原則7）を別の原則として立てています。入口の一度きりの評価と、その後の継続的な把握は別物だという整理です。
2. 評価プロセスの全体像
質問票は、プロセス全体の1つの部品にすぎません。全体はこうなります。
以下、順に見ていきます。
3. リスクベースで対象を絞る
すべての委託先を同じ深さで評価することはできませんし、その必要もありません。判断の軸は「委託先の規模」でも「契約金額」でもなく、その委託先が止まったときに何がどれだけ止まるかです。
停止許容度（Impact Tolerance）から考える
欧州DORAや英国のオペレーショナルレジリエンス規制で用いられている考え方に、重要業務ごとに「これ以上止まったら許容できない」という上限を先に決めるというものがあります。
「振込が何時間止まったら顧客影響が受容できない水準を超えるか」を決めてから、その業務を支えている委託先を特定する。この順序にすると、重要度分類が感覚ではなく業務影響から導けます。
区分 | 判断の目安 | 評価の深さ | 頻度 |
|---|---|---|---|
重要（Critical） | 停止が重要業務の停止許容度を直接侵食する／顧客データを大量に保有する | 深度評価（訪問・実地確認を含む） | 年1回＋変更時 |
標準（Standard） | 業務影響はあるが代替手段または回避運用がある | 標準評価（質問票＋証跡確認） | 2年に1回 |
軽微（Low） | 停止しても重要業務に直接影響しない／機微データを扱わない | 簡易評価（登録と自己申告） | 契約時のみ |
区分の数は3つで十分です。5段階に分けると、境界の議論に時間を取られて肝心の評価が進みません。
4. 証跡で確認する
深度評価では、回答の裏付けを求めます。第1回で触れたとおり、確認すべきは「規程があるか」ではなく「運用されているか」です。
確認したいこと | 質問票の回答（不十分） | 求めるべき証跡 |
|---|---|---|
脆弱性管理 | 手順を定めている | 直近3か月の検出件数と修正期間の実績、未修正の理由 |
アクセス管理 | 最小権限を適用している | 直近の権限棚卸しの実施記録、退職者アカウントの削除実績 |
インシデント対応 | 対応計画がある | 直近の演習実施記録、実際のインシデント対応の記録（匿名化可） |
再委託管理 | 再委託先を管理している | 再委託先の一覧と、各社に対する評価の実施記録 |
第三者認証報告書の読み方と限界
ISMS認証やSOC 2報告書の提出を受けたとき、表紙を確認して受領で終えるのは危険です。少なくとも次の3点を見ます。
- 適用範囲：認証・報告の対象が、自社が利用しているサービスと拠点を含んでいるか。グループ全体の認証で、実際の運用拠点が範囲外という例があります
- 報告の種類と期間：SOC 2であればType 1（設計のみ）かType 2（一定期間の運用有効性）か。Type 2であれば対象期間が現在とどれだけ離れているか
- 例外事項（Exceptions）：報告書の後半に記載された不備と、それに対する経営者の見解。ここが実質的な指摘事項です
認証は「評価しなくてよい理由」ではなく、「どこを重点的に確認すべきかを教えてくれる材料」です。
5. 契約条項に落とす
評価で分かったことは、契約に書かれていなければ実行を求められません。バーゼル委の原則5とDORAの契約必須事項は、おおむね次の項目で重なります。
- 提供されるサービスの明確な定義と、サービス水準（可用性・復旧目標を含む）
- データの所在地、取扱い、アクセス権限、契約終了時の返却と消去
- インシデント発生時の通知義務と通知期限（「速やかに」ではなく時間で書く）
- 再委託の事前承認、再委託先の一覧提供、同等の義務の承継
- 監査権および当局によるアクセス・検査への協力
- 継続的モニタリングのための情報提供（脆弱性対応状況、構成変更、認証の更新）
- 出口条項 ― 契約終了時の移行協力期間、データ移行の形式、移行支援の対価
すべての委託先にこれを求めるのは非現実的です。重要度「重要」の委託先から、更新時期に合わせて順次入れていきます。
6. 是正要求とトラッキング
評価で不備が見つかったあと、多くの組織で起きるのが「指摘はしたが、その後どうなったか分からない」という状態です。
評価結果は、指摘ごとに期限と責任者を付けた是正項目に変換します。そして自社側にも担当を置きます。委託先の是正を追いかけるのは委託先の仕事ではなく、委託した側の仕事です。
期限を過ぎた是正項目が一定数を超えたら、その委託先の重要度を一段上げて監視を強める、というルールを事前に決めておくと、判断が属人的になりません。
7. 継続モニタリングと再評価
評価と評価のあいだを埋めるのが継続モニタリングです。次のような変化を捕捉する仕組みを作ります。
- 委託先側のインシデント公表、脆弱性公表、格付や財務状況の変化
- 再委託先の追加・変更（契約で通知義務を課していれば捕捉できる）
- 自社側の変化 ― 委託範囲の拡大、扱うデータの追加、他業務での同一委託先の利用
最後の項目は見落とされがちです。部門ごとに同じベンダーと個別契約している場合、全社で見ると重要度が「標準」ではなく「重要」になっていることがあります。台帳を全社で1つにする理由はここにあります。
評価設計チェックリスト（10項目）
- 全社で1つの委託先台帳を持っているか
- 重要度を業務影響（停止許容度）から導いているか
- 重要度の区分を3つ程度に絞っているか
- 区分ごとに評価の深さと頻度を定義したか
- 深度評価で運用証跡（実績記録）を求めているか
- 第三者認証は適用範囲・種類・例外事項まで確認しているか
- 重要委託先の契約に通知期限・再委託承認・監査権・出口条項が入っているか
- 指摘を期限と責任者付きの是正項目に変換しているか
- 是正の遅延が続いた場合の扱いを事前に決めているか
- 評価と評価のあいだを埋める継続モニタリングの仕組みがあるか
まとめ
質問票を捨てる必要はありません。質問票を、リスクベースの対象選定・証跡確認・契約・是正・継続監視という流れの中に置き直すことが、実効性を生みます。
次回は、この評価が届きにくい領域 ― 再委託先（4th Party）と、複数の金融機関が同じ基盤に乗ることで生じる集中リスク、そして止まったときのExit Strategyを扱います。
主要出典
- 金融庁・日本銀行「バーゼル銀行監督委員会による『健全なサードパーティリスク管理のための諸原則』の公表について」（2026年2月／原文公表 2025年12月10日）
- 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月、2025年7月一部改正）
- 欧州連合「デジタル・オペレーショナル・レジリエンス法（DORA、規則(EU)2022/2554）」
- NIST SP 800-161 Rev.1「Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations」（2022年5月）
- ISO/IEC 27002:2022（5.19〜5.22 供給者関係）
本記事は公開情報に基づく一般的な解説です。制度・標準の改訂に応じて定期的に見直します