【クラウド法務】監査用資料と、事故対応資料が同じではいけない理由― “説明するための資料”と“動くための資料”を混ぜた瞬間、監査にも事故にも弱くなる ―

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

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

はじめに

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

情シスやクラウド運用の現場で、よくある“善意の一本化”があります。

「監査で求められる資料と、事故対応の資料は同じでいいですよね？」

「どうせ説明するなら、資料は1つにまとめた方が楽」

「監査用の整理ができていれば、事故対応もできるはず」

気持ちは分かります。資料は増やしたくないし、更新コストもかかります。

ところが実務では、この“同じにする発想”が、監査・取引先審査・事故対応のどこかで必ず破綻します。

結論から言うと、監査用資料と事故対応資料は、目的も読者も時間軸も違うため、同じにしてはいけません。

同じにすると、次のどちらか（または両方）が起きます。

・監査では「根拠が弱い」「証跡が足りない」と言われる

・事故では「抽象的すぎて動けない」「機密が多すぎて扱えない」と言われる

本記事では、なぜ同じではいけないのかを技術→法務→運用の順で整理し、現場で回る“二つの資料パック”の作り方を提示します。

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

技術構成の“事実整理”：監査と事故対応は「同じシステム」を見ていても“見ているもの”が違う

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

まず、同じAzure/M365環境でも、監査と事故対応は見ているポイントが違います。

ここを混ぜると資料が崩れます。

よくあるクラウド運用の全体像（テキスト図）

【ID】Entra ID

・条件付きアクセス、PIM、監査ログ

　↓

【Azure/M365】

・VNet/NSG/Firewall、VM/PaaS、Key Vault

・バックアップ/BCP

　↓

【ログ】

・Sign-in / Audit / Activity / Resource logs

・SIEM（Sentinel等）

　↓

【体制】

・自社（情シス/CSIRT/法務/経営）

・委託（SIer/MSP/SOC、再委託・海外SOC含む）

この同じ構成を、監査と事故はこう見ます。

監査が見たいもの（ざっくり）

・統制が“存在している”か

・統制が“運用されている証跡”があるか

・例外が“管理されている”か

・委託・再委託が“統制されている”か

・継続的改善が回っているか（棚卸し、是正、レビュー）

事故対応が見たいもの（ざっくり）

・今この瞬間に“誰が決めるか”（指揮・承認）

・“何を止めるか”（封じ込め）

・“何を残すか”（ログ保全・抽出者記録）

・“何をいつ出すか”（第一報、証跡提出、更新時刻）

・委託先をどう動かすか（期限付き依頼・責任分界）

つまり、監査は「平常時の証明」、事故は「非常時の実行」です。

ここまでは技術の話。ここからが法務・説明責任の地雷です。

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

2. 監査用資料と事故対応資料を同じにしてはいけない理由（6つ）

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

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

理由①：目的が逆だから（監査＝説明、事故＝実行）

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

監査用資料は「説明のための資料」です。

・統制があること

・運用されていること

・証跡があること

を、第三者に“後から”説明するためのものです。

事故対応資料は「実行のための資料」です。

・最初の10分で誰が指揮するか

・何を止め、何を保全し、何を記録するか

を、現場が“今”動くためのものです。

同じにするとどうなるか

・監査資料に寄せると抽象的になり、事故で使えない

・事故資料に寄せると詳細すぎて、監査提出に向かない（機密過多）

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

理由②：時間軸が違う（監査＝月次/四半期、事故＝分/時間）

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

監査は「一定期間の運用」を評価します。

事故は「最初の30分」で勝負が決まります。

監査資料の典型

・年1回レビュー

・四半期の棚卸し

・月次のチェック

・運用実績の証跡

事故対応資料の典型

・0〜10分：指揮官、重大度、ワールーム、記録係

・10〜20分：封じ込め＋保全

・20〜30分：第一報、次回更新時刻、委託先依頼

同じ資料にすると、事故対応の“分単位の意思決定”が、監査資料の“月単位の文章”に埋もれます。

結果、事故で開いた人が「どこを見れば動けるのか」分からなくなります。

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

理由③：アクセス制御が真逆だから（監査＝広め、事故＝絞る）

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

監査用資料は、比較的広い範囲（監査人、親会社、取引先、関係部門）に共有されることがあります。

一方、事故対応資料には、次のような“極めて危険な情報”が入りやすいです。

事故対応資料に入ると危ない情報の例

・封じ込め手順（止め方＝攻撃者にも有用）

・緊急時の例外ルート（暫定開放、除外設定）

・連絡網（個人連絡先、当番）

・委託先の特権アクセス情報

・証跡保全の具体手順（どこから取れるか）

・外部報告のドラフト（未確定情報）

事故対応資料は「必要な人だけが見られる」前提で作るべきです。

監査資料と同じ扱いにすると、機密の取り扱いが破綻します。

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

理由④：契約・説明責任の“地雷”の出方が違う

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

監査では「統制の有無・証跡」が中心です。

事故では「期限付きの約束」が中心になります。

事故で必ず問われる例

・一次通知は何分以内？

・ログ提出は何営業日以内？

・保全（削除停止）は誰が何分以内に？

・復旧は何時間で戻る？（SLAではなくRTO/RPO）

・対外説明は誰が承認する？

監査資料は「運用しています」と書けても、

事故資料は「何分以内に」「誰が」「どの形式で」を書かないと動けません。

同じ資料にすると、監査用の“ふんわり表現”が事故時の説明責任を壊します。

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

理由⑤：更新のしかたが違う（監査＝安定、事故＝改訂が速い）

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

監査資料は、承認済み・版管理・改訂履歴が重要です。

事故対応資料は、実務に合わせて改訂が速く、改善が頻繁に入ります（訓練後に毎回変わるのが正常）。

同じ資料にすると

・監査の版管理が重くなり、事故資料の改訂が遅れる

または

・事故資料の更新が頻繁で、監査資料が安定しない

という矛盾が起きます。

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

理由⑥：事故後の“提出物”は監査資料では代替できない

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

事故後、取引先や親会社が求めるのは、監査資料ではなく「事故の時系列と証跡」です。

事故後に求められがちなもの

・タイムライン（誰がいつ何をしたか）

・封じ込めの根拠と実施記録

・保全実施記録（対象、期間、実施者、時刻）

・抽出者記録（いつ誰がどう取得したか）

・暫定影響と更新履歴（いつ何を把握したか）

・RCA（原因分析）と再発防止の計画

監査資料の「統制しています」は、事故後の説明には足りません。

事故対応資料の“記録フォーマット”が必要です。

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

3. クラウド法務としての「整理のフレーム」：二つの資料パック＋橋渡し資料

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

結論は、資料を1つにするのではなく、役割を分けて“連携”させることです。

おすすめは次の3点セットです。

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

（A）監査用パック（Audit Pack）

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

目的：第三者に「統制がある／回っている」を説明する

最小構成（例）

システム概要（対象範囲、重要度、委託関係）

統制一覧（コントロールマトリクス）

責任分界（タスク別RACI：ただし機密は落とす）

例外管理の仕組み（例外台帳の運用ルール、棚卸し頻度）

ログ管理方針（保持期間の方針、提出の枠組み※詳細手順は事故側へ）

変更管理（承認・記録の流れ、緊急変更の扱い）

委託管理（再委託、特権アクセス統制の枠組み）

証跡目録（何を証跡として保存するか、保存先）

ポイント

監査用パックは「証明」重視。機密情報は原則入れません。

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

（B）事故対応パック（Incident Pack）

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

目的：最初の30分で動き、証跡を残し、期限内に説明できる状態を作る

最小構成（例）

初動30分プレイブック（0-10/10-20/20-30分）

指揮系統（Incident Commander、承認者、記録係）

封じ込め手順（権限剥奪、通信遮断、例外解除の判断基準）

ログ保全手順（削除停止、隔離、抽出者記録、アクセス制限）

ログ提出手順（対象ログ、期限、形式、承認、委託先への依頼テンプレ）

対外コミュニケーションテンプレ（第一報の型、更新時刻の型）

委託先・ベンダー連絡表（SOWに基づく依頼内容と期限）

タイムライン記録テンプレ（意思決定・実施操作・根拠を残す）

ポイント

事故対応パックは「実行」重視。アクセス制限が必須です（見られる人を絞る）。

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

（C）橋渡し資料（Bridge）：監査の言葉と事故の動きを繋ぐ1枚

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

これがあると、資料が増えても迷子になりません。

橋渡し資料に入れるもの（例）

・監査の統制項目（例：ログ管理、権限管理、例外管理）

　→ 事故時に参照する具体手順（どのプレイブック/どのテンプレ）

・証跡として残すべきもの

　→ 事故時に生成される記録（タイムライン、保全記録、抽出者記録）

・委託管理の統制

　→ 事故時の依頼テンプレ（提出期限、保全協力、RACI）

監査と事故対応を「同じ資料」にしない代わりに、

“監査の説明”が“事故の動き”に落ちるように橋を掛けます。

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

4. ケーススタディ（匿名化）：監査資料は完璧なのに事故対応が遅れたA社

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

（実務でよくある構図を匿名化しています）

背景

・Azure＋M365運用

・監査用のバインダー（統制説明、構成図、運用規程）が整備されていた

・SOC監視、MSP運用で分業

事故

・深夜に不正アクセス疑いのアラート

・監査資料は「インシデント対応体制あり」と記載

・しかし事故の現場では、次が無かった／薄かった

指揮官（誰が最終判断か）

封じ込めの判断基準（止める/観察）

ログ保全の手順（削除停止、抽出者記録）

委託先への期限付き依頼テンプレ（提出・保全協力）

結果

・初動30分で決めるべきことが決まらず、封じ込めと保全が遅れた

・後から「監査資料には体制ありと書いてあるのに、なぜ動けなかったか」を問われ、説明が割れた

立て直し

・監査パックと事故パックを分離

・事故パックに初動30分プレイブックと保全・提出テンプレを追加

・橋渡し資料で、監査の統制項目と事故手順を対応付け

・委託契約（SOW）に、一次通知・提出期限・保全協力を期限付き義務として追記

結果

・監査は「証明」が強くなり、事故対応は「実行」が速くなり、両方が改善した

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

5. すぐ使えるチェックリスト：あなたの資料が“混ざって”いないか

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

以下にYESが多いほど、監査資料と事故資料が混ざっていて、どちらも弱くなっている可能性があります。

□ 監査資料に、封じ込め手順や具体的な保全手順がそのまま載っている（機密過多）

□ 監査資料が配布される範囲に、事故対応の連絡網や当番情報が含まれている

□ 事故時に監査資料を開いても、0〜10分で何をするか書いていない（抽象的）

□ 事故対応資料に「統制は実施している」など監査向け文章が多く、手順が薄い

□ 事故対応資料に、ログ提出期限・形式・承認者が固定されていない

□ 事故対応資料が版管理されておらず、訓練後の改善が反映されない

□ 委託先の義務（通知・提出・保全協力）がSOWに落ちていないのに、資料上は“できる前提”になっている

□ 橋渡し資料（監査の統制→事故手順）がなく、どこを見ればいいか迷う

□ 例外台帳や暫定対応の管理が、監査資料には書いてあるが、事故側の実行テンプレに繋がっていない

混ざっている場合は、「監査パック」「事故パック」「橋渡し1枚」に分けるだけで改善します。

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

6. まとめ：同じにすると“どちらにも使えない資料”が出来上がる

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

監査用資料と事故対応資料が同じではいけない理由は、根本的に次が違うからです。

・目的（説明 vs 実行）

・時間軸（月/四半期 vs 分/時間）

・アクセス制御（広め vs 絞る）

・求められる約束（統制証明 vs 期限付き対応）

・更新サイクル（安定 vs 改訂が速い）

・事故後の提出物（統制説明では代替できない）

だから、同じ資料にまとめるのではなく、

監査パック（証明）

事故パック（実行）

橋渡し資料（対応付け）

の3点セットで揃えるのが、最も事故りにくい現実解です。

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

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

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

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、

「監査に強いが事故に弱い」または「事故に強いが監査で説明が割れる」状態を、

監査パック／事故パック／橋渡し資料の形に落として整えるクラウド法務支援を行っています。

・監査資料はあるのに、事故時に何を見ればよいか分からない

・事故対応手順はあるが、監査や取引先に“統制”として説明できない

・ログ保全・提出を期限付きで整備し、証跡（抽出者記録）まで揃えたい

・委託先（SOC/MSP/再委託含む）を含めた責任分界（RACI）とSOWを固めたい

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

お問い合わせの際に「監査資料と事故対応資料の記事を見た」と書いていただけるとスムーズです。