インシデント対応手順の作り方（事業者）

インシデント対応手順は、ISMS文書の中で作るのは比較的簡単で、機能させるのが最も難しい文書です。フローチャートを1枚描き、連絡先一覧を付ければ形は整います。しかし実際に何かが起きたとき、その手順書を開く人がいるかどうかは別の話です。

現場で起きるのは、たいてい次のような事態です。深夜に不審なログイン試行のアラートが出たが、当番のエンジニアは「たぶん誤検知」と判断して朝まで放置する。営業担当が患者データを含むファイルを誤送信したが、「大事にしたくない」と考えて上長に言えないまま数日が過ぎる。顧客医療機関から「おたくのシステムから情報が漏れているのでは」と問い合わせが来て、初めて社内が動き出す。

手順書の良し悪しは、この「最初の30分」を設計できているかで決まります。 医療情報を預かる事業者の場合、さらに顧客医療機関への通知と、個人情報保護法に基づく報告という2つの外部義務が重なります。

本記事では、検知から教訓化までの5段階の設計、報告の敷居を下げる仕組み、外部通知義務の組み込み方、そして演習の設計を扱います。運用プロセス全体は箇条8 運用、改善への接続は箇条10 改善｜不適合と是正処置、規格全体は ISMS（ISO/IEC 27001）とはをご覧ください。

免責：本記事は一般的な情報提供です。規格の要求事項の解釈、認定・認証の取扱いは規格本文および認定機関・審査機関の公表資料が、個人情報の漏えい等に関する報告義務は個人情報保護法および個人情報保護委員会の公表資料が正本です。実際の対応はそれらに基づいて行ってください。

なぜここでつまずくのか

報告が上がってこない

これが最大の問題です。手順書の入口が機能しなければ、その先のフローは存在しないのと同じです。報告が上がらない理由は、担当者の意識ではなく設計の問題であることがほとんどです。

報告すると「誰の責任か」の追及が始まる文化がある
報告先が「情報セキュリティ委員会」のような組織名で、具体的な人が分からない
「インシデントに該当するか」を報告者が判断しなければならない
報告フォームの項目が多く、埋めるのに30分かかる
業務時間外の連絡手段が定まっていない

事象と事件の区別がついていない

規格は、情報セキュリティ事象（何かが起きたかもしれない状態）と情報セキュリティインシデント（情報セキュリティを危うくする可能性が高い事象）を分けて扱う考え方を採っています。この区別を手順に落とさないと、すべてのアラートを重大事案として扱うか、逆にすべてを軽視するかのどちらかになります。評価して切り分ける工程を、明示的に置く必要があります。

外部への通知判断が手順に入っていない

社内の封じ込め手順は書かれているのに、「いつ顧客に言うか」「いつ個人情報保護委員会に報告するか」が書かれていない手順書は非常に多い。この判断は時間制約があり、事後に考えると必ず遅れます。

教訓が次に活きない

対応が終わると報告書が書かれ、ファイルされ、誰も読まない。同じ種類のインシデントが半年後に再発します。

何を決めるのか

インシデント対応手順で事前に決めておくべきことは、次の7点です。

決めること	具体的に定める内容
報告の入口	誰に、どの手段で、いつまでに報告するか。24時間の連絡経路
一次受付の役割	受け付けた人が何をするか（記録、初期判断、エスカレーション）
評価基準	事象をインシデントと判定する基準と、重大度の区分
重大度別の対応体制	どのレベルで誰を招集するか。指揮を執る人
外部通知の判断基準と期限	顧客医療機関、個人情報保護委員会、本人、必要に応じて捜査機関
証拠の保全	ログ・端末・メールをどう保全するか。誰が実施するか
教訓化の手順	事後レビューの実施、是正処置への接続、手順の改定

重大度の区分

重大度は3〜4段階が実務的です。段階が多すぎると判定に迷い、少なすぎると対応が過剰または過少になります。ヘルスケア企業では、医療情報の関与と、顧客医療機関の診療への影響を軸に置くと判定しやすくなります。

区分	判定の目安	招集範囲	初動の目標時間
重大（Critical）	患者データの外部流出が疑われる／顧客医療機関の診療が停止する／ランサムウェア感染	経営層・全関連部門・外部専門家	即時（1時間以内に体制立ち上げ）
高（High）	本番環境への不正アクセスの痕跡／一定規模の誤送信／主要機能の長時間停止	ISMS責任者・技術責任者・関係部門長	当日中
中（Medium）	少数宛先への誤送信／端末の紛失（暗号化済み）／単発の不審ログイン	ISMS事務局・所属部門長	翌営業日
低（Low）／事象	フィッシングメールの受信報告／誤検知と判明したアラート	記録のみ	週次でまとめて確認

重要なのは、判定を迷ったときの原則を書いておくことです。 「判定に迷う場合は上位の区分として扱う」と明記しておけば、現場は安全側に倒せます。逆に原則がないと、責任回避のために低く見積もる力学が働きます。

管理策との対応では、附属書Aの組織的管理策のうちインシデント管理の一連の管理策（計画と準備、事象の評価と決定、対応、教訓、証拠の収集）と、人的管理策の事象の報告がここに集中します。読み方は組織的管理策37項目の読み方と人的管理策8項目の読み方をご覧ください。

実務の手順

1. 検知

検知の経路は複数あり、手順書にはそのすべてを列挙します。

経路	具体例	設計のポイント
自動検知	EDR・WAF・クラウドの監査アラート、監視の閾値超過	アラートの一次受け手を人単位で決める。当番制なら引き継ぎ手順も
従業者からの申告	誤送信、紛失、不審メール、操作ミス	申告経路を1本に絞り、周知を繰り返す
顧客・取引先からの指摘	医療機関からの問い合わせ、委託先からの通知	営業・サポート窓口が受けた場合の社内転送ルート
外部からの通報	セキュリティ研究者、JPCERT/CC等からの連絡	受付窓口を公開しているか。誰が一次対応するか

外部からの通報経路を用意していない企業は多いのですが、脆弱性の指摘が営業の問い合わせフォームに届いて埋もれる事故は実際に起きます。窓口を決め、サイト上で示しておくことが対策になります。

2. 報告

報告の敷居を下げる設計が、この手順全体の成否を決めます。

報告先は「人」または「チャネル」で示す。 「情報セキュリティ委員会に報告」ではなく、「Slackの #security-report チャネル、または情報システム部◯◯（内線◯◯／携帯◯◯）」のように、迷わず届く先を書きます。業務時間外の経路も同様に明記します。

報告者に判定させない。 報告フォームに「インシデント区分」を選ばせる設計は避けます。報告者が書くのは、**いつ・何が・どこで起きたか（または起きたと思われるか）**だけで十分です。判定は受付側の役割です。

最初のフォームは5項目以内に。 実務的には次の5項目で足ります。

項目	記入例
いつ気づいたか	2026年9月14日 14:30頃
何が起きたか（見たまま）	患者リストのExcelを、宛先を間違えて社外の◯◯様に送信した
関係するデータ・システム	患者氏名・生年月日を含むリスト、約120件
現在の状況	送信先には未連絡。メールの取消は不可
報告者と連絡先	営業部 ◯◯／内線◯◯

「報告したこと自体を評価する」文化を明文化する。 手順書の冒頭に、速やかな報告は懲戒の対象としない旨を明記している組織は、報告件数が明確に多くなります。これは精神論ではなく、報告の期待値を制度で担保する設計です。ただし、隠蔽は別に扱うことも同時に明記します。

3. 評価

受付担当は、まず記録を作り、次に事象かインシデントかを判定します。

判定に必要な確認事項をチェックリストにしておくと、担当者による差が出ません。

医療情報・個人データが関与しているか。関与する場合、おおよその件数は
要配慮個人情報（診療情報、健診結果など）が含まれるか
外部に流出した、または流出した可能性があるか
顧客医療機関のシステム・診療業務に影響があるか、または及ぶ可能性があるか
影響が拡大中か、止まっているか
不正アクセス・マルウェアなど、第三者の関与が疑われるか

この段階で「時計を動かす」ことが重要です。 個人情報保護法に基づく報告や顧客への通知には期限があり、起点は原則として事態を知った時点です。評価の記録に、誰がいつ何を認識したかを時刻付きで残します。

4. 対応

対応は、封じ込め → 根絶 → 復旧の順に進めますが、ヘルスケア企業では顧客医療機関の診療を止めないという制約が同時にかかります。感染端末をネットワークから切り離す判断が、そのまま病院の外来停止につながる構造がありうるためです。

段階	実施事項	ヘルスケア固有の注意
封じ込め	アカウント停止、端末隔離、通信遮断、機能の一時停止	顧客医療機関の診療時間を考慮した実施タイミングの判断。判断者を事前に決めておく
証拠保全	ログの退避、メモリ・ディスクの保全、関連メールの保全	復旧を急ぐと証拠が消える。保全を復旧の前工程として手順に明記
根絶	マルウェア除去、脆弱性の修正、不正アカウントの削除	顧客環境にも同種の問題がないかの横展開確認
復旧	バックアップからの復元、サービス再開、監視の強化	復旧判定の基準を事前に定める。再感染の確認
記録	対応の時系列（誰がいつ何をしたか）	後の報告書・顧客説明・監督官庁対応の一次資料になる

証拠保全を復旧の前に置くのは手順設計上の要点です。現場は復旧を優先しがちで、端末を初期化してから「ログを見たい」となる事故が起きます。

外部通知の判断は、この対応と並行して進めます。次節で扱います。

5. 教訓化

対応完了後、原則として2週間以内に事後レビューを行います。目的は責任追及ではなく、再発防止の設計です。

検知は適切なタイミングだったか。もっと早く気づける仕組みはあるか
報告は速やかだったか。遅れた場合、何が障害だったか
判定は妥当だったか。区分の定義に曖昧さはなかったか
手順書どおりに動けたか。動けなかった箇所はどこか
根本原因は何か。技術・運用・体制のどこにあるか

結果は是正処置として起票し、期限と責任者を付けて追跡します。様式は是正処置報告書の書き方を参照してください。同時に、手順書自体の改定が必要かを必ず検討します。「手順書のとおりに動けなかった」は、手順書の不備を示す最良の情報です。

顧客医療機関への通知と法令報告

ここが、一般的なIT企業の手順書と、医療情報を預かる事業者の手順書が決定的に違う部分です。

3種類の外部義務

義務の種類	根拠	起点と期限の考え方
顧客医療機関への通知	委託契約・SLA、および経産省・総務省の事業者向けガイドライン	契約で定めた期限（実務上は「速やかに」「◯時間以内」等）。契約ごとに異なる
個人情報保護委員会への報告	個人情報保護法（漏えい等報告）	速報は速やかに、確報は原則30日以内（不正の目的によるおそれがある行為による場合は60日以内）
本人への通知	個人情報保護法	速やかに。本人の権利利益を保護するため必要な範囲で

医療情報は要配慮個人情報にあたるため、漏えい等の報告対象になりやすい点に注意が必要です。 要配慮個人情報が含まれる漏えい等は、件数の多寡にかかわらず報告対象とされています。「1件だから報告不要」という判断は成り立ちません。

また、個人データの取扱いを委託されている事業者が、委託元に対して所定の事項を通知した場合には、委託先自身の報告義務が免除される取扱いが法令上あります。ヘルスケアSaaS事業者の多くはこの構造に当てはまりますが、免除されるのは委員会への報告であって、顧客医療機関への通知義務がなくなるわけではありません。手順書では両者を分けて書く必要があります。

最新の要件は個人情報保護委員会の公表資料で必ず確認してください。

手順に組み込む方法

通知判断を後回しにしないために、評価工程の出力として通知判断を必ず通る構造にします。

評価の結論	通知に関する必須アクション
個人データの漏えい・滅失・毀損、またはそのおそれがある	法務・責任者へ即時エスカレーション。報告要否の判断を記録
顧客医療機関のデータが関与する	契約書の通知条項を確認し、期限を対応タイムラインに記入
診療業務に影響がある／及ぶおそれがある	影響の見通しとあわせて、暫定情報でも先に一報を入れる
該当なしと判断した	判断した理由と判断者を記録に残す

「該当なし」の判断こそ記録が必要です。 後日、判断が誤っていたと分かった場合に、認識のうえで判断したのか、検討すらしなかったのかは決定的な差になります。

一報は完全な情報を待たない。 顧客医療機関にとって最悪なのは、情報が不完全なことではなく、知らされていない時間が長いことです。「現時点で判明していること／まだ分かっていないこと／次の連絡予定時刻」の3点を示す第一報の様式を用意しておくと、初動で迷いません。

顧客側（医療機関）から見た対応計画は医療機関のインシデント対応計画、漏えい時の報告義務の詳細は個人情報漏えい時の報告義務、責任の切り分けは責任分界点の決め方｜医療機関と事業者で扱います。

よくある失敗

連絡先一覧が古い

手順書の別紙にある連絡先が退職者のままになっている。四半期に一度の更新を、誰かのタスクとして固定するか、社内の名簿システムを参照する設計にします。

手順書が長すぎて緊急時に読めない

30ページの手順書は、深夜の障害対応中には開かれません。本体は詳細に書いてよいが、A4一枚の「初動カード」を別に作るのが実務解です。初動カードには、報告先・重大度の判定表・最初にやること3つ・やってはいけないこと（端末の初期化、証拠の上書き）だけを載せます。

外部専門家への依頼経路が事故後に探される

フォレンジック調査や法律相談が必要になったとき、その場で業者を探し始めると数日を失います。平時に1〜2社と接点を持ち、連絡先を手順書に書いておくことが有効です。契約までは不要でも、窓口を知っているだけで初動が変わります。

演習をやっていない／やり方が形式的

手順書を配って読ませることは演習ではありません。効果があるのは**机上演習（テーブルトップ）**で、進行役がシナリオを段階的に提示し、参加者がその場で判断していく形式です。

演習シナリオの例：

シナリオ	検証したい論点
深夜に管理者アカウントの不審ログイン成功を検知	時間外の招集経路、封じ込め判断の権限、顧客への一報のタイミング
患者データを含むファイルを社外へ誤送信	報告の速さ、法令報告の要否判断、顧客医療機関への通知
委託先からランサムウェア感染の連絡が入る	委託先経由の影響評価、契約上の通知条項の確認、複数顧客への同時連絡
顧客医療機関から「データが見えている」と指摘	マルチテナント分離の確認手順、影響範囲の特定、説明責任
主要クラウドの広域障害でサービス停止	可用性インシデントとしての扱い、BCPとの接続、復旧判定

演習は年1回以上、重大度の高いシナリオで実施し、記録（実施日・参加者・シナリオ・気づき・改善事項）を残します。この記録は審査でも確認されます。可用性側のシナリオは事業継続計画（BCP）とISMSの接続と接続させると効率的です。

インシデント記録の粒度がバラバラ

担当者ごとに書き方が違うと、傾向分析ができません。記録項目を固定したインシデント管理台帳（発生日、検知経路、区分、影響、対応、根本原因、是正処置番号、完了日）を1本持ち、すべてをここに集約します。これが箇条9の監視・測定のインプットになります。

是正処置が「注意喚起」で終わる

誤送信に対して「全社に注意喚起メールを送付」だけで閉じる是正は、再発を防ぎません。仕組みで止める対策（社外宛送信時の確認ダイアログ、添付ファイルの自動暗号化、宛先ドメインの警告）を必ず検討対象に入れます。

ヘルスケア企業の例

医療SaaS事業者の場合

固有の重大シナリオはマルチテナントの分離不備です。テナントAのユーザーにテナントBのデータが表示された、という事象は、影響範囲の特定が技術的に難しく、かつ複数の顧客医療機関に同時に通知が必要になります。手順書には、影響テナントの特定手順（アクセスログからの逆引き、表示されたデータの範囲の確定）と、複数顧客への同時連絡の体制を書いておく必要があります。責任分界の設計は既存記事の AI電子カルテのセキュリティ設計｜責任共有モデルが参考になります。

もう一つはサポート業務での本番データアクセスに起因する事象です。障害調査で参照した患者データを、承認範囲を超えて閲覧した／手元にコピーした、というケースは内部要因のインシデントとして設計しておきます。

PHR事業者の場合

同意範囲を超えたデータ利用が、外部からの攻撃を伴わないインシデントとして立ちます。新機能のリリースによって、利用者が同意していない目的でデータが使われた、という事態です。これは技術的な封じ込め（機能の停止）と、利用者本人への説明の両方が必要になり、通常の漏えい対応とは手順が異なります。詳細は PHR事業者のISMS｜個人情報保護法との関係をご覧ください。

治験・臨床研究システムを扱う企業の場合

完全性のインシデントが中心になります。データの改変、監査証跡の欠落、時刻同期のずれ。機密性のインシデントと違って外部流出を伴わないため、重大度の判定表に完全性の軸を明示的に入れておかないと、低く評価されて見落とされます。

SaMDを開発する企業の場合

セキュリティインシデントが製品の安全性の問題に転化する経路を、手順書に明示します。たとえば更新配信経路の侵害は、ISMS上はインシデントですが、製品側では不具合・回収の判断を要する事象になりえます。ISMSのインシデント対応から、QMS側の不具合処理・当局報告のプロセスへ接続する判断点を書いておくことが必要です。関係の整理は SaMDとISMS・QMS（ISO 13485）の関係で扱います。

委託先を多く使う場合

自社の手順だけでは閉じません。委託先で発生したインシデントが自社に通知される仕組みを、契約と運用の両面で確保する必要があります。契約条項の設計は外部委託先管理｜チェックシートと契約条項をご覧ください。

まとめ

手順書の成否は**「最初の30分」の設計**で決まる。報告の入口が機能しなければ、以降のフローは存在しないのと同じ
報告者に判定させない。報告は5項目以内、判定は受付側の役割。迷ったら上位区分として扱う原則を明記する
事象とインシデントを切り分ける評価工程を明示的に置き、そこから外部通知の判断へ必ず分岐させる
医療情報を預かる事業者には、顧客医療機関への通知・委員会への報告・本人への通知の3系統がある。委員会報告が免除される場合でも顧客への通知義務は残る
証拠保全を復旧の前工程として手順に書く。復旧を急いで証拠が消える事故は現実に多い
机上演習を年1回以上実施し、記録を残す。手順書どおりに動けなかった箇所が最良の改善情報になる

インシデントから得た教訓は箇条10 改善｜不適合と是正処置のプロセスに乗せ、資源配分が必要なものはマネジメントレビューの進め方と議事録で判断します。可用性側の備えは事業継続計画（BCP）とISMSの接続、ガイドライン側の要求との統合は ISMS文書と3省2ガイドライン対応文書の統合をご覧ください。

ポテックは、ヘルスケア領域に特化してISMS認証取得と運用を支援しています。顧客医療機関への通知義務を組み込んだインシデント対応手順は、汎用のひな形では作れない領域です。支援内容と料金は ISMS認証取得支援サービス、個別のご相談はお問い合わせから承ります。

参考・出典

※規格の要求事項の解釈、認定および認証の取扱いは規格本文および認定機関・審査機関の公表資料を、漏えい等報告の要件は個人情報保護委員会の公表資料をご確認ください。法令改正やガイドラインの改定により取扱いが変わる場合があります。