委託先やSaaSベンダーが攻撃を受けると、自社に落ち度がなくても顧客データの流出や業務停止に巻き込まれます。ところが、契約しているベンダーの数が増えるほど、どこまで確認すればよいかの線引きが難しくなります。

サードパーティリスク管理（TPRM）は、ベンダーの特定と分類、取引開始前の評価、契約への反映、継続的なモニタリングの4手順で進めると、限られた人数でも回せます。手順ごとの成果物は次のとおりで、確認項目は評価チェックリストの章にまとめました。

情報システム部門でベンダー選定や委託先の管理を担う方、取引先からセキュリティ対策の確認を求められている方に向けた内容です。

サードパーティ・ベンダーセキュリティリスクとは何か

企業のITシステムやデータ基盤を守るうえで、自社内の対策だけでは不十分な時代になっています。クラウドサービスや外部ベンダーへの依存が深まるほど、自社が直接管理できないサードパーティ経由のリスクが高まるからです。サードパーティ・ベンダーセキュリティリスクとは、業務委託先、SaaSベンダー、クラウド事業者、システム連携パートナーなど、自社以外の第三者が原因となって発生するセキュリティ上の脅威や損失のことを指します。

サードパーティリスクが注目を集めるようになった背景には、大規模なサプライチェーン攻撃の増加があります。ベンダー1社のセキュリティ脆弱性を突いた攻撃が、そのベンダーのサービスを利用する数百社・数千社に波及するケースが国内外で相次いでいます。攻撃の手口と国内の事例はサプライチェーン攻撃とはで詳しく解説しています。金融庁は2026年4月、米国・EU・英国の大手銀行と大手保険会社の管理手法を調べた「金融機関のサードパーティ・サイバーセキュリティリスク管理強化に関する調査」報告書を公表しました。情報システム部門にとって、サードパーティリスク管理（TPRM: Third-Party Risk Management）は今後避けて通れない業務領域です。

サードパーティリスクが一般的なITリスクと異なるのは、自社がコントロールできる範囲の外側で問題が発生する点です。どれだけ自社のセキュリティを強化しても、連携しているSaaSベンダーがインシデントを起こせば、自社のデータや業務が影響を受けます。そのため、ベンダーに対してもセキュリティ基準への準拠を求め、継続的に状況を確認する仕組みが必要です。

参考：サードパーティリスク管理の重要性の高まりを受けて求められる対応｜日本総研

サードパーティリスクが企業にもたらす4つの影響

サードパーティ経由のリスクが顕在化したとき、企業が受ける影響は複数の次元にわたります。リスク管理の優先順位を決めるためにも、どのような損失が発生しうるかを具体的に把握しておくことが重要です。

サイバーセキュリティリスク

最も直接的な影響がサイバーセキュリティ上のインシデントです。ベンダーのシステムを経由したランサムウェアの感染、SaaS経由の不正アクセス、APIを悪用したデータ窃取などが代表的なケースです。サプライチェーン攻撃では、信頼されているベンダーのソフトウェアアップデートにマルウェアを混入させる手口も確認されており、従来の境界防御だけでは対処が困難です。

SaaSが業務インフラとして普及した現在、多くの企業が数十から数百のSaaSアプリを利用しています。各ベンダーのセキュリティ対策水準のばらつきが、そのままサプライチェーン全体の脆弱性につながります。

コンプライアンスリスク

ベンダーが法令違反や規制違反を犯した場合、そのサービスを利用している企業も問われる可能性があります。個人情報保護法や金融庁ガイドラインでは、委託先の管理責任が委託元企業に課せられています。ベンダーがデータ保護義務を果たしていなかった場合、委託元の企業も監督責任を問われます。

業務継続リスク

ベンダーのシステム障害、倒産、サービス終了が発生した場合、そのベンダーのSaaSに依存した業務が突然停止するリスクがあります。特に基幹業務をSaaSに移行している場合、代替手段の準備がなければ業務停止が長引きます。

評判・信頼リスク

ベンダーによる情報漏洩で自社の顧客データが流出した場合、顧客や市場からの信頼を失います。自社に直接の過失がなくても、ベンダー選定の責任が問われます。

参考：サードパーティベンダー管理：リスク監視とコンプライアンス｜Kiteworks

国内外の規制・ガイドラインが求めるサードパーティ管理

サードパーティリスク管理に関する規制要件は、国内外で急速に整備が進んでいます。情シス担当者は自社が適用される規制を把握し、その要件を充足する管理体制を構築する必要があります。

バーゼル銀行監督委員会の基本原則（2025年12月）

2025年12月10日にバーゼル銀行監督委員会が公表した「健全なサードパーティリスク管理のための諸原則」は、全12原則で構成されます。原則1〜9が銀行向け、原則10〜12が監督当局向けです。銀行向けの原則では、ガバナンス、リスク評価、デューデリジェンス、契約締結、オンボーディング・継続モニタリング、業務継続管理、契約終了の各フェーズで求められる管理水準が明確化されました。

金融庁ガイドラインの要求事項

金融庁は「金融分野におけるサイバーセキュリティに関するガイドライン」において、サードパーティをシステム子会社、ベンダー、クラウド事業者、業務提携先として定義し、これらへの管理義務を明確化しています。具体的な要求事項として、管理台帳の整備、取引開始前のデューデリジェンス、リスクの重大性に応じた継続的なモニタリングが求められます。

欧州のDORA（デジタル運用強靭性法）

欧州では2025年1月17日に適用が始まったDORA（Digital Operational Resilience Act）が金融機関に対して厳格なICTサードパーティリスク管理を義務付けています。日本企業でも欧州に拠点を持つ場合は適用対象となりえます。DORAのフレームワークは、金融機関以外の企業にとっても優れた参照基準として活用できます。

SCS評価制度（サプライチェーン強化に向けたセキュリティ対策評価制度）

金融機関以外の企業にとって身近な国内の枠組みが、SCS評価制度です。経済産業省と内閣官房国家サイバー統括室が2026年3月に制度構築方針を公表し、運営はIPAが担います。発注元・受注先・再委託先など、企業規模や立場を問わずサプライチェーンを構成するすべての企業が対象です。

制度が定める段階は★3と★4で、★3は要求事項26・評価基準81、★4は要求事項43・評価基準153で構成されます。要求事項の大分類の一つが「取引先管理」で、運用のサイクルには年1回の取引先の確認も含まれます。運用開始は2026年度末頃が想定されている任意の制度で、取引に規制を設けるものではありません。取引先から★3を求められたときの考え方は、取引先にセキュリティ評価を要求されたときの対応で整理しています。

参考：金融機関のサードパーティ・サイバーセキュリティリスク管理強化に関する調査｜金融庁

参考：Principles for the sound management of third-party risk｜Basel Committee on Banking Supervision

サードパーティリスク管理の4ステップ実践手順

サードパーティリスク管理（TPRM）を効果的に実施するための体系的なアプローチを紹介します。個々の対策を場当たり的に実施するのではない、ライフサイクル全体を通じた管理の仕組みを構築することが重要です。

ステップ1｜サードパーティの特定と分類

まず、自社が関係するすべてのサードパーティを洗い出すことから始めます。業務委託先、SaaSベンダー、クラウド基盤事業者、システム開発会社、データ連携パートナー、間接的なサブコントラクターまで網羅的に把握する必要があります。

把握したサードパーティは、ビジネスへの影響度と取り扱うデータの機密性に基づいてティア分けします。多くの企業では以下の3段階に分類しています。

• ティア1（高リスク）: 機密情報にアクセス可能、または業務停止が経営に直結するベンダー
• ティア2（中リスク）: 一定量の社内データを扱うが、代替手段がある程度あるベンダー
• ティア3（低リスク）: 機密情報へのアクセスがなく、業務への影響が限定的なベンダー

ティア1に分類されたベンダーには最も厳密な管理を適用し、管理リソースを効率的に配分します。SaaSが増殖しやすい現代の環境では、把握できていない「野良SaaS」の存在も問題です。IT部門が承認していないSaaSを従業員が業務利用しているケースは珍しくなく、これらも含めて棚卸しを行う必要があります。

参考：【解説】サードパーティのサイバーセキュリティリスク管理｜効果的な4つの実施ステップ｜NRIセキュア

ステップ2｜セキュリティリスク評価（デューデリジェンス）

サードパーティを特定した後は、各ベンダーのセキュリティ水準を評価します。評価は取引開始前に実施するものと、継続的に行うモニタリングの2段階で構成されます。

取引開始前のデューデリジェンスでは、以下の5区分でアセスメントを実施することが推奨されます。

評価はセキュリティアンケートの送付が一般的ですが、回答の信頼性を高めるために独立した第三者による監査報告書（SOC2レポート等）の提出を求めることが有効です。また、OSINTやセキュリティスコアレーティングサービスを活用することで、ベンダーのセキュリティ状況を客観的に評価できます。SaaSベンダーに絞った評価項目とリスクスコアの付け方は、SaaSセキュリティ評価チェックリストで詳しく紹介しています。

ステップ3｜契約への反映

評価結果を踏まえ、ベンダーとの契約にセキュリティ要件を明記します。口頭での合意や覚書だけでは不十分で、法的拘束力のある契約条項として盛り込むことが重要です。

契約に含めるべき主要な項目は以下のとおりです。

• インシデント報告義務: セキュリティインシデント発生時の報告期限（24時間以内など）と報告先
• 監査権: 定期的またはインシデント発生時に自社がベンダーのセキュリティ状況を監査できる権利
• セキュリティ基準の維持義務: 特定の認証の維持や最低限のセキュリティ対策の実施
• データ取扱い規定: 自社データの取扱い方法、保管場所、保持期間、廃棄方法
• 再委託の制限: サブコントラクターへの再委託に関する承認手続きと同等のセキュリティ要件の適用
• 契約終了時のデータ返還・廃棄: サービス終了時のデータ処理方法の明確化

ステップ4｜継続的なモニタリングと再評価

サードパーティのセキュリティ状況は静的なものではなく、時間とともに変化します。一度評価を行って終わりにするのではなく、定期的な再評価とリアルタイムのモニタリングを組み合わせた継続的な管理が必要です。

継続的モニタリングで把握すべき変化には以下のものがあります。

• ベンダーでのセキュリティインシデントの発生
• 認証・認定の失効や更新
• ベンダーの組織変更（買収・合併等）によるセキュリティ体制の変化
• 新たなサブコントラクターの追加
• サプライチェーンの構成変化

年1回の定期評価を基本としつつ、ティア1ベンダーについては四半期ごとのレビューや外部情報ソースを活用したリアルタイム監視を組み合わせることが理想的です。

参考：金融分野におけるサイバーセキュリティに関するガイドラインを解説｜assured.jp

サードパーティ・ベンダー評価チェックリスト｜取引開始前から契約終了まで

ベンダー評価で確認する項目は、取引開始前・契約時・利用中・契約終了時の4つの場面で変わります。ベンダー管理のプロセス全体を見渡せるよう、場面ごとの確認項目をティア別の要否つきで一覧にしました。ティア1はすべての項目を確認し、ティア3は必須の項目から着手します。

見落とされやすいのは契約終了時の項目です。SaaSを解約しても、連携用のAPIキーや管理者アカウントが自社側に残っていると、ベンダー側で事故が起きたときの入口になります。台帳上で解約を記録するのと同時に、連携設定の削除まで確認してください。

SaaS時代のサードパーティリスク管理が難しい3つの理由

従来の委託先管理と比べて、SaaS時代のサードパーティリスク管理がより困難になっている背景を理解しておく必要があります。難しさの本質を把握することで、有効な対策を講じやすくなります。

把握困難なSaaS利用の増加

クラウドサービスへのアクセスが容易になった結果、事業部門が情報システム部門の承認なしにSaaSを契約・利用するケースが増えています。IT部門の管理外にあるSaaSは、セキュリティ評価も契約管理もされておらず、重大なリスクの温床になります。利用しているSaaSを洗い出してみると、情シスが把握していなかったSaaSが見つかることは珍しくありません。

SaaSの利用状況を網羅的に把握するためには、ネットワークレベルの通信ログ分析や、デバイスに導入したエージェントによる通信監視が有効です。Josysのように350以上のアプリと連携するツールを使うと、連携先のSaaSの利用状況を継続的に把握できます。

サプライチェーンの多層化

ベンダーがさらに別のベンダー（サブコントラクター）を利用するケースが一般化し、サプライチェーンが多層にわたることが珍しくなくなっています。自社から直接見える一次ベンダーだけを評価していても、一次ベンダーが利用するクラウド基盤や開発ツールに脆弱性があれば、最終的に自社のデータや業務が影響を受けます。

バーゼル銀行監督委員会が公表した諸原則でも、「サプライチェーンの遥か先にいるパーティーとの関係が孕むリスク」を把握する重要性が強調されています。

評価リソースの不足

中堅・大企業でも、数百社規模のサードパーティを抱えることは珍しくありません。すべてのベンダーに対して詳細なアセスメントを実施するためのリソース（人員・時間・予算）が不足しているケースがほとんどです。ティア分けによる優先順位付けと、自動化ツールの活用が不可欠です。

情シスが実践すべきサードパーティリスク管理の体制整備

サードパーティリスク管理を継続的に機能させるためには、個別の対策だけでなく、組織としての体制と仕組みを整える必要があります。

管理台帳の整備と最新化

すべてのサードパーティの情報を一元管理する台帳を整備します。台帳に含める情報は、ベンダー名、提供サービス、業務上の役割・重要度、自社データへのアクセスレベル、保持するデータの種類、契約情報（更新日・期限）、リスクティア、最終評価日、担当者名です。

台帳は一度作成すれば終わりではなく、新規導入・契約更新・解約のたびに更新する運用ルールを定めることが重要です。更新の漏れを防ぐために、調達プロセスや発注フローに組み込む形が理想的です。

責任部門とガバナンス体制の明確化

サードパーティリスク管理の責任が曖昧なままでは、評価や対応が後手に回ります。情報システム部門が主管となり、法務・調達・事業部門と役割を分担する体制を構築します。特に、新規ベンダーの採用承認プロセス、リスク許容度の判断基準、インシデント発生時のエスカレーション経路を明文化しておくことが重要です。

インシデント対応計画の準備

ベンダーでのセキュリティインシデントが発生したとき、自社としてどう対応するかをあらかじめ定めておきます。ベンダーへの情報提供要求の手順、業務の代替手段、顧客や規制当局への報告フローをインシデント対応計画に含めます。計画は机上演習（テーブルトップ演習）で年1回以上検証することを推奨します。

SaaSを活用したTPRMの自動化とツール選定

手動によるTPRM運用には限界があります。ベンダー数が増えるほど管理負荷が増大し、情シス担当者の工数を圧迫します。SaaSを活用した自動化により、評価・モニタリング・台帳更新の効率を大幅に向上できます。

TPRM自動化で実現できること

TPRMツールで自動化しやすいのは、評価の配布と回収、期限の管理のような定型作業です。代表的な機能は次のとおりです。

• 定期アセスメントの自動送付と回答ステータスの追跡
• セキュリティスコアレーティングサービスとの連携によるリアルタイム評価
• 契約更新日のアラート通知
• 認証・認定の有効期限管理

ただし、TPRM専用ツールを導入するだけでは、SaaSの利用状況の把握という根本的な問題が解決しません。情シス部門が把握していないSaaSをいかに検出するかが、サードパーティリスク管理の出発点です。

ベンダー管理ソリューションの種類と選び方

ベンダー管理に使えるソリューションは、得意な工程によって4種類に分かれます。どれか1つで全工程をまかなうより、自社のベンダー数と、台帳がすでにあるかどうかで組み合わせを決めるほうが無駄が出ません。

台帳がまだない段階で評価ツールから導入すると、管理外のSaaSが評価の対象から漏れます。まず利用実態を把握してティア1を固め、そのうえで評価や監視のツールを足す順番にすると、投資が無駄になりにくくなります。

SaaS管理プラットフォームとの連携

Josysは、350以上のアプリとの連携と、ログインやブラウザの活動からSaaSの利用状況を検出するSaaS Discoveryによって、どのベンダーのSaaSを誰が使っているかを把握できるようにします。未承認のSaaSが使われていないかを継続的に確認できるため、サードパーティ管理台帳の元データとして活用できます。

2021年のサービス開始以来、国内外1,000社以上に導入されており、事例によってはIT工数を最大50%、ITコストを最大75%削減したケースもあります（効果は個社の状況により異なります）。

SaaS管理とセキュリティを一体で管理する視点については、以下の記事も参考にしてください。

関連記事：SaaSセキュリティとは？基本的な考え方とリスク・対策

関連記事：SaaSセキュリティのリスク7選｜情シスが把握すべき脅威と対策の方向性

サードパーティリスク管理を加速させるJosysの活用方法

情シス担当者がサードパーティリスク管理をより効率的に運用するために、Josysが提供できる価値を具体的に紹介します。

SaaSの利用状況の自動把握

まず把握できていないものは管理できません。Josysは350以上のアプリとAPIで連携し、連携先のSaaSとその利用者を一覧にします。ブラウザ拡張機能によるSaaS Discoveryを組み合わせると、IT部門が承認していない野良SaaSの利用も検出できます。

これにより、「どのベンダーのSaaSを誰が使っているか」「各SaaSに設定されているアクセス権限は適切か」を一か所で確認でき、サードパーティリスク評価の基盤データとして活用できます。

事例：関西電力が審査を通っていないクラウドサービスを洗い出した方法

関西電力のIT戦略室サイバーセキュリティグループは、承認済みのクラウドサービスをSharePoint Online上の台帳で管理していましたが、利用実績がわからず、誰が何を使っているかを突き合わせられずにいました。社内監査では、契約はあるものの審査を通っていないサービスが複数見つかっていたといいます。

3か月のPoCとしてJosysの「SaaSドック」を実施したところ、初回で916件のクラウドサービスが検知されました。承認済みの台帳と突き合わせて高頻度で使われている141件に絞り込み、最終的に対処すべきものを十数件まで特定しています。利用が認められていないサービスの利用者に申請や利用の見直しを伝えるうえで、ブラウザの拡張機能を通じて人（アカウント）を軸に管理できることが導入の決め手になったとしています。

参考：関西電力の導入事例｜Josys

アクセス権限の一元管理と最小権限の実現

業務委託先の担当者に発行したアカウントも、連携対象のSaaSであれば社員と同じ一覧で管理できます。Access Reviewsで定期的に権限を見直すと、不要な権限が残ったままの「孤立アカウント」や過剰な権限を洗い出せます。孤立アカウントが生まれる原因と見つけ方は、孤立アカウントとはで解説しています。

連携対象のSaaSでは、入退社や人事異動にともなう権限の変更をAccess Automationで自動化できるため、委託先の担当者の契約が終わったときの削除漏れも減らせます。

ゼロトラストセキュリティの実践基盤

ゼロトラストセキュリティの考え方では、「信頼できるネットワーク内にいるから安全」という前提を捨て、すべてのアクセスを検証します。サードパーティのベンダーも例外ではなく、常に最小限の権限で認証を要求し、アクセスログを記録することが求められます。Josysは、誰がどのSaaSにどの権限でアクセスできるかを把握する土台として、ゼロトラストの運用を支えます。

ゼロトラストの詳細については、以下の記事をご参照ください。

関連記事：ゼロトラストセキュリティとは

関連記事：SaaSアクセス管理とは

Josysの機能と導入効果は、5分で読める製品資料でご確認いただけます。

Josys製品資料をダウンロードする（5分でわかるJosys）

サードパーティリスク管理のよくある失敗と対策

実際にTPRM推進に取り組む情シス担当者からよく聞かれる課題と、その対処方法を整理します。

失敗1: 台帳が整備されないまま管理が形骸化する

サードパーティ管理台帳を作成しても、更新が追いつかず内容が古くなるケースは非常に多いです。根本的な原因は、台帳の更新が調達・発注フローから切り離されていることです。新規SaaS導入や既存契約の変更時に、台帳更新を必須の承認ステップとして組み込むことで、自然に最新状態を保てます。

失敗2: 評価が取引開始時のみで終わる

デューデリジェンスを取引開始前にしか実施しない企業は多くあります。しかし、ベンダーのセキュリティ状況は時間とともに変化します。認証の失効、組織変更、新たな脆弱性の発見など、継続的なモニタリングなしには把握できない変化が多数あります。年1回以上の定期評価をカレンダーに組み込み、担当者に通知が届く仕組みを作ることが重要です。

失敗3: 契約書にセキュリティ要件が書かれていない

既存ベンダーとの契約を確認すると、セキュリティ関連の条項が一切ない、あるいは抽象的な表現にとどまっているケースが少なくありません。インシデント報告義務や監査権を明記していないと、問題発生時に情報収集や是正措置の要求ができません。既存契約は更新タイミングに合わせて順次見直し、新規契約には必ずセキュリティ条項のひな形を組み込みます。

失敗4: 情シス部門だけが対応しようとする

サードパーティリスク管理には法務・調達・事業部門の協力が不可欠です。情シスが単独で推進しようとすると、全社的な承認フローの整備が進まず、非公式にSaaSを導入する事業部門の行動を止められません。経営層の理解を得て、全社横断のガバナンス体制として位置付けることが成功の前提です。

サードパーティリスク管理の評価指標（KPI）の設定方法

TPRMの取り組みを継続的に改善するには、進捗を測る指標を設定することが重要です。定性的な「管理している」という状態から、定量的な達成状況の把握へと移行します。

情シス担当者が設定する代表的なKPIを以下に示します。

KPIは経営層への報告資料に組み込むことで、サードパーティリスク管理に対する組織全体の関心と投資を維持しやすくなります。

サードパーティリスク管理のまとめと次のアクション

サードパーティ・ベンダーセキュリティリスクの管理は、現代の企業にとって後回しにできない経営課題です。SaaSや外部ベンダーへの依存が深まるほど、自社の管理が届かない領域でのリスクが高まります。

管理の4ステップを改めて確認します。

• 特定と分類: すべてのサードパーティを把握し、リスクティアに応じて優先順位をつける
• リスク評価: 取引開始前にデューデリジェンスを実施し、セキュリティ水準を定量的に評価する
• 契約への反映: インシデント報告義務・監査権・セキュリティ基準を契約書に明記する
• 継続的モニタリング: 定期評価とリアルタイム監視を組み合わせ、変化を継続的に把握する

SaaS管理プラットフォームを活用することで、サードパーティリスク管理の出発点であるSaaS利用状況の把握と、アクセス権限の適切な管理を効率的に実現できます。

Josysの無料デモでは、SaaS利用状況の可視化からアクセス権限管理まで、実際の画面でご確認いただけます。情シス担当者の業務負担を削減しながら、セキュリティ水準を高める仕組みをご体験ください。

無料デモを申し込む

SaaSセキュリティ管理に関連する以下の記事も合わせてご覧ください。

関連記事：SaaSセキュリティ チェックリスト

関連記事：SaaSのベンダー管理とは

関連記事：サイバーセキュリティ SaaS対策