セキュリティインシデントが起きたとき、最初に必要なのは「どこへ報告すべきか」を検索し続けることではありません。被害拡大を止める、証跡を消さない、個人情報や取引先への影響を切り分ける、経営判断に必要な事実をそろえる。この順番を外すと、復旧が遅れ、報告内容も曖昧になります。
個人情報保護委員会は、漏えい等報告について、速報は発覚後速やかに、確報は原則30日以内、不正目的のおそれがある場合は60日以内という期限を示しています。また、ランサムウェア事案による個人データの漏えい等またはそのおそれについて、政府全体の方針に従い共通様式で報告できる旨を案内しています。JPCERT/CCは、国内が関連するインシデントに対応するCSIRTとして、報告受付、対応支援、手口分析、再発防止の助言などを行うと説明しています。
この記事では、2026年7月2日時点で確認できる一次情報を基に、インシデント発生時の報告・復旧・証跡保全の実務チェックリストを整理します。未確定の制度改正や罰則を断定せず、現場が迷いやすい「誰が、何を、どの順番で確認するか」に絞ります。
目次
- 結論：報告先より先に事実確認と証跡保全を固定する
- 誰が読むべきか
- 最初の24時間で確認すること
- 報告先を切り分ける判断表
- PPC漏えい等報告で確認する項目
- 復旧とフォレンジックを分ける
- 平時に整備すべき証跡と体制
- GXOに相談すべきタイミング
- FAQ
- 一次情報・参考情報
結論：報告先より先に事実確認と証跡保全を固定する
インシデント対応では、報告先の一覧表だけでは足りません。報告は、事実確認の結果として行うものです。最初に社内で決めるべきなのは、次の5点です。
横にスクロールして確認できます
| 論点 | すぐ決めること | 決めない場合のリスク |
|---|---|---|
| 指揮系統 | 経営判断者、技術責任者、広報・法務窓口 | 担当者が個別判断し、対応が分裂する |
| 影響範囲 | 影響システム、個人情報、取引先、顧客接点 | 報告要否や復旧優先順位を誤る |
| 証跡保全 | ログ、端末、サーバー、クラウド操作履歴 | 復旧作業で原因調査に必要な証跡を消す |
| 外部連絡 | PPC、JPCERT/CC、警察、所管先、取引先 | 必要な連絡が遅れ、信用低下につながる |
| 復旧判断 | 切り離し、バックアップ、暫定復旧、本復旧 | 攻撃経路を残したまま再開する |
報告義務の有無は、個人情報の種類、件数、不正アクセスの有無、業法、契約条件、被害の性質によって変わります。自社だけで判断できない場合は、技術調査と法務確認を同時に進める体制が必要です。
SECURITY OPERATION
日常の脆弱性運用、情シス1人で回せる体制にしませんか？
月次棚卸・重大度判定・パッチ適用代行まで含む「セキュリティ運用伴走」プラン。単発対応からの卒業で、止まらない運用体制を作ります。
誰が読むべきか
この記事は、経営者、CIO、情シス、セキュリティ担当、Webサイト運用責任者、SaaS管理者、開発保守責任者に向けています。
特に次の状況では、単なるチェックリストではなく、外部支援を含む初動体制を準備すべきです。
- Webサイトが改ざんされ、フォーム入力情報や決済情報への影響が疑われる
- ランサムウェア感染、暗号化、脅迫メール、データ持ち出しの主張がある
- 顧客情報、従業員情報、採用応募者情報、取引先担当者情報を扱っている
- クラウド管理者、VPN、メール、SaaSの不正ログインが疑われる
- 既存ベンダーだけではログ分析や復旧判断ができない
- 取引先からセキュリティ事故報告書や再発防止策の提出を求められている
GXOとして初回相談すべきテーマは、単発の注意喚起ではありません。ハッキングされたサイトの復旧、ランサムウェア初動、システム復旧、ログ調査、再発防止、月次セキュリティ運用、開発保守体制の見直しです。
最初の24時間で確認すること
発覚直後は、全てを完璧に調べるより、被害拡大を止めながら後で説明できる事実を残すことが重要です。
横にスクロールして確認できます
| 時点 | 実施すること | 注意点 |
|---|---|---|
| 発覚直後 | 画面、メール、ログ、アラート、時刻、発見者を記録 | 証跡を消す再起動・初期化を急がない |
| 初動 | 影響端末・サーバー・アカウントを切り離す | 業務停止影響と証跡保全を両方見る |
| 事実確認 | 個人情報、決済情報、認証情報、業務データへの影響を切り分ける | 推測で件数や原因を断定しない |
| 社内報告 | 経営、情シス、法務、広報、営業責任者へ共有 | 外部説明の文言を統一する |
| 外部相談 | 必要に応じてJPCERT/CC、警察、専門会社、弁護士へ相談 | 技術調査と報告判断を分けて進める |
| 復旧判断 | 暫定復旧、本復旧、顧客対応、再発防止の順に整理 | 攻撃経路が残ったまま戻さない |
初動で避けるべき行動は、証跡を取らずにサーバーを作り直す、感染端末を初期化する、原因未確認のまま全顧客へ断定的に説明する、復旧を急いで同じ認証情報を再利用する、といった対応です。
報告先を切り分ける判断表
報告先は一律ではありません。個人情報、犯罪被害、業法、契約、サプライチェーンの観点で切り分けます。
横にスクロールして確認できます
| 状況 | 確認すべき主な相談・報告先 | 実務上のポイント |
|---|---|---|
| 個人データの漏えい等またはそのおそれ | 個人情報保護委員会 | PPCの要件と期限を確認し、速報と確報を分ける |
| 不正アクセス、詐欺、脅迫、ランサムウェア被害 | 警察、JPCERT/CC、専門会社 | 犯罪被害の証跡と復旧調査を並行する |
| 取引先データや委託業務への影響 | 取引先、委託元、契約窓口 | 契約上の通知期限・報告様式を確認する |
| 業法・所管規制の対象 | 所管省庁、監督機関、業界団体 | 業種別ガイドラインと契約条件を確認する |
| Webサイト改ざん・マルウェア配布 | JPCERT/CC、ホスティング事業者、開発保守会社 | 改ざん範囲、外部送信、検索結果汚染を確認する |
| 社内システム停止・復旧不能 | 保守会社、クラウド事業者、復旧支援会社 | バックアップの安全性と復旧順序を確認する |
JPCERT/CCへの報告は、法令上の報告義務と同じ意味ではありません。国内が関連するインシデントの調整や助言を受けるための実務的な相談先として位置付けます。
PPC漏えい等報告で確認する項目
個人情報保護委員会は、漏えい等報告が必要な場合として、要配慮個人情報が含まれる場合、財産的被害のおそれがある場合、不正目的のおそれがある行為による場合、一定規模を超える場合などを示しています。報告期限についても、速報と確報で扱いが分かれます。
社内では、次の情報を早期に集められるようにしておきます。
横にスクロールして確認できます
| 項目 | 確認内容 | 収集元 |
|---|---|---|
| 発覚日時 | 誰が、いつ、何を見て発覚したか | アラート、メール、問い合わせ、監視通知 |
| 事案概要 | 漏えい、滅失、毀損、不正アクセス、誤送信など | 初動記録、ヒアリング |
| 対象データ | 顧客、従業員、応募者、取引先担当者など | DB、ファイルサーバー、SaaS |
| 情報の種類 | 要配慮個人情報、認証情報、決済情報、連絡先など | データ台帳、システム仕様 |
| 対象人数 | 判明範囲と未確定範囲を分ける | ログ、DB抽出、バックアップ |
| 原因 | 判明事項と調査中事項を分ける | ログ分析、フォレンジック |
| 二次被害 | 不正利用、なりすまし、詐欺連絡の有無 | 顧客問い合わせ、監視結果 |
| 再発防止 | 暫定策と恒久策を分ける | 技術調査、運用改善計画 |
速報段階で全てが確定している必要はありません。重要なのは、確認済みの事実、未確認の事項、今後の調査予定を混ぜずに書く姿勢です。
復旧とフォレンジックを分ける
インシデント対応で最も危険なのは、「早く復旧したい」という判断だけで証跡を消してしまう対応です。ハッキングされたWebサイト、ランサムウェア感染、クラウドアカウント侵害では、復旧と調査を分けて設計します。
横にスクロールして確認できます
| 領域 | 復旧で見ること | 調査で見ること |
|---|---|---|
| Webサイト | 改ざんページの停止、フォーム閉鎖、脆弱箇所の修正 | 改ざん経路、外部送信、管理者アカウント、ログ |
| サーバー | ネットワーク隔離、クリーン環境への移行 | 侵入経路、永続化、横展開、マルウェア痕跡 |
| PC端末 | 隔離、業務代替機の用意 | 感染時刻、添付ファイル、認証情報流出 |
| クラウド | 管理者権限の停止、キー再発行 | 操作履歴、APIキー、外部共有、異常ログイン |
| バックアップ | 復旧可能な世代の確認 | 攻撃前の世代か、暗号化・改ざんされていないか |
GXOの現場感では、復旧支援が必要な相談は「セキュリティ診断」よりも緊急度が高く、判断材料が不足したまま始まることが多い領域です。初回対応では、原因の断定よりも、止血、証跡保全、復旧順序、外部説明の土台づくりを優先します。
平時に整備すべき証跡と体制
インシデント時に使える情報は、平時に保存・整理している情報に限られます。平時の準備は、発生後の調査費用を安く見せるためではなく、復旧時間と説明不能リスクを下げるための投資です。
横にスクロールして確認できます
| 領域 | 平時に用意するもの | インシデント時の効果 |
|---|---|---|
| 資産管理 | サーバー、SaaS、ドメイン、管理者、委託先の一覧 | 影響範囲と連絡先を早く特定できる |
| ログ | 認証、管理操作、Web、メール、クラウド、EDRのログ | 侵入経路と被害範囲を追跡できる |
| バックアップ | 世代、保管場所、復旧手順、復旧訓練記録 | 復旧可能性を判断できる |
| 個人情報台帳 | どのシステムに何の個人情報があるか | PPC報告要否と対象人数を確認できる |
| 連絡体制 | 経営、情シス、法務、広報、外部専門家、保守会社 | 初動で連絡漏れを減らせる |
| 契約確認 | 委託先、SaaS、取引先との通知義務 | 通知期限と責任分界を確認できる |
| 訓練 | 机上演習、復旧訓練、報告書作成演習 | 本番時の判断遅れを減らせる |
NIST Cybersecurity Frameworkは、サイバーリスク管理を改善するための枠組みとして使われています。日本企業がそのまま法令対応として使うものではありませんが、資産把握、保護、検知、対応、復旧の観点で自社体制を点検する補助線になります。
GXOに相談すべきタイミング
次のいずれかに該当する場合は、記事を読み進めるだけでなく、早めに外部支援を入れるべきです。
- サイト改ざん、マルウェア配布、フォーム情報の外部送信が疑われる
- ランサムウェア、暗号化、脅迫、データ持ち出しの主張がある
- 顧客情報、従業員情報、採用情報、決済情報への影響が疑われる
- 復旧を急ぎたいが、原因調査や証跡保全も必要
- 既存ベンダーが保守範囲外として対応できない
- 取引先や顧客に提出する報告書・再発防止策が必要
- インシデント後に、監視、ログ管理、バックアップ、権限管理を継続改善したい
GXOでは、インシデント対応支援、脆弱性診断、セキュリティ顧問・運用支援、DX・システム開発、レガシーシステム刷新を組み合わせ、初動対応、復旧、再発防止、継続運用まで整理します。問い合わせ窓口はお問い合わせです。
インシデント発生時の初動・復旧・報告整理が必要な方へ
GXOが、被害範囲の切り分け、証跡保全、復旧順序、PPC報告に必要な情報整理、再発防止策、月次セキュリティ運用まで実務目線で支援します。
緊急時は、現在判明している事実、発覚時刻、影響システム、保守会社、取得済みログの有無を整理してご相談ください。
FAQ
個人情報漏えいか不明な段階でもPPCに報告すべきですか？
報告要否は、対象データ、漏えい等のおそれ、件数、不正目的の有無などで変わります。速報段階では未確定の事項が残る場合もあります。まずは確認済み事実と調査中事項を分け、PPCの公式案内や専門家の助言に基づいて判断します。
JPCERT/CCに連絡すれば法令上の報告は完了しますか？
完了しません。JPCERT/CCはインシデント対応の調整・支援を行う組織であり、個人情報保護委員会への漏えい等報告や、業法・契約上の通知とは別に考える必要があります。
復旧を急ぐ場合、ログ取得より先にサーバーを作り直してよいですか？
状況によりますが、証跡を残さずに初期化すると、侵入経路、影響範囲、再発防止策を説明できなくなる可能性があります。業務停止の影響が大きい場合でも、可能な範囲でスナップショット、ログ、設定情報を保全してから復旧手順を進めます。
平時に最初に整備すべきものは何ですか？
資産一覧、個人情報台帳、管理者アカウント一覧、ログ保存先、バックアップ復旧手順、緊急連絡先です。これらがないと、発生後に報告要否も復旧順序も判断しにくくなります。
一次情報・参考情報
本稿では2026年7月2日に確認したPPC、JPCERT/CC、NISTの公開情報を参照しています。個別事案の報告義務、本人通知、取引先通知、警察相談、所管省庁対応は、被害内容、契約、業法、個人情報の種類によって変わるため、実対応では公式窓口と専門家確認を併用してください。
