⚠ 本書式は弁護士監修前の草稿である。監修完了まで販売・配布・公開を禁止する。 本書式は一般的な情報提供を目的としたものであり、個別・具体的な法律相談に代わるものではない。

IT・情報セキュリティDD資料依頼リスト

第1部: 書式本文

本リストは、【買収会社名】(以下「依頼者」という。)が【対象会社名】(以下「対象会社」という。)の株式又は事業の取得を検討するにあたり、IT・情報セキュリティの観点から実施するデューデリジェンスのために開示を求める資料を整理したものである。対象会社は、各項目に対応する資料を電子データ又は書面で提出するものとし、該当資料が存在しない場合又は提出が困難な場合は、その理由を付して回答する。

1. システム構成・インフラ関連 - ネットワーク構成図及びサーバ構成図(オンプレミス・クラウドの別を明示) - 主要業務システムの一覧表(自社開発、パッケージ導入、SaaS利用の別を区分) - 利用中のクラウドサービス(IaaS・PaaS)契約書及び直近1年分の利用料請求明細 - サポート終了(EOL)が迫るレガシーシステムの一覧及び更改・移行計画

2. ソフトウェアライセンス・ソースコード - 商用ソフトウェアのライセンス契約書及びライセンス数管理台帳 - OSS(オープンソースソフトウェア)の利用一覧及びライセンス種別(GPL、MIT等)の適合性確認記録 - 自社開発ソフトウェアのソースコードに関する著作権帰属を示す資料(業務委託契約書、成果物譲渡条項等) - 外部開発者・フリーランスへの発注実績及び納品物の権利処理状況

3. 外部委託・SaaS利用状況 - システム開発・保守運用の委託契約書一式(再委託先の有無及びその管理体制を含む) - 主要SaaSの利用契約書一覧並びに委託先における情報管理体制に関する確認資料 - クラウドベンダーとのサービス品質保証(SLA)内容及び障害発生時の対応実績

4. セキュリティ体制・インシデント履歴 - 情報セキュリティ基本方針及び関連社内規程 - 直近3年間の脆弱性診断報告書、ペネトレーションテスト結果及び是正対応の記録 - 不正アクセス、マルウェア感染、情報漏えい等セキュリティインシデントの発生履歴と対応記録 - システム管理者権限の付与状況及びアクセスログの保存・監視体制

5. 個人情報等の取扱い状況 - 個人情報保護方針及び個人情報取扱規程・委託先管理規程 - 保有する個人データの項目、取得目的、保存期間を整理した一覧 - 第三者提供及び業務委託に伴う個人データ提供の状況(委託先との契約条項を含む) - 個人情報保護委員会への報告又は本人への通知を要する事案の有無

6. データ保護・事業継続体制 - バックアップ取得方針及び直近のリストア(復旧)テスト実施記録 - システム障害発生時の事業継続計画(BCP)及び復旧目標時間(RTO)の設定資料 - クラウドベンダーが海外にデータを保管している場合、データ保管地域を示す資料

7. その他 - 直近3年間のIT関連投資額及びシステム関連費用の実績 - 内部監査又は外部監査によるシステム監査報告書 - 主要システムに関わるキーパーソン(責任者・エンジニア)の一覧及び在籍状況

第2部: 立場別・場面別の書き換えパターン

A. 買収側(依頼者)向けの修正

A-1. ソースコードエスクローの確認依頼追加

追加項目例:「対象会社が第三者に開発を委託したソフトウェアについて、ソースコードエスクロー契約の有無及び寄託されているソースコードのバージョンを示す資料」 一言解説: 開発委託先が倒産・撤退した場合の保守継続リスクを見極めるため、エスクロー契約の有無を独立の依頼項目として明示する修正である。

A-2. 再委託先までの遡及的な確認

修正後:「委託先が第三者に再委託を行っている場合、再委託先の名称、業務範囲及び再委託先における情報管理体制についても開示を求める。」 一言解説: 一次委託先のみの確認では実際のデータ処理主体を把握できないため、買収側は再委託構造まで遡って開示を求める修正を行う。

B. 対象会社(提出者)向けの修正

B-1. 開示範囲の競合配慮による限定

修正後:「ソースコード自体の提出に代えて、権利帰属を確認できる契約書及び構成概要資料の提出をもって足りるものとする。」 一言解説: ソースコード自体を開示すると技術情報の流出リスクがあるため、対象会社は権利関係を示す書面の提出に限定する修正を求めることができる。

B-2. データルーム内限定閲覧への変更

追加条件例:「本リストに基づき提出する資料は、印刷及びダウンロードを禁止したバーチャルデータルーム内での閲覧に限定する。」 一言解説: セキュリティインシデント履歴等の機微な資料が社外に流出することを防ぐため、対象会社は閲覧方法を限定する修正を加える。

第3部: 書き方と法的ポイント解説

使う場面/使ってはいけない場面 本リストは、M&Aにおける買収側がシステム統合コストやセキュリティ上の偶発債務を事前に把握するために用いる。単なるシステム紹介資料の依頼にとどまる初期段階の商談では過剰であり、基本合意締結後の本格的なデューデリジェンス段階で用いるのが適切である。逆に、対象会社の事業規模がごく小さくシステム資産がほとんど存在しない場合には、簡易な確認書で足りることもある。

根拠法令 個人情報の取扱い状況の確認は個人情報保護法第20条から第28条までの安全管理措置及び第三者提供規制に関わる。ソフトウェアライセンス及びソースコードの権利関係は著作権法第21条以下の著作権帰属及び利用許諾の規律に関わり、特に職務著作(著作権法第15条第2項)の該当性確認が重要である。また、セキュリティインシデントの調査に際しては、不正アクセス行為の禁止等に関する法律(不正アクセス禁止法)上の被害届出状況や再発防止措置の実施状況を確認する必要がある。

実務でよくある失敗と対策 第一に、SaaSやクラウドサービスの利用契約が部門ごとに個別契約されており、全社的な一覧が存在しないため開示が漏れる失敗がある。第3項のように利用契約一覧の提出を独立項目として求めることが対策となる。第二に、ソースコードの著作権が実は外部委託先に帰属したままになっている失敗がある。A-1及び第2項の権利帰属資料の確認により事前に発見できる。第三に、セキュリティインシデントが社内で報告されずに埋もれているケースがあり、B-2のような限定閲覧環境の整備と合わせて、開示対象期間を明確にすることが対策となる。第四に、バックアップの取得は行っているものの復旧テストが実施されておらず、実際の障害発生時に復旧できないリスクが見過ごされる失敗があり、第6項のリストアテスト記録の確認が対策となる。

個々の資料の要否及び開示範囲の適法性は対象会社の事業内容によって異なるため、個別事案は専門家に確認することが望ましい。

第4部: 使用前チェックリスト

• [ ] 依頼対象期間(直近何年分か)を明記したか
• [ ] システム構成図及び主要業務システム一覧の依頼を含めたか
• [ ] OSSライセンスの適合性確認記録を依頼項目に含めたか
• [ ] ソースコードの著作権帰属を示す資料を依頼項目に含めたか
• [ ] 委託先・再委託先の情報管理体制の確認を依頼項目に含めたか
• [ ] 脆弱性診断報告書及びインシデント履歴の開示範囲を確認したか
• [ ] 個人データの取得目的・第三者提供状況の確認項目を含めたか
• [ ] 開示資料の閲覧方法(データルーム利用の要否)を定めたか
• [ ] 秘密保持契約との整合性を確認したか
• [ ] バックアップ・事業継続体制の確認項目を含めたか
• [ ] キーパーソンの在籍状況の確認項目を含めたか
• [ ] 資料不存在時の回答方法を明記したか