セキュリティインシデント対応マニュアル（セキュリティチーム用）

1. はじめに

1.1 目的

本マニュアルは、エアーズ株式会社における情報セキュリティインシデントの対応手順を定める。
インシデント発生時に迅速かつ適切な初動対応・封じ込め・復旧・再発防止を行い、
**発生後レビューに基づく恒久対策、規程・手順改訂、教育・訓練を含む継続的改善（PDCA）**を実現する。

1.2 適用範囲

本マニュアルは、エアーズ株式会社の全従業者および、会社の情報資産を取り扱う外部委託者に関連するインシデントに適用する。

1.3 用語

• インシデント：情報資産に対する機密性・完全性・可用性を損なう、または損なう恐れのある事象。
• 恒久対策：根本原因を除去し、再発を構造的に防ぐための対策。
• 再発防止策：同種・類似インシデントの再発を抑止する対策。

1.4 付則

• 本マニュアルは監査・レビュー・法令改訂等により必要に応じて改訂する。
• 本マニュアル中の「インシデント台帳」や「証跡の保存場所」、その他各種保存内容については「インシデント台帳等について」の章に記載している。

1.5 インシデント対応フロー概要

1. 初動対応（検知・通報受付・一次情報確保）
2. 対応方針決定（トリアージ／役割確定／エスカレーション判断）
3. 対応実施（方針に従った封じ込め・復旧・調査）
4. 恒久対策の検討（レビュー／再発防止策の計画化：Plan）
5. 恒久対策の実施（実装・適用：Do）
6. 効果検証と標準化（検証／規程・手順反映：Check / Act）
7. 教育・訓練／教訓共有（横展開・宙着）

2. 初動対応（検知・通報受付・一次情報確保）

2.1 目的

通報を受領した直後に情報の取り違えや初動遅れを防ぎ、
一次情報と証跡を改変せず確保し、次工程の判断材料を揃える。

2.2 通報の受領

通報は以下のいずれかで受領する。

• Slack：#インシデント報告 チャンネル
• メール：security-alert@airs.co.jp
• 口頭／電話（受領者は速やかにSlackまたはメールに転記する）

2.3 一次情報の確保

通報内容を改変せず一次情報として確保する（スクショ／原文引用／ヘッダ保存 等）。
不明点がある場合は報告者にヒアリングして次を収集する。

• 発生日／発見日
• 種別（誤送信、不審メール、紛失、障害、不正アクセス疑い 等）
• 対象（端末、アカウント、ファイル、サービス 等）
• 既に実施した初動（操作停止、削除依頼、遮断、端末隔離 等）
• 想定される影響範囲（社内／顧客／委託先 等）

2.4 緊急遮断の一次判断

拡大リスクが高いと判断される場合は、次の作業を先行して指示／実施する。

• アカウント停止、トークン無効化
• 不審リンク／ファイルの共有停止
• 対象端末のネットワーク隔離
• サービス停止／アクセス制限（必要時）

2.5 次ステップ

初動対応の結果を持って、3章「対応方針決定」へ移行する。

3. 対応方針決定（トリアージ／役割確定／エスカレーション判断）

3.1 目的

確定事実と暫定評価を短時間でまとめ、
“いま何を優先し、誰が動き、どこへ報告するか”を決める。

3.1 事実確認（ファクトの確定）

2章で確保した一次情報・証跡を基に、「確定した事実」「仮説」「未確認事項」を切り分け整理する。

• 何が起きたか／いつ起きたか／どこで起きたか
• 対象資産と関係者
• 影響し得るデータ・システム

3.2 影響範囲・重大性の暫定評価

以下を観点に暫定評価を付与する（低／中／高）。

• 情報の性質（個人情報、機密、認証情報、公開情報）
• 第三者閲覧・取得の可能性
• 拡大・悪用リスク（進行中／再発しうるか）
• 顧客・事業影響
• 法令・契約上の論点

3.3 対応レベルと優先順位の決定

暫定評価に基づき、対応レベルを決める。

• 一次対応（封じ込め／遮断）を即時実施すべきか
• 調査優先か
• 即時禁止事項（操作停止等）
• 追加招集すべき関係者

3.4 役割確定（RACI）

• 主担当（Responsible）：対応遂行の責任者
• 記録担当：台帳／レポート／証跡管理
• 判断者（Accountable）：重大性更新、社外報告、収束判断の最終責任

3.5 エスカレーション／社外報告の前倒し相談

“中／高”評価、顧客影響、法令・契約上の懸念がある場合、MNL-003_関係当局との連絡マニュアルに従って、社外報告の要否の検討を開始する。

3.6 次ステップ

決定した方針に従い 4章「対応実施」へ移行する。

4. 対応実施（方針に従った封じ込め・復旧・調査）

4.1 目的

対応方針に基づき、被害拡大を防止しつつ原因を特定し、復旧する。

4.1 封じ込め・遮断（必要時）

拡大防止のため、必要な遮断・隔離を実施する。

• アカウント停止／権限剥奪
• 公開範囲縮小／共有停止
• 端末隔離／ネットワーク遮断
• サービスアクセス制限

4.2 暫定復旧

サービス・業務影響を最小化するため、暫定復旧を行う。
復旧の可否・範囲は判断者が承認すること。

4.3 原因調査

証跡に基づき、技術／運用／人／教育／体制の観点で原因を整理する。
必要に応じて外部委託先・ベンダとの協働調査を行う。

4.4 重大性と方針の更新

調査結果に応じて重大性と対応方針を更新する。

4.5 次ステップ

対応が収束し、原因と暫定対策がまとまったら 5章「恒久対策の検討」へ。

5. 恒久対策の検討（レビュー／再発防止策の計画化：Plan）

5.1 目的

対応完了後にレビューを行い、教訓を抽出して、恒久対策・再発防止策をPlanとして確定する。

5.2 発生後レビュー（ポストモーテム）

原則10営業日以内に実施。

確認観点：

1. 事象の再整理（時系列）
2. 根本原因分析
3. 初動〜対応の妥当性
4. 検知・連絡・体制の課題
5. 横展開の必要性

レビュー結果はレポートに追記／別紙化し、台帳にリンクを残すこと。

5.3 恒久対策・再発防止策の策定

レビュー結果から対策案を整理し、以下を確定する。

• 対策内容
• オーナー
• 期限
• 優先度
• 効果測定指標（KPI/KRI）
• 規程・手順・教育改訂の要否
• 横展開対象

「確定した対策一覧（管理表）に、オーナー・期限・効果測定指標を記載してPlanを完了する。」

6. 恒久対策の実施（実装・適用：Do）

6.1 目的

Planとして確定した対策を確実に実装・適用する。

6.2 対策実行

「恒久対策・再発防止策の一覧（管理表）に従い、オーナーが対策を実行する。

※ 管理表は当面、インシデント台帳または別途合意した管理手段（Google Sheet / Jira / Backlog / Notion 等）で管理する。
※ 完了証跡（PR、設定変更記録、教育資料、手順改訂案等）を残す。

6.2 次ステップ

実施完了後、7章「効果検証と標準化」へ。

---

7. 効果検証と標準化（Check / Act）

7.1 目的

実施した対策の有効性を検証し、標準状態として宙着させる。

7.2 効果検証（Check）

以下のいずれか／複数で検証する。

• 机上検証（原因・リスクが潰せているか）
• 再現テスト／訓練
• 運用モニタ（一定期間の指標監視）

7.3 標準化（Act）

有効と判断した対策は以下に反映する。

• 社内規程・運用手順
• 対応テンプレ／チェックリスト
• 監視ルール・アラート
• 教育資料

不十分な場合は 5章へ戻り再計画する。

8. 教育・訓練／教訓共有（横展開）

8.1 目的

再発防止と組織学習のため、教訓を共有し教育・訓練で定着させる。

8.2 教訓共有

レビュー結果を必要最小限に匿名化・機密に配慮したうえで共有する。共有範囲と方法を台帳に記録する。

8.3 教育・訓練

必要な対象者へ教育・訓練・周知を実施し、実施記録を残す。
（例：全社周知、関係部署限定の勉強会、模擬訓練）

インシデント台帳等について

インシデント台帳

インシデント台帳は共有ドライブ「社外秘_情報セキュリティインシデント」で管理している。インシデント登録、恒久対応等の管理はこちらで行うこと。
なお、インシデントIDは振られないため、別途タイトルに SEC-2025112801 のように連番で作成していくこと。

証跡の保存場所について

証跡等については以下のように保存すること。

社外秘_情報セキュリティインシデント/報告書 以下に、証跡やレポート類を管理する専用フォルダを作成します：
/社外秘_情報セキュリティインシデント/報告書/#{インシデントID}/

改訂履歴

改定日	版	改定内容	承認
2026-06-10	1.0	GitHubリポジトリ（airs/isms）へ移行（インシデント台帳のSecureNavi参照を共有ドライブ「社外秘_情報セキュリティインシデント」へ置換、MNL-003参照を相対リンク化、旧ドキュメントの「別タブ」参照を章参照に変更）	-