mcpField
V
vendor-due-diligence-patrick-munro

vendor-due-diligence-patrick-munro

github.com/lawve-aiその他907136 回インストール1 週間前に更新
リポジトリ

vendor-due-diligence-patrick-munro について

vendor-due-diligence-patrick-munroは、テクノロジーベンダーやサービスパートナーを評価するリスクベースのフレームワークです。規制対象の業界を含む組織向けに、初期審査からリスク評価、対策、継続的な監視までを扱います。

主な機能

  1. 013段階のベンダー評価
  2. 02財務・法務・セキュリティ・運用の審査
  3. 036領域の加重リスク評価
  4. 04DORAとNIS2の評価ガイダンス
  5. 05リスク対策と継続監視計画
  6. 06ベンダーリスクレポートの形式

活用シーン

  1. 01候補となる技術プロバイダーの審査
  2. 02DORAに基づくICTプロバイダー評価
  3. 03NIS2に基づくサプライチェーンのセキュリティ確認
  4. 04定期的なベンダーリスクレビューの計画

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lawve-ai/awesome-legal-skills --skill vendor-due-diligence-patrick-munro

インストール後、Claude Code で/vendor-due-diligence-patrick-munroを入力して読み込まれたか確認します。

同梱ファイルLICENSE.txtREADME.md

詳細

ベンダーデューデリジェンスのフレームワーク

概要

重大なリスクを早期に特定し、DORA/NIS2/GDPRへの準拠を確保するとともに、選定、契約条件の調整、継続的な管理に関する明確な推奨事項を提示する、リスクベースのベンダー評価フレームワークです。規制対象セクター(DORAの対象となる金融サービス、NIS2の対象となるKRITISセクター)や、ICTサードパーティへの相応の依存があるあらゆる組織向けに設計されています。

法的免責事項

このスキルは、ベンダー評価の目的でのみフレームワークを提供します。法律、金融、その他の専門的な助言を構成するものではありません。ユーザーは以下を行ってください。

  • 管轄区域における具体的な要件について、資格を有する法律顧問に相談すること。
  • 詳細な評価について、金融およびセキュリティの専門家を起用すること。
  • すべての規制要件を独自に確認すること。
  • フレームワークを組織固有のニーズとリスク許容度に合わせて調整すること。
  • このスキルを専門的なデューデリジェンスサービスの代替として依拠しないこと。

このフレームワークはテンプレートです。実際の評価には、法律、金融、サイバーセキュリティ、リスク管理の専門知識が必要です。このスキルの作成者もClaude/Anthropicも、このスキルの出力に基づく判断について責任を負いません。

規制に関する参照情報は2026-04-23時点のものです。 EU(DORA、NIS2、GDPR)およびドイツ(NIS2UmsuCG、BDSG)に関する引用は、同日時点で参照可能な統合版の法令を反映しています。加盟国におけるNIS2の国内法化状況には依然としてばらつきがあります。ドイツのNIS2UmsuCGは2025年12月6日に施行され、BSIの報告ポータルは2026年1月6日に開設されました。使用前に、EUR-LexおよびBundesgesetzblattで、最新の統合版法令と各国の国内法化状況を確認してください。

このスキルを使用する場面

  • 新しいベンダー、テクノロジープロバイダー、サービスパートナーの評価。
  • DORA Art. 28-30に基づく、重要なICTサードパーティのデューデリジェンスの実施。
  • NIS2 Art. 21(2)(d)に基づくサプライチェーンセキュリティ評価。
  • GDPR Art. 28に基づく処理者のデューデリジェンス。
  • ベンダーのオンボーディング文書の作成と評価。
  • 継続的なモニタリングのフレームワーク(四半期ごと、年次、トリガーベース)。
  • 集中リスク評価。
  • 経営幹部向けベンダーリスクレポート。

主な機能

1. 3段階の評価プロセス

フェーズ1:初期スクリーニング(1~2日):ベンダーに詳細評価が必要かどうかを判断するための迅速な評価です。

  • 基本情報の確認(会社登記、経営陣、ビジネスモデル、顧客基盤)。
  • 迅速なリスク指標の確認(最近のネガティブなニュース、公表されている財務データ、コンプライアンスに関する主張、基本的な技術アーキテクチャ)。
  • 初期スクリーニングメモを添えた、採用可否の判断。

フェーズ2:詳細評価(1~2週間):すべてのリスク領域を対象とする包括的な評価です。セクション2を参照してください。

フェーズ3:最終評価(3~5日):総合評価、リスクスコアリング、緩和策、推奨事項の策定です。

2. 詳細評価の項目
財務デューデリジェンス

請求する書類:過去3年分の監査済み財務諸表、商業信用調査レポート、専門職賠償責任保険(最低€5M)、サイバー保険(ITベンダーの場合は最低€5M)、銀行照会先。

分析項目:売上高の推移と収益性、負債水準と流動性比率、顧客集中リスク、財務安定性スコア(1~5)。

レッドフラグ:継続的な損失またはマイナスのキャッシュフロー、顧客集中度が高い(単一顧客からの売上が30%超)、最近の信用格付けの引き下げ、保険の補償内容が不十分。

法務・コンプライアンスのデューデリジェンス

要求する書類:定款および付属定款、重要な契約書(上位5社の顧客およびサプライヤー)、係争中および過去の訴訟、規制当局への提出書類、知的財産ポートフォリオ、データ保護方針およびGDPR関連文書、再委託先の一覧(データ処理者の場合)。

GDPRコンプライアンスの審査(GDPR第28条):プライバシーポリシーおよび通知、DPAのテンプレート、データ侵害への対応手順、国際データ移転の仕組み(SCC、十分性認定)、第30条に基づく処理記録、高リスクの処理に関するDPIAのプロセス。

業界固有の要件:金融サービスの顧客 — DORAコンプライアンス(第28〜30条)、KRITISセクター — NIS2コンプライアンス(第21条)、AIシステム — AI Actの分類およびコンプライアンス。

危険信号:重大な訴訟が係争中(年間売上高の10%超)、規制当局による執行措置、重大な知的財産権侵害の申し立て、GDPRへの不適合(DPAがない、セキュリティが不十分)。

セキュリティと技術のデューデリジェンス

要求する書類:セキュリティ認証(ISO 27001、SOC 2 Type II、該当する場合はPCI DSS)、最近の侵入テストの結果、過去3年間のセキュリティインシデント履歴、事業継続計画および災害復旧計画、バックアップ手順およびテスト記録、技術アーキテクチャ図、データの保存場所に関する文書、再委託先のセキュリティ評価。

セキュリティ評価:暗号化基準(保存時および転送時)、アクセス制御およびID管理、脆弱性管理プログラム、セキュリティ意識向上トレーニング、インシデント対応手順およびSLA、サードパーティによるセキュリティ監査。

NIS2第21条第2項のセキュリティ対策(KRITISベンダー向け)。法律で定められた10項目に対応:

  • (a) リスク分析および情報システムのセキュリティ方針
  • (b) インシデント対応
  • (c) 事業継続(バックアップ管理および災害復旧)ならびに危機管理
  • (d) 直接のサプライヤーおよびサービスプロバイダーとの関係におけるセキュリティ関連事項を含む、サプライチェーンのセキュリティ
  • (e) 脆弱性への対処および開示を含む、ネットワークおよび情報システムの取得、開発、保守におけるセキュリティ
  • (f) サイバーセキュリティのリスク管理対策の有効性を評価するための方針および手順
  • (g) 基本的なサイバーハイジーンの実践およびサイバーセキュリティトレーニング
  • (h) 暗号技術の使用に関する方針および手順、および適切な場合は暗号化
  • (i) 人的資源のセキュリティ、アクセス制御方針および資産管理
  • (j) 適切な場合の多要素認証または継続的認証、安全な音声・ビデオ・テキスト通信、および安全な緊急通信システム

DORAのICTリスク管理(金融サービスベンダー向け):第6〜16条 ICTリスク管理フレームワーク、第17〜23条 インシデント管理、第24〜27条 デジタル運用レジリエンスのテスト、第28〜30条 サードパーティリスクのモニタリング。

危険信号:ISO 27001または同等の認証がない、SOC 2 Type IIがない、最近の重大なセキュリティインシデントへの対応が不十分、バックアップおよびDRが不十分、データの保存場所に関する要件への不適合。

運用面のデューデリジェンス

要求する書類:SLAの実績(最低12か月分)、顧客満足度指標、サポート体制およびエスカレーション手順、変更管理およびリリース手順、サービス稼働率の統計、MTTRデータ。

分析項目:サービス提供の実績、サポートの応答性、技術的能力、拡張性、終了・移行手順。

危険信号:SLA違反が継続している、顧客からの評価が低い、サポート体制が不十分、文書化された終了手順がない。

3. 6 つの側面によるリスクスコアリング

各ベンダーを各側面について 1(低)から 5(重大)で評価します。加重マトリクス:

カテゴリ重みスコア加重スコア
財務リスク20%
運用リスク25%
コンプライアンスリスク30%
セキュリティリスク15%
評判リスク5%
戦略リスク5%
合計100%

重要なサービス(決済処理、顧客データシステム、中核業務)では、セキュリティ要因とコンプライアンス要因の重みを 2 倍にします。

リスクスコアの解釈:

  • 4.0-5.0:低リスク。標準条件で進めます。
  • 3.0-3.9:中リスク。強化されたデューデリジェンスが必要です。
  • 2.0-2.9:高リスク。追加の保護措置が必要です。
  • 1.0-1.9:重大なリスク。代替ベンダーの検討または却下が必要です。
4. DORA に基づく重要ベンダーの評価

金融サービスのクライアントについては、DORA Art. 28-30 により、ICT サードパーティサービスプロバイダーに対する強化された要件が定められています。

DORA Art. 28 - 一般原則:包括的な ICT サードパーティリスク管理フレームワーク、すべてのサービスに関する完全な契約文書、すべての ICT サードパーティ依存関係の特定、包括的な退出戦略。

DORA Art. 30 - 必須の契約要素:サービスの説明(明確、完全、最新であること)、サービス提供場所(再委託を含む)、サービスレベル(測定と報告を伴う SLA)、GDPR に準拠した DPA、最低限のセキュリティ基準、可用性と事業継続性(DR/BCP)、詳細な退出戦略、定期監査および理由に基づく監査の権利、異議申し立て権を伴う再委託の事前通知、当局(BaFin、ECB、ESMA)の検査権に基づくアクセス、解除権(重大な違反、規制上の懸念)、適切な責任分担、重大な変更、インシデント、規制変更に関する通知要件。

集中リスク(Art. 28(4)):そのベンダーを複数の金融機関が利用していますか?それによりシステミックリスクが生じますか?代替手段はありますか?依存度はどの程度ですか?

代替可能性(Art. 28(4) を Art. 29 と併せて解釈):3〜6 か月以内にベンダーを切り替えられますか(計画の目安となる期間です。DORA 自体は固定期間ではなく、Art. 30 に基づく「適切な移行期間」を求めています)?技術的なロックインはありますか?データポータビリティは確保されていますか?契約上の退出障壁はありますか?

ICT の再委託(Art. 30(2)(a) を、再委託に関する委員会委任規則 RTS、JC 2024 53 と併せて解釈):すべての再委託先が特定されていること、再委託先の所在地が文書化されていること、再委託先のセキュリティが検証されていること、再委託先の変更に関する通知プロセスが整備されていること。

5. NIS2 に基づくベンダー評価

NIS2 の適用範囲に含まれるベンダー(必須事業体/重要事業体の義務が適用される KRITIS セクター)については、Art. 21 によりサイバーセキュリティリスク管理措置が求められます。

Art. 21(2) の措置に基づく必須評価は、上記のセクション 2 に列挙されています。サプライチェーンセキュリティ(Art. 21(2)(d)):ベンダー独自のサイバーセキュリティ対策の検証、ベンダーのサプライチェーンセキュリティ慣行の評価、契約上のサイバーセキュリティ義務の盛り込み、定期的なベンダーセキュリティレビュー、ベンダーのインシデント通知要件。

6. リスク軽減策

財務:契約期間を短縮する(1~2年)。買い手を保護する支払条件(前払いではなくNet 30)。親会社による保証。履行保証またはエスクロー。財務レビューの頻度を高める。

コンプライアンス:GDPR、DORA、NIS2に関する契約条項を強化する。四半期ごとの監査権。コンプライアンス状況の定期的な証明。規制変更の通知を義務付ける。コンプライアンス違反時の解除権を含む、より厳格なSLA。

セキュリティ:認証を継続的な義務として要求する。ベンダー負担による年次ペネトレーションテスト。インシデント通知を72時間以内ではなく24時間以内とする。監視とログ記録を強化する。MFA要件。定期的なセキュリティ評価。

運用:実効性のあるサービスクレジットを含む堅牢なSLA。詳細な終了および移行手順。重要なアプリケーションのソースコードエスクロー。重要なサービスの複数調達。パフォーマンスレビューの頻度を高める。

戦略:契約期間を制限する。退出条項を設ける。独自仕様によるロックインを避ける。複数調達の選択肢を維持する。

7. 継続的なベンダー管理

四半期ごとのレビュー:SLA遵守状況。サービス品質。セキュリティインシデント。財務安定性(四半期データが入手可能な場合)。コンプライアンス状況。

年次評価:リスクスコアリングマトリックス全体を更新する。契約の履行状況と商業条件をレビューする。市場の代替候補と価格を確認する。戦略との整合性を確認する。更新または終了を決定する。

トリガーに基づくレビュー(即時):重大なセキュリティインシデントまたはデータ侵害。規制当局による執行措置。重大な訴訟。財務的な窮境(信用格付けの引き下げ、重大な損失)。買収または所有権の変更。サービス品質の低下。SLA違反の繰り返し。重大な契約違反。

8. 出力形式

ベンダーリスクレポート(10~20ページ):エグゼクティブサマリー。ベンダーの背景。財務評価。法務およびコンプライアンスレビュー。セキュリティおよび技術評価。運用評価。根拠を添えたリスクスコアリングマトリックス。軽減策の提案。推奨する契約条件。導入および監視計画。付録。

ベンダー評価サマリー(2~3ページ):ベンダーの概要とサービス。リスクスコアのサマリーテーブル。主な調査結果。推奨事項(進行/条件付き/却下)。必要な契約条件。次のステップ。

ベンダー比較マトリックス:リスクスコアの横並び比較。コンプライアンス対応範囲の比較。費用対効果分析。強み/弱み。根拠を添えた推奨ベンダー。

ベンダーリスク台帳(スプレッドシート):ベンダー名とID。サービスタイプと重要度。カテゴリ別リスクスコア。総合評価。前回の評価日。次回のレビュー日。主なリスクと軽減策。契約の主要条件。主な連絡先。エスカレーション先の連絡先。

ベンダーオンボーディングチェックリスト:デューデリジェンスの完了と承認。契約の交渉と締結。保険証明書の受領。DPAの署名。セキュリティ関連書類のレビュー。アクセス権の付与完了。統合計画の承認。サービス移行のスケジュール。監視手順の導入。関係管理の担当者の割り当て。リスク台帳へのベンダーの追加。初回の四半期レビューの予定設定。

ベストプラクティス

  1. 詳細な評価に投資する前に、フェーズ1のスクリーニングから始めます。
  2. サービスの重要度とリスクエクスポージャーに応じて、デューデリジェンスの深さを調整します。
  3. リスクスコアリングを使って契約条件を調整します。
  4. すべての調査結果と推奨事項を文書化します(監査証跡)。
  5. 法務、IT/セキュリティ、調達、事業部門、コンプライアンス部門を通じて関与させます。
  6. 認証を発行機関に直接確認します。
  7. 現在の顧客に照会してリファレンスを確認します。
  8. ベンダー自身のベンダー管理慣行をレビューします。
  9. 初回評価だけでなく、継続的な監視も計画します。
  10. 組織全体のベンダーエクスポージャーを追跡し、危険な集中を特定します。

よくある間違い

  1. 実績のあるベンダーに対する財務デューデリジェンスを省略する。
  2. 検証せずにベンダーの自己評価を受け入れる。
  3. 重要なベンダーに対するDORA/NIS2の要件を無視する。
  4. 文書化されたリスク軽減策なしにベンダーを承認する。
  5. 撤退や移行の実現可能性の評価を忘れる。
  6. サブプロセッサーや第4者に関するリスクを見落とす。
  7. オンボーディング後の継続的なモニタリングを怠る。
  8. 法務およびセキュリティの審査なしにベンダーを承認する。

制限事項

このスキルは、専門的なデューデリジェンスサービスに代わるものではなく、法的助言を提供するものでも、ベンダーのパフォーマンスを保証したりリスクを排除したりするものでも、組織固有のリスクフレームワークに代わるものでもありません。また、専門家による検証なしに規制上の義務を満たすものでもなく、弁護士と依頼者の関係や受託者関係を生じさせるものでもありません。

ユーザーは、フレームワークを自らの業界、法域、リスク許容度に合わせて調整する必要があります。規制対象の評価では適格な専門家に依頼し、最新の規制要件を確認し、社内承認を取得し、監査とコンプライアンスに備えて文書を保管し、規制の変化に合わせて評価基準を更新してください。

使用例

  1. DORAに基づき、重要な決済システム向けのクラウドサービスプロバイダーを評価する金融機関。
  2. 保護対象の医療情報を取り扱うSaaSベンダーを評価する医療機関。
  3. KRITISの対象となる製造業者が、産業用制御システムプロバイダーのNIS2サプライチェーンセキュリティ評価を実施する。
  4. Eコマースプラットフォームが、PCI DSSに基づき決済処理業者のデューデリジェンスを実施する。
  5. 政府機関が、クラウドインフラストラクチャに対するFedRAMPコンプライアンス評価を実施する。
  6. スタートアップが、リスクが限定的で重要ではないサービスについて迅速なベンダー審査を実施する。

コメント