ITインシデントの始末書（白紙3パターン）
上のダウンロード欄の Word に、白紙が3パターン入っています。各パターンの記入例（人物・会社・日付・数字は架空）の全文は、このページで「この文面をコピー」できます。会社に所定の様式があるときは、その様式を優先してください。
パターン1：情報漏えい・不正アクセス
情報が外に出たとき、または不正なアクセスを受けたときの始末書です。技術的な事実は、ログで確認できたものだけを書きます。
パターン1：情報漏えい・不正アクセス（記入例）の全文
始 末 書
令和8年10月21日
基盤運用部長 後藤 誠 殿
所属：サンプルシステムズ株式会社 運用課
氏名：前田 直樹 印
件名 情報の漏えい・不正アクセスに関する始末書
このたびの下記の件について、事実と再発防止策を報告します。
発生日時（推定でよい。推定と書く） 令和8年10月18日（日曜日）2時頃（ログから推定）
検知日時・検知の経緯 令和8年10月19日（月曜日）9時15分。監視ツールのアラートで、深夜の大量のログイン失敗に気づいた。
対象のシステム 顧客向け管理画面（本番環境）
影響の範囲（情報の種類・件数） 不正にログインされたアカウント：2件（調査時点）。閲覧された可能性のある情報：当該2社の会社名と担当者の氏名。ほかの影響は調査中。
実施済みの対応（遮断・パスワードの変更・報告） 9時30分に該当のアカウントを停止し、パスワードを再設定した。10時に、上司と情報セキュリティの担当へ報告した。13時に、該当の2社へ経緯を連絡した。
経過（時刻順・事実のみ）
10/18 2:00頃 不審なログインの試行が始まる（ログによる）
10/19 9:15 アラートを受け、ログを確認
10/19 9:30 該当のアカウントを停止
10/19 10:00 上司へ報告
原因 管理画面のログインに2段階認証を設定していなかった。ログインの失敗の回数に上限がなかった。
再発防止策（実行する内容・開始時期）
・管理画面のログインに2段階認証を必須にする（運用課／令和8年10月30日まで）
・ログインの失敗が続いたアカウントを、自動で一時停止する設定にする（運用課／令和8年11月13日まで）
上記のとおり、事実に相違ありません。
再発防止策を実行してまいります。
以上
白紙の欄：発生日時・検知日時・検知の経緯・対象のシステム・影響の範囲・実施済みの対応・経過・原因・再発防止策（白紙のWordの1ページ目）
書かないこと：ログで確認できていない範囲を、確認できたように書かない。
パターン2：障害・サービス停止
システムの障害やサービスの停止があったときの始末書です。発生から復旧までの時刻を分単位で書く欄があります。
パターン2：障害・サービス停止（記入例）の全文
始 末 書
令和8年10月22日
サービス運用部長 近藤 亮 殿
所属：テスト情報サービス株式会社 基盤課
氏名：藤田 美穂 印
件名 障害・サービス停止に関する始末書
このたびの下記の件について、事実と再発防止策を報告します。
発生日時・復旧日時（曜日も書く）
発生：令和8年10月20日（火曜日）14時10分
復旧：令和8年10月20日（火曜日）15時25分
検知の経緯 14時12分に、監視ツールのアラートで、ログイン画面が応答しないことに気づいた。
対象のシステム サービスA（ログインと注文の画面）
影響の範囲（停止した時間・利用者数） 75分間、ログインと注文の画面が利用できなかった。影響を受けた利用者は約1,200名（アクセスログの集計）。
実施済みの対応 14時20分に原因の設定変更を特定し、14時50分に変更前の設定へ戻す作業を開始した。15時25分に復旧を確認した。
経過（時刻順・事実のみ）
14時10分 設定の変更を本番に反映
14時12分 アラートを受け、障害を確認
14時20分 原因の設定変更を特定
15時25分 復旧を確認
原因 設定を変更するとき、変更後の設定ファイルの書き方に誤りがないかを確認する手順がなく、誤りのまま本番に反映した。
再発防止策（実行する内容・開始時期）
・設定の変更の前に、別の環境で設定ファイルを検証する手順を作る（基盤課／令和8年10月30日まで）
・本番への反映は、2人で確認してから行う（基盤課／令和8年10月23日から）
上記のとおり、事実に相違ありません。
再発防止策を実行してまいります。
以上
白紙の欄：発生日時・復旧日時・検知の経緯・対象のシステム・影響の範囲・実施済みの対応・経過・原因・再発防止策（白紙のWordの2ページ目）
書かないこと：原因が特定できていないときは、特定できていないと書き、推測を原因の欄に書かない。
パターン3：データ消失
データを誤って消した、または消えたときの始末書です。復元できた範囲とできなかった範囲を分けて書きます。
パターン3：データ消失（記入例）の全文
始 末 書
令和8年10月26日
開発部長 村上 拓也 殿
所属：デモクラウド株式会社 開発課
氏名：岡田 早苗 印
件名 データの消失に関する始末書
このたびの下記の件について、事実と再発防止策を報告します。
発生日時（曜日も書く） 令和8年10月23日（金曜日）16時20分頃
発見の経緯 令和8年10月23日（金曜日）16時40分に、利用者から注文履歴が表示されないという問い合わせがあり、データベースを確認して気づいた。
対象のデータ（システム名・種類・件数） 本番のデータベースの「注文履歴」。保存期間内の記録の約5,000件（前日以降の注文を含む）
発生の状況（実行した操作・事実のみ） テスト用の画面だと思って開いていた画面が本番の画面で、テスト用のデータを消すつもりで注文履歴の削除の操作を実行し、保存期間内の記録を誤って消した。
復元の状況（バックアップの日時・復元できた範囲） 前日（令和8年10月22日）2時のバックアップから、17時30分までに4,965件を復元した。前日2時以降の35件は復元できなかった。
影響 復元できなかった35件は、注文確認のメールから手で登録し直す必要がある。復元が終わるまでの約1時間、該当の利用者の注文履歴が表示されなかった。
実施済みの対応 16時50分に、上司へ報告した。17時に、削除の操作を行ったユーザーの権限を停止した。
原因 本番とテストの画面の見た目が同じで、本番の画面であることが分かる表示がなかった。本番のデータを削除する操作に、確認の手順がなかった。
再発防止策（実行する内容・開始時期）
・本番の画面に、色の違う帯と「本番」の表示を付ける（開発課／令和8年11月6日まで）
・本番のデータを削除する操作は、2人の承認を必要にする（開発課／令和8年11月13日まで）
上記のとおり、事実に相違ありません。
再発防止策を実行してまいります。
以上
白紙の欄：発生日時・発見の経緯・対象のデータ・発生の状況・復元の状況・影響・実施済みの対応・原因・再発防止策（白紙のWordの3ページ目）
書かないこと：復元できなかった範囲を、確認が終わる前に少なく書かない。
個人情報の漏えいがあったとき
個人情報の漏えいなどが起きたときは、始末書とは別に、国への報告が要る場合があります。報告先は原則として個人情報保護委員会で、委員会の権限が事業所管大臣に委任されている業種では、委任を受けた省庁です（委任されている業種でも、漏れたのが自社の従業員の情報や株主の情報のときは委員会）。報告が要るかどうかは、事態の内容で決まり、会社が判断します。始末書の欄には、その判断を書きません。報告の期限は、次のとおりです。
- 施行規則第8条第1項：報告対象事態を知った後、「速やかに」報告する（ e-Gov 個人情報の保護に関する法律施行規則（第8条） ）
- 同条第2項：事態を知った日から30日以内（不正の目的のおそれがある第3号の事態は60日以内）に報告する
- 委員会のページは、この2回の報告を「速報」「確報」と呼び、速報は「発覚日から、3〜5日以内」、確報は「発覚日から、30日以内」と案内している（ 個人情報保護委員会「漏えい等報告について」 ）。3〜5日は委員会の案内で、条文の期限ではない
報告対象事態の4つの類型と条文の原文は、顛末書のページにあります。
技術的な事実の欄の書き方
| 欄 | 書くこと |
|---|---|
| 発生日時・検知日時 | 起きた時刻と、気づいた時刻を分けて書く。ログの時刻は、日本時間かUTCかも書く |
| 対象のシステム | システム名・環境（本番か、検証か）・サーバー名など |
| 影響の範囲 | 件数・ユーザー数・データの量・停止した時間などを、確認できた数字で。確認が終わっていないものは、確認中と書く |
| 実施済みの対応・経過 | 時刻の順に、何をしたかを書く。実施済みには時刻を入れる |
| 原因 | 分かっていることから書く。特定できていないときは、特定できていないと書く |
再発防止策の書き方
「気をつけます」「確認を徹底します」だけでは、何を変えるのかが読む人に伝わりません。次の3つの層に分けると、書きやすくなります。いずれも、実行する内容と開始する時期を1行に入れます。
- 技術的な対策：パッチの適用、アクセス権限の変更、監視アラートの追加、バックアップの取得方法の変更など
- 運用の対策：変更管理の手順の見直し、本番環境を操作するときの承認の追加、手順書の更新など
- 組織の対策：研修、訓練、委託先との契約条件の見直しなど
始末書と顧客・取引先への報告の違い
ITインシデントでは、社内に出す始末書とは別に、顧客・取引先に出す文書が要ることがあります。次の表は、実務での一般的な使い分けで、法令上の定義ではありません。
| 書類 | 主な読み手 | 主に書くこと |
|---|---|---|
| 始末書 | 社内（上司・人事・管理部門） | 事実・原因・影響・対応・再発防止策 |
| 顧客・取引先への報告 | 影響を受けた顧客・取引先 | おわび・影響の範囲・今後の対応・問い合わせ先。顛末書のページに、取引先向けの白紙がある |
調査の途中で、確認できていないことを断定して書くと、あとで訂正が要ります。「現時点で分かっていること」と「確認中のこと」を分けて書いてください。
始末書の書き方の全体と、会社が始末書を求める根拠（主に就業規則）は、始末書のページにあります。署名の前に迷うときは、総合労働相談コーナーや弁護士に相談してください（ 厚生労働省「総合労働相談コーナーのご案内」 ）。
よくある質問
ITインシデントの始末書は、通常の始末書と何が違いますか？
個人情報の漏えいが起きたとき、個人情報保護委員会への報告の期限は？
始末書に「弊社に原因はない」と書いてよいですか？
始末書に、ログやスクリーンショットを添付してよいですか？
始末書を出すと、損害賠償を求められますか？
始末書の提出を拒否できますか？
参考文献・出典
本ページの内容は以下の公的情報源に基づき作成しています（2026-10-13 確認時点）。
このテンプレートは役に立ちましたか？
残り 300 字
返信はできません。お名前・メールアドレス・電話番号など、個人がわかることは書かないでください。返事が必要なときはお問い合わせから送ってください。
探している書式が見つからないときは、リクエストを送ってください。