インシデント報告が「技術の作文」になる人へ ── 経営者が判断できる型に翻訳する机上演習【CySec復習ログ#12】

Posted at 2026-09-01

はじめに

少し前の私は、インシデント報告を書くと、いつのまにか「技術の作文」になっていました。

「どのサーバーで何が起きたか」「ログに何が出ていたか」「自分が何を切り分けて、どこまで対処したか」。過去にあった技術的な事実を、時系列でびっしり書く。それで報告した気になっていました。ところが、報告を受けた経営層から返ってくるのは、決まってこの一言でした。「で、経営として何を判断すればいいの?」。

私はそこで固まりました。私が書いたのは「何が起きたか(過去)」と「自分が何をしたか(過去)」ばかりで、「これから経営として何を決めるべきか(将来)」が、すっぽり抜けていたのです。技術の言葉は書けても、それを事業・お金・公表といった経営の言葉へ翻訳できていませんでした。これが少し前の私です。

この記事は、CySec(東京電機大学が提供する社会人向けのサイバーセキュリティ教育プログラム「国際化サイバーセキュリティ学特別コース」)で学んだ内容を、自分の言葉で再構成した復習ログで、シリーズ通し番号では #12 です。

直前の #11 も、同じ「机上演習」を扱った回でした。ただし焦点が違います。#11 は、インシデント対応フローを描いて・壊して・連絡手段まで決める、という技術・運用寄りの演習でした。本記事(#12)は、技術インシデントを経営者が判断できる報告へ翻訳する、という経営・マネジメント寄りの演習です。同じ机上演習でも、#11 が「現場でどう動くか」なら、#12 は「経営に何を伝え、何を判断してもらうか」を扱います。

想定読者は、少し前の私と同じく、インシデントの技術的な切り分けや対応はできるけれど、それを経営者が判断できる報告に翻訳できないエンジニア・情シス・セキュリティ担当です。報告を書くと「技術の作文」になりがちな方、社内で机上演習をやってみたものの「ブレストで盛り上がって終わり」になった経験のある方を念頭に置いています。

この記事の軸になる見方を、先に1行で書いておきます。

インシデント報告は「報連相(過去の報告)」ではなく「翻訳と上申」である。机上演習の価値は、技術インシデントを決まった型に流し込んで"事業・顧客・財務・公表"の言葉へ翻訳し、状況が動けば同じ型のまま深刻度を更新し、最後に経営者が判断できる選択肢として上申するところまでを、平時に体験することにある。

結論を先に3点でまとめておきます(TL;DR、最初に結論)。本文はこれをほどいていく形です。

ステータスレポートは「翻訳装置」である。 技術インシデントを決まった型(対象事業・事業への影響・顧客への影響・財務への影響・外部への連絡・影響システム)に流し込むと、技術の話が経営の言葉に翻訳されます。とくに「顧客」「財務」「外部連絡」の3カテゴリが翻訳の肝です。
状況が変われば、同じ型のまま「更新」する。 端末1台の感染(影響軽微・公表不要)から主要システム全停止(事業存続レベル・公表必須)へ状況が動くと、同じフォーマットのまま深刻度・被害者数・外部連絡の要否・公表方針が連動して跳ね上がります。
経営者への報告は「報連相」ではなく「翻訳と上申」。 過去(状況・評価・実施した対処)だけでなく、将来(想定される状況・暫定対処・本質的対応)を両輪で書き、「何を判断してほしいか」を選択肢と費用つきで上申します。

読み終えたとき、自組織で起こり得るインシデントを1つ思い浮かべ、「これを経営者に報告するなら、顧客・財務・外部連絡をこう書く。判断してほしいのはこれ」と、型に沿って書き出せるようになっていれば成功です。なお私自身まだ学習中なので、間違いがあれば指摘していただけると助かります。

なぜ机上演習は「ブレストで盛り上がって終わり」になるのか

本題に入る前に、机上演習そのものについて整理しておきます。机上演習(Tabletop Exercise、TTX)は、実際のシステムを動かさず、台本化したシナリオをもとに「もしこれが起きたら、どう動くか」を議論ベースで検討する演習です。米国の CISA(サイバーセキュリティ・インフラセキュリティ庁)も、机上演習を、台本化したシナリオをファシリテーター付きで議論する形式の演習として位置づけています(出典: CISA Tabletop Exercise Packages)。実機を壊さずに「痛い思い」を先取りできるのが、この形式の良さです。

ところが、机上演習をやってみると、よくこうなります。「いやー大変ですね」「とりあえずバックアップ取っておきましょうか」と盛り上がって、なんとなく終わる。気づきはあった気がするけれど、手元には何も残らない。私にも覚えがあります。

なぜブレストで終わってしまうのか。講義が示した答えはシンプルでした。アウトプット(成果物)を決めていないからです。「議論しましょう」だけだと、議論は発散して終わります。逆に「最後にこの書類を完成させてください」というゴールがあると、議論はそこへ向かって収束します。

この演習では、インシデント対応を次の3つの位置づけで捉えます。

INPUT: シナリオ(どんなインシデントが起きたか)
PROCESS: インシデント対応(どう動くか)
OUTPUT: 公表内容や経営報告(最終的に何を出すか)

そのうえで、「設定した INPUT に対して、適切な OUTPUT が出せるか。それを PROCESS の視点から評価する」という枠で演習を進めます。財務的な目標ではなく、合理的な公表内容・報告内容を出せることをゴールに置くわけです。

そしてこの演習は、セキュリティ施策を2つの論点で評価します。1つは遵守性(コンプライアンス)、もう1つは有効性です。講義が繰り返し問うたのは、「遵守が目的化していないか」という点でした。ルールを守ること自体が目的になり、「そもそも何のためのルールか(=脅威への有効性)」を見失っていないか、ということです。

その背景には、「本当の目的は事業のマネジメントにある」という考え方があります。仮に完璧なセキュリティ対策が実現できても、会社が潰れては意味がない。だからこそ、技術視点だけでなく、事業・経営・外部の視点からも施策の有効性を評価する。本記事のテーマである「翻訳」が必要になるのは、まさにこの理由からです。

ステータスレポートという「翻訳装置」

ここからが本題です。演習で最初に作る成果物が、ステータスレポートでした。これが、技術インシデントを経営の言葉へ変換する「翻訳装置」になります。

仕組みは単純です。インシデントの状況を、あらかじめ決められたカテゴリの「型」に流し込む。すると、技術の話が、勝手に事業・顧客・財務・公表の言葉に並び替わる。型が決まっているから、書く人によって観点が抜け落ちることがありません。ステータスレポートのカテゴリは、大きく次の6つです。

カテゴリ	何を翻訳するか
対象事業	どの事業の話か。事件・事故の概要。どんな情報が影響を受けるか
事業への影響	事業を止めるのか・縮退か・継続か。誰がどの役割を担うか
顧客への影響 ★	顧客にどんな被害が及ぶか。被害者は何人か。何ができるか
財務への影響 ★	いくらの損害か。直接損害・賠償・制裁金・無形損害まで
外部への連絡・報告 ★	監督機関・取引先・被害者・メディアに、いつ何を伝えるか
影響システム	どのシステムが影響を受けたか。原因・要因は何か

技術者が放っておくと、最後の「影響システム」だけ分厚く書いて、ほかが薄くなりがちです。少し前の私がまさにそうでした。経営者が本当に見たいのは、★を付けた顧客・財務・外部連絡の3カテゴリです。後ほど、この3つを具体的に見ていきます。

6カテゴリを横断する3つのものさし

カテゴリの中身に入る前に、6つのカテゴリを横断して使う「ものさし」を3つ押さえておきます。具体的には、深刻度×可能性のコード・RACI(外部専門家は RACIN)・原因/要因/背景/課題の4段分析の3つです。これらは、この演習で用いられた評価の型です。

1つめは、深刻度×可能性の2文字コード。 被害の各項目に、深刻度(大文字)と可能性(小文字)の頭文字を組み合わせた2文字のコードを付けます。たとえば重大(Serious)がすでに発生(occurred)していれば「So」です。一目で「どれくらいヤバいか」がわかる仕掛けです。

深刻度(頭文字)	可能性(頭文字)
Critical(致命的)	occurred(すでに発生)
Serious(重大)	high(高い)
Moderate(中程度)	medium(中程度)
Light(軽微)	unlikely(低い)
-(対象外)	-(対象外)

たとえば「So」なら Serious(重大)×occurred(すでに発生)で、もう起きてしまった重大被害。「Mu」なら Moderate(中程度)×unlikely(可能性は低い)で、起きるかもしれないが今は低い、という読み方です。同じ「被害」でも、すでに起きたのか・起きるかもしれないだけなのかで、対応の優先度はまったく変わります。コードはそれを区別します。

2つめは、関係者の役割を RACI(外部専門家は RACIN)で割り当てる。 RACI は、各タスクについて関係者の役割を4つに分ける考え方です。

Responsible:実行責任(実際に手を動かす)
Accountable:説明責任(最終的に責任を負う。1人)
Consulted:協業・相談(意見を聞く)
Informed:報告先(結果を知らされる)

この演習では、外部専門家(弁護士やセキュリティ企業など)について、ここに N(この演習での割当として「外部への通知/Notification」)を足した RACIN を使っていました。RACI 自体は広く知られた型ですが、"N" の意味は文脈によって異なるため、ここでは「この演習での割当」として一般の RACI と分けて捉えてください。誰が手を動かし、誰が責任を負い、誰に相談し、誰へ通知するか。これを決めておかないと、「で、これは誰がやるの?」で対応が止まります。

3つめは、原因で終わらせず「原因・要因・背景・課題」で分析する。 技術者は「原因(何が起きたか)」を突き止めると満足しがちですが、経営報告ではそこで終わりません。

観点	問い	例
原因	何が起きたか	認証情報が悪用され、システムに侵入された
要因	なぜ防げなかったか	多要素認証が一部で未導入だった
背景	なぜその状態だったか	予算が取れず、導入が後回しになっていた
課題	どう解決するか	来期に多要素認証を全面導入する

「原因」だけだと、技術の話で終わります。「要因・背景」まで掘ると、なぜ防げなかったのかという経営の責任の話に届きます。そして「課題」まで書けば、再発防止という将来の話につながります。この4段の分析は、後で出てくる経営報告書やポジションペーパーでも独立した項目として登場します。

経営が見たい3カテゴリを具体的に見せる(顧客/財務/外部連絡)

それでは、経営者がいちばん見たい3カテゴリ ── 顧客・財務・外部連絡 ── を具体的に見ていきます。固有のシナリオは外し、自組織でそのまま再利用できる「型」として紹介します。

顧客への影響

技術者の報告に最も欠けやすいのが、ここです。「サーバーが侵害された」は書けても、「で、お客さんは何人、どんな被害を受けるの?」に答えられない。顧客への影響カテゴリは、その問いを項目化したものです。

小項目	何を書くか
影響の概要	顧客にどんな影響が及ぶか(情報漏えい・サービス停止など)
データ量・被害者数	影響を受けるデータ量、被害者はおよそ何人か
被害者の特徴	個人か法人か、特定の属性に偏るか
想定される二次被害	漏れた情報を使った詐欺・なりすましなど
被害の確認方法	自分が被害に遭ったか、顧客はどう確認できるか
ワークアラウンド	復旧までの間、顧客はどう回避すればよいか
被害者ができる対策	パスワード変更・カード再発行など顧客側の手当て
外部の専門家(RACIN)	弁護士・セキュリティ企業・損保窓口など、誰に何を依頼するか

ポイントは「被害者数」を数で出すことです。「不明」のままでは経営判断ができません。仮の数でも、桁を見積もって書く。それだけで、報告は「技術の作文」から「経営の判断材料」に変わります。

財務への影響

経営者がいちばん知りたいのは、結局「いくらかかるのか」です。ここで技術者がやりがちなのが、身代金や復旧費用しか思い浮かばないこと。実際には、お金が出ていく経路はもっと広いです。

大分類	費目の例
直接的損害	身代金、詐欺被害、不正な現金引き出し(=金銭損害)/事業停止による機会損失(=利益損害)
費用・賠償・制裁金	事故原因調査、事故対応、広告宣伝、コールセンター、被害者への見舞金、被害範囲調査(=費用損害)/損害賠償・弁護士費用(=損害賠償)/個人情報保護法・GDPR 等にもとづく制裁(=行政損害)
無形損害	ブランド毀損、株価への影響、その他

技術者が見落としがちなのは、2行目以降です。とくにコールセンターの増設費用や機会損失(事業を止めたあいだ稼げたはずの売上)は、規模によっては身代金より桁が大きくなります。「身代金は10万円だけど、事業を1日止めると損失はその何倍」という比較ができて、はじめて経営判断の土俵に乗ります。さらに表の3行目、ブランド毀損や株価への影響といった無形損害は、金額に表しにくいぶん見落とされがちですが、中長期ではいちばん尾を引くことがあります。

外部への連絡・報告

「誰に・いつ・何を伝えるか」は、技術ではなく経営・法務の判断です。だからこそ型にしておく価値があります。

連絡先	判断の選択肢(例)
監督機関	個人情報保護委員会/監督官庁/警察に報告するか/不要か。時間的制約も明記
取引先	即時に第一報/事実関係が判明してから/確実に把握できるまで連絡しない/不要
被害を受ける顧客	即時に第一報/事実判明後/把握できるまで待つ/不要
メディア等の公知	メディア発表/自社サイト掲載/SNS/不要

このうち監督機関への報告は、法律で期限が定められている場合があります。たとえば日本の個人情報保護法では、一定の個人データ漏えい等について、個人情報保護委員会への報告が義務づけられています。速報は法令上「速やかに」報告する義務があります(個人情報保護委員会が示す目安として、おおむね3〜5日以内。土日祝を含む)。確報は原則30日以内です(不正な目的によるおそれがある場合は60日以内)(個人情報保護委員会:漏えい等の対応とお役立ち資料)。海外の利用者がいる場合は、EU の GDPR などで別の期限(例として原則72時間以内)が問題になりますが、海外展開のない組織であれば、まずは国内の報告義務を押さえれば十分です。

ここで大事なのは、「いつ伝えるか」を平時に決め方として持っておくことです。有事に「まだ調査中だから連絡を待とう」と判断を先延ばしにしているうちに、法定の期限を過ぎてしまう。それを防ぐために、選択肢を型として並べておきます。

初動 → 続報でレポートを「更新」する

ここが、この演習のいちばんの体感ポイントでした。同じステータスレポートを、状況の変化に合わせて更新するのです。

演習の仮想設定は、おおよそ次のようなものでした。あるオンラインサービス事業者で、まず在宅勤務中の業務用 PC が1台、ランサムウェアに感染します(身代金は演習の仮想設定で約10万円相当)。この時点では、被害は端末1台にとどまり、影響は軽微、公表も不要という判断になります。ところが対応している最中に、その PC の持ち主が主力サービスの管理者で、その認証情報が悪用され、主力サービスのシステム全体が侵害・暗号化されていることが判明します(身代金は演習の仮想設定で約1000万円相当へ跳ね上がる)。

このとき、ゼロから報告を書き直すのではありません。最初に作ったステータスレポートを、同じフォーマットのまま更新する。すると、初動と続報で、各項目がどう変わるかが一目でわかります。これが、同じ型を使い回すことの強みです。表中のコード(Lu・Co など)は、先ほどの深刻度×可能性の2文字コードです。

項目	初動(端末1台の感染)	続報(主要システム全停止)
対象範囲	業務用 PC 1台	主力サービスのシステム全体
システム停止の影響	大きな影響なし	主力事業が停止、機会損失が日々発生、事業の存続に関わる
顧客被害(コード例)	機密漏えい Lu(軽微・可能性低)	金銭被害 Mm・業務停止 Co・脅迫 Co へ格上げ
被害者数	不明	約◯◯万人(定量化)※演習の仮想設定
二次被害	該当なし	詐欺・漏えい情報の悪用の懸念
財務(身代金)	約10万円 ※演習の仮想設定	約1000万円 ※演習の仮想設定
財務(調査費用)	1人日程度	数名×十数日+数百万円規模
外部連絡	不要	個人情報保護委員会・監督官庁・警察(要検討)
取引先への連絡	不要	事実関係が判明しだい報告(取引銀行を含む)
公表方針	不要	メディア・自社サイト・SNS で公表

数字はいずれも演習の仮想設定であり、実在の事案を指すものではありません。それでも、この対比から学べることは普遍的です。状況が「PC 1台・影響軽微・公表不要」から「主要システム全停止・事業存続レベル・公表必須」へ動くと、①対象範囲 ②深刻度コード ③被害者数の定量化 ④外部連絡の要否 ⑤公表方針が、連動して一気に跳ね上がる。1つの項目だけが上がるのではなく、全部が連動して動くのです。

ここから来る運用思想が、「状況が変わったら、速やかに更新する」です。インシデントは生き物で、初動の判断が続報でひっくり返ることは珍しくありません。だからこそ、ゼロから書き直すのではなく、同じ型のまま差分を更新できる構造にしておく。これがステータスレポートを「型」として持つ最大の利点でした。

なお、続報で身代金が約1000万円に跳ね上がると、「払うべきか」という論点が出てきます。これは経営者に上申すべき経営判断です。事業を1日止めたときの損失(売上/日)と身代金を天秤にかける、払っても復号鍵が渡される保証はない、払えば次の標的になりうる ── どちらを選んでも痛みが残る、現場では極めて難しい判断です。本記事では、これを「経営者が判断すべき論点」として上申すること自体に話を絞り、是非は断定しません。支払いの実行面(払うと決めても即座には払えない実務的ギャップ)や法的リスクについては、技術・運用編の #11 で扱います。

経営者への報告は「報連相」ではない

ステータスレポートで翻訳し、状況に合わせて更新したら、最後は経営者への報告です。ここで、冒頭の「技術の作文」問題に戻ります。

少し前の私の報告がダメだった根本原因は、報告を「報連相」だと思っていたことでした。何が起きて、自分が何をしたかを伝える ── それは過去の報告です。けれど経営者が報告を受けて知りたいのは、過去ではなく「これから何を判断すればいいか」という将来です。経営報告は、過去と将来の両輪で書きます。

過去(起きたこと)	将来(これからのこと)
状況(何が起きているか)	想定される状況(このままだとどうなるか)
評価(深刻度・影響範囲)	暫定対処(いま打てる手)
実施した対処(すでにやったこと)	本質的対応(根本的に直すには何が必要か)

技術者は左の列が得意で、右の列が抜けます。けれど、経営者が判断するために必要なのは右の列です。そして報告の締めは、「報告」ではなく「上申」の形にします。演習で示された型を、自分の言葉に直した雛形が次です。○○や△△を自社の状況に置き換えれば、そのまま使えます。

・○○をご判断いただきたく、お願いします。
・このまま放置すると、△△という事態になります。
・選択肢は次の3つで、私としては□□が適切と考えます。
・必要な費用は、おおよそ◯◯です。
・実行には、××部門の協力が必要です。

「何が起きました」で終わるのが報連相、「何を判断してください、選択肢と費用はこれです」まで書くのが上申です。この差が、報告が経営に「効く」かどうかを分けます。

もう1つ、講義で刺さった視点があります。報告は、直接の上司だけをターゲットにしないということです。あなたが報告する上司は、その内容をさらに上の経営層や、取引先に説明します。だから「直接の上司に伝わればいい」ではなく、「その上司が取引先に説明する場面」まで想定して報告を作る。そうすると、自然と専門用語が減り、事業・顧客・財務の言葉に翻訳されていきます。

模擬記者会見は「内々の論理」を炙り出す

演習の最後には、模擬記者会見もありました。これは公表内容(OUTPUT)の検証です。社内では筋の通った説明のつもりでも、外から見ると「内々の論理」になっていないか、を確かめます。

講義で挙がった、記者会見でやりがちな失言の類型は次の3つでした。

当事者意識のない発言(他人事のような物言い)
法律・規制の軽視(「問題ないと考えています」と安易に言い切る)
含みを持たせた発言(あとで「あれはこういう意味だった」と弁解の余地を残す)

会社の代表として当事者意識を持ち、棒読みせず自分の言葉で、専門用語を避けて話す。挑発には冷静に応じる。技術者がそのまま記者会見に立つことは少ないとしても、「自分の報告は、外に出ても通用する言葉になっているか」を検証する視点として、覚えておく価値があります。

自組織で1周するための持ち帰り

ここまでの「翻訳 → 更新 → 上申」を、自組織で1周してみるための手順を、1枚の表にまとめます。机上演習のグループがなくても、1人でこの3ステップを回すだけで、報告は変わります。

ステップ	自組織でやること	自分への問い	出力物
翻訳	自社で起こり得るインシデントを1つ想定し、顧客・財務・外部連絡の3カテゴリを埋める	「影響システム」だけ分厚くなっていないか?	ステータスレポート1枚
更新	そのインシデントが「悪化したら」を想定し、同じ型を更新する	被害者数・外部連絡・公表方針は連動して動いたか?	初動→続報の差分
上申	経営報告を、過去と将来の両輪+判断の選択肢と費用で書く	「何を判断してほしいか」が1行で書けているか?	経営報告1枚

机上演習の教材は、独学でも手に入ります。この演習のもとになった JNSA(日本ネットワークセキュリティ協会)の CISO 支援ワーキンググループは、CISO 向けの机上演習「CISO-PRACTSIE」のワークショップ参考資料を公開しています(JNSA CISO支援ワーキンググループの成果物)。書籍『CISOのための情報セキュリティ戦略』(高橋正和著、技術評論社、2023年)を補完する位置づけの成果物です。グループがなくても、型と問いの立て方を追体験できます。

まとめ

この記事では、CySec 第11回「机上演習によるセキュリティ施策の評価」の内容を、「インシデント報告は報連相ではなく翻訳と上申である。机上演習の価値は、技術インシデントを型に流し込んで事業・顧客・財務・公表の言葉へ翻訳し、状況が動けば同じ型のまま更新し、経営者が判断できる選択肢として上申するところまでを平時に体験することにある」という1本の軸で再構成しました。タイトルの「技術の作文を、経営者が判断できる型に翻訳する」とは、まさにこのことです。

この記事の幹は3つです。これだけ持ち帰れば十分です。

ステータスレポートは「翻訳装置」。 6つのカテゴリに流し込めば、技術の話が経営の言葉になります。とくに顧客(被害者数を数で出す)・財務(身代金以外の費目を漏らさない)・外部連絡(いつ誰に伝えるかを型で持つ)の3カテゴリが翻訳の肝です。深刻度×可能性のコード、RACI/RACIN、原因/要因/背景/課題の4段分析が、6カテゴリを横断するものさしになります。
状況が変われば、同じ型のまま更新する。 端末1台の感染から主要システム全停止へ動くと、対象範囲・深刻度・被害者数・外部連絡・公表方針が連動して跳ね上がります。ゼロから書き直さず、差分を更新できる構造にしておくのが型の強みです。
経営報告は「報連相」ではなく「翻訳と上申」。 過去(状況・評価・実施した対処)だけでなく将来(想定状況・暫定対処・本質的対応)を両輪で書き、「何を判断してほしいか」を選択肢と費用つきで上申します。報告先の、そのまた先(取引先への説明)まで想定すると、言葉は自然と経営の言葉に翻訳されます。

これらは、机上演習という「準備」を通してしか身につきません。安全な場で「技術の作文」を一度書いてみて、経営者役に「で、何を判断すればいい?」と返されて固まる。その痛みを平時に味わっておくことが、本物の有事で同じ場所に落ちないための近道です。

最後に、手を動かしてほしいことを1つ。自組織で起こり得るインシデントを1つ思い浮かべ、顧客・財務・外部連絡の3カテゴリだけでも埋めて、「経営者に判断してほしいこと」を1行で書いてみてください。それだけで、あなたの報告は「技術の作文」から一歩抜け出します。少し前の私は、技術の事実をいくら積んでも経営者の前で固まりましたが、いまは「判断してほしいのはこれ、選択肢と費用はこれ」と1行で書き出せるようになりました。

なお、本記事の対になる #11(技術・運用編の机上演習。インシデント対応フローを描いて・壊して・連絡手段まで決める回)も公開済みです。同じ机上演習でも、現場でどう動くか(#11)と、経営に何を判断してもらうか(#12=本記事)は、表裏一体です。ここまで読んでいただき、ありがとうございました。冒頭にも書いたとおり、私自身まだ学習中の身です。間違いや、より正確な捉え方があれば、指摘していただけると助かります。

参考資料

本記事で挙げた用語・枠組み・年号は、次の一次情報・公的情報で確認できます。記事中の内容は学習・執筆時点(2026年6月現在)のもので、最新は各サイトで確認してください。

JNSA CISO支援ワーキンググループの成果物(机上演習 CISO-PRACTSIE のワークショップ参考資料を公開)
書籍『CISOのための情報セキュリティ戦略〜危機から逆算して攻略せよ〜』(高橋正和著、技術評論社、2023年)
CISA Tabletop Exercise Packages(机上演習=台本化したシナリオを議論ベースで検討する演習、の説明)
個人情報保護委員会:漏えい等の対応とお役立ち資料(個人情報の漏えい等が発生したときの報告義務・期限)
個人情報保護委員会:漏えい等報告の義務化について(速報・確報の考え方)

※ 本文のシナリオ・数字(身代金約10万円/約1000万円、被害者数など)は、すべて演習の仮想設定です。実在の企業・事案・攻撃を指すものではなく、固有の企業名・人物名・サービス名は外して再利用できる型に抽象化しています。
※ ステータスレポートのカテゴリ・小項目、深刻度×可能性のコード、RACI/RACIN による役割分担、原因/要因/背景/課題の4段分析、経営報告・ポジションペーパー・記者会見の構成は、いずれもこの演習で用いられた型です。公的な標準として断定するものではなく、自組織に合わせて調整することを前提に、「技術インシデントを経営の言葉へ翻訳する」「状況に応じて同じ型を更新する」という構造を普遍的なものとして扱っています。
※ RACIN の "N" の意味は文脈によって異なるため、本記事では「この演習での割当(外部への通知/Notification)」として、広く知られた RACI と分けて記載しています。
※ 個人情報保護委員会への速報の法令上の義務は「速やかに」報告することであり、本文で挙げた「おおむね3〜5日以内(土日祝を含む)」は個人情報保護委員会が示す目安です(法令上の固定された日数ではありません)。確報の30日/60日は法令上の期限です。報告期限は漏えい等の内容や対象によって適用関係が変わり、GDPR など海外の制度もそれぞれ別の基準があります。具体的な対応は、必ず一次情報および専門家の確認のうえで判断してください。身代金支払いの是非についても、本記事では特定の立場を断定していません。