M&AのサイバーセキュリティDD完全ガイド｜情報資産・契約・侵害対応を実務で点検

1．M&AのサイバーセキュリティDDとは何か

M&Aのサイバーセキュリティ・デューデリジェンスとは、対象会社が抱えるサイバーリスクを取引時点で識別し、そのリスクが企業価値、契約責任、事業継続、統合計画に及ぼす影響を評価する調査です。狭い意味の「ウイルス対策ソフトが入っているか」という確認ではありません。誰が、どの情報を、どのシステムで、どの委託先と扱い、事故時にどこまで検知・封じ込め・復旧・説明できるかを一続きの経営システムとして見ます。

財務DDが過去の収益と債務を、法務DDが権利義務と紛争を、IT DDがシステムの機能・費用・拡張性を主に調べるのに対し、サイバーセキュリティDDはそれらの境界を横断します。たとえば顧客管理SaaSの管理者権限が一人に集中している問題は、技術統制の欠陥であると同時に、個人データの安全管理、重要業務の単一障害点、退職時のアクセス回収、買収後の運用費という論点です。担当領域ごとの調査結果を最後に寄せ集めるだけでは、この連鎖を見落とします。

また、認証取得の有無は出発点にすぎません。ISO/IEC 27001、SOC報告書、プライバシーマークなどは、対象範囲、基準日、例外事項、補完的利用者主体統制を読まなければ評価できません。認証範囲外の子会社や開発環境に重要データが置かれていることもあります。証明書の存在を「安全」の代替指標にせず、実際の取引スコープと証明対象が重なるかを確認します。

経済産業省とIPAの「サイバーセキュリティ経営ガイドライン Ver3.0」は、サイバーセキュリティを経営課題として扱い、経営者が認識すべき3原則と担当幹部に指示すべき重要10項目を示しています。M&A専用の合否基準ではありませんが、経営責任、リスク管理、サプライチェーン、復旧、情報共有までを俯瞰するため、DDの質問体系を漏れなく組み立てる基礎として有用です。

IT DD、プライバシーDD、サイバーDDの境界

実務上は領域間の重複をなくそうとしすぎない方がよいでしょう。同じ顧客契約を法務担当は責任制限の観点から、セキュリティ担当は事故通知と監査権の観点から読みます。重要なのは調査担当の縄張りではなく、重複して見た結果を共通の論点IDで束ね、最終判断で矛盾を残さないことです。

2．ネットワーク・端末・メール・OTを点検する

技術環境の点検は、製品名の一覧ではなく、重要業務へ至る攻撃経路の確認から始めます。インターネット、取引先接続、リモートアクセス、メール、端末、ID基盤、サーバ、クラウド、バックアップ、製造設備の関係を一枚の論理図で表し、信頼境界と管理主体を示します。構成図の更新日が古い場合は、ルーティング、ファイアウォール、クラウド接続、EDRの管理画面など別の証拠と照合します。

資産台帳では、ホスト名や機種だけでなく、業務オーナー、技術オーナー、設置場所、OS・ファームウェア、サポート期限、外部公開、扱うデータ、重要度、バックアップ、監視、委託先を紐付けます。端末管理ツール、EDR、ディレクトリ、DHCP、クラウド請求と台帳の件数が一致しないときは、母集団の定義を確認します。差分を無理に一つの数字へまとめず、未管理端末、休眠端末、重複、検出不能という内訳に分けます。

ネットワークとリモートアクセス

ファイアウォールがあることより、誰がルールを申請・承認・棚卸しし、不要な経路を閉じているかが重要です。拠点間VPN、ベンダー保守回線、リモートデスクトップ、無線LAN、ゲストネットワーク、クラウドへの専用線、買収元親会社への接続を確認します。長年使われた一時ルール、送信元を限定しない管理ポート、退職した委託先用VPNは、台帳から漏れやすい入口です。

ネットワーク分離は、図上のVLANだけでは評価できません。境界で許可される通信、認証の分離、管理端末、ログ、例外経路を見ます。攻撃者が一般端末を起点に、ID管理、仮想基盤、バックアップへ順に到達できるなら、サーバごとの防御製品があっても全体の回復力は低くなります。Day1接続では、対象会社から買い手側への通信を必要業務に限定し、監視と遮断権限を明確にします。

端末・サーバと基本設定

端末では、OS更新、暗号化、EDR、ローカル管理者、USB等の外部媒体、画面ロック、MDM、紛失時の遠隔無効化を確認します。すべての端末が同じ統制を持つとは限りません。役員端末、開発者端末、工場共有PC、持込端末、海外拠点、長期出張者、委託先貸与端末を母集団から分け、対象外の理由と代替統制を確かめます。

サーバでは、保守期限、構成標準、不要サービス、管理経路、特権操作、時刻同期、監視、バックアップエージェントを見ます。保守切れOSが一台あるという事実だけで重大度を決めず、外部からの到達性、格納データ、代替可能性、脆弱性、隔離、更新計画を合わせます。一方、台帳にない保守切れサーバが認証基盤へ接続されているなら、統制全体の信頼性に影響します。

メール、ドメイン、DNS

メールは侵入経路であると同時に、契約、顧客連絡、パスワード再設定の基盤です。多要素認証、なりすまし対策、危険な自動転送、メールボックス委任、旧式認証、管理者監査、退職者アカウントを点検します。ドメイン登録事業者のアカウント、DNS、証明書、メール送信認証の管理者が旧オーナー個人になっていると、株式を取得しても実効支配を得られないおそれがあります。

外部向けドメインはブランド資産でもあります。本番サイトだけでなく、旧キャンペーン、採用、検証、短縮URL、送信用サブドメインを洗い出します。期限切れドメインを第三者に取得されれば、フィッシングや過去メールの再利用につながります。レジストラ移管、DNS変更凍結、証明書更新、連絡用メールの切替えをクロージングチェックに含めます。

OT・IoT・医療機器など停止影響の大きい環境

工場、倉庫、ビル設備、検査装置、店舗端末などのOT・IoTでは、通常のITと同じスキャンを安易に実施しません。古いプロトコルや機器は、探索だけでも停止する可能性があります。資産の安全責任者と保守ベンダーを交え、受動的な確認、既存設定・保守記録のレビュー、計画停止中の検証など、安全を優先した手順を合意します。

OTの重大論点は、可用性だけではありません。ベンダー共通ID、常時開放の遠隔保守、ITネットワークとの無制限通信、USBによる更新、構成バックアップ不足、部品供給終了、復旧担当者の属人化を確認します。安全制御とサイバー対応が衝突する場合に、誰が設備停止を決めるかも事前に明確にします。

3．クラウド・SaaSは設定、契約、出口を一体で見る

クラウドやSaaSを利用しているだけで、対象会社の責任がクラウド事業者へ移るわけではありません。事業者が保護する基盤と、利用企業が担うID、設定、データ、端末、ログ、バックアップ、法令対応の境界をサービスごとに確認します。同じ事業者でもIaaS、PaaS、SaaSで責任分界は異なり、契約プランによって監査ログや保管地域の選択肢も変わります。

一覧化の起点は経理の請求だけでは不十分です。無料プラン、個人カード、販売代理店経由、開発者が作ったクラウドアカウントは請求台帳から漏れます。SSO、メール、DNS、ブラウザ、経費、API連携、モバイル端末、部署ヒアリングを組み合わせ、野良SaaSを探します。発見したサービスは直ちに停止せず、業務依存、データ、所有者、代替、エクスポート方法を確認してから処置を決めます。

クラウド管理面の技術確認

• 組織・テナント・サブスクリプションの法的契約者と実管理者が対象会社か。
• ルートまたは最高権限アカウントの認証、保管、緊急利用、監視が適切か。
• SSO、多要素認証、条件付きアクセス、特権昇格の仕組みが管理者にも適用されるか。
• 公開ストレージ、公開DB、管理ポート、過度に広いセキュリティグループがないか。
• 監査ログが有効で、改ざんしにくい別領域へ保管され、調査に必要な期間利用できるか。
• 暗号鍵、シークレット、APIトークンがコードや共同文書に平文で置かれていないか。
• 本番と開発、顧客ごと、対象事業と残存事業の境界が実際の権限でも分かれているか。
• バックアップと災害復旧が同一障害、同一資格情報、同一請求停止の影響を受けないか。

SaaS契約で見落としやすい条項

SOC報告書や第三者認証を受領したら、意見の種類、対象期間、対象サービスとリージョン、除外事項、指摘、サブサービス組織、利用企業側が実施すべき統制を読みます。報告対象期間の後に重大な変更がないかをブリッジレターや変更説明で補います。対象会社が補完的利用者主体統制を実施していなければ、サービス事業者の統制だけでは目的を達成しません。

カーブアウトでは、譲渡企業様グループ共通テナントからの分離に時間がかかります。メール、チャット、ファイル、CRM、ERP、コード、監視、チケットのデータを対象事業だけ抽出できるか、IDを保ったまま移行できるか、監査ログも渡せるかを確認します。TSAを使う場合は、アクセス、事故対応、変更、バックアップ、データ返還、終了判定をサービス単位で定めます。

4．アプリケーションとソフトウェア供給網のDD

対象会社の価値がソフトウェアに依存する場合、ソースコードが存在するだけでは資産になりません。リポジトリの所有権、開発者アクセス、ビルド再現性、依存部品、秘密情報、デプロイ権限、脆弱性対応、保守人材がそろって初めて、継続的に提供できる事業資産です。外注開発では、契約上の知的財産権帰属と、実際にコード・環境・鍵を引き渡せるかを分けて調べます。

開発工程は、要求・設計・実装・レビュー・テスト・リリース・運用・廃止の流れで確認します。変更承認やコードレビューがあるかだけでなく、保護ブランチを管理者が容易に迂回できないか、CI/CDの実行者が本番秘密情報を読み出せないか、成果物の出所を追跡できるかを見ます。緊急修正の例外手続が常態化している場合は、通常統制より例外経路が実質的な標準になっています。

ソフトウェア資産で確認する証拠

• コードリポジトリ、組織アカウント、管理者、外部コラボレーター、退職者の一覧
• 開発・検証・本番環境の分離、デプロイ承認、ロールバック手順と実行記録
• 依存パッケージ、コンテナ、ベースイメージ、ライブラリ、ライセンスと更新方針
• 静的・動的解析、依存関係検査、秘密情報検出、手動診断の範囲と未解決結果
• 脆弱性受付窓口、外部報告者との調整、修正版の配布、顧客通知の手順
• コード署名鍵、パッケージ公開権限、アプリストア、DNS、証明書の管理主体
• オープンソース利用方針、著作権表示、コピーレフト条件、商用部品の利用許諾
• 生成AI・外部コード補完への入力条件、学習データの権利、出力のレビュー

SBOMは、依存部品を追跡する有力な手段ですが、ファイルがあるだけでは十分ではありません。対象バージョンと一致するか、直接依存だけでなく推移的依存を含むか、ビルド時に更新されるか、脆弱性情報と照合して担当者へ通知されるかを確認します。SBOM未整備なら、ロックファイル、コンテナ一覧、ビルド定義、ソフトウェア構成解析の結果を代替証拠として使えます。

脆弱性件数を単純比較して品質を判断しないことも重要です。検査範囲が広い会社ほど多く見つかり、検査していない会社はゼロ件に見えます。未解決件数には、重複、到達不能、誤検知、代替統制、顧客影響の差があります。発見から評価、優先順位、修正、検証、リリースまでの流れと、期限超過の理由をサンプルで追います。

顧客向けAPIやモバイルアプリでは、認証・認可、レート制限、テナント分離、入力検証、秘密情報、アップデート強制、古いAPIの廃止を見ます。個人情報や決済情報を扱う画面は、第三者スクリプトやタグ管理経由の流出も確認対象です。機能テストが成功していても、別顧客のIDを指定するとデータを読める認可不備は残り得ます。

開発受託会社やフリーランスに依存する場合、アカウントの名義、契約終了後の削除、再委託、端末管理、コード複製、秘密保持、障害対応を確認します。「開発会社しか本番を直せない」状態は、セキュリティと事業継続の両方で交渉材料になります。買収後に関係を継続するなら、個人への暗黙依存を法人間のサービス条件へ置き換えます。

5．脆弱性と外部公開資産：件数ではなく悪用可能な経路を評価する

脆弱性管理では、資産の把握、情報収集、影響判定、優先順位、修正、例外承認、完了確認が循環しているかを見ます。IPAはJVNを通じて国内利用者向けの脆弱性対策情報を提供しています。対象会社がベンダー通知、JVN、その他の信頼できる情報源をどのように監視し、自社資産へ照合しているかを確認します。

CVSSの基本値は比較材料ですが、それだけで期限や重大度を決めません。インターネットから到達できるか、既に悪用されているか、認証が必要か、攻撃に必要な条件、重要データへの経路、サービス停止時の影響、補完統制、修正による停止リスクを合わせます。低い基本値でも外部公開された認証回避が中核業務へつながれば優先度は上がり、高い値でも物理的に隔離された検証機なら対応順を調整できます。

外部公開面の確認では、会社が認識するドメインとIPだけに限定しません。証明書、DNS、クラウド資産、買収した過去ブランド、開発環境、委託先公開サイトなど、合法的な公開情報から候補を作り、所有関係を譲渡企業様へ確認します。ただし、発見したホストへ無断で侵入テストや負荷の高いスキャンを行ってはいけません。対象、時間、送信元、手法、停止条件、緊急連絡先、データ取扱いを文書で承認した範囲に限ります。

スキャン結果をDD証拠に変える手順

1. スキャン対象の母集団、除外、実施日時、認証有無、ツール設定を記録する。
2. 検出結果を資産所有者と照合し、対象会社の資産か、委託先の共有基盤かを区別する。
3. バージョン推定だけの結果は、設定・パッケージ・ベンダー情報で確認し、誤検知を除く。
4. 悪用可能性、到達経路、データ、事業影響、補完統制を付け、単純な深刻度順を修正する。
5. 修正後は再検査または設定証拠で閉じ、リスク受容なら承認者、期限、見直し条件を残す。

パッチ適用率を示すときは、分母と基準日を必ず添えます。「適用率が高い」という説明では、対象製品、重大度、期限、除外、検出不能資産が分かりません。たとえば、管理対象サーバのうち基準日に組織内期限を満たした台数と、期限超過、例外承認、停止中、未評価の台数を別々に示します。数値は管理画面のスクリーンショットだけでなく、抽出条件を再現できる形で受け取ります。

保守終了製品は、直ちに全て交換できるとは限りません。製造設備や業務アプリとの互換性、停止可能日、代替製品、データ移行、ライセンス、ベンダー支援を確認し、隔離、アクセス制限、仮想パッチ、監視などの暫定統制と交換計画を組み合わせます。計画がないまま「外部公開していないから安全」とする説明は、内部侵害後の横展開を考慮していません。

ペネトレーションテストは、ある時点・範囲・条件での検証です。報告書が存在しても、重要APIが対象外、認証後テストなし、修正確認なし、買収後の構成変更前ということがあります。発見事項だけでなく、対象範囲、試験者、実施日、制約、再試験、未修正例外を読み、現在の環境へ適用できる証拠かを判断します。

6．委託先・再委託先・サプライチェーンを追跡する

対象会社のサービスは、クラウド、運用保守、開発、コールセンター、決済、物流、給与、人事、マーケティングなど、多数の外部事業者に支えられています。ベンダー台帳を契約金額順に見るだけでは、無料だが全顧客データへアクセスするツールや、少額だが基幹システムの特権を持つ保守会社を見落とします。事業停止、データ、権限、代替困難性の四つで重要度を分類します。

個人データの委託先については、選定時の評価、契約、継続監督を一続きで確認します。質問票を一度回収しただけでなく、証明書・監査報告の更新、重大変更、再委託先追加、事故、是正計画を追跡しているかが重要です。委託元の監督義務は契約書に「安全に管理する」と書くだけでは完結しません。

重要委託先ごとの確認票

• 提供する業務、アクセス可能なデータ・システム、処理場所、接続方法
• 契約主体、契約期間、自動更新、解除、株主変更・契約譲渡、料金改定
• セキュリティ要件、監査権、証明書、脆弱性対応、ログ、暗号化
• 事故の定義、通知先、通知期限、証拠保全、原因調査、顧客・当局対応への協力
• 再委託の条件、一覧、変更通知、国外処理、再委託先への同等義務
• BCP、復旧目標、テスト、データバックアップ、代替事業者への切替え
• 契約終了時の返還・移行・消去、形式、期間、費用、消去証明
• 責任制限、免責、補償、保険、サービスクレジットと実損の差

契約が対象会社の顧客向け約束と整合するかを逆向きにたどります。対象会社が顧客へ短い事故通知、特定地域での保存、長いログ保持、厳しい復旧目標を約束していても、委託先から必要な情報が得られなければ履行できません。上流の義務より下流契約が弱い差分は、未発生でも潜在的な契約リスクです。

再委託先の先にある集中リスクにも注意します。複数SaaSが同じクラウド、同じID事業者、同じDNS、同じ決済基盤へ依存していれば、ベンダー数が多くても単一障害点です。重要機能について、直接契約先だけでなく、障害時に実際に止まる共通基盤を把握します。

買収によるチェンジ・オブ・コントロールが契約解除や事前同意の対象になる場合、セキュリティ機能を失う時期がクロージングと重なることがあります。運用監視、バックアップ、証明書、メール保護など、停止すれば直ちに露出が増える契約を優先し、同意・再契約・暫定契約をクロージング条件表に置きます。

小規模委託先に大企業向けの監査票をそのまま要求しても、形式的な回答が増えます。重要データを扱うなら最低限必要な統制を明確にし、画面共有、運用記録、外部サービスの活用など、規模に応じた証拠を求めます。改善余力が乏しい場合は、アクセス削減、データ最小化、代替先、契約上の終了支援を含めて判断します。

7．インシデント履歴と現在進行中の侵害をどう調べるか

インシデント一覧には、当局報告や公表をした事故だけでなく、誤送信、端末紛失、不正アクセスの疑い、マルウェア、ランサムウェア、アカウント乗っ取り、内部持出し、Web改ざん、DDoS、委託先事故、長時間障害、バックアップ失敗、脆弱性悪用の報告を含めます。会社が「事故」と呼ばず、問い合わせ、品質問題、ヘルプデスク、保険案件として管理している事象も検索します。

過去一覧の正確性は、複数ソースを照合して確認します。CSIRTやITのチケット、メール隔離、EDR・SIEMアラート、サイバー保険の通知・請求、弁護士・フォレンジック会社への依頼、個人情報保護委員会・所管省庁・警察への連絡、顧客苦情、障害報告、取締役会資料、再発防止計画などです。法的秘匿性や捜査上の制約がある資料は、弁護士が範囲を判断し、結論に必要な事実を限定して共有します。

一件ごとに再構成するタイムライン

1. 最初の侵入または異常：推定を含む場合は、確認事実と分析を分ける。
2. 検知：誰が何の証拠で発見し、どの部署がいつ知ったかを記録する。
3. 初動：アカウント停止、端末隔離、通信遮断、証拠保全の順序と承認者を確認する。
4. 影響範囲：対象データ、本人、顧客、システム、拠点、委託先、停止時間を根拠とともに示す。
5. 対外対応：本人、顧客、保険者、当局、警察、公表の要否判断と実施日時を照合する。
6. 根本原因：侵入口だけでなく、横展開・検知遅延・復旧遅延を許した管理要因を分析する。
7. 再発防止：完了した施策、未完了、効果確認、残余リスク、責任者を追う。

「漏えいは確認されなかった」という表現では、何を確認できたかを掘り下げます。対象ログが存在し、必要な期間をカバーし、調査者が窃取の兆候を検証した結果なのか、それともログがなく確認不能なのかで意味は逆です。暗号化ランサムウェアでも窃取を伴うことがあるため、復旧できたことだけをもって機密性への影響を否定しません。

現在進行中の侵害を完全に否定することは困難です。そこで、直近の特権ログイン、異常転送、永続化、EDR未導入資産、停止されたセンサー、未知の管理者、脅威インテリジェンスとの一致などを重点確認し、証拠が欠ける領域を明示します。高リスク案件では、契約上許可された範囲で独立専門家による侵害評価を検討します。

侵害が交渉中に判明した場合は、通常の案件情報ルートだけで処理しません。対象会社のインシデント指揮系統を起動し、封じ込め、証拠保全、法令・契約通知を優先します。買い手は必要な情報を受けつつ、対象会社のネットワークへ無秩序に接続せず、弁護士、保険者、専門会社との役割を整理します。取引判断では、原因・範囲・残存アクセス・是正可能性・開示義務・顧客影響を更新します。

個人データを委託している場合、報告対象事態では原則として委託元と委託先の双方が報告義務を負い、委託先が委託元へ所定の通知をした場合には委託先が報告義務を免れる仕組みがあります。DDでは「ベンダーが報告すると思っていた」という思い込みを排し、契約と実際の連絡網で主体を確定します。

2025年10月1日以降、ランサムウェア事案について政府関係機関への報告負担を軽減する共通様式が利用可能とされています。ただし、共通様式の存在が、各法令・業法・契約の報告要否を自動的に統一するわけではありません。対象業種の報告先と手続は案件時点の公式情報で確認します。

8．バックアップ・復旧・事業継続は「取っている」から「戻せる」へ

バックアップのDDでは、成功表示ではなく、必要な業務を必要な時点へ戻せるかを確認します。対象データ、頻度、保持、暗号化、監視、失敗通知、管理者、保存場所、削除権限を整理し、本番と同じ資格情報や同じ障害で同時に失われないかを見ます。ランサムウェアを想定するなら、攻撃者が本番管理者を奪った後も消去・暗号化しにくい隔離または不変性が重要です。

「復旧テスト済み」という回答には、対象、日時、手順、所要時間、データ整合性、業務確認、失敗と改善を求めます。小さなファイル一個の復元と、認証・DB・アプリ・外部連携を含むサービス全体の復旧は別物です。復旧後に注文、請求、在庫、監査ログが整合するかを業務部門が確認しているかも見ます。

RTOとRPOは、業界共通の数字を当てはめるものではありません。停止によりいつ、どの顧客・業務・安全へ影響が出るかを事業影響分析で決め、その要求を構成と契約が満たせるかを検証します。「可能な限り早く」では合否を判断できないため、システムごとに承認された時間・データ損失許容値と、その根拠を記録します。

復旧能力の確認順序

• 重要業務と依存サービスを順位付けし、復旧順序が合意されているか。
• ID、DNS、鍵、仮想基盤など、他の復旧に先立つ基盤もバックアップされているか。
• バックアップの管理者、復旧手順、連絡先が本番環境の侵害時にも利用できるか。
• 復旧に必要なライセンス、保守会社、予備機、回線、施設、担当者を確保できるか。
• 復旧データにマルウェアや不正アカウントを戻さない検証工程があるか。
• 手作業の代替、顧客連絡、受注制限、決済・出荷の照合が手順化されているか。
• テストで判明した問題が、期限と責任者をもって改善されているか。

BCPとインシデント対応計画は接続している必要があります。技術チームがサーバを復旧しても、法務の通知判断、広報の説明、営業の顧客対応、財務の不正送金防止、経営の操業判断が連動しなければ損失は拡大します。机上演習の記録から、役員を含む意思決定、夜間休日、連絡不能、委託先停止、同時多発を想定しているかを確認します。

買収案件では、譲渡企業様親会社が提供していたバックアップやSOCがクロージングで使えなくなることがあります。TSAの有無、監視継続、ログ引渡し、バックアップの所有、復旧支援、終了条件を確認し、移行完了前にサービスが途切れないようにします。TSA終了予定日だけでなく、終了判定に必要なテストと証拠を定めます。

9．証拠の確かさと、安全な検証の進め方

DDの回答は、主張、文書、運用記録、設定、独立検証の順に確からしさを高めます。ただし、設定画面一枚が常に最上位とは限りません。撮影日時、対象テナント、フィルター、権限、全体を代表するかが不明なら、解釈を誤ります。証拠には出所、基準日、対象範囲、取得方法、保管先を付け、重要結論を再現可能にします。

証拠レベルの実務的な使い分け

サンプル検査では、無作為抽出だけでなくリスクベース抽出を併用します。退職者、管理者、長期未使用、例外承認、海外拠点、委託先、重大システムを意図的に含めます。どの母集団から何件をどう選んだかを記録し、サンプル結果を全体へ一般化できる限界を報告します。

証拠を出せない理由も評価対象です。顧客秘密や弁護士秘匿のため本文を見せられない場合、要約、条項一覧、外部弁護士による確認、クリーンチーム閲覧などの代替があります。ログが設計上保存されていない場合は代替証拠では侵害不存在を証明できないため、「未確認」という残余リスクを契約・Day1へ送ります。

検証は対象会社の事業を危険にさらさないようにします。侵入テスト、フィッシング訓練、パスワード監査、脆弱性スキャン、バックアップ復元は、停止、アカウントロック、監視アラート、データ生成を伴い得ます。実施権限、対象、禁止行為、時間、停止条件、緊急連絡、生成データの処理を文書化し、本番への影響が高い場合は安全な代替を選びます。

報告には確信度を付けると、経営者が不確実性を理解しやすくなります。たとえば「高確信」は複数の独立証拠が一致、「中確信」は限定的証拠または一部未確認、「低確信」は主に説明に依存、と定義します。これはリスクの重大度とは別軸です。重大度が低くても確信度が低い事項と、重大度が高く証拠が強い事項を混ぜません。

10．経営判断に必要な成果物は「診断書」ではなく意思決定パッケージ

良いDD報告は、技術用語を大量に並べた検査成績書ではありません。取締役会、投資委員会、交渉担当、統合責任者が、同じ事実からそれぞれ必要な判断を下せる形にした意思決定パッケージです。最低限、エグゼクティブサマリー、事実認定表、リスクシナリオ、未取得資料一覧、契約反映案、Day1制約、PMI施策、費用見積りの前提を一体化します。

発見事項は「脆弱性あり」では足りません。「インターネット公開された旧式VPN装置が保守期限を過ぎ、特権アカウントに多要素認証がなく、その認証基盤から基幹ファイルサーバへ到達可能。更新機器は未発注で、侵害有無を判断できるログは保存されていない」のように、資産、脅威、統制欠陥、到達経路、証拠限界、事業影響を一文脈で示します。そのうえで、クロージング前の交換、Day1の遮断、価格への織込みなど、選択肢を提示します。

リスクの結論は、原則として四つに分けると交渉へ接続しやすくなります。第一は受容可能で通常運用へ引き継ぐもの、第二は買収後に予算化して改善するもの、第三は契約で譲渡企業様の是正や責任分担を求めるもの、第四は取引条件を根本から見直すものです。「高・中・低」だけでは、誰がいつ何をするかが決まりません。

成果物に必ず残す7項目

1. 確認された事実：資料名、対象範囲、基準日、確認者を含め、再検証できる記録にする。
2. 譲渡企業様の説明：口頭説明は事実認定と混ぜず、誰がいつ述べたかを明記する。
3. 分析・推論：証拠から導いた評価であることを明示し、反証となり得る情報も示す。
4. 不確実性：ログ欠落、対象外子会社、検査未実施、資料更新日の古さを隠さない。
5. 事業影響：停止業務、影響データ、顧客・当局対応、代替手段、復旧依存先を記す。
6. 取引上の処置：価格、前提条件、誓約、表明保証、補償、保険、留保の候補を整理する。
7. 実行責任：クロージング前、Day1、PMIの期限、責任者、完了証拠を定める。

この形式にすると、セキュリティ上の弱点が直ちにディール中止を意味しないことも明確になります。改善可能で費用と期間を合理的に見積もれる問題なら、取引価格やPMI計画で扱えます。一方、侵害の継続可能性、主要顧客への重大な契約違反、復旧不能な中核サービス、営業秘密の成立を損なう管理実態などは、企業価値そのものへ影響し得ます。

11．いつ、誰が、どう進めるか

サイバーセキュリティDDは、意向表明後に一度だけ質問票を送って終える作業ではありません。案件初期の仮説形成、秘密保持契約とVDRの設計、限定資料による一次評価、経営者・実務者インタビュー、証拠検証、契約交渉、クロージング確認、PMI引継ぎという連続工程です。案件の競争性や開示制約が強いほど、初期は重要論点に絞り、独占交渉後に深掘りする段階設計が必要です。

開始時には、買い手側の案件責任者、CISOまたはセキュリティ責任者、IT責任者、法務、プライバシー担当、財務・保険、事業部門、PMI責任者の役割を決めます。譲渡企業側も、経営責任者、IT運用、法務、人事、営業・プロダクト、委託先窓口をそろえます。全員を全会議へ招くのではなく、論点ごとに回答責任者と承認者を一名ずつ定め、窓口の混乱を避けます。

専門家の独立性も重要です。対象会社の運用を長年担うベンダーは、構成を最もよく知る一方、自らの運用不備を評価する立場にもなります。既存ベンダーの知見を排除する必要はありませんが、重要な検証については買い手側または独立した専門家が証拠を確認し、評価根拠を保存する方が適切です。

段階別の標準ワークフロー

中小M&Aでは人員も時間も限られます。それでも調査の質を落とす必要はありません。全統制を均等に調べるのではなく、売上停止、個人データ漏えい、主要顧客喪失、知的財産流出、買い手環境への侵害波及という重大シナリオから逆算します。IPAの「中小企業の情報セキュリティ対策ガイドライン 第4.0版」には、経営者編、実践編に加え、資産管理台帳、クラウド安全利用、インシデント対応などの付録があり、譲渡企業様の準備と買い手のベースライン確認に利用できます。

M&A支援者の行動規範や利益相反管理も、情報管理の前提です。当センターが掲げる手続と姿勢については、中小M&Aガイドライン遵守のご案内もあわせてご確認ください。

12．調査範囲は「法人一覧」ではなく事業価値の流れから決める

調査対象を対象法人の本社ネットワークだけに限定すると、重要な抜けが生まれます。連結子会社、海外拠点、個人事業主への外注、共同開発先、販売代理店、物流、決済、コールセンター、クラウド管理会社、元従業員が管理するドメインなど、事業価値とデータが通る場所を境界に含めます。株式譲渡なら法人に紐づく資産・契約・責任を広く引き受けやすく、事業譲渡なら移転対象を選べる反面、契約承継、アカウント移管、データ分離が難しくなります。

最初に「守る対象」と「失敗シナリオ」を定義します。守る対象には、売上を生むサービス、製造・配送能力、顧客と従業員の情報、認証情報、ソースコード、アルゴリズム、設計図、価格表、取引先条件、ブランド、許認可を支える記録などが含まれます。失敗シナリオは、ランサムウェアで受注停止、クラウド管理者奪取、秘密情報持出し、顧客データ流出、OT停止、ソースコード改ざん、バックアップ破壊、買い手ネットワークへの横展開といった形で具体化します。

次に、各シナリオの成立条件を質問へ分解します。たとえばクラウド管理者奪取なら、管理者IDの数、個人アカウントか共有か、多要素認証、条件付きアクセス、緊急用アカウント、特権操作ログ、アラート、復旧用連絡先、ドメインとDNSの管理、退職者処理を確認します。これにより、一般論の質問票から案件固有の検証へ変わります。

スコープメモに明記する事項

• 対象法人、事業、拠点、子会社、共同運営組織、カーブアウト対象
• 対象システム、クラウドアカウント、SaaS、ドメイン、モバイルアプリ、OT・IoT
• 対象データの種類、本人区分、重要秘密、保存国、処理委託先
• 調査基準日と、過去事象を確認する対象期間
• 許可された検証方法と、実施してはならないテスト
• 譲渡企業様が開示を留保する事項と、その代替証拠
• 重要性基準、評価尺度、リスク受容権限、エスカレーション先

調査対象期間は「過去数年」のように曖昧にせず、案件ごとに開始日と終了日を記載します。その設定理由も、法定保存期間、顧客契約の監査対象期間、システム更改日、現経営陣の就任日、既知事故の発生日などと結び付けます。期間外の重大事故が判明した場合に追加調査できる留保も置きます。

対象外事項も明記します。たとえばソースコードレビュー、侵入テスト、端末フォレンジック、海外法評価、OT安全性検証を実施していないなら、その事実を結論の近くに書きます。調査していない領域を、問題が見つからなかった領域と混同させないためです。

13．譲渡企業様と買い手、それぞれの実務

譲渡企業様：弱点を隠すより、管理可能性を示す

譲渡企業様にとってサイバーDDは、満点のセキュリティを演出する場ではありません。現状、既知の例外、暫定統制、改善計画を一貫した証拠で説明し、買い手が不確実性へ過大な価格を付けないようにする場です。未整備事項を直前に作った規程で覆うと、運用記録との矛盾が増え、組織的な説明の信頼性を損ないます。

まず、資産台帳、データマップ、SaaS一覧、委託先一覧、インシデント一覧、保険、主要顧客のセキュリティ条項、規程、監査・診断結果を同じ基準日でそろえます。資料ごとに対象範囲、所有部門、最終更新日、例外を付けます。発見済みの脆弱性には、対応済み、受容、代替統制、期限付き改善、未評価の区分を付け、単なる未完了一覧にしません。

開示は段階化します。一次段階では集計値や匿名化した構成図を示し、買い手が限定された後に契約・設定の詳細へ進みます。顧客名、個人名、認証情報、ネットワークの攻撃に利用できる詳細、未公表インシデントは、クリーンチーム、閲覧のみ、透かし、ダウンロード禁止、操作ログなどを組み合わせます。ただし、技術的に閲覧を制限しても、法的な利用目的と取扱条件を定める契約の代わりにはなりません。

譲渡企業様は回答窓口を一本化しながら、実際の運用担当者へのインタビューを妨げないことも大切です。経営側の「問題はない」と、担当者の「監視対象外でログがない」が並存する場合、買い手は後者を重く見ます。回答を修正したときは旧回答を消すのではなく、変更理由と根拠資料を追記すると、誠実な開示として評価しやすくなります。

買い手：チェック項目の充足率より、引受け後の制御可能性を見る

買い手は、対象会社を自社基準との単純な差分だけで評価しないよう注意します。大企業の統制をそのまま中小企業へ当てはめれば差分は大量に出ますが、案件の重要リスクが埋もれます。対象会社の事業、規模、脅威、顧客への約束に照らし、どの差分が損失シナリオを成立させるかを見極めます。

同時に、「買収後に自社基盤へ載せ替えるから問題ない」という楽観も避けます。移行完了まで既存環境は動き続け、汚染された端末やIDを接続すれば買い手側へ影響が広がります。ライセンス、データ形式、API制限、契約同意、鍵の所有者、担当者の離職などにより、想定より移行が遅れることもあります。DDでは現状リスクと移行リスクを別々に評価します。

質問への回答が「外部ベンダーに任せている」で止まった場合、管理が存在するとは判断しません。責任分界、委託契約、月次報告、アラートの送付先、承認履歴、復旧テスト、再委託先を確認します。外注は作業主体を変えるだけで、対象会社の経営責任や買い手の引受けリスクを消しません。

買い手候補として案件情報の提供を受ける際は、希望条件だけでなく、対象会社を安全に受け入れられるIT・セキュリティ体制も早期に整理しておくと、Day1設計が進めやすくなります。

14．データマッピング：DDの背骨を作る

データマッピングは、ファイルサーバのフォルダ一覧を作る作業ではありません。データの発生から取得、入力、利用、加工、共有、保管、バックアップ、アーカイブ、消去までを、本人・顧客・委託先・システム・場所・法的根拠・責任者と結び付ける作業です。この地図がなければ、個人情報保護、委託先監督、クラウド移行、事故影響範囲、カーブアウトのいずれも正確に判断できません。

最初から全項目を完璧に埋める必要はありません。売上・サービス継続を左右するデータと、漏えい時の権利利益侵害が大きいデータから始めます。顧客マスタ、注文・決済、従業員・採用、健康情報、問い合わせ、行動ログ、位置情報、映像、研究開発、設計、ソースコード、認証情報、契約・会計記録などをデータ群として定義し、各群に同じ識別子を付けます。

データマップの必須列

台帳と現実の差を見つけるには、トップダウンとボトムアップを併用します。トップダウンでは業務ヒアリング、処理記録、プライバシーポリシー、顧客契約からデータ群を洗います。ボトムアップではSSOのアプリ一覧、経費精算、ブラウザ拡張、DNS、クラウド請求、APIキー管理、EDR端末、バックアップジョブ、メール転送設定などから、台帳にない実利用を探します。

不一致は直ちに違法や侵害を意味しませんが、統制の信頼度を下げます。たとえば「個人データは国内のみ」と回答しながら、海外リージョンのバックアップや海外サポートからのアクセスが見つかった場合、契約、本人向け公表、安全管理措置、外国制度の把握を再確認する必要があります。データマップには物理的な保存場所だけでなく、運用担当者がアクセスする国・地域も記録します。

カーブアウト案件では、データの混在が最大の難所になります。譲渡対象事業と残存事業の顧客が同じDBに入り、共通IDや共通マスタを参照している場合、単純コピーでは過剰移転が起きます。抽出条件、照合方法、例外処理、削除、移行後のアクセス停止、バックアップ内の残存、TSA期間中の責任分界をデータ群ごとに決めます。

完成したデータマップは一度きりのDD資料ではありません。Day1の接続可否、本人問い合わせ、事故時の影響範囲、SaaS解約、システム移行、保存期間統一にそのまま使えます。したがって、PDFの図だけでなく、フィルター可能な表形式でも引き渡し、項目定義と更新責任を添えるのが実務的です。

15．個人情報保護とVDR：開示できることと、無制限に見せてよいことは別

日本の個人情報保護法では、合併、分社化、事業譲渡などの事業承継に伴う個人データの提供について、一定の要件の下で提供先を第三者に該当しないものとして扱います。個人情報保護委員会の通則ガイドラインは、事業承継の契約締結前の交渉段階で相手会社が調査するための提供もこの枠組みに含み得ると説明しています。ただし、利用目的と取扱方法、漏えい等が生じた場合の措置、交渉不成立時の措置など、安全管理措置を相手会社に守らせるために必要な契約を締結しなければならないとしています。

したがって、「M&Aだから本人同意なしで何でもVDRへ置ける」という理解は誤りです。まず、取引の検討に必要か、集計・仮名化・マスキングで目的を達成できないか、閲覧者を限定できるか、保存と消去を管理できるかを検討します。給与明細、健康診断、通報記録、本人確認書類、口座・カード情報、認証情報などは、必要性と開示時期を特に厳しく判断します。

秘密保持契約には一般的な守秘義務だけでなく、サイバーDDのデータ処理条件を具体化します。目的外利用の禁止、閲覧可能者、再提供・再委託、端末と保存先、ダウンロード・印刷、技術的安全管理、事故時の連絡、調査協力、法令開示、交渉終了時の返却・消去、バックアップ残存、消去証明、差止め、監査可能性などです。買い手側のアドバイザー、金融機関、保険会社が閲覧するなら、その範囲も定義します。

VDRの安全設計

• 最小開示：氏名や連絡先が不要なら削除し、顧客別明細が必要でも識別子を置換する。
• 段階的アクセス：案件関係者全員、限定チーム、外部専門家のみという区画を分ける。
• 本人単位の認証：共有IDを避け、多要素認証、期限、IPや端末条件をリスクに応じて設定する。
• 操作記録：閲覧、ダウンロード、削除、権限変更を記録し、異常な一括取得を検知できるようにする。
• 文書制御：透かし、ダウンロード禁止、印刷制限は補助策とし、画面撮影などの残余リスクを前提にする。
• 定期棚卸し：候補者の離脱、担当変更、案件終了時に権限を即時見直す。
• 出口管理：交渉不成立または取引完了時の消去対象、法的保存、バックアップからの消去時期を合意する。

要配慮個人情報を含む人事資料は、開示の必要性、取得時の利用目的、アクセス者を個別に確認します。経営チームの継続性を評価するために、全従業員の病歴や健康診断結果を渡す必要は通常ありません。役職、在籍、スキル、報酬帯などを集計・匿名化し、個別情報は人事・法務のクリーンチームに限定するなど、目的に比例した方法を選びます。

個人データの取扱いを委託している場合、個人情報保護委員会の通則ガイドラインは、適切な委託先の選定、必要な安全管理措置を含む委託契約、取扱状況の把握を示しています。再委託についても、相手、業務内容、取扱方法の事前報告または承認、監査などによる確認が望ましいとされています。DDでは契約条項の存在だけでなく、直近の評価、是正要求、再委託先一覧、事故連絡の実績を確認します。

海外クラウドや海外拠点が関わるときは、サーバ所在地だけで結論を出しません。外国にある事業者への委託、海外サポートのアクセス、再委託、バックアップ先、災害復旧リージョンをデータフローで確認し、外国にある第三者への提供、相当措置、本人への情報提供、外的環境の把握などの該当性を個別に検討します。クラウド事業者がデータを取り扱うか否かという契約・実態も重要です。

事故履歴では、報告対象事態かどうかを当時の結論だけで受け入れず、元資料で再評価します。通則ガイドラインが示す報告対象には、要配慮個人情報を含む個人データ、不正利用により財産的被害のおそれがある個人データ、不正目的の行為による個人データ、本人が1,000人を超える個人データの漏えい等またはそのおそれがあります。サイバー攻撃では確証がなくても「おそれ」が問題になるため、ログ不足を「漏えいなし」と読み替えないことが重要です。

報告対象事態を知った後の速報は「速やか」に行い、その目安は個別事情によるものの概ね3～5日以内とされています。確報は原則として知った日から30日以内、不正目的の行為による事態は60日以内です。これらはDDの独自基準ではなく、個人情報保護委員会のガイドラインに示された法令上の報告実務です。買収契約の事故通知期限は、当局期限に間に合うよう、さらに短く設計する必要があります。

なお、プライバシーポリシーは公開文書であっても、実態との一致を確認する対象です。当センター自身の情報の取扱いについては、情報セキュリティ方針をご覧いただけます。

16．ガバナンス・人・アクセス権：規程より「誰が止められるか」を見る

ガバナンスの確認では、情報セキュリティ方針の有無だけでなく、経営がリスクを知り、優先順位と予算を決め、例外を承認し、改善を追跡する仕組みを見ます。取締役会・経営会議への報告資料、リスク台帳、内部監査、予算、重大インシデントのエスカレーション、責任分界、未完了課題の滞留を確認すると、規程と実態の距離が分かります。

CISOという肩書がなくても、役割が明確で実効的なら直ちに問題ではありません。反対に、CISOが置かれていても兼務範囲が広すぎ、資産を把握できず、システム停止やアカウント無効化を指示する権限がなければ、重大時に機能しません。担当者、意思決定者、経営への報告先、代行者、外部専門家への連絡権限をRACIなどで確認します。

人員面では、重要業務が特定個人に依存していないかを調べます。クラウドのルートアカウント、ドメイン登録、コード署名鍵、バックアップ暗号鍵、ベンダーとの個人的関係、スクリプトの知識が一人に集中すると、その人の離職が事業継続リスクになります。キーパーソン条項だけに頼らず、共有可能な手順、複数管理者、緊急アクセス、秘密情報の適切な移管を設計します。

アイデンティティとアクセス管理の確認ポイント

• 人事マスタとID発行・変更・削除が連動し、退職・休職・異動が期限内に反映されるか。
• 共有アカウント、サービスアカウント、緊急用アカウントの所有者と利用記録があるか。
• 特権管理者、メール、VPN、クラウド管理、コード管理に多要素認証が適用されているか。
• 多要素認証の方式がフィッシング耐性を持つか、復旧手段が迂回路になっていないか。
• 定期アクセスレビューが帳票上の確認で終わらず、不要権限の削除まで追跡されているか。
• 外部委託者、派遣、販売代理店、開発者の期限付きアクセスを誰が承認しているか。
• APIキー、証明書、トークン、SSH鍵など、人以外の認証情報を棚卸し・更新しているか。
• 買収後に譲渡企業様親会社や旧オーナーがアクセスを保持するシステムを特定しているか。

教育では受講率だけでなく、対象と内容を見ます。一般従業員向けのフィッシング訓練、管理者向けの特権運用、開発者向けのセキュア開発、経営者向けの危機判断、広報・法務向けの事故対応は目的が異なります。業務委託者や短期雇用者を対象外にしていないか、未受講者に権限を付けたままになっていないかも確認します。

内部不正は、悪意だけを想定しません。大量ダウンロード、個人メールへの転送、私物クラウド、退職前の持出し、権限の付け過ぎ、誤送信が起きても検知・追跡できるかを見ます。営業秘密については、経済産業省の営業秘密管理指針が示す有用性、秘密管理性、非公知性という要件を踏まえ、秘密であることが従業員に認識可能な管理になっているかを法務と共同で確認します。

買収情報そのものも高度に機密です。案件コード名、インサイダー情報、従業員への通知前の組織案、価格、顧客離反リスクは、通常業務の共有フォルダへ置かないようにします。案件メンバーの追加・削除、外部アドバイザーの端末、メール誤送信対策、会議録の保存場所、生成AIサービスへの入力禁止または条件を、案件開始時に決めます。

17．サイバーリスクを経営判断と金額へ翻訳する

リスク評価は、脅威の派手さではなく「どの事業価値が、どの経路で、どの程度損なわれ得るか」を中心にします。NIST Cybersecurity Framework 2.0のGovern、Identify、Protect、Detect、Respond、Recoverという機能は、調査結果の整理に使える共通言語です。ただし、フレームワークは特定の対策方法やM&Aの合否を決めるものではないため、対象会社の事業と取引条件に合わせて使います。

シナリオごとに、原因、影響資産、既存統制、発生可能性を左右する要因、最大影響、現実的な影響、検知までの能力、復旧条件を整理します。金額化では、緊急対応、フォレンジック、通知、本人対応、法務、広報、復旧、売上停止、違約、顧客離反、システム刷新、保険免責など、重複しない費用区分を作ります。数字が得られない部分は無理に一点推計せず、前提の異なるシナリオ幅と感応度を示します。

改善費用と事故損失は分けます。買収後に必要なMFA、EDR、ログ、バックアップ、保守更新、人員、診断は投資計画であり、事故が起きた場合の損失ではありません。一方、既に発生した事故の未払対応費、顧客補償、当局対応、契約違反は潜在債務として別に扱います。さらに、買い手標準へ統合するための費用は、対象会社固有の不備是正と区別しなければ交渉が不公平になります。

各見積りには、数量、単価、期間、対象範囲、内製・外注、停止条件、依存施策、予備費の根拠を付けます。「セキュリティ強化一式」の概算では、価格調整にもPMI予算にも使えません。ベンダー見積りが間に合わない場合は、比較可能な施策単位に分け、どの前提が未確認かを示します。

M&A サイバーセキュリティDDの最終的なリスク受容は、セキュリティ担当だけで決めません。事業価値、取引価格、統合戦略、法令・契約責任、顧客関係を理解する権限者が承認します。受容したリスクには、見直し日、トリガー、監視指標、所有者を設定し、「DDで把握済み」という理由で永久に放置しないようにします。

18．取引構造、表明保証、誓約、補償へ落とし込む

サイバーDDの結果は、取引契約の一条項だけで処理できません。株式譲渡か事業譲渡か、支配権取得か少数出資か、カーブアウトかによって、引き受ける法人責任、移転資産、契約同意、データ分離、TSAが変わります。まず取引構造図に、システム、契約、データ、知的財産、担当者がどの主体へ残るかを重ねます。

表明保証は、対象会社が法令を順守しているという抽象表現だけでは、発見事項との関係が曖昧です。適用法令と顧客契約、情報セキュリティ・プライバシー方針、重要インシデント、当局・顧客への通知、訴え・調査、個人データの取得・利用・提供、委託先監督、重要システムの管理権限、既知の不正アクセス、開示済み診断結果など、案件固有の重要事項へ分解します。

文言には、重要性、譲渡企業様の認識、対象期間、対象会社・子会社、開示資料との関係が影響します。「譲渡企業様の知る限り問題がない」とする場合、誰の知識を対象にし、合理的な調査を含むかを交渉します。表明保証を広くすれば技術リスクが消えるわけではないため、補償上限、請求期間、免責、保険、譲渡企業様の資力とあわせて実効性を見ます。

契約へ送る主な手段

既知の弱点は開示別紙と是正計画を対応付けます。単に監査報告書をVDRへ置くだけで開示が成立するかは契約文言によるため、重要事項がどの表明保証の例外かを明確にします。買い手も、資料の大量投入を理由に全リスクを認識したとみなされないよう、開示基準と質問回答の優先関係を確認します。

署名後の誓約には、重大なセキュリティ変更を無断で行わないこと、既存統制・保険・ログを維持すること、新たな事故・脆弱性・当局照会・顧客クレームを通知すること、買い手の合理的な追加確認へ協力することなどが考えられます。事業運営を不当に拘束しないよう、通常業務の範囲、緊急対応、承認手続を設計します。

表明保証保険を利用する場合も、既知事項や不十分なDDが当然に補償されるとは限りません。保険者の質問、除外、サイバー保険との重複、事故発生日と請求原因、通知義務を確認します。保険は調査の代替ではなく、契約上残る一部リスクの資金手当てです。

19．クロージングとDay1：接続する前に支配権を確保する

クロージングチェックでは、是正項目の完了、署名後の新規事故、重要契約同意、管理アカウント、ドメイン、クラウド請求、暗号鍵、コード、バックアップ、ベンダー連絡先の移管を確認します。資料を受け取ることと、対象会社が自力で管理できることは別です。旧株主の個人メールへパスワード再設定が届く状態や、保守会社だけが最高権限を持つ状態を残しません。

Day1の原則は、業務継続に必要な最小限の連携、信頼する前の検証、監視可能な接続です。買い手のディレクトリへ全利用者を即時移行したり、ネットワークを双方向接続したりすると、対象会社側に潜む侵害が買い手へ広がる可能性があります。メール共存、ファイル共有、財務報告などの必要機能ごとに、安全な暫定経路を設けます。

Day1レディネス確認

• 緊急連絡網、事故判断者、買い手・譲渡企業様・TSA提供者の役割が周知されている。
• 重要な特権IDを本人単位で再発行し、多要素認証と監視を有効にしている。
• 旧オーナー、離脱ベンダー、案件アドバイザーの不要アクセスを停止している。
• 接続経路、許可通信、監視、遮断責任、ロールバック条件を承認している。
• EDR・ログなど可視性の空白を把握し、接続前の補完策を実施している。
• バックアップの成功と重要サービスの復元手順を確認している。
• 顧客・委託先への必要通知、同意、契約切替えを完了または管理している。
• 従業員向けに、フィッシング、送金先変更、情報共有先の注意を案内している。

M&A公表直後は、攻撃者が役員名や組織変更を悪用しやすい時期です。緊急送金、パスワード再設定、請求先変更、共有リンクを装う連絡を想定し、財務・人事・経営秘書・ヘルプデスクへ確認手順を伝えます。正規の統合案内が何から届くかを従業員へ明示することも、なりすまし対策になります。

20．PMI100日：DD発見事項を消し込む実行計画

以下の100日は法定期限ではなく、統合初期を管理するための実務モデルです。案件規模、規制、侵害状況、カーブアウト難易度に応じて前倒し・延長します。重要なのは日数そのものではなく、各施策に所有者、依存関係、完了条件、残余リスクを持たせることです。

統合方式は、完全統合、独立維持、段階統合のどれかをシステムごとに選びます。ブランドや開発速度を守るため独立性を残す場合でも、事故連絡、最低統制、リスク報告、監査、バックアップなどグループ共通のガードレールは必要です。すべてを買い手標準へ置換することが、常に最小リスクとは限りません。

DDチームからPMIチームへの引継ぎは会議だけで終えず、発見事項IDを維持します。元証拠、評価、契約条項、担当、期限、費用、完了基準を同じ台帳で追い、変更時には理由を記録します。契約交渉で約束した是正が、運用チケットへ正しく変換されたかを法務とセキュリティが共同確認します。

100日目には、施策数ではなくリスク削減を経営へ報告します。未知資産が減ったか、特権アクセスを説明できるか、重大アラートを受けて行動できるか、重要サービスを復元できるか、委託先事故を期限内に把握できるかを証拠で示します。未完了は隠さず、受容・継続改善・追加投資の判断へ戻します。

21．取引判断を止めて再評価すべきレッドフラッグ

次の兆候は直ちに取引中止を意味しませんが、通常のPMI課題として先送りせず、追加調査と経営判断が必要です。

• 重要資産、クラウド、ドメイン、管理者の所有関係を説明できず、台帳との差が大きい。
• 侵害の兆候があるのにログが削除され、証拠保全よりシステム初期化を優先している。
• 公表・当局報告・顧客通知の要否判断が記録されず、契約上の通知漏れが疑われる。
• 主要顧客へ約束した統制と実装が明確に異なり、例外合意もない。
• 全バックアップが本番管理者で削除可能で、復元テストの証拠がない。
• 旧オーナー、退職者、外注者がクラウド・コード・ドメインの最高権限を保持する。
• 営業秘密と主張する中核情報が無区分で共有され、持出しを追跡できない。
• 対象事業データを残存事業から分離できず、移転範囲と削除方法を定義できない。
• 重要SaaSや保守契約が支配権変更で終了し、代替または同意の見通しがない。
• 譲渡企業様の回答、設定、ログ、契約の矛盾が繰り返され、修正理由も説明されない。

レッドフラッグへの対応は、事実保全、影響範囲、短期封じ込め、取引への影響の順で進めます。原因を断定できない段階で責任追及を先行させると、担当者が情報を出しにくくなります。経営者には、確認事実、未確認、最悪シナリオ、可逆的な対策、判断期限を分けて報告します。

22．M&A サイバーセキュリティDD実務チェックリスト

買い手側チェックリスト

• □ 取引構造、対象法人、カーブアウト、TSAを含む調査境界を文書化した。
• □ 重大な事業停止・漏えい・知財流出・横展開のシナリオを先に定義した。
• □ 資産、データ、SaaS、委託先、事故の各台帳を相互照合した。
• □ 個人データ開示の必要性とVDRの契約・権限制御を確認した。
• □ 重要顧客契約のセキュリティ約束を実装証拠と比較した。
• □ 特権ID、退職者、外注者、サービスアカウントをサンプル検証した。
• □ 外部公開面、保守切れ、重大脆弱性を攻撃経路で評価した。
• □ クラウド・SaaSの契約主体、移管、ログ、データ出口を確認した。
• □ 過去事故を複数の記録から再構成し、未完了是正を特定した。
• □ バックアップ復元の実績と、侵害時にも使える管理経路を確認した。
• □ 未確認事項を「問題なし」とせず、確信度と残余リスクを付けた。
• □ 発見事項を価格、契約、前提条件、Day1、PMIのどこで扱うか決めた。
• □ 接続判定、遮断権限、緊急連絡、監視をDay1計画へ入れた。
• □ 是正費用、統合費用、既知事故債務を分けて見積もった。
• □ 最終リスク受容者と、受容後の見直し条件を記録した。

譲渡企業側チェックリスト

• □ 各資料に対象範囲、所有者、基準日、例外を記載した。
• □ 規程を直前に作るのではなく、実際の運用と未整備事項を整理した。
• □ 既知の脆弱性・事故・顧客指摘を一つの課題台帳へ集約した。
• □ 顧客・従業員の個人情報を必要最小限に加工して開示した。
• □ クリーンチーム、閲覧制限、操作ログ、終了時消去を設定した。
• □ 主要委託先と再委託先の契約、評価、事故連絡先をそろえた。
• □ 口頭回答の担当者と根拠を残し、訂正時は変更理由を記録した。
• □ 早期に是正できる外部公開、退職者ID、共有管理者を処理した。
• □ 修正できない事項には暫定統制、期限、費用、責任者を付けた。
• □ 旧オーナー個人名義のドメイン、クラウド、コード、鍵を洗い出した。
• □ 支配権変更・契約譲渡で同意が必要な重要サービスを特定した。
• □ カーブアウトの抽出、照合、残存データ削除、TSAを設計した。
• □ 署名後に新たな事故・指摘が出た場合の更新開示手順を決めた。
• □ クロージングで渡すアカウント、記録、連絡先、手順を一覧化した。
• □ 経営者が残余リスクと買い手への説明内容を承認した。

会社譲渡を検討する譲渡企業様の方は、資料準備の初期段階からサイバーセキュリティ上の論点を整理しておくと、開示の一貫性を保ちやすくなります。

23．ケースで考える：発見事項をどう判断へ変えるか

ケースA：古いVPN装置が残る製造会社

事実：保守終了したVPN装置が工場ネットワークの入口にあり、多要素認証がなく、装置ログは短期間で上書きされます。設備停止の都合で交換日はクロージング後です。分析：単なる更新費ではなく、侵害有無を十分確認できず、ITからOTへの経路もある不確実性が問題です。処置例：署名前に外部公開を必要送信元へ限定し、認証を補強し、Day1は買い手との接続を分離します。交換を期限付き誓約とPMI最優先施策にし、完了証拠を再検査で定義します。

ケースB：SaaS企業の顧客データと契約が食い違う

事実：顧客契約は国内保存を約束しますが、障害解析で海外サポートがデータへアクセスでき、再委託先一覧は更新されていません。過去の事故は確認されていません。分析：「漏えいなし」でも、継続的な契約不整合と個人情報の外的環境確認が論点です。処置例：実際のデータフロー、アクセス制御、契約別顧客を確定し、必要な顧客同意・契約修正・設定変更を評価します。表明保証の開示例外と是正費用を一致させます。

ケースC：インシデントはゼロだがログもない

事実：対象会社は事故ゼロと回答しますが、メールとクラウドの監査ログが無効で、EDR対象外端末があります。分析：事故がなかった事実ではなく、検知・立証能力がない状態です。処置例：侵害不存在を断定せず確信度を低くし、公開面と特権アクセスを追加確認します。Day1前にログとEDRを有効化し、一定の観測期間と接続条件を案件責任者が承認します。

ケースD：小規模でも説明可能な譲渡企業様

事実：専任CISOや高額な製品はありませんが、経営者が資産と委託先を把握し、多要素認証、隔離バックアップ、退職者処理、事故連絡、復旧訓練を証拠で示します。例外は台帳で管理されています。分析：形式的な成熟度は高くなくても、重要リスクを制御し改善できる組織です。処置例：買い手基準との差分をPMIへ計画し、対象会社の迅速な意思決定を損なわない統合方式を選びます。

24．M&A サイバーセキュリティDDのよくある質問

M&AのサイバーセキュリティDDは、いつ始めるべきですか？

案件初期にリスク仮説と情報開示ルールを作り、秘密保持契約後に段階的な調査を始めます。深い技術検証を独占交渉後に行う場合でも、個人データ、重大事故、外部公開、重要委託先、Day1接続の論点は契約交渉前に把握できるよう逆算します。

IT DDを実施すれば、サイバーセキュリティDDは不要ですか？

不要にはなりません。IT DDと重なる資産・構成・費用を利用しつつ、攻撃経路、個人情報、委託先監督、事故対応、契約上の通知、侵害の波及、復旧可能性を追加で評価します。両者を別々に発注する場合も、共通の発見事項IDで結論を統合します。

認証やSOC報告書があれば安全と判断できますか？

認証の存在だけでは判断できません。対象組織・サービス・期間、除外、指摘、サブサービス組織、利用企業側が担う統制を確認し、実際の取引対象と重なるかを見ます。認証範囲外の子会社や開発環境が重要資産を扱う場合は追加検証が必要です。

DDのために個人データを買い手へ提供できますか？

個人情報保護委員会の通則ガイドラインは、事業承継の交渉段階の調査に伴う提供も一定の場合に第三者提供の例外へ該当し得るとしていますが、利用目的、取扱方法、漏えい時対応、不成立時の措置などを定め、安全管理措置を守らせる契約が必要です。必要最小限化、マスキング、クリーンチームも検討し、個別案件は専門家へ確認してください。

脆弱性診断や侵入テストは必須ですか？

全案件で同じ試験が必須というわけではありません。外部公開面、事業依存、既存診断の範囲、事故兆候、証拠不足から必要性を決めます。実施する場合は所有者の書面許可を得て、対象、手法、時間、禁止行為、停止条件、緊急連絡を定めます。

問題が多い会社は買収すべきではありませんか？

問題の数だけでは決まりません。重大シナリオ、現在の侵害、法令・顧客契約、是正可能性、必要費用、経営の説明力を評価します。管理可能なら価格、誓約、Day1隔離、PMIで扱えますが、重要事実を確認できない、是正に協力しない、事業価値の前提が崩れる場合は取引条件を再評価します。

表明保証に書けば技術的なリスクは解決しますか？

解決しません。表明保証は事実説明と違反時の救済を設計する手段であり、侵害を止めたりシステムを復旧したりする統制ではありません。既知の重大事項は、短期封じ込め、クロージング条件、補償、価格、Day1制約、PMI施策を組み合わせます。

クロージング当日にネットワークを接続してよいですか？

所有権取得だけを理由に全面接続するのは避けます。資産・ID・侵害兆候・監視を確認し、必要通信、遮断権限、ロールバック条件を承認してから段階接続します。未確認領域が残る場合は分離を維持し、安全なファイル交換や限定APIなどで業務を継続します。

中小企業でも実施できる現実的な方法はありますか？

あります。重大な事業シナリオから優先順位を付け、IPAの中小企業向けガイドライン、資産管理台帳、クラウド安全利用、インシデント対応の付録を活用できます。製品数より、資産を把握し、重要アクセスを守り、事故を連絡し、バックアップから戻せる証拠を重視します。

一次情報・公式資料

以下は本稿の法令・公的ガイドラインに関する記述を確認するために参照した一次情報です。制度やガイドラインは改正されるため、実案件ではリンク先の最新版、施行日、対象業種を確認してください。

• e-Gov法令検索「個人情報の保護に関する法律」（個人情報取扱事業者の義務、第三者提供、事業承継、漏えい等報告の法的根拠）
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」（安全管理、委託先監督、事業承継交渉時の提供、漏えい等報告）
• 個人情報保護委員会「外国にある第三者への提供編」（越境提供、相当措置、外国委託先の監督）
• 個人情報保護委員会「漏えい等の対応とお役立ち資料」（報告フォーム、ランサムウェア事案の共通様式案内）
• 経済産業省「サイバーセキュリティ経営ガイドラインと支援ツール」（経営者の3原則、重要10項目、インシデント・体制資料）
• IPA「中小企業の情報セキュリティ対策ガイドライン」（第4.0版、資産管理・クラウド・インシデント対応の付録）
• IPA「脆弱性対策情報」（JVNおよび脆弱性情報への公式案内）
• 経済産業省「営業秘密～営業秘密を守り活用する～」（営業秘密の3要件、営業秘密管理指針）
• NIST「Cybersecurity Framework 2.0」（サイバーリスクの統治・特定・防御・検知・対応・復旧の体系）
• 国家サイバー統括室「重要インフラ対策関連」（DDoS・ランサムウェア事案の共通報告様式）