【クラウド法務】SOCを使っていても、説明責任が軽くならない理由― 「SOCが見てます」は免罪符にならない。事故・監査・取引先照会で問われるのは“証跡と体制” ―

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。

────────────────────────────

はじめに

────────────────────────────

「SOCを入れたので、セキュリティ対応は一段落したはず」

クラウド（Azure / M365）を運用している情シスの現場では、そう感じたくなるタイミングがあります。

実際、SOC（24/7監視、アラート分析、一次切り分け）が入ると、現場の負担は確実に軽くなります。

ところが、監査・親会社統制・取引先の審査・事故対応の局面で、別の意味で“詰まる”ことがあります。

それが「説明責任」です。

・「SOCを使っているなら、ログ提出はすぐできますよね？」

・「誰が最終責任者として判断する体制ですか？」

・「再委託（海外SOC等）はありますか？誰がアクセスできますか？」

・「インシデント通知は何分以内？どの情報を出せますか？」

このとき、よくある誤解が

「SOCがある＝説明責任が軽くなる」 です。

結論から言うと、SOCを使っていても説明責任は軽くなりません。むしろ、整理していないと“重く”なります。理由はシンプルで、SOCは「見張る・分析する」役割であって、あなたの会社の「対外説明の主語」にはなりにくいからです。

本記事では、SOCを使っていても説明責任が軽くならない理由を、技術の整理→法務の地雷→整理フレーム→事例→チェックリストの順でまとめます。

────────────────────────────

技術構成の“事実整理”：SOCが入ると何が増えるのか

────────────────────────────

まず、SOC導入で現場が置かれている構造を、技術の言葉で整理します。

SOCは単体で存在しません。だいたい「ログ基盤（SIEM）＋SOC運用」がセットです。

よくある全体像（テキスト図）

【クラウド（Azure / M365）】

・Entra ID（サインイン／監査）

・Azure（Activity Log、リソースログ、NSG/Firewall/WAF等）

・M365（監査ログ、メール、SharePoint等）

　↓（ログ収集・転送）

【ログ基盤（SIEM）】

・Microsoft Sentinel / 他社SIEM

・Log Analytics / データレイク / ストレージ等

　↓（監視・分析）

【SOC（MSSP / MDR）】

・アラートトリアージ（一次切り分け）

・インシデント判定（疑い→確度上げ）

・エスカレーション（連絡、推奨アクション）

・月次レポート、改善提案（範囲は契約次第）

　↓（実行主体）

【自社（情シス／CSIRT／各部門）】

・封じ込め（アカウント停止、通信遮断、端末隔離など）

・復旧（設定戻し、パッチ、リカバリ）

・対外説明（取引先、顧客、親会社、監査）

・再発防止（規程、承認、例外管理、教育）

ここで重要なのは、SOCを入れると次の“3つ”が増えることです。

（1）ログが集まる場所が増える（＝データの所在が増える）

（2）関係者が増える（＝責任の主語が増える）

（3）オペレーションが増える（＝「誰が決めたか」「いつ動くか」が問われる）

ここまでは技術の話。ここからが法務の話です。

SOCを入れたのに説明責任が軽くならないのは、まさにこの「増えた分」を説明しないといけないからです。

────────────────────────────

2. SOCを使っていても説明責任が軽くならない「3つの理由」

────────────────────────────

結論を、実務の論点に落として3つに絞ります。

────────────────────────────

理由①：SOCは“作業者”になれても、対外説明の“主体”になりにくい

────────────────────────────

取引先・顧客・親会社・監査が見ているのは、

「SOCがいるか」ではなく「あなたの会社が統制できているか」です。

社外への説明の主語は、多くの場合あなたの会社です。

取引先と契約しているのも、サービス提供主体もあなたの会社。

だから事故が起きたときに求められるのは、

・影響範囲（誰に、いつ、何が起きた可能性があるか）

・当面対応（封じ込め・復旧・再発防止）

・証跡（ログ・変更履歴・判断の記録）

であり、これを“あなたの会社として”出す必要があります。

SOCは協力者にはなれますが、責任主体を完全に引き受けるのは通常難しい、というのが現実です。

────────────────────────────

理由②：「ログがある」と「ログを提出できる」は別物（提出能力が問われる）

────────────────────────────

SOC導入後に増える“体制質問”の中心は、実はログです。

ただし問われるのは「ログ取ってますか？」ではありません。

・保持期間は何年ですか？（90日では足りないケースがある）

・誰が、何営業日以内に、どの形式で提出できますか？

・事故時にログを保全できますか？（削除停止・隔離・抽出者記録）

・提出するログの真正性を説明できますか？（いつ誰がどう抽出したか）

SOCがログを見ている＝提出できる、ではありません。

提出の責任、期限、形式、承認が決まっていないと、監査・取引先照会で詰まります。

さらに厄介なのが、ログがSOC側やSIEM運用側に寄っている場合です。

「確認します」「抽出します」「別料金です」「時間がかかります」

となった瞬間に、あなたの会社の説明責任としては弱く見えます。

────────────────────────────

理由③：SOC導入で“責任分界が複雑化”し、事故時に主語が割れる

────────────────────────────

SOC導入でよく起きるのが、事故時の「誰が何をするか」問題です。

・SOC：検知・分析・通知はできるが、封じ込め（アカウント停止や通信遮断）はできない／契約外

・MSP：運用変更はできるが、24/7即応は別

・自社：最終判断者はいるが、手順と承認が決まっておらず止まる

・クラウド事業者：基盤側情報は出せても、自社運用の判断はしない

結果、復旧より先に「責任者探し」が始まり、

一次報告が遅れ、説明が割れ、二次炎上します。

SOCを入れるほど「体制が強い」と見られがちですが、

実際は、責任分界を設計していないと“割れやすい構造”が増えるだけです。

────────────────────────────

3. 全国の案件で多い「SOC運用の法務・契約の落とし穴」3選

────────────────────────────

SOC導入後に燃えやすい落とし穴を、技術と法務のギャップとして3つに絞ります。

────────────────────────────

落とし穴①：SOW（別紙）に「通知・提出・保全協力」が落ちていない

────────────────────────────

契約本文に「協力する」「必要な情報を提供する」と書いてあっても、運用には落ちません。

SOC運用の実務を支配するのは、契約別紙（SOW：作業範囲と品質）です。

SOWに明記しないと、事故時にこうなります。

・一次通知の期限が曖昧（何分以内？）

・ログ提出が曖昧（何営業日以内？どの形式？）

・保全協力が曖昧（削除停止できる？抽出者記録は？）

「できるはず」ではなく、「義務としてやる」に落ちていないと、説明責任の材料が集まりません。

────────────────────────────

落とし穴②：再委託（国外SOC等）・越境が“後から発覚”し、委託管理で刺さる

────────────────────────────

SOCは、運用体制の都合で再委託や海外拠点が関与するケースがあります。

このとき問われるのは「海外がダメ」かどうかではなく、

・誰がアクセスできるのか（アクセス主体）

・どの範囲のデータ（ログ）に触れるのか（データ範囲）

・再委託先にも同等の義務（守秘、目的外利用禁止、提出・保全協力）が貫通しているか

・監督責任（一次請けが最終責任を負うか）

です。

ここが整理できていないと、取引先審査や親会社統制で止まります。

────────────────────────────

落とし穴③：「ログの所有・目的外利用（学習利用）・削除」の扱いが曖昧

────────────────────────────

ログは“証跡”である一方、扱いを誤ると“データ管理問題”になります。

特に論点になりやすいのが次です。

・ログの所有権・管理権（誰が持つか）

・目的外利用の禁止（分析改善や学習利用の範囲）

・契約終了時のログ取り扱い（引渡し／削除証明）

・保全（リーガルホールド相当）時の削除停止義務

・取引先照会で提出が求められた場合の協力義務

この整理がないと、説明責任として“出せるはずのものが出せない”状態になります。

────────────────────────────

4. SOC運用で崩れないための「整理のフレーム」

────────────────────────────

SOCを入れて“説明できる体制”にするには、技術強化より先に、最低限この3軸を紙に落とすのが効果的です。

────────────────────────────

整理軸①：責任分界は“タスク別RACI”で固定する（事故対応まで含める）

────────────────────────────

レイヤー（ネットワーク層など）で整理すると、事故対応の実務に落ちません。

SOC運用では次のタスクを並べてRACI（R=実行、A=最終責任、C=相談、I=共有）で固定します。

最低限入れるべきタスク例

1）検知・一次分析（SOC）

2）インシデント判定（誰が最終判定するか：SOC？自社？）

3）一次通知（誰が何分以内に誰へ：社内／委託先／必要なら取引先）

4）封じ込め（アカウント停止、アクセス遮断、端末隔離、CDN purge等：誰が実行するか）

5）ログ抽出・提出（監査・取引先：誰が何営業日以内に）

6）ログ保全（削除停止・隔離・抽出者記録：誰が責任を持つか）

7）復旧（誰が手順を持ち、誰が実行するか）

8）報告書・再発防止（誰がまとめ、誰が承認し、誰が対外説明するか）

9）委託先管理（再委託、特権アクセス、契約終了時の出口）

この1枚があると、SOCがいても主語が割れません。

────────────────────────────

整理軸②：「提出能力」を作る（ログは“取る”ではなく“出す”）

────────────────────────────

SOC導入後に最も問われるのが、ログの提出能力です。

以下を「証跡パック」として定義すると、監査・取引先対応が安定します。

証跡パック（最小セット例）

・対象ログ一覧（認証、管理操作、NW変更、Key操作など）

・保持期間（標準／延長／規制・契約要件との整合）

・提出期限（例：何営業日以内）

・提出形式（項目、時刻基準、マスキングの要否）

・抽出手順（誰が実施、誰が承認）

・保全手順（削除停止、隔離、抽出者記録）

・委託先からの提出ルート（SOC→MSP→自社、など実態に合わせる）

「ログは見えます」ではなく、

「この形式で、何営業日以内に提出できます」

が言えると、説明責任が成立しやすくなります。

────────────────────────────

整理軸③：契約（特にSOW）に“事故対応の義務”を落とす

────────────────────────────

SOCは運用サービスです。運用サービスは、契約別紙（SOW）で品質が決まります。

最低限ここは“義務”として固めたい、という項目です。

SOWに落としたい最低ライン（例）

・一次通知：検知から何分以内、チャネル、通知内容の最低要件

・エスカレーション：重大度（Severity）基準、連絡ルート、エスカレ階層

・ログ提出義務：提出期限・形式・対象範囲・費用（追加費用が出る条件）

・保全協力：削除停止、隔離、抽出者記録、証跡保管

・調査協力：原因分析に必要な情報提供、期限、報告書の粒度

・特権アクセス統制：個人アカウント、期限、承認、操作ログ、剥奪証明

・再委託（国外含む）：条件、範囲特定、同等義務の貫通、監督責任

・契約終了（出口）：ログの引渡し範囲、削除証明、アクセス剥奪証明、引継ぎ

これがないと、説明責任に必要な“材料”が契約上保証されません。

────────────────────────────

5. ケーススタディ（匿名化）：SOCがあるのに取引先照会で詰まった製造業A社

────────────────────────────

実務で起きがちな構図を、匿名化して紹介します。

背景

・業種：製造業

・構成：Azure＋M365、SIEM導入、SOCに24/7監視を委託

・狙い：インシデント検知の強化、情シス負担の軽減

起きたこと

・取引先から「インシデント時のログ提出と保全」「一次通知体制」の照会が入る

・社内は「SOCが見ているので大丈夫」と回答しそうになる

・しかし、提出期限・提出形式・保全手順が社内で定義されておらず、SOC契約にも明記が弱い

・結果、回答が遅れ、部門間で説明が割れる（情シス／法務／委託先）

整理したこと（抜粋）

・タスク別RACIを作成（一次通知、封じ込め、保全、提出、対外説明の主語を固定）

・証跡パックを定義（保持期間、提出期限、形式、承認、保全）

・SOWを見直し、一次通知・ログ提出義務・保全協力・特権アクセス統制を追記

・再委託（国外関与）の有無と範囲を明文化し、同等義務の貫通を整理

結果として

・「SOCがいるから大丈夫」ではなく、「こういう体制と証跡で説明できる」へ切り替えられ、

・取引先照会への回答が安定し、監査でも説明が通りやすくなった

という流れです。

────────────────────────────

6. SOC運用中の企業が、今すぐ確認しておきたいチェックリスト

────────────────────────────

□ SOCが担当する範囲（検知・分析・通知・一次対応）が文章で説明できる

□ 自社が担当する範囲（封じ込め・復旧・対外説明）がRACIで固定されている

□ インシデント一次通知の期限（何分以内）と連絡ルートが決まっている

□ 重大度（Severity）基準とエスカレーション条件が定義されている

□ ログの保持期間が、監査・取引先要件と整合している

□ ログ提出の期限（何営業日以内）・形式・承認者が決まっている

□ 事故時のログ保全（削除停止・隔離・抽出者記録）ができる

□ SOC/委託先にログ提出義務・保全協力がSOWで義務化されている

□ 委託先の特権アクセスが統制されている（個人アカウント、期限、操作ログ、剥奪証明）

□ 再委託（国外SOC等）の範囲特定と同等義務の貫通が説明できる

□ 契約終了時の出口（ログ引渡し、削除証明、アクセス剥奪証明、引継ぎ）が決まっている

「SOCを入れているのにYESが揃わない」なら、説明責任は軽くなっていない可能性が高いです。

────────────────────────────

7. まとめ：SOCは“守ってくれる”が、“説明してくれる”とは限らない

────────────────────────────

SOC導入は、検知・分析・一次対応の強化として非常に有効です。

ただし、SOCはあなたの会社の説明責任を肩代わりする仕組みではありません。

説明責任が軽くならない（むしろ重くなる）理由は、

・主語（関係者）が増える

・ログの所在が増える

・提出能力と契約義務が問われる

からです。

だからこそ、SOC導入企業がやるべきことは

・タスク別RACIで主語を固定する

・証跡パックで提出能力を作る

・SOWで通知・提出・保全協力・特権統制を義務化する

この3点です。

────────────────────────────

8. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azure / M365 等の技術構成と、SOC／SIEM運用を含む委託契約・規程・監査対応をセットで整理する「クラウド法務支援」を行っています。

・SOCを入れたが、取引先や監査に“提出能力”を説明できない

・SOWに一次通知、ログ提出、保全協力、特権アクセス統制を落としたい

・再委託（国外SOC等）を含めた委託管理を、説明できる形にしたい

・責任分界を“レイヤー”ではなく“タスク別RACI”で1枚にしたい

といったお悩みがあれば、オンライン（全国対応）で初回のご相談を承っております。

お問い合わせの際に「SOCと説明責任の記事を見た」と書いていただけるとスムーズです。