data-breach-response

⚠️ 実験的 — このスキルは、教育および情報提供のみを目的として提供されています。法的助言を構成するものではありません。使用に関する責任はすべてユーザーが負います。出力に基づいて行動する前に、資格を有する法律専門家に相談してください。

データ侵害への対応

GDPR Art. 33/34、CCPA、HIPAA、NIS2、PCI DSS、その他の規制に基づく個人データ侵害へのインシデント対応と法令遵守。侵害の重大度を算出し、通知期限を追跡して、対応のタイムラインを管理します。

---

目次

• ツール
  • 侵害重大度計算ツール
  • 侵害タイムライン追跡ツール
• リファレンスガイド
• ワークフロー
• ENISA 重大度の計算式
• 通知判断マトリクス
• トラブルシューティング
• 成功基準
• 対象範囲と制限事項
• アンチパターン
• ツールリファレンス

---

まず確認すること

侵害を評価する前に、以下の入力情報を確認してください。不明な点や曖昧な点があれば、推測せずに質問してください。

• T0 — 認知した時点 — 72時間のカウントが始まります。タイムラインにおけるすべての期限と「残り時間」は、ここを起点に算出されます
• あなたの役割：管理者または処理者 — SA／データ主体に通知するか（Art. 33/34）、管理者にのみ通知するか（Art. 33(2)）を決定します
• データのカテゴリ、規模、特定の容易さ — ENISA 重大度スコアと判定（LOW／MEDIUM／HIGH／VERY HIGH）を左右するDPC／EIの入力項目です
• 適用される規制 — GDPR、CCPA、HIPAA、PCI DSS、NIS2、AI Actのどれが適用されるかによって、マトリクスが提示する通知期限と通知先が決まります

中断ルール：出力を大きく左右する2～3項目だけを質問してください。ユーザーが「とにかく草案を作成して」と言った場合は作業を進め、評価の冒頭に前提条件を列挙してください。

ツール

侵害重大度計算ツール

侵害パラメーターからENISA侵害重大度スコアを算出します。重大度の判定に基づいて通知義務を特定します。

# Calculate severity from parameters
python scripts/breach_severity_calculator.py \
  --dpc 3 --ei 0.75 \
  --confidentiality 0.5 --integrity 0.25 --availability 0 \
  --malicious

# JSON output
python scripts/breach_severity_calculator.py \
  --dpc 2 --ei 0.5 --confidentiality 0.5 --json

# With T0 timestamp for countdown
python scripts/breach_severity_calculator.py \
  --dpc 3 --ei 1.0 --confidentiality 0.5 \
  --t0 "2026-04-10T08:00:00" --json

# Generate input template
python scripts/breach_severity_calculator.py --template

出力内容：

• ENISA 重大度スコア（SE）
• 重大度の判定：LOW／MEDIUM／HIGH／VERY HIGH
• 通知義務（SA、データ主体、一般公開）
• T0からGDPRの72時間以内の通知期限までの残り時間

---

侵害タイムライン追跡ツール

T0（認知した時点）から侵害対応のタイムラインを追跡します。イベントを記録し、期限を監視して、ステータスダッシュボードを生成します。

# Initialize a new breach timeline
python scripts/breach_timeline_tracker.py init \
  --breach-id "BR-2026-001" --t0 "2026-04-10T08:00:00" \
  --description "Unauthorized database access" \
  --output breach_timeline.json

# Record an event
python scripts/breach_timeline_tracker.py event \
  --timeline breach_timeline.json \
  --action "Containment team activated" --category containment

# View status dashboard
python scripts/breach_timeline_tracker.py status --timeline breach_timeline.json

# Check deadlines
python scripts/breach_timeline_tracker.py deadlines --timeline breach_timeline.json

# JSON status output
python scripts/breach_timeline_tracker.py status --timeline breach_timeline.json --json

追跡対象：

• GDPRに基づくSAへの72時間以内の通知期限
• DPAの契約上の期限（処理者からの通知は24時間／48時間以内）
• NIS2に基づく24時間以内の初期警告と72時間以内の通知
• 完了済みと保留中の対応措置
• 各期限までの経過時間と残り時間

---

リファレンスガイド

ENISAの方法論

references/enisa_methodology.md

ENISAによる侵害重大度評価の完全な方法論：

• DPC（データ処理コンテキスト）のスコアリング：1～4
• EI（特定の容易さ）のスコアリング：0.25～1.00
• CB（侵害の状況）の加算スコアリング
• 計算式：SE = (DPC x EI) + CB
• 暗号化、仮名化、データ量による調整
• EDPB事例との照合（参照事例18件）

通知義務

references/notification_obligations.md

複数の規制における通知要件：

• GDPR Art. 33（72時間以内にSAへ）およびArt. 34（データ主体）
• CCPA、HIPAA、PCI DSS、NIS2、州の侵害通知
• 管理者と処理者の義務マトリクス
• 国境を越える場合の通知規則
• AI Act Art. 62に基づく重大インシデントの報告

---

ワークフロー

ワークフロー1：標準的な侵害対応

Step 1: Emergency check — is there <12h remaining on any deadline?
        → If yes, skip to Step 4 (emergency notification)

Step 2: Initialize breach timeline
        → python scripts/breach_timeline_tracker.py init --breach-id "BR-2026-001" \
          --t0 "2026-04-10T08:00:00" --description "Description"

Step 3: Calculate severity
        → python scripts/breach_severity_calculator.py --dpc N --ei N \
          --confidentiality N --integrity N --availability N [--malicious]

Step 4: Based on severity verdict, determine notifications
        → LOW (<2): Internal log only, no external notification
        → MEDIUM (2 to <3): Notify supervisory authority within 72h
        → HIGH (3 to <4): Notify SA + individual data subjects
        → VERY HIGH (>=4): Notify SA + data subjects + consider public notice

Step 5: Execute containment and record events
        → python scripts/breach_timeline_tracker.py event --timeline breach.json \
          --action "Action taken" --category containment

Step 6: Monitor deadlines continuously
        → python scripts/breach_timeline_tracker.py deadlines --timeline breach.json

Step 7: Complete notification obligations and document

ワークフロー2：緊急モード（残り12時間未満）

Step 1: Calculate severity immediately
        → python scripts/breach_severity_calculator.py --dpc N --ei N \
          --confidentiality N --t0 "original-t0" --json

Step 2: If MEDIUM or higher, prepare phased notification
        → Art. 33(4) allows phased notification when full information unavailable
        → Initial notification: what is known + promise of update
        → Supplementary notification: full details when available

Step 3: File initial SA notification before deadline expires

Step 4: Initialize timeline for ongoing tracking
        → Continue gathering information for supplementary notification

Step 5: Document emergency timeline and decisions

ワークフロー3：処理者による侵害通知

Step 1: Processor becomes aware of breach
        → T0 for processor = moment of awareness

Step 2: Processor must notify controller "without undue delay"
        → Check DPA for specific contractual deadline (24h/48h common)

Step 3: Controller's T0 starts when controller becomes aware
        → Controller's 72h clock starts at this point

Step 4: Controller assesses severity independently
        → python scripts/breach_severity_calculator.py (controller's assessment)

Step 5: Controller makes notification decisions
        → Processor provides information; controller decides on SA/subject notification

---

ENISA の重大度算定式

SE = (DPC x EI) + CB

要素	範囲	説明
DPC	1-4	データ処理のコンテキスト — データの性質と機微性
EI	0.25-1.0	識別の容易さ — 個人をどれだけ容易に特定できるか
CB	-0.5 to +1.0	漏えいの状況 — 加算要素（悪意、量、損失の種類）

重大度の判定

スコア範囲	判定	通知義務
<2	低	内部記録のみ。監督機関またはデータ主体への通知は不要
2 to <3	中	72時間以内に監督機関へ通知（Art. 33）
3 to <4	高	72時間以内に監督機関へ通知し、個人データ主体にも通知（Art. 34）
>=4	非常に高	監督機関とデータ主体に通知し、公開告知を検討。危機管理を実施

---

通知判断マトリクス

規制と重大度ごとの通知義務をすばやく確認できます。

規制	監督機関への通知	個人への通知	発動条件
GDPR Art. 33	72時間以内に監督機関へ	該当なし	権利および自由へのリスクが生じる可能性が低い場合を除く
GDPR Art. 34	該当なし	不当な遅延なく	高いリスクが生じる可能性がある場合
CCPA	州司法長官	影響を受ける消費者	暗号化されていない個人情報が侵害された場合
HIPAA	60日以内に HHS へ	影響を受ける個人	保護されていない PHI。500人超の場合はメディアにも通知
PCI DSS	24時間以内にカードブランドへ	カード会員（発行会社経由）	カード会員データが侵害された場合
NIS2 Art. 23	24時間以内に CSIRT へ（早期警告）、72時間以内（通知）	該当なし	重大なインシデント
AI Act Art. 62	15日以内に市場監視機関へ	該当なし	AI システムが関与する重大なインシデント

管理者と処理者の義務

義務	管理者	処理者
監督機関への通知	はい（Art. 33）	いいえ（管理者への通知のみ）
データ主体への通知	はい（Art. 34）	いいえ
すべての侵害を記録	はい（Art. 33(5)）	はい（管理者を支援）
管理者への通知	該当なし	はい。不当な遅延なく（Art. 33(2)）
重大度評価の実施	はい	支援（情報を提供）
期限の起点（T0）	管理者が認識した時点	処理者が認識した時点

---

トラブルシューティング

問題	考えられる原因	解決方法
重大度スコアが「中」と「高」の境界にある	パラメーターがしきい値の境界にある	保守的に評価します。3.0に近い場合は「高」として扱い、データ主体に通知してください。境界値の分析を記録してください
情報が不十分なまま72時間の期限が迫っている	継続的な調査が必要な複雑な侵害	Art. 33(4) の段階的通知を利用します。入手可能な情報を監督機関へ通知し、後から補足してください
処理者が侵害を発見したものの、管理者への通知が遅れた	DPA の契約上の期限を過ぎている可能性がある	遅延を記録し、処理者の遅延が管理者の義務遵守能力に影響したかを評価してください。DPA の条件を確認してください
国境を越える侵害で、どの監督機関に通知すべきか不明	複数の法域にまたがる処理で、主監督機関が不明確	主たる事業所の監督機関に通知します（ワンストップショップ）。不明な場合は、最も多くの影響対象者が居住する地域の監督機関に通知してください
暗号化されたデータが関与する侵害で、通知が必要か不明	暗号化によって重大度が下がる、または通知が不要になる可能性がある	暗号化が有効（強力なアルゴリズムが使用され、鍵が侵害されていない）であれば、Art. 34(3)(a) に基づき通知が不要となる場合があります。分析結果を記録してください
AI システムが侵害に関与しており、追加義務が不明	GDPR とともに AI Act Art. 62 が適用される可能性がある	AI システムが AI Act における高リスクに該当するか評価してください。重大なインシデントの場合は、GDPR 上の義務に加えて、15日以内に市場監視機関へ通知してください

---

成功基準

• 認識から2時間以内に侵害の重大度を算出する -- ENISA の手法を適用し、パラメーターとスコアリングの根拠を記録します
• T0 から72時間以内に SA への通知を提出する -- 重大度が MEDIUM 以上の侵害については、すべての情報が揃っていない場合、段階的な通知を使用します
• データ主体への通知を不当な遅延なく完了する -- 重大度が HIGH 以上の侵害については、影響と保護措置を明確に伝えます
• すべての対応措置をタイムスタンプ付きで追跡する -- T0 から終結までの侵害タイムラインを維持し、すべてのイベントを記録します
• 各規制の義務を特定し、履行する -- 適用される法律に従い、GDPR、CCPA、HIPAA、PCI DSS、NIS2、AI Act の義務を評価して履行します
• 侵害後の文書をすべて整備する -- 通知するかどうかにかかわらず、Art. 33(5) に従って内部の侵害記録を維持します

---

対象範囲と制限事項

対象範囲：

• すべてのパラメーターに対応した ENISA の侵害重大度算出
• GDPR Art. 33/34 の通知期限追跡
• 複数の規制における通知義務の評価（GDPR、CCPA、HIPAA、PCI DSS、NIS2、AI Act）
• 管理者と処理者の義務に関するガイダンス
• 国境を越える侵害の通知先振り分け
• Art. 33(4) に基づく段階的な通知のガイダンス
• 侵害対応イベントの追跡と期限の監視

対象外：

• 技術的なインシデント封じ込め（ネットワークの隔離、フォレンジック調査、マルウェアの削除）
• 監督機関への通知の提出（文書の作成のみ）
• 保険金請求の処理または補償範囲の分析
• 法執行機関との連携
• 広報または危機広報の戦略
• フォレンジック調査の手法

---

アンチパターン

• 時間を稼ぐために T0 の確定を遅らせる -- T0 は管理者が侵害を「認識」した時点であり、詳細がすべて判明した時点ではありません。72時間の猶予を延ばすために意図的に認識を遅らせることはコンプライアンス違反であり、規制当局からもそのように扱われます
• 文書化された分析なしに通知不要と判断する -- 通知不要との結論に至った場合でも、すべての侵害を記録して評価する必要があります。重大度分析の記録もなく「通知しないと決めた」とすることは、正当化できません
• 処理者からの通知を管理者からの通知として扱う -- 処理者が自らの SA に通知しても、管理者の Art. 33 に基づく義務は満たされません。管理者は独自に通知するかを判断し、届出を行う必要があります
• 暗号化を通知免除の自動的な根拠とする -- Art. 34(3)(a) の免除には、暗号化されたデータが判読不能な状態にされており、かつ暗号鍵が侵害されていないことが必要です。暗号化が不十分な場合や鍵が侵害された場合は対象になりません
• AI が関与する侵害で AI Act の義務を無視する -- 侵害に高リスク AI システムが関与する場合、GDPR に加えて Art. 62 に基づく重大インシデント報告（市場監視当局への15日以内の報告）が適用されます。これらは期限の異なる別個の義務です

---

ツールリファレンス

breach_severity_calculator.py

ENISA の侵害重大度スコアを算出し、通知義務を判定します。

フラグ	必須	説明
--dpc <1-4>	はい	データ処理の文脈：1=一般的な人口統計情報、2=行動・財務情報、3=機微な個人情報、4=特別カテゴリー／極めて機微な情報
--ei <0.25-1.0>	はい	識別の容易さ：0.25=無視できる、0.5=限定的、0.75=大きい、1.0=最大
--confidentiality <0/0.25/0.5>	いいえ	機密性の損失スコア（デフォルトは0）
--integrity <0/0.25/0.5>	いいえ	完全性の損失スコア（デフォルトは0）
--availability <0/0.25/0.5>	いいえ	可用性の損失スコア（デフォルトは0）
--malicious	いいえ	悪意ある意図を示すフラグ（CB に +0.5 を加算）
--t0 <ISO datetime>	いいえ	期限の計算に使用する T0 のタイムスタンプ
--template	いいえ	入力テンプレートを生成します
--json	いいえ	JSON 形式で出力します

breach_timeline_tracker.py

情報漏えい対応のタイムライン、イベント、規制上の期限を追跡します。

サブコマンド	説明
init	情報漏えいタイムラインを初期化します（--breach-id、--t0、--descriptionは必須、--outputは任意）
event	イベントを記録します（--timeline、--action、--categoryは必須）
status	ステータスダッシュボードを表示します（--timelineは必須、--jsonは任意）
deadlines	期限のステータスを確認します（--timelineは必須、--jsonは任意）