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

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

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

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

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

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

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

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

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

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

コンプライアンスリスク

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

業務継続リスク

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

評判・信頼リスク

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

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

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

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

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

2025年12月にバーゼル銀行監督委員会が公表した「健全なサードパーティリスク管理のための諸原則」は、金融機関向けに9つの原則を提示しています。ガバナンス、リスク評価、デューデリジェンス、契約締結、オンボーディング・継続モニタリング、業務継続管理、契約終了の各フェーズで求められる管理水準が明確化されました。日本の金融機関はこの原則への対応が求められており、金融庁も国内ガイドラインへの反映を進めています。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

把握困難なSaaS利用の増加

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

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

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

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

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

評価リソースの不足

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

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

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

管理台帳の整備と最新化

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

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

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

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

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

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

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

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

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

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

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

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

ジョーシスのようなプラットフォームでは、350以上のアプリとの連携を通じてSaaSの利用状況をリアルタイムで把握できます。誰がどのSaaSにアクセスしているか、未承認のSaaSが使われていないかを継続的に監視することで、サードパーティリスク管理の基盤データを自動的に収集できます。

ジョーシスを導入した企業では、ITコストの削減最大75%、IT工数削減最大50%の効果が報告されています。700社以上の導入実績を持つプラットフォームとして、中堅・大企業を中心に採用が広がっています。

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

関連記事：SaaSセキュリティとは｜情シス担当者向けのアクセス管理ベストプラクティス

関連記事：SaaSセキュリティリスクと対策｜情シス担当者向け実践ガイド

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

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

SaaSの利用状況の自動把握

まず把握できていないものは管理できません。ジョーシスのプラットフォームは350以上のアプリとAPI連携し、社内で利用されているSaaSとその利用者を自動的にインベントリ化します。ブラウザ拡張機能と組み合わせることで、IT部門が承認していない野良SaaSも含めて検出できます。

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

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

サードパーティのベンダーが自社システムにアクセスする場合も、Josys上で権限を一元管理できます。不要なアクセス権限が残ったままになる「孤立アカウント」や、過剰な権限付与を自動で検知し、アラートを発します。

入退社・人事異動に伴うアクセス権限の変更も自動化できるため、ベンダー担当者の退職時に適切なアクセス削除が漏れるリスクを防げます。

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

ゼロトラストセキュリティの考え方では、「信頼できるネットワーク内にいるから安全」という前提を捨て、すべてのアクセスを検証します。サードパーティのベンダーも例外ではなく、常に最小限の権限で認証を要求し、アクセスログを記録することが求められます。ジョーシスのプラットフォームはこのゼロトラスト実践の基盤として機能します。

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

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

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

ジョーシスの資料では、SaaS管理とサードパーティリスク管理を統合的に進める具体的な手法をご確認いただけます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

無料デモを申し込む

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

関連記事：SaaSセキュリティ対策

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

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