セキュリティポリシー統一の進め方 ― M&A後、2社のルールを1つにする実務
M&A後のIT統合で、最初に取り組むべきはセキュリティポリシーの統一です。
2つの会社がそれぞれ異なるセキュリティルールで運用している状態は、組織全体にとって大きなリスクです。片方の会社がMFAを義務化していても、もう片方が対応していなければ、攻撃者はセキュリティの弱い方を狙います。
本記事では、2社のセキュリティポリシーを1つに統一するための具体的なプロセスを解説します。
なぜセキュリティポリシー統一が最優先なのか
IT PMIにはさまざまなタスクがありますが、セキュリティポリシーの統一を最優先すべき理由は3つあります。
リスクは「弱い方」に合わせて発生する。 買収先のセキュリティが自社より弱い場合、その瞬間から自社のリスクも上がります。ネットワークを接続した時点で、脆弱な環境が攻撃の入口になります。
他の統合作業の前提になる。 テナント統合やIdP連携を進める前に、セキュリティの基準が定まっていないと、統合後の設定が場当たり的になります。
経営層・ステークホルダーへの説明責任。 M&A後にセキュリティインシデントが発生した場合、「統合中だったので」は言い訳になりません。
ステップ1：現状調査（両社のポリシー棚卸し）
まず、買収元と買収先のセキュリティ対策の現状を網羅的に把握します。
調査項目チェックリスト
認証・アクセス制御
- パスワードポリシー（文字数、複雑性、有効期限）
- MFA の導入状況（対象ユーザー、認証方式）
- 条件付きアクセスの設定有無
- 特権アカウント管理の方法
- 退職者アカウントの無効化フロー
端末管理
- MDM の導入状況と対象範囲
- ディスク暗号化（BitLocker / FileVault）の展開率
- OS・ソフトウェアのパッチ管理方法
- 個人端末（BYOD）の許可状況とルール
- USB デバイスの利用制限
ネットワーク
- VPN の利用状況と認証方式
- ファイアウォール / UTM の機種と設定概要
- ゲスト Wi-Fi の分離状況
- リモートアクセスのポリシー
データ保護
- ファイル共有の外部公開ルール
- メールの外部送信制限（DLP）
- バックアップの取得状況と世代管理
- 個人情報の取り扱い規程
運用体制
- インシデント対応手順書の有無
- セキュリティ教育の実施状況
- ログの取得・保管期間
- 外部委託先の管理体制
調査方法
- ドキュメントレビュー: 既存のセキュリティポリシー、運用手順書、IT資産台帳
- 管理コンソールの確認: Entra ID / Google Admin / MDM の実際の設定値
- ヒアリング: IT担当者、各部門の管理者への聞き取り
重要なのは「ドキュメント上のルール」と「実際の運用」のギャップを把握することです。ポリシーは整備されていても、現場で守られていないケースは少なくありません。
ステップ2：ギャップ分析
両社の現状を比較し、差異を一覧化します。
分析の観点
各項目について、以下の3パターンに分類します。
A: 買収元の方が強い → 買収先を買収元の水準に引き上げる B: 買収先の方が強い → 買収元も含めて良い方に合わせる C: 両社とも不十分 → この機会に両社とも改善する
ギャップ分析の結果は、経営層への報告資料としても使えるよう、リスクレベル（高/中/低）を付けて整理します。
優先度の判断基準
すべてを同時に対応することは現実的ではないため、リスクの大きさと対応の容易さで優先順位をつけます。
最優先（即座に対応）
- 全ユーザーへのMFA展開
- 退職者アカウントの棚卸し・無効化
- 管理者アカウントの棚卸しと最小権限化
高（1ヶ月以内）
- パスワードポリシーの統一
- 端末暗号化の展開
- ファイル外部共有ルールの統一
中（3ヶ月以内）
- MDMの統一展開
- VPN / リモートアクセスの統一
- セキュリティ教育の実施
低（6ヶ月以内）
- ログ管理・SIEM の統合
- DLP ポリシーの統一
- 監査体制の統合
ステップ3：統一ポリシーの策定
ギャップ分析の結果を踏まえ、統合後の「あるべき姿」を定義します。
ポリシー策定のポイント
「厳しい方」に合わせるのが基本。 セキュリティに関しては、原則として両社のうち厳しい方のルールを採用します。ただし、業務への影響が大きい場合は段階的な移行を検討します。
例外は明文化する。 統合期間中の一時的な例外（例: 買収先のユーザーはMFA展開まで旧VPNの利用を許可）は、期限とともに文書化します。
技術的に強制できる仕組みを優先する。 「ルールを作って周知する」だけでなく、条件付きアクセスやMDMポリシーで技術的に強制する仕組みを併用します。
策定すべきドキュメント
- 統合セキュリティポリシー（全体方針）: 経営層承認のトップドキュメント
- 技術スタンダード: パスワード要件、MFA設定、端末設定の具体的な基準値
- 移行計画: 現状から統一ポリシーに移行するスケジュールと手順
- 例外管理台帳: 統合期間中の一時的な例外とその解消期限
ステップ4：段階的な展開
統一ポリシーは段階的に展開します。一度にすべてを変更すると、業務への影響が大きくユーザーの抵抗も強くなります。
フェーズ1：管理者アカウントの対策（即日〜1週間）
- 両社の管理者アカウントを棚卸し
- 不要な管理者権限を削除
- 全管理者にMFAを必須化
- 共有管理者アカウントの個人化
フェーズ2：全ユーザーへのMFA展開（2〜4週間）
- ユーザーへの事前告知（1週間前）
- 部門ごとにMFAを段階展開
- ヘルプデスク体制を一時強化
- 展開状況のダッシュボード化
フェーズ3：端末ポリシーの統一（1〜3ヶ月）
- MDMの統一展開（Intune / Jamf Pro）
- ディスク暗号化の全端末適用
- OS・ソフトウェアのパッチ管理ポリシー適用
フェーズ4：データ保護・ネットワーク（3〜6ヶ月）
- ファイル共有ルールの統一
- DLPポリシーの適用
- VPN / リモートアクセスの統一
よくある落とし穴と対策
「買収先の社員が反発する」
セキュリティ強化は「管理が厳しくなった」と受け取られがちです。「なぜこのルールが必要なのか」を丁寧に説明し、セキュリティ教育とセットで展開することが重要です。
「設定変更の影響範囲が見えない」
条件付きアクセスやDLPの設定変更は、事前にレポートオンリーモード（監査モード）で影響を確認してから本番適用します。Entra IDの条件付きアクセスには「レポート専用」モードが用意されています。
「例外がいつまでも解消されない」
例外を認める場合は必ず期限を設定し、月次のステアリングコミッティーで進捗を確認します。期限を過ぎた例外は自動的にエスカレーションされる仕組みにします。
まとめ
セキュリティポリシーの統一は、IT PMIの中で最優先のタスクです。現状調査→ギャップ分析→ポリシー策定→段階展開のプロセスで、確実に進めましょう。
「セキュリティは厳しい方に合わせる」を原則としつつ、業務への影響を最小化する段階的なアプローチが成功の鍵です。
次回は、IdP（Entra ID / Okta / Google Workspace）の統合設計パターンを解説します。
まとめ・ご相談
セキュリティ対策の強化をご検討の方は、Security365（セキュリティ運用・SOCライト）をご覧ください。
貴社のIT課題について、まずは60分の無料相談でお気軽にご相談ください。