「取引先経由で侵入された」「クラウド事業者側の障害で自社サービスが止まった」——自社の統制が効いていても、外部の事業者を起点に事故が起きる事例が続いています。2026年に入り、サードパーティリスク管理（TPRM：Third-Party Risk Management）を掲げる製品発表や調査レポートの公表が相次いでいるのも、この問題意識の広がりを映しています。

本記事では、委託先やクラウド事業者のリスクを組織としてどう測り、監視し続けるかを、IT企画・情報システム部門の推進視点で整理します。

課題 ― チェックシートを配って終わりになる

多くの組織で、委託先管理は「発注前にセキュリティチェックシートに回答してもらう」運用として存在しています。ところが取引先が増え続けるなかで全社に同じ様式を配ると、重要度の低い取引にも同じ枚数の質問が飛び、回答も確認も形式的になります。さらに契約時に一度確認するだけでは、その後の体制変更や再委託の追加を捉えられません。

結果として、書類は揃っているのに「どの委託先が止まると事業が止まるのか」を誰も即答できない状態が残ります。

なぜ今、独立した仕組みとして求められるのか

規制側の要求水準が明確に上がっています。金融庁が2024年10月に公表した「金融分野におけるサイバーセキュリティに関するガイドライン」は、サードパーティリスク管理を独立した着眼点として位置づけ、クラウドサービス事業者や業務提携先、API連携先までを対象に含めることを明示しました。経済産業省・IPAの「サイバーセキュリティ経営ガイドライン Ver3.0」も、指示9でビジネスパートナーや委託先を含むサプライチェーン全体の状況把握を経営者の責任として掲げています。

加えて、個人データの取扱いを委託する場合には、個人情報保護法第25条に基づく監督義務が別途かかります。委託先で事故が起きたとき、監督が適切だったかは委託元にも問われます。

ベンダーマネジメントとの違い

既にベンダー統制の仕組みを持つ組織では、TPRMを別物として立てるべきか迷いがちです。目的の違いで整理できます。

ベンダーマネジメント サードパーティリスク管理（TPRM）
主目的 調達の主導権とQCDの確保 事故・停止・法令違反の予防
対象 発注している委託先 委託先に加え、クラウド、提携先、連携先
見る軸 価格妥当性、品質、ロックイン セキュリティ体制、事業継続性、再委託、法令順守
時間軸 契約・更新のタイミング 契約中も継続的に監視

両者は競合しません。委託先を束ねる仕組みの作り方は マルチベンダー時代のベンダーマネジメント で扱いました。本記事はその先の「束ねた相手のリスクをどう測り続けるか」にあたります。

進め方 ― 四段階で回す

ステップ やること 成果物
1. 棚卸し 委託先・クラウド・提携先を洗い出し、預けているデータと接続の種類を記録する サードパーティ台帳
2. 重要度分類 事業影響とデータの機密度で階層に仕分ける 重要度区分の基準と分類結果
3. 評価 階層ごとに評価の深さを変えて実施する 評価結果、是正依頼
4. モニタリング 重要な相手ほど頻度を上げ、契約更新に反映する 再評価記録、更新判断

棚卸しの起点は購買データと支払データです。情報システム部門を通さずに契約されたSaaSは、この経路でしか見つかりません。ここは アプリケーションポートフォリオ管理 の台帳と重ねると効率的です。

分類の基準は、金額ではなく事業影響で置きます。 少額でも、止まると業務が止まる、あるいは個人データを預けている相手は上位に置きます。上位の階層だけを対象に、管理体制やインシデント対応計画、再委託の構造まで踏み込んで確認し、下位は自己申告と認証の確認にとどめます。すべてを厚く見ようとすると、結局どこも薄くなります。

契約には、責任範囲と有事の取り決めを書き込みます。 クラウドでは責任共有モデル上どこまでが自社の責任かを確認し、再委託の事前承認、インシデント発生時の通知期限、契約終了時のデータ返却・消去を条項として持ちます。評価内容を契約に接続しないと、是正を求める根拠が残りません。

よくある失敗と回避策

よくある失敗 なぜ起きるか 回避策
全社一律のチェックシート 重要度の判断を省いている 階層を先に決め、質問の量を階層ごとに変える
契約時の一度きりで終わる 評価をイベントとして扱っている 上位階層は定期再評価を年次業務として計画に載せる
台帳が情報システム部門の把握分だけ 現場契約のSaaSが見えていない 購買・支払データから突き合わせる
評価結果が契約に反映されない 評価と調達の担当が分断している 是正事項を契約条項と更新判断に紐づける
主管部門が決まらない セキュリティ・法務・調達にまたがる 台帳と基準の維持責任をIT企画かリスク管理部門に置く

まとめ

サードパーティリスク管理は、質問票を増やす取り組みではありません。どの相手が止まると自社が止まるのかを把握し、そこに管理の重さを寄せる取り組みです。

まず台帳を作り、事業影響で階層を分け、上位から評価と監視を厚くする。この順番を守れば、限られた体制でも実効性のある統制になります。

FAQ

Q. 既にベンダーマネジメントの仕組みがあります。別に立てる必要はありますか。 A. 別組織を新設する必要はありません。多くの場合、既存の委託先管理プロセスに「重要度分類」と「継続モニタリング」を足す形が現実的です。対象範囲をクラウドや提携先まで広げる点だけは意識してください。

Q. クラウドサービスは監督の対象になりますか。 A. セキュリティ管理上は対象に含めるべきです。個人情報保護法上は、事業者が個人データを取り扱わない形態であれば法第25条の委託先監督には当たらないと整理されますが、その場合も自ら安全管理措置を講じる責任は残ります。法的な整理と実務上の管理対象は分けて考える必要があります。

Q. 再委託先まで確認しきれません。 A. 全階層を直接確認するのは現実的ではありません。上位階層の委託先に対して、再委託の事前承認と構造の開示を契約で求め、把握できる状態を維持することが実務的な落としどころです。

Q. 誰が主管すべきですか。 A. 評価の実務はセキュリティ部門、契約は法務・調達が担うとしても、台帳と重要度基準を維持する主体は一つに定める必要があります。IT企画部門やリスク管理部門が持つ例が多く見られます。

参考資料

関連記事