- ITインシデント5類型ごとの始末書の書き方・記載項目がわかる
- 個人情報保護法2022年改正対応の対外報告フロー（速報3〜5日・確報30日ルール）がわかる
- ポストモーテム・ヒヤリ・ハット報告との使い分けとキャリアへの影響対策がわかる
ITインシデント5類型
ITインシデントの始末書は、インシデントの種別によって記載すべき事実・技術的根拠・再発防止策の焦点が大きく変わります。 まず自社インシデントがどの類型に当たるかを確認し、対応する書き方ガイドと本テンプレートを活用してください。
| 類型 | 代表例 | 始末書で特に重要な記載事項 | 外部報告義務の有無 |
|---|---|---|---|
| 情報漏洩（個人情報・社外秘） | メール誤送信・USBメモリ紛失・クラウド設定ミス | 漏洩件数・情報の種別・影響を受けた本人数・経路 | 個人情報保護委員会・本人通知（義務） |
| サーバ・サービス障害 | DB障害・ミドルウェア設定ミス・ハードウェア故障 | 停止時間・影響ユーザー数・SLA未達状況・復旧手順 | 監督官庁・顧客SLA報告（契約による） |
| 不正アクセス・サイバー攻撃被害 | 標的型メール・ランサムウェア・不正ログイン | 侵入経路・被害範囲・封じ込め措置・警察届出状況 | 警察・NISC・監督官庁（業種による） |
| データ消失・誤削除 | 本番DBの誤操作・バックアップ未取得・ランサムウェア暗号化 | 消失データの種別・件数・復元可否・バックアップ有無 | 個人情報を含む場合は個情委報告 |
| サービス停止（DDoS等） | DDoS攻撃・CDN障害・DNS障害 | 停止時間・原因（外部/内部）・防御体制の評価・CDN/WAF状況 | 重要インフラ事業者は政府機関へ報告義務 |
情報漏洩（個人情報・社外秘）
情報漏洩インシデントの始末書では、漏洩した情報の正確な特定が最も重要です。 個人情報保護法第26条に基づく報告義務が発生する場合、始末書に記載する事実内容と個人情報保護委員会への報告内容が整合していなければなりません。
- 漏洩情報の種別: 氏名・住所・メールアドレス・クレジットカード情報・健康情報等の区別を明記する
- 漏洩件数: 影響を受ける可能性がある個人の人数を概数でも記載する（ログから算出する）
- 漏洩経路: メール誤送信・USBメモリ・クラウドストレージの公開設定ミス・印刷物の紛失等を特定する
- 発見から報告までの経緯: 発見日時・発見者・社内報告ルートのタイムラインを記載する
- 二次被害防止措置: アクセスブロック・パスワードリセット・本人通知の実施状況を記載する
社外秘情報（営業秘密・技術情報）の漏洩については、不正競争防止法上の営業秘密に該当するかどうかを法務部門に確認してから始末書を作成してください。 特定の取引先・競合企業への流出が疑われる場合は弁護士に相談の上、始末書の文面を決定することを推奨します。
サーバ・サービス障害
サーバ・サービス障害の始末書では、停止時間・影響範囲・原因の技術的記述の3点が核心です。 SLA（サービスレベル合意）に基づくペナルティが発生する場合は、顧客への報告書と始末書の内容を必ず突き合わせてください。
- 障害発生時刻〜復旧完了時刻: 分単位で記載し、ダウンタイムを明示する
- 影響を受けたサービス・ユーザー数: システム名・エンドユーザー数・業務への影響（売上ロス・業務停止時間）を記載する
- 根本原因（RCA: Root Cause Analysis）: ハードウェア故障・設定変更ミス・容量超過等を技術的に特定する
- 一時対応と恒久対応の区別: 「とりあえず再起動で復旧」と「根本対策としてのパッチ適用・設定変更」を明確に分けて記載する
不正アクセス・サイバー攻撃被害
不正アクセス被害の始末書は、セキュリティインシデントとしての封じ込め措置の記録が特に重要です。 IPA 情報セキュリティインシデント対応ガイドライン では、 初動対応（検知・封じ込め・根絶・復旧・教訓）のフェーズ別に記録を残すことを推奨しています。
- 攻撃の種別: 標的型メール・ランサムウェア・SQLインジェクション・不正ログイン・ゼロデイ脆弱性悪用等を特定する
- 侵入経路と侵害範囲: どのシステムが侵害されたか・どのアカウントが悪用されたかをログ根拠で記述する
- 警察・NISC・CERTへの届出状況: 不正アクセス禁止法に基づく被害届の提出有無を記載する
- 封じ込め措置: ネットワーク遮断・アカウント停止・影響システムの隔離等の措置と実施日時を記載する
- フォレンジック調査の実施有無: 外部専門機関による調査を実施したかどうかを記載する
データ消失・誤削除
データ消失・誤削除インシデントでは、復元可否の判断とバックアップ体制の評価が始末書の核心になります。 個人情報を含むデータが消失した場合は、個人情報保護委員会への報告義務が発生する可能性があります。
- 消失データの種別・件数: DB名・テーブル名・レコード件数・含まれる個人情報の種別を記載する
- 消失の原因: 操作ミス（誰が・どのコマンドを実行したか）・ランサムウェア暗号化・ハードウェア障害等を特定する
- バックアップの有無と復元結果: 最終バックアップ日時・復元試行の結果・復元できなかったデータの範囲を記載する
- 本番環境への直接アクセス権限の見直し: 誤操作防止のためのアクセス制御強化を再発防止策に盛り込む
サービス停止（DDoS等）
DDoS攻撃等によるサービス停止では、外部攻撃の事実と自社の防御体制の評価を客観的に記述することが重要です。 外部攻撃が主因の場合でも、WAF・CDN・帯域制御等の防御措置が不十分だったと判断される場合は、その点について始末書に記載する必要があります。
- 攻撃の規模・種別: 攻撃トラフィック量（Gbps/pps）・攻撃手法（SYN flood・HTTP flood等）をログ根拠で記載する
- 既存防御措置の評価: CDN・WAF・帯域制御・IPブロックの実施状況と有効性を評価する
- サービス停止時間と影響: エンドユーザーへの影響・売上への影響・取引先への影響を記載する
- 今後のDDoS対策: Anycastネットワーク・スクラビングセンター活用・クラウドDDoS防御サービス導入等の具体策を記載する
個人情報漏洩時の対外報告フロー
2022年4月施行の改正個人情報保護法により、個人情報の漏洩等が発生した場合の報告義務と本人通知義務が大幅に強化されました。 始末書を作成する前に、以下の対外報告フローを確認してください。
個人情報保護委員会への報告（2022改正対応）
個人情報保護法第26条 （2022年4月施行）では、 以下の要件に該当する漏洩等が発生した場合、個人情報保護委員会への報告が義務付けられています。
- 要配慮個人情報（病歴・障害・犯罪歴等）が含まれる場合
- 財産的被害が生じるおそれがある場合（クレジットカード情報等）
- 不正の目的で行われたおそれがある場合（不正アクセス等）
- 1,000件を超える個人情報が対象となる場合
| 報告の種類 | 提出期限 | 記載すべき主な内容 |
|---|---|---|
| 速報 | 事態を知った日から3〜5日以内 | 発生日時・概要・現在判明している範囲での被害状況・対応状況 |
| 確報 | 事態を知った日から30日以内（不正アクセス等は60日） | 漏洩情報の種別・件数・原因・再発防止策・本人通知の実施状況 |
報告は 個人情報保護委員会の専用報告フォーム から行います。 速報・確報の両方が義務であることに注意してください。 義務違反には50万円以下の罰則が適用される場合があります。
本人通知義務
報告義務対象のインシデントでは、本人への通知も原則として義務となります。 通知が困難な場合は、本人が閲覧できる環境への公表で代替できますが、その旨を個人情報保護委員会への確報に記載する必要があります。
- 通知内容: 発生した事態の概要・漏洩した個人情報の項目・原因・二次被害防止のために取れる措置・問い合わせ先
- 通知方法: メール・書面・電話等。連絡先不明の場合はウェブサイト公表で代替
- 通知時期: 速報と並行してできるだけ早期に実施する
監督官庁への報告
業種によっては、個人情報保護委員会への報告に加えて、所管官庁への報告義務が課される場合があります。
| 業種 | 報告先 | 根拠法令 |
|---|---|---|
| 金融機関（銀行・証券・保険） | 金融庁・財務局 | 銀行法・金融商品取引法等 |
| 医療機関・介護事業者 | 厚生労働省・都道府県 | 医療法・介護保険法等 |
| 通信事業者・電力・ガス等重要インフラ | 総務省・経産省・内閣サイバーセキュリティセンター（NISC） | サイバーセキュリティ基本法・電気通信事業法等 |
| 教育機関 | 文部科学省・都道府県教育委員会 | 学校教育法・関連ガイドライン |
始末書の5W1H記載項目
ITインシデント始末書に記載すべき事項を5W1H形式で整理すると、漏れを防ぎやすくなります。 以下の各項目を本テンプレートの該当箇所に沿って埋めてください。
| 項目 | 記載すべき内容 | ITインシデント特有の注意点 |
|---|---|---|
| When（いつ） | インシデント発生日時・検知日時・報告日時 | ログの時刻はUTC/JSTを明記。タイムゾーンの混在に注意 |
| Where（どこで） | 発生したシステム名・サーバ・環境（本番/ステージング） | クラウドの場合はリージョン・AZ名も記載する |
| Who（誰が） | 操作者・発見者・報告者の役職・氏名 | 委託先・外部ベンダーが関与している場合は企業名も記載 |
| What（何が） | 発生した事象・影響を受けたデータ・システム | 影響件数・データ量を数値で記載する。「多数」「一部」は不可 |
| Why（なぜ） | 直接原因・根本原因（RCA） | 5Whyで掘り下げる。「オペレーションミス」で止めず、なぜミスが起きたかまで分析する |
| How（どのように） | 発生から復旧までの経緯・実施した措置 | タイムライン形式（HH:MM〜HH:MM 何をした）で記載すると明確になる |
再発防止策の書き方
ITインシデント始末書で最も評価される部分が再発防止策です。 「気をつけます」「確認を徹底します」といった抽象的な表現は、技術的インシデントでは特に不十分とみなされます。 以下の3層構造で再発防止策を記述してください。
1層：技術的対策（即時〜1か月以内）
- パッチ適用・脆弱性修正のバージョンと適用予定日を明記する
- アクセス制御の変更内容（誰のアクセス権を剥奪・縮小するか）を具体的に記載する
- 監視アラートの追加・閾値変更の内容を記載する
- バックアップ取得頻度・保存先の変更を記載する
2層：プロセス・運用対策（1〜3か月以内）
- 変更管理プロセス（Change Management）の見直し内容を記載する
- 本番環境操作の承認フロー・ダブルチェック体制の導入を記載する
- インシデント対応手順書（Runbook）の整備・更新を記載する
- 外部委託先のセキュリティ評価・契約条件の見直しを記載する
3層：組織・文化対策（3〜6か月以内）
- 全従業員向けセキュリティ研修の実施計画を記載する
- インシデント対応訓練（レッドチーム演習・机上訓練）の実施を記載する
- ポストモーテム文化の導入・ヒヤリ・ハット報告制度の整備を記載する
- CSIRT（コンピュータセキュリティインシデント対応チーム）の設置・強化を記載する
上司・顧客への謝罪文添付
ITインシデントでは、社内への始末書と並行して顧客・取引先・株主への対外謝罪文が必要になる場合があります。 始末書と謝罪文は目的・読み手が異なるため、別文書として作成してください。
| 文書の種類 | 主な読み手 | 重点を置く内容 | トーン |
|---|---|---|---|
| 始末書 | 社内（上司・人事・経営層） | 事実・原因・再発防止策・誓約 | 内省・反省・技術的詳細 |
| 顧客向け謝罪文 | 被害を受けた顧客・取引先 | 謝罪・影響範囲・二次被害防止策・問い合わせ先 | 誠実・平易・具体的な対応策 |
| プレスリリース | メディア・一般公衆・株主 | 事案の概要・現在の対応状況・問い合わせ先 | 客観的・正確・過大/過少評価なし |
顧客向け謝罪文には、「現時点で判明していること」と「調査中・未確認のこと」を明確に区別して記載することが重要です。 調査段階での不確かな情報を断定的に書くと、後の訂正・修正で信頼を損なうリスクがあります。
業界特化条項のNG/OK比較
ITインシデント始末書には、業界ごとに書いてはいけない表現・必ず書くべき表現があります。 以下のNG/OK比較表を参考に、自社の始末書を見直してください。
| 項目 | NG表現の例 | NG理由 | OK表現の例 |
|---|---|---|---|
| 影響件数 | 「一部の顧客情報が漏洩した」 | 件数が不明確。個人情報保護委員会報告と乖離する | 「顧客情報○○件（氏名・メールアドレス）が漏洩した」 |
| 原因記述 | 「担当者の不注意により発生した」 | 技術的根本原因の分析がなく、再発防止に繋がらない | 「アクセス制御設定の見直し漏れにより、外部からの読み取りが可能な状態になっていた」 |
| 責任の記述 | 「全責任は私にある」 | 組織的・技術的問題を個人責任に矮小化する。求償リスクも高まる | 「○○の対応において注意義務を怠った点について責任を認める」 |
| 再発防止策 | 「今後はセキュリティに気をつける」 | 具体性ゼロ。IPA等の基準を満たさない | 「2026年6月末までにWAFを導入し、不正アクセス検知アラートを設定する」 |
| 外部報告状況 | （記載なし） | 個人情報保護委員会への報告義務を果たしたか不明 | 「2026年○月○日に個人情報保護委員会へ速報を提出済み」 |
| ベンダー責任 | 「ベンダーの脆弱性が原因で当社に過失はない」 | 委託元の監督義務（個情法25条）を無視している | 「○○社製ミドルウェアの既知脆弱性が悪用されたが、パッチ適用管理体制に不備があった」 |
IT業界の残業代・みなし残業の確認
インシデント対応で過重労働が発生した場合、未払い残業代が生じている可能性があります。過去3年分を概算できます。
残業代を計算するよくある質問
ITインシデント始末書と通常の始末書は何が違う？
個人情報漏洩が起きた場合、会社への始末書提出と個人情報保護委員会への報告はどちらが先？
始末書に「弊社には原因がない」と書いてよい？
インシデント始末書にログ・スクリーンショットは添付すべき？
始末書を書いたら損害賠償を請求される？
派遣社員・業務委託エンジニアが起こしたインシデントの場合、誰が始末書を書く？
DDoS攻撃によるサービス停止は始末書の対象になる？
ヒヤリ・ハット報告書とインシデント始末書はどう使い分ける？
ポストモーテム（障害振り返り）と始末書は同じ？
始末書を書いた後のキャリアへの影響は？
複数のシステムに波及した大規模インシデントの場合、始末書は1枚でよい？
汎用版・遅刻・無断欠勤・交通事故対応の始末書テンプレートはこちら
始末書テンプレート（汎用5パターン） では、労基法上の位置づけ・違法な強要への対処・懲戒処分との関係を解説しています。
参考文献・出典
本ページの内容は以下の公的情報源に基づき作成しています（2026-05-12 確認時点）。