時間との戦い、証拠は止まらない：NIS2のようなインシデント報告法が実際に求めるものとは

はじめに

金曜日の午後11時、大規模なサイバーインシデントが発生。NIS2の下では、最初の規制上の期限は、通知文書の作成時点ではなく、組織がインシデントを認識した瞬間からカウントが始まります。24時間後には、国の当局が早期警告を期待しています。その72時間後には、深刻度や影響の初期評価を含む詳細な報告書が求められます。最終報告書は1か月以内に提出が必要です。

これらの期限は意図的に厳しく設定されています。多くの組織が実際に気づくのは、事前ではなくインシデント発生中であり、計画しやすいのは「時間」だけだということです。本当に難しいのは証拠の確保です。信頼性のある72時間報告書を書くために、何が、誰によって、どこからアクセスされ、その後どうなったのかを正確に把握する必要があります。本記事では、インシデント報告制度（NIS2など）が実際に運用上求めているもの、そして多くの場合、失敗の本当の原因がタイムラインではなく証拠のギャップである理由について解説します。

• ポイント1：NIS2のインシデント報告は、3段階の固定タイムラインで進行します。24時間以内の早期警告、72時間以内の詳細通知、1か月以内の最終報告書が、重大インシデントを認識した瞬間からそれぞれ始まります。
• ポイント2：72時間報告書には、物語ではなく具体的な内容が求められます。深刻度、影響、初期評価は裏付けが必要であり、組織が迅速に照会できる記録が必要となります。後から再構築するのでは不十分です。
• ポイント3：多くの組織は期限自体は守れるものの、証拠の基準を満たせません。インシデント対応計画があっても、数時間以内にどのデータが触れられたかを正確に説明できることとは別問題です。
• ポイント4：チャネルごとに分断されたログ管理は、証拠の収集に時間がかかる最も一般的な原因です。メール、ファイル共有、APIなど各チャネルが個別にログを記録している場合、1つの報告書を作成する前に、誰かが時間に追われながら相関付けをしなければなりません。
• ポイント5：単一かつ継続的な監査証跡があれば、報告作業は「手探り」から「照会」へと変わります。すでに1か所に存在する証拠を抽出・検証でき、複数システムから手作業で集めて突き合わせる必要がなくなります。

エグゼクティブサマリー

NIS2のようなインシデント報告制度は、しばしば「期限管理」の問題として捉えられがちです。つまり、24時間・72時間以内に正しい当局へ通知できるよう、社内プロセスを迅速に構築するという考え方です。しかし、実際に組織が苦労するのはそこではありません。期限は事前に決まっており、よく知られています。問題は、必要な証拠が事前に十分な詳細で、かつ照会可能な形で記録されているかどうかです。セキュリティやコンプライアンス責任者にとって重要なのは、インシデント対応計画に正しい連絡先が書かれているかどうかではなく、限られた時間内に「何が、誰にアクセスされたか」をデータで正確に答えられるかどうかです。

インシデント報告のタイムラインが短縮されている理由

近年のインシデント報告フレームワークは、従来のような単一かつ遅延した通知モデルから脱却しています。初日に早期警告、3日以内に実質的な報告という段階的な構造は、「完全な報告書」よりも「早期の可視化」を重視する規制当局の判断を反映しています。

現代的なインシデント報告を支える3段階構造

重大インシデントを認識してから24時間以内に提出する早期警告は、全体像が判明する前に関連当局へシグナルを送るためのものです。72時間以内の詳細通知には、深刻度や影響の初期評価、場合によっては侵害の指標も含まれます。1か月以内の最終報告書では、根本原因や是正措置を報告します。各段階は、組織がすでに、もしくは迅速に事実関係を提示できることを前提としています。規制はタイムラインを定めますが、証拠自体を提供するものではありません。

「重大インシデント」かどうかも迅速かつ確信を持って判断する必要がある理由

報告書作成前に、そもそもそのインシデントが報告対象となる基準を満たしているか（深刻な業務停止、財務損失、他者への重大な被害など）を判断しなければなりません。この判断を迅速かつ根拠を持って行うには、発生直後から範囲や影響を可視化できることが不可欠です。最初の数時間で「何が起き、どのデータが関与したか」を大まかにでも説明できない組織は、単に報告が遅れるリスクだけでなく、そもそも報告が必要かどうかの判断を誤るリスクも抱えています。

本当のボトルネックは「証拠」であり、期限ではない

多くのセキュリティチームに「インシデント対応計画はありますか？」と聞けば「はい」と答えます。しかし、その計画が実際の72時間報告期限に耐えうるかと問えば、自信は一気に下がります。計画があっても、時間的プレッシャーの中で実行できるかどうかは、ほぼ間違いなく「証拠」の問題です。

信頼性のある72時間報告書に本当に必要なもの

72時間報告書は、組織が「こう思う」という説明ではなく、実際の初期評価（深刻度、想定される影響、技術的指標など）を含むことが求められます。そのためには、どのシステム・データが関与し、誰がいつ何にアクセスしたかを迅速かつ自信を持って答えられる必要があります。複数の分断されたシステムから手作業でログを抽出し、フォーマットを揃え、タイムスタンプを突き合わせるような作業では、証拠ではなく「時間」と戦うことになります。

分断されたログ管理が報告期限を「火消し作業」に変えてしまう理由

多くの組織は、機密データをメール、ファイル共有、API、マネージドファイル転送、さらにAIエージェントなど複数のチャネルで扱っています。各チャネルが独自の形式・粒度で独立してログを記録している場合、インシデントの全体像を1つにまとめるには、複数の断片的な記録を期限内に突き合わせる必要があります。ここで報告期限を逃すことが多く、最悪の場合、全体像が間に合わず、実態を過小評価した報告書になってしまうこともあります。

「報告対応可能な証拠」とはどのようなものか

インシデント報告の期限を「安堵」ではなく「自信」を持って守れる組織は、共通して「誰が、いつ、どこから、何に触れたか」を全チャネル横断で記録する単一の証跡を、インシデント発生前から持っています。発生後に寄せ集めるのではなく、あらかじめ存在していることが重要です。

継続的なログ記録は、事後の再構築に勝る

インシデント後に再構築する証拠は、常時記録されている証拠よりも遅く信頼性も低くなります。アクセス、送信、共有、ダウンロードのすべてをリアルタイムで記録し、サンプリングや遅延による抜けがないログがあれば、72時間報告書は既存の監査証跡を照会するだけで済み、断片から推測する必要がありません。

チャネル横断の相関は、インシデント発生前に構築されているべき

重大インシデントは1つのチャネルに限定されることは稀です。したがって、証拠は最初からチャネル横断で相関付け可能でなければなりません。例えば、外部関係者がメールでアクセスし、ファイル共有でダウンロードし、APIで取得したファイルを、1つのタイムラインで正確に示せる組織は、規定時間内に「何が起きたか」を説明できます。インシデント中に別々のシステムから寄せ集めているようでは、それは困難です。

タイムラインが動き出す前に、インシデント報告の備えを構築する

インシデント報告義務にしっかり対応できる組織は、証拠の問題を「インシデント対応」ではなく「インフラ」として捉えています。つまり、インシデント発生前に、すべての機密データの流れを横断してログが継続的かつ完全に記録されているか、数時間以内に意思決定に役立つ形で迅速に照会できるか、そしてその記録が「安心」ではなく「具体的な証拠」として当局の要求を満たせるかを監査しています。インシデント発生後にこれらの問いに答えようとするのは、どんなに計画が立派でも「準備不足」の証です。

データコントロールプレーンが報告期限の達成を可能にする理由

24時間・72時間の報告期限を一貫して守るには、プロセス文書化の問題ではなく「データの可視性」の問題です。メール、ファイル共有、API、AIエージェントなど、機密データが通過するすべてのチャネルで、アクセス・送信・共有・ダウンロードを継続的かつ単一・照会可能な形で記録するガバナンス層が必要です。そうすれば、インシデント発生時に証拠がすでに存在しており、後から寄せ集める必要がありません。

Kiteworks Data Control Planeは、すべてのチャネルにわたりデータ認識型のゼロトラスト・コントロールを適用し、改ざん不可能かつ遅延のない監査ログにすべてのアクションを記録し、セキュリティ情報イベント管理（SIEM）ツールに直接連携します。ログは常時記録され、サンプリングや遅延がないため、セキュリティ・コンプライアンスチームは、24時間以内の早期警告や72時間通知の実際の猶予時間内に「誰が、いつ、何をしたか」を正確に照会できます。日常のNIS2コンプライアンス報告を支える同じ記録が、インシデント通知の証拠基盤となり、毎回再構築する必要がありません。

現在のログ管理が24時間・72時間の報告タイムラインに本当に対応できるか試したい組織は、カスタムデモを予約し、継続的かつチャネル横断の証拠取得が自社のインシデント対応プロセスにどう適用できるかをご確認いただけます。