サイバー事故で信用を失わないための事前準備

事故前に用意すべき文書・連絡網・通知文案

メタディスクリプションサイバー事故で会社の信用を失うかどうかは、事故発生後の「その場対応」ではなく、事故前に整備した文書、連絡網、判断権限、通知文案、証拠保全手順で決まります。中小企業が準備すべきインシデント対応規程、個人情報漏えい対応、取引先通知、委託先連絡、社外公表文案を、企業法務とサイバーセキュリティの実務視点から解説します。

1. サイバー事故で信用を失う会社、失わない会社の違い

ランサムウェア感染、不正アクセス、メール誤送信、クラウド共有設定ミス、委託先からの漏えい連絡、Webサイト改ざん。こうした事故は、どの会社にも起こり得ます。

実務で見る限り、事故そのものよりも、事故後の対応で信用を失う会社が少なくありません。

「事実確認が遅い」「社内で誰が判断するか決まっていない」「取引先への第一報が遅れる」「個人情報保護委員会への報告要否を確認していない」「本人通知や公表文が場当たり的」「委託先やクラウド事業者からログを取得できない」「初動で端末を初期化し、証拠を消してしまう」

これらは、技術力だけの問題ではありません。事故前に、文書・連絡網・判断権限・通知文案を準備していなかったことが原因です。

IPAの「情報セキュリティ10大脅威 2026」では、組織向け脅威の1位がランサム攻撃、2位がサプライチェーンや委託先を狙った攻撃、3位がAIの利用をめぐるサイバーリスクとされています。事故対応は、自社PCだけでなく、委託先、クラウド、AI利用、個人情報、取引先説明まで含む経営課題になっています。

2. 事故対応は「技術対応」ではなく「経営・法務・広報・顧客対応」の総合戦

サイバー事故が起きると、最初に動くのは情報システム担当者や保守会社です。しかし、会社として信用を守るには、技術対応だけでは足りません。

経済産業省の「サイバーセキュリティ経営ガイドライン Ver.3.0」でも、経営者はサイバーセキュリティリスクを自社のリスクマネジメント上の重要課題として認識し、実施方針、予算・人材、実施状況確認、問題把握と対応を通じてリーダーシップを発揮する必要があるとされています。

事故発生時には、次の判断が同時に発生します。

判断事項	主な担当	事前準備がない場合の問題
システム停止・隔離	IT担当、保守会社、経営者	業務停止を恐れて初動が遅れる
顧客・取引先への第一報	経営者、営業、法務、広報	説明が遅れ、隠蔽と受け取られる
個人情報漏えい報告	個人情報管理責任者、総務、法務	期限内に報告できない
本人通知・公表	経営者、法務、広報	不正確な表現で二次炎上する
証拠保全	IT担当、外部専門家	端末初期化やログ消失で原因調査不能になる
委託先・クラウド事業者への連絡	契約担当、IT担当	ログ提出や調査協力を求められない
復旧優先順位	経営者、現場責任者	重要業務より後回しのシステムを先に復旧する

つまり、事故対応は「ウイルスを駆除する作業」ではありません。会社として何を守り、誰に、いつ、どの範囲で説明するかを決める危機管理です。

3. 事故前に用意すべき文書セット

サイバー事故で信用を失わないためには、次の文書を事故前に整備しておく必要があります。

文書	目的
情報セキュリティ基本方針	経営者として情報を守る姿勢を示す
情報セキュリティ規程	アカウント、端末、クラウド、持出し、廃棄、バックアップ等を定める
インシデント対応規程	検知、初動、報告、公表、復旧、再発防止の流れを定める
初動対応チェックリスト	事故直後に現場が迷わず動くための手順
個人情報漏えい等対応手順	報告要否、本人通知、公表、記録保存を定める
連絡網・緊急連絡先一覧	社内、外部専門家、委託先、クラウド事業者、行政機関等の連絡先
情報資産台帳	重要データ、保存場所、管理者、バックアップ有無を把握する
個人情報管理台帳	個人情報の取得元、利用目的、保存場所、委託先、保管期間を把握する
クラウド/SaaS台帳	利用サービス、管理者、保存データ、MFA、ログ取得可否を把握する
委託先管理台帳	委託先、再委託、取扱情報、契約条項、事故連絡先を把握する
通知文案・公表文案	取引先、顧客、本人、Web公表向けの定型文を準備する
事故対応記録票	発生時刻、発見者、影響範囲、対応履歴、判断者を記録する

ISMSでは、情報セキュリティを機密性・完全性・可用性を守る体系的な仕組みとして捉え、技術的対策だけでなく、従業員教育、訓練、組織体制の整備も含めます。事故前の文書整備は、まさにこの「仕組み」を会社の実務に落とし込む作業です。

4. 事故対応規程に必ず入れるべき項目

インシデント対応規程は、難しい専門用語を並べるための文書ではありません。事故時に、誰が読んでも行動できる文書にする必要があります。

最低限、次の項目を定めます。

項目	規程で定める内容
対象となる事故	ランサムウェア、不正アクセス、誤送信、紛失、クラウド誤公開、内部不正、委託先事故等
第一報の受付	誰に、どの方法で、何を報告するか
初動責任者	事故対応責任者、代行者、休日夜間の責任者
経営者への報告	どの段階で社長・役員に報告するか
封じ込め	端末隔離、ネットワーク遮断、アカウント停止、共有リンク停止
証拠保全	ログ、メール、画面、脅迫文、端末、通信記録の保存
外部連絡	保守会社、クラウド事業者、委託先、警察、IPA、JPCERT/CC等
個人情報対応	報告要否、本人通知、公表、記録作成
取引先対応	第一報、続報、最終報、再発防止報告
復旧判断	復旧優先順位、バックアップ利用、再感染防止
再発防止	原因分析、是正措置、教育、契約・規程の見直し

IPAの中小企業向けインシデント対応資料では、検知・初動対応、報告・公表、復旧・再発防止という流れが示され、初動では情報セキュリティ責任者への報告、経営者への報告、体制立上げ、ネットワーク遮断・隔離・停止等が説明されています。また、不用意な操作でシステム上の記録を消さないことも重要とされています。

5. 初動対応チェックリストは「1枚」でよい

事故発生直後、現場は長いマニュアルを読みません。最初に使うのは、1枚のチェックリストです。

初動対応チェックリスト例

確認項目	記録する内容
発見日時	年月日、時刻
発見者	氏名、部署、連絡先
事故の種類	ランサムウェア、不正アクセス、誤送信、紛失、クラウド誤公開等
影響を受けた機器・サービス	PC、サーバ、クラウド、メール、Webサイト等
影響を受けた情報	個人情報、顧客情報、契約書、営業秘密、認証情報等
直ちに行った対応	端末隔離、アカウント停止、共有リンク停止等
証拠保全	スクリーンショット、ログ、メール、脅迫文、通信記録
報告先	社内責任者、経営者、保守会社、委託元、行政機関等
未確認事項	漏えい有無、件数、原因、侵入経路、二次被害
次回報告時刻	何時までに続報を出すか

実務上、最も大切なのは「分からないことを、分からないまま記録すること」です。事故直後に無理に断定すると、後で訂正が必要になり、信用を落とします。

6. ランサムウェア対応で事前に決めておくべきこと

ランサムウェア対応では、初動の数時間が重要です。JPCERT/CCは、侵入型ランサムウェア攻撃への対応方針として、被害範囲の把握と最小化、侵入経路の封鎖、攻撃者の要求に応じずバックアップから復旧することを示しています。また、社内連絡体制、社外向け窓口、外部組織と連携する担当者の確保も重要とされています。

事故前に決めるべきことは、次のとおりです。

項目	事前に決める内容
端末隔離	誰が、どの端末を、どの方法でネットワークから切り離すか
バックアップ保護	バックアップ先を攻撃者から守るため、どの権限を停止するか
業務停止判断	どのシステムを止める権限を誰が持つか
復旧優先順位	受注、出荷、請求、給与、顧客対応など、何を先に復旧するか
身代金対応方針	攻撃者との接触、支払判断、警察・専門家相談の方針
外部専門家	フォレンジック、復旧、広報、法務の相談先
顧客説明	第一報、続報、最終報の文案

IPAの中小企業向けガイドライン第4.0版では、基本対策として「OSやソフトウェアを最新にする」「ウイルス対策」「パスワード強化」「共有設定の見直し」「バックアップ」「脅威や攻撃手口を知る」という情報セキュリティ6か条が示されています。特にバックアップは、事故後の復旧力に直結します。

7. 個人情報漏えい時の報告期限を、事故前にカレンダー化する

個人情報が関係する事故では、報告期限が極めて重要です。

個人情報保護委員会は、漏えい等報告について、速報は発覚日から3〜5日以内、確報は原則30日以内、不正な目的で行われたおそれがある場合は60日以内と案内しています。報告対象には、要配慮個人情報、財産的被害のおそれ、不正目的のおそれ、1,000人超の漏えい等が含まれます。

個人情報事故発覚後の期限管理表

時点	やること
発覚直後	事故対応記録票を作成し、個人情報の有無を確認
当日中	影響範囲、本人数、情報項目、原因仮説を整理
3〜5日以内	報告対象の場合、速報の提出を検討・実施
30日以内	確報を作成・提出
60日以内	不正目的のおそれがある場合の確報期限を管理
随時	本人通知、取引先報告、公表、再発防止策の更新

2025年10月1日以降、ランサムウェア事案による個人データの漏えい等またはそのおそれが発生した場合、共通様式により報告できる運用も案内されています。ランサムウェア時は、個人情報報告とサイバー被害報告が重なるため、事前に様式・報告先を確認しておくべきです。

プライバシーマーク付与事業者の場合は、PMK500上の事故等報告も確認が必要です。PMK500では、事故等として漏えい、紛失、滅失・き損、改ざん、目的外利用・提供、不正利用、開示等の求め等の拒否、これらのおそれまで含まれ、原則30日以内の報告や、重大類型では概ね3〜5日以内の速報が定められています。本人通知・公表、調査、注意・勧告、一時停止、取消しに関する制度上のリスクもあります。

8. 連絡網は「電話番号一覧」では足りない

事故対応の連絡網は、単なる電話番号一覧ではありません。誰が、どの場面で、どの内容を、どの順番で連絡するかを決めるものです。

社内連絡網

役割	担当	連絡内容
事故受付窓口	情報セキュリティ責任者、総務	第一報の受付、記録開始
経営判断者	社長、役員	業務停止、顧客説明、公表、費用判断
IT担当	情報システム、保守会社	隔離、ログ保全、復旧、原因調査
個人情報担当	個人情報管理責任者	漏えい報告、本人通知、台帳確認
営業責任者	営業部門	取引先への第一報、問い合わせ対応
広報担当	経営企画、総務	Web公表、メディア対応、FAQ
契約担当	法務、総務	委託先契約、事故報告条項、再委託確認
記録担当	総務、管理部門	時系列記録、議事録、証跡保管

社外連絡網

連絡先	目的
保守会社・MSP	技術調査、ログ保全、復旧支援
クラウド事業者	アクセスログ、管理者操作ログ、アカウント停止、証跡取得
委託先・再委託先	影響範囲確認、事故報告、調査協力
取引先・委託元	第一報、続報、最終報
個人情報保護委員会または権限委任先省庁	漏えい等報告
警察	犯罪性がある場合の相談・届出
JPCERT/CC、IPA等	技術的相談・届出
サイバー保険会社	保険適用、専門家手配
弁護士	紛争性、損害賠償、法的代理、訴訟対応
行政書士	行政機関向け提出文書、規程・契約・台帳整備支援
フォレンジック事業者	侵入経路調査、証拠保全、技術解析

IPAの中小企業向けインシデント対応資料では、顧客や消費者に関係する場合は受付専用窓口を開設し、被害状況を速やかに把握して対応すること、個人情報漏えいの場合は個人情報保護委員会、犯罪性がある場合は警察、ウイルス感染や不正アクセスの場合はIPAへ届け出ることが示されています。

9. 事故時の第一報は「早く・正確に・言い過ぎない」

事故時の第一報で最も重要なのは、すべてを確定してから連絡することではありません。むしろ、確定を待ちすぎると、取引先や顧客から「隠していた」と見られます。

一方で、事実確認前に「漏えいはありません」「影響はありません」と断定するのも危険です。後日訂正が必要になると、信用を大きく損ないます。

第一報では、次の5点を伝えるのが基本です。

項目	内容
何が起きたか	現時点で把握している事象
いつ発覚したか	発見日時、発覚経緯
現在の対応	隔離、停止、調査、外部専門家への相談等
影響の有無	確認中の範囲を明確にする
次回連絡	続報予定時刻、問い合わせ窓口

取引先向け第一報文案

件名：情報セキュリティインシデント発生の可能性に関する第一報

〇〇株式会社〇〇部　〇〇様

平素より大変お世話になっております。当社において、〇年〇月〇日〇時頃、当社が利用する〇〇システムに関し、情報セキュリティインシデントの可能性がある事象を確認いたしました。

現在、当社では、影響拡大を防止するため、関係する機器・アカウント・サービスの確認及び必要な隔離措置を行うとともに、外部専門家及び関係事業者と連携して原因及び影響範囲を調査しております。

現時点では、貴社情報への影響の有無について確認中です。判明した事実については、速やかに続報としてご報告いたします。

本件に関する当社窓口は以下のとおりです。担当部署：〇〇担当者：〇〇連絡先：〇〇次回のご報告予定：〇年〇月〇日〇時頃

ご心配とご迷惑をおかけしておりますことを、深くお詫び申し上げます。

10. 本人通知文案は、事故前に型を用意しておく

個人情報が関係する事故では、本人通知が必要になる場合があります。事故発生後にゼロから文案を作ると、表現が不正確になりやすく、二次被害防止の案内も不足しがちです。

本人通知文案

件名：個人情報に関するお知らせ

〇〇様

このたび、当社において、〇年〇月〇日、当社が管理する〇〇に関し、個人情報の漏えい又は漏えいのおそれがある事案を確認いたしました。

現時点で確認している内容は以下のとおりです。

項目	内容
発覚日時	〇年〇月〇日〇時頃
事案の概要	〇〇による不正アクセス／誤送信／紛失／クラウド共有設定ミス等
対象となる可能性のある情報	氏名、住所、メールアドレス、電話番号、取引情報等
対象となる可能性のある方	〇〇に該当するお客様
現在の対応	アカウント停止、アクセス遮断、外部専門家による調査、再発防止策の検討等
二次被害のおそれ	現時点で確認中／不審なメール・電話等にご注意ください
お客様へのお願い	不審な連絡、身に覚えのない請求、パスワード使い回しがある場合の変更等
問い合わせ窓口	〇〇

このたびは、多大なご心配とご迷惑をおかけしておりますことを、深くお詫び申し上げます。当社では、引き続き事実確認を進め、判明した内容について速やかにお知らせするとともに、再発防止策を講じてまいります。

個人情報事故の通知文では、原因、影響範囲、対象情報、二次被害のおそれ、本人へのお願い、問い合わせ窓口を明確にする必要があります。PMK500でも、事故等が発生した場合には、事故の概要、対象となる個人情報の項目、原因、二次被害又はそのおそれ等を本人に通知する事項として整理しています。

11. Web公表文は「謝罪文」ではなく「被害拡大防止の情報提供」

公表文は、謝罪だけでは足りません。顧客や取引先が何をすべきかを判断できる内容にする必要があります。

Web公表文案

件名：当社における情報セキュリティインシデントに関するお知らせ

当社は、〇年〇月〇日、当社が管理する〇〇システムにおいて、情報セキュリティインシデントの可能性がある事象を確認いたしました。

現在、当社では、関係するシステムの停止又は制限、外部専門家による調査、影響範囲の確認、再発防止策の検討を進めております。

現時点で確認している内容は以下のとおりです。

項目	内容
発覚日時	〇年〇月〇日
事案の概要	〇〇
影響を受けた可能性のある情報	〇〇
対象となる可能性のある方	〇〇
現在の対応	〇〇
二次被害防止のお願い	不審メール、なりすまし連絡、身に覚えのない請求等への注意
問い合わせ窓口	〇〇

今後、新たに公表すべき事項が判明した場合には、当社Webサイトにて速やかにお知らせいたします。関係者の皆様に多大なご心配とご迷惑をおかけしておりますことを、深くお詫び申し上げます。

IPAのインシデント対応資料でも、すべての関係者への通知が困難な場合や、インシデントの影響が広く一般に及ぶ場合は、時期・内容・対象を考慮してWebサイトやメディアを通じて公表すること、顧客・消費者に関係する場合は専用問い合わせ窓口を開設することが示されています。

12. 委託先・クラウド事業者との契約条項を事故前に見直す

事故時に委託先やクラウド事業者へ連絡しても、契約上の根拠がなければ、ログ提出、調査協力、再委託先確認、データ削除証明をすぐに求められないことがあります。

事故前に、次の条項を契約書・覚書・仕様書に入れておくべきです。

条項	目的
事故報告義務	漏えい確定前の「おそれ」「疑い」の段階で連絡を受ける
報告期限	例：認知後速やかに、重大事故は24時間以内等
調査協力	ログ、証跡、原因、影響範囲の確認に協力させる
再委託管理	再委託先にも同等義務を負わせる
データ返還・削除	契約終了時や事故時の情報残存を防ぐ
バックアップ・復旧	復旧責任、復旧目標、バックアップ範囲を確認する
クラウドログ	アクセスログ、管理者操作ログ、共有設定変更ログの取得可否
通知・公表協力	顧客説明、本人通知、公表文作成に必要な情報を提供させる
生成AI利用制限	委託業務で秘密情報・個人情報を生成AIに入力する範囲を制限する

ただし、発注者側が委託先へ高度なセキュリティ要求を追加する場合、その費用や工数を一方的に押し付けることは避けるべきです。公正取引委員会・中小企業庁の下請法ガイドブックでも、ISO認証取得を要請し、その取得費用を考慮せず一方的に下請代金を据え置く事例は、買いたたきの観点で問題になり得るものとして示されています。セキュリティ要求は、仕様・費用・納期・協議記録とセットで管理することが実務上重要です。

13. 証拠保全手順を決めておかないと、原因調査ができない

サイバー事故では、慌てて対応した結果、証拠を消してしまうことがあります。

やってはいけない初動	問題
感染端末をすぐ初期化する	侵入経路やマルウェアの痕跡が消える
ログを削除する	影響範囲の説明ができない
脅迫文を閉じて保存しない	攻撃者情報や時刻の証拠が残らない
メールを削除する	フィッシング経路の確認ができない
クラウド設定を戻すだけで記録しない	誤公開期間や閲覧有無が確認できない
委託先の口頭説明だけで済ませる	後日の説明根拠が残らない

IPAの中小企業向けインシデント対応資料では、事実関係を裏付ける情報や証拠を保全し、必要に応じてフォレンジック調査を行うこと、ログ、パソコン、サーバ、ネットワーク機器等の調査を行うことが示されています。復旧後は根本原因を分析し、技術的対策、ルール策定、教育、体制整備、運用改善等の再発防止策を検討・実施することも重要です。

証拠保全リスト

証拠	保存方法
画面表示	スクリーンショット、写真
脅迫文	画面、ファイル、URL、時刻を記録
メール	ヘッダー情報を含めて保存
ログ	アクセスログ、認証ログ、管理者操作ログ
端末	電源操作前に専門家へ相談。隔離状態で保全
クラウド設定	設定変更前の状態をスクリーンショットで保存
連絡記録	電話、メール、チャット、会議メモを時系列で保存
判断記録	誰が、いつ、何を判断したかを議事録化

14. 事故対応記録票は、後日の説明責任を支える

事故後に取引先や顧客から問われるのは、「なぜ起きたか」だけではありません。

「いつ気づいたのか」「いつ止めたのか」「誰に連絡したのか」「なぜそのタイミングで公表したのか」「再発防止策はいつ実施したのか」

これに答えるためには、時系列記録が必要です。

事故対応記録票の例

時刻	事実・対応	担当	証跡	次の対応
9:10	社員Aが不審な暗号化画面を確認	社員A	画面写真	責任者へ報告
9:20	情報セキュリティ責任者が端末隔離を指示	責任者	チャット記録	保守会社へ連絡
9:45	保守会社へ調査依頼	IT担当	メール	ログ保全
10:30	社長へ第一報	責任者	議事メモ	対応体制立上げ
12:00	影響可能性のある顧客情報を確認中	個人情報担当	台帳	報告要否確認
15:00	主要取引先へ第一報	営業責任者	送信メール	続報予定設定

事故対応記録は、社内反省のためだけではありません。取引先説明、行政報告、保険請求、再発防止、規程改定、委託先責任確認の基礎資料になります。

15. 事故前に準備すべき「通知先別」文案

取引先向け

目的は、取引先業務への影響を判断してもらうことです。技術用語を並べるより、対象業務、対象情報、今後の対応を明確にします。

書くべき内容	注意点
対象となる取引・業務	どの契約・案件に関係するか
影響可能性	確定事項と確認中事項を分ける
現在の対応	調査、隔離、復旧、再発防止
取引先への依頼	不審メール注意、パスワード変更、問い合わせ集約等
続報予定	いつ次の報告をするか

顧客・本人向け

目的は、二次被害防止と不安の軽減です。

書くべき内容	注意点
事故の概要	事実を分かりやすく
対象情報	氏名、連絡先、決済情報等を具体化
二次被害のおそれ	不審メール、なりすまし、請求等
顧客にお願いする対応	パスワード変更、問い合わせ先、注意事項
問い合わせ窓口	専用窓口を設ける

従業員向け

事故時は、社内の不用意な発信やSNS投稿もリスクです。

書くべき内容	注意点
社内周知	事実確認中であること
禁止事項	SNS投稿、外部への個別回答、端末操作
報告ルート	問い合わせをどこへ集約するか
顧客対応	想定問答に従うこと
証拠保全	メール・画面・端末を勝手に削除しないこと

16. 事故時FAQを準備しておく

問い合わせが増えると、担当者ごとに回答がぶれます。事故前にFAQの型を作っておくと、混乱を抑えられます。

FAQ例

質問	回答例
私の情報は漏えいしましたか	現在、対象範囲を調査中です。判明次第、対象となる方へ速やかにご連絡します。
どの情報が対象ですか	現時点で確認中です。対象となる可能性のある情報は、氏名、メールアドレス、電話番号等です。
クレジットカード情報は含まれますか	当社での保管有無及び影響範囲を確認中です。確認結果は続報でお知らせします。
何をすればよいですか	不審なメール、電話、SMS、身に覚えのない請求にご注意ください。必要に応じてパスワード変更をお願いします。
再発防止策は何ですか	原因調査の結果に基づき、アクセス制御、監視、教育、委託先管理等を見直します。
問い合わせ先はどこですか	専用窓口〇〇までご連絡ください。

FAQは、断定を避けすぎると不誠実に見えます。一方で、未確認事項を断定すると後で訂正が必要になります。確定事項、確認中事項、今後の予定を明確に分けることが重要です。

17. 事故前にやっておくべき机上訓練

文書を作っただけでは、事故時に動けません。年1回でよいので、机上訓練を実施してください。

訓練シナリオ例

シナリオ1：ランサムウェア月曜朝、共有フォルダ内のファイルが開けず、身代金要求画面が表示された。顧客名簿が保存されていた可能性がある。

シナリオ2：クラウド誤公開営業担当者が、クラウドストレージの共有リンクを「リンクを知っている全員が閲覧可」にしていた。取引先資料と個人情報が含まれていた可能性がある。

シナリオ3：委託先事故給与計算の委託先から、不正アクセスの疑いがあると連絡を受けた。従業員情報が含まれている可能性がある。

シナリオ4：生成AI利用事故従業員が顧客情報を含む契約相談内容を生成AIに入力していたことが判明した。

訓練で確認すること

確認項目	見るべきポイント
第一報	誰が誰に連絡するか
経営判断	どの時点で社長が判断するか
技術対応	何を止め、何を残すか
個人情報	報告対象か、本人通知が必要か
取引先対応	第一報をいつ出すか
公表	Web公表が必要か
証拠保全	ログ・画面・メールを残せるか
復旧	バックアップから戻せるか
再発防止	契約・規程・教育の見直しにつながるか

IPAのインシデント対応資料でも、事故対応の目的は、被害と影響範囲を最小限に抑え、迅速に復旧し、再発を防止することで事業継続を確保することとされています。

18. 事故前の準備を90日で整える実務ロードマップ

第1段階：30日以内に「見える化」する

まず、重要情報と連絡先を把握します。

作業	成果物
重要業務の洗い出し	業務停止影響一覧
個人情報の洗い出し	個人情報管理台帳
クラウド利用の確認	クラウド/SaaS台帳
委託先の確認	委託先台帳
管理者権限の確認	アカウント・権限台帳
緊急連絡先の確認	社内外連絡網

第2段階：60日以内に「文書化」する

次に、事故時に使う文書を作ります。

文書	内容
インシデント対応規程	検知、初動、報告、公表、復旧、再発防止
初動対応チェックリスト	事故直後の行動表
個人情報漏えい対応手順	報告要否、本人通知、公表、記録
通知文案	取引先、本人、従業員、Web公表
委託先事故連絡書	委託先から情報を集める書式
証拠保全手順	ログ、端末、メール、クラウド証跡の保存

第3段階：90日以内に「訓練」する

最後に、実際に動かします。

訓練	確認内容
第一報訓練	1時間以内に社内連絡できるか
ランサムウェア机上訓練	隔離、証拠保全、バックアップ保護
個人情報漏えい訓練	3〜5日以内の速報判断
取引先通知訓練	第一報、続報、最終報の文案確認
復旧訓練	バックアップから戻せるか

19. 社長が最後に確認すべき5つの質問

社長は、細かなログ解析をする必要はありません。確認すべきことは次の5つです。

1. 事故が起きたとき、最初に誰へ連絡するか決まっているか

2. システム停止・公表・顧客通知を誰が判断するか決まっているか

3. 個人情報漏えい等報告の期限を守れる体制があるか

4. 取引先・本人・Web公表の文案が準備されているか

5. バックアップから実際に復旧できることを確認しているか

この5つが曖昧な会社は、事故時に「技術対応」はできても、「信用を守る対応」ができません。

20. まとめ：信用を守るのは、事故後の言い訳ではなく事故前の準備

サイバー事故は、完全にゼロにできません。しかし、信用を失うリスクは、事故前の準備で大きく下げられます。

必要なのは、分厚いマニュアルではありません。

• 事故時に動けるインシデント対応規程

• 1枚で使える初動チェックリスト

• 社内外の連絡網

• 個人情報漏えい対応手順

• 取引先・本人・Web公表の通知文案

• 証拠保全手順

• クラウド・委託先・個人情報の台帳

• 年1回の机上訓練

これらが整っていれば、事故時に「確認中です」「次回は何時に報告します」「この範囲で調査しています」と、落ち着いて説明できます。それが、会社の信用を守ります。

山崎行政書士事務所では、行政書士として対応できる範囲で、情報セキュリティ基本方針、インシデント対応規程、個人情報漏えい対応手順、クラウド/SaaS台帳、委託先管理台帳、取引先通知文案、本人通知文案、事故対応記録票、委託契約・個人情報取扱覚書等の整備を支援しています。

紛争性のある損害賠償交渉、訴訟対応、法的代理、専門的なフォレンジック調査、脆弱性診断、SOC運用等が必要な場合は、弁護士、IT専門事業者、情報処理安全確保支援士等と連携し、事故前から「説明できる危機管理体制」を構築します。