紛失・故障時のインシデント対応の実務ガイド｜社内ルールと責任分界を設計する

# 紛失・故障時のインシデント対応の実務ガイド｜社内ルールと責任分界を設計する

会社のスマートフォンやPCが見当たらない、落として画面が割れた、電源が入らない、バッテリーが膨らんだ。このような連絡を「端末交換の依頼」だけで処理すると、認証情報や顧客データの漏えい、安全事故、証拠の消失、回線の不正利用を見落とします。一方、すべてを重大事故として扱えば、現場が報告をためらい、初動が遅れます。

必要なのは、紛失・盗難・所在不明・論理故障・物理破損・電池異常を入口で区別し、情報、アクセス、安全、事業継続の四つの影響を評価する社内ルールです。本稿では、従業員、上長、サービスデスク、セキュリティ、個人情報保護担当、総務・資産管理、通信管理、法務、広報の責任分界を、初動から復旧・再発防止まで具体化します。

1．「紛失」と「故障」を受付時点で分類する

一つの申請フォームにまとめても、分類は分けます。

•紛失：保持者が端末の場所を特定できない
•盗難：第三者が持ち去った疑いまたは事実がある
•一時所在不明：社内、交通機関、宿泊先など候補が限定される
•論理故障：起動不能、暗号化エラー、OS破損、マルウェア疑い
•物理故障：落下、画面割れ、浸水、端子破損
•電池異常：膨張、異臭、異常発熱、発煙、焼損
•複合事故：紛失とアカウント侵害、破損とデータ持出しなど

受付担当者が「たぶん机にある」「電源が入らないだけ」と決めつけません。最後に正常利用した時刻、最後に確認した場所、発見時刻、端末識別子、利用者、申告経路をincident_idへ結びます。後で分類が変わっても、最初の申告を上書きせず履歴として残します。

2．重大度は端末価格ではなく四つの影響で決める

高価な端末でも暗号化、MDM、最小権限が機能していれば情報影響は抑えられます。安価なスマートフォンでも管理者MFAや顧客情報へアクセスできれば重大です。

情報影響

保存・同期される顧客、従業員、決済、営業秘密、認証情報の種類と件数を確認します。ローカル保存が禁止されていても、メール通知、ダウンロード、ブラウザキャッシュ、チャット添付を確認します。

アクセス影響

端末ロック、暗号化、MDM、パスコード強度、MFA、証明書、VPN、SSOセッション、API鍵、復旧コードを確認します。「MFAあり」でも、その端末自身が第二要素なら保護にならない場合があります。

安全・事業影響

電池の発熱・膨張、利用者の負傷、周辺物の焼損を情報事故と別に評価します。同時に、現場作業、決済、顧客対応、医療・物流など、端末停止による業務影響と代替手段を確認します。

四軸を低・中・高で評価し、最高値だけで初動レベルを決めます。端末の簿価や本人の役職だけで重大度を下げません。

3．報告しやすい入口と時間目標を決める

夜間や出張中でも使える電話・Web・チャットの報告先を一つの案内にまとめます。端末自体を失った人が社内ポータルへログインできない前提で、外部から確認できる連絡先も用意します。

社内目標の例は次です。

•発見後ただちに：利用者が安全確保と一次報告
•15分以内：受付、incident_id発行、本人確認
•30分以内：高リスクアクセスの一時停止判断
•1時間以内：MDM、回線、セッション、データ影響の一次評価
•4時間以内：対応責任者と社内報告範囲の確定
•24時間以内：事実関係、継続措置、復旧計画の更新

これは法定期限の代わりではなく、社内初動の目標です。休日も同じ目標を求めるなら、当番、権限、連絡網を用意します。報告遅延を懲罰中心にすると隠蔽を招くため、迅速な善意報告を評価し、故意・重大な規程違反は事実確認後に別プロセスで扱います。

IPAの従業員の初動対応に関する実践例も、起こり得る脅威シナリオごとに証拠保全を踏まえた初動を定め、報告窓口を周知する考え方を示しています。

4．責任分界はRACIではなく実行権限まで書く

「情報システムが対応する」では、休日に誰がセッションを止められるか分かりません。役割、実行権限、承認、代行、期限を表にします。

•利用者：安全確保、一次報告、事実提供、自己判断での分解禁止
•上長：業務影響、顧客案件、代替端末、連絡先の確認
•受付・サービスデスク：本人確認、記録、優先度付け、引継ぎ
•セキュリティ：封じ込め、証拠保全、侵害調査、重大度更新
•ID管理：SSO、MFA、証明書、トークン、共有権限の停止
•MDM管理：紛失モード、ロック、位置情報、ワイプ指示と結果確認
•通信管理：SIM・eSIM・回線、転送、IMEI等の事業者手続
•資産管理：asset_id、貸与、代替、修理、廃棄、保険
•個人情報保護・法務：漏えい等該当性、報告・通知、法的保全
•広報・顧客担当：承認済みメッセージ、問い合わせ対応

夜間責任者が「一時停止」でき、翌営業日に正式承認を追認できる設計が実用的です。不可逆なワイプ、外部通知、廃棄は、緊急時の例外条件と承認者を別にします。

5．最初の15分は安全・接続・証拠を守る

紛失者には、危険な場所へ戻らず、別の安全な端末から報告させます。盗難の疑いがあれば単独で回収に向かわせません。故障端末は症状に応じ、電源やネットワークを維持すべき場合と切るべき場合があるため、利用者が再起動・初期化を繰り返さないよう案内します。

初動で記録する内容は次です。

•誰が、いつ、どこで、何を確認したか
•asset_id、serial、IMEI、電話番号、OS、所有区分
•最終正常利用・最終同期・最終位置の時刻
•暗号化、画面ロック、MDM、通信状態
•ローカル保存データと利用サービス
•直前の不審な通知、MFA要求、フィッシング
•落下、浸水、発熱、異臭、煙、負傷の有無
•利用者がすでに行った操作

記録時刻は同じタイムゾーンに統一し、「朝」「さっき」を避けます。本人の記憶とシステムログを区別します。

6．リモートロック・ワイプは指示と成功を分ける

MDMの操作は、queued、delivered、acknowledged、completed、failed、unreachableを分けます。ワイプボタンを押しただけで「データ消去済み」と記録してはいけません。オフライン端末には届かず、再接続まで保留される場合があります。

ワイプ前には次を判断します。

•位置確認や証拠保全を継続する必要があるか
•暗号化・強固なロックが実際に有効か
•ローカルデータの機密性と外部アクセス可能性
•デバイス証明書やeSIMを先に無効化すべきか
•捜査、保険、法務保全との競合がないか
•個人所有端末で消去できる業務領域が限定されるか

規程には「紛失なら即ワイプ」だけでなく、誰がどの条件で判断し、未達時に何を止めるかを書きます。ワイプ後もSSOセッション、復旧コード、API鍵、共有リンクが別に残り得ます。

7．端末外のアクセスを同時に封じ込める

端末ロックだけでは、すでに発行されたセッションやトークンを止められない場合があります。影響に応じて次を処理します。

高権限・決済・顧客管理のセッションを失効
SSO、メール、VPN、クラウドのアクティブセッションを確認
MFA登録、パスキー、証明書、復旧コードを更新
API鍵、SSH鍵、ブラウザ保存資格情報を評価
SIM・eSIM、電話転送、SMS認証を停止・変更
共有リンク、代理権限、端末信頼を無効化
不審ログインとデータ操作を監視

全パスワードの一律変更は、重要なログを失わせたり利用者を混乱させたりします。認証方式、侵害可能性、セッション失効能力に基づき対象を決めます。変更しただけで旧セッションが切れるとは限らないため、サービス仕様を確認します。

8．個人データの漏えい等は専門担当が現在の基準で判断する

端末紛失は自動的に漏えい確定ではありませんが、暗号化されているから自動的に対象外とも限りません。データの種類、取得可能性、不正目的、対象人数、封じ込め状況を事実で評価します。

個人情報保護委員会の漏えい等対応ページには、報告が必要となる場合、報告先、速報・確報、本人通知などの案内があります。報告要否や期限は、事故時点の法令・ガイドライン、委任先、契約、業界規制を個人情報保護・法務担当が確認します。記事の一般説明だけで自己判断しません。

評価記録には、対象データ、件数の算定方法、暗号化・鍵管理、アクセスログ、漏えい・滅失・毀損のおそれ、判断者、判断日時、参照基準を残します。事実未確定なら「対象なし」とせず、仮説、未確認項目、次回更新時刻を示します。

9．故障と電池異常では人身安全を優先する

画面割れと電池膨張を同じ修理箱へ入れません。膨張、異臭、異常発熱、煙、焼損がある端末は、充電、圧迫、分解、通常梱包、一般ごみへの廃棄をさせず、人を離し、施設の安全手順と専門事業者へ接続します。

総務省消防庁のリチウムイオン電池火災に関する案内は、強い衝撃や高温放置などの主な原因と、出火時には周囲へ知らせて身の安全を最優先にすることを案内しています。社内手順には、危険兆候、隔離場所、連絡先、搬送禁止条件を具体的に書きます。

通常故障でも、修理事業者へ渡す前に所有確認、データ保全、消去可否、保管媒体、委託範囲、輸送記録を確認します。起動不能は消去済みを意味しません。ストレージ交換後の旧部品の扱いも契約へ含めます。

10．代替端末の提供と権限復旧を急ぎすぎない

業務継続のための代替端末は、事故端末の複製ではなく、新しい信頼端末として登録します。

•本人確認と上長承認
•新しいasset_idと貸与記録
•MDM、暗号化、OS、必須設定の確認
•MFA・証明書・業務アプリの再登録
•必要最小限の権限から復旧
•事故端末との同時有効期間の制限
•データ復元元と復元範囲の記録

買い替え価格を優先して事故対応を短縮しません。復旧が完了し、再利用・交換の要件が固まった後に限り、同一条件で[PC相場を確認する](/pc-search)などを使って調達判断を行います。事故端末を未消去のまま下取りへ出さないことが前提です。

11．見つかった端末はそのまま業務へ戻さない

紛失モード中の端末が見つかっても、第三者が触れた可能性、設定変更、破損、証拠保全を確認します。回収者、場所、時刻、封印、端末状態を記録し、隔離ネットワークまたは管理下で検査します。

確認項目は、識別子一致、封印・外装、MDM状態、OS整合性、ログ、アカウント、証明書、SIM、データ消去・再構成の要否です。侵害可能性が否定できなければ、資格情報を再発行し、端末を再構成します。警察・交通機関・施設から受領した場合は、受領書や担当者もcaseへ結びます。

12．修理・保険・警察対応の証拠を一つの台帳へ結ぶ

外部手続をメールだけで追うと、端末と事故が分離します。incident_id、asset_id、shipment_id、修理番号、警察届出、保険請求を相互参照します。

•引渡元・引渡先・日時・担当者
•梱包・封印・追跡番号
•故障症状と写真、ただし機密画面を写さない
•データアクセス・部品交換の許可範囲
•旧ストレージ・SIM・交換部品の返却または処理
•修理結果、検査結果、保証、費用
•警察・施設・保険からの受付番号

修理会社が端末を受け取ったことと、情報事故が終結したことは別です。保険金が支払われても、アクセス停止やデータ評価を閉じません。

13．社内外の連絡は事実・判断・予定を分ける

初期段階では情報が変わります。連絡文には、確認済み事実、未確認事項、実施済み措置、利用者が取る行動、次回更新時刻、問い合わせ先を分けます。原因や対象人数を推測で断定しません。

顧客、本人、規制当局、警察、保険、委託先への連絡は目的と法的根拠が違います。広報だけ、現場だけで送らず、個人情報保護・法務・事業責任者の承認経路を決めます。通知先リストに機密な事故詳細を添付しない、BCCだけに安全を依存しないなど、送信自体の誤送信対策も必要です。

14．終結条件と再発防止を数値で管理する

端末交換が終わった日を事故終結日にしません。最低限、次が確定した時点で責任者が閉じます。

•端末の所在・処理または未回収リスクを確定した
•アクセス、回線、資格情報の必要措置が完了した
•データ影響と外部報告・通知の判断を記録した
•代替端末を安全に登録し、不要権限を残していない
•修理・廃棄・返却の証跡を資産台帳へ反映した
•未解決項目に責任者・期限・経営承認がある
•原因と再発防止を上流プロセスへ反映した

KPIは報告から受付まで、封じ込め判断まで、未到達ワイプ件数、暗号化不明率、期限超過、再オープン率、同種再発率を見ます。紛失件数だけを人事評価に使うと報告が減ったように見えるため、報告速度と管理状態の改善を重視します。

規程を机上の文書にしないための演習

年一回の周知だけでは、深夜の当番や代理承認が機能するか分かりません。交通機関でのスマートフォン紛失、海外出張中のPC盗難、膨張したタブレット、起動不能PCからのデータ保全という異なるシナリオで机上演習を行います。参加者には正解を先に示さず、連絡先、権限、台帳、MDM、通信事業者、外部報告判断へ実際に到達できるかを測ります。

演習では、本番端末を消去したり実在顧客へ通知したりせず、訓練用asset_id、訓練用アカウント、模擬連絡先を使います。開始前に「演習」と識別できる接頭辞と中止権限者を決め、実事故が同時発生した場合は実事故を優先します。終了後は、個人のミス探しではなく、見つからない連絡先、権限不足、二重入力、曖昧な完了条件を改善項目へ変えます。

規程の見直しには、OS・MDM・認証方式の変更、組織再編、委託先変更、法令・ガイドライン更新、実事故・演習の結果をtriggerとして設定します。改訂版には適用日、承認者、変更理由、旧版との差分を残し、端末利用者だけでなく夜間受付、上長、法務、通信・資産担当へ役割別に通知します。「読了」だけでなく、短い判断問題や連絡訓練で理解を確認します。

個人所有端末を業務利用する場合は、会社所有端末と同じ遠隔消去を前提にできません。管理対象となる業務領域、位置情報の取得範囲、退職・事故時の消去、私的データへの影響、補償、同意撤回後の業務手段を事前に定めます。事故が起きてから本人へ端末全体の初期化を迫る設計は避け、業務コンテナ、アプリ単位の制御、アクセス失効で分離できるようにします。

ケース：出張帰りに社用スマートフォンを紛失

利用者が帰宅後21時に紛失へ気づきました。端末は暗号化・MDM管理下でしたが、メールと顧客管理のセッションが有効でした。当番はincident_idを発行し、本人確認後に紛失モード、回線停止、SSOセッション失効を実施。ワイプは証拠・位置確認とデータ影響を評価するまで保留しました。

翌朝、交通機関で端末が発見されました。発見を理由にcaseを閉じず、受領記録、識別子一致、MDMログ、外装、アカウント操作を確認し、端末を再構成しました。顧客データへの不審アクセスがないこと、外部報告判断の根拠、代替端末の権限差分まで記録して終結しました。

まとめ：事故の種類ではなく、四つの影響を閉じる

紛失・故障時の規程は、「利用者がITへ連絡する」「遠隔消去する」だけでは足りません。情報、アクセス、安全、事業継続の四軸で重大度を決め、報告入口、時間目標、実行権限、承認者を明記します。

リモート操作は指示と成功を分け、端末外のセッション・回線・認証情報も封じ込めます。個人データの報告・通知は、事故時点の事実と現在の基準に基づき専門担当が判断します。故障ではデータだけでなく電池安全と委託先の管理を含めます。端末交換ではなく、影響評価、封じ込め、復旧、証跡、再発防止が完了した時点を終結とすることが、実務で機能する社内ルールです。